Related: JavaScript SEO: What Google Actually Indexes, and When Rendering Costs You
Structured data is a machine-readable description of what a page is about, embedded in the page itself. Done right it produces richer search listings, feeds knowledge panels, and gives AI answer engines an unambiguous reading of your content. Done wrong — which is most of the time — it does precisely nothing.
This is a practical guide to the parts worth implementing and the mistakes that quietly waste the effort.
Use JSON-LD, not microdata
There are three syntaxes. Microdata and RDFa interleave attributes through your HTML, which means every template change risks breaking the markup. JSON-LD sits in a single <script type="application/ld+json"> block, separate from presentation.
Google recommends JSON-LD and it is easier to maintain. There is no serious argument for the alternatives on a new build.
The types worth your time
Schema.org defines hundreds of types. A handful produce anything visible.
FAQPage
Question and answer pairs. This is the highest-value type for most service businesses, less for the search snippet — Google narrowed FAQ rich results to authoritative sites — than because it hands AI answer engines pre-formed answers to quote.
The rule that catches people: every question and answer in the markup must be visible on the page. Marking up FAQs that only exist in the JSON-LD is a violation and gets the whole block ignored.
Organization
Your identity. Name, logo, URL, contact point, and — the part most sites omit — sameAs, an array of links to your profiles elsewhere. That array is how a search engine connects your website to the entity it already has records for.
Put it on every page or at least the homepage. Keep the details identical to what appears everywhere else you are listed; a mismatch between your schema and your directory listings undermines both.
Article and NewsArticle
For editorial content. Include headline, datePublished, dateModified, image, and a real author object rather than a bare string. An author with a name, a URL and a description carries more weight than "author": "Admin".
Keep dateModified honest. Bumping it without changing anything is a well-known trick and is discounted accordingly.
Product and Offer
If you sell something at a listed price, this produces price and availability in the listing. Reviews and ratings can appear too, but only for genuine reviews collected from real customers — self-serving markup on your own products is explicitly disallowed and is one of the most commonly penalised abuses.
BreadcrumbList
Low effort, reliable payoff. It replaces the raw URL in the search listing with a readable hierarchy, and it helps machines understand your site structure. If your site has any depth, implement it.
LocalBusiness
For anywhere with a physical presence. Address, geo coordinates, opening hours, phone. Feeds local packs and map results. Use the most specific subtype that fits — ProfessionalService, Restaurant, Dentist — rather than the generic parent.
The mistakes that waste the effort
Marking up content that is not on the page
The most common failure and the most serious. Structured data must describe what a visitor actually sees. Invisible FAQs, prices that appear nowhere, ratings you invented — all of it either gets ignored or earns a manual action.
One syntax error killing everything
JSON-LD is parsed as a whole. A trailing comma, an unescaped quote inside a string, a smart quote pasted from a document — any one of them invalidates the entire block, including the parts that were fine.
This bites hardest when the JSON is assembled by a template. If you build markup from database fields, escape them properly. In a JavaScript template, JSON.stringify() on each value is the reliable approach; hand-concatenating strings into JSON is how apostrophes in a client's name take down your whole schema.
Describing several entities at once
A page should have one clear primary entity. A page that claims to be an Article, a Product, an FAQPage and a LocalBusiness simultaneously gives a machine nothing to hold onto. Pick the type that matches the page's actual purpose and use @id references to link related entities rather than stacking them.
Forgetting it exists
Markup drifts. Prices change, staff leave, services get retired, and the JSON-LD keeps announcing the old facts long after the visible page was updated. Stale structured data is worse than none, because it is confidently wrong. Put it on the same review cycle as the content it describes.
Validating properly
Two tools, and you want both:
- Google's Rich Results Test tells you whether a page qualifies for a specific rich result. This is the one that answers "will this actually show up".
- Schema Markup Validator (schema.org's own) checks conformance to the vocabulary generally, including types Google does not use.
Test the rendered page, not your template source. If your markup is injected or modified by JavaScript, test the URL rather than pasting code — what ships is what counts.
Then watch Search Console. Its Enhancements reports show errors and warnings across every page it has crawled, which is the only way to catch a template bug that broke markup on four hundred pages at once.
A reasonable baseline
For a typical service business:
- Every page: Organization (or LocalBusiness), and BreadcrumbList below the top level.
- Homepage: WebSite with a SearchAction if you have site search.
- Service pages: Service, plus FAQPage where a visible FAQ exists.
- Blog posts: Article with a proper author object.
- Anything with a listed price: Product and Offer.
That takes a day to implement and covers essentially all the available value. Everything past it is diminishing returns.
What structured data will not do
It is not a ranking factor in the way people hope. Correct markup makes you eligible for richer presentation and makes your content easier for machines to read accurately. It does not push a weak page up the results.
The order of operations matters: get the content right, then describe it accurately. Schema on a thin page just describes a thin page precisely.
If you want your markup reviewed, or built properly as part of a rebuild, tell us what you are working with.
Comments