2026-01-14 · Baduno Editorial Team · 7 blog.readMin · Blog & Knowledge
Structured Data: Schema.org Explained Clearly
Machine-readable supplementary information turns search results into rich results with reviews, FAQs, and company data. Here's how it works.
What structured data is
Invisible JSON blocks in the source code describe what is on the page: This is a company with this address, this is an article with this date, this is a FAQ with these questions. Search engines don't have to guess – they read.
What it delivers
Eligibility for enhanced displays (FAQ snippets, breadcrumbs, organization panel), better understanding of relationships, and cleaner Knowledge Graph entries. Not a ranking turbo – but more surface area and trust in search results.
The most important types for businesses
Organization with registration data, WebSite, Service or Product with Offer, Article for professional articles, FAQPage, and BreadcrumbList. For multilingual: Each language version carries its own translated markup.
Don't forget to validate
The Rich Results Test shows what Google reads, the Schema Validator checks syntax. Faulty markup is worse than none – it costs trust and, in serious cases, the enhanced display.
Structured data and hreflang: The perfect interplay for multilingual pages
A common source of errors on multilingual websites is inconsistent use of structured data and hreflang tags. While hreflang signals language and regional alternatives to search engines, structured data reveals the content type. Both are independent but complementary: A German product page should both link to the English variant via hreflang and, in the structured data block, mark up the same product ID with different offers and languages. Important: Each language version receives its own JSON-LD block with appropriate values – otherwise contradictions arise. Google's Rich Results Test often shows errors when, for example, the organization in the German version contains an English address. Therefore, always check both markup types in parallel after each language rollout.
Maintenance and updates: Who manages the data?
Structured data is not a one-time project. When prices, opening hours, or product details change, the JSON-LD blocks must be updated. Ideally, the content management system handles dynamic population. If this automation is missing, a clear responsible person in the team is necessary – for example, the editor for article and FAQ data, and the developer for organizational data. Avoid data silos: An outdated phone number in the Organization block damages trust. Plan quarterly reviews of all structured data, at least before every major relaunch. A central dashboard showing all marked-up pages and their validation status is helpful.
AI-assisted creation and verification of structured data
Modern AI tools can automatically generate JSON-LD from unstructured text – for FAQ pages or articles, for example. This speeds up work, but carries risks: AI often overlooks contextual nuances (e.g., incorrect price or outdated date). Therefore, native-language review by an editor is essential. Use AI for the rough draft, then have a human validate the values. For multilingual pages, AI also helps with translating structured data, but hreflang tags and language-specific IDs must be set manually. A proven approach: AI creates the English standard block, a local editor corrects and adds country-specific fields.
Machine-readable supplementary information turns search results into rich results with reviews, FAQs, and company data. Here's how it works.
Mark dynamic content: FAQs, reviews, and products
Errors occur particularly often with dynamic content. FAQ pages should have a separate JSON-LD entry per question – not the entire list as a single Question object. For reviews, the rating scale must be correctly specified (e.g., bestRating and worstRating). Product pages with variants require AggregateOffer blocks with all price and availability information. Use templates in the CMS that automatically generate the correct types. Test each dynamic page individually in the Rich Results Test, as errors only become visible with concrete values. A common mistake: using 'Review' instead of 'AggregateRating' for average ratings.
Combining multiple Schema.org types on one page
On a single page, you can mark up multiple Schema.org types in parallel, provided they describe different aspects of the content. A product page might simultaneously contain a Product block (with price, availability), an Organization block (for the manufacturer), and a Review block (for ratings). It is important that each type is placed in its own JSON-LD script or consistently linked via @id. For example, the Product block references the Organization block with "brand": {"@id": "#organisation"}. Avoid contradictory information – such as different addresses in the Organization and LocalBusiness blocks. Each type must be correctly and language-specifically marked up: a French page receives French values in all blocks. Use the CMS to manage types modularly so you don't have to adjust each block manually. Check with the Rich Results Test whether all blocks are accepted – some tests may only display the first block. A clean combination of multiple types increases the chances of rich results such as carousel, product boxes, or organization panel.
Working with @id and References for Linked Data
Schema.org allows referencing objects via @id to avoid redundant data. Instead of repeating the full organization on every page, define a central Organization block with a unique @id (e.g., "https://example.de/#company") and reference it in other blocks via "@id": "https://example.de/#company". This is especially useful for multilingual websites: the organization remains the same, only language-specific fields like "name" or "description" differ. Ensure that the @id is consistent across all language versions – i.e., the same URI for German, English, etc. References can also be used for article authors, product brands, or review items. Validate with the Schema Validator that all @id references are resolvable. A common mistake: if the referenced @id is not defined in the same page source or on another page, validation fails. Therefore, store central entities either in a global file (e.g., organisation.json) and include them via JavaScript, or use the CMS for dynamic integration. A clean @id structure helps search engines link information and improves consistency in the Knowledge Graph.
Correctly Marking Up BreadcrumbList: Tips and Pitfalls
Marking up BreadcrumbList may seem simple, but in practice, mistakes often occur that jeopardize rich snippet success. A correct implementation starts with understanding the hierarchy: each entry in the list requires an ItemListElement object, which in turn contains a ListItem object. The position property is crucial: it numbers the elements ascending, starting with 1 for the homepage. Avoid omitting the homepage – even if it doesn't appear in the visible breadcrumb, it should be included in the structured data. A common mistake is using absolute URLs without considering the language version: ensure the URL in the breadcrumb points to the correct language variant, e.g., /de/products instead of /en/products. Also, the naming of the elements must be language-specific – 'Startseite' in German, 'Home' in English. Use the name field for the displayed text and avoid abbreviations or acronyms that search engines might misinterpret. After implementation, test each path with the Rich Results Test, as dynamically generated breadcrumbs can easily have swapped positions or duplicate entries. Note that Google displays a maximum of ten elements – a shorter, precise navigation is therefore preferable to an overly long one.
Nested Objects and References: @id and @context
Complex structured data often uses linking of multiple types via @id references. A typical example is a product page that contains both an Offer and a Review. Instead of cramming all data into one monolithic block, it is cleaner to define separate blocks with unique @id values and then reference them. The @id value must be unique within the page and the entire domain – ideally, use the absolute URL of the object with a fragment like #product-1. Avoid generic IDs like #produkt, as they cause conflicts across multiple pages. Another important aspect is the @context: by default, the Schema.org vocabulary is used, but for proprietary extensions, a custom context can be specified. Ensure that verified extensions like health-lifesci or bib do not inadvertently end up on commercial pages. For multilingual pages, @id references must be language-specific: the German product page references the German Offer ID, not the English one. A useful technique is using @reverse for inverse relationships, e.g., when a product references an organization, but the organization does not maintain a direct list of all products. Test such chains in the Schema Validator, as even a missing colon leads to a validation error. Allocate sufficient time for debugging referenced objects – they are a common source of errors in complex implementations.
blog.faqT
Can I add structured data retroactively to old pages?
Yes, structured data can be added at any time. Ensure that all information is up to date. Use Google's Rich Results Test to verify correct implementation. For many pages, a step-by-step approach per content type is recommended.
How often should structured data be updated?
Whenever the underlying information changes (prices, opening hours, product details). Plan at least a quarterly overall review. Dynamic systems can automatically populate data – reducing update effort and sources of error.
