Structured data: what a business website actually needs
Structured data is not a ranking factor. It is a translation: it tells machines what a passage means instead of leaving them to guess. That is increasingly what decides whether a page appears in answers at all.
In short
- Four types are enough for almost any business site: Organization, WebPage or Article, BreadcrumbList and FAQPage.
- Deliver it as JSON-LD in the
<head>— not as markup woven through the body text. - The most common mistake is silent and expensive: details in the structured data that do not appear on the page itself.
- Three much-discussed types can be skipped by a service business — they only work with a matching offering or genuine reviews.
A machine reading a page initially sees only text. That "Emma Woelk" is a person, "TEISENDA GmbH" a company and "22 August 2026" a publication date has to be guessed — or stated explicitly.
Structured data is that explicit statement. It does not improve a position. It decides whether a page is eligible for enhanced presentation and for generated answers at all.
The four that are enough
1. Organization – once, on the home page
Who you are: name, address, logo, founding year, profiles elsewhere. This is the entry that makes a logo next to your search result possible — and the most common reason one is missing is simply that this entry does not exist.
Important: the logo has to be a raster image. An SVG is not evaluated here.
2. WebPage or Article – on every page
What this page is: title, description, language, publication date and last revision. On articles, additionally Article or BlogPosting with the author as a separate Person entry — with a role, not just a name.
Important: the revision date has to be true. A date reset on every page build is a signal that invalidates itself.
3. BreadcrumbList – on all subpages
Where this page sits in the structure. Visible as a path at the top of the page, machine-readable in the head. Both belong together — a path in the data that does not exist on the page is a false statement.
4. FAQPage – wherever there are real questions
The questions section at the end of an article. For answer engines the most valuable type of all, because it delivers question and answer already paired — exactly the form in which quoting happens.
Important: only for questions actually visible on the page. Invented questions that exist only in the data breach the guidelines.
Three you can skip
Product and Offer. For services quoted on request they bring nothing — without a price and availability they will not be surfaced anyway. Worth it only with a real shop.
AggregateRating. Stars in the search result are tempting and tied to strict conditions: the reviews have to be genuine, verifiable and visible on the page. Self-awarded ratings are a guideline breach with real risk.
HowTo. Its presentation has been substantially scaled back, and it no longer justifies the upkeep for most business sites.
Worth knowing
Structured data is not a ranking factor — Google has said so repeatedly. It decides presentation, not position.
For answer engines the case is slightly different. A model building an answer from a page prefers what is unambiguously marked up: question-answer pairs, author with role, date of last review. It then does not have to guess what belongs together. The benefit therefore lies less in ranking than in quotability.
How to implement it
Three rules that avoid most problems.
- JSON-LD, in the
<head>. Not as attributes in the body text. JSON-LD can be maintained separately from the layout and does not get lost when the design changes. - One block per page, not five. Multiple entries belong in a
@graphand are linked via@id. That way the article refers to the same organisation as the home page instead of repeating it. - Generate it from the same source as the visible content. If title, date and author come from the same fields as the page itself, they cannot drift apart. That is the single most effective preventive measure there is.
The most expensive mistake is the quietest: the structured data says something the page does not. A revision date of yesterday on a text from 2023. An author who appears nowhere in the visible area. Questions in the data that do not exist on the page.
No validation tool catches this — the data is formally valid. It gets caught in a manual review, and then the consequence is not limited to the offending markup. That is why the rule "generate from the same source" matters more than any completeness.
Checking — in this order
| Step | With | What you see |
|---|---|---|
| 1. Syntax | Schema Markup Validator | whether the JSON is valid and the type correct |
| 2. Eligibility | Rich Results Test | whether enhanced presentation would be possible |
| 3. Reality | Search Console, Enhancements | what was actually recognised, across all pages |
| 4. Agreement | read it yourself | whether every detail also appears visibly on the page |
Step four is the only one no tool performs — and the only one where the serious mistakes surface.
Check this page's structured data for completeness and for agreement with the visible content. Visible page content: [paste the page text] The page's JSON-LD: [paste the block] Tasks: 1. Name every detail in the JSON-LD that does not appear in the visible content. This is the most important point – be thorough here. 2. Name every visible detail that should be marked up but is missing (author with role, revision date, questions, path). 3. Check whether the four basic types are sensibly covered: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Name types in the block that bring no benefit to a service business with no shop and no verifiable reviews. 5. Point out every guideline breach, particularly self-awarded ratings and questions that do not exist on the page. Output the corrected JSON-LD in full at the end. Do not invent values – mark anything missing as [to be added].
In closing
Structured data is quickly overrated and just as quickly done wrong. Four types cover a business site's needs, and their benefit lies less in position than in being quotable.
The one rule that carries everything: mark up nothing that is not on the page. Generate the data from the same source as the visible content and you have solved that structurally — and can largely skip the follow-up checks.
Common questions
What structured data does a business website need?
Four types are enough: Organization once on the home page, WebPage or Article on every page, BreadcrumbList on all subpages, and FAQPage wherever there are real, visible questions. Product, AggregateRating and HowTo generally do not pay off for service businesses.
Does structured data improve rankings?
No. It is not a ranking factor; it decides presentation — whether a logo, a path or expandable questions can appear in the search result. For answer engines it raises quotability, because question-answer pairs, author and date are unambiguously marked up rather than having to be guessed.
Why does Google not show our logo?
The most common reason is a missing or incomplete Organization entry on the home page. The second most common: the logo exists only as an SVG — a raster image is required here. Even with correct markup there is no entitlement to display.
What is the most common mistake with structured data?
Details that appear in the data but not in the visible content: a wrong revision date, an unnamed author, invented questions. Validation tools do not flag this because the data is formally valid. It is avoided by generating the markup from the same source as the visible text.
JSON-LD or microdata?
JSON-LD in the <head>. It is Google's recommended form, can be maintained separately from the layout, and survives design changes. Microdata spreads the markup through the body text and breaks whenever the page is rebuilt.
Marketing that sets itself up
The Studio Engine beta is live. Claim your spot and help shape it from the start.
Join the beta →