KI-SEO-Audit: Warum eine Chat-Sitzung keine ganze Website abdeckt
Warum ein KI-SEO-Audit in einer Chat-Sitzung nur die gelesenen Seiten abdeckt: Website-Größe, Belege außerhalb der Seite und Konflikte zwischen Seiten.
Ein KI-Assistent kann eine einzelne Seite gut prüfen: Er liest Title, Überschriften und Text, die man ihm gibt, und erklärt, was sich ändern sollte. Eine ganze Website kann eine einzelne KI-Sitzung jedoch nicht prüfen, und zwar aus zwei Gründen. Erstens liegen die meisten Belege, die ein SEO-Audit braucht, nicht im Seitentext, den ein Assistent liest, sondern in den Response-Headern, in der robots.txt, in der XML-Sitemap, in Weiterleitungen und in den Beziehungen zwischen Seiten. Zweitens hat eine Website ab einer überschaubaren Größe mehr URLs, als eine Sitzung gleichzeitig lesen und vergleichen kann. Der erste Grund wiegt schwerer, und ein größeres Modell ändert daran nichts.
Bei 45 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat, lagen 94 % der 506 gemeldeten Probleme an Stellen, die ein Leser der Seite nie sieht. Dieser Artikel rechnet die Abdeckung durch, zeigt, wo diese Belege liegen, und erklärt, wie Sie eine Website mit KI prüfen: indem Sie dem Assistenten eine Diagnose auf Website-Ebene geben, bevor er mit den Korrekturen beginnt. Er baut auf dem Artikel warum KI-Stichproben kein systematisches SEO-Audit ersetzen auf, der die beiden Methoden verglichen hat; hier geht es um die Zahlen.
Was eine Chat-Sitzung sieht und was ein Website-Audit erfasst
Ein KI-Website-Audit im Chat beginnt meist mit einer URL. Das Abruf-Tool des Assistenten ruft diese Seite ab und gibt zurück, was es erhalten hat, oft in lesbaren Text umgewandelt, und das Gespräch arbeitet mit diesem Text. Ein systematisches Audit setzt eine Ebene höher an, bei der Website. Es liest die Dateien, die für den gesamten Host gelten, protokolliert die HTTP-Antwort jeder angefragten URL, vergleicht das Roh-HTML mit der gerenderten Seite und vergleicht dann die Seiten untereinander und mit der Sitemap.
Der Weg über eine einzelne URL ist sinnvolle Arbeit. Er ist aber nur einer von vielen Wegen durch eine Website, und bei jedem Schritt kann etwas verloren gehen. Eine Textumwandlung behält die Wörter, die ein Besucher liest, kann aber die Head-Tags und die Response-Header verwerfen. Und die nächste Sitzung beginnt ohne die Seiten, die diese gelesen hat.
Wie groß ist die Website, die ein Assistent prüfen soll?
Von 45 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat, hatten 15 (33 %) keine XML-Sitemap unter der in der robots.txt angegebenen Adresse oder unter /sitemap.xml. Bei den 29 dieser Websites, deren Sitemap mindestens eine URL enthielt, listete die mittlere Sitemap (Median) etwa 90 URLs; ein Viertel listete 20 oder weniger, ein Viertel mehr als 440, und das größte Zehntel mehr als 3.000.
Es handelt sich um Websites, die für ein SEOReport-Audit eingereicht wurden, nicht um eine Zufallsstichprobe des Webs, und sie sind eher klein. Die Spannweite ist trotzdem groß: Websites im größten Zehntel listen mehr als 150-mal so viele URLs wie Websites im kleinsten Viertel. Auch das Drittel der Websites ohne Sitemap unter der erwarteten Adresse ist relevant. Für sie gibt es keine Seitenliste an der Stelle, an der ein Assistent oder ein Crawler nachsehen würde. Die Seiten müssen also über Links gefunden werden, ein Abruf nach dem anderen.
Wie viele Sitzungen braucht ein KI-SEO-Audit der ganzen Website?
Die folgende Tabelle ist ein Modell, keine Messung. Sie teilt die oben genannten Sitemap-Größen durch eine angenommene Zahl von Seiten, die eine Sitzung vollständig lesen und trotzdem nebeneinander vergleichen kann. Die Annahmen:
- Eine Sitzung liest jede Sitemap-URL einmal vollständig und hält sie für den Vergleich mit den anderen bereit.
- Gezeigt werden zwei Kapazitäten: 25 Seiten und 100 Seiten pro Sitzung. Beide dienen nur der Veranschaulichung. Die tatsächliche Kapazität hängt vom Assistenten, seinem Abruf-Tool und dem Umfang jeder Seite ab, und wir haben sie nicht gemessen.
- Gezählt werden nur Sitemap-URLs. robots.txt, Response-Header, Weiterleitungsschritte und gerenderte Seiten kommen als zusätzliche Arbeit hinzu, daher ist jeder Wert eine Untergrenze.
| 20 URLs, unteres Quartil | 1 | 1 |
| Etwa 90 URLs, Median | 4 | 1 |
| 447 URLs, oberes Quartil | 18 | 5 |
| Mehr als 3.000 URLs, größte 10 % | 120+ | 30+ |
Bei etwa der Hälfte der 29 Websites mit Sitemap passt die gesamte Sitemap unter der großzügigen Annahme in eine Sitzung. Dort lässt sich eine Prüfung per Chat am ehesten vertreten. Oberhalb des Medians wächst die Zahl der Sitzungen mit der Website, und die Sitzungen ergeben zusammen kein einheitliches Audit.
Sofern der Assistent keine Gedächtnisfunktion hat oder Sie keine Notizen weitergeben, beginnt jede neue Sitzung ohne die Seiten, die die vorherige gelesen hat. Notizen transportieren Schlussfolgerungen. Ein späterer Vergleich braucht aber die Belege selbst: die genaue Canonical-URL auf Seite 12, den Statuscode hinter der Weiterleitung auf Seite 340. Und eine Sitzung, die ihr Vorgehen jedes Mal selbst wählt, kann in verschiedenen Durchgängen Verschiedenes prüfen, sodass Durchgang 7 und Durchgang 8 nicht nach demselben Maßstab messen.
Die meisten SEO-Belege stehen nicht auf der Seite, die Sie einfügen
Die Zahl der Sitzungen ist das kleinere Problem. Das folgende Diagramm nimmt die 506 Probleme, die bei 45 externen, von SEOReport zwischen Mai und Oktober 2026 geprüften Websites gemeldet wurden, und ordnet jedes dem Ort zu, an dem man nachsehen müsste, um den Beleg zu sehen. 94 % lagen an Stellen, die ein Leser der Seite nie sieht: Response-Header, Head-Tags, strukturierte Daten, XML-Sitemap, robots.txt, Weiterleitungen oder Beziehungen zwischen Seiten.
Bei denselben 45 Websites (Mai–Oktober 2026) hatte jede mindestens ein gemeldetes Problem außerhalb des sichtbaren Seitentexts, und bei 24 von ihnen (53 %) lag jedes gemeldete Problem außerhalb davon. Die mittlere Website hatte gemeldete Probleme an 5 verschiedenen Belegorten, ein Viertel an 6 oder mehr. Selbst wenn man Security-Header ganz herausrechnet, lagen 91 % der übrigen gemeldeten Probleme außerhalb des sichtbaren Seitentexts.
Jeder dieser Orte erfordert einen eigenen Blick:
- Die HTTP-Antwort. Laut Googles Dokumentation zum Blockieren der Indexierung (Stand: Oktober 2026) kann noindex als
X-Robots-Tag-Response-Header gesendet werden, und laut der Dokumentation zur Angabe einer kanonischen URL kannrel="canonical"als HTTP-Link-Header gesendet werden. Beides taucht nirgends im Seitentext auf. - robots.txt. Laut Googles robots.txt-Dokumentation (Stand: Oktober 2026) muss die Datei im obersten Verzeichnis liegen, und ihre Regeln gelten nur für den Host, das Protokoll und den Port, über die sie ausgeliefert wird.
www.example.comundshop.example.comhaben jeweils ihre eigene Datei, wie unser Leitfaden zu robots.txt und Crawling-Zugriff erklärt. - Roh-HTML im Vergleich zur gerenderten Seite. Laut Googles Dokumentation zu JavaScript-SEO (Stand: Oktober 2026) indexiert Google eine Seite anhand des gerenderten HTML; der beste Ort für das Canonical ist das HTML, JavaScript sollte es nicht auf eine andere URL ändern, und wenn Google auf ein noindex stößt, kann es das Rendering überspringen. Bei 34 externen Websites, bei denen SEOReport das Roh-HTML des Servers mit der gerenderten Seite verglichen hat (Mai–Oktober 2026), waren 7 (21 %) für etwas, das eine Suchmaschine zuerst liest, auf JavaScript angewiesen: Title, Meta-Description, Canonical oder H1 erschienen erst nach der Ausführung von JavaScript, oder das Roh-HTML enthielt fast nichts vom Text der Seite. Ein Assistent, der umgewandelten Text liest, sieht eine dieser beiden Versionen, und im Gespräch wird selten klar, welche.
Manche Probleme gibt es nur zwischen Seiten
Von denselben 45 externen Websites (Mai–Oktober 2026) hatten 32 (71 %) mindestens ein Problem, das auf keiner einzelnen URL sichtbar ist: Es zeigt sich erst, wenn man die Sitemap mit den darin gelisteten Seiten vergleicht, Seiten miteinander vergleicht oder den Artikelbestand als Ganzes liest. Ohne den Artikelbestand sind es 28 von 45 (62 %).
So sehen diese Belege auf einer Beispiel-Website aus:
# https://www.example.com/robots.txtUser-agent: *Disallow: /checkout/# https://www.example.com/sitemap.xml listshttps://www.example.com/checkout/https://www.example.com/old-services/ (answers 301)# https://www.example.com/en/services/ declareshreflang="es" -> https://www.example.com/es/servicios/# https://www.example.com/es/servicios/ declaresno hreflang link back to /en/services/
Jede Datei sieht für sich genommen korrekt aus. Die Probleme zeigen sich erst, wenn man sie zusammen liest:
- Die Sitemap widerspricht den Seiten. Laut Googles Sitemap-Dokumentation (Stand: Oktober 2026) garantiert eine Sitemap nicht, dass ihre URLs gecrawlt und indexiert werden, und die Canonical-Dokumentation nennt die Aufnahme in die Sitemap ein schwaches Canonical-Signal. Wer eine URL listet, die weiterleitet, blockiert ist oder noindex trägt, sendet widersprüchliche Signale. Bei 29 externen Websites, deren Sitemap-Seiten SEOReport abgerufen hat (Mai–Oktober 2026), hatten 8 (28 %) mindestens eine Sitemap-URL, die weiterleitet, als noindex markiert ist oder durch die robots.txt blockiert wird.
- Die robots.txt verdeckt ein noindex. Laut Googles Dokumentation sieht ein Crawler, der durch die robots.txt blockiert wird, das noindex der Seite nie, und die URL kann trotzdem indexiert werden, wenn andere Seiten auf sie verlinken. Um das zu erkennen, braucht man robots.txt und Seite zusammen; unsere Analyse von Indexierbarkeitskonflikten geht das durch.
- hreflang ohne Rückverweis. Googles Leitfaden zu lokalisierten Versionen (Stand: Oktober 2026) sagt sinngemäß: Wenn nicht beide Seiten aufeinander verweisen, werden die Tags ignoriert. Um das zu bestätigen, braucht man beide Seiten, wie der Leitfaden zur hreflang-Implementierung zeigt.
- Ein Canonical mit fehlerhaftem Ziel. Ein Canonical, das auf eine weiterleitende oder mit noindex versehene Seite verweist, ist erst sichtbar, wenn auch das Ziel abgerufen wird.
Eine Chat-Sitzung kann jedes dieser Probleme erkennen, wenn sie zufällig beide Hälften vorliegen hat. Über viele Sitzungen hinweg landen die Hälften aber leicht in verschiedenen Gesprächen, und keines der beiden Gespräche sieht ein Problem.
So prüfen Sie, was ein KI-Website-Audit tatsächlich abgedeckt hat
Bevor Sie auf das Audit eines Assistenten hin etwas ändern, fragen Sie ihn nach vier Dingen: der Liste der abgerufenen URLs, den gelesenen robots.txt-Zeilen, dem Statuscode und den Headern Ihrer Startseite und ob er das Roh-HTML mit der gerenderten Seite verglichen hat. Kann er das nicht vorlegen, gehen Sie davon aus, dass das Audit diese Punkte nicht abgedeckt hat. Vergleichen Sie anschließend seine URL-Liste mit Ihrer Sitemap.
Dieselben Belege können Sie mit drei Befehlen selbst sammeln:
curl -s https://www.example.com/robots.txtcurl -s -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|location|x-robots-tag|link)'curl -s https://www.example.com/sitemap.xml | grep -o '<loc>' | wc -l
Der zweite Befehl sendet eine normale GET-Anfrage und gibt nur die Response-Header aus. Verwenden Sie die Sitemap-Adresse aus Ihrer robots.txt, falls sie von /sitemap.xml abweicht. Ist die Sitemap ein Sitemap-Index, entspricht die letzte Zahl der Anzahl der untergeordneten Sitemaps, nicht der Seiten. Prüfen Sie außerdem, ob der Assistent Ihre Seite überhaupt erhalten hat. Von 377 externen Websites, die zwischen Mai und Oktober 2026 bei SEOReport eingereicht wurden, ließen mindestens 51 (13,5 %) keine Bewertung der Startseite durch einen automatisierten Crawler zu, und mindestens 34 (9 %) antworteten mit einer Bot-Challenge oder einem CAPTCHA. Auch das Abruf-Tool eines Assistenten ist ein automatisierter Client; ist es auf eine Challenge-Seite gestoßen, hat es die Challenge geprüft. Unser Artikel über Bot-Schutz, der Crawler blockiert behandelt diesen Fall.
Geben Sie dem Assistenten ein Audit auf Website-Ebene, und lassen Sie ihn dann korrigieren
Assistenten sind stark bei der Arbeit, die auf eine Diagnose folgt: einen Befund erklären, die Template-Änderung schreiben, eine Weiterleitungsliste entwerfen, einen Title umformulieren. Was einer Sitzung fehlt, ist eine wiederholbare Grundlage auf Website-Ebene. Eine vollständige SEOReport-Diagnose liefert genau das. Sie liest robots.txt und Sitemap, untersucht Ihre Startseite sowie eine Stichprobe der Seiten, die Ihre Sitemap listet und auf die Ihre internen Links verweisen, protokolliert den HTTP-Status jeder angefragten Seite und vergleicht das Roh-HTML Ihrer Startseite mit der gerenderten Seite. Sie meldet Befunde, die nur seitenübergreifend existieren, etwa Sitemap-Einträge, die den gelisteten Seiten widersprechen, interne Links auf fehlende Seiten und nahezu doppelte Artikel. Jeder Befund enthält seine Belege und nennt die betroffenen URLs, und jeder auf einer Stichprobe beruhende Befund gibt an, wie viele Seiten untersucht wurden. Jede Diagnose führt dieselben festgelegten Prüfungen auf dieselbe Weise aus, sodass zwei Berichte zur selben Website Befund für Befund vergleichbar sind.
Ein Agent kann den Bericht über den MCP-Server und die REST-API erstellen, seinen Status abfragen und jeden Befund lesen. Seine Sitzungen starten dann von der Diagnose aus und nutzen ihre Kapazität für Korrekturen, einen Befund nach dem anderen. Die Seite für Agenten beschreibt dieses Setup.
Häufige Fragen
Kann ChatGPT ein SEO-Audit durchführen?
Jeder leistungsfähige Assistent kann die Seiten prüfen, die er erhält oder abrufen kann, und erklärt Probleme verständlich. Ein SEO-Audit der ganzen Website braucht aber auch robots.txt, Sitemap, Response-Header, Roh- und gerendertes HTML sowie seitenübergreifende Vergleiche. Betrachten Sie ein Chat-Audit als Prüfung der Seiten, die gelesen wurden, und lassen Sie sich diese Liste geben.
Werden größere KI-Modelle die Lücke schließen?
Mehr Kapazität erhöht im obigen Modell die Zahl der Seiten pro Sitzung. Sie verschiebt aber keine Belege in den Seitentext: Header, robots.txt und seitenübergreifende Konflikte müssen weiterhin gezielt abgerufen und verglichen werden. Eine feste Methode ist ebenso wichtig wie Kapazität, denn nur sie sorgt dafür, dass zwei Durchläufe übereinstimmen.
Reicht eine KI-Sitzung für eine kleine Website?
Bei einer Website mit etwa 20 URLs kann eine Sitzung jede Seite lesen. Sie braucht trotzdem robots.txt, Sitemap, Response-Header und Roh-HTML, also fordern Sie diese ausdrücklich an. Die Größe ist die leichtere Hälfte des Problems.
Sollte ich meine ganze Sitemap in den Chat einfügen?
Eine eingefügte Sitemap gibt der Sitzung eine URL-Liste, aber nicht die Seiten, ihre Header oder ihre Statuscodes. Der Assistent muss trotzdem jede URL einzeln abrufen, und damit gilt wieder die Sitzungsrechnung von oben.
Erhalten Sie die vollständige Diagnose Ihrer Website
Ein belegter Bericht und ein priorisierter Aktionsplan – in einem Plan mit monatlichen Credits.