Start with the page’s real job, not a schema checklist
Structured data is code that labels information on a page in a standard format. It can help a search system identify a product, business, article, profile, breadcrumb path or another supported item.
That definition is simple. The buying decision is not.
Before anyone writes code, answer four questions:
- What useful job does this page do for a person?
- Which fact on the page needs a machine-readable description?
- Which documented system or search feature can use that description?
- Who will update the markup when the fact changes?
If one answer is missing, do not start with implementation. A tool that reports “missing schema” has not established that the page is missing a useful feature.
Use this first-pass test:
| Page state | Decision |
|---|---|
| The page has no clear purpose or useful visible content | Fix the page before adding markup |
| The fact exists but is not visible to users | Publish and verify the fact first, or do not mark it up |
| Schema.org defines a type but no useful consumer has been named | Hold; vocabulary availability is not a business case |
| A current feature guide matches the page and its visible facts | Evaluate the required fields and maintenance cost |
| Existing markup is accurate, supported and maintained | Keep and monitor it |
Google’s introduction to structured data describes it as a standardized way to classify page content. It also says the markup belongs on the page it describes. That is the right starting point: the page and the fact come first.
Structured data describes visible facts. It cannot create them.
Markup is a label, not evidence that the label is true.
LocalBusiness code cannot create a staffed location. Review code cannot turn ratings copied from another site into first-party reviews. Product code cannot make an unavailable item purchasable. Person code cannot create a qualification the person does not hold.
Google’s general structured-data guidelines require the marked information to be relevant, representative and current. The visible page and the code should tell the same story.
Check a proposed fact in this order:
- Visible: Can a visitor find the fact on the page?
- Specific: Does it describe this page rather than the site in general?
- True: Can the business owner confirm it from an operating source?
- Current: Will someone change the markup when the fact changes?
- Useful: Does a documented consumer or supported feature use it?
This prevents common errors. A price changes in the catalog but not in the JSON-LD. An attorney leaves the firm but remains in an author node. A clinic changes its hours but one template still shows the old schedule. A contractor adds a virtual office to markup even though customers cannot visit it.
The safest markup is not the graph with the most properties. It is the smallest complete description someone can keep accurate.
If the business name, people, locations or offers already conflict across public records, reconcile those facts with the entity foundations guide before marking them up.
Separate the vocabulary from Google feature eligibility
Schema.org and Google Search answer different questions.
- Schema.org provides a broad shared vocabulary for describing things and relationships.
- Google Search Central documents the structured-data types and properties used for current Google Search features.
- A valid graph means a validator can parse the vocabulary and structure.
- An eligible item means the page also meets the current feature requirements and policies.
- A shown result means Google chose to display an eligible feature for that search.
Those states are not interchangeable.
| State | What it establishes | What it does not establish |
|---|---|---|
| Schema.org-valid | The vocabulary and graph can be parsed | Google supports a special result for it |
| Google-test eligible | Required fields for a supported feature are present | Google will show the feature |
| Rich result shown | The feature appeared for a dated search | It caused a click, call or sale |
| Click recorded | Someone visited the site | The visitor was qualified or converted |
| Conversion recorded | A site action occurred | The structured data caused it |
Google’s current supported-feature gallery is the feature inventory to use for Google—not a list produced by a plugin. Google also states that correct markup does not guarantee a rich result.
Google also says structured data is not required for generative AI search and that there is no special Schema.org markup to add for it. Treat an “AI schema” offer like any other claim: ask which documented consumer uses it and which visible page fact it describes.
This distinction matters when a result type is retired. The vocabulary may remain valid while the Google presentation disappears. Use the FAQ rich-results decision guide for that exact case rather than treating every valid type as an active Google feature.
Match the page type to the buyer action
Choose markup from the main job of the page, not from every noun it contains.
| Page’s real job | Type to evaluate | First fact to verify | Buyer action affected |
|---|---|---|---|
| Explain the company | Organization or a more specific subtype | public name, URL and contact facts | trust and contact |
| Represent a customer-facing location | LocalBusiness subtype | real address, hours and location identity | call, visit or booking |
| Sell or describe a specific product | Product, ProductGroup and relevant offer data | purchasable item, variant, price and availability | order |
| Focus on one affiliated person | ProfilePage with Person where the use case fits | identity and visible role | trust or enquiry |
| Show the page’s place in site navigation | BreadcrumbList | real hierarchy | navigation |
| Describe a downloadable or web application | SoftwareApplication only when the page qualifies | application and offer facts | trial or evaluation |
Google’s Organization guidance says organization markup normally belongs on the homepage or one organization page. Repeating a full organization block on every URL does not give each page a clearer job.
The same restraint applies elsewhere:
- Use LocalBusiness guidance for a real location, not a city keyword target.
- Use ProfilePage guidance when one affiliated person or organization is the page’s primary focus.
- Use SoftwareApplication guidance for a qualifying application page, not every SaaS marketing page.
- Use breadcrumb guidance to describe navigation, not to insert extra keywords.
The type should make the page easier to classify. It should not change what the page pretends to be.
Change the decision for each of the five industries
The test stays the same. The facts, page types and buyer actions change.
| Industry | Page and markup worth evaluating | Shortcut to reject | Outcome to keep separate |
|---|---|---|---|
| Home Services | A real location page with a valid LocalBusiness subtype, hours and customer contact facts | Marking every target city as a business location or adding copied review stars | qualified calls and booked work |
| Legal | An attorney profile whose visible role supports ProfilePage, plus accurate organization and breadcrumb facts | Invented credentials, hidden disclaimers or ratings copied from directories | appropriate prospective-client enquiries |
| Healthcare | A real clinic or practitioner page with accurate provider, location and appointment facts | Treating markup as a substitute for clinical, privacy or advertising review | appropriate appointment requests |
| B2B SaaS | A qualifying application page with visible application and offer facts | Applying SoftwareApplication to every use-case, comparison or homepage URL | demos, trials and qualified pipeline |
| eCommerce | A purchasable product/variant page whose visible price and availability agree with the feed | One generic Product item for several variants or stale price and stock | completed and supportable orders |
The ecommerce case deserves special care. Google’s Product guidance separates product snippets from merchant listings and explains how on-page data can work with Merchant Center. A feed and structured data are complementary sources. Neither guarantees a shopping placement. Use the semantic product architecture guide when the problem is the relationship between categories, products and variants rather than the markup decision alone.
Reviews need the same restraint. Google’s review-snippet guidance requires visible review content and restricts self-serving stars for Organization and LocalBusiness. Copying a rating from another platform into your markup is not a shortcut.
Regulated facts still need the responsible professional or operating owner. Code does not approve a legal claim, medical statement, financing term, security promise or return policy.
Build the smallest accurate graph you can maintain
Google supports JSON-LD, Microdata and RDFa for structured data unless a feature guide says otherwise. Google generally recommends JSON-LD because it is easier to implement and maintain.
The format is less important than the source of truth.
| Fact | Better source | Maintenance question |
|---|---|---|
| Organization name and logo | governed organization record | Who approves a rebrand? |
| Location address and hours | location operating record | Who updates holidays, moves and closures? |
| Product price and availability | catalog or commerce platform | Does rendered markup update with the purchasable variant? |
| Person role and credentials | approved profile record | What happens when the role changes? |
| Breadcrumb path | page hierarchy | Does the trail match the navigation users can follow? |
Use one stable @id when several nodes refer to the same thing. Do not create slightly different versions of the organization, person or product because several plugins emit their own blocks.
Dynamic generation can work, but it needs a rendered-page check. Google’s JavaScript structured-data guidance warns against duplicating changing values in a tag manager and notes extra risk for fast-changing product price and availability.
For ecommerce, compare the selected variant on the page, the rendered JSON-LD and the merchant feed. For local businesses, compare the visible location page, the profile and the markup. For people, compare the profile copy, role and current organization relationship.
If the team cannot name the source and owner, adding more properties creates more ways for the site to become wrong.
Run four different checks before release
One green check is not enough because the tools answer different questions.
| Check | Tool or review | Finds | Can still miss |
|---|---|---|---|
| Vocabulary and graph | Schema.org Validator | parsing, type and property structure | Google feature rules and business truth |
| Google feature eligibility | Rich Results Test | required and recommended fields for supported features | unsupported types, policy context and guaranteed display |
| Rendered and indexed output | URL Inspection and rendered HTML | whether Google can see the released markup | whether the visible fact is accurate |
| Fact and policy review | a person who owns the page fact | false, hidden, stale or misleading claims | future template or platform changes |
Use this order:
- Inspect the visible page and name the fact owner.
- Validate the graph and vocabulary.
- Test the current Google feature when one applies.
- Inspect the live rendered output rather than only the source template.
- Confirm crawl and index access on a representative URL.
- Re-read the current feature-specific policy.
A validator cannot know that the office is unstaffed, the product is unavailable or the person left the company. A passing test proves a narrow technical state. It does not approve the business claim.
Deploy a sample and measure without pretending one change caused everything
Do not release a new template to every page first.
Choose a small representative set: one service page, location page, profile, product or article for each template affected. Capture the page, current rendered markup, validation state and recent Search Console baseline. Then release the change and inspect the live and indexed result.
Keep the observations separate:
| Layer | What to record | Safe conclusion |
|---|---|---|
| Deployment | valid and invalid items | the code reached the intended pages |
| Eligibility | Rich Results Test and status report | the item currently meets the tested feature fields |
| Appearance | dated Search Console search appearance where available | Google reported that appearance for that page/date |
| Behavior | impressions and clicks | search exposure or visits changed |
| Business result | qualified calls, appointments, enquiries, demos or orders | a business action changed; causation still needs evidence |
Google’s introduction recommends testing stable pages and comparing performance over time. That still does not isolate the structured-data change from seasonality, content edits, releases, demand or ranking changes.
Mindflow’s conversion and measurement service owns the broader work of connecting visits and actions to qualified calls, appointments, enquiries, demos and orders.
Define the rollback condition before release. Examples include markup missing from the rendered page, wrong variants, invalid required fields, a shared template affecting unrelated URLs or a visible fact falling out of agreement.
Maintain markup when facts, templates and platforms change
Structured data is not a one-time installation.
Review it when:
- a business moves, rebrands or changes contact details;
- a person joins, leaves or changes role;
- product price, stock, variants, shipping or returns change;
- a CMS, theme, plugin or component is replaced;
- Google changes a feature guide or retires a result type;
- Search Console reports a new rise in invalid items;
- the visible page changes but the markup generator does not.
Assign two owners: one for the underlying business fact and one for the template or data connection. The technical owner cannot approve an operational fact. The operational owner may not know how the site emits it. Both are needed.
Removal can be the right maintenance decision. Retired feature code, an unknown plugin output or a large graph without a named consumer can create work without serving the page. Do not remove accurate code blindly, but do not keep it forever because a validator still recognizes the vocabulary.
Google changes supported appearances over time. Check the current feature guide before a consequential release, not an old audit screenshot.
Decide: add, fix, keep, monitor or remove
Use one admission record for every proposed type or shared template.
| Field | Record |
|---|---|
| Page job | The useful decision or action the page supports |
| Visible fact | The exact fact being described |
| Fact owner | The person who can confirm and update it |
| Type and properties | The smallest accurate Schema.org description |
| Named consumer | Current Google feature or other documented system |
| Validation | vocabulary, feature, rendered and policy results |
| Update trigger | the event that can make the markup stale |
| Technical owner | the person responsible for the implementation |
| Final ruling | add, fix, keep, monitor or remove |
Add when a real page and visible fact match a useful documented consumer. Fix when the purpose is sound but the fact, graph or output is wrong. Keep when the markup is accurate, used and maintained. Monitor when it is valid but the benefit or dependency remains uncertain. Remove when it is false, obsolete, duplicated or has no defensible consumer and no maintenance owner.
Mindflow can review a limited public sample from the visible page through the rendered markup and current feature requirements. Bring one public URL, the markup or warning you were given and the buyer action the page is meant to support to the Free Visibility Check.
The check does not implement markup, validate an entire site, restore a rich result, improve rankings or create an AI citation. If the problem is broader than structured data, use the technical SEO decision guide or review Mindflow’s Organic SEO service.
Primary sources
- Google Search Central: Introduction to structured data
- Google Search Central: General structured-data guidelines
- Google Search Central: Supported structured-data gallery
- Google Search Central: Organization structured data
- Google Search Central: LocalBusiness structured data
- Google Search Central: Product structured data
- Google Search Central: Review snippets
- Google Search Central: Generative AI Search guidance
- Schema.org Validator
Primary platform and standards sources were checked on 21 August 2026. Supported result types and property requirements can change; confirm the current feature guide before release.