// stack · schema

Strukturierte Daten.

Strukturierte Daten sind bei siteway keine nachträgliche SEO-Zutat, sondern eine Ebene im Code. Wir zeichnen jede Seite mit Schema.org als JSON-LD aus — gebündelt in einem @graph je Seite, generiert aus den Feldern deines CMS. Aus derselben Quelle leiten wir Meta, Open Graph und Twitter ab. Wie das hier funktioniert, steht auf dieser Seite; buchen kannst du es als Leistung Strukturierte Daten.

stack stack: schema.org · json-ld einsatz: @graph je seite seit: 2006

Projekt anfragen Wie wir es einsetzen

// definition

Was ist JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) ist ein Datenformat, das strukturierte Daten als maschinenlesbares Objekt in einem <script>-Tag im HTML ablegt — getrennt vom sichtbaren Inhalt. Es beschreibt, was eine Seite ist: eine Organisation, eine Leistung, ein Artikel, eine FAQ. Google empfiehlt JSON-LD seit 2017 als bevorzugtes Format für Schema.org — Mikrodaten und RDFa, die das Markup in die HTML-Tags verweben, sind der ältere Weg.

Der entscheidende Baustein ist @graph: ein Array, das mehrere Entitäten in einem JSON-LD-Block zusammenfasst und über @id-Referenzen verknüpft. Genau daran arbeiten wir — nicht an einzelnen Schnipseln, sondern an einem sauberen Objektgraphen je Seite.

// wie wir es einsetzen

Ein @graph, eine Quelle.

markup folgt dem inhalt

Die meisten Ratgeber erklären JSON-LD als Copy-and-paste-Schnipsel, den man einmal ins Template klebt. Genau da fangen die Probleme an: Der Schnipsel altert, der sichtbare Text ändert sich, und irgendwann behauptet das Markup etwas anderes als die Seite. Wir gehen es andersherum an — der @graph ist die Single Source of Truth, und alles andere folgt daraus.

Konkret: Je Seite entsteht genau ein @graph, generiert aus den Feldern deines CMS. Titel, Autor, Datum, Bild und Seitentyp liegen ohnehin in TYPO3, WordPress oder Statamic — daraus bauen wir beim Ausspielen die Entitäten, verknüpfen sie über @id und leiten Meta-Description, Open Graph und Twitter-Cards aus derselben Quelle ab. Deine Redaktion pflegt einmal, das Markup entsteht mit.

Welche Entitäten in den @graph gehören, hängt vom Seitentyp ab. Eine Startseite trägt Organisation und Website, eine Leistungsseite eine Service-Entität, ein Blogbeitrag Article plus Person für den Autor. Der Aufbau ist überall gleich, der Inhalt seitenspezifisch — dieselbe Systematik, mit der auch diese Stack-Seite ausgezeichnet ist.

$ cat schema.jsonld · ein block je seite

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "…/#organization" },
    { "@type": "WebSite",      "@id": "…/#website" },
    { "@type": "WebPage",      "@id": "…#webpage",
      "isPartOf":   { "@id": "…/#website" },
      "breadcrumb": { "@id": "…#breadcrumb" } },
    { "@type": "BreadcrumbList", "@id": "…#breadcrumb" },
    { "@type": "FAQPage",       "@id": "…#faq" }
  ]
}

// technische details · 6 bausteine

Wie der Graph gebaut ist.

jeder baustein eine entscheidung

Sechs technische Entscheidungen stecken hinter jedem @graph, den wir ausliefern. Sie sind der Unterschied zwischen „irgendein Schema ist da" und einem Markup, das jahrelang synchron zum Inhalt bleibt.

// d-01container

Ein @graph.

Je Seite genau ein Block, der alle Entitäten bündelt — nicht fünf verstreute Schnipsel. Ein Ort zum Lesen, ein Ort zum Warten, kein Widerspruch zwischen Blöcken.

@graph · 1 block/seite

// d-02verknüpfung

@id-Referenzen.

Jede Entität bekommt eine stabile @id. Autor verweist auf Organisation, Seite auf Website, FAQ auf Seite — verknüpft statt dupliziert. So versteht Google die Beziehungen im Knowledge Graph.

@id · referenz statt kopie

// d-03quelle

Aus CMS-Feldern.

Der @graph wird beim Ausspielen aus den Feldern in TYPO3, WordPress oder Statamic generiert. Redaktion pflegt Inhalt, das Markup entsteht mit — nie von Hand nachgetippt, nie veraltet.

cms → @graph

// d-04ableitung

Meta abgeleitet.

Meta-Description, Open Graph und Twitter-Cards ziehen ihre Werte aus dem @graph. Eine Quelle für Suchtreffer und Social-Vorschau — die Preview bei LinkedIn oder WhatsApp kann nicht mehr vom Schema abweichen.

meta · og · twitter

// d-05mapping

Seitentyp-Mapping.

Jeder Seitentyp bekommt seine Entitäten: WebPage und Organization überall, Service auf Leistungsseiten, Article und Person im Blog, FAQPage und BreadcrumbList, wo sie hingehören.

webpage · service · article · faq

// d-06prüfung

Validierung im Build.

Schema Markup Validator und Googles Rich-Results-Test laufen als Schritt in der Deployment-Pipeline. Fehlt ein Pflichtfeld oder bricht eine @id, meldet der Build den Fehler — bevor die Seite live geht.

validator · rich-results-test

// pipeline · 4 schritte

Vom Feld zum Markup.

automatisch · nicht von hand

// schritt 01 · modellieren

Felder modellieren.

Wir legen im CMS die Felder an, aus denen der @graph entsteht: Seitentyp, Autor, Datum, Bild, Rubrik. Was das Schema braucht, hat auch die Redaktion im Backend.

output: feldmodell
// schritt 02 · generieren

@graph generieren.

Beim Ausspielen baut das Template aus den Feldern die Entitäten, setzt die @id-Referenzen und schreibt genau einen @graph-Block in den <head>.

output: @graph je seite
// schritt 03 · ableiten

Meta ableiten.

Aus demselben Datensatz entstehen Meta-Description, Open Graph und Twitter-Cards. Eine Quelle, mehrere Ausgaben — nichts wird doppelt gepflegt.

output: meta · og · twitter
// schritt 04 · validieren ● ergebnis

Im Build prüfen.

Vor dem Go-live läuft das Markup gegen Validator und Rich-Results-Test. Nur gültiges Schema geht live — Fehler stoppt den Build, nicht die Suchmaschine.

output: valides markup

// faq

Häufige Fragen.

Was ist JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) ist ein Datenformat, das strukturierte Daten als maschinenlesbares Objekt in einem <script>-Tag im HTML ablegt — getrennt vom sichtbaren Inhalt. Google empfiehlt JSON-LD seit 2017 als bevorzugtes Format für Schema.org-Markup. siteway baut damit die maschinenlesbare Ebene jeder Seite: Google, Bing und KI-Systeme lesen daraus, was eine Seite ist und wie ihre Inhalte zusammenhängen.

Was ist @graph in JSON-LD?

@graph ist ein Array, das mehrere Entitäten in einem einzigen JSON-LD-Block zusammenfasst — Organisation, Website, Seite, Breadcrumb, FAQ und mehr. Statt vieler einzelner Schema-Schnipsel über die Seite verteilt entsteht so ein Objektgraph. Jede Entität bekommt eine @id, über die andere Entitäten sie referenzieren, statt Daten zu duplizieren.

Warum ein @graph statt einzelner Schema-Blöcke?

Weil ein @graph Beziehungen abbildet, die getrennte Blöcke nicht kennen. Über @id-Referenzen weiß der Autor eines Artikels, dass er zur selben Organisation gehört wie das Impressum, und die FAQ hängt an derselben Seite wie der Breadcrumb. siteway pflegt je Seite genau einen @graph als Single Source of Truth — das verhindert widersprüchliche Angaben und doppelte Daten.

Woher kommen die Daten im @graph?

Aus den Feldern deines CMS. Titel, Autor, Datum, Bild und Seitentyp liegen ohnehin in TYPO3, WordPress oder Statamic — siteway generiert den @graph beim Ausspielen der Seite aus genau diesen Feldern. Deine Redaktion pflegt Inhalte einmal im gewohnten Backend, das Markup entsteht automatisch mit und bleibt dadurch synchron zum sichtbaren Text.

Werden Meta-Tags, Open Graph und Twitter auch daraus erzeugt?

Ja. Titel, Beschreibung und Vorschaubild stehen schon im @graph — siteway leitet Meta-Description, Open Graph und die Twitter-Cards aus derselben Quelle ab. Der JSON-LD-@graph ist die Single Source of Truth, alle anderen Kopf-Daten folgen daraus. So kann die Vorschau bei Google, LinkedIn oder WhatsApp nicht mehr vom Schema abweichen.

Wie stellt ihr sicher, dass das Markup gültig ist?

Jede Seite läuft gegen den Schema Markup Validator und Googles Rich-Results-Test, bevor sie live geht — bei siteway als Schritt in der Deployment-Pipeline, nicht als einmalige Handprüfung. Fehlt ein Pflichtfeld oder bricht eine @id-Referenz, meldet der Build das, statt es unbemerkt online gehen zu lassen.

Was ist der Unterschied zwischen JSON-LD, Mikrodaten und RDFa?

Alle drei sind Wege, Schema.org auszuzeichnen. Mikrodaten und RDFa verweben das Markup direkt in den HTML-Tags des sichtbaren Inhalts — jede Layout-Änderung kann sie beschädigen. JSON-LD liegt gebündelt in einem eigenen <script>-Block, unabhängig vom HTML. Deshalb empfiehlt Google JSON-LD, und deshalb baut siteway ausschließlich damit.

// womit das zusammenhängt

Womit das zusammenhängt.

leistung · audit · stack

// leistung · buchbar