Eine Zeile Serverkonfiguration hat unsere Website 42 % ihrer Sichtbarkeit gekostet

Wir schreiben das hier über unsere eigene Seite, nicht über die eines Kunden. Das ist unangenehmer, aber ehrlicher — und der Fehler ist so verbreitet, dass er es wert ist.

Der Befund

Über zwölf Monate hatte unsere Website 133.168 Impressionen bei Google. Davon liefen 67.663 auf Seiten, die es nicht mehr gab — 42 Prozent. Wer sie anklickte, landete auf „Seite nicht gefunden”.

Die Search Console meldete es sogar: Soft 404 — 123 Seiten. Nur hatte niemand hingesehen.

Die Ursache

In der Serverkonfiguration stand diese Zeile:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /404.html [L]

Auf den ersten Blick richtig: Wenn die angefragte Datei nicht existiert, liefere die 404-Seite aus. Genau das tut sie auch — sie liefert den Inhalt der 404-Seite.

Was sie nicht tut: den Statuscode setzen.

RewriteRule mit [L] ist ein internes Rewrite. Der Server holt eine andere Datei und schickt sie mit dem Status, den er ohnehin gesetzt hätte: HTTP 200 OK. Für einen Menschen sieht das aus wie eine Fehlerseite. Für Google steht in der Antwort: Diese Seite existiert und ist in Ordnung.

Es fehlte eine einzige Anweisung:

ErrorDocument 404 /404.html

Damit liefert Apache dieselbe Seite mit Status 404 aus. Ein Wort Unterschied im Ergebnis, drei Monate Unterschied in der Wirkung.

Warum das teuer ist

Wenn eine gelöschte Seite 404 meldet, entfernt Google sie nach einigen Wochen aus dem Index. Sauber, vorgesehen, unspektakulär.

Wenn sie 200 meldet, passiert das Gegenteil:

• Sie bleibt im Index. Google hat keinen Anlass, sie zu entfernen — der Server sagt ja, sie sei in Ordnung.
• Sie sammelt weiter Impressionen. Bei uns waren es zwei Seiten mit über 14.000 Impressionen jede — beide waren Fehlerseiten.
• Jeder Klick ist verbrannt. Der Nutzer landet auf „Seite nicht gefunden” und geht zurück. Das ist ein Besucher, den man hatte und verloren hat, bevor er etwas gelesen hat.
• Es fällt nicht auf. Kein Fehler im Log, kein Alarm, keine Meldung. Die Seite funktioniert ja. Sie erzählt nur eine falsche Geschichte über sich selbst.

Der letzte Punkt ist der eigentliche. Ein Absturz fällt in Minuten auf. Ein falscher Statuscode fällt in Monaten auf — wenn überhaupt.

Wie es dazu kam

Nicht durch Nachlässigkeit. Durch eine Kette plausibler Schritte:

1. Ein statischer Export braucht auf einem Apache-Server eine Regel, die schöne URLs auf Dateien abbildet.
2. Dieselbe Regel muss einen Fall abdecken, in dem keine Datei passt.
3. RewriteRule . /404.html [L] löst genau das. Man testet es im Browser. Es sieht richtig aus.
4. Niemand prüft den Statuscode, weil man Statuscodes nicht sieht.

Dazu kam ein zweiter Umstand, der noch typischer ist: Im Repository lag eine gepflegte Redirect-Datei für eine Hosting-Plattform, auf der die Seite gar nicht lief. Achtzehn sorgfältige Weiterleitungen, die nie ausgeführt wurden. Wer an der falschen Datei arbeitet, misst nie eine Wirkung — und sucht den Fehler dann im Inhalt.

Prüfen Sie es. Dauert dreißig Sekunden.

Rufen Sie eine Adresse auf Ihrer Domain auf, die es garantiert nicht gibt:

curl -I https://ihre-domain.at/gibt-es-garantiert-nicht-xyz/

In der ersten Zeile muss 404 stehen. Steht dort 200, haben Sie dasselbe Problem.

Gegenprobe, falls Sie kein Terminal öffnen wollen: Rufen Sie die erfundene Adresse im Browser auf und vergleichen Sie die Seite mit einer echten Unterseite, die Sie kürzlich gelöscht haben. Sehen beide gleich aus und lädt beides ohne Fehler — sehen Sie sich die Serverkonfiguration an.

In der Search Console finden Sie es unter Seiten → Nicht indexiert → Soft 404.

Was wir daraus gelernt haben

Statuscodes sind Inhalt. Eine Seite sagt nicht nur, was auf ihr steht — sie sagt auch, ob sie existiert. Die zweite Aussage ist unsichtbar und wird deshalb nie getestet.

Statisches Hosting auf einem eigenen Server verlangt Beweise. Unsere anderen Projekte laufen auf GitHub Pages und liefern korrekte 404 ohne Zutun. Die einzige Seite mit handgeschriebener Serverregel war die kaputte. Das ist kein Argument gegen eigene Server — es ist ein Argument dafür, sie zu prüfen.

Was man nicht misst, ist wahrscheinlich falsch. Nicht möglicherweise. Wahrscheinlich.

Der Fix kostet eine Zeile. Ihn zu finden hat gedauert, weil niemand nach einem Fehler gesucht hat, der wie Erfolg aussieht.

Wie wir seither prüfen — und was wir dabei auf der eigenen Seite gefunden haben — steht im Prüfprotokoll. Was diese Seite über sich behauptet und nachzählbar macht, steht auf Haltung.