Wenn die vierte Seite kurz nicht erreichbar war

Vor einigen Wochen habe ich die vierte Gewerke-Landingpage gebaut: eine Seite für Garten- und Landschaftsbau in der Ortenau, nach demselben Muster wie zuvor für Schreinereien, Dachdecker und Fliesenleger. Bilder aus einem Konzept-Beispiel mit einem fiktiven Gartenbaubetrieb, ein Hinweis auf das Google-Unternehmensprofil, verlinkt von der Startseite und in der Sitemap eingetragen. Inhaltlich war alles fertig, geprüft, freigegeben. Trotzdem zeigte die Seite nach dem ersten Livegang für einen Tag einen Fehler 404 — nicht gefunden.

Was schiefging

Der Grund war unspektakulär und genau deshalb lehrreich. Mein Werkzeug, das die Website vor jedem Deploy in ein Paket packt, arbeitet bei den Gewerke-Seiten mit einer Liste einzelner Dateinamen statt mit einem Muster. Die neue Datei für Garten- und Landschaftsbau stand zwar auf der Website, in der Sitemap, in der Navigation — aber nicht auf dieser einen Liste. Beim Zusammenbauen des Pakets fehlte sie einfach, und der Server bekam sie nie zu sehen. Dieselbe Fehlerklasse war mir schon einmal untergekommen, bei einer anderen neuen Datei, Wochen vorher. Ich hatte sie beim ersten Mal notiert, aber nicht so behoben, dass sie nicht wiederkommen konnte.

Das ist der Teil, den ich nicht schönreden will: der Fehler war vermeidbar, und er ist trotzdem zweimal passiert. Was mich beruhigt, ist, wie er aufgefallen ist. Ich prüfe nach jedem Deploy die Seite live nach — nicht nur, ob sie sich anfühlt, wie sie soll, sondern ob jede einzelne URL aus der Sitemap tatsächlich antwortet. Genau diese Prüfung hat den 404 noch am selben Tag gezeigt, bevor ein Betrieb oder ein Kunde die Seite über eine Google-Suche gefunden hätte.

Wie ich es repariert habe

Die schnelle Lösung wäre gewesen, die fehlende Datei einfach von Hand auf die Liste zu setzen. Das hätte den akuten Fehler behoben, aber nichts an der Ursache geändert — die nächste neue Gewerke-Seite hätte das gleiche Problem gehabt. Stattdessen habe ich die Liste durch ein Muster ersetzt: Jede Datei, die wie eine Gewerke-Seite für die Ortenau aussieht, kommt jetzt automatisch mit ins Paket, ohne dass ich sie von Hand eintragen muss. Zusätzlich habe ich eine Prüfung eingebaut, die vor jedem Deploy Datei für Datei gegen die Sitemap abgleicht — fehlt auch nur eine einzige Seite, bricht der Vorgang ab, statt eine unvollständige Website live zu stellen.

Beide Änderungen habe ich getestet, bevor sie beim nächsten echten Deploy zum Einsatz kamen: einmal mit einem absichtlich unvollständigen Testpaket, das die Prüfung zu Recht abgelehnt hat, einmal mit dem echten, vollständigen Paket, das anstandslos durchging. Erst danach war ich sicher, dass der Fehler nicht ein drittes Mal auftauchen kann.

Was das für eine Garten- und Landschaftsbau-Website bedeutet

Für die Seite selbst war der Fehler harmlos — sie zeigt nur ein Konzept-Beispiel, keinen echten Betrieb. Aber er zeigt etwas Grundsätzliches über Websites für Garten- und Landschaftsbau in der Ortenau, das über diesen einen Vorfall hinausgeht: Gerade bei Betrieben, die von saisonaler Nachfrage leben — Frühjahrsputz im Garten, Terrassenbau im Sommer, Pflasterarbeiten vor dem Winter — kostet jeder Tag, an dem die Website nicht erreichbar ist, echte Anfragen. Wer im April nach „Gartenbau Achern" sucht und auf eine Fehlerseite trifft, sucht in der Regel nicht ein zweites Mal beim selben Betrieb.

Eine gute Website für diesen Bereich braucht aus meiner Sicht drei Dinge:

• Echte Bilder fertiger Projekte — Terrassen, Bepflanzungen, Wegebau, mit erkennbarem Bezug zur Region, nicht austauschbare Stockfotos von fremden Gärten.
• Verlässliche Erreichbarkeit, gerade in der Saison — eine Seite, die nur an guten Tagen lädt, ist keine Seite, auf die sich ein Betrieb verlassen kann.
• Den Hinweis aufs Google-Unternehmensprofil, weil ein großer Teil der Suchanfragen ohnehin lokal und mit Kaufabsicht kommt — „Gartenbau in meiner Nähe" statt eines Firmennamens.

Was ich daraus mitnehme

Der eigentliche Fehler war nicht die fehlende Zeile in einer Liste, sondern dass ich ihn beim ersten Mal als Einzelfall behandelt habe statt als Muster. Zwei fast identische Vorfälle innerhalb weniger Wochen sind kein Zufall, sie sind ein Hinweis, dass die Lösung noch nicht die richtige Ebene erreicht hatte. Jetzt läuft die Prüfung automatisch bei jedem Paketbau mit, für jede Seite, die es heute gibt, und für jede, die noch dazukommt.

Was mich dabei am meisten beschäftigt hat, ist die Frage, woran man eigentlich merkt, dass ein Fehler die letzte Reparatur nicht wirklich beseitigt hat, sondern nur seine Symptome. Eine einzelne fehlende Datei lässt sich in einer Minute nachtragen — und genau das macht es verlockend, dort aufzuhören. Erst der zweite, fast identische Vorfall hat mir gezeigt, dass das eigentliche Problem eine Ebene tiefer lag: in der Art, wie neue Seiten überhaupt in die Paketliste kommen. Seitdem stelle ich mir bei jedem wiederkehrenden Fehler eine einfache Frage, bevor ich ihn abhake: Würde dieselbe Reparatur auch die nächste, noch nicht existierende Seite retten? Wenn die Antwort Nein ist, ist die Reparatur nicht fertig, egal wie schnell der akute Fehler verschwunden ist.

Falls du selbst eine Website betreust und dir nicht sicher bist, ob wirklich jede ihrer Seiten nach dem letzten Update noch erreichbar ist: Schreib mir kurz — ich schaue mir das ehrlich an.

Geschrieben mit KI-Unterstützung — geprüft von Elvis Sharando · Website prüfen lassen