SEO-Check mit KI-Agent: Was der Agent auf Ihrer Seite wirklich sieht

Wenn Sie einen KI-Agenten bitten, die SEO einer Seite zu prüfen, arbeitet er meist mit der in Text umgewandelten Seite. Überschriften und Fließtext erreichen ihn; HTTP-Status, Response-Header, Weiterleitungsschritte, Head-Tags und strukturierte Daten in der Regel nicht. Der Agent kann Ihre Texte daher gut bewerten, aber das meiste von dem, was darüber entscheidet, ob eine Suchmaschine die Seite indexiert, kann er nicht bestätigen.

Die Abruf-Tools der verschiedenen Assistenten unterscheiden sich und ändern sich mit der Zeit. Die sinnvolle Frage lautet deshalb: Was hat der Agent tatsächlich erhalten? Im Oktober 2026 haben wir das für eine unserer eigenen Seiten beantwortet und den vollständigen HTTP-Austausch neben der Textansicht aufgezeichnet, mit der ein Agent arbeitet. Dieser Artikel beschreibt genau, was wir ausgeführt haben, was jede Ansicht enthielt und wie Sie einem Agenten die fehlenden Belege geben.

Wir haben eine unserer Seiten auf beide Arten abgerufen

Wir haben einen veröffentlichten Artikel gewählt, unseren Leitfaden zu Weiterleitungsketten, und ihn über die lange Adresse angefragt, die jemand in einen Chat einfügen könnte: http://www.seoreport.dev/articles/redirect-chains-guide/. Reines HTTP, der Host www und ein abschließender Schrägstrich sind alles Varianten, die die Website normalisiert; die Anfrage musste also weitergeleitet werden.

Wir haben sie auf 3 Arten gelesen:

1. Der vollständige HTTP-Austausch mit curl, wobei jeder Weiterleitungsschritt, die abschließende Statuszeile, jeder Response-Header und das Roh-HTML aufgezeichnet wurden.
2. Eine reine Textextraktion desselben HTML: Skripte, Styles und der <head> entfernt, sichtbarer Text behalten. Diese Umwandlung führen viele Abruf-Tools durch, bevor ein Assistent eine Seite liest.
3. Das eingebaute Abruf-Tool eines KI-Coding-Assistenten, mit der Anweisung, Punkt für Punkt nur das zu melden, was im erhaltenen Inhalt tatsächlich enthalten war.

Die Ansichten 2 und 3 stimmten bei jedem hier relevanten Punkt überein, daher zeigt die Tabelle sie zusammen. Der einzige Unterschied: Das Abruf-Tool gab den Seitentitel weiter, während die reine Extraktion die H1 behielt, die denselben Wortlaut hat.

Nach Größe umfasste die Textansicht etwa 10 KB einer HTML-Antwort von 71 KB. Das meiste, was wegfiel, ist Skript- und Style-Code, den kein SEO-Review braucht. Der Rest sind genau die Belege, für deren Prüfung ein SEO-Review da ist.

Zwei Details aus der Tabelle wiegen schwerer als die Zahlen. Erstens hing die Antwort zum Canonical-Tag davon ab, wie wir gefragt haben. Sollte das Abruf-Tool jedes Tag als „vorhanden oder nicht vorhanden“ einstufen, antwortete es bei einem Canonical, das die Seite hat, mit „nicht vorhanden“ und ergänzte erst danach einen Vorbehalt zum <head>. Mit der Option „nicht feststellbar“ wählte es stattdessen diese. Ein Agent, der die erste Antwort erhält und danach handelt, würde empfehlen, ein Tag hinzuzufügen, das bereits existiert. Zweitens tragen das Article-JSON-LD und ein article:modified_time-Tag beide ein Änderungsdatum vom 3. Oktober 2026, während die sichtbare Autorenzeile nur das Veröffentlichungsdatum 28. September 2026 zeigt. Das Datum, das eine Suchmaschine als „zuletzt aktualisiert“ lesen kann, existiert nur in dem Teil der Seite, den der Agent nie erhalten hat.

Auf dieser Seite war nichts falsch. Zwei Weiterleitungsschritte liegen deutlich unter den 10, denen Googles Crawler laut Googles Crawling-Dokumentation folgen, und das Canonical zeigt auf die Seite selbst. Der Befund ist, dass der Agent das so oder so nicht hätte wissen können.

Das Abruf-Tool meldete einen Status nur, wenn die Seite fehlschlug

Wir haben den Test mit einer Adresse wiederholt, die auf unserer Website nicht existiert. Der Server antwortete mit 404, und das Abruf-Tool sagte das auch: Es meldete „HTTP 404 Not Found“ und gab keinen Seitentext zurück. Bei der funktionierenden Seite wurde die 200 nie erwähnt.

Dieses Muster (Fehler werden sichtbar, erfolgreiche Antworten bleiben stumm) lässt genau die Fälle aus, die am meisten Ärger machen, weil sie mit 200 antworten:

• Eine Seite, die wie fehlend wirkt, aber mit 200 antwortet. Unsere 404-Seite sagt „Article Not Found. The article you are looking for does not exist.“ Würde ein Server denselben Text mit Status 200 senden, wäre die Textansicht identisch. Nur die Statuszeile sagt Suchmaschinen, was davon vorliegt, und wenn Google die Variante mit 200 erkennt, meldet die Search Console sie als „Soft 404-Fehler“.
• Eine Seite, die sich einwandfrei liest, Suchmaschinen aber anweist, sie nicht zu indexieren. Laut Googles Dokumentation zum Robots-Meta-Tag (Stand: Oktober 2026) kann jede Regel, die in einem Robots-Meta-Tag verwendbar ist, auch als X-Robots-Tag-HTTP-Header gesendet werden. Ein so gesendetes noindex hinterlässt im Text keine Spur. Wie Sie solche Fälle finden und bewerten, behandeln wir im Artikel URL als „noindex“ markiert in der Search Console.
• Eine Seite, deren Canonical in einem Header angegeben ist. Google dokumentiert einen Link-Response-Header mit rel="canonical" als Alternative zum HTML-Tag, auch für Nicht-HTML-Dateien wie PDFs. Eine Textansicht kann ihn nicht sehen.

Die Belege stecken im Austausch, nicht auf der Seite

Alles, was die Textansicht verworfen hat, gehört zu einer Art: Belege, die Server und Crawler austauschen und die ein Besucher, der die Seite liest, nie sieht. Sie verteilen sich auf 6 Orte.

Status und Weiterleitungen. Jeder Weiterleitungsschritt ist eine eigene Antwort mit eigenem Statuscode. Manche Abruf-Tools schreiben http:// vor der Anfrage in https:// um, sodass die Weiterleitung von HTTP auf HTTPS gar nicht erst angefragt wird. Der Leitfaden zu Weiterleitungen und URL-Normalisierung erklärt, welche Schritte bleiben sollten.

Response-Header. X-Robots-Tag, Link, Cache-Control, Vary und die Security-Header werden alle oberhalb des HTML übertragen. Keiner davon ist Text auf der Seite.

Head-Tags. Canonical, Meta-Robots, hreflang, Meta-Description und die Tags für Open Graph stehen im <head>, den Textumwandlungen entfernen.

Strukturierte Daten. JSON-LD steht in einem <script>-Element. Textumwandlungen entfernen Skripte, und das JSON-LD verschwindet mit ihnen. Der Leitfaden zu strukturierten Daten und Social-Metadaten erklärt, was es enthalten sollte.

Roh-HTML im Vergleich zum gerenderten HTML. Manche Abruf-Tools führen JavaScript aus, bevor sie die Seite umwandeln, andere nicht, und die Ausgabe sagt selten, welches der Fall war. Eine Seite, deren Inhalt erst nach der Ausführung von JavaScript erscheint, kann für ein Tool vollständig und für ein anderes leer aussehen. Wie oft diese Lücke auftritt, haben wir in was KI-Crawler tatsächlich sehen gemessen.

Dateien und Seiten jenseits der URL. Die robots.txt ist eine eigene Datei, die der Agent nur anfragt, wenn man ihn darum bittet. Laut Googles Dokumentation kann Google das noindex einer Seite gar nicht lesen, wenn die robots.txt die Seite blockiert; beides muss also zusammen geprüft werden. Sitemap, interne Links und etwaige doppelte URLs liegen ohnehin auf ganz anderen Seiten.

sequenceDiagram
    participant U as Sie
    participant A as KI-Agent
    participant F as Abruf-Tool
    participant S as Ihre Website
    U->>A: Prüfe die SEO dieser Seite
    A->>F: URL abrufen
    F->>S: GET http://www.example.com/page/
    S-->>F: 301 und ein Location-Header
    F->>S: GET https://example.com/page/
    S-->>F: 301 und ein Location-Header
    F->>S: GET https://example.com/page
    S-->>F: 200, Response-Header, vollständiges HTML
    Note over F: Weiterleitungsschritte, Status, Header, Head-Tags und JSON-LD verworfen
    F-->>A: Sichtbarer Text als Markdown
    A-->>U: Empfehlungen allein auf Basis des Texts

Die meisten SEO-Probleme, die wir melden, liegen außerhalb des Seitentexts

Unsere eigenen Audit-Daten zeigen, wie viel eines Reviews von dem abhängt, was die Textansicht verwirft. 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: Response-Header, Head-Tags, strukturierte Daten, XML-Sitemap, robots.txt, Weiterleitungen oder Beziehungen zwischen Seiten.

Das folgende Diagramm schlüsselt dieselben 506 Probleme nach dem einen Ort auf, an dem man nachsehen müsste, um den Beleg zu sehen.

Nur die 5,9 % im sichtbaren Seiteninhalt sind die Art von Beleg, die eine Textansicht behält. Gruppiert danach, was ein Agent erhalten müsste, um sie zu sehen, fallen die übrigen Orte in 3 Gruppen. HTTP-Status und Header, Head-Tags und strukturierte Daten machen zusammen 69 % der 506 Probleme aus: Belege, die in der eigenen Antwort einer Seite ankommen und die eine Textumwandlung wegwirft. Eine bessere Textextraktion würde sie nicht zurückholen, das Lesen der Antwort selbst schon. XML-Sitemap, der Artikelbestand als Ganzes, Beziehungen zwischen Seiten und robots.txt machen zusammen etwa 20 % aus: Belege, die in keiner einzelnen Seitenantwort enthalten sind. Die übrigen 5,6 % erfordern eine zweite Sicht auf die Seite oder ihre Adresse: die gerenderte Seite neben dem Roh-HTML, die Smartphone-Antwort neben der Desktop-Antwort oder die Weiterleitungsschritte vor der Seite.

Dieselbe Stichprobe zeigt die Auswirkung pro Website: Jede der 45 Websites hatte mindestens ein gemeldetes Problem außerhalb des sichtbaren Seitentexts, und bei 24 von ihnen (53 %) lag jedes gemeldete Problem außerhalb davon. Auf diesen 24 Websites hätte ein Review, das sich auf sichtbaren Text beschränkt, keinen einzigen der gemeldeten Belege vor sich gehabt.

So geben Sie Ihrem Agenten die fehlenden Belege

Ein Agent zieht gute Schlüsse aus Belegen, die er sehen kann. Die Lösung besteht darin, ihm den Austausch vorzulegen.

Hat Ihr Agent Zugriff auf eine Shell, bitten Sie ihn, diese Befehle auszuführen und Ihnen die Rohausgabe zu zeigen, bevor er Schlüsse zieht. Hat er keinen, führen Sie die Befehle selbst aus und fügen die Ausgabe in den Chat ein.

# 1. Every hop, every status, the headers that matter (GET, following redirects)
curl -sL -D - -o /dev/null http://www.example.com/page/ \
  | grep -iE '^(HTTP/|location|x-robots-tag|link|content-type|cache-control|vary)'

# 2. Canonical, hreflang and meta robots tags from the raw HTML
curl -s https://example.com/page \
  | grep -oiE '<link[^>]*rel="(canonical|alternate)"[^>]*>|<meta[^>]*name="robots"[^>]*>'

# 3. How many JSON-LD blocks the raw HTML contains
curl -s https://example.com/page | grep -o 'application/ld+json' | wc -l

# 4. The crawl rules that apply to the page
curl -s https://example.com/robots.txt

Drei Gewohnheiten machen die Antworten verlässlich:

• GET verwenden, nicht HEAD. Manche Server beantworten beides unterschiedlich. Unserer tat das: Der erste Weiterleitungsschritt in unserem Test antwortete auf eine GET-Anfrage mit 301 und auf eine HEAD-Anfrage mit 308.
• Erst fragen, was ankam, dann, was falsch ist. „Statuscode, Header und Head-Tags auflisten, die sichtbar sind“ macht aus einer verborgenen Lücke eine sichtbare und zeigt Ihnen, welche Antworten mit „nicht vorhanden“ eigentlich „nie erhalten“ bedeuten.
• Fragen, ob das HTML gerendert wurde. Hat das Tool des Agenten JavaScript ausgeführt, kann seine Sicht von dem abweichen, was der Server sendet. Vergleichen Sie sie mit dem Roh-HTML aus Befehl 2, wie es der Leitfaden zum JavaScript-Rendering beschreibt.

Eine vollständige Prüfung einer Seite bleibt die Prüfung einer Seite

Mit dem vollständigen Austausch vor sich kann ein Agent eine einzelne Seite gründlich prüfen. Was die Antwort nicht enthalten kann, ist der Rest der Website: ob Ihre Sitemap die Seite listet, ob andere Seiten auf sie verlinken, ob eine andere URL sie dupliziert, ob die robots.txt Seiten blockiert, die Ihre Sitemap bewirbt. In der Stichprobe oben lag etwa jedes fünfte gemeldete Problem dort, wo keine einzelne Seitenantwort es zeigen konnte. Um das abzudecken, muss man die Arbeit über viele Seiten hinweg wiederholen, in vielen Sitzungen und mit einer Methode, die jedes Mal gleich bleibt. Darum geht es im Artikel warum eine einzelne KI-Sitzung keine ganze Website prüfen kann.

Eine vollständige SEOReport-Diagnose erledigt einen Großteil dieser Arbeit auf Website-Ebene in einem Bericht. Sie fragt die Seiten an, die Ihre Sitemap listet, verfolgt die eingereichte Adresse durch jeden Weiterleitungsschritt, liest Ihre robots.txt und vergleicht das Roh-HTML Ihrer Startseite mit der gerenderten Seite. Jeder Befund enthält seine Belege (Statuscodes, Header-Werte, betroffene URLs), und jeder Befund, der auf einer Stichprobe von Seiten beruht, gibt an, wie viele untersucht wurden. Ein Agent kann diesen Bericht über den MCP-Server und die REST-API erstellen und lesen und startet so von den Belegen der Website statt von Text.

Häufige Fragen

Kann ChatGPT die SEO meiner Website prüfen?

Es kann alles bewerten, was bei ihm ankommt: Überschriften, Fließtext und den Title, sofern das Tool ihn weitergibt. Ob es auch Statuscode, Header, Head-Tags oder strukturierte Daten sieht, hängt vom Abruf-Tool ab, das es in diesem Moment verwendet; das variiert und wird selten angegeben. Bitten Sie es, zuerst aufzulisten, was es erhalten hat, oder fügen Sie die Ausgabe der Befehle oben ein.

Ist ein KI-SEO-Checker dasselbe wie ein SEO-Audit?

Ein KI-SEO-Checker bewertet meist eine Seite anhand des Inhalts, den sein Tool zurückgibt. Ein Audit liest den HTTP-Austausch, die robots.txt, die Sitemap und die Beziehungen zwischen Seiten und hält die Belege für jeden Befund fest, sodass das Ergebnis überprüft und wiederholt werden kann. Beide beantworten unterschiedliche Fragen: Das eine bewertet die Texte einer Seite, das andere stellt fest, was die Website an Crawler ausliefert.

Warum sagt mein Agent, meine Seite habe kein Canonical-Tag, obwohl sie eines hat?

Das Canonical-Tag steht im <head>, den Textumwandlungen entfernen. In unserem Test antwortete das Abruf-Tool bei einem vorhandenen Canonical mit „nicht vorhanden“. Prüfen Sie das mit Befehl 2 oben oder über die Quelltextansicht im Browser, bevor Sie solchen Empfehlungen folgen.

Spielt es eine Rolle, ob das Abruf-Tool meines Agenten JavaScript ausführt?

Ja, wenn Ihre Inhalte oder Tags von JavaScript abhängen. Ein Tool, das die Seite rendert, kann einen Title oder eine H1 melden, die im Roh-HTML fehlen, und ein Tool, das nicht rendert, kann eine fast leere Seite melden, die Browser vollständig anzeigen. Der Vergleich von Roh-HTML und gerenderter Seite klärt, was Suchmaschinen und andere Crawler zuerst erhalten.