Zum Inhalt springen
SilktideHilfe

Structured data markup

Structured data is a machine-readable description of what a page contains, embedded in the page itself. Instead of leaving a search engine or AI assistant to guess from your layout that this page is a product with a price, or an article by a named author updated last week, you state it outright, in a standardized vocabulary (schema.org) and format () that every major engine parses.

The markup is a small script block, invisible to visitors:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to reconcile corporate card statements",
  "datePublished": "2026-05-01T09:00:00Z",
  "dateModified": "2026-07-10T14:30:00Z",
  "author": { "@type": "Person", "name": "Maria Chen" }
}
</script>

Throughout this page, suppose you run Fernwood, an expense-management product with a marketing site, a blog, and a pricing page.

Why it works

Machines reading your pages face an extraction problem: your content is written for humans, and everything a machine wants to know - who published this, when, what it costs, what kind of thing it is - has to be inferred from layout and prose. Structured data removes the inference. That pays off three ways:

  • Identity and trust. An Organization entity with links to your verified profiles lets an engine confirm that fernwood.com, the Fernwood on LinkedIn, and the Fernwood being reviewed on G2 are the same company. Answer engines weight identity confidence when deciding whether to cite you - a source they cannot pin down is a source they hedge about.
  • Freshness. datePublished and dateModified are the strongest machine-readable freshness signals a page can carry, and freshness is weighted heavily in both ranking and citation. This matters enough to be its own technique: Machine-readable dates.
  • Accurate extraction and rich results. Declared facts get quoted correctly - a price in an Offer is unambiguous in a way a price in a paragraph is not. In classic search, several types still earn enhanced listings (rich results): product prices and ratings, breadcrumbs, event details, job postings.

Be clear-eyed about what it does not do: structured data is not a ranking magic word, and Google has been steadily retiring the cosmetic rewards - FAQ rich results were restricted in 2023 and stopped appearing entirely in May 2026, and HowTo rich results were deprecated in 2023. The durable value has shifted from decorating search listings to being legible to answer engines - which is exactly the audience that is growing.

Where to invest

Do not try to mark up everything. Each type below earns its keep on a specific kind of page; a page with nothing to declare can honestly go without.

TypeWhereThe fields that matter
OrganizationSitewide (homepage or every page)name, url, logo, sameAs
Article / BlogPostingBlog posts, guides, newsheadline, datePublished, dateModified, author
Product + OfferProduct and pricing pagesname, description, offers.price, offers.priceCurrency
LocalBusinessLocation pagesname, address, openingHours, telephone
BreadcrumbListAny page in a hierarchyitemListElement - your navigation path
WebSiteHomepagename, url - declares your site name

FAQPage deserves a special note because it was cargo-culted onto everything for years: the Google rich result it used to earn is gone, so add it only where a page genuinely is a set of questions and answers - it still helps machines parse that structure, but it no longer buys placement.

How to do it

1. Prefer your CMS or plugin over hand-writing

Most platforms and SEO plugins (Yoast, Rank Math, and equivalents) already generate Organization, Article, and breadcrumb markup from data they hold - the fix is usually configuration, not code. This is the right default because hand-maintained markup drifts: the page gets edited, the script block does not, and now your markup lies.

If you build your own templates, generate the markup in the template from the same source of truth as the visible content - the article's byline and the author field should come from the same database column.

2. Use JSON-LD, connected into a graph

Google recommends JSON-LD over the older microdata and RDFa formats, and it is the format to standardize on: it lives in one block, separate from your HTML structure, so template changes cannot silently break it.

Entities can reference each other. On a Fernwood blog post, the article, its author, and the publishing organization belong together:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://fernwood.example/#org",
      "name": "Fernwood",
      "url": "https://fernwood.example/",
      "logo": "https://fernwood.example/assets/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/fernwood-example",
        "https://github.com/fernwood-example"
      ]
    },
    {
      "@type": "BlogPosting",
      "headline": "How to reconcile corporate card statements",
      "datePublished": "2026-05-01T09:00:00Z",
      "dateModified": "2026-07-10T14:30:00Z",
      "author": {
        "@type": "Person",
        "name": "Maria Chen",
        "sameAs": ["https://www.linkedin.com/in/maria-chen-example"]
      },
      "publisher": { "@id": "https://fernwood.example/#org" }
    }
  ]
}
</script>

The @id reference means you describe your organization once and point to it, instead of repeating slightly different copies of it on every page - inconsistent copies are how engines end up unsure which version to believe.

On the pricing page, declare the product the way you would want an assistant to repeat it:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Fernwood",
  "description": "Expense management with multi-entity approval workflows.",
  "brand": { "@id": "https://fernwood.example/#org" },
  "offers": {
    "@type": "Offer",
    "price": "12.00",
    "priceCurrency": "USD",
    "url": "https://fernwood.example/pricing"
  }
}
</script>

3. Follow the honesty rules

Google's structured data policies are the codified version of common sense, and violating them gets markup ignored or the site penalized:

  • The markup must describe content visible on the page. Declaring an aggregateRating for reviews that appear nowhere on the page, or marking up content the visitor cannot see, is treated as spam.
  • It must be current. An Offer price that no longer matches your pricing page is a contradiction the engine resolves by distrusting the markup - and pricing is the field assistants most love to quote.
  • Self-serving reviews don't count. Marking up your own testimonials as independent Review entities of yourself is explicitly against Google's review snippet rules, and is the on-page cousin of astroturfing.

4. Validate before and after publishing

Broken structured data fails silently - the page looks fine, the engine discards the block, and nothing tells you. Validate with the Rich Results Test (Google's eligibility view) and the Schema Markup Validator (vocabulary correctness), and re-validate when templates change. The usual killers are trailing commas, unescaped quotes, and template placeholders that never got replaced.

How Silktide helps

Silktide tests this technique from four angles across the site:

  • Structured data finds indexable pages carrying no structured data at all, so you can decide which of them should.
  • Structured data validity catches the silent failures: blocks that do not parse, entities with no @type, and types missing their required properties.
  • AI schema signals checks that the schema you already publish includes the fields answer engines lean on hardest - dateModified on articles and sameAs on organizations.
  • Content dates flags substantial pages that declare no dates in any machine-readable form.

Silktide's AEO reports additionally judge whether your structured data matches the page it sits on - the honesty rule, tested.

Zuletzt aktualisiert

War diese Seite hilfreich?