Technisches GEO: Voraussetzungen für KI-Sichtbarkeit

Technisches GEO stellt sicher, dass relevante Inhalte einer Website öffentlich erreichbar, crawlbar, eindeutig einer URL zugeordnet und technisch verarbeitbar sind. Dazu gehören unter anderem Botsteuerung, Indexierbarkeit, Statuscodes, Canonicals, interne Verlinkung, Rendering und strukturierte Daten.

Die technische Optimierung schafft jedoch nur die Voraussetzungen für Sichtbarkeit. Eine technisch fehlerfreie Seite wird nicht automatisch in ChatGPT, Google AI Overviews, Gemini oder Perplexity genannt. Die Systeme entscheiden weiterhin selbst, welche Quellen für eine konkrete Frage relevant sind.

Google stellt ausdrücklich klar, dass für AI Overviews und den KI-Modus keine besonderen GEO-Techniken oder speziellen Schema-Typen erforderlich sind. Die bekannten SEO-Grundlagen bleiben entscheidend.

Was ist technisches GEO?

Technisches GEO ist die technische Optimierung einer Website für eine zuverlässige Auffindbarkeit, Verarbeitung und Zuordnung in klassischen und generativen Suchsystemen.

Der Bereich umfasst insbesondere:

• Erreichbarkeit der Website,
• Steuerung relevanter Crawler,
• Indexierbarkeit,
• eindeutige URLs,
• korrekte Statuscodes,
• technische Bereitstellung der Inhalte,
• interne Linkstruktur,
• strukturierte Daten,
• Medien und Dokumente,
• laufende Fehlerkontrolle.

Technisches GEO erzeugt keine fachliche Relevanz. Es verhindert vielmehr, dass gute Inhalte aufgrund technischer Probleme gar nicht oder nur unvollständig berücksichtigt werden können.

Eine Seite kann fachlich hervorragend sein. Steht sie jedoch auf noindex, verweist ihr Canonical auf eine andere URL oder blockiert die robots.txt den relevanten Suchcrawler, besitzt sie deutlich schlechtere Voraussetzungen.

Wie unterscheidet sich technisches GEO von technischem SEO?

Technisches SEO sorgt dafür, dass Suchmaschinen eine Website crawlen, rendern, indexieren und technisch korrekt einordnen können.

Technisches GEO übernimmt diese Grundlagen und erweitert die Prüfung um generative Such- und Antwortsysteme.

Dazu gehören zusätzliche Fragen:

• Darf der OAI-SearchBot die Inhalte abrufen?
• Welche weiteren KI-bezogenen Bots werden blockiert?
• Sind die wichtigsten Informationen ohne unnötige technische Hürden zugänglich?
• Können Unternehmen, Autoren, Produkte und Leistungen eindeutig zugeordnet werden?
• Welche URLs werden von generativen Systemen tatsächlich als Quellen verwendet?
• Lässt sich Referral Traffic aus ChatGPT erkennen?

Der größte Teil des technischen GEO ist damit kein Ersatz für technisches SEO. Er ist dessen plattformübergreifende Erweiterung.

Unsere zentrale Einordnung lautet:

Technisches GEO beginnt nicht mit neuen KI-Dateien. Es beginnt mit sauberem technischem SEO, klar zugänglichen Inhalten und der Frage, welche Systeme eine Website tatsächlich crawlen dürfen.

Welche technischen Voraussetzungen benötigen KI-Suchsysteme?

Nicht jedes System arbeitet technisch gleich. Trotzdem lassen sich einige grundlegende Voraussetzungen ableiten.

Eine relevante Seite sollte:

• öffentlich erreichbar sein,
• einen korrekten Statuscode liefern,
• nicht unbeabsichtigt blockiert werden,
• eine eindeutige URL besitzen,
• wichtige Informationen zuverlässig ausliefern,
• intern auffindbar sein,
• keine widersprüchlichen technischen Signale senden,
• für Nutzer verständlich und bedienbar bleiben.

Google weist darauf hin, dass selbst die Einhaltung sämtlicher technischer Anforderungen keine Aufnahme in den Index oder eine bestimmte Darstellung garantiert.

Für ChatGPT Search gilt ebenfalls: Jede öffentliche Website kann grundsätzlich erscheinen. OpenAI empfiehlt, den OAI-SearchBot nicht zu blockieren, wenn Inhalte gefunden, zusammengefasst, zitiert und verlinkt werden sollen. Eine Freigabe stellt jedoch keine Aufnahmegarantie dar.

Unser Sieben-Schichten-Modell für technisches GEO

Für technische GEO-Analysen unterscheiden wir sieben aufeinander aufbauende Schichten:

1. Erreichbarkeit
2. Crawling-Steuerung
3. Indexierbarkeit und URL-Eindeutigkeit
4. Rendering und Inhaltszugang
5. Website- und Informationsarchitektur
6. semantische und mediale Auszeichnung
7. Kontrolle und Monitoring

Ein Fehler in einer frühen Schicht kann alle folgenden Maßnahmen beeinträchtigen.

1. Erreichbarkeit

Zunächst muss geprüft werden, ob eine Website zuverlässig aufgerufen werden kann.

Dazu gehören:

• funktionierendes HTTPS,
• stabile DNS-Auflösung,
• erreichbarer Server,
• korrekte Weiterleitungen,
• keine Weiterleitungsschleifen,
• keine dauerhaften Serverfehler,
• keine übermäßig strengen Firewall-Regeln,
• keine unbeabsichtigten Rate Limits für Crawler.

Wichtige HTTP-Statuscodes

Statuscode	Bedeutung
200	Seite ist erfolgreich erreichbar
301	URL wurde dauerhaft weitergeleitet
302 oder 307	URL wurde vorübergehend weitergeleitet
404	Inhalt wurde nicht gefunden
410	Inhalt wurde dauerhaft entfernt
500	interner Serverfehler
503	Dienst vorübergehend nicht verfügbar

Eine Seite mit Statuscode 200 ist technisch erreichbar. Das bedeutet noch nicht, dass sie indexierbar oder fachlich relevant ist.

Eine dauerhaft gelöschte URL sollte einen passenden 404- oder 410-Status liefern. Wird stattdessen bei jeder nicht vorhandenen URL eine inhaltlich leere Seite mit Statuscode 200 ausgegeben, kann ein Soft-404-Problem entstehen.

Besonders problematisch sind sporadische Serverfehler. Eine Seite kann im Browser meist funktionieren, während Bots aufgrund von Schutzsystemen, Lastspitzen oder CDN-Regeln regelmäßig 403-, 429- oder 5xx-Antworten erhalten.

2. Crawling-Steuerung

Die Crawling-Steuerung legt fest, welche Bots welche Bereiche einer Website abrufen dürfen.

Die Funktion der robots.txt

Die robots.txt befindet sich üblicherweise im Stammverzeichnis der Domain:

https://beispiel.de/robots.txt

Sie kann für einzelne User-Agents festlegen, welche Pfade gecrawlt werden dürfen.

Google beschreibt die robots.txt vor allem als Instrument zur Steuerung des Crawlerzugriffs und zur Begrenzung unnötiger Serveranfragen. Sie ist nicht als zuverlässige Methode gedacht, um eine URL aus dem Suchindex zu entfernen.

Beispiel einer Freigabe:

User-agent: OAI-SearchBot
Allow: /

Beispiel einer Sperre:

User-agent: OAI-SearchBot
Disallow: /

Die zweite Regel verhindert den regulären Abruf durch den OAI-SearchBot.

OAI-SearchBot

Der OAI-SearchBot ist für die Suchfunktion von ChatGPT relevant.

OpenAI erklärt, dass der Bot Zugriff benötigt, damit Inhalte in ChatGPT-Zusammenfassungen und Ausschnitten berücksichtigt werden können. ChatGPT ergänzt bei Referral Links automatisch den Parameter utm_source=chatgpt.com, wodurch entsprechende Besuche in Analysesystemen erkennbar werden können.

Die Freigabe bedeutet nicht:

• dass jede Seite gecrawlt wird,
• dass sie in einem eigenen OpenAI-Index gespeichert wird,
• dass sie für einen Prompt ausgewählt wird,
• dass sie sichtbar zitiert wird.

GPTBot

GPTBot und OAI-SearchBot sollten nicht gleichgesetzt werden.

Der OAI-SearchBot ist auf die Suchfunktion von ChatGPT ausgerichtet. GPTBot steht im Zusammenhang mit dem Crawling für generative Modellverbesserungen.

Ein Unternehmen kann daher unterschiedliche Entscheidungen treffen:

• Suchzugriff erlauben,
• Nutzung für Modellverbesserungen einschränken,
• beide Bottypen zulassen,
• beide Bottypen blockieren.

Die Entscheidung sollte bewusst und nicht durch eine pauschale Sicherheitsregel erfolgen.

Weitere relevante Bots

Je nach Plattformstrategie können unter anderem geprüft werden:

• Googlebot,
• Bingbot,
• OAI-SearchBot,
• GPTBot,
• PerplexityBot,
• weitere offiziell dokumentierte Crawler.

Ein Eintrag in der robots.txt allein beweist nicht, dass der Bot die Website tatsächlich besucht. Dafür ist eine Logfile-Analyse erforderlich.

Sicherheitsplugins und Firewalls

WordPress-Sicherheitsplugins, Web Application Firewalls und CDNs können bekannte oder unbekannte Bots blockieren.

Typische Ursachen:

• aggressive Bot-Protection,
• Ländersperren,
• Captchas,
• JavaScript-Challenges,
• Rate Limits,
• IP-basierte Sperrlisten,
• Blockierung unbekannter User-Agents.

Eine formal erlaubende robots.txt hilft nicht, wenn der Server den Bot anschließend mit 403 oder 429 abweist.

3. Indexierbarkeit und URL-Eindeutigkeit

Crawlbarkeit und Indexierbarkeit sind unterschiedliche technische Eigenschaften.

Eine Seite kann gecrawlt werden, aber auf noindex stehen. Eine blockierte URL kann umgekehrt über externe Links bekannt werden, obwohl der Crawler ihren Inhalt nicht abrufen darf.

Google weist ausdrücklich darauf hin, dass eine Sperre in der robots.txt eine Indexierung der URL nicht immer verhindert. Für einen zuverlässigen Ausschluss aus Google Search ist noindex vorgesehen. Der Crawler muss die Seite allerdings abrufen dürfen, damit er die Anweisung lesen kann.

Meta Robots und X-Robots-Tag

Eine HTML-Seite kann beispielsweise so auf noindex gestellt werden:

<meta name="robots" content="noindex, follow">

Bei PDFs und anderen Nicht-HTML-Dateien kann ein X-Robots-Tag über den HTTP-Header verwendet werden.

Zu prüfen sind:

• wichtige Seiten mit unbeabsichtigtem noindex,
• widersprüchliche Plugin-Einstellungen,
• globale WordPress-Sichtbarkeitseinstellungen,
• Staging-Regeln, die nach dem Relaunch aktiv blieben,
• noindex auf Kategorien oder Leistungsseiten.

Canonical

Ein Canonical bezeichnet die bevorzugte Version einer Seite.

Beispiel:

<link rel="canonical" href="https://beispiel.de/leistungen/geo-analyse/">

Google behandelt das Canonical als starkes Signal, aber nicht als absolute Anweisung. Google kann eine andere URL als kanonisch auswählen, wenn die übrigen Signale widersprüchlich sind.

Typische Fehler:

• alle Unterseiten verweisen auf die Startseite,
• Detailseite verweist auf eine allgemeine Kategorie,
• HTTP und HTTPS werden gemischt,
• Sitemap enthält eine andere URL als das Canonical,
• interne Links zeigen auf nichtkanonische Versionen,
• Parameterseiten besitzen unklare Canonicals,
• Sprachversionen verweisen auf die falsche Sprache.

Die robots.txt sollte nicht zur Canonicalisierung verwendet werden. Google kann gesperrte URLs weiterhin anhand anderer Signale kennen.

Weiterleitungen

Interne Links sollten möglichst direkt zur aktuellen Ziel-URL führen.

Ungünstig:

/alte-seite/ → /zwischenziel/ → /neue-seite/

Besser:

Alle internen Links verweisen direkt auf /neue-seite/.

Weiterleitungsketten erhöhen die technische Komplexität und erschweren Wartung und Fehlerdiagnose.

Duplicate Content

Doppelte oder nahezu identische Inhalte können entstehen durch:

• URL-Parameter,
• Druckansichten,
• Filter,
• Tags,
• Kategorien,
• Groß- und Kleinschreibung,
• Trailing-Slash-Varianten,
• Produktvarianten,
• Sprachversionen,
• kopierte Landingpages.

Technisches GEO benötigt keine vollständige Eliminierung jeder ähnlichen Textpassage. Entscheidend ist, dass für jede Suchintention eine eindeutige Hauptseite vorhanden ist.

4. Rendering und Inhaltszugang

Eine technisch erreichbare URL kann trotzdem unzureichend verarbeitet werden, wenn der Hauptinhalt erst unter schwierigen Bedingungen geladen wird.

Zu prüfen ist:

• Wird der Text im HTML ausgeliefert?
• Wird der Hauptinhalt erst über JavaScript nachgeladen?
• Ist eine Nutzerinteraktion notwendig?
• Werden wichtige Informationen erst nach einem Klick sichtbar?
• Blockiert eine Cookie-Einwilligung den Inhalt?
• Sind Produktinformationen nur in einem Konfigurator vorhanden?
• Benötigt die Seite eine Anmeldung?
• Liegen zentrale Aussagen ausschließlich in Bildern?

Google kann JavaScript verarbeiten. Die Verarbeitung erfolgt jedoch in zusätzlichen Schritten, weshalb Google eigene Empfehlungen für JavaScript-Websites veröffentlicht.

Für andere Such- und KI-Systeme ist nicht einheitlich dokumentiert, welche JavaScript-Funktionen und Renderingressourcen zur Verfügung stehen.

Die robuste Grundregel lautet:

Wichtige Überschriften, Texte, Links, Produktinformationen und Leistungsangaben sollten im ausgelieferten HTML zuverlässig verfügbar sein.

Das bedeutet nicht, dass Websites kein JavaScript verwenden dürfen. Interaktive Funktionen, Konfiguratoren und dynamische Filter können sinnvoll sein. Der fachliche Kern sollte jedoch nicht unnötig davon abhängig sein.

Google betrachtet Dynamic Rendering lediglich als Übergangslösung für Websites, deren JavaScript-Inhalte Suchmaschinen nicht zuverlässig erreichen. Die Methode erhöht die technische Komplexität und wird nicht als bevorzugte Dauerlösung empfohlen.

Akkordeons und Tabs

Inhalte in Akkordeons oder Tabs sind nicht grundsätzlich problematisch.

Wichtig ist:

• Der Text befindet sich bereits im HTML.
• Der Inhalt ist ohne technische Nachladefehler verfügbar.
• Die Elemente sind bedienbar und barrierearm.
• Zentrale Aussagen werden nicht vollständig versteckt.
• Überschriften und Inhalte bleiben logisch strukturiert.

Ein FAQ-Akkordeon kann daher technisch funktionieren. Es ersetzt jedoch keinen klaren Haupttext.

Login, Paywall und Formulare

Geschützte Inhalte können von öffentlichen Such- und KI-Systemen nur eingeschränkt verarbeitet werden.

Problematisch sind:

• Fachwissen nur nach Newsletter-Anmeldung,
• PDF-Downloads nur nach Formularübermittlung,
• Produktdaten nur nach Kundenlogin,
• vollständige Inhalte hinter Cookie- oder JavaScript-Barrieren.

Für wichtige Fachinformationen ist meist sinnvoll:

• eine öffentlich zugängliche HTML-Zusammenfassung,
• ergänzender Download für Detaildaten,
• sichtbare Methodik,
• öffentlich erkennbare Autoren- und Unternehmenszuordnung.

5. Website- und Informationsarchitektur

Technisches GEO umfasst auch die Struktur der Website.

Dazu gehören:

• Hauptnavigation,
• interne Verlinkung,
• Breadcrumbs,
• Themencluster,
• Klicktiefe,
• verwaiste Seiten,
• XML-Sitemaps.

Google nutzt crawlbare Links, um neue Seiten zu finden und Beziehungen zwischen Seiten zu verstehen.

Der Beitrag Interne Verlinkung für KI-Systeme erklärt die redaktionelle und strategische Planung ausführlich.

Interne Links

Wichtige Seiten sollten über reguläre HTML-Links erreichbar sein.

Beispiel:

<a href="https://geoagentur.net/leistungen/geo-analyse/">
    GEO-Analyse
</a>

Problematisch können Links sein, die ausschließlich über:

• JavaScript-Events,
• nicht crawlbare Buttons,
• Formularaktionen,
• clientseitige Zustandsänderungen

funktionieren.

Der Linktext sollte verständlich beschreiben, was sich auf der Zielseite befindet.

Klicktiefe

Eine zentrale Leistungsseite sollte nicht nur über mehrere Ebenen oder einen einzelnen alten Artikel erreichbar sein.

Geeignete Verbindungen entstehen über:

• Hauptnavigation,
• Leistungsübersicht,
• Startseite,
• thematisch passende Wissensartikel,
• Breadcrumbs,
• Hub-Seiten.

Eine starre Drei-Klick-Regel ist kein offizieller GEO-Standard. Die Klicktiefe bleibt dennoch ein hilfreicher Indikator für die strukturelle Bedeutung einer Seite.

Verwaiste Seiten

Verwaiste Seiten besitzen keine regulären eingehenden internen Links.

Sie können möglicherweise über eine XML-Sitemap oder externe Links gefunden werden. Ihre fachliche Rolle innerhalb der Website bleibt jedoch unklar.

Zu prüfen sind insbesondere:

• neue Wissensartikel,
• ältere Leistungsseiten,
• Landingpages nach Relaunches,
• Produktvarianten,
• Branchenunterseiten,
• archivierte Studien.

XML-Sitemap

Eine XML-Sitemap hilft Suchmaschinen, relevante URLs zu entdecken. Sie garantiert weder Crawling noch Indexierung.

Die Sitemap sollte grundsätzlich nur URLs enthalten, die:

• kanonisch,
• erreichbar,
• indexierbar,
• inhaltlich relevant

sind.

Nicht hinein gehören:

• 404-Seiten,
• Weiterleitungsziele mit 3xx-Status,
• noindex-Seiten,
• nichtkanonische URLs,
• interne Suchergebnisse,
• ungewollte Parameterseiten.

Eine Sitemap ersetzt keine interne Verlinkung.

6. Semantische und mediale Auszeichnung

In dieser Schicht werden Inhalte und Entitäten technisch eindeutiger beschrieben.

Strukturierte Daten

Strukturierte Daten können beispielsweise kennzeichnen:

• Unternehmen,
• Autoren,
• Artikel,
• Produkte,
• Breadcrumbs,
• Veranstaltungen,
• Videos.

Sinnvolle Schema-Typen können sein:

• Organization,
• Person,
• Article,
• BlogPosting,
• Product,
• BreadcrumbList,
• gegebenenfalls Service.

Google erklärt ausdrücklich, dass strukturierte Daten für generative Suchfunktionen nicht erforderlich sind und kein spezielles Schema.org-Markup für AI Overviews oder AI Mode ergänzt werden muss. Sie bleiben als Bestandteil der allgemeinen SEO-Strategie und für unterstützte Rich Results sinnvoll.

Der Beitrag Strukturierte Daten und GEO behandelt Nutzen und Grenzen ausführlich.

Die wichtigste Regel lautet:

Strukturierte Daten müssen den sichtbaren Inhalt korrekt beschreiben.

Eine oberflächliche Leistungsseite wird nicht dadurch hochwertiger, dass im JSON-LD zahlreiche Leistungen und Branchen ergänzt werden.

Bilder

Für Bilder sollten geprüft werden:

• eindeutige Dateinamen,
• geeignete Dateiformate,
• sinnvolle Komprimierung,
• erreichbare Bilddateien,
• Alt-Texte,
• Bildunterschriften, wenn fachlich hilfreich,
• erklärender umgebender Text.

Wichtige technische Angaben sollten nicht ausschließlich als Text innerhalb eines Bildes vorliegen.

Bei einer technischen Grafik kann der umgebende Text erklären:

• was dargestellt wird,
• welche Bauteile gemeint sind,
• welcher Prozess gezeigt wird,
• welche Einschränkungen gelten.

Videos

Videos können durch zusätzliche Informationen besser eingeordnet werden:

• klare Überschrift,
• Beschreibung,
• sichtbare Zusammenfassung,
• Transkript,
• Kapitel,
• Vorschaubild,
• gegebenenfalls VideoObject.

Ein Video ohne begleitenden Text bietet weniger direkt zugängliche Informationen als eine Seite mit Zusammenfassung und Transkript.

PDFs

PDFs können von Such- und KI-Systemen als Quellen verwendet werden. Trotzdem entstehen häufig technische und redaktionelle Nachteile:

• eingeschränkte interne Navigation,
• schwierige mobile Nutzung,
• unklare Dokumentversionen,
• schwache Verknüpfung mit Leistungsseiten,
• fehlende sichtbare Aktualisierung,
• Informationen sind nur schwer modular nutzbar.

Wichtige Fachinformationen sollten deshalb möglichst zusätzlich als HTML-Seite vorliegen.

Geeigneter Aufbau:

1. HTML-Seite mit Zusammenfassung und Kernaussagen
2. sichtbare Autoren- und Unternehmensinformationen
3. interne Links zu passenden Leistungen und Fachseiten
4. PDF als vertiefender Download

7. Kontrolle und Monitoring

Technisches GEO ist kein einmaliges Projekt.

Websites verändern sich durch:

• neue Plugins,
• Theme-Updates,
• Relaunches,
• Redirects,
• neue Inhalte,
• Änderungen an Sicherheitsregeln,
• Hosting- oder CDN-Anpassungen.

Deshalb müssen technische und GEO-bezogene Daten regelmäßig zusammengeführt werden.

Zu kontrollieren sind:

• Statuscodes,
• Crawling-Fehler,
• noindex-Seiten,
• Canonicals,
• Sitemap-URLs,
• interne Links,
• Botzugriffe,
• verwendete Quellen-URLs,
• Referral Traffic,
• Veränderungen bei Markennennungen.

Botlogs

Serverlogs zeigen, ob ein Bot die Website tatsächlich besucht hat.

Erfasst werden können:

• User-Agent,
• aufgerufene URL,
• Zeitpunkt,
• Statuscode,
• Antwortgröße,
• Häufigkeit.

Wichtig ist eine zuverlässige Verifizierung. User-Agents lassen sich imitieren. Ein bloßer Eintrag mit der Bezeichnung eines bekannten Bots beweist nicht automatisch, dass der Zugriff tatsächlich vom jeweiligen Anbieter stammt.

Referral Traffic aus ChatGPT

OpenAI ergänzt Links aus der ChatGPT-Suche mit utm_source=chatgpt.com. Dadurch können entsprechende Besuche in Webanalyse-Systemen erkannt werden.

Diese Daten zeigen nur Klicks.

Nicht erfasst werden:

• Markennennungen ohne Link,
• Erwähnungen ohne Klick,
• Quellen, die angezeigt, aber nicht besucht wurden,
• Anbieterempfehlungen ohne Websitebesuch.

Ein GEO-Monitoring muss daher über reine Trafficdaten hinausgehen.

robots.txt, noindex und Canonical richtig unterscheiden

Die drei Elemente erfüllen unterschiedliche Aufgaben.

Element	Hauptaufgabe
robots.txt	steuert den Crawlerzugriff
noindex	verhindert die Indexierung, wenn die Anweisung gelesen werden kann
Canonical	nennt die bevorzugte URL-Version

Typischer Fehler:

Eine URL wird in der robots.txt blockiert und gleichzeitig mit noindex versehen. Der Bot kann die Seite dann möglicherweise nicht abrufen und das noindex nicht lesen.

OpenAI weist ebenfalls darauf hin, dass ein Crawler die Seite aufrufen dürfen muss, um ein noindex-Metatag zu erkennen.

Benötigt eine Website eine llms.txt?

Eine llms.txt soll KI-Systemen ausgewählte Inhalte und Informationen über eine Website bereitstellen.

Für Google AI Overviews und den KI-Modus ist sie nicht erforderlich. Google erklärt ausdrücklich, dass keine zusätzlichen KI-Textdateien oder besonderen GEO-Dateien benötigt werden.

Für andere Plattformen gibt es derzeit keinen allgemein belastbaren Nachweis, dass eine llms.txt regelmäßig zu mehr:

• Crawling,
• Zitationen,
• Markennennungen,
• Empfehlungen

führt.

Eine llms.txt kann als experimentelle Ergänzung bestehen bleiben. Sie ersetzt jedoch nicht:

• robots.txt,
• XML-Sitemap,
• interne Verlinkung,
• Indexierbarkeit,
• hochwertige HTML-Inhalte,
• klare Unternehmensinformationen.

Welche Rolle spielen Ladezeit und Core Web Vitals?

Eine schnelle und stabile Website verbessert die Nutzererfahrung und die technische Zuverlässigkeit.

Zu prüfen sind:

• Largest Contentful Paint,
• Interaction to Next Paint,
• Cumulative Layout Shift,
• Serverantwortzeit,
• Bildgrößen,
• JavaScript-Menge,
• CSS,
• Caching,
• CDN.

Core Web Vitals sind kein öffentlich dokumentierter direkter ChatGPT-Zitationsfaktor.

Schlechte Performance kann dennoch praktische Probleme erzeugen:

• Timeouts,
• unvollständige Auslieferung,
• hohe Serverlast,
• blockierte Ressourcen,
• schwierige mobile Bedienung,
• fehlerhafte Formulare.

Die geeignete Einordnung lautet:

Gute Performance verbessert technische Zuverlässigkeit und Nutzerfreundlichkeit. Sie garantiert keine Sichtbarkeit in KI-Antworten.

Technisches GEO für WordPress

WordPress kann eine solide technische Grundlage bieten. Probleme entstehen häufig nicht durch WordPress selbst, sondern durch widersprüchliche Einstellungen und zu viele parallele Systeme.

Typische Fehlerquellen:

• „Suchmaschinen davon abhalten“ ist aktiviert,
• SEO-Plugin setzt wichtige Seiten auf noindex,
• Theme und Plugin erzeugen unterschiedliche Canonicals,
• mehrere Plugins geben doppeltes Schema Markup aus,
• Sicherheitsplugin blockiert relevante Bots,
• alte URLs bleiben intern verlinkt,
• Archive und Attachment-Seiten werden ungewollt indexiert,
• XML-Sitemap enthält ungeeignete URLs,
• Page Builder lädt zentrale Inhalte erst über JavaScript,
• Cache oder CDN liefert Bots veraltete Versionen.

Für geoagentur.net ist die technische Basis mit WordPress, Blocksy, Gutenberg und Stackable vergleichsweise schlank.

Sinnvoll ist:

• möglichst wenige notwendige Plugins,
• klare Zuständigkeit für SEO-Metadaten,
• nur ein zentrales System für Canonicals und Sitemaps,
• Prüfung des bereits vorhandenen Schema Markups,
• regelmäßige Backups,
• kontrollierte Updates,
• technische Tests nach größeren Änderungen.

Zusätzliche GEO-Plugins sollten nur installiert werden, wenn sie ein konkret nachgewiesenes Problem lösen.

Technisches GEO für B2B-Websites

B2B-Websites besitzen häufig wenige zentrale Leistungen, aber viele Fachartikel, Downloads und Fallstudien.

Besonders zu prüfen sind:

• klare Verbindung von Wissen und Money-Pages,
• indexierbare Leistungsseiten,
• zugängliche Preis- und Ablaufinformationen,
• HTML-Zusammenfassungen von Whitepapern,
• sichtbare Autoreninformationen,
• technisch erreichbare Kontaktwege,
• funktionierende Formulare,
• nachvollziehbare Unternehmensangaben.

Ein häufiges Problem ist Fachwissen, das nur nach einer Formularübermittlung als PDF verfügbar wird.

Dadurch ist zwar ein Lead-Magnet vorhanden, das eigentliche Wissen bleibt für öffentliche Recherche- und Antwortsysteme jedoch nur eingeschränkt zugänglich.

Eine bessere Lösung kann sein:

• Kernerkenntnisse öffentlich als HTML,
• vollständige Studie zusätzlich als Download,
• klare interne Links,
• sichtbare Methodik,
• passender Leistungsbezug.

Technisches GEO für Industrieunternehmen

Industrie-Websites besitzen oft komplexe Beziehungen zwischen:

• Produkten,
• Produktgruppen,
• Werkstoffen,
• Verfahren,
• Branchen,
• Anwendungen,
• Normen,
• Datenblättern.

Typische technische Risiken:

• Filter erzeugen zahlreiche URL-Varianten,
• Produktvarianten besitzen nahezu identische Inhalte,
• Canonicals zeigen auf ungeeignete Übersichten,
• technische Daten stehen nur im PDF,
• Produkte sind ausschließlich über Konfiguratoren erreichbar,
• alte Datenblätter bleiben indexierbar,
• Branchen- und Produktseiten sind nicht intern verbunden,
• Bilder enthalten wesentliche Informationen ohne Textalternative.

Eine geeignete Struktur sollte ermöglichen, dass:

• jede wichtige Produktgruppe eine eindeutige URL besitzt,
• individuelle Fertigungsleistungen separat erklärt werden,
• technische Kerndaten im HTML stehen,
• PDFs ergänzen statt ersetzen,
• Produkt-, Werkstoff- und Branchenseiten sinnvoll verbunden sind,
• alte Dokumentversionen kontrolliert entfernt oder weitergeleitet werden.

Internationale Websites und hreflang

Internationale B2B- und Industrieunternehmen benötigen eine klare Sprach- und Länderstruktur.

Zu prüfen sind:

• eigene URL pro Sprachversion,
• korrekte wechselseitige hreflang-Verweise,
• passende Canonicals,
• vollständige Übersetzungen,
• keine automatische Weiterleitung ausschließlich anhand der IP-Adresse,
• keine Vermischung unterschiedlicher Sprachen auf einer URL,
• intern konsistente Sprachlinks.

Google verwendet im Rahmen des Mobile-first Indexing die mobile Seitenversion als primäre Grundlage. Strukturierte Daten und wichtige Inhalte sollten deshalb auf mobilen und Desktop-Versionen konsistent vorhanden sein.

Auch im GEO-Monitoring sollten Sprachen und Märkte getrennt betrachtet werden. Ein Unternehmen kann in deutschen Antworten anders sichtbar sein als in englischen oder französischen Prompts.

Wie läuft ein technisches GEO-Audit ab?

Ein technisches GEO-Audit sollte technische Websiteprüfung und plattformspezifische Kontrolle verbinden.

Schritt 1: Erreichbarkeit prüfen

Kontrolliert werden:

• HTTPS,
• DNS,
• Serverantwort,
• Weiterleitungen,
• Statuscodes,
• Firewall,
• CDN,
• Timeouts.

Schritt 2: Crawlerzugriff prüfen

Kontrolliert werden:

• robots.txt,
• Googlebot,
• OAI-SearchBot,
• GPTBot,
• Bingbot,
• weitere relevante Bots,
• Serverlogs,
• Sicherheitsregeln.

Schritt 3: Indexierungssteuerung prüfen

Kontrolliert werden:

• Meta Robots,
• X-Robots-Tag,
• Canonicals,
• Weiterleitungen,
• Duplicate Content,
• Sitemap-Einträge.

Schritt 4: Rendering prüfen

Kontrolliert werden:

• initialer HTML-Inhalt,
• JavaScript-Abhängigkeiten,
• Akkordeons,
• Lazy Loading,
• Cookie-Barrieren,
• Formulare,
• Loginbereiche.

Schritt 5: Informationsarchitektur prüfen

Kontrolliert werden:

• Navigation,
• interne Links,
• Klicktiefe,
• Breadcrumbs,
• Themencluster,
• verwaiste Seiten,
• XML-Sitemap.

Schritt 6: Semantik und Medien prüfen

Kontrolliert werden:

• Organization-Markup,
• Autoren,
• Article-Markup,
• Produkte,
• Leistungen,
• Bilder,
• Videos,
• PDFs.

Schritt 7: GEO-Daten abgleichen

Kontrolliert werden:

• Welche URLs erscheinen als Quellen?
• Welche wichtigen Seiten fehlen?
• Werden unerwünschte URLs verwendet?
• Entstehen ChatGPT-Referrals?
• Wie werden Marke und Leistungen eingeordnet?
• Welche Wettbewerber erscheinen?

Eine GEO-Analyse verbindet diese technische Prüfung mit Content-, Quellen- und Wettbewerbsdaten.

Typische technische GEO-Fehler

Relevante Bots werden blockiert

Die Website erlaubt den Zugriff in der robots.txt, während Firewall oder Sicherheitsplugin die Bots trotzdem abweisen.

robots.txt und noindex werden verwechselt

Eine Crawling-Sperre wird als sichere Deindexierungsmethode verwendet.

Wichtige Seiten stehen auf noindex

Leistungs-, Produkt- oder Wissensseiten sind unbeabsichtigt von der Indexierung ausgeschlossen.

Falsche Canonicals werden gesetzt

Detailseiten verweisen auf Startseite oder Übersichtsseite und verlieren ihre eindeutige URL-Zuordnung.

Hauptinhalte hängen vollständig von JavaScript ab

Texte und Produktdaten stehen nicht zuverlässig im ausgelieferten HTML.

Informationen liegen ausschließlich in PDFs

Die HTML-Seite enthält kaum eigene fachliche Substanz oder interne Links.

Relevante Seiten sind verwaist

Neue Inhalte wurden nicht in bestehende Themencluster eingebunden.

Die XML-Sitemap enthält ungeeignete URLs

Weiterleitungen, Fehlerseiten, noindex-URLs oder nichtkanonische Seiten werden eingereicht.

Mehrere Systeme erzeugen widersprüchliches Markup

Theme, SEO-Plugin und Schema-Plugin beschreiben unterschiedliche Organisationen oder Autoren.

Datumsangaben werden künstlich aktualisiert

dateModified ändert sich bei jedem Seitenaufruf oder kleinen technischen Update.

llms.txt wird als zentrale Maßnahme behandelt

Grundlegende Crawling-, Indexierungs- oder Contentprobleme bleiben bestehen.

Botzugriffe werden nicht kontrolliert

Unternehmen nehmen an, bestimmte Systeme könnten die Website nutzen, prüfen aber weder Logs noch Statuscodes.

Was unser eigenes GEO-Monitoring zeigt

Unser eigenes Monitoring-System dokumentiert vollständige Antworten, Quellen, verwendete URLs, Markennennungen und Wettbewerber.

Daraus ergeben sich mehrere technische Beobachtungen.

Technische Erreichbarkeit ist notwendig, aber nicht ausreichend

Eine blockierte oder nicht indexierbare Seite besitzt schlechte Voraussetzungen.

Ist der Fehler behoben, beginnt jedoch erst der Wettbewerb um:

• Prompt-Relevanz,
• fachliche Qualität,
• Quellenfähigkeit,
• Markenpositionierung,
• externe Bestätigung.

Eine technische Korrektur erzeugt nicht sofort eine Nennung

Nach einer Änderung müssen Seiten erneut:

• gecrawlt,
• verarbeitet,
• gegebenenfalls indexiert,
• für eine passende Anfrage abgerufen

werden.

Auch danach entscheidet das System, ob die Seite relevant genug ist.

Plattformen verwenden unterschiedliche URLs

Innerhalb desselben Themenclusters können verschiedene Systeme unterschiedliche Seitentypen nutzen:

• Wissensartikel,
• Produktseite,
• Leistungsseite,
• externe Quelle.

Technische Änderungen dürfen nicht vorschnell kausal interpretiert werden

Steigt die Sichtbarkeit nach einer Canonical-Korrektur, können sich gleichzeitig verändert haben:

• Inhalte,
• Prompts,
• Plattformmodelle,
• Suchindizes,
• Wettbewerber,
• externe Quellen.

Eine zeitliche Reihenfolge beweist noch keine direkte Ursache.

Logs, Crawls und GEO-Daten müssen gemeinsam betrachtet werden

Ein Website-Crawl zeigt, welche technischen Signale ausgegeben werden.

Serverlogs zeigen, welche Bots tatsächlich zugreifen.

Das GEO-Monitoring zeigt, welche URLs später in Antworten erscheinen.

Erst die Kombination dieser Perspektiven ermöglicht eine belastbare Diagnose.

Auch in unserem Fachbuch zur Sichtbarkeit in KI-Systemen trennen wir deshalb technische Verfügbarkeit und tatsächliche Auswahl.

Technische Probleme erzeugen vor allem Ausschlussgründe. Nach ihrer Behebung beginnt erst der eigentliche Wettbewerb um Relevanz, Quellenfähigkeit und Anbieterzuordnung.

Welche Kennzahlen sollten kontrolliert werden?

Technische Kennzahlen

• Anteil erreichbarer URLs,
• 4xx- und 5xx-Fehler,
• Weiterleitungsketten,
• indexierbare Seiten,
• Canonical-Konflikte,
• Orphan-Page-Quote,
• Klicktiefe,
• Core Web Vitals.

Crawling-Kennzahlen

• Zugriffe relevanter Bots,
• gecrawlte URLs,
• Statuscodes je Bot,
• blockierte Pfade,
• Crawlinghäufigkeit,
• wiederkehrende Fehler.

GEO-Kennzahlen

• verwendete Quellen-URLs,
• Quellenquote,
• Markenerwähnungsquote,
• Plattformabdeckung,
• Referral Traffic,
• Wettbewerber,
• historische Entwicklung.

Eine technisch fehlerfreie Website kann weiterhin geringe KI-Sichtbarkeit besitzen. Technik beseitigt Hindernisse. Sie ersetzt keine fachliche Relevanz.

Technische Zugänglichkeit ist die Grundlage, nicht das Ergebnis

Technisches GEO sorgt dafür, dass eine Website grundsätzlich am Wettbewerb um KI-Sichtbarkeit teilnehmen kann.

Dazu gehören:

• stabile Erreichbarkeit,
• bewusste Botsteuerung,
• eindeutige URLs,
• indexierbare Inhalte,
• zuverlässige HTML-Auslieferung,
• klare interne Verlinkung,
• korrektes Markup,
• laufende technische Kontrolle.

Spezielle KI-Dateien oder Plugins sind dafür nicht die Grundlage. Google verlangt für seine generativen Suchfunktionen keine gesonderten GEO-Techniken. OpenAI benötigt für die ChatGPT-Suche vor allem den Zugriff des OAI-SearchBot auf öffentlich zugängliche Inhalte.

Die Technik kann verhindern, dass eine gute Seite ausgeschlossen wird. Sie kann nicht garantieren, dass ein fremdes System diese Seite zitiert oder das Unternehmen empfiehlt.

Eine professionelle GEO-Strategie priorisiert technische Maßnahmen deshalb gemeinsam mit Content, Positionierung und externen Quellen. Die laufende GEO-Betreuung sorgt dafür, dass neue Inhalte technisch korrekt eingebunden und bestehende Fehler behoben werden.

Der entscheidende Grundsatz lautet:

Technisches GEO macht Inhalte erreichbar und eindeutig. Die Relevanz für eine konkrete KI-Antwort muss anschließend durch Inhalt, Kontext und Quellen entstehen.

Was ist technisches GEO?

Technisches GEO stellt sicher, dass relevante Inhalte öffentlich erreichbar, crawlbar, indexierbar, eindeutig einer URL zugeordnet und technisch verarbeitbar sind. Es erweitert technisches SEO um die Kontrolle generativer Suchsysteme und ihrer Crawler.

Welche Bots müssen für KI-Sichtbarkeit zugelassen werden?

Die Auswahl hängt von den priorisierten Plattformen ab. Häufig geprüft werden Googlebot, Bingbot, OAI-SearchBot, GPTBot und PerplexityBot. Die Bots besitzen unterschiedliche Aufgaben und sollten nicht pauschal gleichbehandelt werden.

Muss der OAI-SearchBot in der robots.txt freigegeben werden?

OpenAI empfiehlt, den OAI-SearchBot nicht zu blockieren, wenn Inhalte in der ChatGPT-Suche gefunden, zusammengefasst, zitiert und verlinkt werden sollen. Die Freigabe garantiert jedoch keine Aufnahme oder Quellenangabe.

Benötigt eine Website eine llms.txt?

Nein. Google benötigt keine llms.txt für AI Overviews oder den KI-Modus. Auch für andere Systeme gibt es keinen belastbaren allgemeinen Nachweis einer direkten Sichtbarkeitswirkung. Die Datei kann ergänzen, ersetzt aber keine technische SEO-Grundlage.

Kann technisches GEO eine Nennung in ChatGPT garantieren?

Nein. Technisches GEO beseitigt Zugriffs-, Indexierungs- und Zuordnungsprobleme. Ob ChatGPT oder ein anderes System eine Seite anschließend als Quelle verwendet oder eine Marke nennt, hängt zusätzlich von Relevanz, Inhalt, Quellenlage und Wettbewerb ab.