Soft 404 Fehler bei Weiterleitung auf https

Starten Sie online durch!

Soft 404 Fehler bei Weiterleitung auf https

TL;DR: Wenn Ihnen die Problemstellung bekannt ist und Sie nur auf der Suche nach einer Lösung sind, so finden Sie diese hier.

Da Google mittlerweile HTTPS als ein positives Ranking-Signal wertet – wenngleich vorerst nur als ein schwaches Signal dessen Auswirkung aber nach und nach verstärkt wird – sehen sich Administratoren von dynamischen Webseiten vor ein Problem gestellt: die Einrichtung des Webservers, sodass Inhalte nur mehr über HTTPS ausgeliefert werden, ist nicht kompliziert. Doch da man in der Regel HTTPS forcieren möchte, wird man eine Weiterleitung aller Anfragen auf HTTP-URLs auf die entsprechende HTTPS-URL einrichten.

Dies ist an und für sich gut und sollte auch so gehandhabt werden. Das Problem ergibt sich allerdings in der Auslieferung von Fehlerseiten – insbesondere mit dem Statuscode 404 (Not Found) oder 410 (Gone). Wenn nun eine Anfrage auf eine ungültige HTTP-URL kommt, so wird zuerst der Webserver (also Apache, nginx oder dergleichen) mit einer 301- oder 302-Weiterleitung auf die HTTPS-URL antworten. Wenn dann diese URL aufgerufen wird, kommt erst die 404/410-Antwort.

Dieses Verhalten wird von Google allerdings negativ gewertet. Wenngleich auch im offiziellen Blog-Eintrag zu „Soft 404s“ und in der Hilfe-Seite dies nicht explizit genannt wird, so findet man in den entsprechenden Foren Beiträge, die beschreiben, dass Google solche 301=>404 Redirects in den Webmaster-Tools als „soft 404 Fehler“ aufführt.

Da bei dynamischen Inhalten aber erst das Backend – also zB ein CMS wie WordPress oder Drupal – prüfen kann, ob eine URL gültig ist oder nicht, kann der Webserver dies nicht schon vor der Weiterleitung von HTTP auf HTTPS überprüfen und damit auch nicht schon an dieser Stelle korrekt mit 404/410 antworten.

Aus diesem Grund haben wir ein kleines Tool geschrieben, das sich als Proxy vor ein dynamisches Backend einhängen lässt, und das genau das macht. Es antwortet auf HTTP-Anfragen und leitet dieser zuerst intern auf das entsprechende HTTPS-Backend weiter. Wenn dieses Backend mit einem Statuscode im Bereich 2xx antwortet, so reagiert der Proxy mit einer 301-Response und leitet den Browser (oder eben den Crawler der Suchmaschine) auf die HTTPS-URL weiter. Antwortet das Backend allerdings mit einem 4xx-Status, so liefert der Proxy dies sofort aus. Dabei wird auch der Inhalt der Antwort vom Backend mit ausgegeben – schön gestaltete Fehlerseiten funktionieren also auch mit diesem Proxy weiterhin. Einmal angefragte URLs merkt sich der Proxy 24 Stunden lang vor, damit er bei der nächsten identen Anfrage das Backend gar nicht erst kontaktieren muss, sondern unmittelbar mit der entsprechenden Response antworten kann.

Wir haben diesen Proxy open source gestellt und auf Github veröffentlicht. Es handelt sich dabei um eine Node.js-App und die relativ einfache Installationsanleitung finden Sie in der README-Datei.

Sollten Sie Hilfe bei der Installation benötigen oder Sie in Ihrer Hosting-Umgebung keine Node.js-Anwendung betreiben können oder wollen, so kontaktieren Sie uns einfach. Gerne besprechen wir mit Ihnen eine Lösung, die auch in Ihrer Hosting-Umgebung funktioniert, oder bieten entsprechendes Hosting auf unserer Hardware an.

Add comment