Guide · Website checks
Structured data on your pages
Review structured data against the visible page, choose an appropriate type and check the result without promising AI inclusion.
What it describes
Choose the subject of the actual page before choosing a markup type. A business, an article and a product are not interchangeable descriptions.
Don't add product details to a service page just because another site does.
Structured data is an SEO tool first. Google uses it to understand a page and to show rich results.
Structured data sits beside the visible page rather than replacing it. A visitor never reads it, so it can't make up for anything the page leaves out.
Use the name customers see on the page in the markup too. A trading name on the page and a different registered name in the markup can read as separate businesses.
A service name, a location and an opening time should describe the same offer everywhere they appear. Fix contradictions first.
If a fact is unknown, leave it out. Markup should describe what's established, not fill a gap with a plausible guess.
Write the confirmed facts in a short list before anyone writes code. The developer then copies values from the list, not from memory or an old page.
Choose the most specific type that's true
Schema.org defines LocalBusiness as a physical business or a branch of an organisation. Its examples include a medical practice and a branch of a bank.
Google asks you to use the most specific LocalBusiness subtype that fits, such as Restaurant or HealthClub. A business offering several kinds of service can list more than one type. Specific doesn't mean flattering, so pick the type a customer would recognise from your signage.
For the business as a whole, Google suggests organisation markup on the home page or a single about page. It says that markup doesn't need to sit on every page. Its local business guidance requires an address for each location, so describe each branch separately.
Shops have their own path. Google's product guidance separates product snippets, for pages where people can't buy, from merchant listings, for pages where they can buy from you.
Types also change. Google's documentation changelog records that the FAQ rich result has been retired and its guide removed. Check the current documentation for a type before you add it, rather than an old tutorial.
Use the same facts as the page
Google requires structured data to represent the page content. Keep names, descriptions and other facts in line with what a visitor can read.
Ask your website operator to check existing markup before adding more. Two tools adding data can produce conflicting values.
Note where each value comes from. If the opening hours in the markup are typed in separately from the hours on the page, the two drift apart over time.
Check it after publication
The website owner publishes the change. Use a validation tool, then compare the rendered page with the markup.
A validation result checks a set of rules. It can't tell you every statement is true.
Check the page on a phone as well as a desktop. Some templates load different components on small screens, and the markup can change with them.
Skip the shortcuts
Don't add ratings, reviews or availability you made up. Leave a property out if the business can't support it.
Google says its AI features don't need special AI markup. A valid block can't promise a citation.
Don't mark up a service area wider than the one you serve, or hours you can't staff. A machine-readable claim is still a claim the business has to stand behind.
Take care with reviews and ratings
Review markup carries rules of its own. Read them before you mark up any customer feedback.
Google says a business that controls the reviews about itself can't get star ratings on pages that use LocalBusiness or another organisation type. That includes reviews on its own site shown through an embedded widget.
Its local business guidance recommends aggregate rating markup only for sites that collect reviews about other businesses.
Google also rules out fake reviews and undisclosed paid-for reviews, on the page and in the markup. Keep genuine customer feedback on the page if you wish, but don't add rating markup the guidelines exclude.
Google says a structured data issue can lead to a manual action, which removes a page's eligibility for rich results. The Manual Actions report in Search Console shows whether one applies.
Fill fewer properties, and fill them well
Google says it's more important to supply fewer complete and accurate properties than every possible property with weak data. That suits a small team with little time.
Start with the facts the business confirms and checks often. Name, address, phone number, opening hours and website address are the usual core.
Leave a property out rather than filling it with a placeholder. A dummy phone number or a sample price is worse than no value at all.
Schema.org also defines properties such as areaServed, for the area a service covers, and specialOpeningHoursSpecification, for special opening hours. Use them only when the visible page states the same thing.
Google's guidelines ask for up-to-date information and complete items. If a page shows several reviews, for example, marking up only the best ones misrepresents the page.
Pick a format, and check what scripts add
Google accepts JSON-LD, Microdata and RDFa. It recommends the format that's easiest for you to maintain, which in most cases it says is JSON-LD.
Markup doesn't always sit in the page source. Plugins, themes, widgets and tag managers can insert it when the page loads.
Google says it can read structured data that JavaScript adds to a page. It warns that copying details into a tag manager raises the risk of a mismatch with the page content.
Its guidance suggests using variables that read the details from the page instead. The markup then changes when the visible text changes.
Test injected markup with a tool that renders the page. Viewing the raw source alone can miss it, or show markup that a later script replaces.
When a page describes more than one thing, such as a business and an event it runs, Google describes two approaches. Nest the items under one main item, or keep them separate and link them with an identifier.
Two components can describe the same business with different details. Find where each description comes from before you add or remove anything.
Record the responsible person and where it's implemented, so a later correction doesn't mean guessing which component owns it.
Where two components output markup, choose one to own each fact. Switch the other off for that fact, rather than trying to keep two copies in step.
Validate the syntax, then check the meaning
A validator can find missing fields and broken syntax. It doesn't know if a business fact is true.
Compare every field with the visible page and your confirmed record. Check the type, the address, the service details and any conditions.
Google's structured data policies call for relevant, representative information. Passing a technical check doesn't make you eligible for every feature.
Read the markup with the owner of the facts, not only the developer. The developer knows the code, and the owner knows whether the hours are right.
Test before launch, then keep checking
Google's Rich Results Test accepts a live address or a pasted code snippet. The code option lets you check a draft before anyone publishes it.
For an address test, every page resource must be reachable by an anonymous visitor. A page behind a password or a firewall can't be tested that way.
Google's guidelines also say not to block pages with structured data from Googlebot, whether through robots.txt, noindex or another access control. Images named in the markup need to be crawlable too.
The test covers the types Google supports for rich results. A pass says the code meets those technical rules, not that the facts in it are right.
Google also advises checking the rich result reports in Search Console after launch, because markup can break through templating or serving issues.
Those reports show a sample of detected items, not a full list. Google points to the URL Inspection tool for a page the report doesn't show.
Its local business guidance adds that it may take several days after publishing for Google to find and crawl a page. Judge the reports after that, not on the day.
Keep the markup in step with the business
Markup goes stale the same way pages do. A new phone number, a changed service area or a closed branch has to reach the markup as well as the text.
Add the markup to your list of places where each fact lives. When a fact changes, the same owner checks the visible page and the machine-readable copy together.
Google's organisation guidance describes sameAs for pointing to your profiles on other websites, such as social media or review sites. List only profiles the business runs, and remove any that close.
Plan a check after any theme, plugin or platform update. Updates can add, remove or duplicate markup without anyone touching the content.
After the owner publishes, inspect the public output again.
Keep a record of what changed. A later AI citation needs its own evidence, and a markup check isn't it.
When a service ends, take it out of the markup the same day. Old markup can go on describing an offer the page no longer makes.
A worked example
A business page lists its current opening hours.
| Detail | Observation | Review or next step |
|---|---|---|
| Visible page | Saturday appointments are available. | Confirm the exact hours with the owner. |
| Markup | A theme still outputs the previous hours. | Update the source and inspect the public output. |
Syntax can be valid and still carry a wrong fact, so check the meaning as well as the code.
Common questions
Is valid markup enough?
No. Valid syntax doesn't confirm the facts. Compare the values with the visible page and the owner's record, and check the public output again after publishing.
Should I add more markup types to be more visible?
Use a type only when it describes the page accurately and meets its requirements. Nothing here suggests more types lead to more AI mentions. Keep the description relevant and easy to maintain.
Is valid markup enough?
No. Valid syntax doesn't confirm the facts. Compare the values with the visible page and the owner's record, and check the public output again after publishing.
Should I add more markup types to be more visible?
Use a type only when it describes the page accurately and meets its requirements. Nothing here suggests more types lead to more AI mentions. Keep the description relevant and easy to maintain.
Check your understanding
What should a page label describe?
Read the answer and explanation
- A claim copied from another business.
- The information visible on the page.
- A result you hope to receive.
Answer. The information visible on the page.
Check labels against the facts visible on the page. Valid labels don't ensure an AI recommendation.
Answer and explanation
The information visible on the page.
Check labels against the facts visible on the page. Valid labels don't ensure an AI recommendation.
Your next steps
Sources and method
A Carqo review method. Provider statements link to the relevant documentation.
- Google introduction to structured data Link checked 4 November 2026
- Google structured data policies Link checked 4 November 2026
- Google guidance on AI features Link checked 4 November 2026
- Schema.org definition of LocalBusiness Link checked 29 October 2026
- Google Search Central, local business structured data Link checked 29 October 2026
- Google guidance on organisation structured data Link checked 29 October 2026
- Google product data guidance Link checked 4 November 2026
- Google Search Central documentation changelog Link checked 29 October 2026
- Google guidance on review snippet structured data Link checked 29 October 2026
- Google guidance on generating structured data with JavaScript Link checked 29 October 2026
- Google Search Console help on the Rich Results Test Link checked 29 October 2026
- Google Search Console help on rich result reports Link checked 29 October 2026