Structured data has a reputation problem: years of being sold as a route to rich results made it sound like a formatting trick. Its actual function is duller and more durable. It states, unambiguously, what a page is and who made it, at a moment when a great deal of software is trying to work that out from prose.
The six that matter
| TYPE | REMOVES THE QUESTION | WHERE IT GOES |
|---|---|---|
| Organization | Who is this, and is it the same entity as the one mentioned elsewhere? | Once, sitewide, with a stable @id |
| Article | When was this written, by whom, and has it been updated? | Every editorial page |
| FAQPage | Which parts of this page are questions and answers? | Any page with a real Q&A block |
| DefinedTerm | Is this a definition, and of what? | Glossary entries, in a DefinedTermSet |
| HowTo | Is this a procedure, and what are the steps? | Genuine step-by-step pages only |
| BreadcrumbList | Where does this sit in the site’s structure? | Every page below the root |
Two more are worth adding when they apply honestly: Product for anything sold, and Person for authors who exist as entities elsewhere. Beyond that the returns fall off quickly and the maintenance burden does not.
The @id discipline
The single highest-value practice in structured data is giving your organisation one stable @id and referencing it from every other node instead of repeating the details. It converts a set of independent pages into a connected graph, which is what allows a system to conclude that the studio in the Article node and the publisher in the DefinedTermSet are the same organisation.
Repeating an organisation’s name and address inline on forty pages does not achieve this. It produces forty organisations that look similar.
Author is not optional any more
An Article node with no author is a page nobody is responsible for. Systems that weight source credibility have no way to attach anything to it, and the trend in every published guideline is towards weighting responsibility more heavily every year.
A real name, a page for that person on your own site, and consistent use across everything they wrote. If the work is collective, say so with an organisation as the author. An invented byline is the one thing here that will get you caught.
The three mistakes that make markup harmful
- Marking up content that is not on the page. An FAQPage node describing questions no visitor can see is the fastest way to lose the credibility the markup was meant to establish, and it is detectable.
- Dates that lie. A modified date that updates on every deploy tells a system the page changed when it did not, and once that signal is noise it is worthless in both directions.
- HowTo on anything that is not a procedure. Steps that are a list of considerations misrepresent the page, and the misrepresentation is the thing being indexed.
Generate it from the data
Hand-written JSON-LD in a template is a promise that somebody will remember to update it. They will not. The correct architecture is to render the schema from the same objects that render the content: the FAQ block on the page and the FAQPage node come from one array, the visible published date and the datePublished come from one field.
This is the only way the markup stays true through two years of edits, and untrue markup is a liability with a schema wrapper on it.
What schema will not do
- It will not make a thin page rank or get quoted. It removes ambiguity about content that exists; it does not create content.
- It will not force a rich result. Eligibility is not entitlement, and it has not been for years.
- It will not substitute for a clear first paragraph. A model quoting your page quotes the prose.
- It will not fix inconsistent naming elsewhere. If your organisation is described three different ways across the site, the graph inherits the confusion.
Schema tells a system what a passage is. This is how to write a passage worth lifting.
WRITING THE PARAGRAPH ITSELF →