Structured data is machine-readable markup that describes a page and the entities it contains. Schema.org supplies the vocabulary; Google’s current Search documentation decides whether a type can qualify for a Google rich result. Correct markup improves clarity and eligibility, not guaranteed rankings or display.
Mark up the page’s visible, current truth with the smallest useful model. Never invent a review, rating, price, author, location, product or relationship because a generator offers the field.
Separate four terms that are often mixed together
| Term | Meaning | What it does not mean |
|---|---|---|
| Structured data | Machine-readable information in a standardized form | Any specific vocabulary or search display |
| Schema.org | A shared vocabulary of types and properties | Automatic Google support for every type |
| Schema markup | Using that vocabulary on a page, often as JSON-LD | Guaranteed rich result or ranking |
| Rich result | A Google result enhanced for a supported feature | Every SERP feature or Knowledge Panel |
| Search appearance | How Google reports or presents a result type | A permanent format; features can change |
What structured data can and cannot do
Google uses structured data as explicit clues about page meaning and to enable supported rich-result eligibility. Eligibility is only one input: Google can still choose a normal text result, and Search appearance can vary by query, location, device and product.
Google does not promise that markup alone improves rankings, wins clicks, creates trust or earns inclusion in AI answers. Its current AI optimization guidance points site owners back to normal SEO fundamentals rather than a special AI Schema type.
| Can help | Cannot guarantee |
|---|---|
| Clarify a page, entity and relationships | That every claim is believed without evidence |
| Qualify for a currently supported feature | That the feature will display |
| Keep machine-readable facts consistent | Higher web rankings |
| Expose product, article or event attributes | Traffic, sales or AI citations |
| Improve monitoring through enhancement reports | Coverage for unsupported Schema.org types |
Use a source hierarchy before choosing a type
For Google Search behavior, treat current Google Search Central documentation and the Search Gallery as authoritative. Use Schema.org to validate vocabulary and model broader data. Generators, plugins and third-party articles are implementation aids, not the final eligibility rule.
This hierarchy matters because rich-result support changes. A recently published checklist can become outdated when Google retires a feature.
| Decision | Primary source | Why |
|---|---|---|
| Does Google support this appearance now? | Google Search Gallery and feature guide | Current Search eligibility and policies |
| Is this Schema.org type/property valid? | Schema.org definition and validator | Vocabulary-level validity |
| Which fields are required/recommended by Google? | Current feature documentation | Eligibility differs from Schema.org |
| How will our CMS generate it? | CMS/plugin documentation and source code | Implementation-specific behavior |
| Did production output stay accurate? | Visible page, JSON-LD, logs and Search Console | Live evidence beats configuration screens |
Feature support changes: the 2026 FAQ example
Google stopped showing FAQ rich results on May 7, 2026 and removed the FAQ rich-result documentation in June 2026. An FAQ section can still help users, and FAQPage remains a Schema.org type, but it no longer qualifies for a Google FAQ rich result.
The same maintenance principle applies to any retired or changed feature: preserve useful visible content, remove obsolete promises and monitoring, and recheck whether the markup still has a non-Google consumer or operational purpose. Do not delete helpful FAQs simply because the decoration disappeared.
- Confirm the change in Google’s documentation update log.
- Check the current Search Gallery and feature guide.
- Separate visible-content value from rich-result eligibility.
- Remove deprecated reporting and unsupported promises.
- Keep valid non-Google markup only when it has an identified consumer.
- Update templates, documentation and QA cases together.
- Annotate the date in performance reporting.
Choose the type from the page’s primary purpose
Start with the page users actually see. Select a specific truthful primary type and add secondary entities only when they have a clear relationship to that page. More nodes are not automatically better.
| Page purpose | Practical model | Important limit |
|---|---|---|
| Personal-brand home/about | Person, or Organization if a real organization is primary | Keep one stable identity; do not pretend both are unrelated publishers |
| Business home/about | Organization or specific subtype | Google recommends one home/about placement rather than every page |
| Blog or news article | Article, BlogPosting or NewsArticle | Real author, dates, headline and representative images |
| Site hierarchy | BreadcrumbList | Represent a normal user path with final URLs |
| Physical location | Specific LocalBusiness subtype | Visible, accurate address, hours and phone |
| Product for sale | Product plus Offer/merchant properties | Single product or variants; price and availability must match |
| Software landing page | SoftwareApplication when requirements fit | Do not reuse one app rating across unrelated products |
| Service page | Service may describe meaning | No dedicated Google Service rich result is promised |
| FAQ content | Visible HTML first; optional Schema.org modeling only with a reason | No Google FAQ rich result since May 2026 |
Use JSON-LD when it is easiest to keep correct
Google supports JSON-LD, Microdata and RDFa, and generally recommends JSON-LD because it is easier to express nested data and maintain at scale. The best format is still the one your system can generate accurately and test reliably.
JSON-LD may appear in the <head> or <body>. Its separation from visible HTML is convenient, but also makes content drift easier unless both outputs share a source of truth.
| Format | Strength | Operational risk |
|---|---|---|
| JSON-LD | Readable, nested and template-friendly | Can drift silently from visible content |
| Microdata | Properties stay close to visible elements | Harder to refactor and review in complex markup |
| RDFa | Flexible linked-data attributes | Less familiar to many delivery teams |
| JavaScript-injected JSON-LD | Can use dynamic route data | Depends on rendering and can lag fast-changing facts |
Build one coherent entity model
Use absolute public URLs. A stable @id is a practical identifier for recurring entities, but it is not a substitute for a real page, brand, author or organization. An @graph is optional organization—not an SEO requirement.
Connect an article to its real author and publisher, a Breadcrumb to final route URLs, and a product to its real Offer. Use sameAs only for profiles that genuinely identify the same person or organization.
- One preferred HTTPS URL for each public entity.
- Stable name, URL and identifier across templates.
- Current crawlable logo or representative image.
- Real author profile URL where available.
- Verified official sameAs profiles only.
- Contact and address only when accurate and relevant.
- Breadcrumb and entity URLs agree with Canonical routes.
- No test, staging or placeholder identifiers in production.
Create a field-level source of truth
Every property needs an owner and upstream field. Generate visible content and JSON-LD from the same record whenever possible. If a value is not collected reliably, omit it rather than filling it with a guess.
Fast-changing ecommerce facts deserve special care. Google warns that dynamically generated Product markup can make Shopping crawls less frequent and less reliable; initial HTML and Merchant Center feeds may be better for price and availability workflows.
| Property | Source of truth | Release rule |
|---|---|---|
| headline/name | Published page record | Must match the visible subject |
| author | Verified author profile | Include all visible authors separately |
| datePublished | Original publication record | Never reset during a cosmetic edit |
| dateModified | Meaningful editorial update | ISO 8601 and visible when appropriate |
| image/logo | Approved media library | Relevant, crawlable and current |
| price/availability | Commerce system | Same value in page, JSON-LD and feed |
| rating/reviewCount | Verified user-review system | No manual invention or selective total |
| URL/Canonical/Breadcrumb | Routing configuration | Final production URLs only |
Map common templates without boilerplate abuse
| Template | Core relationships | QA sample |
|---|---|---|
| Article | Article → author Person/Organization → publisher | Headline, all authors, truthful dates, image |
| Homepage/About | WebPage → primary Person or Organization | Name, URL, logo, sameAs and contact |
| Breadcrumb | BreadcrumbList → ordered ListItems | Visible hierarchy and resolvable URLs |
| Location | LocalBusiness subtype → PostalAddress/hours | One real location and accurate service state |
| Product | Product → Offer, review or aggregateRating when eligible | Single product/variant, current commercial facts |
| Profile page | ProfilePage → mainEntity Person/Organization | Profile owned by the site and visible identity |
| Software app | SoftwareApplication → operating system/category/Offer or rating | Requirements and real app details |
| Service | WebPage → Service as descriptive entity | No promise of a service rich result |
Validation is a stack, not one green tick
The Schema.org validator checks vocabulary and extraction. Google’s Rich Results Test checks supported Google feature eligibility. URL Inspection checks a live Google render. None can verify business truth, ownership or whether a result will actually display.
Fix critical errors for eligibility. Review warnings against the feature documentation and your data; do not invent recommended fields merely to remove a warning.
| Layer | Tool/evidence | Question | Does not prove |
|---|---|---|---|
| JSON syntax | Parser or build test | Can the JSON be parsed? | Schema vocabulary |
| Vocabulary | Schema.org Validator | Are types/properties recognized? | Google rich-result support |
| Google eligibility | Rich Results Test | Does a supported feature meet technical fields? | Display or truth |
| Rendered delivery | URL Inspection and rendered HTML | Can Google access final markup? | Indexing or ranking |
| Content parity | Visible page versus JSON-LD | Do claims match? | Policy compliance by itself |
| Production health | Enhancement reports and sampled URLs | Did templates remain valid? | Business impact |
Quality policies matter more than syntactic validity
Google requires markup to be visible, current, representative of the page’s main content, original where required and not misleading. A technically valid block can still lose rich-result eligibility or trigger a structured-data manual action.
Google says a structured-data manual action removes rich-result eligibility rather than changing normal web ranking. Resolve the underlying deceptive or inaccurate markup and use Search Console’s Manual Actions process where applicable.
| Risk | Why it fails | Correct response |
|---|---|---|
| Hidden or unrelated marked-up content | Not representative of the visible page | Show the fact or remove the property |
| Fake product, author or location | Misleading identity | Use verified real entities only |
| Outdated event, price or availability | Time-sensitive data is wrong | Sync or remove immediately |
| Markup on a blank holder page | No useful described page content | Put markup on the page it describes |
| Incomplete visible review set | Selective and misleading representation | Mark up all visible reviews consistently |
| Wrong primary type | Page focus is ambiguous | Use the most specific truthful type |
Reviews and ratings need a separate evidence gate
Do not add five stars because testimonials exist. Review and aggregateRating properties must follow the current supported-type rules, describe the reviewed item clearly, come from real users and match visible review information.
For LocalBusiness and Organization, Google does not show self-serving review snippets when the reviewed entity controls the reviews on its own pages—even through an embedded third-party widget. Fake reviews are prohibited, and reviews exchanged for a benefit require clear, prominent disclosure.
- Confirm the reviewed type is currently eligible.
- Identify the reviewed item once and unambiguously.
- Verify every review and rating source.
- Show the represented review information to users.
- Recalculate average and count from the same dataset.
- Disclose incentivization clearly where applicable.
- Exclude staff-written or fabricated customer identities.
- Document who can correct or remove invalid data.
Handle JavaScript and GTM carefully
Google can process JSON-LD injected by JavaScript or Google Tag Manager when it appears in the rendered DOM. That capability does not make client injection the safest default for essential or fast-changing data.
Google recommends deriving GTM variables from the page instead of duplicating values in the container. Server- or build-generated JSON-LD is usually easier to version with content; follow the JavaScript SEO guide when rendering or API failure can affect the graph.
| Method | Use when | Main control |
|---|---|---|
| Server/build output | Identity, Article and stable route data | Same record generates page and JSON-LD |
| CMS/plugin output | Supported templates with clear ownership | Disable duplicate generators and inspect output |
| GTM injection | Controlled transitional implementation | Page-derived variables, versioning and consent behavior |
| Custom client JavaScript | Genuinely dynamic data | Rendered tests, API fallback and production monitoring |
Align multilingual, duplicate and Canonical pages
Each language URL should contain markup matching its visible translation, language-specific Canonical and Breadcrumb URLs. The underlying person or organization can keep one stable identity while page names, descriptions and URLs localize.
Google recommends placing equivalent structured data on duplicate pages too, not only the Canonical. Coordinate route decisions with the Canonical guide and keep hreflang, Sitemap and internal links consistent.
- Localized headline, description and Breadcrumb names.
- Self-consistent Canonical for each intended language URL.
- Hreflang points to equivalent pages.
- Entity identity remains stable across translations.
- Prices, currencies, dates and availability reflect the visible market.
- All marked image URLs are crawlable.
- No untranslated placeholder or fallback values.
Roll out by template, then monitor
Treat structured data as production code. Start with one valuable supported template and a small URL sample; do not deploy an unreviewed generator across thousands of pages.
- Define the page purpose and current Google feature, if any.
- Read the feature-specific and general guidelines.
- Inventory visible facts and their owners.
- Choose the smallest accurate model and format.
- Map every property to a source field.
- Generate page content and JSON-LD from shared data.
- Validate syntax and Schema.org vocabulary.
- Run Rich Results Test for supported Google features.
- Compare visible, raw and rendered production output.
- Deploy a representative sample and inspect live URLs.
- Expand by template only after the sample passes.
- Monitor enhancement, Manual Actions, releases and feature changes.
Measure eligibility and search impact honestly
Measure structured data as a release and eligibility change, not as a guaranteed ranking experiment. Search Console can expose enhancement validity and some Search appearance filters, but feature availability and reporting differ by type.
Annotate the deployment date, compare eligible page/query cohorts, and track impressions, clicks, CTR and qualified outcomes. A richer result may change presentation without changing rank; seasonality, query mix and other releases limit causal claims.
| Metric | Question | Limit |
|---|---|---|
| Valid/invalid items | Did the template produce eligible markup? | Validity does not guarantee display |
| Indexed eligible URLs | Can Google process the intended pages? | Not every valid page is indexed |
| Search appearance impressions | Did a supported appearance show? | Filters are feature-dependent |
| CTR by page/query | Did presentation and relevance improve clicks? | Rank and query mix may also change |
| Leads/revenue | Did the eligible traffic create value? | Attribution needs analytics quality |
| Manual spot checks | Do visible facts still match markup? | Sampling can miss rare states |
Maintain a feature and template registry
Rich-result support, property rules and Search Console reporting change. Assign an owner and last-reviewed date to every generated type, and subscribe to Google’s Search documentation updates.
Add structured-data checks to the SEO audit workflow. Revalidate after CMS migration, redesign, routing changes, author or logo updates, review-provider changes, commerce changes and new languages.
| Registry field | Example |
|---|---|
| Template | Blog article |
| Primary type | BlogPosting |
| Google feature/status | Article — supported as of review date |
| Generator/owner | Build module — engineering |
| Source fields | Title, author, dates, image, publisher |
| Sample URLs | New, old, translated and edge-case pages |
| Last reviewed | Date + Google documentation link |
| Monitoring | Build test, RRT sample and Search Console report |
Common structured data myths
- “Valid Schema.org markup guarantees a Google rich result.”
- “Schema markup is a direct ranking factor.”
- “Every page needs every possible type.”
- “FAQ markup still creates Google FAQ results in 2026.”
- “Testimonials justify five-star Organization markup.”
- “A green Rich Results Test proves every claim is true.”
- “Recommended fields should be filled even when the data is unknown.”
- “A plugin configuration screen proves production output.”
- “JavaScript injection is always equivalent to initial HTML.”
- “Schema alone is a special shortcut into AI answers.”
Frequently asked questions
What is the difference between structured data and Schema markup?
Structured data is the broader concept; Schema markup usually means using Schema.org vocabulary on a webpage, often in JSON-LD.
Does structured data improve Google rankings?
Google can use it to understand content and enable supported appearances, but does not promise a ranking increase from markup alone.
Does valid Schema guarantee a rich result?
No. The type must be supported by Google, meet current technical and quality rules, and Google still decides whether the appearance is useful for that search.
Should every page have JSON-LD?
Only when accurate markup has a purpose, source of truth and owner. More nodes without reliable data increase risk rather than value.
Does FAQPage still create Google FAQ rich results?
No. Google stopped showing the FAQ rich-result feature on May 7, 2026 and removed its documentation in June. Keep useful FAQs for people, not the retired decoration.
Can a personal brand use Person and Organization?
Model the real primary entity and relationship. A real company may publish a person’s profile; a solo personal brand should not invent a separate organization merely to add nodes.
Can I add five-star markup for testimonials?
Not automatically. Ratings require an eligible reviewed type, genuine sourced ratings and visible matching data; self-serving LocalBusiness or Organization review snippets are ineligible.
Are warnings in the Rich Results Test failures?
Critical errors can block eligibility. Warnings often refer to recommended fields; add them only when the information genuinely exists and improves the result.
Can Google Tag Manager generate JSON-LD?
Yes, but derive values from the page, avoid duplicate markup and test rendered production URLs. Stable server/build output is often easier to govern.
How often should structured data be audited?
Retest whenever a template, URL, content field, commerce system, review source, language or Google feature changes, plus scheduled representative checks.
Official references
- Google Search Central: structured data introduction
- Google Search Central: general structured data guidelines
- Google Search Central: supported structured data gallery
- Google Search Central: documentation updates
- Google Search Central: Article structured data
- Google Search Central: Organization structured data
- Google Search Central: Breadcrumb structured data
- Google Search Central: Product structured data
- Google Search Central: LocalBusiness structured data
- Google Search Central: Review snippet guidelines
- Google Search Central: ProfilePage structured data
- Google Search Central: JavaScript-generated structured data
- Google Search Central: AI features optimization guide
- Schema.org: Markup Validator
- Ahrefs: Schema markup implementation guide
- Semrush: Schema markup implementation guide
Share the page templates, data sources and current JSON-LD. Jack can map accurate entities, remove unsupported or risky claims, and build a release and monitoring checklist.
How Google Ranking Evolved: From PageRank to Modern Search SystemsSeptember 2, 2026
Google AI Content and SEO: What Is Allowed, What Is Spam, and How to Publish SafelySeptember 2, 2026
Google Florida Update (2003): What We Know, What Remains TheorySeptember 2, 2026