Why Your Schema Markup Isn't Working: A Diagnostic Checklist for Local Sites

Every schema problem falls into one of three buckets, and naming the bucket before touching code saves hours. An eligibility failure means the markup is fine but the page or the type does not qualify for the feature you are expecting. A rendering failure means the crawler never received the markup you think is on the page. A recognition failure means the markup was received and is valid, but the search engine or AI system does not trust or cannot resolve the entity it describes.

The three have completely different fixes. Eligibility problems are solved by changing expectations or changing page content. Rendering problems are solved in the build and delivery layer. Recognition problems are solved slowly, through consistency and corroboration across the web. Misdiagnosing between them is why so many teams keep re-editing JSON-LD that was never the problem.

The single most common cause of "my schema is not working" is that the feature was retired or narrowed. Rich result programs are not permanent. Over the past several years the visible footprint of FAQ and HowTo results in particular has been sharply reduced for most site types, and several review-related displays have been restricted by category. Markup that once produced a visible enhancement can be perfectly valid and simply no longer eligible to draw anything on the results page.

This does not make the markup worthless. Structured data still functions as machine-readable clarification, which is precisely what generative systems consume when deciding what a page is and whether to cite it. But you have to separate two goals: earning a visual feature in traditional search, and being unambiguously understood by a system that reads rather than displays. Judge each piece of markup against the goal it can actually serve.

Practical fix: before you debug anything, confirm which enhancement reports exist for your property and which features are currently documented as supported for your content type. If the feature is gone, stop optimizing for a screenshot from 2021 and treat the markup as an extraction aid instead.

Structured data is a description of the page, not an additional page. When the two disagree, the description loses. Marked-up FAQ answers that do not appear in the rendered content, an aggregate rating with no reviews visible anywhere, an offer price that contradicts the pricing table, opening hours that differ from the footer: each of these is a mismatch, and mismatches get markup ignored at best and treated as manipulation at worst.

The check is unglamorous. Load the page with JavaScript disabled if possible, read the visible text, and confirm every factual claim in your JSON-LD appears on screen in substantively the same form. Wording does not have to be identical, but the substance does. If an answer in your markup is 90 words and the visible version is a two-word bullet, that is a mismatch.

The most frequent version of this on service sites is stale content in a template. Someone updated the visible price range on a service page and left the offers block untouched, or added new service areas to the copy without touching areaServed. Any field that a human edits should have an owner responsible for updating the markup in the same pass.

This is the check almost nobody runs, and it explains a large share of silent failures. Testing tools frequently execute JavaScript. Crawlers do too, but on their own schedule and with their own budget, and anything that depends on a third-party tag manager, a consent gate, or a client-side hydration step can be absent in the version that gets indexed.

Fetch the raw response and look for your markup in it directly rather than in the browser inspector. A request with curl, or the raw HTML view in a crawling tool, tells you what the server actually sent. If your JSON-LD only appears in the DOM inspector and not in the raw response, it is being injected client-side, and that is a rendering dependency worth removing.

Two related traps: markup injected through a tag manager after a cookie consent decision will be missing entirely for any crawl that never consents, and markup rendered inside an iframe belongs to the iframe's document rather than the page you care about. Both fail quietly and look fine to a human tester.

A robots.txt rule that blocks a script or a JSON endpoint your markup depends on can neutralize structured data without producing any validation error. So can a noindex on the page, a canonical pointing somewhere else, or a redirect chain that lands on a different URL than the one you tested. Structured data is evaluated for the canonical version of a page, so markup unique to a non-canonical duplicate is generally wasted work.

Check the canonical first. On templated location and service pages this is where multi-page programs go wrong: several URLs share a canonical, so only one version's markup is ever considered. If you run city or state pages, our guides on city and service page structure and scaling service area pages safely cover the canonical patterns that keep those pages independently eligible.

Multiple plugins, a theme, and a hand-written block can each emit their own Organization or LocalBusiness node. The result is two or three descriptions of the same business with different names, phone numbers, or logos, and no indication of which is authoritative. Search engines resolve this by picking one or by trusting none of them.

The fix is consolidation, not addition. Emit one graph per page, assign a stable @id to each entity, and have every other node reference those identifiers instead of repeating fields. A Service node points at the business with provider and an @id. A BlogPosting points at the same node with publisher. Once identifiers are consistent site-wide, a crawler can assemble one coherent picture of the business from many pages instead of a pile of near-duplicates.

Audit for this by counting script blocks of type application/ld+json in the raw HTML. If a page has more than one and you did not deliberately author each, you have found a real problem.

Markup asserts. Corroboration confirms. When a business claims a name, address, and phone number in JSON-LD but no other source on the web agrees, there is nothing to validate the assertion against, and the entity stays weak. This is the failure mode that no amount of code editing fixes.

Consistency across your Google Business Profile, major directories, licensing bodies, trade associations, and your own site is what turns markup into a recognized entity. Our guides on NAP consistency in the AI era and building an entity search engines and AI systems recognize go deeper on this work, which is slower than markup but far more durable.

Structured data is processed on a crawl, and a crawl is not instant. For a page that gets crawled frequently, changes can be reflected within days. For a low-traffic location page on a small site, several weeks is normal, and enhancement reports lag further behind still. Judging a change after 48 hours produces false conclusions and, usually, a second round of unnecessary edits.

Set a review date instead of refreshing reports. Make one deliberate change, record what you changed and when, and evaluate after a full crawl cycle. Changing five things at once and then rolling half of them back guarantees you will never know which one mattered.

Many teams conclude schema "is not working" because no visual enhancement appeared, while ignoring the outcome that has become more valuable: being read correctly by systems that answer questions. Those systems do not report back. Absence of a star rating is not absence of effect.

Useful proxies for the AI side of the picture include running a fixed set of buying-intent prompts monthly and logging whether your business appears, watching branded search volume, and watching direct traffic in your service area. Our guide to tracking whether AI assistants recommend your business lays out that measurement routine. On the traditional side, watch impressions and click-through rate for the specific pages you marked up rather than sitewide totals, which drown the signal.

Turn the checks above into a short recurring pass rather than a one-time project. Fifteen minutes per template, four times a year, catches nearly everything before it compounds.