Performance nach Relaunch verbessern: 404-Fehler vermeiden
Jeder, der eine Zeit lang im Web gearbeitet hat, kennt den leidigen Fehler "404". Er erscheint, wenn man eine Seite aufruft, die es eigentlich nicht gibt.
Um diesen Fehler soll es im heutigen Blog-Eintrag gehen: Warum es gut ist, ihn zu vermeiden, wie eine von uns gebaute Extension dabei hilft - und wie sie nebenbei das Google-Ranking verbessert.
Was ist der 404-Fehler?
Der Fehler mit der merkwürdigen Nummer entsteht auf einer recht technischen Ebene im Internet. Ein Nutzer steuert eine bestimmte Seite an, z.B. wichtige-domain.de/kontakt. Diese Anforderung wird über mehrere Zwischenschritte weiter geleitet, bis sie schließlich einen Webserver erreicht. Er ist dafür zuständig, diese Seite aus seinem Speicher zu holen und an den Nutzer zurück zu senden. Der Vorgang dauert normalerweise nur Sekundenbruchteile.
Was aber, wenn der Server die entsprechende Seite nicht kennt? Dann sendet er eine entsprechende Meldung an den Nutzer zurück - und damit es schnell geht, fasst er sich kurz: "404". Wer mag, kann in offiziellen Verzeichnissen nachschlagen und findet die menschenlesbare Übersetzung: "Page not found" - Seite nicht gefunden.
Wie geht TYPO3 mit dem 404-Fehler um?
Innerhalb von TYPO3 lässt sich genau einstellen, was passieren soll, wenn eine nicht vorhandene Seite aufgerufen wird. Das ist dann (technisch gesehen) zwar kein richtiger 404-Fehler mehr, weil ja der Webserver bei TYPO3 anfragt und er von dort durchaus eine Antwort zurück bekommt.
TYPO3 veranlasst dann aber selbst, dass der Fehlercode "404" gesendet wird. Zusätzlich schickt TYPO3 eine individuell gestaltete Seite an den Nutzer zurück. So bleibt dieser nicht ganz so ratlos zurück wie nach einer kümmerlichen Server-Antwort. Auch auf unserer Seite ist das entsprechend konfiguriert: https://metapublic.com/dieseSeiteGibtEsNicht
Wie entstehen 404-Fehler?
Zunächst einmal: Eine solcher Fehler lässt sich jederzeit mutwillig erzeugen. Jeder Internet-Nutzer kann jede fremde Seite mit sinnlosen Anfragen traktieren und erhält dann die (zutreffende) Antwort, dass die Seite nicht existiert.
Interessanter ist die Frage, unter welchen Umständen solche Fehler auch bei nicht-mutwilligen Nutzern auftreten können.
Ein übliches Szenario ist das Umbenennen von Seiten: Der Redakteur benennt vielleicht die Seite "news" um in "Nachrichten". Folglich ist .../news nicht länger erreichbar. Jetzt heißt es .../nachrichten.
Hat der Nutzer die alte Seite .../news bei sich noch abgespeichert, vielleicht als Bookmark in seinem Browser, so landet er auf dem berüchtigten 404-Fehler.
Dasselbe kann passieren, wenn er einem veralteten Link von einer Suchmaschine folgt. Nach einiger Zeit merkt übrigens auch die Suchmaschine, wenn ein solcher Link ins Leere führt und löscht ihn aus ihrem Index. Für die entsprechende Seite ist das ein eher schlechtes Zeichen: Sie ist wenig gepflegt und verliert Reichweite.
404-Disaster nach einem Relaunch
Besonders gefährlich ist in diesem Zusammenhang der Relaunch einer Webseite. Dabei wird oft nicht nur das Aussehen der Seite überarbeitet, sondern zugleich die Struktur. Seiten werden umbenannt und verschoben. Manche fallen ganz weg, andere werden vielleicht zusammengefasst zu einer einzigen.
Nach einem Relaunch gibt es also viele ehemalige Links, die auf der neuen Seite nicht mehr anzutreffen sind.
Trifft eine Suchmaschine auf viele solcher veralteten Links, sinkt die Reputation ganz schnell.
Besser ist es, der Suchmaschine und damit auch den Nutzern mitzuteilen, wo die entsprechende neue Seite liegt. Das ist dann eine so genannte "301"-Weiterleitung. Dieser Code signalisiert der Suchmaschine und dem Browser, dass die entsprechende Seite dauerhaft umgezogen ist. Statt .../news muss man eben jetzt .../nachrichten eingeben.
Die Reputation bleibt erhalten, der Nutzer merkt im besten Fall nicht einmal, dass sich etwas geändert hat, weil er ja die Inhalte erreicht, die er sucht.
Mit einem TYPO3 Widget alle 404-Fehler im Blick behalten
Trotz sorgfältiger Vorbereitung kann es bei einem Relaunch immer wieder passieren, dass man einzelne (301)-Weiterleitungen vergessen hat.
Oft genug haben Nutzer noch Bookmarks aus früheren Zeiten bei sich gespeichert, oder Suchmaschinen arbeiten langsamer als erhofft.
Wir haben deshalb das Dashboard von TYPO3 genutzt, um einen laufenden Überblick über die 404-Fehler zu bekommen.
Redakteure können damit bequem überwachen, welche alten Links noch angesteuert werden und diese dann per Redirect-Modul auf die passenden Seiten weiter leiten.
Die Liste des Widgets greift zurück auf das Logfile des Servers und zeigt die gesammelten Werte des Vortags an. Man sieht, ganz oben, unter "lines total", wie oft der Server angefragt wurde.
Darunter, unter "ignorierte Requests", erkennt man die Anzahl der Versuche, sich zum Beispiel an einem Wordpress-Backend anzumelden. Das sind automatisierte Vorgänge, die nicht unterbunden werden können und natürlich bei einer TYPO3-Seite nicht zum Erfolg führen. Daher werden sie gar nicht erst angezeigt.
Weiter unten sieht man dann echte Zugriffe, woher auch immer sie kommen.
Mit dieser Information kann jetzt der Redakteur entscheiden, wohin die Zugriffe gelenkt werden sollen.
Zwei Tage nachdem er dann einen Redirect eingerichtet hat, sollte dann dieser 404-Fehler nicht mehr in der Liste auftauchen.
Das 404-Widget kann noch mehr
Natürlich zeigt das Widget nicht nur die 404-Fehler an, sondern auch alle anderen, die vom Server zurück gemeldet werden. Für viele Redakteure ist diese Information allerdings nicht relevant, weshalb wir hier nicht weiter darauf eingehen wollen.
Für die Zukunft planen wir, das Widget öffentlich zugänglich zu machen. Im Augenblick fehlt dazu die Zeit - und noch ein geeigneter Name. Sobald beides vorhanden ist, werden wir den nächsten Schritt gehen.
Kontaktieren Sie uns gerne
Wenn Sie einen guten Namensvorschlag haben oder dieses (oder ein anderes) Widget benötigen, so rufen Sie uns einfach an: Für Vorschläge sind wir offen; unser Wissen teilen wir gerne. Tel: 089 38 15 76 400