Ein Release ist durch, die Seite lädt, und niemand weiß, ob die alte Beitragsadresse noch weiterleitet, ob eine Sperre aus der Testumgebung mit live gegangen ist oder ob der Canonical auf die falsche Adresse zeigt. Jede dieser Fragen lässt sich in Sekunden beantworten, wenn jemand sie stellt, und keine wird beantwortet, wenn sich jeder auf den Eindruck verlässt, dass die Seite aussieht wie vorher.
Unsere Position: Ein Website-Audit ist ein Soll-Ist-Abgleich, und ohne vorher festgelegtes Soll hat ein Agent nichts, wogegen er prüfen kann. Dieser Beitrag zeigt fünf Prüfschichten, die ein Agent nach jedem Release abarbeitet, wo seine Instrumente enden und was ein Lauf über unsere eigene Website ergeben hat.
Das Wichtigste in Kürze
- Soll zuerst: Ein Website-Audit ist ein Soll-Ist-Abgleich, und ohne vorher festgelegte Erwartung hat ein Agent nichts, wogegen er prüfen kann.
- Fünf Schichten: Status, Indexierung, Weiterleitungen, Canonical mit Sitemap und Darstellung, sortiert nach dem Schaden, den ein Fehler anrichtet.[1][2][3]
- Grenzen: Die URL-Inspection-Schnittstelle prüft keine Live-Adresse,[4] die PageSpeed-Schnittstelle antwortete ohne Schlüssel mit 429,[5] und automatische Tests fanden bei Barrierefreiheit 57,38 Prozent der Probleme.[7]
- Eigenlauf: 30 Beiträge und 69 Weiterleitungen ohne Befund, die Schreibweisen mit Schrägstrich und mit „www“ brauchen bei 69 von 69 zwei Schritte.
- Basislinie: Ein Lauf ohne Befund ist der Normalfall und die Vergleichsbasis für den nächsten Release.
- Aufwand: Bei den angenommenen Werten sinkt die Prüfzeit der HTTP-Schichten von 10 Stunden auf 1 Stunde im Jahr.
Ein Audit ist ein Soll-Ist-Abgleich
Ein Crawl allein ist noch kein Audit. Er sammelt Beobachtungen, aber erst eine vorher festgelegte Erwartung macht aus einer Beobachtung einen Befund. Der Agent prüft deshalb pro Adresse und Regel vier Dinge, die er getrennt festhält: die Erwartung, die Beobachtung, den Beleg und das Urteil.
Der Agent sortiert Befunde und markiert fehlende Belege, Veränderungen gegenüber dem letzten Lauf hebt er hervor. Ein erfolgreicher Abruf sagt etwas über die Antwort des Servers. Ob Google die Seite indexiert hat und ob sie sich gut bedienen lässt, zeigt er nicht. Status und Weiterleitungen beantwortet die HTTP-Abfrage, die gerenderte Seite zeigt der Browser, und die Sicht von Google liefert die Search Console. Das inhaltliche Urteil bleibt bei einem Menschen.
Fünf Prüfschichten in der Reihenfolge ihres Schadens
Die Schichten sind nach dem Schaden sortiert, den ein Fehler anrichtet. Eine Sperre für alle Crawler wiegt schwerer als ein zu großes Bild, und deshalb läuft die Reihenfolge von der Erreichbarkeit bis zur Darstellung.
| Schicht | Soll, das Sie festschreiben | Instrument | Grenze |
|---|---|---|---|
Adresse und Status | jede Soll-Adresse antwortet mit 200 und leitet nicht weiter | HTTP-Abfrage | sagt nichts über die gerenderte Seite |
Indexierung | kein | HTTP-Abfrage mit Auswertung von HTML und Header | zeigt die Anweisung, nicht Googles Entscheidung |
Weiterleitungen | jede alte Adresse erreicht ihr Ziel in einem Schritt und mit 301 | HTTP-Abfrage ohne automatisches Folgen | prüft die Adressen, die Sie kennen |
Canonical und Sitemap | der Canonical zeigt auf die eigene Adresse, die Adresse steht in der Sitemap | HTML-Auswertung, Sitemap-Abruf | Google behandelt den Canonical als starkes Signal, nicht als Anweisung |
Darstellung | Viewport-Angabe, genau eine H1, Ladezeit im Rahmen | Browser oder Lighthouse | Labormessungen schwanken |
Der Canonical ist die Angabe im Seitenkopf, welche Adresse als Hauptfassung einer Seite gilt, und „noindex“ die Anweisung, eine Seite nicht in den Suchindex aufzunehmen. Drei Aussagen von Google tragen die Soll-Werte. robots.txt ist kein Mittel, eine Seite aus dem Index herauszuhalten, dafür nennt Google „noindex“ oder Passwortschutz, und eine gesperrte Adresse kann ohne Beschreibung trotzdem in den Ergebnissen stehen.[2] Permanente Weiterleitungen gehören serverseitig eingerichtet, wenn sie nicht zurückgenommen werden.[1] Und der Canonical gehört nur einmal je Seite gesetzt, möglichst als absolute Adresse, weil eine relative Angabe zum Problem wird, sobald eine Testumgebung versehentlich gecrawlt wird.[3]
Grenzen der Instrumente nach dem Release
Die Instrumente beantworten jeweils eine Frage, und keine reicht für die ganze Prüfung. Die URL-Inspection-Schnittstelle der Search Console zeigt den Status der Fassung im Google-Index, die Indexierbarkeit einer Live-Adresse prüft sie nicht.[4] Gerade nach einem Release interessiert aber die Live-Adresse, also gehört dieser Teil in eine eigene Abfrage.
Die PageSpeed-Insights-Schnittstelle liefert Laborwerte von Lighthouse, Googles freiem Messwerkzeug für Ladezeit und Seitenqualität, und, noch, Felddaten aus dem Chrome User Experience Report, deren Wegfall Google angekündigt hat; für häufige automatische Abfragen empfiehlt Google einen Schlüssel.[5] Bei unserem Test ohne Schlüssel antwortete sie am 27. Oktober 2026 beim ersten Aufruf mit dem Fehler 429. Deshalb fehlt in unserem Lauf unten die Ladezeit. Für Ihren Release bedeutet das: Planen Sie für die Ladezeit einen Schlüssel ein, sonst fehlt diese Schicht in Ihrem Lauf wie in unserem. Lighthouse CI führt jede Seite dreimal aus, und je größer der Rechner, desto stabiler fallen die Werte aus.[6]
Auch die automatische Prüfung der Barrierefreiheit deckt nur einen Teil ab. Deque fand in Erstprüfungen reiner HTML-Seiten nach WCAG 2.0 und 2.1 (Stufe A und AA) mit automatischen Tests 57,38 Prozent aller Probleme, also 169.242 von 294.958, den Rest nur von Menschen.[7] Ein grüner Bericht beweist deshalb nur, dass die geprüften Regeln gelten.
Unser Lauf über 30 Beiträge und 69 Weiterleitungen
Wir haben die Schichten am 27. Oktober 2026 auf quandes-canvas.com angewendet: auf die 30 veröffentlichten Beiträge und auf die 69 Weiterleitungen von quandes.com, die auf diese Beiträge zeigen. Das sind 99 Adressen.
| Schicht | Prüfung | Ergebnis |
|---|---|---|
Adresse und Status | Soll-Adresse antwortet mit 200 ohne Weiterleitung | 30 von 30 |
Indexierung | kein | 30 von 30 ohne |
Weiterleitungen | ein Schritt und Endstatus 200 | 69 von 69 |
Canonical und Sitemap | Canonical gleich Adresse, Adresse in einer der Sitemaps | je 30 von 30 |
Darstellung | Viewport-Angabe, genau eine H1, Seitentitel | je 30 von 30 |
Der Lauf blieb ohne Befund, mit einer Ausnahme, die er sauber benennt. Die Schreibweisen der alten Adressen mit abschließendem Schrägstrich und mit „www“ brauchen jeweils zwei Schritte, bei allen 69 Adressen. Das ist für uns ein bekanntes Verhalten der Weiterleitungs-Kette, das wir bisher nicht beheben. Ein Agent muss solche Fälle als „bekannt und akzeptiert“ führen können, sonst meldet er sie bei jedem Lauf neu.
Ein Lauf ohne Befund ist der Normalfall. Sein Wert liegt in der Basislinie, gegen die der nächste Release geprüft wird.
Rechnung für zwölf Releases im Jahr
Die Rechnung zeigt den Aufwand der HTTP-Schichten. Alle Werte sind Annahmen und keine Messung.
| Annahme | Wert |
|---|---|
geprüfte Adressen je Release | 99 |
manuelle Prüfung der vier HTTP-Schichten je Adresse | 30 Sekunden |
Sichtung des Agentenprotokolls je Release | 5 Minuten |
Releases im Jahr | 12 |
Manuell kostet ein Release rund 50 Minuten, 99 mal 30 Sekunden, im Jahr 600 Minuten oder 10 Stunden. Mit Agent sind es 5 Minuten je Release und 60 Minuten im Jahr, also eine Stunde. Die Differenz von 9 Stunden entsteht bei einem Lauf ohne Befund. Jeder Befund kostet zusätzlich die Zeit, die seine Behebung braucht, aber diese Zeit fällt auch ohne Agent an, nur später und ohne Beleg. Einrichtung und Pflege der Regeln sind in der Rechnung nicht enthalten.
Der Vergleich zweier Läufe
Der Agent speichert jeden Lauf und meldet die Unterschiede zum vorigen. Er ordnet jeden Befund einer von drei Klassen zu: neu fehlerhaft, bekannt und akzeptiert oder behoben. Nur die erste Klasse löst eine Aufgabe aus, die zweite steht mit Begründung in einer Liste, die ein Mensch pflegt.
Beginnen Sie mit einem ersten Lauf über Ihre wichtigsten Adressen, zum Beispiel Startseite, Kontaktseite und die Adressen Ihrer Weiterleitungen, und legen Sie das Ergebnis als Stand ab. Jeder spätere Lauf wird gegen diesen Stand verglichen.
Vor dem Release hilft die Checkliste im Canvas-Handbuch. Ihr Abschnitt zur öffentlichen Sichtbarkeit verlangt unter anderem, zu entscheiden, ob die Seite indexiert werden soll, den Wartungsmodus zum Startplan zu prüfen und die Seite ohne Admin-Vorschau zu öffnen.[8] Der Agentenlauf wiederholt diesen Teil nach dem Release an der echten Adresse und für alle Adressen, die Sie kennen. Ob ein Release trotz eines Befunds bleibt, entscheidet ein Mensch.
Quandes Canvas
Weiterleitungen und strukturierte Daten
Nach einem Relaunch führen dauerhafte Weiterleitungen von alten auf neue Adressen. Strukturierte Daten gehören zu den Funktionen für Inhalte und Redaktion.
Funktionen für Inhalte ansehenHäufige Fragen zum Website-Audit mit KI-Agent
Was prüft ein Agent nach einem Release?
Er prüft fünf Schichten gegen vorher festgelegte Regeln: Status, Indexierung, Weiterleitungen, Canonical mit Sitemap und Darstellung. Zu jeder Regel hält er die Erwartung fest, dazu die Beobachtung mit ihrem Beleg.
Ersetzt der Agentenlauf die Search Console?
Nein. Die Schnittstelle zeigt die Fassung im Google-Index und prüft keine Live-Adresse.[4] Der Agent beantwortet die Frage, was gerade an der echten Adresse ausgeliefert wird.
Reicht robots.txt, um eine Seite aus Google herauszuhalten?
Nein. Google nennt dafür „noindex“ oder Passwortschutz, und eine gesperrte Adresse kann ohne Beschreibung in den Ergebnissen stehen.[2]
Wie viele Weiterleitungsschritte sind in Ordnung?
Wir legen für unsere Adressen einen Schritt als Soll fest. Eine Obergrenze nennt Google auf der Seite zu Weiterleitungen nicht,[1] deshalb ist das eine eigene Regel und keine Vorgabe.
Wie zuverlässig sind Ladezeit-Messungen im Lauf?
Als Hinweis gut, als einzelne Zahl schwankend. Lighthouse CI führt jede Seite dreimal aus, und größere Rechner liefern stabilere Werte.[6]
Weiterführend
Sichtbarkeit in Suche & KI
301-Redirects richtig einrichten: Weiterleitungen ohne Ranking-Verlust
301-Redirects sichern Rankings bei Relaunch, HTTPS-Umstellung und URL-Wechsel. Der KMU-Leitfaden erklärt Codes, Umsetzung und typische Fehler.
Website & Content-System
Website-Relaunch ohne Sichtbarkeitsverlust: der KMU-Fahrplan
Ein Website-Relaunch verliert Rankings, wenn URL-Mapping und Redirects fehlen. Der Fahrplan für KMU klärt auch, ob ein Relaunch der richtige Schritt ist.
Sichtbarkeit in Suche & KI
robots.txt erstellen und sicher prüfen
Die robots.txt steuert Crawler, schützt aber keine Daten. So setzen Sie Direktiven, Sitemap und Bot-Regeln ein und prüfen jede Änderung sicher.