Structured data: standing out in search results

Structured data is, at its core, a translation exercise. A person reading a service page understands that a company installs solar systems in the Hildesheim region, is reachable on weekdays from eight to five and works within a certain price range. A program initially reads nothing but a sequence of words. Markup puts those same details into a fixed schema and labels them: this is the company name, this is the postal address, these are the opening hours, this is a service on offer. The practice is now widespread. In the analysis published by the Google Web Almanac on the basis of the HTTP Archive, around 41 percent (Google Web Almanac, Structured Data chapter) of the mobile pages examined shipped JSON-LD markup, and around 26 percent (Google Web Almanac, Structured Data chapter) used microdata inside the markup itself. The underlying vocabulary offers more than 800 types (schema.org vocabulary), far more than any single company will ever need, since in practice a handful of them covers the ground.

The opposite direction matters just as much, and proposals tend to skip over it. Structured data is not a ranking factor in the narrow sense, and it replaces neither substantial content nor a sound technical basis. It does not decide whether a page is found at all; it decides whether the page is eligible for enriched result formats. Whether a search engine then actually shows such a format remains its own decision, taken afresh for every query, and there are no dependable promises to be made at this point. Marking up a slow, thin page therefore tends to produce a slow, thin page with accurately labelled metadata. The order stays the same: substance and technology first, markup second. Why the delivery model weighs more heavily than many detail optimisations is covered in the article on PageSpeed and static delivery.

The most common misconception is that structured data is a one-off setting for an entire website. In reality the right markup depends on the page type. A home page describes the company, a service page describes the service and the area it covers, an article describes the text with author and date, a contact page describes how to get in touch. Copying the same block across every page ends with the same company described fifty times and not a single service. Around 88 percent (Federal Statistical Office of Germany, survey on the use of information and communication technologies in enterprises) of companies in Germany run a website of their own, so the difference in search results rarely comes from having a site at all. It comes from how precisely that site describes its content. The structure of the pages therefore decides how much the markup can contribute in the first place, which is a good reason to plan structure and content together, as the overview of what XICflow offers describes. The following mapping covers the page types that appear in most business websites.

Search engine guidelines are unambiguous on this point: only content that visitors actually find on the page may be marked up. Declaring twelve FAQ entries when three of them appear on the page breaks that basic rule. The same applies to services described nowhere, to addresses with no counterpart in the imprint and to dates that exist only in the record. Possible consequences range from the markup being quietly ignored to a manual action that suspends enriched formats for the whole domain. The visibility requirement has a practical consequence: the content belongs in a section that people can operate. An expandable FAQ section is permitted, but it has to be reachable by keyboard and report its state correctly — exactly the requirements covered in the article on accessibility under the European Accessibility Act and WCAG 2.2. Markup and accessibility pull in the same direction here: both reward content that is clearly structured and genuinely present.

Reviews deserve particular care, and not only from a search engine perspective. Since the German implementation of the European modernisation directive, Section 5b(3) of the Act against Unfair Competition (UWG) requires companies that make consumer reviews accessible to state whether and how they ensure that those reviews come from people who actually used the service. Items 23b and 23c in the annex to Section 3(3) UWG classify fake reviews and unsubstantiated authenticity claims as unfair commercial practices. For markup that means stars in a search result are not a design element but a statement of fact. Only reviews that were genuinely collected, that can be inspected on the page and whose origin is explained should be marked up. Setting an average score because it looks appealing in the result invites competition law claims on top of losing the display.

Structured data rarely fails spectacularly. It fails quietly: one comma too many, one field with the wrong data type, one date in the wrong format, and the whole block is discarded without anything on the page looking different. That is why validation belongs in the publishing process rather than in the category of occasional checks. It matters that the check happens in the HTML that is actually delivered, not in the preview of an editing tool. When a page is delivered statically, the markup sits unchanged in the file that visitors receive, which makes the check unambiguous. A second point concerns images: if the markup references a file, that file has to exist in the stated resolution, which makes the article on image formats and alt text worth a look. These seven steps have proven themselves as a sequence:

In XICflow the markup is not hand-written into a template; it follows from the page configuration. Every page has a type, and that type determines the matching record: the home page describes the business, a service page describes the service, an article describes the text with author and date, an FAQ section describes its question and answer pairs, and every subpage additionally carries its breadcrumb trail. The master data behind it is maintained once and feeds the footer, the contact page and the legal pages at the same time, so a changed opening hour takes effect everywhere instead of having to be tracked down in four places. Because pages are delivered statically, the block sits unchanged in the delivered file and can be inspected right there. How the path from briefing to finished site works is shown in the overview of how XICflow works, and what the result looks like across different industries can be explored in the demo websites.

Two edge cases deserve a final mention because they are regularly overlooked in day-to-day maintenance. The first is multilingual delivery: each language version needs its own record with the translated paths and the matching language declaration, otherwise the English page describes the German content. How language versions work together cleanly is set out in the article on multilingual sites and hreflang. The second is the relaunch: when paths change, the references inside the record keep pointing at the old targets. Redirects catch the visitors, but the markup itself should be switched to the new paths. Which steps take effect in which order is described in the article on relaunching without losing rankings.