Strukturierte Daten & Maschinenlesbarkeit

Das lernst du in dieser Lektion

Du verstehst, wie strukturierte Daten zu Rich Results in Suchmaschinen führen.
Du kannst Article, FAQPage und BreadcrumbList als JSON-LD auszeichnen.
Du kennst Microdata als Alternative und kannst begründen, wann welcher Weg passt.
Du grenzt data-Attribute und time/datetime sauber von strukturierten Daten ab.

Dein wichtigster Besucher hat keine Augen. Der Crawler einer Suchmaschine sieht keine Farben und keine Bilder – er liest deinen Quelltext und versucht zu verstehen, was deine Seite bedeutet. Gutes semantisches HTML hilft ihm dabei schon enorm. Aber es gibt eine Ausbaustufe: strukturierte Daten, mit denen du Suchmaschinen wörtlich sagst: „Das hier ist ein Rezept, es dauert 45 Minuten und wurde mit 4,8 Sternen bewertet.“ Die Belohnung siehst du täglich in den Suchergebnissen – Bewertungssterne, aufklappbare FAQs, lesbare Breadcrumb-Pfade. In dieser Lektion lernst du, wie du dir solche Rich Results verdienst.

Warum Maschinenlesbarkeit belohnt wird

Semantisches HTML sagt einer Maschine, dass etwas ein Artikel ist – aber nicht, wovon er handelt, wer ihn wann geschrieben hat oder wie ein Produkt bewertet wurde. Genau diese Lücke schließen strukturierte Daten: zusätzliche, für Menschen unsichtbare Angaben in einem Format, das Suchmaschinen garantiert verstehen.

Suchmaschinen belohnen diese Mühe mit Rich Results („angereicherten Suchergebnissen“): Bewertungssterne unter dem Treffer, direkt in der Ergebnisliste aufklappbare FAQ-Antworten, Brotkrumen-Pfade statt kryptischer URLs, Rezeptkarten mit Bild und Kochzeit. Solche Treffer fallen auf, werden nachweislich häufiger geklickt – und sind ohne strukturierte Daten schlicht nicht zu haben. Eine Garantie gibt es allerdings nicht: Die Suchmaschine entscheidet von Fall zu Fall, ob sie ein Rich Result anzeigt. Ohne Auszeichnung liegt die Chance aber bei null.

Damit dabei alle dieselbe Sprache sprechen, gibt es schema.org: ein gemeinsames Vokabular, das die großen Suchmaschinen 2011 gemeinsam ins Leben gerufen haben. Es definiert hunderte Typen (Article, Product, Recipe, Event, LocalBusiness …) mit jeweils passenden Eigenschaften. Im Alltag brauchst du nur eine Handvoll davon – aber für praktisch jeden Inhalt existiert ein passender Typ.

Übrigens lesen längst nicht mehr nur Suchmaschinen mit: Auch KI-Assistenten, Preisvergleichsdienste und soziale Netzwerke greifen auf strukturierte Daten zurück, wenn sie deine Seite zusammenfassen oder als Vorschau darstellen. Wer heute maschinenlesbar schreibt, wird morgen öfter zitiert.

JSON-LD: der empfohlene Weg

Für die technische Umsetzung haben sich zwei Formate durchgesetzt. Das erste – und von Google ausdrücklich empfohlene – ist JSON-LD (JSON for Linked Data). Die Idee: Du legst einen kleinen Datenblock im JSON-Format in ein <script type="application/ld+json">-Element, meist im <head>. Der Browser führt diesen Block nicht aus und zeigt ihn nicht an – er ist ausschließlich Post an die Maschinen. Der große Vorteil: Die Daten leben getrennt vom Markup. Du kannst sie pflegen, automatisch generieren oder austauschen, ohne eine einzige Zeile deines sichtbaren HTML anzufassen.

Zwei Schlüssel tauchen in jedem JSON-LD-Block auf: @context nennt das Vokabular (praktisch immer https://schema.org) und @type den Typ des Dings, das du beschreibst. Alles Weitere sind Eigenschaften dieses Typs. Drei Beispiele decken die häufigsten Fälle ab – zuerst der Klassiker, ein Artikel:

JSON-LD für einen Artikel

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Sauerteigbrot für Einsteiger",
  "description": "Schritt für Schritt zum ersten selbst gebackenen Sauerteigbrot.",
  "author": {
    "@type": "Person",
    "name": "Jana Berg"
  },
  "datePublished": "2026-07-01",
  "dateModified": "2026-07-10"
}
</script>

Für Frage-Antwort-Seiten existiert der Typ FAQPage: Jedes Paar wird als Question mit einer acceptedAnswer beschrieben. Genau daraus baut die Suchmaschine die aufklappbaren Antworten direkt in der Ergebnisliste:

JSON-LD für eine FAQ-Seite

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Wie lange muss Sauerteig reifen?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Ein frisch angesetzter Sauerteig braucht etwa 5 bis 7 Tage, bis er backfähig ist."
      }
    },
    {
      "@type": "Question",
      "name": "Kann ich Sauerteig einfrieren?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Ja, eingefroren hält er mehrere Monate. Vor dem Backen zwei Tage lang wieder auffrischen."
      }
    }
  ]
}
</script>

Und die BreadcrumbList beschreibt den Navigationspfad zur aktuellen Seite. Suchmaschinen zeigen dann statt der rohen URL einen lesbaren Pfad wie „Backstube › Rezepte › Brot“ an – das dritte klassische Rich Result:

JSON-LD für eine Breadcrumb-Navigation

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Backstube",
      "item": "https://www.backstube-beispiel.de/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Rezepte",
      "item": "https://www.backstube-beispiel.de/rezepte/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Brot",
      "item": "https://www.backstube-beispiel.de/rezepte/brot/"
    }
  ]
}
</script>

Drei Blöcke, ein Muster: @context, @type, Eigenschaften. Mehrere JSON-LD-Blöcke dürfen problemlos auf derselben Seite stehen – ein Artikel mit FAQ-Teil bekommt eben einen Article- und einen FAQPage-Block. Wichtig ist nur, dass jeder Block beschreibt, was auf genau dieser Seite tatsächlich zu sehen ist: Die headline entspricht der sichtbaren Überschrift, das Datum dem angezeigten Veröffentlichungsdatum. Strukturierte Daten sind ein Spiegel der Seite – keine zweite Wahrheit neben ihr.

Microdata: Auszeichnung direkt im Markup

Der zweite Weg ist Microdata: Statt eines separaten Datenblocks reicherst du dein vorhandenes Markup mit Attributen an. Drei davon musst du kennen: itemscope erklärt ein Element zum „Ding“, itemtype nennt dessen schema.org-Typ, und itemprop markiert einzelne Eigenschaften – deren Werte kommen direkt aus dem sichtbaren Inhalt der Elemente:

Ein Produkt als Microdata – die Daten stecken im sichtbaren Text

<article itemscope itemtype="https://schema.org/Product">
  <h2 itemprop="name">Klapprad X200</h2>
  <p itemprop="description">
    In 15 Sekunden gefaltet – Bestwert der Preisklasse.
  </p>
  <p itemscope itemprop="offers"
     itemtype="https://schema.org/Offer">
    Preis: <span itemprop="price" content="899.00">899 €</span>
    <meta itemprop="priceCurrency" content="EUR">
  </p>
</article>

Der Charme: Daten und sichtbarer Inhalt können nicht auseinanderlaufen, denn sie sind dieselbe Textstelle. Der Preis dafür ist verwobenes Markup: Sobald du dein HTML umbaust, musst du höllisch aufpassen, keine itemprop-Kette zu zerreißen – und bei verschachtelten Typen wie dem Offer oben wird es schnell unübersichtlich. In der Praxis lautet die ehrliche Empfehlung deshalb: Nimm JSON-LD. Es ist wartbarer, lässt sich zentral erzeugen (etwa von einem CMS) und ist das Format, das Google selbst empfiehlt. Microdata solltest du lesen können – schreiben wirst du fast immer JSON-LD.

Im Editor unten kannst du das Prinzip live erleben: Der sichtbare Text ist hier der Datenwert. Änderst du den Rezeptnamen, ändert sich automatisch auch das, was eine Maschine ausliest – beides bleibt zwangsläufig synchron:

Probier es ausÄndere den Code – die Vorschau aktualisiert sich sofort.

<article itemscope itemtype="https://schema.org/Recipe">
  <h2 itemprop="name">Omas Apfelkuchen</h2>
  <p>Ein Rezept von
     <span itemprop="author">Greta Sommer</span></p>
  <p itemprop="description">Saftiger Klassiker mit Zimt –
     gelingt auch Anfängern.</p>
  <p>Backzeit:
     <time itemprop="cookTime" datetime="PT45M">45 Minuten</time>
  </p>
</article>

<p>Ändere Rezeptname oder Autorin: Der sichtbare Text
IST hier der Datenwert.</p>

Abgrenzung: data-Attribute sind Privatsache

Ein häufiges Missverständnis gehört an dieser Stelle ausgeräumt: Die data-*-Attribute, die dir vielleicht schon begegnet sind, haben mit strukturierten Daten nichts zu tun. Ein data-produkt-id="4711" auf einem Kaufen-Knopf ist eine private Notiz deiner Seite an ihr eigenes JavaScript oder CSS – etwa damit ein Skript beim Klick weiß, welches Produkt in den Warenkorb soll. Suchmaschinen ignorieren data-*-Attribute mit voller Absicht: Ihr Inhalt ist frei erfunden, folgt keinem gemeinsamen Vokabular und ist deshalb für Dritte bedeutungslos.

Am anderen Ende der Skala steht die kleinste Form der Maschinenlesbarkeit, die du längst kennst: <time datetime="2026-07-13">13. Juli</time>. Das datetime-Attribut übersetzt eine menschliche Datumsangabe in ein genormtes Format – strukturierte Daten im Miniaturformat, direkt in den HTML-Standard eingebaut. Merke dir die Staffelung: time für einzelne Zeitangaben, JSON-LD oder Microdata für ganze Dinge mit vielen Eigenschaften, data-* ausschließlich für interne Zwecke.

Testen – und die goldene Regel

Strukturierte Daten sind unsichtbar – umso wichtiger ist das Testen. Zwei Werkzeuge solltest du dir merken (du findest beide über eine kurze Suche): Der Google Rich-Results-Test prüft eine URL oder einen Code-Schnipsel und zeigt, für welche Rich Results die Seite infrage kommt. Der Schema.org-Validator prüft unabhängig vom Anbieter, ob deine Auszeichnung dem Vokabular entspricht. Beide nennen dir Fehler und fehlende Pflicht-Eigenschaften konkret beim Namen – mach den Test zur festen Gewohnheit nach jeder Änderung.

Ein bewährter Arbeitsablauf sieht so aus: Zuerst schaust du auf schema.org nach, welcher Typ zu deinem Inhalt passt und welche Eigenschaften für ein Rich Result mindestens erwartet werden. Dann schreibst du den JSON-LD-Block, prüfst ihn im Rich-Results-Test und behebst die gemeldeten Punkte. Und nach jedem Relaunch oder größeren Umbau wiederholst du den Test – gerade bei Microdata reißt eine harmlos wirkende Markup-Änderung schnell eine Eigenschaft ab, ohne dass es jemandem auffällt.

Zusammenfassung

Strukturierte Daten übersetzen deine Inhalte in das gemeinsame Vokabular von schema.org – die Belohnung sind Rich Results wie Sterne, FAQs und Breadcrumbs.
JSON-LD ist der empfohlene Weg: ein unsichtbarer Datenblock in <script type="application/ld+json">, sauber getrennt vom Markup.
Microdata (itemscope, itemtype, itemprop) lebt direkt im Markup – funktioniert, ist aber deutlich schwerer zu warten.
data-*-Attribute sind private Daten für dein eigenes JavaScript – Suchmaschinen ignorieren sie bewusst; time/datetime ist die kleinste eingebaute Form der Maschinenlesbarkeit.
Teste mit Rich-Results-Test und Schema.org-Validator – und zeichne nur aus, was sichtbar auf der Seite steht.

Deine Seiten sind jetzt semantisch, barrierefrei und maschinenlesbar. In der letzten Lektion des Kurses bringen wir sie auf Tempo: „Performance & Best Practices“ zeigt dir, warum ausgerechnet HTML der größte Performance-Hebel ist – und schnürt zum Abschluss die große Checkliste für professionelles HTML.

Weiter: Performance & professionelles HTML →