Schema markup and structured data

Entity clarity, which is the honest version of the AI argument

Once you accept that schema does not earn AI citations, a fair question follows: why do it at all beyond rich results? The answer is disambiguation, and it is worth separating from the claim it gets confused with.

Search engines maintain entity records: a model of which real-world things exist and which facts attach to each. Schema is the most direct way to state that yours is a specific business, with this legal name, at this address, with these verified profiles attached through sameAs. That does not make an engine quote you. It makes it less likely to confuse you with a similarly named company, attach the wrong location, or carry an outdated description.

This matters more than it used to, because those entity records feed things beyond the classic results page. But the causal chain runs through the record, not through the markup, and it is not a citation lever. We describe it as what it is: insurance against being misidentified, which is cheap to buy and expensive to fix later.

• sameAs links tying your site to verified profiles you control
• One consistent legal name, address and contact point across every page
• Explicit relationships between parent organisation, brands and locations
• Fewer opportunities to be confused with a similarly named business

What schema markup does, and what it does not do

Schema markup labels the facts on a page in a machine-readable format. It tells a search engine that this string is a price, that one is an opening time, and that the block below is a question with an answer. The engine no longer has to infer those things from layout and wording. That clarity does two useful jobs: it makes pages eligible for rich results in the search listings, and it reduces the chance an engine misreads what your business is and what it sells.

It is worth being blunt about the limits, because the market is full of claims that go well past the evidence. Schema is not a ranking factor. Adding it does not move you up the results page on its own. It also does not cause AI systems to cite you. Google states plainly that there is no special structured data you need to add for its AI features, and a controlled study that compared pages which added JSON-LD against similar pages that did not found no meaningful citation lift.

So we sell schema for what it genuinely delivers. Eligibility for the visual features that lift click-through. Clean entity signals that keep your name, location and services unambiguous across the systems that read them. Anyone promising schema will get you quoted by ChatGPT is selling something the evidence does not support.

• Real benefit: eligibility for rich results such as review stars, FAQs, breadcrumbs, events and products
• Real benefit: unambiguous entity facts, so engines connect your site, profiles and listings
• Not a benefit: direct ranking improvement, which Google has never claimed
• Not a benefit: guaranteed AI citation, which the available evidence does not support

The types that actually produce something visible

Most sites need far fewer types than the Schema.org vocabulary suggests. The question we ask for every proposed type is simple: does this produce a documented rich result, or does it clarify a fact an engine would otherwise get wrong? If the answer to both is no, we skip it. Markup that nobody consumes is maintenance debt.

Organization and its LocalBusiness subtypes carry the entity facts: legal name, logo, address, contact points and the sameAs links to your verified profiles. Product and Offer power the price, availability and review stars that appear in shopping and product listings. Article and its subtypes support publisher features. BreadcrumbList produces the path shown under a result, which is small but reliable. Event, Recipe, JobPosting, Course and VideoObject each support specific formats where they apply.

FAQPage and HowTo deserve a caution. Google narrowed FAQ rich results to a small set of authoritative sites and retired HowTo results in search. The markup is still worth having for entity clarity and for the structure it enforces on your content, but nobody should be promised the visual feature. We say that before we build it, not after.

• Organization and LocalBusiness for the core entity record
• Product, Offer and AggregateRating for shopping and product features
• BreadcrumbList for the path display under a listing
• Article, VideoObject, Event, JobPosting and Recipe where the content genuinely qualifies
• FAQPage and HowTo for structure, with honest expectations about the visual result

Building it into templates instead of pasting it per page

Hand-written markup on individual pages rots. Someone edits a price in the CMS, the JSON-LD block still says the old one, and the listing now contradicts the page. We avoid that by generating markup from the same data the page renders. One product record feeds both the visible price and the Offer node. One location record feeds both the contact block and the LocalBusiness node. They cannot drift apart because they come from the same source.

That approach also makes coverage complete by default. A new service page inherits Service and Organization markup the moment it is published. A new location inherits its LocalBusiness node. Nobody has to remember, and nobody has to check a spreadsheet of which pages got markup and which were missed.

We use JSON-LD in every case. It sits in a script tag, keeps the markup separate from the HTML, and survives design changes that would break microdata scattered through the page body. It is also the format Google recommends.

The errors we find most often

The single most common problem is markup that describes something the page does not show. A Product node on a category page. Review stars for the business pasted onto every product. An FAQPage node where the questions exist only in the markup. All of these are violations of the structured data guidelines, and Google applies manual actions for them. The rule is straightforward: the markup must describe content a visitor can see on that page.

After that, the errors are mostly technical. Required properties left blank, so the type is ineligible. Multiple conflicting Organization nodes across a template and a plugin, so the engine has to pick. Nodes that reference each other by an identifier that does not exist. Dates in the wrong format. Currency codes missing from an Offer. Ratings with no review count. None of these break the page, which is exactly why they sit undetected for years.

The third category is duplication. Sites that have accumulated three plugins over a decade often emit three overlapping sets of markup, each slightly different. We consolidate to one authoritative graph per page rather than adding a fourth.

• Markup for content that is not visible on the page, which breaches the guidelines
• Self-serving review markup applied where it does not belong
• Missing required properties that quietly block eligibility
• Conflicting Organization or LocalBusiness nodes from overlapping plugins
• Broken node references, malformed dates and missing currency codes

Validation, and why it has to be ongoing

Every piece of markup gets checked twice before it ships. The Schema.org validator confirms the syntax and vocabulary are correct. The Google Rich Results Test confirms the page is eligible for the specific feature we are targeting, which is a stricter test and the one that matters commercially. Passing the first and failing the second is common, and it is the gap where most agencies stop looking.

After launch we watch the enhancement reports in Search Console, because those show errors on live pages at scale rather than on the one URL you happened to test. A template change that breaks a required property will show up there as a sudden drop in valid items, usually before anyone notices a change in the listings.

We re-validate after any release that touches templates, pricing, CMS plugins or the design system. Structured data breaks silently and arrives with unrelated work, so a scheduled re-check catches more than an as-needed one.

How we measure whether it worked

The honest measure for schema is eligibility and appearance, not rankings. We track how many pages are valid for each type in Search Console, how many are showing the rich result, and what happens to click-through rate on those pages once the feature appears. A page holding the same position with a higher click-through rate after markup went live is the outcome we are looking for.

We also track the entity side, which is less visual but often more valuable. Whether the knowledge panel shows the right logo and description. Whether branded searches surface your correct site links and profiles. Whether third-party tools reading your Organization data return the facts you intended.

What we will not do is attribute a ranking change or an AI mention to markup. There is no clean way to isolate that, and the studies that have tried did not find the effect. Reporting that claims otherwise is guessing dressed as measurement.

• Valid items by type in Search Console, tracked over time
• Rich result impressions and how they change click-through at stable positions
• Knowledge panel accuracy: logo, description, profiles and contact details
• Error and warning counts after each release, so regressions get caught fast