Article Schema: Strukturierte Daten für Fachartikel richtig einsetzen

Ein Kunde hatte vor unserer Zusammenarbeit ein WordPress-Plugin installiert, das automatisch Article-Markup auf jede Seite legte – inklusive der Kontaktseite und einer PDF-Landingpage ohne echten Fließtext. Das Markup war technisch valide. Es widersprach nur komplett dem, was auf der Seite tatsächlich stand. Genau dieses Muster sehe ich häufig: Strukturierte Daten werden als Ranking-Hebel behandelt, den man „einfach dazuschaltet”, statt als das, was sie sind – eine maschinenlesbare Zusammenfassung von Inhalten, die ohnehin sichtbar sein müssen.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die Fachartikel, Blogbeiträge oder Wissensseiten veröffentlichen und wissen wollen, wie Article-Schema korrekt eingesetzt wird – ohne Illusionen über das, was es bewirkt, aber mit den konkreten technischen Details, die in den meisten Anleitungen zu kurz kommen.

Begriffe kurz geklärt

Strukturierte Daten sind ein standardisiertes Format (meist JSON-LD), mit dem eine Seite Suchmaschinen zusätzliche, maschinenlesbare Informationen über ihren Inhalt liefert – zum Beispiel: „Dies ist ein Artikel, geschrieben von X, veröffentlicht am Y.”

Schema.org ist das gemeinsame Vokabular, auf das sich Google, Bing und andere Suchmaschinen geeinigt haben. Es definiert Typen (wie Article) und deren Properties (wie headline oder author).

Rich Result ist die erweiterte Darstellung eines Suchergebnisses – etwa mit Vorschaubild, Datum oder Autorenname direkt in der Trefferliste. Strukturierte Daten sind eine Voraussetzung für bestimmte Rich Results, aber keine Garantie dafür; Google entscheidet pro Anfrage neu, ob und wie ein Rich Result angezeigt wird.

JSON-LD (JavaScript Object Notation for Linked Data) ist das von Google empfohlene Format, um schema.org-Markup in eine Seite einzubetten – als eigenständiger <script type="application/ld+json">-Block, unabhängig vom sichtbaren HTML.

Wichtig zur Abgrenzung: Article-Schema ist kein Ranking-Faktor im klassischen Sinn. Google bestätigt in der eigenen Dokumentation zu strukturierten Daten und KI-Suche ausdrücklich, dass strukturierte Daten für generative KI-Suche nicht erforderlich sind und es kein spezielles Markup gibt, das man dafür „hinzufügen muss”. Was Markup tut, ist etwas Bescheideneres: Es macht explizit, was im Text ohnehin steht, und erhöht die Chance, dass diese Information korrekt und mit Zusatzelementen dargestellt wird.

Welche Article-Typen gibt es?

Schema.org und Google unterstützen im Article-Kontext drei Typen, die in einer Hierarchie zueinanderstehen:

• Article – der generische Basistyp für redaktionelle Inhalte aller Art. Passt für Ratgeber, Fachbeiträge, Whitepaper-Zusammenfassungen und alles, was sich nicht eindeutig als News oder Blogpost einordnen lässt.
• NewsArticle – eine Unterklasse von Article, gedacht für nachrichtliche, zeitkritische Inhalte, wie sie klassische Redaktionen produzieren. Für die meisten B2B-Wissensartikel ist dieser Typ nicht passend, weil er journalistische Aktualität suggeriert, die ein Ratgeberartikel nicht hat.
• BlogPosting – ebenfalls eine Unterklasse von Article, für Blog- und Wissensartikel wie den, den du gerade liest. In der Praxis der naheliegendste Typ für Content-Marketing- und Wissensseiten von KMU.

Die Dokumentation von Google behandelt alle drei Typen im selben Leitfaden und macht keinen Unterschied in der Auswertung, der für die Typwahl entscheidend wäre – die Wahl richtet sich in erster Linie nach dem, was inhaltlich korrekt ist. Ein falsch gewählter Typ ist selten das größere Problem; problematischer ist unvollständiges oder vom sichtbaren Inhalt abweichendes Markup, unabhängig vom gewählten Typ.

Für eine reine Wissens- oder Ratgeberseite ohne redaktionellen Nachrichtencharakter ist BlogPosting in der Regel die naheliegende Wahl; für eine gemischte Content-Sektion mit sowohl Ratgebern als auch Presse-/News-Meldungen lohnt sich eine bewusste Trennung nach Inhaltstyp.

In der Praxis sehe ich häufig den Fehler, dass ein CMS pauschal einen einzigen Typ für alle Inhaltsformate ausgibt – Produktseiten, Landingpages und redaktionelle Artikel bekommen dasselbe Article-Markup, weil das Template es „schon immer so” macht. Das ist genau die Art von generischem, nicht auf den Inhalt abgestimmtem Einsatz, die Googles Richtlinien für strukturierte Daten als Relevanzproblem beschreiben: Markup muss zum tatsächlichen Seiteninhalt passen, nicht zur Bequemlichkeit der Implementierung.

Welche Eigenschaften sind wichtig?

Eine Besonderheit, die viele Anleitungen unterschlagen: Google definiert für Article-Markup formal keine Pflichtfelder. Die offizielle Dokumentation formuliert es so: Es gibt keine erforderlichen Properties – stattdessen sollen die Properties ergänzt werden, die für den jeweiligen Inhalt zutreffen. Das klingt nach Freiheit, ist in der Praxis aber eine Falle: Ohne bestimmte Felder gibt es schlicht kein Rich Result, das Google eventuell anzeigen könnte. Die folgenden fünf Properties solltest du deshalb wie Pflichtfelder behandeln, auch wenn sie es formal nicht sind:

Property	Zweck	Typische Stolperfalle
headline	Artikeltitel	Zu lang gewählte Headlines werden von Google gekürzt dargestellt
image	Vorschaubild(er)	Bild zu klein, nicht crawlbar oder falsches Seitenverhältnis
datePublished	Veröffentlichungsdatum	Fehlendes Zeitzonen-Format oder falsches Datumsformat
dateModified	Letzte Aktualisierung	Wird gesetzt, aber nie wieder aktualisiert – wirkt dann irreführend
author	Autor:in oder Organisation	Nur ein Name-String statt vollständigem Objekt mit Identifikationslink

Darüber hinaus sind je nach Inhalt weitere Properties sinnvoll, etwa publisher (die herausgebende Organisation) oder mainEntityOfPage, die auf die kanonische URL des Artikels verweist. Sie sind nicht Kern des Minimalsets, ergänzen aber ein sauberes, vollständiges Markup.

Wie werden Autor und Datum angegeben?

Hier liegt der Detailteufel, den ich in Audits am häufigsten finde. Google stellt für author konkrete Anforderungen:

• Struktur: Autor:innen werden als eigenständiges Objekt angegeben, nicht als reiner Text-String. Bei mehreren Autor:innen gehört jede Person in ein eigenes author-Feld – nicht als kombinierter String wie "Anna Muster und Ben Beispiel".
• Typ: Jedes author-Objekt bekommt ein @type, entweder Person (für individuelle Autor:innen) oder Organization (wenn ein Unternehmen als Herausgeber auftritt, ohne benannte Einzelperson).
• Name: author.name enthält nur den Klarnamen, ohne Titel oder Präfixe wie „Dr.” oder „Autor:”.
• Identifikation: author.url oder author.sameAs verlinkt auf eine Seite, die die Autor:innenidentität bestätigt – etwa eine Autorenseite auf der eigenen Domain oder ein verifiziertes Profil.

Bei Datumsangaben gilt: datePublished und dateModified werden im ISO-8601-Format angegeben, empfohlen mit Zeitzone (z. B. 2026-07-17T09:00:00+02:00). dateModified trägst du nur dann ein, wenn sich der Inhalt tatsächlich substanziell geändert hat – ein Artikel, dessen dateModified bei jedem CMS-Speichervorgang automatisch mitläuft, ohne dass sich am Text etwas ändert, erzeugt genau die Art von irreführendem Signal, die Googles Richtlinien für strukturierte Daten ausdrücklich untersagen.

Was muss sichtbar sein?

Das ist die wichtigste und am häufigsten verletzte Regel: Google formuliert es unmissverständlich – Markup darf nicht für Inhalte gesetzt werden, die für Leser:innen der Seite nicht sichtbar sind. Das bedeutet konkret:

• Wenn im JSON-LD ein author mit Namen steht, muss dieser Name auch im sichtbaren Artikeltext oder in der Byline auftauchen – nicht nur im Code.
• Wenn datePublished gesetzt ist, sollte ein Veröffentlichungsdatum auch für Leser:innen erkennbar sein, typischerweise im Artikelkopf.
• Das im image-Feld angegebene Bild sollte das tatsächliche, im Artikel verwendete Titelbild sein – nicht ein beliebiges Stock-Foto, das nirgendwo im sichtbaren Layout vorkommt.
• Die headline sollte inhaltlich mit der sichtbaren Überschrift (H1) übereinstimmen, auch wenn sie technisch nicht identisch sein muss.

Der Grund dieser Regel ist keine Formalie. Googles allgemeine Richtlinien für strukturierte Daten verlangen, dass Markup „a true representation of the page content” ist – eine wahrheitsgemäße Abbildung dessen, was auf der Seite tatsächlich steht. Verstöße dagegen zählen zu den Praktiken, die Google explizit als „to deceive or mislead users” beschreibt und die zum Entzug der Rich-Result-Berechtigung führen können. Der eingangs erwähnte Fall – Article-Markup auf einer Kontaktseite ohne Artikeltext – ist ein Lehrbuchbeispiel für genau diesen Fehler.

Wie validiert man JSON-LD?

Validierung läuft in der Praxis auf zwei Ebenen, die häufig verwechselt werden:

1. Syntaxprüfung. Ist das JSON-LD überhaupt valides JSON? Ein fehlendes Komma oder eine offene Klammer reicht, damit der gesamte Block von Suchmaschinen ignoriert wird. Ein einfacher JSON-Linter (auch im Browser-Devtools über JSON.parse() möglich) findet solche Fehler sofort.
2. Schema-Konformitätsprüfung. Werden die richtigen Typen und Properties erkannt, so wie sie schema.org und Google definieren? Dafür gibt es dedizierte Struktur­daten-Testtools, die den <script type="application/ld+json">-Block einer URL oder eines HTML-Schnipsels einlesen und anzeigen, welche Properties erkannt wurden, welche fehlen und ob Warnungen vorliegen.

Ein Punkt, der in der Praxis öfter übersehen wird als er sollte: Immer die ausgelieferte, gerenderte Seite testen, nicht nur den Quellcode im CMS-Editor. Bei Frameworks mit clientseitigem Rendering kann der Zustand, den ein Bot beim Crawlen sieht, vom Template-Code abweichen – etwa wenn JSON-LD per JavaScript nachträglich eingefügt wird und das Rendering fehlschlägt. Google weist in den allgemeinen Richtlinien für strukturierte Daten zudem darauf hin, dass Seiten mit strukturierten Daten nicht per robots.txt, noindex oder anderen Zugriffssperren blockiert werden dürfen – sonst wird das validierte Markup nie ausgewertet, egal wie sauber es ist.

Eigenes Template: Minimal-JSON-LD für Article-Markup

Als reproduzierbare Vorlage – abgeleitet aus den oben beschriebenen Anforderungen, keine Kopie einer Quelle – hier ein Minimalbeispiel mit Erklärung jedes Felds:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Kurzer, prägnanter Titel (max. ~110 Zeichen)",
  "image": [
    "https://example.de/bilder/artikel-16x9.jpg",
    "https://example.de/bilder/artikel-4x3.jpg",
    "https://example.de/bilder/artikel-1x1.jpg"
  ],
  "datePublished": "2026-07-17T09:00:00+02:00",
  "dateModified": "2026-07-17T09:00:00+02:00",
  "author": [
    {
      "@type": "Person",
      "name": "Vorname Nachname",
      "url": "https://example.de/ueber-uns/vorname-nachname/"
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "Firmenname",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.de/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.de/artikel-slug/"
  }
}

Erklärung der Felder – was Pflicht, was Kür ist:

Feld	Status	Praxis-Hinweis
@type	Auswahl treffen	Article, NewsArticle oder BlogPosting – siehe Abschnitt zu den Typen
headline, image, datePublished, author	faktisch unverzichtbar	Ohne diese vier entsteht kein Rich Result
dateModified	unverzichtbar bei Updates	Nur bei echter inhaltlicher Änderung aktualisieren
publisher	empfohlen	Wichtig, wenn ein Unternehmen als Herausgeber auftritt
mainEntityOfPage	empfohlen	Verweist auf die kanonische URL, vermeidet Mehrdeutigkeit bei mehreren URLs mit ähnlichem Inhalt
author.url/sameAs	faktisch unverzichtbar	Ohne Identifikationslink ist die Autor:innenangabe für Google schwerer verifizierbar

Umsetzung: reproduzierbare Schrittfolge

Aus Projekten hat sich bei mir folgende Reihenfolge bewährt, wenn Article-Markup neu eingeführt oder überarbeitet wird:

1. Inhaltstyp klären. Entscheiden, ob Inhalte als Article, NewsArticle oder BlogPosting typisiert werden – pro Content-Kategorie, nicht pro Einzelseite, damit die Entscheidung konsistent bleibt.
2. Datenquelle pro Feld festlegen. Für jedes Property (Headline, Bild, Datum, Autor) definieren, aus welchem CMS-Feld es automatisch befüllt wird. Manuell nachgepflegtes Markup verwaist erfahrungsgemäß nach wenigen Monaten.
3. Autorenobjekte vorbereiten. Für jede Autor:in ein festes Person-Objekt mit Name und URL zu einer Autorenseite anlegen – einmalig, dann wiederverwendbar für alle Artikel dieser Person.
4. Template implementieren. JSON-LD serverseitig rendern (nicht nachträglich per Client-JavaScript einfügen), damit Crawler das Markup zuverlässig sehen.
5. Sichtbarkeitsabgleich prüfen. Für eine Stichprobe von Artikeln manuell vergleichen: Stimmt jedes Feld im JSON-LD mit einem sichtbaren Element auf der Seite überein?
6. Syntaktisch validieren. JSON-Syntax mit einem Linter prüfen – vor dem Deployment, nicht danach.
7. Schema-konform validieren. Die ausgelieferte, gerenderte Live-URL mit einem strukturierte-Daten-Testtool prüfen, Warnungen und fehlende empfohlene Felder auswerten.
8. Stichproben-Monitoring etablieren. Nach dem Rollout regelmäßig (z. B. quartalsweise) eine Stichprobe neuer und alter Artikel erneut validieren – neue CMS-Felder, Template-Änderungen oder Plugin-Updates brechen Markup erfahrungsweise öfter, als man erwartet.

Dieser letzte Punkt wird am häufigsten übersehen: Strukturierte Daten sind kein Projekt, das man einmal abschließt, sondern ein Bestandteil des laufenden Content-Prozesses, wie er auch in unserem Artikel zum SEO-Content-Prozess eine Rolle spielt.

Risiken & Grenzen

Ein paar Dinge, die du realistisch einordnen solltest, bevor du Zeit in Article-Markup investierst:

• Kein Ranking-Hebel. Strukturierte Daten sind kein direkter Ranking-Faktor. Google bestätigt in der eigenen Dokumentation zur KI-optimierten Suche ausdrücklich, dass strukturierte Daten für generative KI-Suche nicht erforderlich sind. Wer sich Rankingverbesserungen von Markup allein verspricht, wird enttäuscht.
• Keine Garantie für Rich Results. Auch vollständiges, valides Markup führt nicht automatisch zu einer erweiterten Darstellung in den Suchergebnissen – Google entscheidet situativ, ob und wie ein Rich Result angezeigt wird.
• Fehlerhaftes Markup kann schaden. Markup, das nicht mit dem sichtbaren Inhalt übereinstimmt, verstößt gegen Googles Richtlinien für strukturierte Daten und kann im schlechtesten Fall zum Entzug von Rich-Result-Berechtigungen führen – das Risiko liegt also eher im „zu viel und falsch” als im „zu wenig”.
• Wartungsaufwand wird unterschätzt. Ein Markup-Template, das nie wieder angefasst wird, veraltet zusammen mit dem CMS, den Plugins und den Redaktionsprozessen. Ohne Owner und Stichprobenprüfung verfällt die Datenqualität schleichend.
• Kein Ersatz für guten Inhalt. Markup beschreibt Inhalt, es erzeugt ihn nicht. Ein dünner, wenig hilfreicher Artikel mit perfektem JSON-LD bleibt ein dünner Artikel – Google nennt in der eigenen Anleitung zur KI-Optimierung ausdrücklich einen einzigartigen Blickwinkel und hilfreiche, verlässliche Inhalte als das, worauf es ankommt, nicht Markup-Vollständigkeit.

Für Unternehmen mit vielen bestehenden Artikeln lohnt sich eine ehrliche Bestandsaufnahme, bevor neues Markup ausgerollt wird: Wie viele Artikel haben aktuell gar kein, veraltetes oder vom Inhalt abweichendes Markup? Das ist oft aufschlussreicher als die Frage, welches JSON-LD-Feld als Nächstes ergänzt werden soll.

Eine letzte Grenze, die selten offen ausgesprochen wird: Auch bei technisch perfektem Markup bleibt die Darstellung in den Suchergebnissen eine Entscheidung der jeweiligen Suchmaschine, keine feste Zusage. Wer intern einen Business Case für ein Markup-Projekt rechtfertigen muss, sollte deshalb nicht mit versprochenen Klickzahlen argumentieren, sondern mit dem, was tatsächlich beeinflussbar ist: sauberere, wartbare Datenrepräsentation, geringeres Risiko von Richtlinienverstößen und ein Content-Prozess, in dem technische und redaktionelle Qualität zusammen mitgedacht werden.

Checkliste: Article-Markup korrekt einsetzen

1. Content-Typ pro Kategorie festgelegt: Article, NewsArticle oder BlogPosting.
2. headline, image, datePublished, dateModified und author sind vollständig und automatisiert aus dem CMS befüllt.
3. Jede Autor:in hat ein eigenes Person-Objekt mit Name und Identifikationslink (url oder sameAs).
4. dateModified wird nur bei echter inhaltlicher Änderung aktualisiert, nicht bei jedem Speichervorgang.
5. Jedes Feld im JSON-LD hat eine sichtbare Entsprechung auf der Seite (Autor, Datum, Titelbild, Headline).
6. JSON-LD wird serverseitig gerendert, nicht nachträglich per Client-Skript eingefügt.
7. Seiten mit strukturierten Daten sind nicht durch robots.txt, noindex oder andere Zugriffssperren blockiert.
8. JSON-LD ist syntaktisch (Linter) und schema-konform (Struktur­daten-Test) an der Live-URL validiert.
9. Ein regelmäßiges Stichproben-Monitoring nach dem Rollout ist eingerichtet, keine einmalige Prüfung.
10. Es besteht kein Anspruch, Markup allein würde Rankings verbessern – der Fokus liegt auf korrekter, wartbarer Repräsentation echter Inhalte.

Wer Article-Markup als Teil eines größeren technischen SEO- und Content-Setups einordnen will, findet die Landkarte im Themen-Cluster Web, SEO & GEO. Wenn du deinen bestehenden Content-Bestand oder Redaktionsprozess auf technische Sauberkeit prüfen lassen willst, ist ein kostenloses Erstgespräch der pragmatischste erste Schritt – oder direkt unser Beratungsangebot, wenn ein Umsetzungsprojekt ansteht.