Structured data won't rank you higher, but it decides how you look when you do

Background

Structured data gets sold as an SEO ranking trick, and that's the wrong frame entirely - it isn't one, and Google has said as much directly. What it actually does is tell a search engine unambiguously what's on the page, rather than leaving it to infer from headings and paragraph text. Get it right and a search result can show star ratings, a price, an event date, or an expandable FAQ, right there on the results page before anyone's clicked anything. Two pages ranking in the same position, one plain, one with that extra detail attached, don't get the same number of clicks.

Setup

Choosing the right type

Pick the type that actually matches the page, not the type that sounds most impressive:

• A blog post or guide is Article or TechArticle.
• A product page is Product, with Offer for price and availability.
• A local clinic, shop or practice is LocalBusiness (or a more specific subtype where one exists, like MedicalBusiness).
• A page with genuine question-and-answer content is FAQPage.
• A list of events is Event, one block per event, not one block trying to describe several.

The wrong type applied for the sake of having something gets ignored at best and can read as manipulative at worst - Google's own documentation is explicit that markup has to reflect the page's actual primary content, not whatever type happens to unlock the most attractive rich result.

Writing it safely

Two rules that matter more than the schema vocabulary itself:

• Only mark up what's genuinely visible on the page. A Review schema block claiming a rating that doesn't appear anywhere a visitor can see is exactly what Google's structured data guidelines exist to catch, and it's a real risk to the whole domain's trust, not just that one page - never describe something in JSON-LD that isn't actually there in the rendered content.
• Use JSON-LD, not microdata sprinkled through the HTML. A single <script type="application/ld+json"> block is far easier to keep correct as the page changes than attributes scattered across a dozen tags that all need updating in sync.
• Encode it safely. A JSON-LD block built by concatenating raw content into a script tag is a script-injection risk the moment that content contains something like </script> - escape it properly (most templating engines have a JSON-safe escaping mode for exactly this) rather than string-building it by hand.

Testing before you trust it

• Test against the actual rendered page, not just the source you wrote. Google's Rich Results Test shows what it can parse from the live URL, which catches the case where the markup's correct but sits on a page that never actually renders the content it describes.
• Check the specific rich result type you're aiming for is actually supported for that page type. Not every schema type Google understands also has a corresponding visible rich result - some markup is used for general understanding of the page without ever producing a special display, which is fine, but worth knowing before promising a stakeholder a star rating will appear.
• Re-test after a template change, not just when the markup itself changes. A shared layout change that alters how a page renders can break the connection between what the schema claims and what the page actually shows, even if the JSON-LD block itself was never touched.

A worked example

A real one, for a guide page like this one - every field here matches what's actually printed on the page, nothing invented for the sake of filling the schema out:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Structured data won't rank you higher, but it decides how you look when you do",
  "description": "Schema markup doesn't move you up the results page. It's the difference between a plain blue link and a result with stars, a price, or a FAQ dropdown attached to it.",
  "datePublished": "2026-09-16",
  "author": { "@type": "Person", "name": "Michael Shreeves" }
}

Nothing about ratings, prices or availability, because none of that exists on the page - a TechArticle only claims what a guide page actually is.

Keeping it in sync as the page changes

Structured data isn't a one-time task once the block's written:

• Generate it from the same source the page renders from, not as a separately hand-maintained block. A Product price that's templated from the same variable the visible price uses can't drift; one typed in by hand as a "one-off addition" will, the first time the price changes and someone forgets there were two places to update.
• Add it to whatever checklist covers a template change. If a page layout is being redesigned, the structured data that describes it needs the same review, not a silent assumption that it'll keep working because nobody touched the JSON-LD block directly.