Structured data describes your page’s content in a machine-readable format. It does not improve rankings directly. What it can do is change how your result appears — star ratings, prices, FAQ expanders, breadcrumbs — and those appearance changes affect click-through rate, which is worth real traffic.
Most schema types produce no visible change at all. Knowing which is which saves a lot of wasted implementation.
Types that produce visible results
Article and NewsArticle. Required for inclusion in certain news and discovery surfaces, and provides the author, publisher and date information that supports expertise signals. Worth adding on every editorial page.
Breadcrumb. Replaces the URL in search results with a readable hierarchy. Cheap to implement, applies site-wide, and improves how results look at essentially no cost.
Product with Offer and AggregateRating. Produces price, availability and star ratings in results. Among the highest-impact markup available for ecommerce, and the one with the strictest requirements.
Review and AggregateRating. Stars in results, where the reviews are genuine and visible on the page. Policies around which page types are eligible have tightened considerably, so check current guidance before investing.
FAQPage. Historically produced expandable questions under a result. Eligibility has been narrowed substantially and now applies mainly to recognised authoritative sites. Still worth including for the semantic clarity, with no expectation of a visual change.
HowTo, Recipe, Event, JobPosting, LocalBusiness, VideoObject. Each produces distinctive results within its domain, and each is only relevant if your content genuinely is that thing.
Types that rarely do anything visible
Organization and WebSite markup are widely recommended and produce little by themselves — the sitelinks search box and knowledge panel associations they once supported are now largely determined by other signals. Add them because they are trivial, not because they will change your result.
Person, WebPage, ImageObject and most of the generic vocabulary fall into the same category: harmless, semantically useful, visually invisible.
The rule of thumb is that if a search feature does not exist for a content type, markup for it will not create one.
JSON-LD, not microdata
Three formats exist. JSON-LD is the recommended one and the right choice in almost every case: it sits in a script tag, separate from the markup, so it can be generated independently of templates and changed without touching the page layout.
Microdata and RDFa embed attributes in the HTML itself, which couples the data to the presentation and makes both harder to maintain. Legacy implementations are fine to leave alone; new work should be JSON-LD.
Implementation that holds up
Four rules prevent most problems.
Mark up what is visible. Structured data must describe content the user can see on the page. Marking up a price that is not shown, or reviews that are not displayed, is a policy violation and a plausible route to a manual action.
Generate it from the same source as the page. Hand-written JSON-LD drifts out of sync the first time someone edits the content. Generate both from the same data.
Include the required properties. Each type has required and recommended fields; missing a required one means the markup is ignored entirely. Validate rather than assuming.
Use one block per page where possible. Multiple scripts are allowed, and a single graph with linked entities is easier to reason about and to debug.
Validating
Two checks, both necessary. A schema validator confirms the syntax and vocabulary are correct. A rich-results test confirms whether the markup is eligible for a specific search feature — the two answer different questions, and passing the first does not imply the second.
After deployment, watch the enhancement reports in search console. They show errors across the whole site rather than one page at a time, which is how you discover that a template change broke markup on four thousand pages.
Mistakes that cause real harm
Marking up content that is not on the page. The most serious one, and the most common. It includes review markup for reviews shown on a different page.
Self-serving reviews. Marking up reviews of your own business on your own site for star ratings is explicitly against guidelines in most cases.
Markup that contradicts the page. A price in markup that differs from the displayed price, or a date in markup that differs from the byline.
Leaving stale markup. Event markup for events that have passed, product markup for discontinued items, FAQ markup for questions removed from the page.
Testing only one page. Templates fail in patterns. Validate a sample across every template type.
Where it fits in a wider programme
Structured data is a modest, reliable improvement rather than a growth lever. The sensible position is to implement the two or three types relevant to your content well, validate them, monitor them, and spend the remaining effort on content and links.
It belongs in the regular technical SEO audit as a check rather than as a project of its own, and it should be part of the template work rather than something added page by page.
Schema for AI and answer engines
A newer argument for structured data is that it helps systems that generate answers rather than lists of links understand your content. The evidence here is thin and the landscape is changing quickly, so it is worth being honest: nobody has reliable public data on how much markup influences these systems.
What is reasonable regardless is that clearly structured content with explicit entities, dates, authors and relationships is easier for any machine consumer to interpret. That argument stood before these systems existed and does not depend on them.
A worked example for an article page
For an editorial site, the useful markup on a typical article is narrower than most implementations assume. Four things carry weight.
The headline and description, matching what is on the page rather than a separately written SEO title.
Author as a linked entity, not a string. An author with a profile page, a described role and relevant credentials provides a connection between the article and a real person, which is what expertise signals rest on.
Publisher, with the organisation’s name and logo, linked to the Organization entity.
Both dates — published and modified — accurate and matching what the page displays. A modified date in markup that does not appear on the page, or that changes without the content changing, is the single most commonly abused property in article markup.
Everything else on an article page is optional, and adding it will not change anything visible.
Maintaining markup over time
Structured data breaks silently. Nothing on the page looks different when the markup stops validating, so it can be broken for months.
Three habits prevent that. Generate markup from the same data that renders the page, so a content change cannot leave the two out of step. Add a validation check to the deployment pipeline for one page per template, which catches template regressions before release. And review the search console enhancement reports monthly, since they are the only view that covers the whole site.
When markup does break, the fix is usually in a template rather than in content, which is a reason to keep it out of the editorial workflow entirely. Markup that writers have to remember to add is markup that will be missing.
Frequently asked questions
Does schema markup improve rankings?
Not directly. It affects how results are displayed, which affects click-through rate, which can affect traffic substantially without changing position.
How long until rich results appear?
From days to several weeks after the page is recrawled. Eligibility is never guaranteed — valid markup makes a rich result possible, not certain.
Can a plugin handle this?
Yes, and most SEO plugins generate reasonable Article, Breadcrumb and Organization markup automatically. Validate what they produce rather than assuming it is correct, and watch for duplicate markup when two plugins both generate it.
Should every page have structured data?
Every page can have Breadcrumb and the appropriate page-type markup. Beyond that, add only types that genuinely describe the content.
