Structured Data for SMEs: Schema.org, Rich Results and Validation

Distinguish Schema.org, structured data and rich results

A vocabulary describes meaning; a search feature sets its own rules

Schema.org provides a shared vocabulary: types such as Organization or Article and properties such as name, author or dateModified. Structured data is the concrete page markup that uses this vocabulary. JSON-LD, Microdata and RDFa are possible formats. Google supports all three and generally recommends JSON-LD because it can be maintained separately from the visible HTML. The Google introduction to structured data describes this markup as standardised clues about a page's content.

Separately, the Google structured data general guidelines apply. They link technical markup to quality requirements: the markup must fit the main content, users must not be misled, and the page must be accessible for the relevant use case. These boundaries should be checked when selecting the model, not only after an error appears.

A rich result, by contrast, is a specific presentation in Google Search. It has its own technical, content and quality requirements. A property can therefore be correct within the Schema.org vocabulary without being used for a Google search feature. Conversely, a Google-supported type is not enough if required information is missing, the content is not visible or the page violates a policy.

Five validation states prevent false success reports

A green test therefore confirms only the state that the tool examined. It is not evidence that Google has indexed the URL, selected the markup or will display an enhanced search result consistently. This distinction belongs in every ticket and report.

Define the page type, source of truth and objective before writing markup

Modelling starts with the approved page, not a generator

Start by defining one URL or a homogeneous template, its visible main content and the intended search use case. A service page is not automatically a product, a company blog is not automatically a news organisation, and a contact page without a served physical location is not a LocalBusiness. The type must describe the main purpose of the actual page, not imitate a hoped-for search appearance.

Next, establish which systems are authoritative for the name, logo, address, author, prices, availability, publication date and other claims. The CMS, inventory system, location management platform and theme may hold different versions of the same information. Until the valid value is clear, the structured output must not conceal the conflict. Correct the visible page and the authoritative data source first; add the markup afterwards.

The title element, headings, visible copy and image information should already be aligned editorially. Use the preceding guide to on-page SEO for SMEs for this work. Structured data cannot repair an unclear page role and does not replace visible information.

Maintain a Structured Data Release Ledger as the shared source of truth

Every published claim needs a source, rule, owner and retest

The Release Ledger connects a URL or template group to its intended entity model, visible source and validation evidence. It prevents a plugin status being treated as complete approval or a change going live without an accountable owner. An entry is closed only after the published URL has been tested again.

For each finding, add the timestamp, language, device or user agent, expected state, observed state and ticket link. For dynamic data, include the cache time and data age. This makes it possible to distinguish whether an error originates in the source, mapping, template logic, rendering or only after publication.

Translate visible claims into entities and relationships first

A small, consistent graph is more valuable than many isolated blocks

Begin by identifying real things on the page: the company, location, website, article, person, product, offer and breadcrumb navigation. Then decide which thing is the URL's main entity and which entities merely provide context. On an article page, the article is normally the main entity; the organisation, author and website relate to it but do not become competing main objects.

Do not populate a field merely because the generator offers it. Include it when the value is meaningful for the selected type, current, and visible or otherwise unambiguous to users. If the information is absent from the page, either add it editorially or remove it from the markup. A structured claim must not extend beyond the substantiated main content.

Record intentional omissions as well. An SME that does not publish opening hours does not need invented values. An article without a demonstrably qualified author should not inherit a person from a global default. Gaps in the model often reveal missing content governance; they are not an invitation to fabricate data.

Decide on Schema.org vocabulary and Google eligibility separately

The search gallery defines the approval boundary for Google features

Check the Google Search Gallery for current documentation of the intended search feature. The feature guide linked there provides the basis for the eligibility review; the Google structured data validation overview places the Rich Results Test within this workflow. Search features change: Google Search updates documents relevant launches and removals. The approval record must therefore capture the documentation current at the time of the test.

The vocabulary is broader. The Schema.org schema documentation contains more types and properties than Google uses for rich results. Schema.org version 30.0 was released on 19 March 2026; a valid property from that vocabulary is still not evidence of a Google search feature. First establish whether the model accurately describes the real object, then assess its Google eligibility separately.

This separation prevents two errors: teams remove useful semantic data simply because it produces no rich result, or promise a particular appearance because a type exists in the vocabulary. The Release Ledger can document both: semantic purpose and Google use case have separate fields.

The URL's technical accessibility and indexability remain prerequisites outside the markup. If the response, canonical, robots rules or rendering are unresolved, use the guide to technical SEO for SMEs first.

Use stable entity identifiers and unambiguous relationships

The same organisation should not be reinvented on every page

A stable absolute identifier using @id can connect recurring entities across pages and blocks. For example, the organisation can be defined on the homepage and referenced as the publisher in articles. The identifier is not a public profile and does not have to resolve as a page; as a durable internal identity commitment, however, it should not change with every theme update.

Maintain a small registry of reusable entities: Organization, WebSite, public person roles, real locations and, where appropriate, product families. For each entry, document the canonical URL, identifier, responsible system and permitted properties. Language variants can contain localised names or descriptions, but they should not present the same real organisation or person as unrelated identities.

Avoid circular or conflicting models. A product offer must not point to a different product identity, an author represented as a Person must not also be typed as the company, and a location must not alternate between LocalBusiness and a mere postal address. When in doubt, a smaller, coherent graph is safer than numerous automatically added nodes.

Generate JSON-LD from one accountable source

A page type needs one controlled generator, not competing plugins

JSON-LD can be generated centrally from template data without changing the visible design. That makes it maintainable but not automatically correct: a clean block can still carry incorrect defaults, outdated master data or empty variables. Define exactly one technical owner for each entity and page type. The theme, SEO app, review service and shop system must not independently publish the same Product, Organization or Breadcrumb node.

Specify the mapping like a data interface. For every property, define the source, data type, required logic, fallback, locale behaviour and exclusion condition. A fallback may provide only an equivalent confirmed value. It must not invent an address, rating, author role, availability or price when the business source is empty.

Version the mapping and template together. After every change to fields, applications or localisation, retest a representative URL sample. A manually inserted block disconnected from its source may work on one page, but it quickly becomes stale when prices, authors or addresses change.

Limit markup to visible, relevant and current content

Technical validity cannot cure a misleading claim

Google's general guidelines require markup to represent the page's main content truthfully and to be visible or relevant to users. Do not mark up a service the company does not offer, a review that is absent from the page, or a price available only in another market or subject to additional conditions.

Assess quality at three levels. First, the value must be factually correct. Second, the visible presentation must convey the same meaning. Third, the technical output must match the current state of the actual URL. An offer with a correctly formatted number remains wrong if the visible product page now shows a different price. An old dateModified value remains syntactically valid but can misrepresent the content's recency.

A policy violation can affect eligibility for rich results. It does not automatically mean that the page is removed from standard search results. Reports and stakeholder communication should describe the consequences precisely rather than claim a general ranking penalty from a structured data error.

Define separate contracts for an organisation, location, article and product

Organization and LocalBusiness describe different levels

Organization represents the company's public identity. The Google Organization documentation recommends placing the markup on the homepage or a central company page and specifies no required properties. Include only relevant public data: the legally and editorially confirmed name, URL, logo, and verified contact or profile relationships.

LocalBusiness describes a real, served physical location. According to the LocalBusiness documentation, name and physical address are required, and the most specific appropriate subtype should be selected where possible. Model multiple locations as separate entities with their own pages and data. A virtual presence, PO box or desired service area does not justify an invented street address.

Article and merchant listings require precise editorial or commercial data

For blog posts and guides, the Google Article documentation lists recommended properties such as headline, author, datePublished, dateModified and image. The author identity must match the visible byline; update dateModified only after a genuine, traceable content change. An automated build date is not a substitute for editorial maintenance.

The merchant listing documentation applies to pages where a specific product or variant can actually be purchased. Price, currency, availability, variant and offer period must match the visible purchasing state. For rapidly changing values, prefer reliable initial HTML output and reconcile it with feed or backend data.

Control reviews, offers and dates particularly strictly

An attractive snippet must not be obtained through unsubstantiated claims

Reviews are not a decorative field. The Google review snippet guidelines exclude, among other things, self-serving reviews for LocalBusiness and Organization from star review features. Do not import aggregate ratings from third-party platforms as your own review basis, and disclose incentives or editorial relationships transparently when collecting reviews.

For Germany, the official annex to the Act Against Unfair Competition contains specific provisions on consumer reviews: claims that reviews are authentic require reasonable verification measures; fake reviews and false representations for sales promotion purposes are prohibited. This summary is not individual legal advice. In case of uncertainty, involve the responsible legal and compliance specialists.

A fail-closed approach is appropriate for these fields: if a reliable value is missing or systems conflict, suppress the affected object instead of inserting a default. Correct the visible user journey and authoritative source first.

Localise DE, EN, RU and UK without multiplying real entities

Translatable copy and shared master data need separate rules

Multilingual pages can localise the name, description, article headline and other language-dependent values. The legal company name, unchanged brand identity, product identifier or physical address remain shared facts unless the target market legitimately requires a different representation. For each property, define whether it is translated, formatted, referenced jointly or sourced locally from a market-specific system.

Test every language URL separately. A global JSON-LD block can output the German headline on every variant, a shop system can change currency or availability by market, and a cache can retain old locale values. DOM parity across templates is useful, but it does not replace linguistic and factual reconciliation.

Entity IDs can connect the same real organisation or person across language paths. Article or product pages, by contrast, have their own canonical URLs and localised page claims. Canonical and hreflang are assessed in technical SEO; the Structured Data Ledger only records which URL and language the relevant node actually describes.

Remove duplicate and conflicting outputs from themes, applications and the CMS

Several valid blocks can combine into an incorrect overall model

Many platforms already publish structured data: the theme may add Organization and BreadcrumbList, an SEO app a second Organization node, a review app AggregateRating and the commerce module Product with Offer. Each block can be syntactically valid in isolation while the name, @id, price, image or availability conflicts across the combined graph.

Inventory all generators in the original HTML and rendered DOM. Assign every node to an owner and decide which generator remains. Disable components only after testing, because an app may control visible functions or data feeds as well as markup. Where removal is impossible, deliberately align IDs, sources and update logic.

Typical conflicts include sitewide AggregateRating output, Product on category pages, multiple prices for different variants, an obsolete logo path or Organization nodes with changing identifiers. Fix the generating rule and test a sample instead of manually patching individual pages.

Test syntax, Google eligibility and published reality separately

Every validator answers only a particular question

The Schema Markup Validator helps assess syntax, types, properties and the extracted Schema.org graph. The Google Rich Results Test, by contrast, checks whether Google detects supported rich-result types in the tested output and identifies errors or warnings for those features. A Schema.org-valid node can intentionally remain without a supported Google feature.

During development, begin with reproducible examples. Before approval, however, test the actual URL because only it reflects redirects, robots rules, JavaScript, resources, consent, market logic and cache behaviour. Save a screenshot or export, timestamp, tested URL and tool status in the Ledger. A link to an ephemeral test result alone is not sufficient for later root-cause analysis.

Record errors and warnings together with the affected property and the value actually extracted. An error in a test copy may already have been corrected while the live cache still serves the old block; conversely, a code example may pass even though real product data generates empty or incorrectly formatted values. Never report a test stage without its URL, environment and data state.

Source, rendered DOM and live URL must carry the same model

Compare the initial HTML response with the rendered document. Google can process JavaScript-modified output, but late data increases the risk of delays and discrepancies. Price and availability in particular should not appear only after interaction or arrive from an unstable third-party source. Also test smartphone output, locale, signed-in and anonymous states, and at least one URL for each template edge case.

For monitoring after publication, continue with working with Google Search Console for SMEs. URL Inspection and rich-result status reports show what Google detects for known URLs. They replace neither fact reconciliation nor a controlled live retest.

Roll out the change with a sample, rollback path and clear decision

Approval means evidenced consistency, not merely green code

Start with a small, representative group: for each page type, select a normal URL, one language variant, one dynamic page and one known edge case. Test the same layers before and after the change. Assign the rollout an owner, time window, cache plan, monitoring and a rollback route in case prices, visibility or templates behave unexpectedly.

Do not treat warnings categorically as errors or as meaningless. The team documents whether the recommended property is factually available and useful for the use case. If it is intentionally absent, retain the decision in the Ledger. For critical conflicts, stop the rollout or restore the last known version.

Measure detection and search appearance after publication without false causality

For supported types, Search Console can group valid items, invalid items and items with warnings. “Valid” means the detected output is generally eligible for the feature; it does not mean every URL receives a rich result. Assess changes alongside indexing status, release date, page type and search queries.

Define a small comparison baseline before rollout: affected URLs, time period, devices, countries, search appearance and any other changes planned for the same time. Monitor technical errors and detection coverage first. Impressions, clicks or click-through rate need longer periods and enough data. Seasonality, rankings, snippet rewrites, demand and other releases can change the same metrics.

A decline after a feature update is not automatically an implementation error. Google can change or retire search features. Check current documentation, release history and test results before removing working markup. Semantically useful data can remain even when a particular search appearance is discontinued.

Frequently asked questions about structured data