Schema Markup Audit Checklist: Test, Fix and Monitor Structured Data

A schema markup audit asks a deceptively simple question: does the structured data on a page accurately describe visible content in a form that machines can understand and, where relevant, Google can use?

Passing one validator is not enough. Markup can be valid Schema.org vocabulary but ineligible for a Google rich result. It can also pass a technical test while describing content that users cannot see, pointing to the wrong canonical page or repeating stale template values across thousands of URLs.

The strongest audit therefore works at three levels: code validity, semantic accuracy and search-feature eligibility. It samples the right pages, fixes recurring problems at their source and leaves an evidence trail that can be checked after deployment.

What a schema markup audit should prove

Structured data gives explicit labels to entities and relationships on a page. A product page may identify a product, its offer and its review aggregate. An article may identify its headline, author, dates and primary image. The markup is useful only when those statements match the page and follow the vocabulary and platform rules.

A complete audit should answer five questions:

1. Coverage: Is markup present on every intended template and absent where it does not belong?
2. Validity: Does the code parse, and do properties fit the declared Schema.org types?
3. Accuracy: Does the markup match visible, current page content?
4. Eligibility: Does it meet the current requirements for a supported search feature?
5. Consistency: Do canonical URLs, entity identifiers and template values remain coherent across the site?

This scope prevents two common failures. The first is the “green test” fallacy: assuming a single valid example proves the whole implementation. The second is overmarking: adding types and properties merely because they exist, even when the page does not substantiate them.

The three validation layers

Use separate tests because each one answers a different question.

Google’s documentation explicitly says correctly marked-up content is not guaranteed to receive a rich result. Search systems consider additional quality, relevance and policy signals. Treat eligibility as an opportunity, not an entitlement.

The TRACE audit workflow

The original TRACE workflow turns a collection of validator checks into a repeatable audit.

T — Target eligible outcomes

Start with the business and search outcome. Use Google’s supported structured-data gallery to identify features that actually apply to the site. Then map each supported type to a real page template.

For example, Article may fit editorial pages, Product may fit pages for individual products, and LocalBusiness may fit a genuine business location page. A category archive is not automatically a product, and an internal navigation trail should not be marked as a recipe or review.

Create a scope table before crawling:

If a type is not supported by Google, it may still have semantic value for another consumer. Record that purpose explicitly rather than mixing it into a rich-result KPI.

R — Retrieve a representative sample

Do not choose only clean, popular URLs. Build a stratified sample that includes:

• at least one normal URL from every marked-up template;
• high-traffic and high-conversion pages;
• newly published and old content;
• pages with missing optional fields;
• paginated, localized or variant URLs where applicable;
• URLs with parameters, canonicals or redirects;
• examples already flagged in Search Console;
• JavaScript-rendered pages if markup is injected client-side.

For a small site, testing every eligible URL may be practical. For a large site, crawl the full population for detectable properties and manually review a representative sample for semantic accuracy.

The sample should preserve evidence: URL, template, canonical, detected types, test date, tool used, outcome and issue owner.

A — Assess syntax, meaning and eligibility

Run every sample through the relevant layers.

Inspect the delivered code. Confirm whether JSON-LD, Microdata or RDFa is present in the final rendered page. Google generally recommends JSON-LD when the setup allows it because it is often easier to maintain, but supported formats can work when implemented correctly.

Validate the vocabulary. Use Schema.org Validator to identify parsing problems, unknown types, misplaced properties and type/property mismatches.

Test Google eligibility. Use Rich Results Test on the live URL and, when debugging a pending release, on a code snippet. Review errors and warnings by item, not only the overall result.

Compare with visible content. Check names, dates, ratings, prices, availability, authors, images and other claims against what a user can see. Hidden or misleading markup can violate Google’s structured-data policies.

Check page signals. Verify the canonical URL, indexability, HTTP status, robots controls and rendered DOM. Valid markup on a non-indexable duplicate may not support the intended canonical page.

C — Correct the source template

Group defects by cause before editing anything.

If 500 pages lack dateModified because one component never emits it, fix the component. If an upstream product feed sends stale availability, correct the feed or transformation. Page-by-page patches hide the systemic problem and are likely to regress.

For each fix, define:

• affected template or data source;
• owner and reviewer;
• intended output;
• representative test cases;
• negative test cases where markup must not appear;
• rollback condition;
• monitoring window.

Deploy to a staging environment when possible. Test rendered output, not only the source template, because tag managers, consent layers, rendering services and JavaScript can change the final page.

E — Evidence and monitor

After deployment, re-run the same sample and store before-and-after results. Then watch Search Console’s applicable rich-result report. Google may need to recrawl pages before the report reflects a fix, so record the deployment date and avoid treating an immediate unchanged count as failure.

Use URL Inspection for a few important URLs when appropriate, but rely on normal crawling and an accurate sitemap for broad discovery. Do not repeatedly request indexing for unchanged pages.

A practical schema audit checklist

Inventory and scope

• List every page template that emits structured data.
• Record each type, format and generation method.
• Map types to supported search features and documented purposes.
• Identify the code owner and the underlying data owner.
• Export Search Console enhancement errors and affected example URLs.

Page and crawl checks

• Confirm the URL returns the intended status code.
• Verify it is indexable and points to the correct canonical.
• Check both raw HTML and rendered output when JavaScript is involved.
• Confirm markup is present once at the intended scope.
• Test localized, paginated, variant and edge-case pages.

Entity and property checks

• Use the correct @context and intended @type.
• Keep stable @id values for the same entity where an identifier is used.
• Match names, URLs, dates, images and other facts to visible content.
• Include required properties for the targeted feature.
• Evaluate recommended properties only when accurate data exists.
• Connect nested entities logically instead of publishing contradictory duplicates.

Policy and quality checks

• Do not mark up hidden, misleading or unrelated content.
• Do not fabricate ratings, reviews, prices, authors or availability.
• Use a specific supported type only when the page genuinely fits it.
• Confirm images are crawlable, representative and rights-cleared.
• Keep marked dates and other changeable values current.

Release and monitoring checks

• Test representative pages in Schema.org Validator.
• Test relevant pages in Google Rich Results Test.
• Save evidence before and after the fix.
• Deploy template fixes with regression cases.
• Watch Search Console after recrawl.
• Add recurring checks for template and feed changes.

How to prioritize issues

Not every warning deserves the same queue position. Use a transparent score that reflects impact, coverage and confidence.

Audit priority score = impact × coverage × confidence

Score each factor from 1 to 3:

A confirmed required-property failure across a major template scores 27 and should outrank a low-impact warning on one page. The score is an internal triage aid, not a Google metric and not a ranking predictor.

Track two simple operational measures:

Critical-error-free rate = URLs without critical errors ÷ URLs tested × 100

Template coverage rate = eligible templates with validated markup ÷ eligible templates in scope × 100

Keep the denominator and sampling method visible. A 100% rate across three hand-picked URLs does not prove sitewide health.

Common failures and overmarking traps

A technically valid but inaccurate value

A parser can accept a price or author value that is wrong. Always compare structured data with the rendered page and source system.

Markup on the wrong template

Sitewide organization, product or article markup is sometimes injected everywhere. Scope each entity to pages that substantiate it and connect shared entities deliberately.

Duplicate entities with conflicting values

A theme, plugin and tag manager may each publish their own JSON-LD. The result can be three versions of the same organization or product. Consolidate responsibility and use stable identifiers where helpful.

Copying a schema example without adapting it

Documentation examples illustrate structure; they are not production data. Remove properties your page cannot support and replace every placeholder with verified content.

Treating warnings as automatic failures

Errors typically block eligibility for the affected item. Warnings often indicate recommended properties that may improve completeness. Review the documented requirement and data quality before adding a value merely to silence a warning.

Assuming no rich result means broken markup

Eligibility is not display. Google can choose a normal result even when markup is valid. Diagnose technical issues with the relevant tests and Search Console, but do not promise a rich result or ranking improvement.

Reporting template and metrics

Use one row per issue group, not one row per affected URL when the cause is shared.

This format links the visible defect to the code or data decision that can prevent recurrence.

Frequently asked questions

Which tool should I use to validate schema markup?

Use Schema.org Validator for vocabulary and structural validation. Use Google Rich Results Test for Google-supported rich-result eligibility. Use Search Console to monitor what Google detects across eligible indexed pages.

Does valid schema markup guarantee a rich result?

No. Google states that valid structured data does not guarantee an enhanced result. The page must also meet quality and policy requirements, and Google decides what result format to show.

Is JSON-LD better than Microdata?

Google supports multiple formats and generally recommends JSON-LD when the site setup allows it. The best choice is the one your team can generate accurately, keep synchronized with visible content and test reliably.

Should every page have every possible schema type?

No. Use markup that accurately describes the page and serves a documented consumer or feature. Unrelated or misleading markup creates risk without meaningful value.

How often should a schema audit run?

Run focused validation after template, CMS, plugin, feed or rendering changes. Add periodic monitoring based on release frequency and business risk, and investigate new Search Console errors when they appear.

The bottom line

A useful schema audit is not a hunt for the largest number of types or a single green test. It proves that structured data is present where intended, technically valid, truthful, eligible for the desired feature and maintainable at scale.

Use TRACE to define the target, sample the real site, test three validation layers, fix the source and preserve evidence. That turns structured data from a fragile plugin output into a governed part of the publishing system.

Sawaira