Semantic SEO & GEO für TYPO3 – Teil 2

Im ersten Teil ging es um den entscheidenden Unterschied zwischen klassischer Suchmaschinenoptimierung und Generative Engine Optimization: SEO hilft dabei, Inhalte zu finden. GEO soll dafür sorgen, dass Suchmaschinen und KI-Systeme die Inhalte, ihre Bedeutung und ihre Zusammenhänge verstehen.

Strukturierte Daten bilden dafür die technische Grundlage. Ein paar isolierte JSON-LD-Blöcke machen jedoch noch keinen Knowledge Graph. Entscheidend sind die Beziehungen zwischen Seiten, Leistungen, Themen, Projekten und häufig gestellten Fragen.

Genau hier spielt TYPO3 seine Stärke aus.

Vom Seitentext zum semantischen Datensatz

In klassischen CMS-Projekten werden Inhalte vor allem als Seiten betrachtet. Eine Seite erhält eine Überschrift, einen Text, einige Bilder und gegebenenfalls Metadaten für Suchmaschinen.

Für Besucherinnen und Besucher kann das vollkommen ausreichend sein. Maschinen erkennen darin jedoch zunächst nur ein Dokument. Sie wissen nicht automatisch:

• welche Organisation hinter dem Angebot steht,
• welche Leistungen sie anbietet,
• welche Fachthemen auf der Seite behandelt werden,
• welche Projekte ihre Erfahrung belegen,
• welche Begriffe miteinander verwandt sind,
• und welche anderen Seiten denselben fachlichen Zusammenhang beschreiben.

Eine semantische TYPO3-Architektur löst diese Informationen deshalb aus dem reinen Seitentext heraus und verwaltet sie als eigenständige Datensätze.

Dazu gehören beispielsweise:

• Organisation
• Leistungen
• Themen und Fachbegriffe
• Projekte und Referenzen
• Personen
• Zielgruppen
• häufig gestellte Fragen

Diese Datensätze können anschließend mit einer oder mehreren Seiten verbunden und automatisch als strukturierte Daten ausgegeben werden.

Der Inhalt wird damit nicht mehr ausschließlich als Dokument gedacht, sondern als Teil eines Beziehungsnetzes.

{
  "@type": "DefinedTerm",
  "@id": "https://www.beispiel.de/#topic-gesellschaftsvertrag",
  "name": "Gesellschaftsverträge und Satzungen",
  "description": "Rechtliche Grundlage für Beteiligungsverhältnisse, Zuständigkeiten und Entscheidungen innerhalb einer Gesellschaft.",
  "inDefinedTermSet": {
    "@id": "https://www.beispiel.de/#gesellschaftsrecht"
  }
}

Project

Projekte und Referenzen belegen, dass eine Leistung nicht nur angeboten, sondern tatsächlich erbracht wurde.

Ein Projekt kann mit folgenden Elementen verbunden sein:

• ausgeführte Leistungen,
• behandelte Themen,
• eingesetzte Technologien,
• Branche oder Zielgruppe,
• beteiligte Organisationen und Personen.

Je nach Inhalt kann die strukturierte Ausgabe beispielsweise als CreativeWork, Project, Article oder ein spezifischerer Schema.org-Typ erfolgen.

Für GEO sind solche Nachweise besonders interessant. Sie verbinden abstrakte Kompetenz mit konkreter Erfahrung.

FAQ

FAQs sollten ebenfalls als eigenständige Datensätze gepflegt werden. Dadurch lassen sie sich auf mehreren passenden Seiten einsetzen, ohne dieselbe Frage mehrfach verwalten zu müssen.

Eine FAQ wird dabei nicht nur einer Seite zugeordnet. Sie kann zugleich mit einer Leistung oder einem Topic verbunden sein.

Die Frage: Wann sollte ein Gesellschaftsvertrag überprüft werden? gehört beispielsweise zur Leistung »Gesellschaftsverträge und Satzungen« und zum übergeordneten Themenbereich »Gesellschaftsrecht«.

Diese Verbindung ist semantisch wertvoller als ein isolierter Akkordeontext am Ende einer Seite.

Beziehungen statt bloßer Wiederverwendung

Zentrale Records werden häufig zunächst eingeführt, um Inhalte mehrfach verwenden zu können. Das ist praktisch, greift aber zu kurz.

Der eigentliche Wert entsteht durch ihre Beziehungen:

• Eine Organisation bietet Leistungen an.
• Eine Leistung behandelt bestimmte Themen.
• Eine Seite beschreibt eine oder mehrere Leistungen.
• Ein Projekt belegt Erfahrung mit diesen Leistungen.
• Eine FAQ beantwortet eine Frage zu einem Thema.
• Eine Person ist für bestimmte Fachgebiete zuständig.

Diese Verbindungen sollten sowohl intern im TYPO3-Backend als auch extern im JSON-LD nachvollziehbar sein. Dafür benötigt jedes semantische Objekt eine dauerhafte, eindeutige Kennung – normalerweise eine URL mit Fragment-ID:

www.beispiel.de
www.beispiel.de
www.beispiel.de

Taucht dasselbe Objekt an mehreren Stellen im JSON-LD auf, wird nicht jedes Mal ein neuer Datensatz erzeugt. Stattdessen verweisen die verschiedenen Elemente auf dieselbe @id. Genau dadurch entsteht ein Graph.

Der @graph als gemeinsame Struktur

Alle semantischen Objekte einer Seite können innerhalb eines gemeinsamen @graph ausgegeben werden:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LegalService",
      "@id": "https://www.beispiel.de/#organization",
      "name": "Beispiel Kanzlei"
    },
    {
      "@type": "WebPage",
      "@id": "https://www.beispiel.de/gesellschaftsrecht/#webpage",
      "name": "Gesellschaftsrecht",
      "about": {
        "@id": "https://www.beispiel.de/#service-gesellschaftsrecht"
      }
    },
    {
      "@type": "Service",
      "@id": "https://www.beispiel.de/#service-gesellschaftsrecht",
      "name": "Beratung im Gesellschaftsrecht",
      "provider": {
        "@id": "https://www.beispiel.de/#organization"
      }
    }
  ]
}

Die Organisation, die Seite und die Leistung stehen nicht mehr unverbunden nebeneinander:

• Die Organisation erbringt die Leistung.
• Die Seite beschreibt die Leistung.
• Beide beziehen sich über dieselben IDs auf dieselben Entitäten.

Diese Konsistenz ist wichtiger als möglichst viele Schema.org-Typen auf einer Seite.

Pflege im TYPO3-Backend

Damit die semantische Struktur langfristig funktioniert, muss sie für Redakteurinnen und Redakteure verständlich bleiben.

Eine Landingpage kann deshalb Relationsfelder erhalten, über die passende Records ausgewählt werden:

• 3 bis 5 Leistungen
• 5 bis 10 Topics
• 3 bis 8 Projekte
• ein thematisch passender FAQ-Bereich

Diese Werte sind keine starren Vorgaben. Sie helfen aber, Seiten nicht mit beliebigen Beziehungen zu überladen.

Auch für semantische Verknüpfungen gilt: Qualität ist wichtiger als Menge. Ein Topic sollte nur dann zugeordnet werden, wenn es auf der Seite tatsächlich behandelt wird. Ein Projekt sollte die genannte Leistung nachvollziehbar belegen. Eine FAQ muss die Suchintention der Seite sinnvoll ergänzen.

Das TYPO3-Backend wird damit zur redaktionellen Oberfläche des Knowledge Graphs.

Inhalte nur einmal definieren

Ein zentraler Vorteil dieser Architektur ist die konsistente Datenpflege.

Die Organisation wird einmal mit Name, Logo, Adresse, Kontaktinformationen, Profilen und Kernkompetenzen angelegt. Leistungen, Topics, Projekte und FAQs werden ebenfalls zentral verwaltet.

Auf den einzelnen Seiten werden anschließend nur noch die passenden Beziehungen ausgewählt.

Dadurch lassen sich typische Probleme vermeiden:

• unterschiedliche Bezeichnungen für dieselbe Leistung,
• widersprüchliche Beschreibungen,
• mehrfach gepflegte FAQs,
• uneinheitliche IDs,
• voneinander isolierte JSON-LD-Blöcke.

Ändert sich eine zentrale Information, kann sie an allen verbundenen Stellen einheitlich aktualisiert werden.

Was Suchmaschinen und KI-Systeme daraus ableiten können

Ein solcher Graph garantiert nicht, dass eine Website in einer KI-Antwort genannt oder besonders hervorgehoben wird. Er schafft aber bessere Voraussetzungen dafür, Inhalte korrekt einzuordnen.

Maschinen erhalten deutlichere Hinweise darauf:

• wer eine Organisation ist,
• wofür sie fachlich steht,
• welche Leistungen sie anbietet,
• wie diese Leistungen voneinander abgegrenzt sind,
• welche Themen und Fragen dazugehören,
• und welche Inhalte ihre Kompetenz belegen.

GEO bedeutet deshalb nicht, möglichst viel zusätzliches JSON-LD zu erzeugen. Es bedeutet, fachliche Zusammenhänge so eindeutig und konsistent abzubilden, dass Menschen, Suchmaschinen und KI-Systeme dieselbe inhaltliche Struktur erkennen können.

Der Knowledge Graph beginnt dabei nicht erst bei Google oder einer generativen Suchmaschine. Er beginnt im Content-Modell des eigenen TYPO3-Projekts.

Im dritten und letzten Teil geht es darum, wie dieser Graph technisch erzeugt, validiert und weiterentwickelt wird – vom automatischen JSON-LD-Rendering über Vorschau und Fehlerprüfung bis zum AI Context Layer.