Die Sitemap ist die langweiligste Datei Ihrer Website und oft die einzige, die seit der Abnahme niemand geöffnet hat. Was wir vorfanden und was Sie selbst prüfen können.
Die Sitemap ist die langweiligste Datei Ihrer Website. Sie ist auch oft die einzige Datei, die seit der Abnahme niemand geöffnet hat.
In einem aktuellen Projekt habe ich sie geöffnet, auf Wunsch des Auftraggebers, der den Verdacht hatte, dass etwas nicht stimmte. Darin standen sechs Adressen. Die Website hatte hunderte Seiten.
Es gab drei Sitemaps, und die angekündigte war die falsche
Was dort stand, war nicht die Datei, die das System erzeugt. Es war eine echte Datei im Webverzeichnis, übrig aus einem früheren Aufbau, und so eine Datei liefert der Webserver aus, bevor die Anfrage die Website überhaupt erreicht.
Es kam noch besser. In der robots.txt war eine dritte Datei angekündigt, von einem Plugin, das es nicht mehr gab. Es waren also drei Sitemaps im Umlauf: die angekündigte, die gefundene und die echte. Die ersten zwei existierten nur noch aus Gewohnheit.
Wenn Sie eines aus diesem Artikel mitnehmen: tippen Sie die Adresse Ihrer eigenen Sitemap in den Browser und sehen Sie hin. Nicht, was Ihr Verwaltungsbildschirm zu erzeugen behauptet, sondern was Ihre Domain tatsächlich ausliefert.
Die Leerzeile, die Ihre Anwendung öffnete
Ein Prüfwerkzeug meldete danach etwas zu den Disallow-Regeln in der robots.txt. Solche Meldungen sind oft Rauschen, aber diese stimmte, und zwar nicht für alle.
Google, Bing und jeder Leser, der dem heutigen Standard folgt, sehen eine Gruppe bei einer User-agent-Zeile beginnen und nehmen dann die spezifischste passende Regel. Die lasen die Datei richtig. Doch die ursprüngliche Vereinbarung von 1994 beendet eine Gruppe bei einer Leerzeile, und die einfacheren Crawler und Prüfwerkzeuge machen das bis heute. Die Standardbibliothek von Python gehört dazu, und die steckt unter einem guten Teil der Scanner.
In der Datei stand eine Leerzeile direkt unter der User-agent-Zeile. Für diese Leser war die Gruppe damit leer, und jedes Disallow darunter hing an keinem Bot. Zudem nehmen dieselben Leser die erste passende Regel, und die erste Regel war ein Allow für die ganze Website. Also doppelt tot.
Die Folge: für diesen Teil der Leser standen das Kundenportal, die Abmeldelinks und die ganze Verwaltung zum Crawlen offen. Nicht unsicher, denn darauf liegt eine Anmeldung, aber genau das, was Sie nicht in einem Index haben wollen.
Die Lösung ist unspektakulär. Innerhalb einer Gruppe trennt man die Teile mit Kommentarzeilen statt mit Leerzeilen, und man ordnet die Regeln von spezifisch nach allgemein. Die Datei liegt jetzt in der Versionsverwaltung, in einer Form, die unverändert auf alle Domains kopiert wird.
Die Sitemap neu, und warum über die Identität
Dann die Sitemap selbst. Sie wird nun in zwei Schritten gebaut: erst je Sprache sammeln, dann ausschreiben.
Der Schlüssel ist die Identität eines Eintrags, nicht seine Adresse. Das ist das Detail, an dem eine mehrsprachige Sitemap scheitert. Ein Produkt heißt auf Niederländisch anders als auf Deutsch, die Adresse ist also je Sprache verschieden, während es dasselbe Produkt ist. Schlüsseln Sie über die Adresse, sehen Sie vier einzelne Seiten. Schlüsseln Sie über die Identität, sehen Sie einen Eintrag in vier Sprachen.
Jede Adresse trägt jetzt die anderen Sprachen als Alternative bei sich, mit der Quellsprache als Rückfall für Besucher aus einem Land, das Sie nicht bedienen. Nur die Sprachen, in denen der Eintrag wirklich existiert, vollständig und auf beiden Seiten. Und es ist dieselbe Liste wie die Zeilen im Kopf der Seite selbst, die beiden können also nicht mehr auseinanderlaufen.
Bei vier Domains ist das wichtiger, als es klingt. Die Sitemap ist dann die einzige Stelle, an der auf einmal zu lesen ist, welche Adressen einander übersetzen. Google und die AI-Suchmaschinen übernehmen das direkt, statt vier Seiten zu holen und selbst etwas daraus zu machen.
Vier Lücken, und was sie kosten
Beim Neubau kamen vier Dinge hoch, die keiner der Beteiligten erwartet hatte.
Eine gewöhnliche indexierbare Seite stand in keiner Sitemap, obwohl der Fuß und zwei Seitenleistenkarten darauf verlinkten. Das ist eine Seite, die Sie selbst für wichtig halten und die Ihrer Suchmaschine nie angeboten wurde.
Eine Sprache ohne eigene Domain fiel vollständig aus den Sitemaps. So eine Sprache wohnt auf der Basisadresse, aber die Datei dieser Adresse lieferte nur ihre eigene Sprache. Eine vollständige Sprachfassung, die nirgends angemeldet wurde.
Ein noindex-Häkchen an einem Begriff wurde übergangen. Die Seite selbst setzte ein noindex, die Sitemap reichte also eine Adresse ein, die die Seite danach nicht indexieren lässt. Zwei Signale, die sich widersprechen, sind schlechter als ein klares Signal.
Und eine Seite mit einem Canonical auf eine andere Adresse stand unter ihrer eigenen Adresse darin. Das ist derselbe Fehler spiegelbildlich: Sie bitten um Indexierung einer Seite, die selbst sagt, dass sie woanders hingehört.
Keine Adressen, die nirgends ankommen
Die letzte Regel, die dazukam: eine Adresse gehört nicht in die Sitemap, wenn der Webserver den ersten Teil dieses Pfades selbst abfängt oder die robots.txt ihn schließt.
Diese Regel brachte sofort einen Fund. Die Anmeldeseite für den Newsletter hat auf Englisch und Deutsch einen Pfad, der mit dem Pfad des Newsletter-Moduls kollidiert. Der Webserver schickt diese Anfrage an das Modul, diese zwei Seiten sind also nicht zu öffnen. Nicht von einem Crawler und nicht von einem Besucher.
So wird eine Sitemap-Prüfung zu einem Weg, kaputte Seiten zu finden. Zwei Seiten, die in jeder Übersicht ordentlich auf veröffentlicht standen, waren nicht erreichbar.
Warum das für AI-Suche mehr wiegt
Eine klassische Suchmaschine crawlt viel und korrigiert unterwegs. Eine Antwortmaschine crawlt weniger, liest Struktur wörtlicher und gibt eine Antwort statt zehn Links.
Das macht Fehler teurer. Eine Sprachfassung, die nie angemeldet wurde, existiert für so eine Maschine nicht. Ein hreflang-Satz, der nur in eine Richtung zeigt, gibt ihr keinen Grund, Ihre deutsche Seite mit einer deutschen Frage zu verbinden. Und eine Adresse, die nicht öffnet, kostet Sie nicht einen Besucher, sondern das ganze Thema.
Was Sie in zehn Minuten selbst prüfen
Fünf Dinge, ohne Werkzeug.
Öffnen Sie die Adresse Ihrer Sitemap im Browser und zählen Sie die Einträge. Sehen Sie in der robots.txt nach, welche Sitemap dort angekündigt ist und ob es dieselbe ist. Suchen Sie in der robots.txt nach Leerzeilen innerhalb einer Gruppe. Nehmen Sie eine Seite, die in mehreren Sprachen existiert, und prüfen Sie, ob die Verweise auf beiden Seiten aufeinander zeigen. Und klicken Sie drei zufällige Adressen aus Ihrer Sitemap an, um zu sehen, ob sie öffnen.
Wenn dabei etwas herauskommt, ist es meist keine Kleinigkeit.
Auch lesenswert
- Slug-Richtlinie: warum die Adresse Ihrer Seite kein Freitextfeld ist, über die Adressen, die hier drinstehen
- Von WordPress zu einem Flat-File-CMS: umsteigen ohne Ihre Google-Positionen zu verlieren, über das, was bei einer Migration zurückbleibt
- Alle realisierten Projekte ansehen, Webplattformen und Automatisierungslösungen
Bert
Häufig gestellte Fragen
- Wie viele Adressen gehören in eine Sitemap?
- So viele, wie Sie indexierbare Seiten haben. Das klingt selbstverständlich, ist aber die schnellste Prüfung überhaupt: zählen Sie die Adressen in Ihrer Sitemap und stellen Sie das neben die Zahl der Seiten, die Sie zu haben glauben. Liegt ein Faktor dazwischen, sehen Sie eine andere Datei als gedacht, oder einen Generator, der die Hälfte überspringt.
- Ist ein Disallow in robots.txt ein Schutz?
- Nein, und diese Unterscheidung ist wichtig. Ein Disallow ist eine Bitte: anständige Suchmaschinen halten sich daran, der Rest ignoriert sie, und die Datei kann jeder lesen. Was wirklich abgeschirmt werden muss, gehört hinter eine Anmeldung oder hinter eine Sperre auf dem Webserver. Robots.txt nutzt man, um nützliche aber sinnlose Adressen aus einem Index zu halten, nicht um etwas geheim zu halten.
- Sollte man changefreq und priority verwenden?
- Nein. Google hat vor Jahren gesagt, dass es beide ignoriert, und die meisten anderen Leser tun dasselbe. Sie stehen oft noch drin, weil ein altes Plugin sie geschrieben hat. Lassen Sie sie weg: es sind zusätzliche Felder, die Sie pflegen müssen und die nichts bringen, und eine falsche priority erweckt den Eindruck, Sie versprächen etwas, das Sie nicht halten.