Website-Audit mit KI bei 500 Seiten: Wie viele Chat-Sitzungen nötig sind

Nach dem Modell in diesem Artikel braucht das Audit einer 500-Seiten-Website per KI-Chat für einen einzigen Durchlauf etwa 21 Sitzungen und rund 15 Stunden Ihrer eigenen Zeit. Schwerer wiegt, dass die 21 Ergebnisse zusammen kein Audit ergeben: Jede Sitzung beginnt ohne die Belege, die die anderen gesehen haben, prüft auf verschiedenen Seiten verschiedene Dinge und formuliert ihre Urteile auf ihre eigene Weise. Es gibt also keine einheitliche Methode, nach der sich die Ergebnisse zusammenführen oder im nächsten Monat wiederholen ließen. KI-Sitzungen sind hervorragend darin, Probleme zu erklären und zu beheben; ihre beste Arbeit leisten sie, wenn sie von einer vollständigen Liste der Befunde ausgehen.

Ob Sie eine Website mit ChatGPT, Claude oder einem anderen Assistenten prüfen, die Rechnung unten bleibt dieselbe, denn sie ergibt sich aus der Funktionsweise von Chat-Sitzungen und nicht aus einem bestimmten Produkt. Der erste Beitrag dieser Serie, warum eine einzelne KI-Sitzung keine ganze Website prüfen kann, behandelte, was eine einzelne Sitzung erreicht, und modellierte die Zahl der Sitzungen pro Website bei 25 und bei 100 Seiten je Sitzung. Dieser Beitrag rechnet zusammen, was passiert, wenn Sie immer neue Sitzungen öffnen: Ihre Stunden und die Abweichung zwischen den Sitzungen.

Eine 500-Seiten-Website gehört zum oberen Viertel und ist trotzdem verbreitet

Die Größe der Website bestimmt in diesem Modell alles, deshalb beginnt es mit realen Größen. Unter 29 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat und deren XML-Sitemap mindestens eine URL enthielt, listete die Sitemap im Median etwa 90 URLs; ein Viertel listete 20 oder weniger, ein Viertel mehr als 440, und das größte Zehntel mehr als 3.000.

Das sind Websites, die für ein SEOReport-Audit eingereicht wurden, keine Zufallsstichprobe des Webs. Eine 500-Seiten-Website liegt knapp innerhalb des oberen Viertels, typischerweise ein etabliertes Unternehmen mit Blog, Leistungs- oder Produktseiten und vielleicht einigen Sprachversionen. Eine Sitemap listet die Seiten, die Suchmaschinen finden sollen; Tag-, Filter- und Archiv-URLs können außerhalb davon liegen, die Zahl in der Sitemap ist also eine Untergrenze für das, was ein Audit berücksichtigen muss.

Das Modell: Seiten pro Sitzung, dann Sitzungen pro Website

Das ist ein Modell, keine Messung. Jede Zahl darin folgt aus 4 offen genannten Annahmen, und Sie können jede davon ändern.

1. 25 Seiten pro Sitzung. Das ist die niedrigere der beiden Kapazitäten aus dem ersten Beitrag dieser Serie. Eine sorgfältige Seitenprüfung liest weit mehr als den sichtbaren Text: den Statuscode, die Antwort-Header, die Tags im Head, die strukturierten Daten und wie sich die Seite zur Sitemap und zu anderen Seiten verhält. Bei 45 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat, lagen 94 % der 506 gemeldeten Probleme an einer Stelle, die ein Leser der Seite nie sieht, und die Median-Website hatte gemeldete Probleme an 5 verschiedenen Fundorten. So viele Belege pro Seite im Blick zu behalten und trotzdem sorgfältig zu antworten, spricht für die niedrigere Kapazität, nicht für die höhere. Einfache Seiten erlauben mehr, schwere Templates weniger.
2. 1 zusätzliche Sitzung für websiteweite Dateien. robots.txt, die XML-Sitemap und die Weiterleitungen zwischen HTTP und HTTPS sowie zwischen dem Hostnamen mit und ohne www.
3. 20 Minuten Ihrer Zeit pro Sitzung. Etwa 10 Minuten, um die Methode erneut zu erklären und die Seitenliste zu übergeben, und 10, um die Ausgabe zu sichern und in eine Gesamtliste zu übernehmen.
4. 1 Minute Ihrer Zeit pro Seite. Die Seite mit ihren Headern abrufen oder einfügen und sicherstellen, dass die Sitzung sie tatsächlich gelesen hat. Die Abruf-Tools von Assistenten liefern die Seite oft als Text ohne Header zurück, deshalb gibt es diesen Schritt; was ein KI-Agent sieht, wenn er Ihre Seite prüft zeigt den Unterschied.

Die Formeln: Sitzungen = Seiten ÷ 25, aufgerundet, plus 1. Ihre Minuten = 20 × Sitzungen + Seiten.

Die Stunden reagieren weniger empfindlich auf die Annahme pro Sitzung als die Zahl der Sitzungen, weil die Minuten für die Seitenbearbeitung nicht schrumpfen, wenn eine Sitzung größer wird. Bei 10 Seiten pro Sitzung braucht die 500-Seiten-Website 51 Sitzungen und etwa 25 Stunden. Bei 100 Seiten pro Sitzung, der großzügigen Kapazität aus dem ersten Beitrag, braucht sie 6 Sitzungen und immer noch etwa 10 Stunden.

Nicht enthalten sind in den Stunden außerdem 3 Dinge: die Zeit, in der der Assistent arbeitet, die Fixes selbst und ein etwaiger zweiter Durchlauf zur Kontrolle des ersten.

Warum 21 Sitzungen zusammen kein Audit ergeben

Die Stunden sind sichtbar, und Sie können sie einplanen. Die Abweichung ist schwerer zu erkennen, und sie macht das Gesamtergebnis unzuverlässig.

Jede Sitzung beginnt ohne die Befunde der anderen. Sitzung 14 weiß nicht, dass Sitzung 3 dasselbe fehlende Canonical-Tag im Blog-Template gefunden hat. Sie meldet es erneut, als wäre es neu, oder behandelt ein Template-Problem auf 180 Seiten als Notiz zu einer einzelnen Seite. Projektdateien und Gedächtnisfunktionen tragen frühere Notizen weiter, was hilft, doch Notizen sind Schlussfolgerungen. Sie bringen Sitzung 14 nicht dazu, die Kriterien von Sitzung 3 anzuwenden.

Jede Sitzung entscheidet selbst, worauf sie achtet. Soll ein Assistent einen Stapel Seiten prüfen, wählt er für jede Seite aus, welche Signale er prüft. Eine Sitzung liest die strukturierten Daten, eine andere überspringt sie, weil die Seite in Ordnung aussah. Am Ende wissen Sie, welche Seiten geöffnet wurden, aber nicht, welche Prüfungen auf welcher Seite liefen.

Jede Sitzung formuliert ihre Urteile anders. „Missing canonical“, „no rel=canonical link“ und „canonical tag absent“ sind ein Befund in 3 Formulierungen. Auch der Schweregrad wandert: Dasselbe Problem ist in einer Sitzung „kritisch“ und in der nächsten „geringfügig“. Die Zahl, die über die Priorität entscheidet, nämlich wie viele Seiten ein Problem gemeinsam haben, gibt es erst, wenn Sie jede Zeile von Hand vereinheitlicht haben.

Probleme zwischen Seiten fallen zwischen die Sitzungen. Von denselben 45 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat, hatten 32 (71 %) mindestens ein Problem, das auf keiner einzelnen URL sichtbar ist: Es zeigt sich erst, wenn die Sitemap mit den Seiten verglichen wird, die sie listet, wenn Seiten miteinander verglichen werden oder wenn die Artikelsammlung als Ganzes gelesen wird. Wer eine Website in Pakete zu 25 Seiten aufteilt, zerteilt genau diese Vergleiche. Zwei nahezu identische Artikel, die in den Sitzungen 4 und 19 geprüft werden, begegnen sich nie; so überstehen die doppelten Seiten hinter Duplikat – vom Nutzer nicht als kanonisch festgelegt eine Prüfung Seite für Seite.

Der nächste Monat lässt sich nicht wiederholen. Dieselbe Frage, zweimal gestellt, kann anders formuliert und hin und wieder anders bewertet zurückkommen. Wenn Sie die 21 Sitzungen im Dezember wiederholen und weniger Probleme finden, können Sie nicht sagen, ob sich die Website verbessert hat oder die Sitzungen ihre Meinung geändert haben. Ohne feste Methode gibt es keine Basis für den Vergleich.

flowchart TD
    subgraph many["Viele Chat-Sitzungen"]
        A["Die nächsten 25 Seiten auswählen"] --> B["Neue Sitzung: Methode erneut erklären"]
        B --> C["Sitzung prüft, was sie selbst wählt, in eigenen Worten"]
        C --> D["Ihre Befunde in die eigenen Notizen kopieren"]
        D --> E{"Noch Seiten übrig?"}
        E -->|ja| A
        E -->|nein| F["21 Notizsätze von Hand zusammenführen"]
        F --> G["Keine Aufzeichnung, die sich im nächsten Monat wiederholen lässt"]
    end
    subgraph one["Ein Audit, dann KI pro Befund"]
        H["Ein Audit: bei jedem Lauf dieselbe Methode"] --> I["Liste der Befunde mit Belegen"]
        I --> J["Eine KI-Sitzung pro Befund"]
        J --> K["Späteres Audit, dieselbe Methode"]
        K -->|"Befund noch offen"| J
    end

Was ein Audit ändert und was nicht

Auch ein Audit arbeitet mit Stichproben. Eine vollständige SEOReport-Diagnose untersucht die Startseite, die Seiten, die Ihre Sitemap listet, und Seiten, auf die Ihre internen Links verweisen. Sie liest nicht jede Seite, und jeder Befund aus einer Stichprobe gibt an, wie viele Seiten er untersucht hat, sodass der Umfang jedes Ergebnisses dokumentiert ist.

Was es ändert, ist die Methode. Jede Diagnose führt denselben definierten Satz von Prüfungen auf dieselbe Weise aus und hält zu jeder den Beleg fest, sodass zwei Berichte derselben Website Befund für Befund vergleichbar sind. Die Vergleiche, die zwischen Chat-Sitzungen verloren gehen, finden innerhalb eines Laufs statt: Sitemap-Einträge, die den gelisteten Seiten widersprechen, interne Links auf fehlende Seiten, nahezu identische Artikel, widersprüchliche Artikeldaten und Seiten, auf die nichts verlinkt. Das Ergebnis ist eine einzige Bestandsliste: Befunde mit Belegen und betroffenen URLs, ein priorisierter Maßnahmenplan mit Prüfschritten und Exporte als PDF, Markdown und JSON. Was ein SEO-Bericht mit Score enthält geht diese Struktur durch.

Es ändert auch den Umfang der Aufgabe für die KI. Bei 249 externen Websites, die SEOReport zwischen dem 23. August und dem 4. Oktober 2026 geprüft hat, meldete der Median-Bericht 14 verschiedene Probleme (fehlgeschlagene Prüfungen oder Warnungen), und ein Viertel der Websites hatte 17 oder mehr. Ein Problem kann viele Seiten betreffen, ist aber trotzdem eine klar umrissene Aufgabe. Eine Arbeitsliste mit etwa 14 Aufgaben samt Belegen ist ein ganz anderer Auftrag als 21 offene Erkundungssitzungen.

Was das Audit nicht tut: Urteilsvermögen ersetzen oder die Fixes schreiben. Genau dort haben KI-Sitzungen ihren Platz, wie ein früherer Beitrag über KI-Stichproben aus der anderen Richtung gezeigt hat.

So setzen Sie KI-Sitzungen bei einer großen Website sinnvoll ein

Geben Sie der Sitzung die Befunde, nicht die Website. Beginnen Sie jede Sitzung mit einem Befund, seinem Beleg und den betroffenen URLs. Ein Agent kann den Bericht auch selbst erstellen und jeden Befund über die REST API oder den MCP-Server lesen, wie auf unserer Seite für KI-Agenten beschrieben, sodass seine Arbeit bei der Diagnose beginnt, statt die Website neu zu erkunden.

Ein Fix pro Sitzung. Eine eng gefasste Aufgabe hält die Aufmerksamkeit der Sitzung bei einer Ursache und macht ihre Antwort leicht überprüfbar. Ein Prompt dieser Form funktioniert gut:

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

Wenn Sie den Chat zur Erkundung nutzen müssen, schreiben Sie zuerst die Methode auf. Fügen Sie zu Beginn jeder Sitzung dieselbe Checkliste ein, weisen Sie jeder Sitzung eine feste Seitenliste zu und verlangen Sie ein einheitliches Ausgabeformat: eine Tabelle mit URL, Prüfung, beobachtetem Wert und Urteil. Das Zusammenführen wird dann mechanisch. Das verringert die Abweichungen in Formulierung und Abdeckung; die Probleme, die erst zwischen Seiten sichtbar werden, holt es nicht zurück.

Verifizieren Sie mit einem späteren Audit und mit Google. Für alles, was die Search Console meldet, beheben Sie zuerst jede betroffene URL und führen dann in der URL-Prüfung für eine davon „Live-URL testen“ aus, um zu bestätigen, dass Google die geänderte Seite abrufen kann. Der Live-Test prüft keine Duplikat- oder Canonical-Entscheidungen, bei solchen Problemen bestätigt er also nur den Zugriff. Klicken Sie dann beim Problem auf „Fehlerbehebung überprüfen“. Laut Googles Dokumentation zum Bericht zur Seitenindexierung (geprüft im Oktober 2026) dauert die Validierung in der Regel bis zu etwa zwei Wochen und in manchen Fällen deutlich länger. Ein späterer Bericht oder das wöchentliche Monitoring über die API, beschrieben in kontinuierliches SEO-Monitoring, zeigt, ob der Befund nach derselben Methode, die ihn gefunden hat, verschwunden ist.

Bei kleinen Websites fällt das Bild milder aus: Im Modell bedeutet eine Website mit 20 Seiten 2 Sitzungen und etwa eine Stunde, und eine Frage zu einer einzelnen Seite braucht überhaupt kein Audit. Die Kosten wachsen mit der Website, und mit ihnen der Wert einer wiederholbaren Methode.

Häufige Fragen

Kann ein Assistent mit Webzugriff die ganze Website selbstständig prüfen?

Der Webzugriff erspart das Einfügen, die 1 Minute pro Seite im Modell schrumpft also. Der Assistent öffnet die Seiten aber weiterhin einzeln, wählt aus, welche er öffnet, und erhält oft umgewandelten Seitentext statt der vollständigen Antwort mit ihren Headern. Das Verhalten der Tools unterscheidet sich zwischen Assistenten, und keines davon bringt eine feste Methode mit, die im nächsten Monat genauso läuft.

Löst ein größeres Kontextfenster das Problem?

Es erhöht die Zahl der Seiten pro Sitzung und senkt damit die Zahl der Sitzungen. Im Modell bedeuten 100 Seiten pro Sitzung bei einer 500-Seiten-Website immer noch 6 Sitzungen und etwa 10 Stunden, weil jede Seite gleich viel Bearbeitungszeit kostet. An der Abweichung zwischen den Läufen ändert es nichts.

Sind 25 Seiten pro Sitzung realistisch?

Es ist eine Annahme, gewählt für eine Sitzung, die neben dem Text auch Header, Tags im Head und strukturierte Daten liest. Passen Sie sie an Ihre Seiten an und verwenden Sie die Formel: Sitzungen = Seiten ÷ Seiten pro Sitzung, aufgerundet, plus 1. Die Schlussfolgerungen zur Abweichung hängen nicht davon ab.

Sollte ich die Chat-Verläufe als Audit-Dokumentation aufbewahren?

Bewahren Sie sie als Arbeitsnotizen auf. Ein Chat-Verlauf hält fest, zu welchem Schluss eine Sitzung gekommen ist, meist ohne die Rohbelege, die sie gesehen hat, etwa den Statuscode und die Header-Werte zu diesem Zeitpunkt. Eine Aufzeichnung, die zu jedem Befund den Beleg speichert, lässt jemanden das Urteil später nachprüfen und mit dem nächsten Audit vergleichen.