Website Redesign SEO Checkliste: Replatforming ohne Trafficverlust

Ein Website Redesign ist der häufigste Moment, in dem SEO Traffic still und leise vernichtet wird. Nicht durch ein Google Update, nicht durch einen Wettbewerber, sondern durch einen Launch, bei dem jemand die Redirect Map vergessen hat, die neuen URLs “weil sie sauberer aussehen” kürzer wurden und die strukturierten Daten nur in den alten Templates lebten. Wenn das Dashboard einen Rückgang des organischen Traffics um 40 Prozent zeigt, ist das Projekt geschlossen, das Team weitergezogen und jemand muss erklären, warum die neue Seite zwar schön aussieht, aber für nichts mehr rankt.

Diese Checkliste soll diese Geschichte verhindern. Sie geht durch die Arbeit, die vor, während und nach einem Redesign passieren muss, damit die in Jahren aufgebaute Sichtbarkeit mit der neuen Seite mitgeht, statt zurückgelassen zu werden. Sie ist um die Momente herum aufgebaut, in denen Dinge tatsächlich schiefgehen.

Warum Redesigns SEO einbrechen lassen

Die kurze Antwort lautet, Suchmaschinen sehen alte Seite und neue Seite als zwei verschiedene Sites, solange Sie ihnen nicht ausdrücklich das Gegenteil sagen. Jede Änderung bringt eine Chance mit sich, dass dieses Signal bricht.

URLs ändern sich, weil die neue Informationsarchitektur sauberer ist. Die Redirect Map vergisst den Long Tail. Meta Titel werden von einer neuen Texterin überarbeitet, die die alten Muster nicht kannte. Interne Verlinkungen gehen über drei Sprünge, weil das Dev Team “Kompatibilitäts Weiterleitungen” ohne Prüfung der Ziele eingebaut hat. Die XML Sitemap wird neu generiert und listet nur die live geschalteten neuen URLs, während Google immer noch 50.000 alte URLs im Index hat, die nicht mehr aufgelöst werden.

Nichts davon ist Böswilligkeit. Es ist das absehbare Ergebnis eines Projekts, das SEO als “Phase 2” behandelt, statt es in jede Entscheidung einzubauen. Die Lösung ist, diese Entscheidungen früh sichtbar zu machen und die Antworten in den Launch Plan einzubauen.

Phase 1: Audit vor dem Redesign

Bevor das Designteam Figma öffnet, braucht das SEO Team ein vollständiges Bild dessen, was die aktuelle Seite einbringt. Das ist die Grundlinie, gegen die später alles gemessen wird.

Die aktuelle Seite vollständig crawlen. Mit einem echten SEO Crawler mit JavaScript Rendering, vollständiges URL Inventar exportieren. Für jede URL erfassen: Statuscode, finales Canonical, Meta Titel, Meta Description, H1, Anzahl interner Links, Anzahl externer Backlinks und organischer Traffic der letzten 12 Monate. Dieser Datensatz ist die Wahrheitsquelle für die Redirect Map.

Search Console Performance der letzten 16 Monate abrufen. URLs mit Klicks und Impressionen, die Queries, die sie gebracht haben, und die Trafficverteilung auf Seitenebene. Die obersten 20 Prozent der Seiten bringen meist 80 Prozent des Traffics. Diese Seiten brauchen explizite Erhaltungspläne; der Long Tail kann über Muster gelöst werden.

Backlink Daten exportieren. URLs mit eingehenden Links. Eine Seite ohne organischen Traffic aber mit starken Backlinks ist trotzdem ein kritischer Wert, weil dieses Linkpotenzial durch sie zur restlichen Seite fließt. Diese Seite in einer Migration zu verlieren ist in Traffic Dashboards unsichtbar, aber langfristig in der Gesamtautorität der Seite sichtbar.

Strukturierte Daten kartieren. Welche Schema Typen leben auf welchen Templates? Article, Product, Organization, BreadcrumbList, FAQPage. Jeder davon muss in den neuen Templates erhalten bleiben, idealerweise mit identischem oder verbessertem Markup. Eine Seite, die ihr FAQPage Schema verliert, verliert beim nächsten Recrawl ihren Rich Result Platz.

URL Muster dokumentieren. Wie sind die URLs heute aufgebaut? /blog/{slug}, /product/{kategorie}/{slug}, /{lang}/{section}/{slug}. Die neue Seite muss diese Muster nicht behalten, aber jede Änderung braucht einen Redirect. Schreiben Sie die Muster auf, bevor irgendeine Entscheidung über die neue Architektur fällt.

Das Ergebnis von Phase 1 ist eine Tabelle mit jeder URL der aktuellen Seite, ihren Schlüsselsignalen und ihrem geplanten Ziel auf der neuen Seite. Diese Tabelle ist die Wahrheitsquelle für alles, was folgt. Ein solides technisches SEO Audit ist der richtige Rahmen für diese Phase.

Phase 2: Die Redirect Map (das wichtigste Artefakt)

An der Redirect Map scheitern die meisten Migrationen. Es ist gleichzeitig der Teil, der am leichtesten richtig wird, wenn man ihn früh ernst nimmt.

Eine Redirect Map ist eine Liste alter URLs und der neuen URL, an die jede gesendet werden soll, sowohl für Nutzer als auch für Suchmaschinen. Sie muss jede jemals indexierte URL abdecken, nicht nur die heute populären. Vergessene Seiten mit hochwertigen Backlinks sind häufig; sie tragen täglich zur Autorität der Seite bei, bis die Redirect Map sie fallen lässt.

Regeln für eine gute Redirect Map.

Jede Weiterleitung ist HTTP 301, nicht 302. Eine 301 sagt Google, dass der Umzug dauerhaft ist und das Signal mitnimmt; eine 302 hält die alte URL als Canonical und verliert Signal. 302 nur für wirklich vorübergehende Bewegungen (ein Ausfall, ein A/B Test).

Jede Weiterleitung landet auf einem relevanten Ziel, nicht auf der Startseite. /blog/post-zu-hreflang auf /blog weiterzuleiten, weil “die Startseite passt überall”, verliert die Relevanz. Das richtige Ziel ist die neue Seite mit demselben Thema, auch wenn sie kein perfekter Treffer ist. Besser 80 Prozent thematisch zu landen, als auf eine generische Übersicht.

Jede Weiterleitung ist ein einzelner Sprung. /old-url → /intermediate-url → /new-url ist eine Weiterleitungs Kette, die Equity verliert und das Crawlen verlangsamt. Immer direkt auf die finale URL weiterleiten, auch wenn das alte verkettete Regeln neu zu schreiben bedeutet.

Jede Parameter Variante ist abgedeckt. /blog/post?utm_source=... soll sauber weiterleiten, idealerweise mit gestripptem Parameter auf der neuen Seite. Vergessene Parameter Varianten sind, wie Analytics nach dem Launch wochenlang bricht.

Die Map im Maßstab bauen.

Für musterbasierte Änderungen (/blog/post wird zu /articles/post) reguläre Ausdrücke in den Redirect Regeln nutzen. Für Einzelfälle jedes Paar explizit listen. Die meisten Redirect Maps landen bei 70 Prozent Mustern und 30 Prozent explizit, das ist gesund.

Die Map vor dem Launch validieren. Einen Crawler gegen die neue Site mit den alten URLs als Eingabe laufen lassen. Jede alte URL soll auf eine 301 treffen und bei 200 landen. Jede 404 im Bericht ist ein Loch; jede 301 zu 301 ist eine Kette; jede 200 von einer alten URL bedeutet, dass eine Weiterleitungsregel nie konfiguriert wurde.

Phase 3: Entscheidungen zur URL Struktur

Wenn die neue Seite dieselben URLs behält, überspringen Sie diese Phase. Die meisten Redesigns tun das nicht. Neue URL Strukturen sind eine Designchance, aber jede Änderung hat einen Preis.

Widerstehen Sie dem Drang, URLs “aufzuräumen”, wenn es keinen echten Grund gibt. Eine URL wie /blog/2023/06/article-title wirkt veraltet, aber sie zu ändern bedeutet einen Redirect für jeden je veröffentlichten Blogpost. Wenn die datierte Struktur nicht aktiv schadet (tut sie nicht), lassen Sie sie. Geben Sie das Redirect Budget für Strukturen aus, die wirklich kaputt sind.

Eine klare Hierarchie wählen und durchhalten. Eine URL wie /kategorie/unterkategorie/produkt-slug liest sich für Menschen und Suchmaschinen gut. Inkonsistente Tiefen (/produkt-slug für manche, /kategorie/produkt-slug für andere) machen die Seite schwerer crawlbar und schwerer interpretierbar.

Trailing Slashes einmal und für immer entscheiden. /about/ und /about sind für Suchmaschinen unterschiedliche URLs. Eines wählen und serverseitig mit einem Redirect erzwingen. Das Mischen ist ein langsamer Verlust durch Duplikatspaare und verschenktes Linkpotenzial.

Sprach und Regions Präfixe sorgfältig behandeln. Wenn die neue Seite hreflang zum ersten Mal einführt, ist das ein eigenes Projekt. Der hreflang Implementierungsleitfaden deckt die Regeln ab.

Stoppwörter und Füller vermeiden. /der-beste-leitfaden-zu-seo ist schlechter als /seo-leitfaden. Kürzere und direktere URLs sind leichter zu scannen, teilen und merken. Aber kürzer heißt nicht kryptisch; /g1 ist aus ganz anderen Gründen schlecht.

Eine Übersicht:

Phase 4: On Page Signale übernehmen

Jede Seite der neuen Site muss die SEO Signale tragen, die der alten Seite ihre Rankings eingebracht haben. Das ist meist unsichtbare Arbeit, die verschwindet, wenn sie gelingt.

Title Tags und Meta Descriptions. Die bestehenden Tags standardmäßig übernehmen. Wenn das Team neue möchte, ist das eine Entscheidung pro Seite, kein automatischer Überschreib. Seiten mit starkem CTR in der Search Console sollten ihre bewährten Titel behalten. Die volle Mechanik liegt im Meta Tags SEO Leitfaden.

Überschriften Struktur. Jede Seite soll weiterhin ein H1, hierarchisch sortierte H2 und H3 und Inhalte haben, die zu ihren Queries passen. Ein Redesign, das alle Überschriften zu divs verflacht, weil “das Designsystem divs nutzt”, ist eine selbst zugefügte SEO Wunde.

Interne Verlinkung. Den internen Linkgraph vor der Migration kartieren. Wenn Seite A auf Seite B mit Ankertext “X Technik” verlinkt und B jetzt /new-url ist, sollte der Link von A auf die neue URL zeigen, nicht durch die 301 laufen. Interne Links durch 301 sind nicht fatal, aber unsauber und sie summieren sich.

Canonical Tags. Jede indexierbare Seite der neuen Site braucht ein selbstreferenzierendes Canonical. Seiten, die berechtigt auf eine andere URL konsolidiert werden (Parametervarianten, paginierten Ansichten, regionale Duplikate), brauchen Canonicals, die auf den Master zeigen. Der Canonical Tags Leitfaden ist die Referenz für die Regeln.

Strukturierte Daten. Jeden Schema Typ aus den alten Templates übernehmen. Wenn noch kein Inventar existiert, einen Crawl mit dem Rahmen aus dem Schema Markup Leitfaden machen und ihn als Migrationsziel nutzen.

hreflang. Bei einer mehrsprachigen Seite muss jede hreflang Annotation gleichzeitig mit den URL Änderungen aktualisiert werden. Eine Redirect Map, die hreflang vergisst, lässt Google auf URLs zeigen, die woanders weiterleiten, was das internationale Setup zerschlägt.

Phase 5: QA in der Staging Umgebung

Die meisten Launches scheitern, weil die Testumgebung nicht nah genug an der Produktion ist. Ein realistisches Staging zu bauen ist die halbe Arbeit.

Staging crawlbar, aber nicht indexierbar machen. Staging soll für die öffentliche Suche mit noindex Headern und HTTP Basic Auth gesperrt sein, aber ein echter Crawler mit Zugangsdaten soll sie abrufen können. Staging so crawlen, wie Googlebot später die Produktion crawlt.

Ein vollständiges Audit gegen Staging laufen lassen. Die gleichen Werkzeuge nutzen wie in Phase 1. Metriken vergleichen. Seiten, die früher eine Meta Description hatten, sollen weiterhin eine haben. Seiten, die früher FAQ Schema hatten, sollen es weiterhin haben. Seiten, die früher auf einen Master kanonikalisierten, sollen es weiterhin tun.

Weiterleitungen auf Staging verifizieren. Die Redirect Map auf die Staging Konfiguration anwenden und die alten URLs dagegen crawlen. Jede alte URL soll mit einer einzelnen 301 auf ihre Ziel URL auflösen. Dieser Test hat die höchste Hebelwirkung im ganzen Projekt, weil er sowohl fehlende Regeln als auch Ketten findet.

Rendering prüfen. Wenn die neue Seite stark auf JavaScript baut, jedes Schlüssel Template durch einen JavaScript fähigen Crawler rendern und prüfen, dass der extrahierte Inhalt dem sichtbaren entspricht. Eine moderne Seite, die diesen Test fehlschlägt, wird beim Launch JavaScript SEO scheitern.

Performance messen. Core Web Vitals auf Staging sagen für die meisten Templates die Core Web Vitals auf Produktion vorher. Ein neues Design, das langsamer lädt als das alte, ist eine Regression, auch wenn es schöner ist. Der Core Web Vitals Leitfaden deckt die Zielwerte ab.

Eine Staging Search Console ziehen. Search Console temporär für den Staging Hostnamen einrichten und eine Beispiel Sitemap einreichen. Das bringt Probleme an die Oberfläche, die spezifisch Google interessieren und die andere Werkzeuge übersehen.

Das Liefergegenstand von Phase 5 ist eine Punkteliste jedes Problems, das vor dem Launch gelöst sein muss, plus eine unterschriebene Aussage, dass die Redirect Map wie geplant funktioniert. Ohne diese Aussage kein Launch.

Phase 6: Launch Day

Der Launch Day ist hauptsächlich, nichts Überraschendes zu tun. Die Arbeit lief in den vorherigen Phasen; der Launch Day ist die Ausführung.

Ein Launch Fenster mit geringem Traffic wählen. Die meisten Seiten haben ein Fenster mit niedrigem Traffic (spät in der Nacht, Wochenendmorgen). Dieses Fenster nutzen, damit frühe Probleme die wenigsten Nutzer betreffen. Dienstag um 10 Uhr in der Hochsaison ist für fast jede Seite das falsche Launch Fenster.

DNS aktualisieren, dann verifizieren. Nach dem DNS Wechsel von mehreren Standorten aus prüfen, dass die neue Seite antwortet. CDN Propagation kann eine Region für Stunden auf der alten Seite halten; das früh zu erkennen ist wichtig.

Sofort die neue XML Sitemap einreichen. Die neue Sitemap erzeugen, validieren, in der Search Console einreichen. Je schneller Google die neuen URLs sieht, desto schneller läuft die Neu Indexierung. Der XML Sitemap Leitfaden deckt die Validierung ab.

Produktion mit der alten URL Liste crawlen. Innerhalb einer Stunde nach Launch die alte URL Liste durch einen Crawler gegen die Produktion laufen lassen. Jede alte URL soll auf eine 301 treffen und bei 200 landen. Jede 404 ist ein kritisches Thema und gehört in den nächsten Deploy.

Die offensichtlichen Dashboards beobachten. Search Console Coverage, Google Analytics Realtime, Fehlerquote, Antwortzeit des Servers. Die ersten 24 Stunden zeigen, ob der Launch gesund ist. Die meisten Launch Probleme werden in diesem Fenster sichtbar, wenn jemand hinsieht.

Mit dem Team kommunizieren. Stakeholder sollten wissen, dass Traffic Schwankungen in der ersten Woche normal sind, während Google neu indexiert. Ein 5 Prozent Rückgang für 7 bis 14 Tage ist erholbar; ein 30 Prozent Rückgang, der nach zwei Wochen nicht beginnt zurückzukommen, ist ein echtes Problem.

Phase 7: Die ersten 30 Tage

Nach dem Launch verschiebt sich die Arbeit von Prävention zu Erkennung. Der erste Monat ist, wenn Probleme, die durch das Testen schlüpften, sichtbar werden.

Täglich in der ersten Woche:

• Search Console Coverage Bericht, auf neue “Nicht gefunden” achten
• Search Console Enhancements Bericht, auf Schema Warnungen achten
• Server Logs, auf Googlebot 404 und 500 achten
• Interne Slack oder Stand up Updates, damit das Team dieselben Signale sieht

Wöchentlich im ersten Monat:

• Vollständigen Crawl der Seite, gegen die Baseline vor Launch vergleichen
• Search Console Performance, die Top URLs aus Phase 1 beobachten
• Backlink Berichte, dass eingehende Links weiter sauber auflösen
• Traffic Kurven mit demselben Zeitraum im Vorjahr vergleichen, nicht nur mit der Vorwoche

Häufige Probleme, die in Woche 2 auftauchen:

• Weiterleitungsregeln existieren, leiten aber auf das falsche Ziel (kosmetische Übereinstimmung ohne semantische)
• Seiten, die für Nutzer laden, aber für Googlebot leer rendern (JavaScript Regression)
• Seiten, die ihr Canonical verloren haben und jetzt mit eigenen Duplikaten konkurrieren
• Seiten, die ein versehentliches noindex aus einem Default im neuen CMS bekamen

Häufige Probleme, die in Woche 4 auftauchen:

• Long Tail URLs, an die niemand mehr dachte, jetzt 404, sammeln sich im Coverage Report
• Schema Markup, das validiert, aber keine Rich Results bringt, weil eine Pflichteigenschaft entfiel
• Interne Linkmuster, die auf 301 zeigen statt auf die finale URL, drainieren einen Anteil der Crawl Effizienz

Ein 30 Tage Review am Ende des ersten Monats schließt die Migration ab. Jedes Signal aus Phase 1 mit seinem aktuellen Stand vergleichen. Alles, was nicht in Parität ist, bekommt ein Ticket. Die meisten Migrationen sind erst dann “fertig”, wenn der 30 Tage Review nichts findet.

Was auch bei sorgfältiger Arbeit schiefgeht

Manche Probleme überleben auch eine sorgfältige Migration. Sie zu kennen, hilft, nicht in Panik zu geraten, wenn sie auftauchen.

Neu Indexierung dauert. Auch mit perfekter Redirect Map braucht Google Wochen, um die alten URLs vollständig in die neuen zu konsolidieren. Ein kleiner Sichtbarkeitsknick in dieser Zeit ist normal. Die Erholungskurve, nicht die Launch Day Zahl, ist die Metrik, die zählt.

Cache Invalidierung hinkt nach. Browser, CDN und Googles eigener Cache zeigen nach dem Launch stundenlang alte Seitenversionen. Wenn ein Nutzer “die Seite ist kaputt” meldet, hilft oft ein Hard Refresh. Serverseitig die CDN Konfiguration doppelt prüfen.

Manche Queries verschieben sich. Eine Seite, die für “billige rote Schuhe” rankte, kann nach der Migration leicht anders ranken, auch wenn der Inhalt identisch ist. Google bewertet eine umgezogene Seite gegen seinen aktuellen Index, und der Index hat sich auch bewegt. Kleine Rankingverschiebungen sind Rauschen; große Verschiebungen auf Top Seiten sind das Signal zum Untersuchen.

Alte Screenshots in der Search Console. Das “Live Test” Werkzeug zeigt eine Weile die alte Version, weil es cached. Vertrauen Sie der Historieansicht der URL Inspection, nicht dem Screenshot, für den Indexierungs Status.

Wofür diese Checkliste

Für ein Redesign einer einzelnen Seite ist das overkill. Für ein Redesign auf Bereichs Ebene Phasen 2, 4, 6, 7. Für eine vollständige Site Migration alle sieben Phasen. Die Checkliste ist das Rückgrat; jedes Projekt passt die Tiefe jeder Phase an seine Größe an.

Für tieferen Kontext zur Rendering Seite moderner Migrationen erklärt der JavaScript SEO und Rendering Leitfaden, was sich ändert, wenn die neue Seite React oder Vue ist. Für einen Audit Rahmen, der dieselben Crawl Daten nutzt, gibt die technische SEO Audit Checkliste die Struktur eines laufenden Programms nach der Migration. Und Seodisias ist gebaut, um die Lücke zwischen dem, was ein Crawler auf der alten Seite sieht, und dem, was er auf der neuen sieht, sichtbar zu machen, was während einer Migration die tägliche Frage ist.

Ein Website Redesign sollte ein Moment der Investition in die Marke sein, nicht ein Moment, in dem das SEO Fundament blutet, das die Nutzer zuerst zur Marke geführt hat. Mit der richtigen Vorbereitung startet die neue Seite besser als die alte, auf jedem Signal, das zählt.