Schema.org für Entwickler: JSON-LD, Rich Results und was Google wirklich liest

Ich habe strukturierte Daten lange ignoriert. Nicht aus Überzeugung, sondern aus Bequemlichkeit. Mein HTML war sauber, die Meta-Tags waren gesetzt, Lighthouse zeigte grüne Zahlen — warum also noch ein JSON-Block in den Head packen, den kein Mensch jemals sieht? Dann habe ich bei einem Artikel über Shopware-Plugins ein simples TechArticle-Schema ergänzt, und zwei Wochen später tauchte der Beitrag in den Suchergebnissen mit Autor, Datum und Beschreibung auf. Nicht als nackter blauer Link, sondern als etwas, das nach einer echten Quelle aussah. Das war der Moment, in dem ich verstanden habe, worum es bei Schema.org eigentlich geht.

Was Schema.org ist — und was nicht

Schema.org ist ein Vokabular, auf das sich Google, Microsoft, Yahoo und Yandex geeinigt haben, damit Maschinen verstehen, was auf einer Seite steht. Nicht im Sinne von „da steht Text“, sondern im Sinne von „das ist ein technischer Artikel, geschrieben von dieser Person, veröffentlicht an diesem Datum, zu diesem Thema“. Es ist keine Magie und kein Ranking-Faktor im klassischen Sinn. Es ist schlicht eine gemeinsame Sprache. Und JSON-LD ist das Format, in dem du diese Sprache sprichst — ein JSON-Block in einem <script type="application/ld+json">-Tag, unsichtbar für den Leser, aber lesbar für jede Suchmaschine und jeden KI-Crawler.

Das Grundprinzip ist einfach. Du hast einen @context, der auf https://schema.org zeigt, einen @type, der beschreibt, was das Ding ist, und dann die Eigenschaften. Klingt abstrakt, wird aber schnell konkret, wenn du es einmal aufbaust.

JSON-LD von Grund auf: ein echtes Beispiel

Nehmen wir an, du schreibst einen technischen Blogartikel. Das Minimalschema dafür sieht so aus:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Schema.org für Entwickler",
  "description": "Wie du JSON-LD in einem WordPress-Theme einbaust.",
  "author": {
    "@type": "Person",
    "name": "René Schustek",
    "url": "https://ruhrcoder.de/ueber-mich/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "RUHRCODER",
    "url": "https://ruhrcoder.de"
  },
  "datePublished": "2026-04-07",
  "dateModified": "2026-04-07",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://ruhrcoder.de/seo-schema-org-fuer-entwickler/"
  }
}

Der @type sagt: Das hier ist ein technischer Artikel, kein Rezept, kein Produkt, kein Event. Der author ist ein verschachteltes Objekt — kein einfacher String, sondern eine eigene Entität mit Typ, Name und URL. Das ist wichtig, weil Google damit den Autor über verschiedene Seiten hinweg zuordnen kann. Dasselbe gilt für publisher. Die Datumsfelder müssen im ISO-8601-Format stehen, also YYYY-MM-DD oder YYYY-MM-DDTHH:MM:SS+00:00. Ein „7. April 2026“ versteht die Maschine nicht.

Die wichtigsten Typen für Entwickler-Websites

Für eine Website wie diese — technische Artikel, Software-Projekte, eine Person dahinter — brauchst du eine Handvoll Typen, und ehrlich gesagt reichen die für 90 Prozent aller Fälle. Article und TechArticle für Blogbeiträge, wobei TechArticle die spezifischere Variante ist und sich für Tutorials und technische Anleitungen eignet. Person für die Über-mich-Seite, damit Google versteht, wer hinter dem Content steckt. Organization für das Unternehmen oder die Marke. BreadcrumbList für die Brotkrümel-Navigation — das ist einer der Typen, die tatsächlich direkt sichtbare Auswirkungen in den Suchergebnissen haben, weil Google die Breadcrumbs in den Snippet-URLs anzeigt. FAQPage für Seiten mit häufig gestellten Fragen, was zu aufklappbaren Antworten direkt in den Suchergebnissen führen kann. Und SoftwareApplication für Software-Projekte.

Ein Schema für eine Desktop-Anwendung sieht zum Beispiel so aus:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "EchoPlay",
  "description": "Desktop-Musikverwaltung mit Spotify-Integration für Windows.",
  "applicationCategory": "MultimediaApplication",
  "operatingSystem": "Windows 10, Windows 11",
  "author": {
    "@type": "Person",
    "name": "René Schustek"
  },
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "EUR"
  }
}

Der offers-Block ist Pflicht, wenn du willst, dass Google die App korrekt einordnet — selbst wenn sie kostenlos ist. Ohne Preis fehlt ein Pflichtfeld, und das Schema wird ignoriert. Solche Details sind der Grund, warum du immer validieren solltest.

Schema.org im WordPress-Theme: die PHP-Seite

In einem klassischen WordPress-Theme hängst du das Schema per wp_head-Hook ein. Keine Plugin-Abhängigkeit, keine Drittanbieter-Bloatware — eine einzelne Funktion in deiner functions.php oder in einer eigenen Datei, die du einbindest. Hier ist eine vollständige Funktion, die du direkt übernehmen und anpassen kannst:

function ruhrcoder_output_article_schema(): void {
    if ( ! is_singular( 'post' ) ) {
        return;
    }

    $post = get_post();
    if ( ! $post instanceof WP_Post ) {
        return;
    }

    $schema = [
        '@context'        => 'https://schema.org',
        '@type'           => 'TechArticle',
        'headline'        => esc_html( get_the_title( $post ) ),
        'description'     => esc_html( get_the_excerpt( $post ) ),
        'datePublished'   => get_the_date( 'c', $post ),
        'dateModified'    => get_the_modified_date( 'c', $post ),
        'mainEntityOfPage' => [
            '@type' => 'WebPage',
            '@id'   => esc_url( get_permalink( $post ) ),
        ],
        'author'          => [
            '@type' => 'Person',
            'name'  => get_the_author_meta( 'display_name', $post->post_author ),
            'url'   => esc_url( home_url( '/ueber-mich/' ) ),
        ],
        'publisher'       => [
            '@type' => 'Organization',
            'name'  => 'RUHRCODER',
            'url'   => esc_url( home_url() ),
        ],
    ];

    $thumbnail_id = get_post_thumbnail_id( $post );
    if ( $thumbnail_id ) {
        $image_url = wp_get_attachment_image_url( (int) $thumbnail_id, 'full' );
        if ( $image_url ) {
            $schema['image'] = esc_url( $image_url );
        }
    }

    $json = wp_json_encode( $schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE );
    if ( $json ) {
        echo '<script type="application/ld+json">' . $json . '</script>' . "\n";
    }
}
add_action( 'wp_head', 'ruhrcoder_output_article_schema' );

Ein paar Dinge, die hier wichtig sind: Die Funktion prüft zuerst, ob wir auf einem einzelnen Beitrag sind — auf Archivseiten oder der Startseite willst du kein Artikel-Schema ausgeben. Die Datumsformate nutzen 'c', das ist PHPs ISO-8601-Format. Das Beitragsbild wird nur ergänzt, wenn eines vorhanden ist. Und wp_json_encode ist die WordPress-Variante von json_encode, die sicherstellt, dass die Ausgabe valide ist.

Debuggen: Schema.org im Browser prüfen

Vielleicht kennst du das auch — du baust etwas ein, es sieht richtig aus, aber du bist dir nicht sicher, ob es wirklich funktioniert. Bei JSON-LD kannst du das direkt in der Browser-Konsole prüfen. Öffne die DevTools auf deiner Seite und gib das hier ein:

document.querySelectorAll('script[type="application/ld+json"]').forEach(el => {
    console.log(JSON.parse(el.textContent));
});

Du siehst sofort alle JSON-LD-Blöcke auf der Seite, sauber als Objekte ausgeklappt. Das ist der schnellste Weg, um zu prüfen, ob dein Schema überhaupt ausgegeben wird und ob die Werte stimmen. Keine Felder mit null, keine leeren Strings, keine kaputten URLs — das sind die Dinge, auf die du achten solltest.

Für die eigentliche Validierung gibt es zwei Werkzeuge, die du kennen musst. Das erste ist der Google Rich Results Test unter search.google.com/test/rich-results. Du gibst eine URL ein oder fügst HTML-Code ein, und Google zeigt dir, welche strukturierten Daten erkannt wurden und ob sie für Rich Results qualifiziert sind. Grüner Haken bedeutet: Google versteht das Schema und kann es in den Suchergebnissen verwenden. Warnungen sind meistens fehlende optionale Felder — nicht kritisch, aber besser, wenn du sie ergänzt. Fehler bedeuten: Das Schema wird ignoriert.

Das zweite Werkzeug ist der Schema Markup Validator unter validator.schema.org. Der prüft nicht gegen Google-spezifische Anforderungen, sondern gegen die Schema.org-Spezifikation selbst. Das ist nützlich, wenn du Typen verwendest, die Google noch nicht für Rich Results unterstützt, aber die trotzdem korrekt sein sollen — zum Beispiel für Bing oder für KI-Crawler, die strukturierte Daten auswerten.

Typische Fehler, die ich selbst gemacht habe

Der häufigste Fehler sind fehlende Pflichtfelder. Ein Article ohne headline wird ignoriert. Ein SoftwareApplication ohne offers wird ignoriert. Google dokumentiert die Pflichtfelder für jeden Typ, und wenn eines fehlt, ist das gesamte Schema wertlos — nicht nur das fehlende Feld. Der zweithäufigste Fehler sind falsche Datumsformate. "datePublished": "07.04.2026" ist ungültig. Es muss "2026-04-07" sein, oder besser noch mit Zeitzone. Ich habe das einmal übersehen und mich gewundert, warum der Rich Results Test alles rot markiert hat.

Dann gibt es das Problem mit doppelten Schemas. Wenn ein SEO-Plugin bereits ein Article-Schema ausgibt und dein Theme ein zweites hinzufügt, hast du zwei konkurrierende Definitionen auf derselben Seite. Google nimmt dann irgendeins oder keins — das Ergebnis ist unvorhersehbar. Prüfe also mit dem Konsolen-Befehl von oben, ob bereits ein Schema vorhanden ist, bevor du dein eigenes einbaust. Ein Theme und ein Plugin sollten sich nie ins Gehege kommen.

Was sich in den Suchergebnissen ändert

Ehrlich gesagt — nicht jedes Schema führt zu sichtbaren Änderungen. Google entscheidet selbst, ob und wann Rich Results angezeigt werden, und strukturierte Daten sind eine Voraussetzung, keine Garantie. Aber wenn es funktioniert, siehst du den Unterschied sofort. Ein Artikel-Schema kann dafür sorgen, dass Autorname, Veröffentlichungsdatum und Beitragsbild im Snippet erscheinen. Ein Breadcrumb-Schema ersetzt die nackte URL durch eine lesbare Pfadangabe. Ein FAQ-Schema kann aufklappbare Antworten direkt unter deinem Suchergebnis anzeigen, was dein Snippet deutlich größer macht als die Konkurrenz.

Der Effekt ist nicht mehr Traffic durch besseres Ranking, sondern mehr Klicks durch bessere Darstellung. Das ist ein feiner, aber wichtiger Unterschied.

Wann du es lassen solltest

Strukturierte Daten sind kein Allheilmittel, und es gibt Situationen, in denen du sie besser weglässt. Wenn deine Seite kein klar definierbares Ding beschreibt, brauchst du kein Schema dafür. Eine generische Landingpage ist kein Article. Eine Kontaktseite ist kein FAQPage. Ein Impressum ist kein AboutPage im Schema.org-Sinn — oder zumindest bringt es dir keinen Vorteil, es so zu markieren. Schema-Spam, also das wahllose Hinzufügen von Typen in der Hoffnung, dass irgendwas davon greift, kann sogar nach hinten losgehen. Google erkennt das und entwertet im schlimmsten Fall auch die legitimen Schemas auf deiner Seite.

Mein Ansatz ist pragmatisch: Artikel bekommen ein TechArticle-Schema, Software-Projekte ein SoftwareApplication-Schema, die Über-mich-Seite ein Person-Schema, und die Navigation bekommt ein BreadcrumbList-Schema. Alles andere — nur wenn es einen konkreten Grund dafür gibt. Strukturierte Daten sollen beschreiben, was da ist. Nicht erfinden, was nicht da ist.