Monitoring-Abdeckung prüfen: Welche Seiten Sie vergessen

Grün heißt geprüft, nicht heil

Ein Prüfziel kann sich in drei Zuständen befinden, aber ein Dashboard kennt zwei Farben. Zustand eins: geprüft und in Ordnung. Zustand zwei: geprüft und defekt. Zustand drei: gar nicht geprüft. Die ersten beiden bekommen eine Farbe, der dritte bekommt keine Kachel, und genau darum sieht er aus wie der erste. Ein Bestand, der zu neunzig Prozent aus Zustand drei besteht, zeigt eine makellose Oberfläche.

Der Statuscode selbst sagt dabei weniger, als ihm zugeschrieben wird. Nach der HTTP-Semantik zeigt 200 an, dass die Anfrage erfolgreich war (RFC 9110) - nicht, dass die ausgelieferte Seite die richtige ist, aktuell ist oder das enthält, was sie enthalten soll. Und 404 zeigt an, dass der Server keine aktuelle Darstellung der angefragten Ressource gefunden hat oder deren Existenz nicht offenlegen will (RFC 9110); ob dieser Zustand vorübergehend oder dauerhaft ist, lässt der Code ausdrücklich offen. Wer die Zahl 200 mit dem Wort "in Ordnung" übersetzt, hat bereits eine Deutung eingebaut, die im Protokoll nicht steht.

Der HTTP Archive Web Almanac formuliert dieselbe Einschränkung am Beispiel der robots.txt sehr direkt: Eine Antwort mit Status 200 bestätigt lediglich, dass eine Datei existiert; über die Richtigkeit ihrer Anweisungen sagt sie nichts (Web Almanac 2025). Diese Unterscheidung überträgt sich auf jedes Prüfziel im Monitoring. Erreichbarkeit ist die schwächste aller Aussagen, die sich über eine Adresse treffen lässt, und in vielen Einrichtungen ist sie die einzige, die überhaupt erhoben wird.

Am schärfsten steht das Problem im Robots-Exclusion-Protokoll. Ist die robots.txt wegen Server- oder Netzwerkfehlern unerreichbar, gilt sie als undefiniert, und der Crawler muss eine vollständige Sperre annehmen (RFC 9309). Der Ausfall der Messung ist dort also kein neutraler Zustand, sondern hat eine festgelegte, harte Folge. Im Monitoring fehlt diese Festlegung meist: Fällt ein Lauf aus, gibt es entweder gar keinen Datenpunkt oder einen, den die Oberfläche behandelt wie einen bestandenen.

Was ein URL-Inventar ist

Ein URL-Inventar ist die vollständige, entdoppelte Liste aller Adressen, für die Sie sich verantwortlich fühlen - jede mit einem Vermerk, woher sie stammt, welchen Statuscode sie zuletzt geliefert hat, ob sie die kanonische Fassung ist und ob ein Prüfziel auf sie zeigt. Das klingt nach Buchhaltung, und es ist welche. Der Unterschied zur Seitenliste im Redaktionssystem: Das Redaktionssystem kennt nur, was es selbst erzeugt hat.

Was es nicht kennt, ist reichlich: die Weiterleitung, die vor zwei Jahren von Hand im Webserver eingetragen wurde; die PDF-Preisliste im Uploadverzeichnis; die Buchungsstrecke eines Fremdsystems, die unter Ihrer Domain läuft; das alte Kampagnenverzeichnis, das nur noch aus einer Anzeige heraus aufgerufen wird; der Produktfeed, den ein Partner stündlich abholt. Diese Adressen erscheinen in keinem Menü und in keiner Sitemap - aber wenn eine davon ausfällt, ruft jemand an.

Ein Inventar hat deshalb zwei Eigenschaften, die eine Seitenliste nicht hat. Es ist quellenübergreifend, und es merkt sich die Herkunft jeder Adresse. Die Herkunft ist kein Beiwerk: Eine Adresse, die ausschließlich im Serverprotokoll auftaucht, ist ein anderer Fall als eine, die in Sitemap, Crawl und Suchmaschinen-Index gleichzeitig steht. Der erste Fall verlangt eine Entscheidung, der zweite ist unstrittig geschäftsrelevant und gehört ohne Diskussion in den Prüfplan.

Vier Quellen, vier blinde Flecken

Praktisch kommen vier Quellen in Frage. Jede liefert einen echten Ausschnitt, und jede hat eine Grenze, die sich nicht durch Sorgfalt beheben lässt, weil sie aus der Bauart der Quelle folgt.

Die Sitemap ist die einzige der vier Quellen, in der Sie selbst der Autor sind. Genau deshalb ist sie in der Form die verlässlichste und im Inhalt die schwächste: Sie enthält, was der Generator hineinschreibt, und der Generator kennt dieselben Grenzen wie das Redaktionssystem, das ihn betreibt.

Das Serverprotokoll ist umgekehrt gebaut. Es behauptet nichts, es zeichnet auf. Dafür sieht es nur die Vergangenheit und nur das Fenster, das Ihre Aufbewahrung offen hält. Eine Seite, die es in vier Wochen auf keinen einzigen Abruf gebracht hat, existiert in dieser Quelle nicht, obwohl sie ausgeliefert würde, wenn jemand sie anfragte. Für Wartungs-, Rechts- und Archivseiten ist genau das der Normalfall.

Die Sitemap ist eine Meldung, kein Befund

Das Sitemap-Protokoll ist klar in dem, was es zusagt, und noch klarer in dem, was es nicht zusagt. Eine Sitemap hilft Suchmaschinen dabei, Adressen zu entdecken, sichert aber nicht zu, dass alle darin genannten Einträge gecrawlt und aufgenommen werden (Google Search Central). Sie ist ein Vorschlag, kein Vertrag. Für das Inventar heißt das: Was in der Sitemap steht, ist eine Aussage des Betreibers über den eigenen Bestand, keine Feststellung über den ausgelieferten Zustand.

Hinzu kommen harte Formgrenzen, an denen Inventare regelmäßig auseinanderbrechen, ohne dass es jemand bemerkt:

• Obergrenze je Datei. Jede Sitemap-Datei darf höchstens 50.000 Adressen enthalten und unkomprimiert nicht größer als 50 MB sein (sitemaps.org). Wer mehr Adressen hat, braucht mehrere Dateien und einen Sitemap-Index; fehlt der Index, bleibt der Rest des Bestands unsichtbar.
• Protokoll- und Hostbindung. Alle Adressen in einer Sitemap müssen dasselbe Protokoll verwenden und auf demselben Host liegen wie die Sitemap selbst (sitemaps.org). Adressen einer Subdomain gehören nicht hinein und werden verworfen - ein häufiger Grund dafür, dass ein Hilfe- oder Buchungsbereich im Inventar fehlt.
• Geltungsbereich des Ablageorts. Eine Sitemap deckt den Pfadbereich ab, in dem sie liegt. Wird sie in ein Unterverzeichnis verschoben, schrumpft ihr Geltungsbereich mit, ohne dass sich an der Datei selbst etwas ändert.
• Alterung ohne Rückmeldung. Ein Generator, der bei einem Fehler die zuletzt gültige Datei stehen lässt, liefert weiterhin Status 200 (RFC 9110). Das Inventar altert still, während die Prüfung des Sitemap-Abrufs grün bleibt.

Die letzte Zeile ist der Kern des Themas: Ein Sitemap-Check, der nur den Statuscode ansieht, prüft die Datei und nicht ihren Inhalt. Sinnvoll ist der Vergleich von Adressanzahl und jüngstem Änderungsdatum gegen den Vorlauf. Wie das als laufende Prüfung aussieht, steht im Beitrag zur Sitemap-Überwachung.

Serverprotokoll und Crawl widersprechen sich

Legen Sie die Adressliste aus dem Serverprotokoll neben das Ergebnis eines Crawls, stimmen beide Listen selten überein - und die Differenz ist der interessanteste Teil des Inventars. Adressen, die nur im Crawl stehen, werden ausgeliefert, aber von niemandem abgerufen. Adressen, die nur im Protokoll stehen, werden abgerufen, sind aber über die Website nicht erreichbar.

Der zweite Fall ist der gefährlichere, weil er verdeckt läuft. Dazu gehören Adressen aus alten Anzeigen, aus gedruckten Unterlagen, aus einer fest verdrahteten Partnerschnittstelle und aus Lesezeichen von Stammkunden. Sie stehen in keiner Sitemap und in keinem Menü, erzeugen aber echten Verkehr. Fällt eine davon auf 404, meldet das Monitoring nichts, weil sie ihm gar nicht bekannt ist. Das Muster ähnelt dem der verwaisten Seiten, nur andersherum: Dort fehlt der eingehende Verweis, hier fehlt der Eintrag im Prüfplan.

Der Crawl hat seinerseits zwei Grenzen. Er folgt nur dem, was im ausgelieferten Markup als Verweis steht; eine Adresse, die erst nach einem Klick durch ein Skript entsteht, findet er nicht. Und er hält sich an die robots.txt, deren Auswertegrenze bei mindestens 500 Kibibyte liegt (RFC 9309): Was in einer sehr großen Datei hinter dieser Grenze steht, lesen konforme Crawler nicht mehr. Praktisch greift das selten, denn 97,5 Prozent der Dateien auf dem Desktop und 97,6 Prozent auf mobilen Abrufen bleiben unter 100 Byte (Web Almanac 2025). Bemerkenswerter ist der Anteil von 1,8 Prozent vollständig leerer Dateien, denn für die leere Datei legt der Standard kein Verhalten fest (Web Almanac 2025).

Zwischengespeicherte Regeln kommen hinzu. Crawler sollen eine zwischengespeicherte robots.txt nicht länger als 24 Stunden verwenden, außer die Datei ist unerreichbar (RFC 9309). Ein Crawl, der die Sperren von gestern anwendet, liefert ein Inventar von gestern. Wer die Datei ändert und am selben Tag ein Ergebnis erwartet, misst unter Umständen noch den alten Stand. Die häufigsten Fehler dieser Art sammelt der Beitrag über robots.txt-Fehler.

Vereinigung, Normalisierung, Kanonisierung

Bevor die vier Listen zusammenpassen, müssen sie in dieselbe Schreibweise gebracht werden. Ohne diesen Schritt besteht die Differenz zwischen den Quellen zur Hälfte aus Formalien: Protokoll, Schreibweise des Hosts, Präfix mit oder ohne www, Schrägstrich am Ende, Reihenfolge und Vorhandensein von Parametern, Fragmentbezeichner, prozentkodierte Zeichen. Vier Listen mit je 1.200 Adressen ergeben nach naiver Vereinigung schnell 3.000 Einträge, von denen 1.800 dieselbe Seite meinen.

Der zweite Schritt ist die Kanonisierung. Ein Canonical-Verweis benennt, welche Fassung einer Seite die maßgebliche ist. Er liegt auf 68 Prozent der Desktop-Seiten und 67 Prozent der mobilen Seiten vor; 7 Prozent der Desktop- und 9 Prozent der mobilen Seiten sind ihrerseits kanonisiert, verweisen also auf eine andere Adresse als die maßgebliche (Web Almanac 2025). Für das Inventar heißt das: Rund zwei Drittel Ihrer Adressen tragen die Antwort auf die Entdopplungsfrage bereits selbst mit sich.

Das übrige Drittel und die Widersprüche bleiben Handarbeit. Widersprüche gibt es messbar: Bei 0,7 Prozent der Seiten weichen die Canonical-Angaben voneinander ab (Web Almanac 2025). Das klingt wenig, trifft aber bei zehntausend Adressen rund siebzig Seiten, und es sind selten die unwichtigen, weil solche Konflikte dort entstehen, wo mehrere Systeme dieselbe Seite ausliefern. Für den Prüfplan gilt: Überwacht wird die kanonische Fassung, die Varianten bekommen einen Verweis auf sie und keinen eigenen Eintrag.

Ebenso wichtig ist der Umgang mit Statuscodes im Inventar. Eine Adresse, die dauerhaft weiterleitet, gehört als Weiterleitung geführt und nicht als Seite; ihr Prüfziel ist das Ziel der Weiterleitung samt der Weiterleitung selbst. Der unangenehmste Fall ist eine Adresse, die eine Fehlermeldung mit Status 200 ausliefert - sie zählt in jeder Statistik als heil. Wie sich das erkennen lässt, beschreibt der Beitrag über Soft-404-Seiten.

Von der Liste zur Abdeckungsquote

Ein Inventar ohne Kennzahl bleibt eine Datei. Die Kennzahl, die aus ihm folgt, ist die Abdeckungsquote: der Anteil der Adressen im Inventar, für den ein aktives Prüfziel existiert und für den innerhalb des erwarteten Intervalls auch ein Ergebnis vorliegt. Beide Bedingungen zählen. Ein Prüfziel, das seit elf Tagen kein Ergebnis geliefert hat, deckt nichts ab.

In der Praxis führt man drei Quoten nebeneinander, weil sie unterschiedliche Fehler sichtbar machen:

1. Rohe Abdeckung. Prüfziele geteilt durch Inventarumfang. Zeigt, wie groß der ungeprüfte Rest überhaupt ist.
2. Gewichtete Abdeckung. Dieselbe Rechnung, gewichtet nach Abrufen oder Umsatzbeitrag aus dem Serverprotokoll. Zeigt, ob die geprüften Adressen die wichtigen sind - eine rohe Quote von 20 Prozent kann eine gewichtete von 95 Prozent bedeuten, und umgekehrt.
3. Wirksame Abdeckung. Prüfziele mit einem frischen Ergebnis geteilt durch Inventarumfang. Zeigt den Ausfall der Messung selbst und ist die einzige der drei Quoten, die fällt, wenn ein Prüfknoten stillsteht.

Die dritte Quote ist die, die im Alltag fehlt. Sie beantwortet nicht die Frage "Ist die Website in Ordnung?", sondern die Frage "Weiß ich, ob die Website in Ordnung ist?". Wie eng die Aussagekraft am Prüfintervall hängt, steht im Beitrag über Prüfintervalle und Erkennungszeit; welche Kennzahlen auf eine Übersicht gehören, im Beitrag über das Monitoring-Dashboard.

Welche Adressen typischerweise fehlen

Die Lücken sind über Websites hinweg erstaunlich ähnlich. Es sind fast durchweg Adressen, die kein Mensch anklickt, solange alles läuft - und die genau deshalb beim Einrichten des Monitorings niemandem einfallen.

Ein Muster verbindet die sechs Punkte: Der Ausfall fällt zunächst niemandem auf, hat aber Folgen - rechtliche, vertragliche oder finanzielle. Genau dafür ist ein Inventar da. Für Abläufe, die über mehrere Seiten laufen, reicht ein Statuscode ohnehin nicht; dort gehören synthetische Browser-Prüfungen hin, und für Hintergrundarbeiten ohne eigene Adresse Heartbeats.

Wenn der Ausfall der Messung als Ergebnis zählt

Bis hierhin ging es um Adressen ohne jedes Prüfziel. Der zweite, schwerer zu findende Fall betrifft Prüfziele, die es gibt, die aber kein Ergebnis liefern - und deren Schweigen als Ruhe gelesen wird.

Die Ursachen wiederholen sich. Der Prüfknoten steht still, aber sein Ausfall wird nicht überwacht. Eine Zeitüberschreitung wird als "kein Befund" statt als eigener Zustand verbucht; im Almanac ist sie eine ausgewiesene Kategorie und tritt bei 1,0 Prozent der Desktop- und 1,1 Prozent der mobilen robots.txt-Abrufe auf (Web Almanac 2025). Ein Zertifikatsfehler bricht die Verbindung ab, bevor ein Statuscode entsteht, und das Ergebnis fällt aus der Auswertung. Eine Sperre in der robots.txt hält den eigenen Crawler von einem Teil des Bestands fern, und dieser Teil erscheint als "nichts gefunden" statt als "nicht geprüft".

Das Robots-Protokoll zeigt, wie die saubere Trennung aussieht: Es unterscheidet ausdrücklich zwischen einer Datei, die per Statuscode als nicht verfügbar gemeldet wird, und einer, die unerreichbar ist. Im ersten Fall darf ein Crawler auf alle Ressourcen zugreifen, im zweiten muss er eine vollständige Sperre annehmen (RFC 9309). Das ist eine bewusste, ausgeschriebene Entscheidung darüber, wie ein Messausfall zu behandeln ist. Ein Monitoring braucht dieselbe Entscheidung, und zwar sichtbar.

Praktisch heißt das: drei Zustände in der Datenhaltung statt zwei, eine eigene Alarmregel für ausbleibende Ergebnisse und ein Zähler für die Läufe, die überhaupt stattgefunden haben. Eine Website, die seit sechs Tagen keine Prüfung erhalten hat, muss anders aussehen als eine, die seit sechs Tagen ohne Befund geblieben ist. Dieselbe Unterscheidung entscheidet darüber, ob Alarme Vertrauen verdienen; wie man sie so einstellt, dass sie nicht abstumpfen, steht im Beitrag über die Konfiguration von Alarmen.

Das Inventar aktuell halten

Ein Inventar, das einmal erstellt und dann abgelegt wird, ist nach einem Quartal wieder falsch. Die Pflege besteht aus vier wiederkehrenden Schritten, die sich vollständig automatisieren lassen.

Der letzte Punkt ist der wirksamste. Ein Vergleich des Inventars vor und nach einer Umstellung fängt genau die Fehlerklasse ab, die bei Umbauten entsteht: Adressen, die es danach nicht mehr gibt, ohne dass eine Weiterleitung eingerichtet wurde. Das Vorgehen dafür beschreibt der Beitrag zur Migrationsüberwachung.

Beim Ergänzen des Inventars hilft die Erinnerung an eine Grundtatsache: Es gibt kein zentrales Verzeichnis aller Webseiten, weshalb Suchmaschinen fortlaufend nach neuen und geänderten Seiten suchen müssen (Google Search Central). Was für Suchmaschinen gilt, gilt für Sie in Ihrem eigenen Bestand ebenso - die Liste entsteht nicht von selbst, sie wird gebaut und fortgeschrieben.

Der nächste Schritt

Fangen Sie nicht mit dem Werkzeug an, sondern mit der Zählung. Exportieren Sie die vier Listen einmal von Hand, normalisieren Sie sie, bilden Sie die Vereinigung und zählen Sie, wie viele Adressen darin stehen. Vergleichen Sie diese Zahl mit der Anzahl Ihrer aktiven Prüfziele. Das Verhältnis beider Zahlen ist Ihre rohe Abdeckungsquote, und in den meisten Fällen fällt sie deutlich niedriger aus als erwartet.

Danach ist die Reihenfolge einfach: zuerst die Adressen mit Verkehr aufnehmen, dann die rechtlich vorausgesetzten, dann die Abläufe mit mehreren Schritten, zuletzt die Randbereiche. Wer Nutzerpfade und Seitenübergänge ohnehin auswertet, hat die halbe Datengrundlage bereits im Haus. Für die technischen Prüfziele, die dabei entstehen, gibt es das API-Monitoring und die Statusseite mit Bericht; was in welchem Tarif enthalten ist, zeigt die Preisübersicht.