Soft 404 Fehler

Es gehört zum guten Ton, dass eine Webseite beim Aufruf von nicht vorhandenen URLs keine hässliche Textmeldung liefert, sondern eine weiterführende Fehlerseite wie. z.B. dies: 404 Fehler. Allerdings gibt es hier zwei Möglichkeiten, dies zu gestalten:

  • 404 ErrorCode mit eigener Seite
  • 302 Weiterleitung auf "schöne 404 Seite"

Der Unterschied ist auf den ersten Blick für den Anwender nicht zu erkennen. Für Suchmaschinen aber schon.

Soft 404 Fehler und Suchmaschinen

Schaue ich mir in den Webmastertools meine MSXFAQ an (Stand Feb 2016), dann sind da schon einige Soft-404 zu sehen.

Wegen 130-200 solcher "Fehler würde ich nun nicht gleich nervös werden. Umorganisationen passieren halt immer wieder mal wieder, damit eine Webseite verwaltbar bleibt. Alte Seiten landen im Archiv und da ich kein CMS nutze, sind das eben HTML-Dateien in einem Verzeichnisbaum. Damit Google dennoch alle wieder findet, gibt es ja die Sitemap. Dennoch ist es natürlich unschön, weil Google und andere Suchmaschinen viel Zeit damit verbringen diese "falschen Seiten" zu parsen. Wobei das nur zutrifft, wenn der HTTP-Fehlercode nicht ein 404 ist, sondern der Zugriff auf eine nicht vorhandene Seite zu einer Weiterleitung führt.

Sendet mein Webserver einen echten 404?

Natürlich können Sie mit den WebMasterTools auch einfach eine URL "proben" und sehen, wie der Webserver darauf reagiert.

Das ist also ein "Soft 404, da er in Wirklichkeit eine Weiterleitung. Ein Klick au den Text hinter dem gelben Ausrufezeichen zeigt das auch an

Wer es selbst prüfen möchte, kann auch mit Tools wie Fiddler die Abfrage etwas genauer ermitteln.

So eine Weiterleitung ist in einigen Fällen durchaus gerechtfertigt, nämlich wenn der Inhalt einer Webseite wirklich "umgezogen" ist und der Webseitenautor bzw. das CMS den gleichen Inhalt nun unter einer neuen URL bereitstellt. Über eine 302-Weiterleitung auf die richtige neue Seite kann eine Suchmaschine ganz schnell die neue Position lernen. Ein 302 ist aber nicht sinnvoll, um eine nicht mehr existente Seite auf die Homepage umzuleiten. Das mögen Suchmaschinen angeblich nicht.

ErrorDocument 404 richtig konfigurieren

Ich habe einige Blogs und Hinweise gelesen, bis ich rausgefunden, wie man denn die richtige HTTP-Fehlermeldung bei einer Konfiguration der 404 Umstellung erreicht. Wer, wie die MSXFAQ, auf einem Apache läuft, wird die Methode kennen über die ".htaccess"-Datei die Fehlerseiten umzuleiten. In meiner Datei stand da lange drin:

ErrorDocument 404 http://www.msxfaq.de/404.htm
ErrorDocument 401 http://www.msxfaq.de/401.htm

Diese Einstellungen habe ich aus verschiedenen Blog und natürlich auch der 1und1 Hilfe gefunden und übernommen.

Das dabei aber niemand dazu schreibt, ist die Rückgabe eines "302 Moved Temporary", damit der Besucher auf die neue URL verwiesen wird. Die Ziel-URL für die Fehlerseite könnte also auch ganz wo anders liegen. Mit einem 302-Fehler wird Google und Co aber nicht glücklich, da die Seite so nicht deutlich als "not found" gemeldet wird. Google erkennt wohl, dass die Zielseite bei jedem Zugriff auf eine ungültige URL kommt.

Ein echter 404 Fehler kommt aber nur, wenn man eine relative URL zur Webseite nutzt.

ErrorDocument 404 /404.html

Fiddler zeigt das dann auch schön an:

Diese einfache Umstellung hat aber einen anderen unschönen Effekt, wenn der Browser nicht auf der Wurzel nach einer ungültigen Seite sucht, sondern in einem Unterverzeichnis. Dann stimmen die ganzen Links zu Bildern und Stylesheets nicht, wenn diese "Relativ" sind

Es kann sogar zu einer "Schleife" kommen, wenn nachgeladene Bilder eben auch einen 404 generieren und sie sehen hier in der Adressleiste z.B. das Problem, dass der Zugriff auf das Banner sich immer wieder hochschaukelt. Die 404-Fehlerseite sollte also idealerweise komplett ohne Verlinkungen auf andere Seiten auskommen oder diese Links "absolut" sein. Das ist aber nicht praktikabel, da ich dann ja diese Seiten mit einer abweichenden Formatvorlage und ohne Bilder gestalten müsste.

Mein Vorschlag 404 und 302 kombiniert

Ich habe daher einen anderen Ansatz gewählt und lasse den 404-Fehler schon aus eine rudimentäre HTML-Datei verweisen, die dann aber auch die "richtige" Datei per Weiterleitung schaltet. Allerdings keine echte 302 Weiterleitung, sondern eine HTTP-Refresh-Eintrag im Header:

<meta http-equiv="refresh" content="0; URL=https://www.msxfaq.de/404.htm">

Das ist zwar nicht ganz sauber, wenn schöner wäre eine echte HTTP-Weiterleitung mit einem 301 oder 302, aber wichtiger ist, dass zuerst ein 404 geliefert wird. Damit sollten die Suchmaschinen wissen, dass diese Seite wirklich nicht mehr existiert und sie aus dem Index entfernen. Alle "gültigen Seiten" erhalten Sie ja über die SiteMap. In Fiddler ist das dann gut zu sehen:

Der Zugriff auf "egal5.htm", die es nicht gibt, produziert einen schnellen kleinen "echten" 404 HTTP-Fehler, den die Suchmaschine aber versteht. Der Content enthält eine kleine Textinformation und dann die Weiterleitung zur "schönen 404-Seite" mit einem "META Refresh"

301 Weiterleitung für umgezogene Seiten

Es gibt aber auch Verzeichnisse, die ich komplett umbenannt oder in der Struktur verschoben habe. Hier wäre ein 404 auch bezüglich des PageRank nicht so nett. Dafür gibt es ja extra den "301 Moved Permanently". So kann eine Suchmaschine erkennen, das die Seite unter einer anderen URL erreichbar ist und diese neue Adresse ausliefern. Wenn alles gut geht, dann sollte auch der "Pagerank" der alten Seite auf die neue Seite übertragen werden. Auch das geht durch die HTACCESS. Hier ein Auszug:

#redirect old directories and files to new files
RewriteEngine On
RedirectMatch 301 /office365/produkte /cloud/technik$1
RedirectMatch 301 /office365 /cloud$1
RedirectMatch 301 /cloud/produkte /cloud/technik$1

Sie können hier gut sehen, dass der Bereich "Cloud" früher einmal "Office 365" hieß. Microsoft ändert aber Namen ab und an und auch die Produkte werden erweitert. Aus der früheren "Business Productivity Online Suite (BPOS)" wurde Office 365. Vergessen darf man aber nicht, dass in der Microsoft Cloud mittlerweile noch ganz viel mehr Produkte unter kommen. Daher habe ich den Namen früh noch auf "Cloud" gewechselt. Und Dinge, die unter "Produkte" lagen, habe ich nach Technik verschoben.

Ein anderer großer Themenblock ist natürlich die Neustrukturierung, die 2015/2016 erfolgt ist. Die MSXFAQ war lange Zeit 99% Exchange und daher waren die ersten Ebenen alles mit Exchange Installation, Administration, Migration, Betrieb, Tools, Verschlüsseln, AntiSpam...  und wenn dann noch Lync, Cloud, Backstage, Bastelbude etc. dazu kommen, dann wurde die erste Menüebene einfach unübersichtlich. Die erste Ebene sollte gestrafft werden und so wurde "Exchange, Lync, Cloud, Windows, Sonstiges" draus. Damit aber auch ich die Seite einfacher finden konnte, habe ich auch den physikalischen Pfad entsprechend angepasst. Und natürlich sollte ich, dass Google und Go hier nicht von "neuen Inhalten" ausgehen oder vielleicht sogar von "doppelten" Inhalten. Daher ist auch hier ein 301 eine sinnvolle Option. Erst recht, wenn ich z.B. aus "Lync" ein "Skype for Business" oder "SfB" machen will.

#redirect old directories and files to new files
RewriteEngine On
RedirectMatch 301 ^/lync(.*) /skypefb$1
RedirectMatch 301 ^/migration(.*) /exchange/migration$1
RedirectMatch 301 ^/notfall(.*) /exchange/notfall$1
RedirectMatch 301 ^/archiv(.*) /sonst/archiv$1
RedirectMatch 301 ^/ideen(.*) /sonst/ideen$1
RedirectMatch 301 ^/events(.*) /sonst/events$1
RedirectMatch 301 ^/verschiedenes/bastelbude(.*) /sonst/bastelbude$1
RedirectMatch 301 ^/verschiedenes(.*) /windows$1
RedirectMatch 301 ^/backstage(.*) /sonst/backstage$1
RedirectMatch 301 ^/uc(.*) /lync/exchangeum$1

Nebenbei sind die URLs dann auch etwas Sprechender, was vielleicht auch in Google und Co zu einer besseren Sichtbarkeit führt. Allerdings mache ich mir diese Mühe wirklich nur für komplette Verzeichnisse bzw. Bereiche aber nicht für jede einzelne Datei, die ich mal umbenannt oder anders einsortiert habe.

404, 302 und MSXFAQ

Mein Problem bei all der Technik ist, dass ich für eine effektive Arbeit manchmal nicht umhin komme, die physikalische Ablagestruktur der Dateien etwas zu verändern. Da reicht schon ein "Aus Lync wird Skype for Business". Ich kann aber unmöglich für jede verlagerte Datei eine eigene Umleitung bauen, damit die Suchmaschine die neue Datei wieder findet. Da vertraue ich drauf, dass Google und Co über die Sitemap die komplette MSXFAQ korrekt erfassen und erkennen, dass die Seite nun eine neue Adresse hat. Da ein Update des Index von Google aber einige Tage dauern kann, behelfe ich mir derart, dass ich lokal die Struktur anpasse aber beim FTP-Upload im Ziel die neuen Dateien hoch kopiere und die alten noch nicht sofort lösche. Erst ein paar Tage oder vielleicht Wochen später lösche ich im Ziel auch die alten "orphaned" Dateien. Erst dann wird der Webserver auf einen Zugriff darauf einen 302 oder 404 liefern.

Mir ist dabei schon bewusst, dass externe Links natürlich auch brechen. Und hierfür habe ich leider keine Lösung, denn mit "Permalink" arbeite ich aktuell nicht. Das gibt meine aktuelle Verwaltung nicht her. Allerdings scheinen selbst große Seiten die Erreichbarkeit von Links über einen langen Zeitraum nicht sonderlich wichtig anzusehen. Es dürfte wichtiger sein, dass die Pfade und Dateinamen den Inhalt und das Thema am besten wiedergeben und so die Suchmaschinen diese Seiten besser bewerten. Ich kann schon gar nicht mehr alle externen Links auf der MSXFAQ nachhalten, die irgendwo hin gehen. Manchmal finde ich sogar einen Link, der auf eine nicht mehr aktive Domain verweist und die sich Domaingrabber dann unter die Nägel gerissen haben.

Schön ist es nicht, aber die ganze Welt besteht aus Kompromissen.

Weitere Links