Structured data is machine-readable code that states what a page is about in a fixed vocabulary. For answer engines it removes guesswork, confirming facts that would otherwise have to be inferred from the wording of the page.
Short answer
Structured data is code added to a page that names its subject in a shared vocabulary, so a machine does not have to infer it from the wording. For most business sites the useful types are the organization, the local business, the services offered, questions and answers, and any step-by-step instructions. Markup must match what visitors actually see.
Markup states facts in a form that needs no interpretation. Your business name, where you work, what you sell, who wrote the page, when it was updated. A parser reading the code does not have to guess at any of it.
What it does not do is make a page eligible for anything by itself. It describes; it does not promote. A thin page with excellent markup is still a thin page, and no vocabulary in the world fixes that.
It also does not override the visible page. Where the code and the content disagree, the disagreement itself is the signal, and it is not a good one. Our page on schema markup covers the basics in more depth.
Most small business sites need a small set and nothing more. Start with the type that describes the business itself, add the pages that describe what you sell, and add question markup only where a real question and answer set exists.
Resist the temptation to mark up everything. Each type you add is something to maintain, and stale markup is worse than absent markup because it states something false in a format that is designed to be trusted.
Prose can hedge. Markup cannot. A field either holds a value or it does not, and whatever it holds is read as a definite statement about your business rather than as a claim you are making in passing.
That is why review markup causes the most trouble. Marking up ratings that are not shown, or that are not real, is a policy violation and a legal risk. Our page on testimonials and reviews covers the rules.
Address and hours run a close second. Markup that says you open at a time you do not open will be repeated confidently by systems that have no way to know better, and the person turning up at a locked door blames you.
The safest arrangement is for the markup to be generated from the same source as the visible content, so the two cannot drift apart. Hand-written code pasted into a template is the usual origin of a mismatch.
If the code is maintained by hand, tie it to the same review cycle as the page. Anything that changes on screen has to change in the code in the same edit, without exception, or the mismatch will eventually appear.
Check it after any redesign. A template change that moves content around frequently leaves markup describing a page that no longer exists in that shape, and nothing at all will warn you that it happened.
Validators confirm the syntax is correct and the required fields are present. They cannot confirm the values are true, which is the part that actually matters, so passing validation is a floor rather than a finish line.
Read the output as a person as well. Take the values, write them out as sentences, and ask whether you would be comfortable seeing them quoted in an answer about your business. That question catches what a validator cannot.
Then confirm the page itself still reads well. Markup sits underneath the content and changes nothing a visitor sees, so a page that gained markup and lost clarity has moved backward overall.
Do not mark up content that is not visible. Hidden question sets, invisible reviews and ratings that appear nowhere on the page are all forms of describing a page that does not exist for a visitor.
Do not mark up an instruction set that is really a sales page, or a question set assembled to look like one. Systems read a great many of these and the pattern is not subtle to anyone looking for it.
And do not invent a vocabulary. If nothing in the shared vocabulary fits your case, the answer is clearer prose rather than a field used to mean something it was never defined to mean.
Below structure and above almost everything else. Headings in order, a definition near the top and reachable pages come first. Markup is the next layer, and it is genuinely worth the afternoon it takes on a small site.
It pairs naturally with the writing work. A page with an answer block and matching markup states the same fact twice, once for people and once for machines, with no contradiction between the two of them.
The page on generative engine optimization sets out the whole order, so you can see what should already be done before any code is added to a template.
They read the page, and structured data is part of the page. It removes guesswork about facts such as who you are, what you sell and when the page was reviewed. It does not by itself cause a page to be cited.
The script-based format placed in the page is the most widely supported and the easiest to maintain, because it sits in one block rather than being scattered through the markup. Most modern site tools generate it for you.
Yes. Markup that contradicts the visible page, or that describes content a visitor cannot see, is a policy problem and can lead to features being withdrawn. It also risks systems repeating something untrue about your business.
Only where the reviews are genuine, collected properly and shown on the page being marked up. Marking up ratings that are invented, borrowed or hidden is both a policy violation and a consumer protection risk. Nothing here is legal advice.
15-day free trial. Card required. Cancel before day 15 and you pay nothing.