Website-Relaunch ohne SEO-Verluste: die Checkliste mit Weiterleitungen und Tests

Bei einem Website-Relaunch bleiben deine Rankings am ehesten erhalten, wenn jede alte URL mit einer dauerhaften, serverseitigen Weiterleitung (301 oder 308) direkt auf ihre neue Entsprechung zeigt, die Inhalte erhalten bleiben, die Sperren der Testumgebung beim Start fallen und Canonical, hreflang, interne Links und Sitemap auf die neuen Adressen umgestellt sind. Die Weiterleitungen behältst du mindestens ein Jahr, und in der Search Console beobachtest du über Wochen, wie Google umzieht. Wir zeigen jeden Schritt an einem eigenen Fall: Am 14. Oktober 2026 haben wir die Adressen von neun deutschen Ratgebern geändert, mit 308-Weiterleitungen, und jede Antwort unseres Servers mitgeschnitten.

Was bei einem Relaunch für Google passiert

„Relaunch“ kann vieles heißen: ein neues Design, ein neues Content-Management-System (CMS), eine neue Domain, neue URLs, neu geschriebene Inhalte. Für die Suche zählt vor allem, was sich an Adressen, Inhalten und Verlinkung ändert. Ein neues Design auf denselben URLs mit denselben Texten ist für Google eine kleine Änderung. Eine neue URL-Struktur ist ein Umzug.

Google beschreibt einen solchen Umzug in seiner Anleitung „Website migrieren“ so: Der Googlebot muss jede URL der alten und der neuen Website mindestens einmal aufrufen, und die Migration erfolgt URL für URL. Signale wie Links wandern über die Weiterleitungen von der alten zur neuen Adresse. Laut Google haben 301- und andere dauerhafte Weiterleitungen keine negativen Auswirkungen auf den PageRank.

Drei Ratschläge aus derselben Anleitung prägen den ganzen Ablauf:

• Nicht alles auf einmal ändern. Google rät, Änderungen nacheinander vorzunehmen, etwa zuerst die Domain zu wechseln und danach das Layout.
• Einen ruhigen Zeitpunkt wählen. Am besten ziehst du in einer Phase mit wenig Traffic um, damit Fehler weniger Schaden anrichten.
• Mit Schwankungen rechnen. Während Google neu crawlt und indexiert, kann sich das Ranking vorübergehend ändern.

Unser eigener Fall: neun neue Adressen an einem Tag

Unsere deutschen Ratgeber gingen am 14. Oktober 2026 online, zunächst mit kurzen Adressen wie /de/blog/hreflang. Noch am selben Tag haben wir uns für längere, beschreibende Slugs entschieden, die neben dem Haupt-Keyword auch das wichtigste Unterthema nennen, etwa /de/blog/hreflang-x-default-canonical-dach. Für alle neun Ratgeber gilt seitdem eine dauerhafte Weiterleitung von der alten auf die neue Adresse. Schon am Vorabend hatten wir die Adresse unserer Autorenseite geändert, von /authors/sukru auf /authors/sukru-celik.

Ehrlich gesagt ist das ein kleiner Fall: Die alten Adressen waren nur wenige Stunden alt, hatten keine Rankings und kaum Links. Was wir zeigen können, ist die Technik: Statuscodes, Weiterleitungsketten, Sitemap und hreflang, gemessen an unserer echten Website. Was wir nicht zeigen können, ist der Effekt auf Rankings. Den Zeitpunkt haben wir bewusst so früh gewählt. Je später eine Adresse geändert wird, desto mehr Links, Lesezeichen und Signale hängen an ihr.

Schritt 1: Alle alten URLs sammeln

Eine Weiterleitung kannst du nur für eine Adresse einrichten, die du kennst. Die Liste der alten URLs ist deshalb die Grundlage des ganzen Relaunches. Google empfiehlt in seiner Anleitung mehrere Quellen, weil keine allein vollständig ist:

• XML-Sitemaps der alten Website;
• Serverprotokolle mit allen URLs, die in letzter Zeit aufgerufen wurden; wähle einen Zeitraum, der auch saisonale Seiten abdeckt;
• Analytics mit den Seiten, die den meisten Traffic bringen;
• die Search Console, vor allem den Bericht „Links“ mit den Seiten, auf die andere Websites verlinken;
• dein CMS, das alle veröffentlichten Seiten kennt;
• einen Crawl der alten Website. Die kostenlose Version des Screaming Frog SEO Spider crawlt bis zu 500 URLs.

Denk dabei nicht nur an HTML-Seiten. Google nennt ausdrücklich auch Bilder, Videos, PDFs sowie JavaScript- und CSS-Dateien. Ein PDF, das seit Jahren Traffic aus der Suche bekommt, ist nach dem Relaunch genauso wertvoll wie eine Seite.

Sichere bei der Gelegenheit den Ausgangszustand: Exportiere die Leistungsdaten je URL aus der Search Console (Klicks, Impressionen, Position), notiere Titel und Meta-Descriptions und speichere den Crawl. Ohne diese Daten kannst du nach dem Relaunch nicht sagen, welche Seite verloren hat.

Schritt 2: Die Weiterleitungstabelle

Für jede alte URL legst du fest, wohin sie künftig führt. Das Ergebnis ist eine Tabelle mit zwei Spalten, alt und neu, im Fachjargon das Redirect-Mapping. Dabei gelten ein paar Regeln:

1. Eins zu eins: Jede alte Seite zeigt auf die neue Seite mit demselben Inhalt.
2. Zusammengelegt: Werden zwei Seiten zu einer, zeigen beide alten Adressen auf die neue gemeinsame Seite.
3. Gestrichen: Gibt es keinen Nachfolger, antwortet die alte Adresse mit 404 oder 410. Google behandelt beide Codes laut seiner Dokumentation gleich: Alle 4xx-Fehler außer 429 werden gleich behandelt.
4. Nicht alles auf die Startseite: Google rät ausdrücklich davon ab, eine größere Zahl alter URLs auf eine einzige irrelevante Ziel-URL wie die Startseite weiterzuleiten. Das kann Nutzer verwirren und als Soft-404-Fehler gewertet werden.
5. Direkt aufs Ziel: Jede Regel zeigt auf die endgültige Adresse, nicht auf eine Adresse, die selbst noch einmal weiterleitet.

Bei uns steht die Tabelle direkt im Code der Website, in der Datei next.config.ts. Jede Zeile ist ein Paar aus altem und neuem Slug:

Das hat einen Vorteil und einen Haken. Der Vorteil: Die Regeln liegen in der Versionsverwaltung, jede Änderung ist datiert und nachvollziehbar. Der Haken: Die Regeln gehen erst mit dem nächsten Deploy online. Hätten wir die Slugs nur im CMS geändert, hätten die alten Adressen bis dahin mit 404 geantwortet. Wer Adressen im CMS ändert, sollte deshalb wissen, ob das System die Weiterleitung selbst anlegt oder ob jemand sie von Hand einrichten muss.

301, 308, 302, 307: Welcher Statuscode wofür?

Google unterscheidet dauerhafte und temporäre Weiterleitungen. Bei dauerhaften zeigt Google das neue Ziel in den Suchergebnissen, bei temporären die Quellseite. Die wichtigsten Statuscodes laut Google:

• 301 (Moved Permanently): dauerhaft, ein starkes Signal, dass das Ziel verarbeitet werden soll.
• 308 (Permanent Redirect): laut Google „gleichbedeutend mit 301“.
• 302 (Found): temporär, ein schwaches Signal.
• 307 (Temporary Redirect): gleichbedeutend mit 302.

Für einen Relaunch nimmst du also 301 oder 308. Der Unterschied zwischen beiden liegt außerhalb der Suche: Nach dem HTTP-Standard RFC 9110 darf ein Client bei 301 und 302 aus historischen Gründen eine POST-Anfrage in eine GET-Anfrage umwandeln, bei 307 und 308 nicht. Next.js, auf dem unsere Website läuft, verwendet deshalb 308 für dauerhafte und 307 für temporäre Weiterleitungen. Laut der Next.js-Dokumentation kommt bei 308 automatisch eine Refresh-Kopfzeile dazu, damit auch der alte Internet Explorer 11 der Weiterleitung folgt. Genau diese Kopfzeile siehst du in unserer curl-Ausgabe weiter unten.

Daneben gibt es Weiterleitungen, die nicht der Server, sondern die Seite selbst auslöst. Ein meta refresh mit null Sekunden Verzögerung wertet Google als dauerhaft, mit Verzögerung als temporär. JavaScript-Weiterleitungen solltest du laut Google nur verwenden, wenn weder eine serverseitige Weiterleitung noch ein meta refresh möglich ist. Google listet die Methoden in der Reihenfolge, in der es sie am zuverlässigsten erkennt, und serverseitige Weiterleitungen stehen ganz oben.

Achte auf Voreinstellungen, die unbemerkt eine temporäre Weiterleitung erzeugen. Beim Webserver Apache wird eine Redirect-Anweisung ohne Statusangabe laut Dokumentation zu einer temporären 302-Weiterleitung. In Next.js ergibt permanent: false eine 307. Viele Hoster lassen dich den Statuscode einer Domain-Weiterleitung im Dashboard wählen; prüfe dort, was eingestellt ist. Bing empfiehlt übrigens 301 für dauerhafte Änderungen und 302 nur für sehr kurze, weniger als zwei Tage.

Die Testumgebung sperren, ohne den Start zu gefährden

Eine neue Website entsteht meist auf einer Testumgebung, auch Staging genannt. Sie darf nicht in den Suchergebnissen landen, sonst konkurriert sie mit der echten Website. Drei Wege werden dafür oft genannt, und nur zwei davon funktionieren zuverlässig:

• robots.txt reicht nicht. Laut Google ist robots.txt nicht dafür gedacht, Webseiten aus der Google Suche auszuschließen. Eine gesperrte URL kann trotzdem indexiert werden, wenn andere Seiten auf sie verweisen.
• noindex wirkt, aber nur, wenn Google die Seite crawlen darf. Ist sie per robots.txt gesperrt, sieht der Crawler die noindex-Regel nicht. Die Regel kann im HTML-Kopf stehen oder als X-Robots-Tag in der HTTP-Antwort.
• Ein Passwort ist die sicherste Sperre, weil niemand ohne Zugang die Seiten sieht, auch kein Crawler.

Das größere Risiko ist nicht die Sperre, sondern ihr Ende. Eine noindex-Regel oder ein „Disallow: /“, das den Start überlebt, nimmt der neuen Website die Sichtbarkeit. Google nennt solche Reste in seiner Fehlerliste für Migrationen an erster Stelle. Plane deshalb vorher, welche Sperren am Starttag fallen, und prüfe danach jede einzelne.

Wir haben das mit einem einzigen Schalter gelöst. Bis zum Start schickte unsere Website auf jede Anfrage die Kopfzeile „X-Robots-Tag: noindex, nofollow“, und die robots.txt erlaubte das Crawlen, nannte aber keine Sitemap. So konnte Google die noindex-Regel sehen, und keine Seite wurde indexiert. Am Abend des 13. Oktober 2026 haben wir eine Umgebungsvariable umgestellt und die Website neu gebaut. Seitdem fehlt die Kopfzeile, und die robots.txt nennt die Sitemap. Es gab keine Liste von Sperren, die jemand einzeln entfernen musste.

Canonical, hreflang, interne Links und Sitemap umstellen

Eine Weiterleitung allein reicht nicht. Auf der neuen Website müssen alle Hinweise, die Google ausliest, auf die neuen Adressen zeigen:

• Canonical: Jede neue Seite verweist mit rel="canonical" auf sich selbst, nicht auf ihre alte Adresse.
• hreflang: Hat die Seite Sprachfassungen, müssen alle auf die neuen Adressen zeigen, in beide Richtungen. Google nennt das in seiner Migrationsanleitung ausdrücklich. Ändert sich bei uns die deutsche Adresse, muss auch die englische Fassung auf die neue deutsche Adresse verweisen. Wie hreflang funktioniert, steht in unserem Ratgeber zu hreflang, x-default und Canonical.
• Interne Links: Links zwischen deinen eigenen Seiten führen direkt auf die neuen Adressen. Jeder interne Link über eine Weiterleitung kostet Ladezeit und Crawling.
• Sitemap: Die Sitemap enthält nur die neuen, kanonischen Adressen.

Bei uns passierten alle vier Umstellungen automatisch, weil die Website sie aus dem CMS erzeugt. Interne Links schreiben wir im Text nicht als Adresse, sondern als Verweis auf einen Artikelschlüssel; die Website setzt beim Ausliefern den aktuellen Slug der jeweiligen Sprache ein. Nach der Änderung zeigte deshalb kein interner Link auf eine alte Adresse. Die englische Fassung des hreflang-Ratgebers nennt seitdem im hreflang-Tag für Deutsch die neue Adresse, und die deutsche Sitemap enthielt nach dem Deploy keine einzige alte Adresse mehr:

Zur alten Sitemap gibt es zwei Ansichten. Google beschreibt, dass du eine Sitemap der alten URLs eine Zeit lang zusätzlich einreichen kannst, um in der Search Console zu sehen, wie die Zahl ihrer indexierten Seiten sinkt und die der neuen steigt. Bing wünscht dagegen, dass weitergeleitete URLs zügig aus Sitemaps verschwinden. Unser Vorschlag: Die öffentliche Sitemap enthält nur neue Adressen. Eine Sitemap der alten Adressen reichst du höchstens vorübergehend in der Search Console ein, als Messinstrument, und entfernst sie, sobald der Umzug abgeschlossen ist.

Der Starttag in der richtigen Reihenfolge

Am Tag des Relaunches kommt es auf die Reihenfolge an:

1. Weiterleitungen aktivieren und Sperren entfernen, im selben Schritt: Passwort, noindex und alte robots.txt-Regeln der Testumgebung fallen, die Weiterleitungen gehen online.
2. robots.txt prüfen: Sie muss erreichbar sein und darf die Website nicht sperren. Antwortet sie mit einem Serverfehler, stellt Google das Crawling der Website laut seiner Dokumentation in den ersten zwölf Stunden ein.
3. Weiterleitungen testen: jede alte URL einmal, mit Statuscode, Ziel und Zahl der Sprünge (siehe nächster Abschnitt).
4. Neue Sitemap einreichen in der Search Console und, wenn du Bing nutzt, in den Bing Webmaster Tools.
5. Adressänderung melden, aber nur bei einem Domainwechsel (siehe unten).
6. Links aktualisieren, die du selbst in der Hand hast: Profile in sozialen Netzwerken, Anzeigen, E-Mail-Signaturen. Google rät außerdem, Betreiber wichtiger verlinkender Websites um eine Aktualisierung zu bitten.
7. Wichtige Seiten einzeln prüfen mit dem URL-Prüftool der Search Console, das ein Tageslimit hat. Für viele Seiten ist die Sitemap der bessere Weg.
8. Tracking prüfen: Läuft die Webanalyse auf den neuen Vorlagen?

Weiterleitungen testen: curl, Browser und Crawler

Ob eine Weiterleitung stimmt, siehst du am zuverlässigsten in der rohen Antwort des Servers. Das Kommandozeilenwerkzeug curl ist unter Windows 11 und macOS vorinstalliert und auf den meisten Linux-Systemen vorhanden. Für eine einzelne Adresse genügen diese Befehle:

• curl -sI https://example.de/alte-seite zeigt Statuscode und Location-Kopfzeile der ersten Antwort.
• curl -sIL https://example.de/alte-seite folgt der ganzen Kette und zeigt die Kopfzeilen jeder Station.
• curl -s -o /dev/null -w "%{http_code} %{redirect_url}" https://example.de/alte-seite gibt nur Statuscode und Ziel aus, praktisch für Listen. Unter Windows schreibst du NUL statt /dev/null.

Achtung unter Windows: In der Windows PowerShell 5.1 ist curl nur ein anderer Name für das Cmdlet Invoke-WebRequest, das andere Optionen kennt. Tippe dort curl.exe, dann startet das echte curl. So sieht die Antwort unseres Servers auf eine der alten Adressen aus:

Prüfe nicht nur die Adresse, die du kennst, sondern auch die Varianten, über die Besucher und Crawler kommen: http statt https, mit und ohne www. Dort verstecken sich zusätzliche Sprünge. Wir haben dieselbe alte Adresse über vier Einstiege abgefragt:

Über https braucht die alte Adresse einen Sprung, über http mit www drei: von http zu https, von www zur Domain ohne www und vom alten zum neuen Slug. Das liegt noch im Rahmen dessen, was Google empfiehlt. Der Googlebot folgt laut Google bis zu zehn Sprüngen, aber besser ist eine direkte Weiterleitung zum Ziel; wenn das nicht geht, sollten es im Idealfall bis zu drei und höchstens vier sein. Wer bei einem Relaunch neue Weiterleitungen auf alte Domain- und Protokoll-Weiterleitungen stapelt, ist schnell darüber.

Zwei Eigenheiten des Browsers machen ihn zu einem schlechten Prüfwerkzeug:

• Der Cache: Laut der Next.js-Dokumentation weist ein 308 Clients an, die Weiterleitung für immer zu speichern. Hat ein Browser eine falsche dauerhafte Weiterleitung einmal gespeichert, folgt er ihr womöglich weiter, auch wenn du sie längst korrigiert hast. Unser Server schickt bei der Weiterleitung „Cache-Control: public, max-age=0, must-revalidate“ mit, also die Aufforderung, jedes Mal neu nachzufragen. Teste trotzdem mit curl, in einem privaten Fenster oder mit der Option „Cache deaktivieren“ in den Entwicklertools.
• HSTS: Unsere Domain schickt die Kopfzeile Strict-Transport-Security. Wer die Website einmal über https geöffnet hat, dessen Chrome wechselt bei einem http-Link selbst zu https, ohne den Server zu fragen. Im Netzwerkprotokoll steht dann „307 Internal Redirect“, mit dem Grund HSTS. Das ist keine temporäre Weiterleitung deines Servers, auch wenn die 307 so aussieht.

Für viele Adressen auf einmal nimmst du eine Textdatei mit allen alten URLs und lässt curl sie in einer Schleife abfragen, oder du nutzt den Listenmodus eines Crawlers wie Screaming Frog. Beides liefert eine Tabelle mit Statuscode und Ziel je Adresse. Gesucht sind drei Fehler: jede 302 oder 307, die eine 301 oder 308 sein sollte, jede 404, die eine Weiterleitung haben sollte, und jede Kette mit mehr als einem Sprung über https.

Das URL-Prüftool der Search Console ist für Weiterleitungen übrigens nur bedingt geeignet. Laut seiner Hilfeseite folgt der Live-Test Weiterleitungen, ohne die endgültige URL anzuzeigen. Eine andere Google-Seite sagt, die Prüftools folgten gar keinen Weiterleitungen. Für die Frage „Was antwortet mein Server?“ ist curl die eindeutigere Quelle.

Die Search Console nach dem Relaunch

In den Wochen nach dem Start zeigen drei Berichte, ob der Umzug läuft.

Seitenindexierung. Für alte Adressen ist der Status „Seite mit Weiterleitung“ das erwartete Ergebnis: Die URL leitet weiter und wird deshalb nicht indexiert. Aufmerksam werden solltest du bei diesen Gründen:

• „Nicht gefunden (404)“: in Ordnung für Seiten, die du bewusst gestrichen hast, ein Fehler für Seiten, die nur umgezogen sind;
• „Soft 404-Fehler“: oft die Folge von Weiterleitungen auf die Startseite oder auf unpassende Ziele;
• „Weiterleitungsfehler“: eine zu lange Kette, eine Schleife oder ein ungültiges Ziel;
• „URL wird von der robots.txt-Datei blockiert“ und „URL als ‚noindex‘ markiert“ bei neuen Seiten: Reste der Testumgebung.

Crawling-Statistik. Der Bericht teilt die Antworten des Servers nach Typ auf. 308 zählt dort zu „Dauerhaft verschoben (301)“, 307 zu „Vorübergehend verschoben (302)“. Steigt nach dem Relaunch der Anteil vorübergehender Weiterleitungen, ist irgendwo die falsche Einstellung aktiv. „Verschoben (Sonstiges)“ steht für meta refresh.

Sitemaps. Hier siehst du je eingereichter Sitemap, wie viele Adressen Google gefunden und indexiert hat. Hast du die alte Sitemap vorübergehend eingereicht, sollte ihre Zahl indexierter Seiten sinken und die der neuen steigen.

Dazu kommt der Leistungsbericht mit Klicks und Impressionen je Seite. Vergleiche die neuen Adressen mit den Werten der alten aus deinem Export vor dem Relaunch. Unsere eigenen Berichte haben noch keine Daten, weil die Website erst am 13. Oktober 2026 gestartet ist.

Wie lange der Umzug dauert

Feste Wochenzahlen findest du in vielen Relaunch-Ratgebern, eine Quelle meist nicht. Google selbst ist vorsichtiger: Bei einer kleinen bis mittelgroßen Website dauere es im Allgemeinen einige Wochen, bis die meisten Seiten migriert sind, bei größeren Websites länger. Wie schnell es geht, hänge vor allem von der Zahl der URLs und der Geschwindigkeit deiner Server ab. Eine eingereichte Sitemap kann den Prozess laut Google beschleunigen.

John Mueller von Google sagte 2022 in einem Video, über das Search Engine Land berichtete, dass Google eine URL-Änderung vollständig erst nach mehreren Monaten verarbeitet haben kann; wichtigere URLs gehen schneller, weniger wichtige dauern länger. Schwankungen im Ranking während dieser Zeit sind laut Google normal.

Wenn du eine Zahl brauchst, um ein Projekt zu planen, rechne also mit Wochen für das Gros der Seiten und mit Monaten, bis alles abgeschlossen ist, und miss es in der Search Console nach, statt einer pauschalen Zahl zu vertrauen.

Wie lange Weiterleitungen bleiben müssen

Google ist hier eindeutig: „Behalte die Weiterleitungen möglichst lange bei, generell mindestens für ein Jahr.“ Aus Sicht der Nutzer ist es am besten, sie gar nicht mehr zu entfernen; alte Links in E-Mails, PDFs und Foren leben oft länger als jede Website-Version. Wir haben unsere zehn Weiterleitungen deshalb ohne Ablaufdatum angelegt.

Zwei Situationen führen trotzdem oft dazu, dass Weiterleitungen verschwinden:

• Beim nächsten Relaunch. Die alten Regeln gehen beim Umbau verloren, weil niemand mehr weiß, wofür sie da sind. Dokumentiere sie deshalb mit Datum und Grund, wie wir es in den Kommentaren unserer next.config.ts tun.
• Beim Aufräumen von Ketten. Entsteht durch einen zweiten Umzug eine Kette von A über B nach C, löst du sie auf, indem du die Regel für A direkt auf C zeigen lässt. Lösche nie die Regel für A.

Bei einem Domainwechsel kommt eine dritte Regel hinzu: Google empfiehlt, die alte Domain mindestens ein Jahr weiter zu bezahlen, damit sie niemand für schädliche Zwecke kauft und nutzt.

Domainwechsel: wann das Tool zur Adressänderung hilft

Die Search Console hat ein „Tool zur Adressänderung“. Es gehört zu den Werkzeugen, die in Relaunch-Checklisten am häufigsten falsch einsortiert werden, denn es ist laut Google nur für den Umzug von einer Domain oder Subdomain auf eine andere gedacht. Ausdrücklich nicht dafür:

• der Wechsel von http zu https;
• das Verschieben von Seiten innerhalb deiner Website, etwa von beispiel.de/alterpfad/ zu beispiel.de/neuerpfad/;
• der Wechsel zwischen Varianten mit und ohne www.

Unser Fall, neue Pfade auf derselben Domain, braucht das Tool also nicht. Ziehst du dagegen auf eine neue Domain um, meldest du die Änderung für jede bestätigte Variante der alten Domain, auch für www. Laut Google zeigt die Search Console den Umzug dann 180 Tage lang an. In dieser Zeit sollen die Weiterleitungen mindestens bestehen, länger, solange über sie noch Traffic aus der Suche kommt. Für alle anderen Fälle gilt die allgemeine Regel von mindestens einem Jahr.

Die häufigsten Relaunch-Fehler

Aus Googles Anleitungen und unserem eigenen Umzug haben wir die Fehler zusammengestellt, die am meisten kosten:

1. Die Sperre der Testumgebung geht mit online. noindex, „Disallow: /“ oder ein Passwort überleben den Start. Prüfe nach dem Start die Kopfzeilen einer Seite mit curl und die robots.txt im Browser.
2. robots.txt als einzige Sperre. Sie verhindert das Crawlen, nicht die Indexierung, und versteckt eine noindex-Regel vor dem Crawler.
3. Alte URLs per robots.txt gesperrt. Kann der Googlebot eine alte Adresse nicht abrufen, sieht er auch ihre Weiterleitung nicht.
4. Alles auf die Startseite. Google kann das als Soft 404 werten. Ohne passenden Nachfolger ist 404 oder 410 die ehrlichere Antwort.
5. Temporär statt dauerhaft. Voreinstellungen von Server, CMS oder Hoster erzeugen 302 oder 307, wo 301 oder 308 hingehört.
6. Ketten und Schleifen. Alte Regeln zeigen auf Adressen, die selbst weiterleiten, oft zusätzlich über http und www.
7. Inhalt und URLs gleichzeitig geändert. Google rät, eins nach dem anderen zu ändern. Wer alles auf einmal umbaut, kann später nicht sagen, welche Änderung geschadet hat.
8. Bilder, PDFs und andere Dateien vergessen. Auch sie haben Adressen, Links und Traffic.
9. Canonical und hreflang zeigen auf alte Adressen, vor allem in den anderen Sprachfassungen einer mehrsprachigen Website.
10. Interne Links bleiben auf alten Adressen. Jeder Klick und jeder Crawl nimmt dann einen Umweg.
11. Die Sitemap enthält weiter alte Adressen oder wird nach dem Start gar nicht aktualisiert.
12. Weiterleitungen zu früh entfernt, etwa beim nächsten Umbau oder weil eine Seite scheinbar keinen Traffic mehr hat.
13. Das Tool zur Adressänderung für den falschen Fall, oder bei einem echten Domainwechsel gar nicht genutzt.
14. Nur im Browser getestet. Cache und HSTS zeigen dir dort nicht, was der Server gerade sendet.
15. Kein Export vor dem Start. Ohne die alten Werte je URL lässt sich ein Verlust nicht zuordnen.

Checkliste zum Abhaken

Vorher

1. Festlegen, was sich ändert: Domain, Protokoll, URLs, CMS, Design, Inhalte. Möglichst nicht alles auf einmal.
2. Alle alten URLs sammeln: Sitemaps, Serverprotokolle, Analytics, Search Console, CMS, Crawl; dazu Bilder, PDFs und andere Dateien.
3. Ausgangszustand sichern: Leistungsdaten je URL, Titel, Meta-Descriptions, Crawl.
4. Weiterleitungstabelle anlegen: eins zu eins, Zusammenlegungen, 404 oder 410 für Gestrichenes, nichts pauschal auf die Startseite.
5. Statuscode festlegen: 301 oder 308, serverseitig, direkt aufs Ziel; Voreinstellungen von Server und Hoster prüfen.
6. Testumgebung mit Passwort oder noindex sperren und das Ende der Sperre planen.
7. Auf der Testumgebung prüfen: Canonical auf sich selbst, hreflang auf neue Adressen, interne Links, neue Sitemap.
8. Alle Varianten der Website in der Search Console bestätigen.
9. Eine Textdatei mit allen alten URLs für die Tests vorbereiten.

Am Starttag

10. Weiterleitungen aktivieren und Sperren entfernen, im selben Schritt.
11. robots.txt prüfen.
12. Alle alten URLs mit curl oder einem Crawler testen, auch über http und www.
13. Neue Sitemap einreichen.
14. Bei einem Domainwechsel: Adressänderung in der Search Console melden.
15. Eigene Links in Profilen, Anzeigen und Signaturen aktualisieren.

Danach

16. Seitenindexierung, Crawling-Statistik und Sitemaps wöchentlich ansehen.
17. 404-Fehler und Soft-404-Fehler bei umgezogenen Seiten beheben.
18. Ketten auflösen, indem alte Regeln direkt aufs Ziel zeigen.
19. Wichtige externe Links um eine Aktualisierung bitten.
20. Weiterleitungen mindestens ein Jahr behalten, am besten dauerhaft, und mit Datum und Grund dokumentieren.