Structured data: types, facts and validation

Structured data, Schema.org, JSON-LD and rich results

These terms are not interchangeable. Structured data is the general approach. Schema.org supplies a vocabulary of types, such as Organization and Service, and properties, such as name and provider. JSON-LD is a format for expressing that information in a page’s script element. Google also supports Microdata and RDFa, but generally recommends JSON-LD for easier maintenance.

Rich results are enhanced search appearances, not a markup format. Schema.org validity alone does not make a page eligible for one. Google’s feature documentation defines its supported features and their requirements.

Choose types that match visible content

Choose the most specific applicable type, not the one that seems most attractive in search. Article, BreadcrumbList and Product have documented Google features with their own conditions. Organization and profile-page markup serve different purposes. Service is a Schema.org type, but Google does not list a dedicated Service rich result.

Names, descriptions and provider relationships must reflect the page. Do not add hidden achievements, prices or ratings. Supply required properties for the relevant Google feature; add recommended properties only when accurate and applicable.

Worked example: Koupoli, Karlo and a service

Consider an illustrative model, not a report of deployed or tested markup. An Organization has the name Koupoli and url https://koupoli.com/. Its proposed @id is https://koupoli.com/#organization. A Person named Karlo Ridan uses the example identifier https://koupoli.com/about/#karlo-ridan. The About page visibly identifies Karlo as Koupoli’s founder, supporting a founder reference from the organization to the person.

A Service has the name Technical SEO services and url https://koupoli.com/services/technical-seo-ai-search/. Its proposed identifier could add #service to that URL. Its provider references the same Koupoli organization identifier. Its description can summarize the page’s visible crawl and indexation, site architecture, rendering and structured-data work. Do not invent results or reviews.

The url points to the relevant page; @id identifies the described item for consistent references. Check existing identifiers before adopting these examples. Keep each fact visible on the page its markup describes.

A workflow from page selection to maintenance

Treat structured data as maintained page information, not a one-off plugin setting.

• Choose the page and document the facts it actually publishes.
• Choose the type and check Google’s documentation if targeting a supported feature.
• Map properties to visible facts. Reuse stable identifiers rather than creating conflicting copies.
• Have the person responsible for the business confirm provider and founder facts, then assign responsibility for keeping them current.
• Test the draft, resolve errors and review warnings without inventing missing facts.
• Deploy, retest the public URL and use Search Console URL Inspection to check access and rendered content.
• Monitor applicable enhancement reports and revisit markup after content, template or service changes.

Use both validators and avoid false confidence

Google’s Rich Results Test checks supported Google features and their technical requirements. Schema Markup Validator checks Schema.org markup more broadly, including types without dedicated Google rich results. It extracts the data and flags syntax issues without Google-specific feature validation. Neither tool verifies factual truth or every quality rule.

Common mistakes include conflicting plugin output, changing identifiers, marking up invisible claims, stale service details and interpreting no eligible rich result as invalid Schema.org markup. Check the page and the relevant tool before changing types.

A passing test does not guarantee rich results, higher rankings or AI citations. Google requires no special schema for AI Overviews or AI Mode. Useful visible content and crawlable pages still matter.