Structured data is a description of a page written for machines. Done well, it removes ambiguity: which firm this is, what the page offers, who wrote it, when it changed.
Done badly — which is most common — it introduces contradictions. The classic example is a theme that ships with an address from the theme author's demo site, left in place for years.
Start here, ignore the rest
Organization
Your firm as an entity: name, URL, contact, logo, profiles. One per site, referenced by @id everywhere else.
Service
What a service page offers, who provides it and where. Pairs naturally with a commercial page.
FAQPage
Only where the questions and answers are visible on the page. Must match visible text word for word.
Article / BlogPosting
Headline, author, dates, image. The dates matter: they are how a system knows the page is current.
BreadcrumbList
The page's position in the site. Cheap, and it mirrors navigation you already have.
A foreign address
Template residue from a demo or a previous business. It tells search engines your firm is somewhere it is not, and contradicts your contact page.
Two article entities on one page
An Article node without dates plus a BlogPosting node with dates. The system has to choose; it may choose the weaker one.
FAQ markup without visible FAQs
Content in schema that a user cannot see is a policy violation, not an optimisation.
Review and rating markup without reviews
Fabricated ratings are the fastest route to a manual action. If you have no published reviews, omit the property.
The pattern we use
One entity, referenced by @id from every other page. No address unless it is your verified address. No employee entries you cannot evidence.
| Property | Why it matters |
|---|---|
| @id | Lets every other page point at the same entity instead of redefining it |
| name / url / logo | Basic identity — logo should be a real logo file, not a favicon |
| email / telephone | Must match the contact page exactly |
| sameAs | Links to profiles that confirm the entity exists elsewhere |
| founder / employee | Only people you can evidence on the site |
Omit any property you cannot substantiate. An absent property is harmless; a wrong one is not.
Before you ship
Syntax
The JSON must parse. A broken block fails silently — the page looks fine and the markup does nothing.
Schema validator
validator.schema.org for structural correctness and warnings.
Rich Results Test
Confirms which Google features the page is eligible for. Not every type produces a rich result, and that is normal.
Visible-content check
Read the schema and the page side by side. Every fact in the markup must appear on the page.
It will not create rankings that content does not earn, will not produce a rich result for every type, and will not fix a site that search engines cannot crawl.
It is an accuracy tool. Treat it that way and it is genuinely useful; treat it as a ranking lever and you will be disappointed.
Placement and scope
| Where | What belongs there |
|---|---|
| Every page (head) | Nothing page-specific. Reference the Organization by @id from the page-level node instead. |
| Homepage | The Organization entity, the WebSite entity, and the WebPage node that ties them together. |
| Service page | A Service node, provider referenced by @id, plus BreadcrumbList. |
| Article page | One BlogPosting node with headline, author, dates and image. One, not two. |
| Any page with visible Q&A | FAQPage, mirroring the visible questions verbatim. |
Sitewide duplication of the full Organization node on every page is a common cause of conflicting entity data.
A practical rule: if a fact appears in the markup but nowhere on the page, remove it from the markup. Structured data describes a page; it does not add claims to it.