A structured data audit compares what a page tells search engines with what a reader actually sees.
A valid block of code can still name the wrong author or point at the wrong page. That is why the useful question is not simply, “Does this have schema?” It is, “Does this describe the page correctly?”
Use the example below to check one article, fix the source of a mismatch and see whether the repair holds across the site.
Start with the article in front of you
Open this page alongside its article record. The record is the source copy; the browser shows the result.
- Compare the title. The record's title should agree with the visible heading and the article headline in JSON-LD.
- Compare the author. The page and markup should identify the actual contributor. Do not replace an AI contributor with a human name to make the markup look stronger.
- Compare the address. This article's canonical address ends in
/article/structured-data-audit/. Its canonical link and article references should identify that same page. - Compare the dates. The first publication and the latest revision are different events. An edit should not erase the original publication date.
You can inspect the rendered HTML in your browser's developer tools and find the application/ld+json blocks. Google's Rich Results Test checks supported Google features; the Schema.org validator helps inspect the wider vocabulary. Neither substitutes for comparing the description with the visible page.
One organization should not become two identities
JSON-LD uses @id values to connect descriptions of the same thing. This site's organization is identified as https://seo.krisada.com/#organization. Its website has a separate website identity.
A second block of JSON-LD is not automatically a problem. A second, competing identity for the same organization is the thing to investigate.
For example, if an article points to one publisher ID while its catalog creates another publisher for the same site, compare the records before adding anything. Keep the richer correct information and make the references agree.
That example is a failure pattern to look for, not a claim that this site's current graph has that defect.
Use the catalog to check the whole library
SEO.Krisada.com uses Digital Karma Federation v8.2. Its catalog lists the site's content collections, and its rendered audit receipt records a sitemap-wide check.
The receipt checked on October 5, 2026 reported:
| Check | Recorded result |
|---|---|
| Sitemap pages checked | 113 |
| Pages passed / failed | 113 / 0 |
| Expected Datasets per page | 6 |
This is a dated snapshot. The linked receipt is rebuilt, so later counts may change.
Under this portfolio's rules, each sitemap page must connect to the catalog and its declared Datasets. A clean homepage cannot stand in for the other pages. Compare the receipt's sitemap with the current sitemap and check whether the report still describes the published version.
This verifies the portfolio's implementation. It does not certify Google rankings or AI citations. Google explains its separate requirements in AI features and your website.
Fix the source, then repeat the failed check
If the title is wrong in the JSON record, repair the record. If the record is right but the browser prints something else, inspect the template. If references disagree across templates, reconcile the shared identity instead of adding another publisher.
After the repair, reload the affected page and compare the same fields again. Then repeat the sitemap-wide check so a fix to one template does not hide a failure elsewhere.
The proof is the corrected published result, not the fact that a file was saved.
For help with the writing before the audit, use Writing Content AI Can Read and People Can Use. For a recurring problem across the library, start with Content Systems.
