Ein Website-Relaunch ohne Weiterleitungstabelle kostete einen Malerbetrieb in einer Beispielrechnung rund 2.900 Euro an entgangenen Anfragen und Nacharbeit, weil zwei Migrationen an einem Wochenende zusammenfielen.
KI-unterstützt · redaktionell geprüft
Ein Malerbetrieb mit sechs Mitarbeitern wechselt im Zuge eines Relaunchs von einem alten Baukastensystem zu einer individuell programmierten Website – angenommen, das ist der Auslöser dieses Falls. Zwei Wochen später sind die Plätze auf der ersten Google-Trefferseite verschwunden, auf denen der Betrieb seit Jahren stand.
Der neue Anbieter sollte die alte Seite eins zu eins ablösen: gleiche Struktur, moderneres Layout, kürzere Ladezeiten. Die Domain blieb identisch, nur das System dahinter wechselte vom Baukasten zur Eigenentwicklung. Im Angebot stand ein Posten namens „Migration inklusive“ – ohne dass irgendwo aufgeschlüsselt war, was das umfasst. Für den Anbieter bedeutete das: Texte und Bilder von der alten Seite übernehmen, neu einbauen, Layout anpassen. URLs, Weiterleitungen und die Struktur der Seitenadressen kamen in dieser Definition nicht vor.
Genau da liegt der übliche Bruch. Der Baukasten hatte Adressen wie /leistungen/fassadenanstrich oder /galerie/aussenanstrich-muenchen automatisch aus dem Seitentitel erzeugt. Die neue, individuell programmierte Seite bekam eine eigene, schlankere Struktur: /leistungen/fassade, /projekte/1. Inhaltlich fast identisch, technisch zwei getrennte Adressen. Ohne eine Zuordnungstabelle zwischen alt und neu meldet der Server für jede alte Adresse einen 404-Fehler. Google merkt das innerhalb weniger Tage.
In diesem Fall kam ein zweiter Faktor hinzu: Der Hosting-Wechsel lief am selben Wochenende wie der Systemwechsel, weil beide Verträge zufällig zum Monatsende ausliefen. Zwei Fehlerbilder überlagerten sich – fehlende Weiterleitungen und ein noch nicht vollständig propagiertes DNS. Dadurch dauerte die Fehlersuche länger, weil unklar war, welches der beiden Probleme welchen Effekt hatte. Erst nach drei Wochen stand die Weiterleitungstabelle vollständig, und die Domain lief stabil.
Vor dem Ausfall erhielt der Betrieb nach eigener Schätzung durchschnittlich fünf Anfragen pro Woche über die organische Suche (Annahme, typischer Wert für einen kleinen Malerbetrieb mit guter lokaler Position). Während der drei Wochen mit fehlendem Ranking sank das auf zwei Anfragen pro Woche, der Rest kam weiter über Bestandskunden und Empfehlungen. Das macht drei entgangene Anfragen pro Woche, über drei Wochen neun Anfragen.
Nicht jede Anfrage wird zum Auftrag. Wird für diesen Betrieb ein durchschnittlicher entgangener Deckungsbeitrag von 250 Euro pro Anfrage angesetzt (Annahme, grob aus Auftragswert und üblicher Abschlussquote gebildet), ergibt das:
9 Anfragen × 250 Euro = 2.250 Euro entgangener Deckungsbeitrag.
Dazu kommt die Nacharbeit selbst: sechs Stunden Zeit des Betriebsinhabers für Fehlersuche und Abstimmung mit dem Anbieter, zu 45 Euro internem Stundensatz angesetzt, macht 270 Euro. Der Anbieter musste zusätzlich vier Stunden für das nachträgliche Erstellen der Weiterleitungstabelle aufwenden, zu 95 Euro Stundensatz macht 380 Euro. Zusammen 650 Euro Nacharbeit.
2.250 Euro plus 650 Euro ergibt 2.900 Euro.
Wäre nur eine der beiden Migrationen betroffen gewesen, hätte die Fehlersuche vermutlich zwei statt sechs Stunden gedauert, und die Behebung wäre nach einer statt drei Wochen abgeschlossen gewesen. Drei entgangene Anfragen mal 250 Euro macht 750 Euro, dazu 90 Euro Chef-Zeit und weiterhin 380 Euro Dienstleisterzeit – macht in Summe rund 1.220 Euro. Weniger als die Hälfte.
Wäre die Störung dagegen sechs statt drei Wochen unentdeckt geblieben, etwa weil niemand im Betrieb die Rankings beobachtet, stiegen die entgangenen Anfragen auf achtzehn, macht 4.500 Euro. Dazu kommt höhere Nacharbeit: zwölf Stunden Chef-Zeit (540 Euro) und acht Stunden Dienstleisterzeit (760 Euro), macht 1.300 Euro. Summe: rund 5.800 Euro. Die Rechnung kippt also stärker mit der Zeit bis zur Entdeckung als mit der Zahl der beteiligten Systeme.
Ein Hausmeisterservice mit vier Mitarbeitern – ebenfalls ein konstruiertes Beispiel – wechselt nicht nur das System, sondern auch die Domain, von hausmeister-service-mueller.de zu mueller-facility.de. Hier reicht eine technisch korrekte 301-Weiterleitungstabelle allein nicht aus. Google behandelt einen Domainwechsel anders als einen reinen Systemwechsel: Ohne die Funktion „Adressänderung“ in der Google Search Console wird die neue Domain wie ein unbekanntes, neues Projekt eingestuft, selbst wenn jede einzelne Adresse korrekt weitergeleitet ist. Die alte Property in der Search Console muss bestehen bleiben, bis die neue vollständig übernommen wurde. Wird sie vorzeitig gelöscht, geht der Nachweis der Weiterleitung mit ihr verloren.
Bestandsaufnahme: alle indexierten Adressen exportieren, über die Google Search Console (Bereich „Seiten“) oder mit einem Crawler wie Screaming Frog, bevor die alte Seite abgeschaltet wird. Zuordnungstabelle: jede alte Adresse bekommt eine konkrete neue Zieladresse – keine Sammelweiterleitung aller Adressen auf die Startseite. Serverseitige Umsetzung: die Tabelle wird als 301-Weiterleitung in der Serverkonfiguration hinterlegt, in der .htaccess bei Apache oder im entsprechenden Block bei nginx, nicht als JavaScript-Weiterleitung im Browser. Kontrolle nach Go-Live: jede alte Adresse einzeln testen, der Statuscode muss 301 lauten, nicht 302 und nicht 200 mit falschem Inhalt. Nachpflege in der Search Console: neue Sitemap einreichen, bei Domainwechsel zusätzlich die Adressänderung eintragen.
Bei einer Seite mit drei bis fünf Unterseiten, kaum eingehenden Links und wenig organischem Traffic ist eine vollständige Zuordnungstabelle unverhältnismäßig. Eine pauschale Weiterleitung aller alten Adressen auf die neue Startseite reicht dann aus. Auch bei einem geplanten inhaltlichen Neustart, bei dem die alten Seiten gar nicht mehr existieren sollen, ist eine 1:1-Weiterleitung wenig sinnvoll: Wer eine Landingpage zu einem eingestellten Angebot auf eine thematisch fremde Seite umleitet, verwirrt eher, als dass er hilft. Und eine korrekte Weiterleitungstabelle behebt keine anderen technischen Probleme der neuen Seite – eine langsame Ladezeit oder eine fehlende mobile Darstellung bleiben bestehen, unabhängig von den Redirects.
Manche Anbieter setzen statt serverseitiger 301-Weiterleitungen eine Weiterleitung per JavaScript oder Meta-Refresh im HTML-Kopf ein. Für Suchmaschinen ist das ein schwächeres Signal: Der Linkwert wird nicht zuverlässig übertragen, und bei langsamer Skriptausführung sieht der Crawler unter Umständen nur eine leere Seite. Wildcard-Weiterleitungen – ganze Verzeichnisse auf ein neues Muster umleiten – funktionieren, wenn sich die URL-Struktur nur nach einem festen Muster ändert, etwa bei durchnummerierten Blogbeiträgen. Bei individuell benannten Seiten mit uneinheitlicher neuer Struktur braucht es die 1:1-Tabelle. Wildcards würden hier auf falsche Ziele zeigen.