GEO für TYPO3: Wo Beratung und Engineering zusammenkommen

Generative Engine Optimisation, meist als GEO abgekürzt, wird oft als neue Marketing-Disziplin dargestellt. Die typischen Empfehlungen konzentrieren sich auf Inhalte: mehr Fragen beantworten, Informationen klarer strukturieren und Material veröffentlichen, das KI-gestützte Suchsysteme verstehen und zitieren können.

All das ist wichtig, deckt aber nur einen Teil des Problems ab.

Bevor ChatGPT, Gemini, Google AI Mode oder ein anderes System Informationen von einer Website nutzen kann, muss es auf die Inhalte zugreifen, erkennen, was die Informationen darstellen, und verstehen, wie Unternehmen, Personen, Produkte, Dienstleistungen und Standorte zueinander in Beziehung stehen.

Auf einer komplexen TYPO3-Website lassen sich diese Fragen nicht allein durch Content-Optimierung beantworten. Sie erfordern ein semantisches Konzept, das auch die Architektur und das Datenmodell der Website widerspiegelt.

Genau hier treffen Beratung und Engineering aufeinander.

Der Berater muss verstehen, was die Informationen des Kunden bedeuten. Der Entwickler muss verstehen, wie diese Informationen in TYPO3 abgebildet, aktualisiert und ausgeliefert werden. In vielen Fällen sind das keine zwei getrennten Phasen. Konzept und Umsetzung müssen Hand in Hand entwickelt werden.

Für Agenturen entsteht daraus die Chance, Kunden mehr als eine SEO-Checkliste zu bieten. Es entsteht aber auch der Bedarf an technischen Partnern, die sich an der Analyse beteiligen können, statt auf eine fertige Spezifikation zu warten.

GEO ersetzt kein technisches SEO

GEO wird manchmal als völlig neue Disziplin mit eigenen Regeln beschrieben. In der Praxis baut vieles davon auf vertrauten SEO-Grundlagen auf.

Google stellt klar, dass etablierte SEO-Best-Practices für AI Overviews und AI Mode relevant bleiben. Eine Seite muss weiterhin zugänglich, indexierbar und für die Google-Suche geeignet sein, bevor sie für diese generativen Funktionen berücksichtigt werden kann. Es gibt kein spezielles Markup, das die Aufnahme in eine KI-generierte Antwort garantiert.^[1]

Diese Unterscheidung ist wichtig, wenn man GEO mit Kunden bespricht. Eine Agentur kann nicht verantwortungsvoll versprechen, dass ein bestimmtes KI-System ein Unternehmen empfiehlt oder eine bestimmte Seite zitiert. Was wir tun können, ist die technische und semantische Grundlage zu verbessern, auf der diese Systeme die Website interpretieren.

Die Arbeit beginnt daher weiterhin mit vertrauten Fragen:

Können Crawler auf die relevanten Seiten zugreifen?
Ist der beabsichtigte Inhalt indexierbar?
Sind Canonical-URLs und Sprachvarianten korrekt konfiguriert?
Sind wichtige Informationen im gerenderten HTML verfügbar?
Werden das Unternehmen, seine Produkte, Dienstleistungen, Experten und Standorte konsistent dargestellt?
Kann die Umsetzung korrekt bleiben, während sich die Inhalte ändern?

Eine Website mit unklaren Seitenstrukturen, widersprüchlichen Informationen oder unzugänglichen Inhalten wird nicht dadurch KI-fähig, dass man eine llms.txt-Datei hinzufügt oder eine weitere Extension installiert.

Crawler-Zugriff ist eine geschäftliche Entscheidung

Technischer Zugriff ist die erste Ebene von GEO, aber die Entscheidung beschränkt sich längst nicht mehr darauf, Googlebot zuzulassen oder zu blockieren.

Verschiedene Anbieter setzen möglicherweise unterschiedliche Crawler für Suche, Modelltraining und nutzerausgelösten Zugriff ein. OpenAI unterscheidet beispielsweise zwischen OAI-SearchBot, der die ChatGPT-Suche unterstützt, GPTBot, der mit dem Modelltraining zusammenhängt, und ChatGPT-User, der eine Seite auf Anfrage eines Nutzers abrufen kann. Diese Steuerungen sind voneinander unabhängig.^[2]

Eine pauschale Regel, die alle KI-Crawler blockiert, kann daher Folgen haben, die der Kunde nicht beabsichtigt hat. Ein Unternehmen möchte vielleicht die Nutzung fürs Training einschränken, aber in der KI-gestützten Suche auffindbar bleiben.

Das ist keine Entscheidung, die Entwickler stillschweigend beim Bearbeiten der robots.txt treffen sollten. Sie erfordert ein Gespräch mit dem Kunden über die beabsichtigte Nutzung der Inhalte, gefolgt von einer technisch korrekten Umsetzung.

Für ein TYPO3-Projekt würden wir normalerweise Folgendes prüfen:

robots.txt und Robots-Meta-Anweisungen;
CDN- und Web-Application-Firewall-Regeln;
Bot-Schutz auf HTTP-Ebene;
Canonical-URLs;
Weiterleitungen und Statuscodes;
XML-Sitemaps;
sprachspezifische URLs und hreflang;
über JavaScript gerenderte Inhalte;
Staging-, Archiv- und Legacy-Domains;
abgelaufene Datensätze, die indexierbar bleiben.

TYPO3 bietet bereits eine gute technische Grundlage. Die System-SEO-Extension unterstützt Canonical-URLs, Robots-Anweisungen, Metadaten und XML-Sitemaps.^[3]

Die Engineering-Aufgabe besteht nicht einfach darin, diese Funktionen zu aktivieren. Sie müssen entsprechend den Sites, Sprachen, Extensions und dem Content-Lebenszyklus des Projekts konfiguriert werden.

Maschinen brauchen mehr expliziten Kontext

Ein menschlicher Besucher kann aus Navigation, Design und Bildern sehr viel ableiten. Eine Maschine, die eine isolierte Textpassage verarbeitet, verfügt möglicherweise nicht über denselben Kontext.

Eine Seite spricht vielleicht von „unserem Upgrade-Service“, während die umgebende Website deutlich macht, dass das Unternehmen TYPO3-Upgrades für Digitalagenturen anbietet. Wird die Passage isoliert abgerufen, sind Anbieter, Technologie und Zielkunde möglicherweise nicht mehr klar.

Wichtige Informationen sollten daher auch außerhalb des vollständigen visuellen Kontexts der Seite verständlich bleiben:

Welche Organisation erbringt die Dienstleistung?
Welche Technologie, welches Produkt oder welche Branche betrifft sie?
Für wen ist sie gedacht?
Wo ist die Dienstleistung verfügbar?
Welche Erfahrung stützt die Aussage?
Wer hat die Information verfasst oder geprüft?
Wann wurde sie zuletzt überprüft?

Das bedeutet nicht, Keywords unnatürlich zu wiederholen. Es bedeutet, relevante Entitäten und Beziehungen klar genug darzustellen, dass Menschen und Maschinen sie interpretieren können.

Auf einer TYPO3-Website existieren diese Entitäten möglicherweise bereits als Domänen-Datensätze. In anderen Projekten sind sie vielleicht in generische Inhaltselemente eingebettet oder über mehrere Extensions verteilt. Bevor strukturierte Daten zuverlässig generiert werden können, müssen wir verstehen, welche Informationen existieren und welche Quelle maßgeblich sein soll.

Das erfordert sowohl Beratung als auch technische Analyse.

Strukturierte Daten sind keine Liste von Tags

Strukturierte Daten, typischerweise als JSON-LD mit dem Schema.org-Vokabular umgesetzt, können Maschinen helfen zu erkennen, was eine Seite darstellt. Sie können Organisationen, Personen, Artikel, Produkte, Angebote, Dienstleistungen, Veranstaltungen, Standorte und viele weitere Entitäten beschreiben.

Der schwierige Teil ist nicht das Erzeugen der JSON-LD-Syntax. Der schwierige Teil ist die Entscheidung, was dargestellt werden soll und wie die Entitäten zueinander in Beziehung stehen.

Eine Seite kann mehrere gültige Schema-Typen enthalten, ohne eine kohärente Beschreibung des zugrunde liegenden Geschäfts zu liefern. Umgekehrt kann eine technisch korrekte Umsetzung irreführend werden, wenn die strukturierten Daten nicht mehr mit dem sichtbaren Inhalt synchron sind.

Google verlangt, dass strukturierte Daten mit den Informationen übereinstimmen, die Besucher sehen können.^[4]

Die Schema-Auswahl kann daher nicht als rein redaktionelle Entscheidung behandelt werden, während die Umsetzung nicht auf ein Entwicklungsticket reduziert werden kann. Das Konzept muss sowohl die semantische Bedeutung der Informationen als auch das Verhalten der Daten innerhalb von TYPO3 berücksichtigen.

Was Yoast SEO für TYPO3 beiträgt

Yoast SEO für TYPO3 kann ein nützlicher Teil dieses Setups sein, besonders für die redaktionelle Arbeit.

Es integriert die Inhaltsanalyse in das TYPO3-Backend und hilft Redakteuren, Seitentitel, Beschreibungen, Fokus-Keyphrases und Aspekte der Lesbarkeit zu überprüfen. Für größere Redaktionsteams kann das die Konsistenz verbessern und unvollständige Optimierungsarbeit leichter erkennbar machen.^[5]

Yoast bietet außerdem eine grundlegende Implementierung strukturierter Daten. Die Standardausgabe umfasst WebSite und BreadcrumbList, während die provider-basierte Architektur über Konfiguration erweitert werden kann.^[6]

Das sind nützliche Bausteine, aber sie liefern kein vollständiges GEO-Konzept.

Yoast kann nicht wissen, was ein Studiengang in der Organisation des Kunden darstellt, wie ein Fahrzeugangebot mit einem Standort zusammenhängt oder welcher TYPO3-Datensatz die maßgebliche Quelle einer Dienstleistungsbeschreibung ist. Es kann nicht entscheiden, ob zwei optisch ähnliche Seiten dieselbe semantische Entität darstellen.

Wir sehen Yoast daher als redaktionelle und technische Grundlage. Das projektspezifische Modell erfordert weiterhin Analyse, Beratung und Engineering.

Auswahl strukturierter Daten für eine Universität

Gemeinsam mit einer Partneragentur haben wir passende primäre und unterstützende Schema.org-Typen für eine Universitätswebsite ausgewählt.

Auf den ersten Blick hätte man die Aufgabe angehen können, indem man jeder Seitenkategorie einen Schema-Typ zuweist. In der Praxis erforderte die Arbeit ein detaillierteres Verständnis der Informationsarchitektur der Universität.

Die Website enthielt verschiedene Konzepte: die Institution selbst, Sammlungen von Studiengängen, einzelne Studiengänge, Beratungsinformationen, Veranstaltungen sowie physische oder virtuelle Standorte. Einige dieser Seiten nutzten ähnliche Layouts, stellten aber nicht dasselbe dar.

Eine wichtige Unterscheidung bestand zwischen einer Studiengangübersicht und einem einzelnen Studiengang.

Eine Übersicht mit mehreren Studiengängen lässt sich als CollectionPage mit einer ItemList darstellen. Die Detailseite steht für einen bestimmten Studiengang und kann stattdessen als EducationalOccupationalProgram beschrieben werden, mit Beziehungen zur Institution, zu einem Abschluss, einem Angebot oder ergänzenden Dokumenten.

Der Unterschied ist eher semantisch als visuell. Ihn zu erkennen erfordert Beratung: Jemand muss den Inhalt, die Nutzerreise und die Bedeutung der zugrunde liegenden Informationen verstehen.

Diese Unterscheidung in eine zuverlässige TYPO3-Umsetzung zu überführen, ist eine Engineering-Aufgabe. Die Umsetzung muss erkennen, woher die Studiengangdaten stammen, wie die Beziehungen gepflegt werden und wie das resultierende JSON-LD generiert wird.

Eine ähnliche Unterscheidung trafen wir zwischen physischen und Online-Veranstaltungen der Universität. Beide lassen sich als Veranstaltungen darstellen, aber ein physischer Tag der offenen Tür verweist möglicherweise auf einen Place, während eine Online-Informationssitzung eine VirtualLocation erfordert.

Diese Beispiele stellen nur einen ausgewählten Teil des Konzepts dar. Das vollständige Mapping umfasste weitere Seitenkategorien und projektspezifische Regeln, die an den Kunden übergeben wurden. Die wichtige Lehre ist nicht die endgültige Liste der Schema-Typen, sondern der Prozess, mit dem sie ausgewählt wurden.

Wir haben außerdem den Unterschied zwischen dem umfassenderen Schema.org-Vokabular und den Funktionen für strukturierte Daten berücksichtigt, die Google derzeit anzeigt. Ein Typ kann nützliche Semantik ausdrücken, ohne ein eigenes Rich-Result zu erzeugen. Die Unterstützung von Rich Results war daher relevant, aber nicht der einzige Grund, einen Schema-Typ auszuwählen oder abzulehnen.^[7]

Referenzierte Schema.org-Typen:CollegeOrUniversity · CollectionPage · ItemList · EducationalOccupationalProgram · Event · Place · VirtualLocation

Modellierung eines Fahrzeug-Verkaufsportals

In einem anderen Projekt haben wir eine Partneragentur beratend bei der Definition der Strategie für strukturierte Daten eines Fahrzeug-Verkaufsportals unterstützt.

Hier waren die Informationen bereits stark strukturiert. Jedes Fahrzeug enthielt viele technische Merkmale, aber ein Inserat konnte nur für kurze Zeit verfügbar bleiben. Das Modell musste das Fahrzeug detailliert beschreiben und gleichzeitig mit wechselnden Preisen und Verfügbarkeiten konsistent bleiben.

Der gewählte Ansatz kombinierte mehrere Perspektiven:

Organization oder ein passender LocalBusiness-Subtyp für das Unternehmen und seine Standorte;
Vehicle für fahrzeugspezifische Eigenschaften;
Product und Offer für das kommerzielle Angebot, einschließlich Preis und Verfügbarkeit;
Service für zugehörige Dienstleistungen des Unternehmens.

Kein einzelner Schema-Typ beschrieb die gesamte Situation.

Vehicle drückte aus, was der Gegenstand war. Product und Offer stellten die Tatsache dar, dass ein bestimmtes Fahrzeug zu definierten kommerziellen Bedingungen verfügbar war. Der Verkäufer, seine Standorte und zugehörige Dienstleistungen waren separate Entitäten, die verbunden werden mussten, ohne fälschlich zusammengeführt zu werden.

Diese Beziehungen auszuwählen, erforderte ein Verständnis ihrer semantischen Unterschiede. Sie korrekt zu halten, erforderte ein Verständnis der Anwendung und ihrer Datenflüsse.

Für ein Fahrzeugportal ist Aktualität ebenso wichtig wie Vollständigkeit. Ein JSON-LD-Block kann syntaktisch gültig bleiben und dennoch Informationen präsentieren, die nicht mehr zutreffen. Wurde ein Fahrzeug verkauft, sollten das sichtbare Inserat, seine Verfügbarkeit, die Sitemap und alle zwischengespeicherten strukturierten Daten einander nicht widersprechen.

Daraus ergaben sich weitere Umsetzungsfragen:

Welches System ist maßgeblich für Verfügbarkeit und Preis?
Wie schnell werden Änderungen auf der Website widergespiegelt?
Was passiert mit der URL, wenn ein Fahrzeug verkauft wird?
Wann sollte es aus der XML-Sitemap entfernt werden?
Können zwischengespeicherte strukturierte Daten veralten?
Wie kann die Ausgabe nach Template- oder Integrationsänderungen validiert werden?

Google kann strukturierte Daten vom Typ Product und Offer nutzen, um Informationen wie Preis und Verfügbarkeit zu verstehen. Korrektes Markup kann die Berechtigung für bestimmte Suchdarstellungen schaffen, garantiert aber nicht, dass Google sie anzeigt.^[8]

Referenzierte Schema.org-Typen:Organization · LocalBusiness · Vehicle · Product · Offer · Service

Dieses Projekt zeigte besonders deutlich, warum GEO nicht von Application-Engineering getrennt werden kann. Die strukturierten Daten waren keine statische Ergänzung eines Templates. Sie waren eine weitere Darstellung sich schnell ändernder Geschäftsdaten.

Wo Beratung und Engineering zusammenkommen

Projekte für strukturierte Daten werden oft in zwei isolierte Phasen unterteilt. Ein Berater erstellt eine Liste empfohlener Schema-Typen, und ein Entwickler wird später gebeten, sie umzusetzen.

Für einfache Websites mag das ausreichen. Für komplexe TYPO3-Projekte glauben wir nicht, dass es die besten Ergebnisse liefert.

Umsetzungsentscheidungen beginnen bereits während der konzeptionellen Arbeit.

Um die richtigen Schemas auszuwählen, muss das Team die semantischen Unterschiede zwischen den verfügbaren Typen verstehen. Gleichzeitig muss es wissen, wie die Informationen des Kunden gespeichert sind, welches System sie besitzt, wie oft sie sich ändern und welche Beziehungen TYPO3 zuverlässig erzeugen kann.

Eine Studiengangübersicht und ein einzelner Studiengang mögen ähnlich aussehen, bedeuten aber nicht dasselbe. Ein Fahrzeug ist nicht dieselbe Entität wie das kommerzielle Angebot, unter dem es verkauft wird. Eine Organisation ist nicht identisch mit einem ihrer Standorte. Ein physischer Veranstaltungsort unterscheidet sich von einem virtuellen.

Diese Unterschiede zu erkennen, ist Teil der Beratungsarbeit. Sie auf Datensätze, Integrationen und Frontend-Ausgabe abzubilden, ist Teil der Engineering-Arbeit. Das endgültige Konzept wird erst dann zuverlässig, wenn diese Perspektiven gemeinsam entwickelt werden.

Für eine Partneragentur bedeutet das nicht, die Kundenbeziehung oder ihre strategische Rolle aufzugeben. Wir können uns dort in die Analyse einbringen, wo spezialisiertes TYPO3- und semantisches Wissen benötigt wird, zu kundenbezogenen Gesprächen beitragen und das vereinbarte Konzept in eine Umsetzung überführen, die zum bestehenden System passt.

Die sichtbare Ausgabe mag am Ende ein JSON-LD-Block sein. Der eigentliche Wert liegt in den Entscheidungen und Datenbeziehungen dahinter.

Wie Agenturen ein TYPO3-GEO-Projekt angehen sollten

Wenn ein Kunde eine Agentur bittet, einer TYPO3-Website „GEO hinzuzufügen“, sollte das erste Ergebnis keine generische Liste von Schema.org-Typen sein.

Bevor das Markup gewählt wird, muss die Agentur verstehen, was die Informationen des Kunden darstellen und wie sie im System existieren. Für jede relevante Entität muss das Projekt klären:

welcher TYPO3-Datensatz oder welches externe System die maßgebliche Quelle ist;
ob die Information strukturiert oder in redaktionelle Inhalte eingebettet ist;
wie die Entitäten seiten- und extensionübergreifend zueinander in Beziehung stehen;
wie sich Sprach- und Site-Varianten auf diese Beziehungen auswirken;
was passieren soll, wenn Datensätze sich ändern, ablaufen oder verschwinden;
wie die generierte Ausgabe validiert wird;
was der Kunde von GEO erwartet und welche Ergebnisse nicht garantiert werden können.

Diese Fragen zeigen oft, dass sich das semantische Konzept und die technische Architektur nicht unabhängig voneinander gestalten lassen.

Wird eine Dienstleistung getrennt auf mehreren Seiten gepflegt, gibt es möglicherweise keine zuverlässige Quelle für eine konsistente Service-Entität. Existiert ein Standort nur als formatierter Text innerhalb eines Inhaltselements, lässt er sich nicht zuverlässig mit der Organisation, den Veranstaltungen und Angeboten verknüpfen. Wird die Fahrzeugverfügbarkeit aus einem externen System importiert, müssen die strukturierten Daten demselben Aktualisierungszyklus folgen, statt sich auf ein separat gepflegtes TYPO3-Feld zu verlassen.

Die Lösung erfordert nicht zwangsläufig den Neuaufbau des gesamten Content-Modells. In vielen Projekten genügen einige wenige, sorgfältig ausgewählte strukturelle Änderungen. Ziel ist es, eine zuverlässige Quelle für die wichtigen Informationen zu schaffen und nur jene Beziehungen anzulegen, die korrekt gehalten werden können.

Ein Schema-Mapping kann ein Ergebnis dieser Analyse sein, ist aber noch kein Umsetzungskonzept. Das Konzept muss außerdem erklären, woher die Informationen stammen, wie TYPO3 sie in sichtbare und maschinenlesbare Ausgabe überführt und wie beide Darstellungen konsistent bleiben, wenn sich die zugrunde liegenden Daten ändern.

Deshalb steigen wir bevorzugt schon in der Konzeptphase in ein GEO-Projekt ein. Gemeinsam mit der Partneragentur können wir die Anforderungen des Kunden verstehen, das semantische Modell hinterfragen oder verfeinern und es direkt in eine wartbare TYPO3-Umsetzung übersetzen.

Wenn einer Ihrer Kunden nach GEO, strukturierten Daten oder Sichtbarkeit in KI-gestützter Suche fragt, können wir dem Projekt beitreten, bevor die technische Spezifikation bereits feststeht. Die Agentur behält ihre Kundenbeziehung und gewinnt zugleich einen spezialisierten Partner in dem Bereich, in dem sich semantische Beratung und TYPO3-Engineering überschneiden.

Quellen

Google Search Central — AI features and your website. developers.google.com/search/docs/appearance/ai-features ↩
OpenAI — Overview of OpenAI crawlers. platform.openai.com/docs/bots ↩
TYPO3 Documentation — SEO features (EXT:seo). docs.typo3.org — cms-seo Features ↩
Google Search Central — Structured data general guidelines. developers.google.com — sd-policies ↩
TYPO3 Documentation — Yoast SEO for TYPO3. docs.typo3.org — yoast_seo ↩
Yoast SEO for TYPO3 — Structured data configuration. docs.typo3.org — Yoast StructuredData ↩
Google Search Central — Structured data markup that Google Search supports. developers.google.com — search-gallery ↩
Google Search Central — Product (Product, Review, Offer) structured data. developers.google.com — product ↩