Verwaiste Seiten finden: Was intern niemand verlinkt

Was eine Seite verwaist macht

Verwaist heißt nicht kaputt. Die Seite antwortet, der Inhalt ist vollständig, das Layout stimmt. Der Defekt sitzt nicht in der Seite, sondern im Verweisgraphen der Website: Es gibt keinen Pfad, der von der Startseite über anklickbare Verweise zu dieser Adresse führt. Genau darum fällt der Zustand bei der üblichen Sichtprüfung unbemerkt - wer die Adresse kennt und aufruft, sieht eine einwandfreie Seite. Nur wer den Graphen von außen nachzeichnet, sieht die Lücke.

In der Praxis begegnen einem drei Abstufungen. Vollständig verwaist ist eine Seite, auf die im ausgelieferten HTML keiner Ihrer eigenen Inhalte verweist. Faktisch verwaist ist sie, wenn der einzige eingehende Verweis von einer Seite kommt, die selbst nicht indexierbar ist oder ihrerseits nicht erreicht wird - der Zubringer hängt dann an derselben Insel. Und praktisch verwaist ist eine Seite, deren einziger Zugang über ein Formular, einen Parameter oder eine erst nach Klick eingesetzte Skript-Aktion entsteht: Ein Crawler, der nur das gelieferte Markup liest, kommt dort nicht an.

Die Unterscheidung ist keine Wortklauberei, sie entscheidet über die Gegenmaßnahme. Eine vollständig verwaiste Seite braucht einen Verweis von der thematisch passenden Übersicht. Eine faktisch verwaiste Seite braucht zuerst die Reparatur ihres Zubringers, sonst verlagern Sie das Problem nur um eine Ebene. Und eine praktisch verwaiste Seite braucht meist gar keinen Verweis, sondern eine Entscheidung: Soll dieser Zustand überhaupt eine eigene Adresse haben?

Wie eine Adresse überhaupt entdeckt wird

Suchmaschinen arbeiten die Entdeckung in Stufen ab, und nicht jede Adresse übersteht jede Stufe (Google Search Central). Am Anfang steht die Frage, wie eine Adresse überhaupt bekannt wird. Der Regelweg ist der Verweis: Ein Crawler folgt Adressen, die er auf bereits abgerufenen Seiten gefunden hat - liegt kein solcher Verweis vor, bleibt die Seite unter Umständen unentdeckt (Google Search Central). Eine Übersichtsseite, die auf einen neuen Beitrag zeigt, ist damit kein Komfort, sondern der Transportweg.

Der zweite Weg ist die XML-Sitemap. Sie meldet Adressen ohne jeden Kontext an - ohne Ankertext, ohne Position im Dokument, ohne Umfeld. Deshalb ist sie ein Hinweis, keine Zusicherung: Sie hilft beim Auffinden, sichert aber nicht zu, dass alle enthaltenen Einträge gecrawlt und indexiert werden (Google Search Central). Gerade auf großen Websites ist es erfahrungsgemäß schwieriger sicherzustellen, dass jede Seite von mindestens einer anderen Seite verlinkt wird, weshalb neue Seiten dort eher übersehen werden (Google Search Central). Die Sitemap federt diesen Fall ab, ersetzt die Verlinkung aber nicht.

Auch die Sitemap selbst hat harte Grenzen. Je Datei sind höchstens 50.000 Adressen und 50 MB erlaubt, größere Bestände müssen über eine Indexdatei aufgeteilt werden (sitemaps.org). Wer diese Grenze überschreitet oder eine kaputte Indexdatei ausliefert, verliert genau den Ersatzweg, auf den er sich verlässt. Wie sich die Sitemap dauerhaft prüfen lässt, behandelt der Beitrag zum Sitemap-Monitoring.

Woran verwaiste Seiten typischerweise entstehen

Verwaiste Seiten sind selten ein einzelner Fehler. Sie sind der Rückstand normaler Arbeit an einer Website: Etwas wird umgebaut, der Inhalt bleibt liegen, und niemand prüft danach den Graphen. Diese Muster tauchen erfahrungsgemäß am häufigsten auf.

1. Menüumbau ohne Nachlauf. Ein Punkt fliegt aus der Navigation, die dahinterliegenden Seiten bleiben online. War die Navigation der einzige Zubringer, sind sie ab diesem Deploy verwaist.
2. Kampagnenseiten aus dem Außenkanal. Landingpages, die nur in Anzeigen, in einem Newsletter oder auf einer Messeunterlage standen, tauchen im eigenen Bestand gar nicht auf.
3. Abgeschaltete Paginierung. Archiv- und Kategorieseiten ab Seite drei verschwinden, sobald ein Umbau die Blätterleiste durch eine Nachladefunktion ersetzt.
4. Filter- und Facettenseiten. Adressen, die nur aus Formularparametern entstehen, existieren im Markup nicht als Verweis - und sind trotzdem indexierbar.
5. Relaunch ohne Übernahme der Verweisstruktur. Der Inhalt wandert mit, die Querverweise aus dem Fließtext nicht. Das ist der größte Einzelposten in fast jeder Migration.
6. Verweise, die erst ein Skript einsetzt. Was nach einem Klick oder beim Scrollen nachgeladen wird, steht im ausgelieferten HTML nicht und zählt für die Entdeckung nicht.
7. Downloads und Merkblätter. PDF-Übersichtsseiten, die nur aus einer E-Mail heraus angesteuert wurden, hängen nach dem Versand ohne Zubringer da.
8. Sprachfassungen ohne durchgehenden Umschalter. Sitzt der Sprachwechsel nur auf der Startseite, ist die halbe Übersetzung von innen heraus nicht erreichbar.

Auffällig ist die zeitliche Verteilung: Die meisten dieser Fälle entstehen an einem Stichtag, nämlich beim Deploy eines Umbaus, und nicht schleichend. Wer den Abgleich nur einmal im Jahr fährt, sieht das Ergebnis, aber nicht den Auslöser. Für Migrationen im Besonderen lohnt der separate Blick auf das Monitoring einer Website-Migration, weil dort mehrere dieser Muster gleichzeitig auftreten.

Verwaiste Seite und toter Verweis sind Gegenrichtungen

Beide Befunde sind Defekte im selben Graphen, aber sie zeigen in entgegengesetzte Richtungen. Ein toter Verweis ist eine Kante ohne Ziel: Der Verweis existiert, die Adresse dahinter antwortet nicht mehr. Eine verwaiste Seite ist ein Ziel ohne Kante: Die Adresse antwortet einwandfrei, nur zeigt nichts auf sie. Der Bestand an Ratgebern behandelt fast ausschließlich die erste Richtung, was verständlich ist - sie ist billiger zu messen.

Genau darin liegt die Asymmetrie. Ein toter Verweis fällt beim Crawl von selbst an: Der Crawler folgt der Kante und bekommt einen Fehlerstatus zurück. Der Ratgeber zur Überwachung toter Verweise beschreibt diesen Weg im Detail. Eine verwaiste Seite fällt beim Crawl gerade nicht an, denn der Crawler kommt dort gar nicht vorbei. Sie wird nur sichtbar, wenn der Crawl gegen eine zweite, unabhängig erzeugte Liste gestellt wird. Ein Crawl allein kann diese Frage grundsätzlich nicht beantworten.

Dazu kommt der Sonderfall der Seiten, die zwar antworten, aber inhaltlich leer sind und trotzdem Status 200 melden. Sie erscheinen im Crawl als gültige Knoten und verdecken damit den Blick auf die tatsächliche Struktur; wie sich das erkennen lässt, behandelt der Beitrag zu falschen Statuscodes. Für den Abgleich gilt: Erst die Statuscodes sortieren, dann die Mengen vergleichen.

Ein dritter Punkt betrifft die Qualität vorhandener Kanten. Auf Unterseiten tragen 92,42 Prozent der Desktop-Websites beschreibende Verweistexte, auf Startseiten sind es 84,64 Prozent (Web Almanac). Ein Verweis mit nichtssagendem Ankertext zählt für die Entdeckung mit, trägt aber wenig zur Einordnung bei. Beim Aufräumen einer verwaisten Seite lohnt deshalb beides: die Kante setzen und ihr einen Text geben, der das Ziel benennt.

Vier Listen und ihre Differenzen

Die Suche nach verwaisten Seiten ist im Kern eine Mengenlehre-Aufgabe. Sie brauchen mindestens zwei Listen, besser vier, und der Befund steckt nicht in einer Liste, sondern in der Differenz zwischen ihnen. Jede der vier Quellen kennt Adressen, die die anderen nicht kennen - und genau dieser Überhang ist die Ausbeute.

Die erste Differenz ist die wichtigste: alles, was in der Sitemap steht und im Crawl fehlt. Weil die Sitemap in der Regel direkt aus der Datenbank des Redaktionssystems entsteht, kennt sie den Sollzustand; der Crawl kennt den Istzustand. Achten Sie dabei auf die Formatgrenzen - bei mehr als 50.000 Adressen je Datei liegt der Bestand verteilt vor (sitemaps.org), und wer nur die erste Datei einliest, erzeugt sich seine Differenz selbst.

Die zweite Differenz kommt aus dem Serverprotokoll und ist die ehrlichste: Was abgerufen wurde, existiert. Adressen, die dort auftauchen und im Crawl fehlen, sind entweder verwaist oder werden von außen angesteuert. Die dritte Differenz stammt aus den Aufrufdaten und ist die wirtschaftlich interessanteste, weil sie zeigt, welche verwaisten Seiten trotzdem Publikum haben. Wie sich Übergänge zwischen Seiten dafür auswerten lassen, beschreibt der Beitrag zu Nutzerpfaden und Seitenübergängen - verwaiste Seiten fallen dort dadurch auf, dass sie als Einstieg vorkommen, aber in keinem Pfad als Zwischenschritt.

Eine vierte, oft übersehene Quelle ist die interne Suche Ihrer eigenen Website. Suchbegriffe ohne Treffer und Suchen, die in einem Seitenaufruf enden, zeigen, welche Inhalte Menschen erwarten und über die Navigation nicht finden. Der Beitrag zur Auswertung der internen Suche geht auf die Auswertung ein; für unser Thema ist vor allem der zweite Fall aufschlussreich, weil er verwaiste Seiten mit echtem Bedarf markiert. Wie breit ein Bestand insgesamt überwacht ist, behandelt der Beitrag zur Abdeckung des URL-Inventars.

Den Crawl so aufsetzen, dass er die Wahrheit misst

Der Crawl liefert die Bezugsgröße für alles Weitere. Ist er zu eng eingestellt, meldet er verwaiste Seiten, die keine sind; ist er zu weit, verschwindet der Befund im Rauschen. Diese Punkte entscheiden über die Belastbarkeit des Ergebnisses.

• Nur ausgeliefertes Markup zählt. Als Kante gilt ein Verweis, der im HTML steht, das der Server ausgibt. Was erst eine Nutzeraktion einsetzt, ist für die Entdeckung ohne Wirkung (Google Search Central).
• Weiterleitungen auflösen, nicht zählen. Eine Kette aus mehreren Sprüngen erzeugt Zwischenknoten, die keine echten Seiten sind; der Beitrag zu Weiterleitungsketten zeigt, warum sie getrennt gehören.
• noindex sauber trennen. Die Anweisung findet sich auf 3,5 Prozent der Desktop-Websites und 2,4 Prozent der mobilen (Web Almanac). Eine solche Seite darf Kanten weitergeben, taugt aber nicht als einziger Zubringer - dann hängt das Ziel faktisch an einer Insel.
• Meta-Robots auf beiden Wegen lesen. Meta-Robots-Anweisungen kommen auf 47,0 Prozent der Desktop-Websites und 47,9 Prozent der mobilen vor (Web Almanac); wer nur das Meta-Element und nicht den HTTP-Kopf auswertet, übersieht einen Teil.
• Canonical mitschreiben. 68 Prozent der Desktop-Seiten führen ein Canonical-Element, mobil sind es 67 Prozent (Web Almanac). Zeigt es woandershin, ist die Adresse kein eigenständiges Ziel und gehört nicht in die Kandidatenliste.
• Den Dokumentkopf prüfen. Auf 10,1 Prozent der Desktop-Websites und 10,3 Prozent der mobilen stehen ungültige Elemente im Kopfbereich (Web Almanac) - das kann nachfolgende Anweisungen abschneiden und Ihr Crawl-Ergebnis verfälschen.
• Statuscodes vorher sortieren. Auf 13,3 Prozent der Desktop-Websites und 13,2 Prozent der mobilen antwortet mindestens eine geprüfte Ressource mit 404 (Web Almanac); solche Adressen gehören nicht in den Mengenvergleich.
• Die Ausschlussdatei ernst nehmen. Die Verarbeitung von mindestens 500 Kibibyte robots.txt ist vorgeschrieben (IETF); alles darüber darf ein Client ignorieren. Eine überlange Datei kann also Regeln enthalten, die praktisch folgenlos bleiben.

Ein eigener Fallstrick ist die versehentliche Sperre. Kommt bei einem Deploy eine noindex-Anweisung auf Seiten, die sie nicht haben sollten, verschwinden diese aus dem Index und wirken später wie verwaiste Seiten, obwohl der Graph in Ordnung ist. Der Beitrag zum noindex-Leak nach dem Deploy beschreibt den Ablauf; für den Abgleich heißt das: Die Indexierbarkeit gehört als eigene Spalte in den Bericht und nicht in den Filter.

Vom Fund zur Entscheidung

Eine gefundene verwaiste Seite ist noch kein Auftrag. Der häufigste Fehler nach dem ersten Abgleich besteht darin, jede Adresse aus der Liste irgendwo zu verlinken - das Ergebnis ist eine Fußzeile mit dreißig Verweisen, die niemandem hilft und die Struktur der Website verwischt. Sinnvoll sind drei Ausgänge, und der Befund selbst liefert die Entscheidungsgrundlage: Aufrufe, Alter, Thema und Statuscode.

Der Umfang bestimmt die Reihenfolge. Die Hinweise zum Crawl-Budget richten sich ausdrücklich an große Websites mit mehr als einer Million Adressen und mäßig häufigen Änderungen sowie an mittlere und größere Websites ab 10.000 Adressen mit sehr schnell wechselnden Inhalten (Google Search Central). Unterhalb dieser Größenordnungen ist das Argument gegen verwaiste Seiten nicht das Crawl-Budget, sondern schlicht die Auffindbarkeit für Menschen. Und selbst oberhalb gilt: Nicht jede gecrawlte Seite wird zwangsläufig indexiert (Google Search Central).

Ein nützlicher Zwischenschritt ist die Sortierung nach Aufrufen aus dem Serverprotokoll. Seiten mit regelmäßigen Zugriffen und ohne internen Zubringer sind die lohnendsten Kandidaten, weil dort bereits Nachfrage nachweisbar ist. Seiten ohne Zugriffe und ohne Verweis sind dagegen der eigentliche Ballast - sie kosten Pflege und liefern nichts. Wie sich solche Prüfungen dauerhaft automatisieren lassen, beschreibt der Beitrag zum technischen SEO-Monitoring.

Auffindbarkeit ist auch eine Anforderung der Barrierefreiheit

Der Blick auf verwaiste Seiten wird meist rein als SEO-Frage geführt. Das greift zu kurz. Die Web Content Accessibility Guidelines verlangen im Erfolgskriterium 2.4.5 auf Stufe AA mehr als einen Weg, um eine Seite innerhalb einer Menge von Seiten aufzufinden - ausgenommen sind nur Seiten, die Ergebnis oder Schritt eines Vorgangs sind (W3C). Eine verwaiste Seite hat nicht einen Weg zu wenig, sie hat null.

Auf der gesetzlichen Seite zieht das Barrierefreiheitsstärkungsgesetz dieselbe Linie. Produkte und Dienstleistungen gelten dort als barrierefrei, wenn sie in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind (BFSG). Das Wort auffindbar steht dabei vor zugänglich und nutzbar - eine Reihenfolge, die zur Sache passt: Was niemand findet, muss auch nicht zugänglich sein.

Praktisch heißt das: Der zweite Weg zu einer Seite sollte kein Notbehelf sein. Neben der Hauptnavigation eignen sich eine gepflegte Übersichtsseite, thematische Verweise im Fließtext und eine funktionierende interne Suche. Wer die Anforderungen im Zusammenhang betrachten will, findet die Einordnung unter Barrierefreiheit nach BFSG.

Verwaiste Seiten dauerhaft im Blick behalten

Ein einmaliger Abgleich räumt den Altbestand auf und ist danach wertlos, denn der nächste Umbau erzeugt neue Fälle. Der Abgleich gehört deshalb in denselben Takt wie der Deploy: erzeugen, vergleichen, melden. Entscheidend ist nicht die Frequenz an sich, sondern die Verknüpfung mit dem Zeitpunkt, an dem Änderungen live gehen.

• Crawl und Sitemap im selben Lauf erzeugen, damit die beiden Listen denselben Stand abbilden und die Differenz nicht aus Zeitversatz besteht.
• Adressen einheitlich normalisieren: Protokoll, Domain mit und ohne www, Schrägstrich am Ende, Groß- und Kleinschreibung, Sortierung der Parameter.
• Den Bericht auf Neuzugänge filtern. Interessant ist, was seit dem letzten Lauf hinzugekommen ist - der Altbestand steht sonst in jedem Bericht und stumpft ab.
• Schwelle statt Einzelmeldung. Ein Alarm ab einer bestimmten Zahl neuer Fälle je Lauf trifft die Deploy-Ausreißer, ohne bei jeder redaktionellen Änderung anzuschlagen.
• Die Sitemap gesondert prüfen, weil sie den Ersatzweg trägt; ein schneller Blick gelingt mit dem Sitemap-Prüfwerkzeug.
• Den Befund an die Redaktion ausspielen, nicht nur an die Technik - die Entscheidung verlinken, zusammenführen oder stilllegen ist eine inhaltliche.
• Verlauf aufheben. Erst die Zeitreihe zeigt, welcher Umbau welchen Ausschlag erzeugt hat; ein Bericht mit Statusseite hält das ohne Zutun fest.

Damit wird aus einer Aufräumaktion ein Regelkreis. Der Aufwand nach dem ersten Durchgang ist gering, weil nur noch Differenzen zur Vorwoche anfallen - typischerweise eine Handvoll Adressen statt einer langen Liste. Welche Prüfintervalle und welcher Umfang zu einem Bestand passen, zeigt die Preisübersicht.