Website-Relaunch-Fallstudie: Douzu Carry Service, ein Speditionsunternehmen aus Miyazaki — was wir von der alten Website übernommen haben und wie

Das Gefährlichste an einem Website-Relaunch ist, dass sich zwar das Erscheinungsbild erneuert, aber Suchranking und Anfrageweg dabei still und leise zerbrechen. Diesmal nehmen wir das Relaunch-Projekt von „Douzu Carry Service“, einem Speditionsunternehmen aus Miyazaki, als Beispiel und fassen zusammen, was wir vor der Gestaltung festgelegt haben.

Wenn von einem Website-Relaunch die Rede ist, beginnt das Gespräch meist mit Design-Entwürfen oder dem Aussehen der Startseite. Doch wenn die alte Website bereits nennenswerten Suchtraffic oder Backlinks hat, gibt es Dinge, die vor dem Design festgelegt werden müssen – sonst lassen sie sich später nur schwer zurückdrehen. Das sind das URL-Design und die Frage, wie die Informationen der alten Website übernommen werden.

Dieser Artikel nimmt den Relaunch von „Douzu Carry Service“ – einem Speditionsunternehmen aus Miyazaki, das Einzelumzüge, Fernlieferungen und Kühl-/Tiefkühltransporte anbietet – als Beispiel und fasst die tatsächlich befolgten Schritte zusammen. Einen kurzen Überblick gibt es unter „Der Fall, der die Struktur von Douzu Carry Service zusammenfasst“, dieser Artikel geht jedoch etwas tiefer in die Details.

Zu beachten ist, dass dieser Artikel keine Wirkungszahlen wie Veränderungen bei Besuchs- oder Anfragezahlen enthält. Was wir hier darstellen können, beschränkt sich auf die Fakten – was in welcher Reihenfolge getan wurde –, da Wirkungszahlen nicht Teil der Quellen dieses Artikels sind.

1. Projektüberblick — Vorher / Nachher

Zunächst das Gesamtbild.

Die wichtigsten statischen Seiten – Startseite, Leistungsübersicht, Umzug, Kühl-/Tiefkühltransport, Same-Day-Lieferung, Umzug in Seniorenwohnanlagen, Preise, Unternehmensinformationen, FAQ und Kontakt – behielten zusammen mit den neun Gebietsseiten für Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima und Ebino während des Relaunchs alle ihre URLs unverändert bei. Was sich hauptsächlich änderte, war der Umgang mit den bedeutungslosen URLs des alten Blogs und einem ungenutzten Restskript.

Darüber hinaus wurde das Design der neuen Website auf Basis des vom japanischen Digitalamt (Digital Agency) veröffentlichten Designsystems aufgebaut. Der Verzicht auf den Schritt, ein Design von Grund auf neu zu entwerfen, ließ uns den dadurch gesparten Aufwand in die in diesem Artikel behandelte URL-Gestaltung und Content-Migration stecken. Die dahinterliegende Überlegung ist in „Warum KomuraSoft Websites auf dem Designsystem der Digital Agency aufbaut — geringe Kosten und hohe Qualität lassen sich vereinen“ zusammengefasst.

Wenn man diesen Fall auf einen Punkt bringen müsste, dann diesen: Wir haben die URL- und Inhalts-Bestandsaufnahme abgeschlossen, bevor wir das visuelle Design angefasst haben, und erst danach begonnen. Die folgenden Kapitel gehen diesen Prozess Schritt für Schritt durch.

2. Der erste Schritt war nicht das Design, sondern eine URL-Bestandsaufnahme

Das Erste, was wir zu Beginn des Relaunchs erstellt haben, war kein grober Design-Entwurf, sondern eine Bestandsaufnahme-Tabelle, die alle URLs der alten Website auflistete.

Konkret haben wir die folgenden Einheiten lückenlos erfasst.

• Statische Seiten (Startseite, Leistungsübersicht, Umzug, Kühl-/Tiefkühltransport, Same-Day-Lieferung, Umzug in Seniorenwohnanlagen, Unternehmensinformationen, Datenschutzerklärung, FAQ, Preise, Blog, Kontakt)
• Die neun Gebietsseiten (Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, Ebino)
• Einzelne Beiträge des alten Blogs (über 100, von gebietsbezogenen Kolumnen bis zu Know-how-Artikeln über Einzel- und Fernumzüge)
• „Dateien, die keine Seiten sind, aber dennoch öffentlich zugänglich sind“, wie robots.txt, sitemap.xml, die Search-Console-Eigentümerschaftsdatei und das alte Formular-Übermittlungsskript (php/submit.php)

Erst nachdem diese Bestandsaufnahme vorlag, konnten wir eine Zuordnungstabelle erstellen, die URL für URL entschied, was auf der neuen Website damit geschehen sollte. In der Zuordnungstabelle dieses Projekts haben wir die Entscheidung in zwei große Kategorien unterteilt.

Die statischen Seiten, die Gebietsseiten und die aktuell bedeutungstragenden Blogbeitrags-URLs wurden alle auf keep (unverändert) gesetzt. Andererseits wurden bedeutungslose, vom System automatisch nummerierte URLs mit zufälliger Zeichenkette (etwa /blog/5lmln1lx0x/) sowie datumsbasierte Dateinamen wie post20210721.html so gestaltet, dass sie per 301 auf neue Artikel-URLs mit aussagekräftigem Slug weiterleiten.

Ein weiterer Punkt in diesem Entscheidungsprozess war php/submit.php, ein auf der alten Website zurückgelassenes Übermittlungsziel-Skript. Wir stellten fest, dass es von keinem Formular im veröffentlichten HTML referenziert wurde und dass die tatsächlich funktionierenden Anfragekanäle nur die drei Systeme Telefon, E-Mail und LINE-Angebotsanfrage waren – wir stuften es daher als „zurückgelassenes Übermittlungsskript“ ein und richteten eine 301-Weiterleitung zu /contact/ ein (den Hintergrund dieser Entscheidung behandeln wir ausführlicher im nächsten Kapitel und in Kapitel 5).

Beim Redirect-Design haben wir zwei Regeln ausnahmslos durchgesetzt.

• Jede Weiterleitung löst sich in einem einzigen Hop auf (niemals eine Weiterleitungskette bilden)
• Beim Build eine Prüfung einbauen, die verifiziert, dass die Ziel-URL tatsächlich existiert (um den Unfall einer 301-Weiterleitung auf eine nicht existierende URL zu verhindern)

Diese Bestandsaufnahme und Zuordnungstabelle festzulegen, bevor überhaupt über das Design nachgedacht wird, bedeutet, dass die späteren Phasen von Implementierung und Content-Erstellung auf der soliden Grundlage „was kommt auf welche URL“ ablaufen können, was Nacharbeit reduziert. Das ist nicht auf dieses eine Projekt beschränkt – es ist ein grundlegendes Vorgehen, das genauso direkt für jeden Relaunch einer alten Website gilt, die bereits Backlinks oder Suchtraffic hat.

3. Eine Erhaltungs-Checkliste, damit kein Inhalt „verloren geht“

Parallel zur URL-Gestaltung haben wir eine Inhalts-Erhaltungs-Checkliste erstellt, um zu bestätigen, dass alle auf der alten Website geschriebenen Informationen auch auf der neuen ausnahmslos wiedergegeben werden können.

Bei einem Relaunch können kleine werbliche Formulierungen und Zahlen im Zuge der Neugestaltung unbemerkt verloren gehen. Wenn dabei Informationen verloren gehen, die direkt die Anfrageentscheidung beeinflussen – Preise, Öffnungszeiten, Kontaktdaten, zentrale Stärken –, kann das genau zu dem Ergebnis führen, dass die Website besser aussieht, die Anfragen aber zurückgehen.

Deshalb haben wir für jede Hauptseite die unverzichtbaren Informationen der alten Website festgehalten. Hier ein Auszug dessen, was das umfasste.

Mit dieser Checkliste haben wir vor dem Launch der neuen Website alte und neue Seiten Seite für Seite abgeglichen und bestätigt, dass keine Elemente verloren gegangen waren. Der entscheidende Punkt ist, dass wir über eine Liste – statt über Gefühl oder Erinnerung – sichergestellt haben, dass das „Entscheidungsmaterial“ wie Preise, Öffnungszeiten und Stärken trotz der Designänderung vollständig übernommen wurde.

4. Lokales SEO — die Gestaltung der neun Gebietsseiten

Zu den von der alten Website übernommenen Seiten gehören neun Einzelseiten, jeweils eine für die folgenden Gebiete: Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima und Ebino.

Diese Gebietsseiten existieren als Landing Point für Suchanfragen, die einen Ortsnamen enthalten, etwa „[Ortsname] + Umzug“ oder „[Ortsname] + Lieferung“. Bei einem Dienst wie Spedition oder Umzug, dessen Einzugsgebiet an konkrete Regionen gebunden ist, übernehmen sie die Rolle, die ortsnamenbezogene Suchnachfrage abzufangen, die Startseite oder Preisseite allein nicht vollständig erfassen können.

Ein Blick in die URL-Zuordnungstabelle zeigt, dass alle neun Seiten von /area/miyazaki/ bis /area/ebino/ als keep (keine URL-Änderung) eingestuft wurden, und der Relaunch hat diese Struktur selbst nicht angetastet. Daneben gibt es auch zahlreiche Blogbeiträge, die mit jedem Gebiet verknüpft sind und konkrete lokale Ortsnamen behandeln – etwa Stadtteile innerhalb der Stadt Miyazaki oder Miyakonojo –, wodurch eine Struktur entsteht, in der sich Gebietsseiten und Blogbeiträge gegenseitig ergänzen.

Seiten wie diese Gebietsseiten – der Typ, der durch bloßes Variieren des Ortsnamens in einem ansonsten identischen Format massenhaft erzeugt wird – laufen Gefahr, bei dünnem Inhalt sowohl für Suchmaschinen als auch für Leser wie wiederverwendete Kopien derselben Seite zu wirken. In diesem Fall wurde die Arbeitsteilung von der alten Website übernommen: Die Gebietsseiten selbst decken die Gebietsebene ab, während die Blogbeiträge einzeln die Details auf Stadtteilebene innerhalb jedes Gebiets behandeln. Diese Struktur vermied bereits die für Massenproduktionsseiten typische „Dünnheit“. Der Relaunch hat diese Struktur unangetastet gelassen und die URLs unverändert beibehalten.

5. Konsolidierung verstreuter Anfragekanäle

Der Umgang mit php/submit.php, das in Kapitel 3 erwähnt wurde, war auch aus Sicht der Organisation des Anfrageweges eine wichtige Entscheidung.

Bei der Untersuchung der alten Website stellten wir fest, dass nur die folgenden drei Systeme tatsächlich als öffentlich verfügbare Anfragekanäle funktionierten.

• Telefon (0120-931-677, Erreichbarkeitszeiten 8:00–20:00 Uhr)
• E-Mail
• LINE-Angebotsanfrage

Andererseits blieb das Übermittlungsziel-Skript php/submit.php selbst zwar im Code erhalten, wurde jedoch von keinem Formular im veröffentlichten HTML referenziert. Mit anderen Worten: Es war ein „zurückgelassenes Skript“, das tatsächlich nicht mehr genutzt wurde. Darauf aufbauend konsolidiert die neue Website die drei Kanäle – Telefon, E-Mail und LINE-Angebotsanfrage – auf der Seite /contact/, und jeder Zugriff auf php/submit.php ist so gestaltet, dass er per 301 auf /contact/ weiterleitet.

Wenn Anfragekanäle über mehrere Seiten und Skripte verstreut sind, verliert man gerade zum Zeitpunkt eines Relaunchs leicht den Überblick, welche davon tatsächlich genutzt werden. Dieser Ansatz – zunächst zu ermitteln, welche Kanäle tatsächlich funktionieren, und sie dann zu konsolidieren, wie wir es hier getan haben – gilt auch als allgemeines Prinzip für die Überprüfung des Weges zwischen Startseite, Leistungsseiten und Kontaktseite. Diesen Gedanken haben wir auch in einem früheren Artikel behandelt, „Die drei Stellen, die man zuerst reparieren sollte, wenn eine Website keine Anfragen erhält“, der sich ebenfalls lohnt.

6. Aufräumen alter Domains — Umgang mit einer verwaisten Landingpage-Domain

Unternehmen wie Speditionen, die für jeden Dienst separate Landingpages aufgebaut haben, finden sich manchmal, ohne es recht zu bemerken, mit auf mehrere Stellen verstreuten Domains wieder. Auch in diesem Fall mussten die folgenden Domains bereinigt werden.

Besonders der dritte Fall ist eine wichtige Lehre. Der Inhalt der alten Kühl-/Tiefkühltransport-Landingpage – ihre Kernaussagen zu Fahrzeugen mit −20 °C-Kühlaggregaten, 24/7-Verfügbarkeit an 365 Tagen sowie planmäßigen Touren und Routenlieferung – wurde bereits nach /refrigerated/ auf der neuen Website migriert. Doch da sich die alte Domain selbst nicht mehr auflösen lässt, vermutlich wegen eines abgelaufenen DNS-Eintrags, gibt es keine Möglichkeit, dort eine 301-Weiterleitung einzurichten. Die Lehre daraus: Lässt man eine Domain unbetreut und unverlängert liegen, riskiert man, eines Tages plötzlich die dort angesammelte Backlink-Autorität und den Traffic aus Markensuchen zu verlieren.

Wenn Ihr Unternehmen Service-Landingpages auf separaten Domains betreibt und einen Relaunch erwägt, empfehlen wir, nicht nur festzulegen, wohin die Inhalte konsolidiert werden, sondern gleichzeitig auch den Vertragsstatus der alten Domain zu prüfen – ob die Verlängerung noch läuft und ob ihr DNS noch aktiv ist. Ob man die 301-Weiterleitung noch einrichten kann, solange eine Wiederherstellung möglich ist, macht einen echten Unterschied dafür, wie leicht sich die angesammelte Autorität später übertragen lässt.

7. Prüfung vor dem Launch und Aufgaben nach dem Launch

Vor dem Launch der neuen Website haben wir die folgenden Prüfungen durchgeführt.

• Abgleich mit der in Kapitel 2 und 3 erstellten Inhalts-Erhaltungs-Checkliste (stimmen die Elemente von alten und neuen Seiten überein)
• Live-Verifizierung der 301-Weiterleitungen (tatsächlich Anfragen senden und bestätigen, dass die erwarteten Statuscodes und Ziele zurückkommen)
• Bestätigung, dass die Search-Console-Eigentümerschaftsdatei korrekt einen 200er-Status zurückgibt
• Bestätigung, dass für den Launch benötigte Dateien wie robots.txt, sitemap.xml und _headers tatsächlich veröffentlicht sind

Auch nach dem Launch gibt es Aufgaben zu erledigen.

• sitemap.xml erneut bei der Search Console einreichen
• Mit dem URL-Prüftool einzeln bestätigen, dass die ID-URLs des alten Blogs und die datumsbasierten .html-Dateinamen wie erwartet per 301 weiterleiten
• Über mehrere Wochen hinweg im Abdeckungsbericht prüfen, ob alte URLs, die zuvor 404 waren oder vom Index ausgeschlossen waren, schließlich als „Weiterleitung“ erkannt werden

Ein Relaunch-Projekt endet nicht mit dem Launch – es lohnt sich, von der Prämisse auszugehen, dass es erst wirklich abgeschlossen ist, wenn man die Weiterleitungen überwacht und bestätigt hat, dass die Suchmaschine sie nach dem Launch korrekt erkannt hat.

8. Zusammenfassung — allgemeine Regeln, um bei einem Relaunch nicht zu scheitern

Destilliert man die Überlegungen aus diesem Douzu-Carry-Service-Fall zu Ideen, die gleichermaßen für andere Relaunch-Projekte gelten, ergibt sich Folgendes.

• URL-Design zuerst, Design danach. Bei einer alten Website mit bereits vorhandenem Suchtraffic oder Backlinks sollte die vollständige URL-Bestandsaufnahme und die Zuordnungstabelle zu den neuen URLs (301-Mapping) finalisiert werden, bevor überhaupt über das visuelle Design nachgedacht wird.
• Nicht ohne Content-Bestandsaufnahme launchen. „Entscheidungsmaterial“ wie Preise, Öffnungszeiten, Kontaktdaten und Stärken vor dem Launch mit einer Checkliste bestätigen, die alte und neue Seiten Seite für Seite abgleicht.
• Nur tatsächlich genutzte Kanäle beibehalten. Findet man ein ungenutztes Formular oder Übermittlungsskript, den tatsächlichen Sachverhalt klären und dann in den noch aktiven Kanal konsolidieren.
• Jede Weiterleitung mit einem einzigen Hop und einer Verifizierung der Zielexistenz kombinieren. Niemals Ketten bilden und einen Mechanismus vorhalten, der niemals auf eine nicht existierende URL verweist.
• Domains aufräumen, solange sie noch aktiv sind. Lässt man eine separate Domain für eine Service-Landingpage unbetreut, kann ein abgelaufener DNS-Eintrag sie unwiederbringlich machen — und einen damit genau die Gelegenheit kosten, die angesammelte Autorität zu übertragen.

Ein Website-Relaunch ist nicht einfach die Arbeit, das Design aufzufrischen — er ist zugleich eine Gestaltungsaufgabe, bei der es darum geht, wie man die über die Zeit aufgebaute Suchautorität und den Anfrageweg überträgt. Ein knapper Überblick zu diesem Fall ist unter „Der Fall, der die Struktur von Douzu Carry Service zusammenfasst“ zusammengefasst, der sich ebenfalls lohnt.

Wenn Sie ähnliche Bedenken bezüglich URL-Design oder der Übertragung bestehender Inhalte haben, können wir im Rahmen einer Beratung zur Website-Entwicklung gemeinsam mit der Bestandsaufnahme der alten Website beginnen.

Verwandte Artikel

• Der Fall, der die Struktur von Douzu Carry Service zusammenfasst
• Warum KomuraSoft Websites auf dem Designsystem der Digital Agency aufbaut — geringe Kosten und hohe Qualität lassen sich vereinen
• Die drei Stellen, die man zuerst reparieren sollte, wenn eine Website keine Anfragen erhält
• Website-Entwicklung
• Kontakt

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Womit sollte ein Website-Relaunch beginnen?

Nicht mit einem Design-Entwurf, sondern mit einer Bestandsaufnahme-Tabelle, die alle URLs der alten Website auflistet. Das bedeutet, statische Seiten, Gebietsseiten und Blogbeiträge lückenlos zu erfassen – ebenso wie „Dateien, die keine Seiten sind, aber dennoch öffentlich zugänglich sind“, etwa robots.txt, die Search-Console-Eigentümerschaftsdatei oder Formular-Übermittlungsskripte. Darauf aufbauend erstellt man eine Zuordnungstabelle, die URL für URL entscheidet, ob sie unverändert bleibt oder weitergeleitet wird (301). Wenn diese Grundlage zuerst steht, verringert das Nacharbeit bei Implementierung und Content-Erstellung in späteren Phasen.

Was sind die wichtigsten Punkte beim Redirect-Design, um bei einem Relaunch keine Suchranking-Verluste zu erleiden?

Bedeutungstragende URLs – statische Seiten, Gebietsseiten und Ähnliches – bleiben unverändert (keep), während nur die bedeutungslosen, vom System automatisch nummerierten URLs per 301 auf neue URLs mit aussagekräftigem Slug weitergeleitet werden. Als Designregeln setzen wir ausnahmslos zwei Dinge durch: Jede Weiterleitung löst sich in einem einzigen Hop auf, ohne Ketten zu bilden, und der Build enthält eine Prüfung, die verifiziert, dass die Ziel-URL tatsächlich existiert, um den Unfall einer 301-Weiterleitung auf eine nicht existierende URL zu verhindern. Nach dem Launch überwachen wir die Search Console mehrere Wochen lang, bis die Weiterleitungen erkannt werden.

Warum führt ein Relaunch manchmal dazu, dass die Anfragen zurückgehen?

Weil im Prozess der Neugestaltung Informationen, die direkt die Anfrageentscheidung beeinflussen – Preise, Öffnungszeiten, Kontaktdaten, zentrale Stärken – unbemerkt verloren gehen können. Als Gegenmaßnahme erstellen wir eine Inhalts-Erhaltungs-Checkliste, die für jede Hauptseite die unverzichtbaren Informationen der alten Website festhält (Preispläne, Erreichbarkeitszeiten, angebotene Leistungen usw.), und gleichen vor dem Launch alte und neue Seiten Seite für Seite ab. Entscheidend ist, dies über eine Liste abzusichern statt sich auf Gedächtnis oder Bauchgefühl zu verlassen.

Ist es unbedenklich, eine ungenutzte Landingpage auf einer separaten Domain sich selbst zu überlassen?

Sie sich selbst zu überlassen ist riskant. In diesem Fall ließ sich die alte Landingpage-Domain für Kühl-/Tiefkühltransporte nicht mehr auflösen, vermutlich weil ihr DNS-Eintrag abgelaufen war – und obwohl die Inhalte bereits auf die neue Website migriert waren, gab es keine Möglichkeit mehr, von der alten Domain aus eine 301-Weiterleitung einzurichten. Lässt man eine Domain unbetreut und unverlängert liegen, kann man eines Tages plötzlich die dort angesammelte Backlink-Autorität und den Traffic aus Markensuchen verlieren. Bei einem geplanten Relaunch sollte man sowohl den Vertragsstatus der alten Domain als auch prüfen, ob ihr DNS noch aktiv ist, und die 301-Weiterleitung einrichten, solange eine Wiederherstellung noch möglich ist.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.