Setting up Schema.org correctly: structured data for AI visibility

What Schema.org actually is

Schema.org is not a Google product but an open vocabulary maintained jointly by Google, Microsoft, Yahoo and Yandex. It defines types such as Product, Organization, Article, Event or LocalBusiness and matching properties such as name, price or openingHours. The idea is simple: instead of a machine having to guess from your text whether 49 euros is a price, a house number or a phone area code, you tell it directly and unambiguously.

The important difference: humans read meaning from context, machines need structure. A tax advisor writes initial consultation free of charge into a paragraph, and a human understands it immediately. A crawler sees only characters. With structured data you translate your page content into a format that every machine interprets the same way, whether it is a search engine, a price comparison site or an AI assistant.

For AI visibility this has become decisive. Language models and answer systems increasingly draw on structured signals to secure facts. When your company name, your address and your offering are stored in machine-readable form, the risk that an AI system cites you incorrectly or confuses you with a competitor drops.

JSON-LD instead of Microdata: the right format

There are three technical ways to mark up Schema.org: Microdata, RDFa and JSON-LD. Microdata and RDFa weave the details directly into your HTML, that is into the individual elements of your visible page. This quickly becomes confusing and breaks as soon as someone tinkers with the layout. JSON-LD, by contrast, you place as a separate script block, separated from the visible markup. Google explicitly recommends JSON-LD, and it is the standard today.

The practical advantage of JSON-LD: you can maintain the structured data in one place without touching the rest of the template. An online shop generates the Product block dynamically from the database, a publisher the Article block from the editorial system. Because the script block is independent of the design, it survives relaunches and style changes far better than nested Microdata attributes.

Concretely it looks like this: a script tag of type application/ld+json in the head or body of the page, containing a JSON object with @context https://schema.org and an @type. All that matters is that the marked-up details match what the user actually sees on the page. Anything else counts as spam and can be penalized.

Which types for which industry

Don't start with the rarest type, but with the one that fits your core business. A trades business or a dental practice uses LocalBusiness with address, opening hours and phone number. An online shop relies on Product together with Offer, price, availability and AggregateRating. A magazine or blog uses Article or BlogPosting with author, publication date and headline.

Other common cases: a seminar provider or event organizer uses Event with date, location and ticket price. A law firm or agency describes its services via Service and the company via Organization. A recipe portal takes Recipe with ingredients, preparation time and nutritional values. A software company can use SoftwareApplication. For each of these templates you'll find the complete list of allowed properties on schema.org.

Combine types where it makes sense. Almost every page benefits from an Organization or WebSite block that bundles brand, logo and social profiles. Frequently asked questions on a page you can additionally mark up as FAQPage. But don't overdo it: only mark up what really appears on the page and is relevant to the user.

Setting it up step by step

The process is manageable if you carry it out with discipline. First determine the page type, then research the required fields, then build the JSON-LD block, then test, then go live. Skip no step. Most mistakes happen because someone copies a block from the web without cleanly inserting or checking their own values.

Maintain the values as dynamically as possible from your data source. A price that shows 39 euros in the shop but still carries 49 euros in the JSON-LD is worse than no markup at all, because it destroys trust. Automated population from the CMS or the merchandise management system is the only method that stays consistent across hundreds of pages.

• Choose the page type: what is the main content of this specific URL?
• Clarify required fields: which properties does Google expect for rich results?
• Write or dynamically generate JSON-LD, pulling values from the real data source.
• Check with the Rich Results Test and the Schema Markup Validator.
• Go live and monitor the reports in the Google Search Console.

Testing and finding errors

No going live without a test. Two tools are enough for everyday work: Google's Rich Results Test shows you whether your markup qualifies for enhanced search results and which fields are missing. The Schema Markup Validator from Schema.org, by contrast, checks the pure syntactic and semantic correctness, regardless of whether Google builds a rich result from it. Use both, they answer different questions.

Pay attention to the distinction between errors and warnings. Errors mean that a required field is missing or a value has the wrong format, for example a date that doesn't conform to the ISO standard. Warnings concern recommended but not mandatory fields. Errors you must fix, warnings you should resolve where possible, because more complete data increases the chance of a good display.

After going live, check real URLs, not just pasted code. In the Google Search Console you'll find reports on products, FAQ, reviews and more, including the pages on which Google detects problems. This is your ongoing control: errors often only surface there once a template has been rolled out across many pages.

Common mistakes that cost you visibility

The most expensive mistake is inconsistency between markup and visible content. If you mark up reviews that appear nowhere on the page, or claim a discount price that doesn't apply, Google treats this as manipulation. That can lead to the loss of all rich results for the domain. Mark up exclusively what the user really sees and what corresponds to the truth.

Second classic: incomplete required fields. A Product without a valid Offer, an Event without startDate, an Article without author. Such blocks are ignored, your work was for nothing. Third mistake: outdated details. Opening hours that have changed, or sold-out items still marked as available, send false signals to humans and machines alike.

Fourth point: copy-paste without adaptation. Again and again you find blocks on the web that still contain the template's example data, foreign company names, placeholder URLs or a wrong @type. Check every block you take over field by field. And deduplicate: several contradictory Organization blocks on the same page confuse crawlers more than they help.

Why this matters for AI answers

AI systems increasingly answer questions without the user ever clicking on your page. They pull facts from the web and reproduce them in condensed form. Whether you appear correctly in such answers depends on how unambiguously your facts are stored. Structured data is the most reliable signal here, because it requires no interpretation.

An example: a user asks an assistant for a tax advisor in her city with evening consultation hours. If you have marked up your opening hours cleanly as LocalBusiness, the system can reliably assign you. If the info only sits in the running text of a subpage, the chance is smaller that it is correctly recognized and reproduced. Structure beats prose when it comes to hard facts.

Structured data, however, is not a substitute for good content but its amplifier. It helps machines understand what is on your page anyway. Whoever tries to fake substance with markup gets caught. Whoever cleanly marks up real, current details makes them accessible to the next generation of search and AI assistants in the first place.

Keeping schema current: maintenance instead of one-time setup

Structured data is not a project you finish once. It is a promise to search engines and AI systems: what stands in the markup should be true on the page. As soon as opening hours, prices, addresses or product availability change, your schema quietly ages in the background – and nobody notices until an AI serves up false information.

Therefore build in fixed checkpoints. If your data comes from a CMS or a shop system, the schema should follow automatically and not be maintained by hand. With static markup a quarterly check is worthwhile: are the phone number, URL, logo path and description still correct? A single dead link in the sameAs field or an old price is enough for a system to classify your markup as unreliable.

In practice this means: assign responsibility. Who updates the schema when marketing builds a new campaign page? Without clear ownership, exactly those contradictions between visible content and markup arise that cost you visibility later.

A worked example: from zero to the rich answer

Take a small trades business with five locations. Before the setup an AI knows only the running text of the homepage and guesses with every query. After adding LocalBusiness markup per location – with name, address, geo coordinates, opening hours and phone number – the system has a clean, machine-readable data record for each branch.

The effect is concrete. If someone asks the AI for the nearest location with Saturday opening, it can compare the openingHours and answer directly instead of passing. If you add FAQ markup with three real customer questions about directions, appointments and payment methods, these answers appear both in search results and in AI summaries.

Calculate the effort honestly: the first location may cost you two hours of familiarization, each further one ten minutes, because you only copy the structure and adapt the fields. Five locations are therefore half a working day – for a data basis that every AI and every search engine uses permanently.

Limits and misconceptions

Schema.org is not a ranking turbo. Structured data ensures that systems understand and display your content correctly – but it does not artificially lift a weak page. Whoever thinks they can mask poor content with lots of markup is wasting time. Conversely: good content without markup is often still found, just served up less precisely.

A second misconception is the matter of rich results. Correct markup is the prerequisite for enhanced search results, but no guarantee. Search engines decide themselves whether and when they show a rich display. You supply the clean data basis – the display remains outside your control. Disappointment only arises when you expect this wrongly.

And never mark up things that are not visible on the page. Reviews that don't exist, prices that aren't correct, events long past: such markup violates the guidelines and can lead to manual penalties. The rule is simple – your schema describes only what people actually see on the page.

• Not a ranking booster, but an understanding aid for machines
• Rich results are possible, but never guaranteed
• Only mark up what is visible on the page
• False reviews or prices risk penalties