Start with the pages that already rank or already earn impressions. That is the fastest useful structured data audit, because those pages are already visible enough for schema mismatches, unsupported types, or stale fields to matter. The job is not just to confirm that markup exists. It is to check whether the markup matches the real page type, the visible page content, and Google's currently supported rich result features, then decide whether to keep it, fix it, simplify it, or remove it.
If the page itself is weak, mixed-intent, non-indexable, or not clearly the right URL for the query, do not expand the schema first. Fix the page decision first. Structured data can clarify a good page. It does not rescue a page whose purpose is still unclear.
The Short Answer: Audit the Pages That Already Rank
A ranking-page audit is narrower than a sitewide schema project, and that is exactly why it works. When a page already competes, you can review markup against real query context instead of auditing every template blindly. You can see whether the page could plausibly earn a rich result, whether the current schema type fits the page, and whether the indexed version still matches what your code says.
Use this operating model:
| Audit question | What to check first | Output |
|---|---|---|
| Is this page worth auditing now? | It already ranks, already earns impressions, or sits close enough to matter for the target query or cluster. | Include it in the audit set. |
| Does the page deserve its current schema type? | Real page type, visible content, and Google's supported feature set. | Keep, change, or remove the type. |
| Is the markup merely valid, or actually useful? | Syntax, Google eligibility, and what Google detects on the indexed page. | Fix, simplify, or ignore. |
| What should be fixed first? | Critical errors, wrong type choice, conflicts, missing required properties, then maintainable optional properties. | Clear remediation order. |
The first decision rule is simple: if the page is not worth enhancing as a page, it is not worth enhancing with markup.
Decision rule: audit ranking or near-ranking URLs first, and do not widen into a full-site schema inventory unless the same problem repeats across a template.
Build a Ranking-Page Audit Set First
Pull the audit set from Google Search Console, live SERP review, or both. The point is to start with URLs that already have search visibility, not with every URL a crawler can find. Pages already earning impressions are where schema review becomes practical instead of theoretical, because you can judge the markup against a query, a page type, and a real search result environment.
That first pass gets easier when the team is explicit about the difference between SERP context and page-level source data. Search Console and live results help you choose the right audit set. The page itself still has to prove what markup it actually outputs and whether that output matches the live, canonical URL.
A small audit sheet is enough if the columns are right:
| Field | Why it matters |
|---|---|
| Query or query cluster | Keeps the review tied to one search problem instead of one template assumption. |
| Page URL | Defines the actual ranking asset under review. |
| Page type | Prevents article pages, product pages, category pages, and FAQ-style sections from being reviewed as if they were interchangeable. |
| Current markup type | Shows what the page is trying to communicate now. |
| Collection date | Matters when the page, SERP, or feature set changes over time. |
| Rich result potential | Forces the question of whether the page could reasonably qualify for a supported enhancement at all. |
That last column matters more than most teams admit. Many audits begin by asking whether the schema is valid. The better first question is whether the page even has a believable rich result path. A plain marketing page that carries FAQPage, Product, or another ambitious type may be syntactically clean and still be the wrong candidate.
Keep the scope tight at first. If you are reviewing one ranking article, do not mix that job with a complete sitewide schema count. Expand only if you find the same issue across multiple ranking URLs of the same kind.
Red flag: if the sheet mixes manually checked ranking pages with a generic export of every site URL, you are no longer running a ranking-page audit. You are blending two different jobs and weakening both.
Match the Page Type Before You Test the Markup
Before you run a validator, confirm what the page actually is. This step blocks a common failure mode: teams test syntax first and never ask whether the page deserves that schema type in the first place.
For ranking pages, the useful categories are usually concrete: article, product, recipe, video page, forum page, breadcrumb-supported content page, event page, or something else clearly defined. A broad schema.org graph may still describe the page honestly, but if your goal is Google rich result eligibility, the meaningful boundary is Google's documented supported feature set, not the entire schema.org universe.
For a normal article page, the baseline is usually small and maintainable. In practice, this is close to using schema and headings to clarify what an article page really is: Article or BlogPosting, visible author details when real, real publication or update dates, the actual hero image, and breadcrumbs where the page genuinely sits in a hierarchy are often enough. JSON-LD is usually the easiest format to maintain, which matters more in audits than novelty does.
Use page fit, not wishful thinking:
| Page situation | Usually sensible | Common trap |
|---|---|---|
| Real editorial article | Article or BlogPosting plus maintained supporting fields |
Adding extra types because the page feels too plain |
| Product page with real commercial details | Product markup that reflects visible price, availability, and product identity | Marking up a generic landing page as a product |
| Article with a short FAQ section | Keep article markup unless the page is truly an FAQ page and the feature expectation is justified | Treating FAQPage as a routine enhancement |
| Video-first page | Video markup when the video is central and visible | Using video markup when the page only embeds a supporting clip |
| Mixed marketing page | Minimal descriptive markup, or none beyond basics | Forcing a rich-result type onto a page with unclear purpose |
This is where current expectations need restraint. Valid FAQPage markup is not a general-purpose visibility play for normal marketing sites, and a page does not become a product page because it mentions pricing somewhere. If the page type is not clear to a careful human reviewer, it is not clear enough for schema expansion either.
Stop sign: do not add more markup until the page type is clear, indexable, canonical, and worth enhancing on its own.
Use Three Checks: Markup, Eligibility, and Indexed Reality
One tool is not enough, because one tool cannot answer every audit question. A practical review separates three layers: what your page outputs, whether Google sees that markup as rich-result eligible, and what Google actually detects on the indexed page.
| Layer | Best check | What it answers | What it does not answer |
|---|---|---|---|
| Source markup | View source, rendered HTML, or crawler output | What schema is actually on the page, whether scripts are duplicated, and whether types conflict | Whether Google supports the type for a rich result |
| Google eligibility | Rich Results Test | Whether the page qualifies for supported Google rich result features and which required or optional fields are missing | Whether the enhancement will actually show in Search |
| Syntax and graph validation | Schema.org Validator | Whether JSON-LD, RDFa, or Microdata extracts cleanly and whether the graph is structurally sound |
Whether the markup is eligible for a Google feature |
| Indexed reality | Search Console rich result reports and URL Inspection | What Google appears to detect on the indexed page and whether the live output matches indexed understanding | A complete inventory of every issue or every affected page |
This separation matters because "valid" is overloaded. A page can be valid in Schema.org Validator and still fail Rich Results Test because the type is unsupported for that feature. A page can pass Rich Results Test and still not show a rich result. A page can pass both tools and still be misread in practice because the indexed page differs from the source you just inspected.
Run the layers in order:
- Confirm the page's real markup and look for duplicate, conflicting, or stale scripts.
- Test the page in Rich Results Test when the goal is Google feature eligibility.
- Use Schema.org Validator to catch extraction and graph issues outside Google's feature boundary.
- Check Search Console and URL Inspection to see whether Google's indexed understanding matches the current page state.
Search Console is useful here, but do not treat rich result reports as exhaustive inventories. They are operationally helpful, not a census of every URL and every issue on the site.
Practical takeaway: separate code validity from Google eligibility, and separate both from indexed reality. Most audit confusion comes from collapsing those layers into one pass.
Fix the Mismatches That Actually Block Rich Results
Once the page type is right and the tools are separated, prioritize the fixes that change the outcome. The biggest wins rarely come from adding more optional fields first. They come from removing contradictions between the markup and the page the user and Google can actually see.
Use this order:
| Priority | What to fix | Why it comes first |
|---|---|---|
| 1 | Critical errors and broken markup | Invalid output can block detection entirely. |
| 2 | Wrong or unsupported type choice | A clean but wrong type sends the audit in the wrong direction. |
| 3 | Conflicting or duplicate markup | Multiple scripts can create contradictory signals. |
| 4 | Missing required properties | These determine feature eligibility more than embellishment does. |
| 5 | Optional properties worth maintaining | Useful only when the page can keep them accurate over time. |
The most common blocking mismatches are content mismatches. The schema says one thing; the page shows another. Dates change in markup but not on the page. Price or availability is stale. Ratings are marked up without visible support. The FAQ text differs from the visible page copy. The author field exists in markup even though the page shows no author. The image field points to an asset that no longer matches the live hero image. Headings were rewritten, but the schema was never updated.
Check these fields against the current canonical page state:
| Field or signal | What to verify |
|---|---|
| Title and headline alignment | The page still uses the title or headline the markup describes. |
| Dates | datePublished and dateModified match visible reality and are not being used as fake freshness. |
| Author or publisher details | The marked-up identity is visible and supportable. |
| Images | The referenced image is accessible and matches the live page. |
| Price, availability, and offer details | Product-related fields reflect the visible commercial state now. |
| FAQ content | The questions and answers in markup match the visible content exactly. |
| Canonical and indexability | The page is canonical, not blocked, and still the right URL to enhance. |
Also check for technical mismatches outside the schema block itself. A noindexed page with perfect markup is not a rich-result opportunity. A canonicalized duplicate is not the page to optimize. A blocked image can limit how the enhancement appears. A plugin that injects one graph while the CMS outputs another can turn a valid-looking page into a messy one.
Priority rule: fix the contradictions that make the page untrustworthy before you enrich the page with more fields.
Why Valid Schema Still May Not Show
Valid schema creates eligibility, not a promise. That is the practical answer behind most "valid but not shown" confusion.
There are several routine reasons a page can validate and still show no rich result:
| Reason | What to verify before changing anything |
|---|---|
| The type is valid but not relevant to a supported Google feature | Check whether the markup maps to a currently supported feature, not just to schema.org vocabulary. |
| The page fit is weak | Confirm that the page is genuinely the type it claims to be. |
| The markup and visible content do not align cleanly | Re-check dates, authorship, FAQ wording, pricing, images, and page headings. |
| The feature is restricted or rarely shown | Do not assume broad display just because the type validates. |
| The SERP design or query pattern does not favor that enhancement | Look at the current results before adding more markup. |
| Google chooses not to show the enhancement | Accept that eligibility does not force display. |
FAQPage is the clearest example of why this distinction matters. A page can carry valid FAQ markup and still have no realistic expectation of FAQ rich-result display on a normal marketing site. That does not make the code broken. It means the feature expectation is wrong.
The same caution applies to article pages. A clean Article graph can help Google interpret dates, authorship, image associations, and page type, but it does not guarantee a special result presentation for that query. If the page already ranks, the right question is not "How do we force a rich result?" It is "Is this markup accurate, useful, and worth maintaining?"
Decision rule: treat "valid but not shown" as a diagnostic state. First check feature support, page fit, content alignment, and indexed detection. Only then decide whether to keep, simplify, or drop the markup.
Red Flags That Mean You Should Simplify or Remove Markup
Some audit outcomes should not lead to expansion. They should lead to less markup, not more. Teams often keep layering fields onto a page because each individual addition feels harmless. In practice, over-marked pages become harder to maintain and easier to misalign with reality.
| Red flag | Why it matters | Better action |
|---|---|---|
| The page type is still arguable | You cannot maintain accurate schema on top of an unclear page model | Clarify the page first or keep markup minimal |
| The fields are not maintained by the publishing workflow | Accurate today becomes stale next month | Remove optional fields the team cannot keep true |
| A plugin outputs broad markup across every page | Generic schema often overstates what the page really is | Narrow the implementation to the pages that deserve it |
| Duplicate graphs describe the page differently | Conflict is worse than simplicity | Consolidate to one clean implementation |
| The enhancement expectation depends on folklore | The markup strategy is being driven by wishful thinking, not page fit | Revert to supported, honest, maintainable markup |
| The page keeps changing faster than the metadata is updated | Structured data becomes a lagging copy of the old page | Simplify until the workflow can keep pace |
This is the part many audits skip. Sometimes the right answer is not to fill every optional property. Sometimes it is to reduce the graph to the fields that are real, visible, and operationally durable.
Red flag: if you need perfect editorial discipline to stop the markup from becoming stale, the implementation is already too ambitious for that page.
When to Keep the Audit Small, and When to Expand to the Template
Stay at page level when the issue is local. Expand to the template, plugin, or implementation layer when the same defect repeats across multiple ranking URLs of the same page type.
Use this boundary:
| Pattern you find | Best scope |
|---|---|
| One page has stale dates or a mismatched image | Fix the page-level content and metadata |
| One manually edited page uses the wrong type | Correct that page first |
| Several ranking articles share the same missing required field | Audit the article template |
| Multiple pages output duplicate or conflicting graphs | Review the plugin or schema injection layer |
| Search Console shows the same rich result issue across a class of URLs | Escalate to a template-level review |
A useful audit stays small until repetition proves otherwise. That keeps the work decision-driven. If one ranking URL has a local mismatch, you do not need a six-week schema project. If five ranking URLs from the same template share the same wrong Article graph, you do.
This is also the moment where ad hoc checks usually stop scaling. Once the same page type repeats, teams need a cleaner way to extract structured source data from selected URLs, compare visible page fields to output markup, and review canonical state without relying on memory or screenshots.
Expansion rule: promote the audit to template level only when the same ranking-page problem appears more than once in the same implementation pattern.
Final Checklist Before You Revalidate
Run this pass before you call the work done:
- Confirm the page is the right canonical, indexable URL for the target query or query cluster.
- Check that the schema type matches the real page type, not the team's hoped-for enhancement.
- Verify that visible headings, dates, authorship, images, prices, FAQs, and publisher details still match the markup.
- Inspect the source or rendered HTML for duplicate, conflicting, or stale schema blocks.
- Test Google feature eligibility in Rich Results Test.
- Test syntax and graph extraction boundaries in Schema.org Validator when needed.
- Use URL Inspection or Search Console to confirm what Google appears to detect on the indexed page.
- Separate three outcomes in your notes: syntax fixed, eligibility fixed, and actual rich result appearance still unconfirmed.
- Remove or simplify fields the team cannot keep accurate.
The final principle is the one worth keeping: fewer accurate, maintainable fields are better than ambitious markup that drifts away from the live page.
FAQ
What is the fastest way to audit structured data on pages that already rank?
Start with pages that already rank or already earn impressions, then review them in three layers: source markup, Google rich-result eligibility, and indexed detection in Search Console or URL Inspection. That gives you a page-level decision quickly without turning the job into a blind sitewide crawl.
Why does valid schema markup still fail to show rich results?
Because valid markup only creates eligibility. A rich result may still not appear when the type is unsupported for the feature you expect, the page does not fit the type cleanly, the visible content and schema do not align, the feature is restricted, or Google simply does not choose to show the enhancement for that query.
Should I use Rich Results Test or Schema.org Validator first?
Use Rich Results Test first when your question is Google feature eligibility. Use Schema.org Validator when you need to check syntax or graph extraction boundaries beyond Google's supported feature set. They answer different questions, so neither one replaces the other.
Should every ranking article page use FAQ or extra schema types?
No. A ranking article page should usually start with honest article-level markup such as Article or BlogPosting and only the supporting fields the team can keep accurate. Extra schema types are not routine additions. They are decisions that need page fit, visible support, and a realistic reason to exist.
Want more SEO data?
Get started with seodataforai →