2021 gab ein großer britischer Einzelhandelsbetrieb Seahawk einen Migrationsauftrag für eine Website mit knapp über 22.000 indexierten URLs. Das Dev-Team arbeitete bereits seit vier Monaten an der neuen Plattform. Sie hatten ein Startdatum. Sie hatten eine Staging-Website. Was sie nicht hatten und wirklich nicht bedacht hatten, war eine Weiterleitungskarte. Nicht eine grobe. Gar keine. Der Plan des SEO-Leads war, es „nach dem Launch zu handhaben". Ich denke manchmal noch an dieses Meeting.
Wir verschoben den Launch um drei Wochen. Bauten die Redirect-Strategie von Grund auf neu auf. Die Website ging saubere Online, behielt 94 % ihres organischen Traffics während des Übergangs, und der Kunde schickte uns eine Flasche Scotch. Die drei Wochen Verzögerung bewahrten sie vor dem, was fast sicherlich ein sechsmonatiger Recovery-Marathon geworden wäre.
Okay. Hier ist, wie du für eine Website in diesem Umfang eine Weiterleitungskarte richtig aufbaust – der Prozess, die Tools, die Priorisierungslogik und die Teile, über die die meisten Migrations-Guides stillschweigend hinweggehen.
---
Beginnen Sie mit einem vollständigen URL-Inventar
Du kannst nicht abbilden, was du nicht gezählt hast. Vor allem anderen brauchst du einen vollständigen Export jeder live, indexierten URL auf der Ursprungs-Website. Nicht nur die Sitemap. Sitemaps lügen, sie sind oft veraltet, sie schließen paginierte URLs aus, und sie lassen routinemäßig Produkt- oder Archivseiten aus, die über Jahre Links gesammelt haben.
Ich führe Screaming Frog SEO Spider im List-Modus gegen eine kombinierte Quelle aus: die XML-Sitemap plus ein Google Search Console-Export aller indexierten URLs. Diese beiden Quellen zusammen bringen fast immer URLs ans Licht, die die andere übersieht. Bei einer 20.000-URL-Website rechne mit einer tatsächlichen Crawl-Zahl zwischen 18.000 und 35.000 – Paginierung, Filter, Facetten-Navigation, alles dabei.Screaming Frog SEO Spider in list mode against a combined source: the XML sitemap plus a Google Search Console export of all indexed URLs. Those two sources together almost always surface URLs the other misses. For a 20,000-URL site, expect the real crawl count to come back anywhere between 18,000 and 35,000, pagination, filters, faceted nav, all of it.
Exportiere den Crawl in eine Tabellenkalkulation. Du brauchst mindestens: URL, HTTP-Status, Title-Tag, H1, Anzahl der eingehenden internen Links und ob sie in der GSC mit Impressionen angezeigt wird. Diese letzte Spalte ist wichtiger, als die meisten zugeben.
Vergiss nicht die 404er, die immer noch Traffic bekommen
Während du in GSC bist, hole dir den Coverage-Report und sammle jede URL, die Google in den letzten sechs Monaten zu crawlen versucht hat – einschließlich bestehender 404er. Manche dieser kaputten Seiten haben noch externe Backlinks, die auf sie zeigen. Ich habe einen 404er mit 40 verweisenden Domains auf einer Website gesehen, die zwei Jahre nicht gewartet worden war. Diese brauchen auch ein Ziel.
---
Kategorisiere vor dem Mapping
Eine flache Liste von 20.000 URLs ist unbrauchbar. Das Erste, das ich nach dem Crawl-Export mache, ist jede URL nach Typ zu kategorisieren, denn die Abbildungslogik ist völlig unterschiedlich, je nachdem, was eine URL ist.is.
Hier ist die grobe Taxonomie, die ich verwende:
- Produktseiten, 1:1-Abbildung auf neue Produkt-URL wo möglich, 1:1 map to new product URL where possible
- Kategorie- / Sammlungsseiten, Abbildung auf gleichwertige neue Kategorie oder nächste übergeordnete, map to equivalent new category, or nearest parent
- Blogbeiträge / Artikel, Abgleich nach Slug, Titel-Ähnlichkeit oder Topic-Cluster, match by slug, title similarity, or topic cluster
- Tag- und Archivseiten werden üblicherweise auf die Kategorie oder Homepage konsolidiert, usually consolidate to category or homepage
- Paginierte URLs (z. B. /category/shoes/page/3) führen fast immer zur übergeordneten Kategorie (e.g.
/category/shoes/page/3), almost always → parent category - Benutzergenierte oder Account-URLs werden üblicherweise gelöscht oder auf die Anmeldung weitergeleitet, usually drop or redirect to login
- Alte Campaign-Landing-Pages, bewerten Sie die Link-Equity, bevor Sie sich entscheiden, evaluate link equity before deciding
- Duplikate/kanonische Varianten werden auf die kanonische weitergeleitet, Ende der Geschichte, redirect to the canonical, full stop
Diese Kategorisierungsaufgabe in Google Sheets mit einer Dropdown-Spalte durchzuführen dauert ein Paar Stunden. Das spart Tage. Sobald alles eingegeben ist, können Sie jede Kategorie mit einem anderen Regelsatz verarbeiten, statt 20.000 einzelne Entscheidungen zu treffen.
---
Die Matching-Phase: Zuerst automatisiert, dann manuell
Hier passiert den meisten Teams der Fehler. Sie versuchen, jeden URL manuell abzugleichen. Bei 20.000 Zeilen ist das nicht gründlich, das ist ein Nervenzusammenbruch, der nur darauf wartet zu passieren.
Mein Prozess läuft so ab: automatisiertes Matching zuerst, manuelle Überprüfung danach, nur für die URLs, die wirklich zählen.
Automatisierter Abgleich mit VLOOKUP und Python
Bei Websites, bei denen die URL-Struktur zwischen alt und neu ähnlich ist (z. B. /products/red-shoes/ wird zu /shop/red-shoes/), erledigt ein einfaches VLOOKUP in Sheets auf den Slug-Teil 60–70% der Liste in unter zehn Minuten. Regex-basierte Suchen/Ersetzen handhaben strukturelle Musteränderungen./products/red-shoes/ becoming /shop/red-shoes/), a simple VLOOKUP in Sheets on the slug portion sorts out 60–70% of the list in under ten minutes. Regex-based find/replace handles structural pattern changes.
Bei komplizierteren Migrationen, Plattformwechseln oder kompletten IA-Redesigns nutze ich ein kurzes Python-Skript, das Fuzzy-String-Matching zwischen dem alten Crawl-Export und dem Crawl der neuen Website durchführt. Die thefuzz-Bibliothek (ehemals FuzzyWuzzy) eignet sich dafür gut. Alles über einem Match-Score von 85 % wird automatisch zugewiesen. Alles darunter geht in eine manuelle Überprüfungs-Warteschlange.thefuzz library (formerly FuzzyWuzzy) does this well. Anything above an 85% match score gets auto-assigned. Anything below goes into a manual review queue.
Die manuelle Warteschlange ist üblicherweise 20–30% der Liste. Nicht alles braucht Aufmerksamkeit von Senior-Level.
Priorisierung der manuellen Warteschlange
Nicht alle 20.000 URLs verdienen gleich viel Zeit. Ich bewerte jede URL nach:
- GSC-Impressionen der letzten 90 Tage – wenn es Suchverkehr generiert, hat es hohe Priorität, if it's driving search traffic, it's high priority
- Anzahl der verweisenden Domains (aus Ahrefs), Link-Equity, die Sie nicht verlieren können (pulled from Ahrefs), link equity you can't afford to drop
- Anzahl der internen Links aus dem Crawl, signalisiert strukturelle Wichtigkeit, signals structural importance
- Umsatzzuordnung – falls der Kunde GA4-E-Commerce-Daten bereitstellen kann, springen Seiten, die Conversions auslösen, nach oben, if the client can provide GA4 ecommerce data, pages driving conversions jump to the top
Alles mit Impressionen, Backlinks oder Umsatz erhält eine manuelle Mapping-Entscheidung. Alles andere kann einer regelgestützten Fallback folgen (normalerweise → übergeordnete Kategorie oder Homepage). Ehrlich gesagt, bei einer 20.000-URL-Website brauchen vielleicht 800–1.200 URLs echte individuelle Aufmerksamkeit. Der Rest ist Long-Tail-Müll.
---
Strukturierung des Redirect-Map-Dokuments
Die fertige Map lebt in einer Tabellenkalkulation. Einfach. In dieser Phase braucht es keine clevere Tooling, die Datei muss nur eindeutig und importierbar sein.
Die Spalten, die ich nutze:
- Source URL (vollständige, absolute URL der alten Seite)
- Destination URL (vollständige, absolute URL der neuen Seite)
- Redirect-Typ (301 in fast jedem Fall, 302 nur für wirklich temporär, was selten vorkommt)
- Abgleichtyp (exakt / Muster / regex)
- Kategorie (aus der Taxonomie-Stufe)
- Prioritätsebene (High / Medium / Low, basierend auf der obigen Bewertung)
- Status (Ausstehend / Bestätigt / Implementiert / Getestet)
- Notizen
Diese "Notes"-Spalte wird unterschätzt. Dort packst du Dinge rein wie "Kunde hat bestätigt, dass dieses Produkt eingestellt ist, zu Kategorie leiten" oder "Backlink von Forbes zeigt hierher, zum nächsten Äquivalent leiten, nicht zur Homepage." Zukünftiges Du wird Gegenwart-Du dankbar sein.
Behalte die Quell-URLs genau so bei, wie sie sind – mit oder ohne Trailing Slash, mit Query Strings falls zutreffend. Inkonsistenz hier führt zu Partial Matches und übersehenen Redirects, die nach dem Launch ein Albtraum sind zu diagnostizieren.
---
Musterbasierte vs. exakte Umleitungen
Bei dieser Größenordnung brauchst du absolut Pattern-basierte Redirects, nicht nur Exact-Match. 20.000 einzelne Redirect-301-Zeilen in eine .htaccess-Datei zu schreiben funktioniert zwar, aber es ist fragil, langsam beim Parsen und ein Wartungs-Desaster.Redirect 301 lines in an .htaccess file is, well, it works, but it's fragile, slow to parse, and a maintenance disaster.
Bei Apache/WordPress-Setups nutze ich regex-basierte RewriteRules für strukturelle Muster. Wenn beispielsweise jede alte URL unter /old-blog/[post-slug]/ zu /insights/[post-slug]/ abgebildet wird, ist das eine Regel, nicht 4.000.regex-based RewriteRules for structural patterns. For example, if every old URL under /old-blog/[post-slug]/ maps to /insights/[post-slug]/, that's one rule, not 4,000.
Bei Nginx gilt das gleiche Prinzip mit Rewrite-Direktiven. Bei Cloudflare kannst du Bulk Redirects nutzen (ihr kostenloses Tier handhabt bis zu 20 exakte Übereinstimmungen; Workers oder das kostenpflichtige Redirect Rules Produkt handhabt Mustlogik im großen Maßstab).rewrite directives. On Cloudflare, you can use Bulk Redirects (their free tier handles up to 20 exact-match rules; Workers or the paid Redirect Rules product handles pattern logic at scale).
Das Map-Dokument sollte kennzeichnen, welche Redirects musterfähig sind und welche exakte Übereinstimmungen benötigen. Typischerweise: Blog-Beiträge, Produkte und Kategorieseiten folgen Mustern. Alte Kampagnenseiten, veraltete Subdomains und merkwürdige historische URLs benötigen exakte Übereinstimmungen.
Teste Muster, bevor sie live gehen
Ich fahre die komplette Pattern-Rule-Set gegen die URL-Liste in einer Staging-Umgebung und logge jede Redirect-Response mit einem Tool wie Redirect Checker (bulk) oder einer curl-Loop in bash. Jeder verkettete Redirect (alt → zwischenlage → neu) ist ein Problem – Google folgt Ketten, verliert aber bei jedem Hop ein wenig Link-Equity. Flache sie vor dem Launch.Redirect Checker (bulk) or a curl loop in bash. Every chain redirect (old → interim → new) is a problem, Google will follow chains but loses some link equity at each hop. Flatten them before launch.
---
Umgang mit dem Long Tail: Die Fallback-Strategie
Das Ding ist: Bei einer 20.000-URL-Website haben wahrscheinlich mehrere tausend dieser URLs null Traffic, null Backlinks und keinen Grund, dass sie je wieder jemand besucht. Alle zur Homepage zu leiten schafft ein anderes Problem: Es sieht manipulativ für Google aus und verwirrt Nutzer, die einem bestimmten Link gefolgt sind.
Meine Fallback-Hierarchie:
- Wenn die URL eine Unterkategorie-Seite ohne Traffic und ohne Links ist → redirect zur übergeordneten Kategorie
- Falls es sich um ein Tag- oder Autor-Archiv handelt → zur Blog-Übersicht umleiten
- Falls es sich um eine wirklich verwaiste Seite ohne logisches Äquivalent handelt → auf 404 setzen oder soft-redirect zu einer gut gestalteten 404-Seite mit Navigation
Eine gute Custom-404-Seite mit kontextueller Suche und populären Category-Links rettet mehr dieser Besuche als ein pauschales Homepage-Redirect. Ich habe letztes Jahr eine für einen Seahawk-Kunden gebaut, sie hatte eine 28%-„Recovery"-Rate (Nutzer navigieren von der 404 zu einer anderen Seite) gegenüber etwa 9% davor.
---
Validierung nach dem Launch
Die Redirect-Map endet nicht beim Launch. Die ersten 72 Stunden sind kritisch.
Ich richte eine GSC-Propertyverifizierung am Tag vor dem Launch ein und überwache den Coverage-Report dann die ersten zwei Wochen täglich. Neue 404s nach dem Launch deuten normalerweise auf URLs hin, die durch die Bestandsaufnahme gerutscht sind, auf Varianten mit Rogue-Parametern, hreflang-Alternativen oder auf alte URLs in externen E-Mail-Kampagnen.
Für jede neue 404, die ich finde, füge ich eine Redirect hinzu und pushe sie. Kleine Brände. Man möchte sie fangen, bevor Googlebot diese URLs ganz aufgibt.
Schau dir auch deine Server-Logs an. Nicht nur GSC. Googlebot besucht URLs, die nirgendwo verlinkt sind, basierend auf seinen eigenen historischen Crawl-Daten. Die Log-Analyse (ich nutze GoAccess für schnelle Lesevorgänge bei kleineren Server-Setups) bringt 404s ans Licht, die GSC manchmal eine Woche oder länger braucht, um zu melden.
---
FAQ
Wie lange dauert es wirklich, eine Redirect-Map für 20.000 URLs zu erstellen?
Realistisch solltest du zwei bis drei Wochen Teilzeitarbeit einplanen, maybe 40–60 Stunden insgesamt, je nachdem wie chaotisch die URL-Struktur der alten Website ist. Die automatisierte Matching-Phase geht schnell. Die manuelle Überprüfung hochpriorisierter URLs und die Validierungsphase kosten die meiste Zeit. Lass dir von keinem Client oder PM einreden, dass das „übers Wochenende" gemacht werden kann.
Sollte ich jeden einzelnen URL umleiten, oder ist es okay, einige 404-Fehler zuzulassen?
Es ist völlig in Ordnung, genuein tote URLs ohne Traffic und ohne Backlinks natürlich 404 anzeigen zu lassen. Eine Umleitung zu einer irrelevanten Seite erzeugt ein Soft-404-Signal, das möglicherweise noch schlimmer ist. Priorisieren Sie rigoros. Leiten Sie weiter, was zählt, und investieren Sie in ein solides Custom-404-Erlebnis für den Rest.
Welchen Redirect-Typ sollte ich nutzen, 301 oder 302?
301 (permanent) für fast alles bei einer Migration. Ein 302 signalisiert Google, dass der Umzug temporär ist, und Google behält die alte URL im Index. Ich habe gesehen, wie Agenturen 302er verwenden „um auf Nummer sicher zu gehen" und dann beobachten, wie die alte Domain weiterhin rankt, während die neue monatelang stagniert. Verwenden Sie 301.
Kann ich ein Plugin verwenden, um 20.000 Redirects in WordPress zu verwalten?
Ja, aber wählen Sie sorgfältig aus. Redirection von John Godley verwaltet große Mengen gut und speichert Regeln in der Datenbank statt in .htaccess, was bei großem Umfang besser für die Performance ist. Bei mehr als etwa 10.000 exakten Redirects würde ich dennoch empfehlen, musterbasierte Regeln zu Server-Konfiguration zu migrieren, statt sich komplett auf ein Plugin zu verlassen.Redirection by John Godley handles large volumes well and stores rules in the database rather than .htaccess, which is better for performance at scale. For anything above ~10,000 exact-match redirects, I'd still recommend migrating pattern-based rules to server config rather than relying entirely on a plugin.
Welchen häufigsten Fehler machen Teams bei großen Migrationen?
Die Redirect-Map zu spät starten. Ich sehe das ständig, die Dev-Arbeit ist zu 90 % fertig, der Launch ist zwei Wochen entfernt, und dann fragt jemand „was ist eigentlich mit Redirects?" An dem Punkt gerätst du in Stress und vergisst unweigerlich Dinge. Die Redirect-Map sollte ab dem Moment gebaut werden, in dem die URL-Struktur der neuen Website bestätigt ist. Ein paralleler Workstream, nicht ein nachträglicher Gedanke.
---
Drei Wochen Verzögerung, eine Flasche Scotch, 94% Traffic-Erhalt. Die Rechnung, das richtig hinzubekommen, ist ziemlich einfach.
Die Redirect-Map ist nicht der glamouröse Teil einer Migration. Niemand stellt sie in das Hero-Banner einer Fallstudie. Aber sie ist der Unterschied zwischen einer Migration und einer Recovery, und ich weiß, welche ich lieber abrechnen würde.