Ein in die Jahre gekommenes Content-Management-System wird irgendwann zur Bremse: Sicherheitsrisiken steigen, Redaktionsabläufe stocken, und neue Anforderungen lassen sich nur noch mit Workarounds umsetzen. Der Wechsel auf ein modernes CMS ist dann überfällig, aber er ist auch riskant. Wie flüchtig die aufgebaute Substanz ist, zeigt eine Auswertung von über zwei Millionen Websites: 66,5% der Links auf diese Seiten sind seit Anfang 2013 tot (Ahrefs). Wer beim Systemwechsel zusätzlich die eigenen Adressen bricht, verliert Sichtbarkeit, die sich nur mühsam zurückholen lässt. Eine CMS-Migration ist deshalb kein reines IT-Projekt, sondern ein strategisches Vorhaben, das Content, SEO und Technik gleichermaßen umfasst. Dieser Leitfaden zeigt, wie Sie mit Content-Audit, URL- und Redirect-Strategie, SEO-Erhalt und phasenweisem Rollout vom Legacy-System auf ein modernes CMS wechseln, ohne mühsam aufgebaute Sichtbarkeit zu verlieren.
Warum Legacy-Systeme zum Risiko werden
Veraltete CMS-Installationen kosten Geld, lange bevor sie ausfallen. Jede nicht eingespielte Aktualisierung vergrößert den Abstand zum aktuellen Stand, und mit jedem Versionssprung wächst der Aufwand, diesen Rückstand aufzuholen. Sichtbar wird das meist erst im Schadensfall: 39,1% der Content-Management-Systeme waren zum Zeitpunkt der Infektion nicht auf dem aktuellen Stand (Sucuri). Jeder Monat, in dem die Migration aufgeschoben wird, verteuert sie also.
Der zweite Treiber ist Sicherheit. Veraltete Systeme, ungepflegte Erweiterungen und nicht eingespielte Updates sind das häufigste Einfallstor für Angriffe. Allein 7.966 neue Schwachstellen wurden 2024 im WordPress-Umfeld erfasst, davon 96% in Plugins und 4% in Themes (Patchstack). Passend dazu entfielen 95,5% der erfassten Infektionen auf WordPress, das mit Abstand am weitesten verbreitete System (Sucuri). Ein modernes CMS mit gepflegtem Update-Pfad senkt diese Angriffsfläche deutlich, weshalb wir Sicherheit von Beginn an in jede Migration einplanen.
Hinzu kommt ein oft unterschätzter Faktor: die Produktivität der Redaktion. Veraltete Backends erzwingen umständliche Pflegeprozesse, fehlende Vorschaufunktionen und manuelle Workarounds für Aufgaben, die moderne Systeme automatisieren. Entwicklerinnen und Entwickler verbringen in Legacy-Umgebungen im Schnitt 17,3 Stunden pro Woche mit dem Umgang mit Altcode und technischer Schuld (Stripe). Diese Zeit fehlt für neue Funktionen, Conversion-Optimierung oder Content. Ein Wechsel auf ein modernes Content-Management-System ist deshalb nicht nur eine Sicherheits-, sondern auch eine Effizienzentscheidung, deren Wirkung sich Monat für Monat summiert.
Rund 96% aller WordPress-Schwachstellen stecken in Plugins (Patchstack), und 39,1% der betroffenen Content-Management-Systeme waren zum Zeitpunkt der Infektion veraltet (Sucuri). Eine geplante Migration ist damit selten eine Frage des Ob, sondern des Wann und Wie.
Phase 1: Content-Audit und Bestandsaufnahme
Jede saubere Migration beginnt mit einem vollständigen Inventar. Bevor auch nur eine Seite umzieht, müssen Sie wissen, welche Inhalte, URLs und Templates existieren, welche davon Traffic und Rankings tragen und welche bedenkenlos entfallen können. Dieser Schritt zahlt sich aus: Was im Inventar fehlt, fällt erst nach dem Go-Live auf, und dann unter Zeitdruck. Wer ausreichend Projektzeit in die Analyse des Altsystems und seiner Abhängigkeiten investiert, verlagert diese Arbeit in die Phase, in der sie noch planbar ist.
Der Audit beantwortet drei Fragen pro Inhalt: Behalten, überarbeiten oder verwerfen. Veraltete oder dünne Inhalte werden konsolidiert, statt sie eins zu eins mitzunehmen, denn ein Relaunch ist die ideale Gelegenheit, die Informationsarchitektur zu verschlanken. Parallel entsteht das technische Inventar aus Datenbankstrukturen, Plugins, Schnittstellen und individuellen Anpassungen. Genau dieses Inventar fehlt in den meisten gescheiterten Projekten: Ohne vollständige Liste der Abhängigkeiten bleibt jede Schätzung zu Aufwand und Termin eine Vermutung.
Der Audit ist außerdem der richtige Moment, um die Informationsarchitektur grundsätzlich zu hinterfragen. Über die Jahre wachsen Websites organisch, Kategorien überschneiden sich, und einzelne Seiten konkurrieren in der Suche um dieselben Begriffe. Eine Bestandsaufnahme deckt solche Kannibalisierungen auf und erlaubt es, beim Umzug Strukturen zu bündeln, Themencluster zu bilden und schwache Inhalte gezielt zu stärken oder zusammenzuführen. So wird die Migration nicht zum reinen Eins-zu-eins-Transfer, sondern zur Chance, die Suchmaschinen-Sichtbarkeit auf einem moderneren Fundament zu verbessern, statt Altlasten mitzunehmen.
- Content-Inventar - alle Seiten, Beiträge, Mediendateien und Dokumente vollständig erfassen, inklusive Traffic- und Conversion-Daten je URL
- URL-Liste exportieren - sämtliche indexierten URLs aus Sitemap, Server-Logs und Search Console zusammenführen
- Ranking-Baseline sichern - aktuelle Positionen, Klicks und Impressionen dokumentieren, um den Migrationserfolg später zu belegen
- Technisches Inventar - Datenbank, Plugins, Schnittstellen und Custom-Code mit Abhängigkeiten kartieren
- Backlink-Profil prüfen - welche externen Links auf welche URLs zeigen, damit deren Link-Equity erhalten bleibt
- Performance-Baseline - Ladezeiten und Core Web Vitals vor der Migration messen, um Verbesserungen sichtbar zu machen
Phase 2: URL-Mapping und Redirect-Strategie
Das Herzstück jeder verlustfreien Migration ist das URL-Mapping: eine vollständige Tabelle, die jede alte URL einer neuen zuordnet. Fehlt diese Zuordnung, landen Nutzende und Suchmaschinen auf 404-Fehlerseiten, und jahrelang aufgebaute Link-Autorität verpufft. Externe Links auf die alten Adressen lassen sich nicht nachträglich korrigieren: Sie liegen auf fremden Servern, und niemand pflegt sie nach. Die Weiterleitung ist deshalb der einzige Hebel, der beim Systemwechsel in Ihrer Hand bleibt.
Das Werkzeug der Wahl ist der 301-Redirect, die permanente Weiterleitung. Google bestätigt, dass 301-Redirects die Link-Autorität (PageRank) auf das neue Ziel weiterreichen, sofern jede alte URL auf ihr inhaltliches 1:1-Pendant zeigt (Search Engine Journal). Entscheidend ist, jede einzelne alte URL gezielt auf ihr inhaltliches Pendant zu leiten, nicht pauschal auf die Startseite, denn eine solche Sammelweiterleitung wird von Google häufig als Soft-404 gewertet und gibt kaum Signale weiter. Redirect-Ketten sollten vermieden werden, da jede zusätzliche Station Equity verliert.
| Szenario | Auswirkung | Empfehlung |
|---|---|---|
| Keine Redirects | 404-Fehler, externe Links laufen ins Leere | Vollständige 301-Map pflegen |
| Pauschal auf Startseite | Soft-404, kaum Equity-Übertragung | 1:1-Mapping auf inhaltliches Pendant |
| Redirect-Ketten | Equity-Verlust pro Sprung | Direkt auf Endziel weiterleiten |
| Saubere 301-Map | Link-Autorität 1:1 erhalten (Search Engine Journal) | Vor Go-Live testen |
In der Praxis entsteht die Redirect-Map direkt aus dem Content-Inventar der ersten Phase. Jede alte URL erhält eine Spalte für ihre neue Zieladresse, den Statuscode und das Testergebnis. Ändert sich im Zuge des Relaunchs die URL-Struktur, etwa weil Kategorien zusammengelegt oder Sprachpfade vereinheitlicht werden, muss jede betroffene Adresse einzeln zugeordnet werden. Besonders sorgfältig sind URLs mit vielen externen Backlinks und URLs mit hohem organischen Traffic zu behandeln, da hier der größte Wert auf dem Spiel steht. Eine gepflegte Redirect-Map ist kein Wegwerfartefakt, sondern bleibt nach dem Go-Live als Referenz und für die laufende 404-Auswertung erhalten.
Die mit Abstand verbreitetste Migrationspanne ist das Fehlen oder Verschütten von 301-Weiterleitungen. Bereits ein einziges fehlerhaftes Mapping auf wichtigen URLs kann Rankings über Wochen kosten. Testen Sie deshalb mindestens die Top 100 bis 200 Legacy-URLs am Go-Live-Tag auf korrekte Auflösung und überwachen Sie 404-Logs kontinuierlich.
Phase 3: SEO-Substanz erhalten und übertragen
Redirects sind notwendig, aber nicht hinreichend. Eine Migration überträgt nur dann die volle SEO-Substanz, wenn auch alle ranking-relevanten Elemente mitwandern. Dazu zählen Title-Tags, Meta-Descriptions, Überschriftenstruktur, strukturierte Daten, interne Verlinkung und die Bild-Alt-Texte. Geht hier etwas verloren, sinken Rankings selbst bei perfekten Redirects, weil die Seite für Google plötzlich anders aussieht.
Besonders unterschätzt wird die interne Verlinkung. Alte Links zeigen nach der Migration oft auf die früheren URLs und erzeugen so vermeidbare Redirect-Ketten oder 404-Fehler. Eine Ahrefs-Auswertung zeigt, wie flüchtig Links sind: 66,5% der Links auf die untersuchten Websites sind seit Anfang 2013 tot (Ahrefs). Im Zuge der Migration sollten interne Links deshalb direkt auf die neuen Zieladressen aktualisiert werden. Wer den Wechsel zudem für eine moderne Architektur nutzt, kann über einen Headless-Ansatz Frontend und Backend entkoppeln und so künftige Wechsel erleichtern.
Auf-Seite-Elemente übertragen
Title-Tags, Meta-Descriptions, H1 bis H3, kanonische URLs, Open-Graph- und strukturierte Daten 1:1 mitnehmen oder gezielt verbessern.
Technische Signale sichern
XML-Sitemap neu erzeugen und einreichen, robots.txt prüfen, hreflang bei mehrsprachigen Seiten und Core Web Vitals im Blick behalten.
Interne Links aktualisieren
Alle internen Verweise auf die neuen URLs umschreiben, statt sie über Redirects laufen zu lassen, um Equity-Verlust zu vermeiden.
Backlinks adressieren
Bei besonders wertvollen externen Links die verweisenden Seiten möglichst zur Aktualisierung anstoßen, der Rest läuft über 301-Redirects.
Wenn der Wechsel zugleich die Plattform tauscht, etwa von einem klassischen Redaktionssystem zu Shopware Community Edition oder zu einem anderen CMS, gelten dieselben Prinzipien, nur mit höherer Komplexität. Welche Plattform sich eignet, hängt von Anforderungen und Redaktionsmodell ab; ein nüchterner Vergleich von TYPO3 und WordPress hilft bei der Auswahl. Für Shops gelten zusätzlich die Besonderheiten einer Shop-Migration mit Rankings-Erhalt, etwa der Umgang mit Produkt-, Kategorie- und Filter-URLs. Wie ein solcher Umstieg unter Zeitdruck gelingen kann, zeigt unser Leitfaden zur SAP Commerce Migration nach Shopware.
Phase 4: Phasenweiser Rollout statt Big Bang
Bei der Umsetzung stehen sich zwei Strategien gegenüber. Der Big-Bang-Ansatz schaltet alles auf einmal live, ist potenziell günstiger, lässt aber kaum Raum für Fehler: Geht etwas schief, betrifft es sofort alle Nutzenden zugleich. Der phasenweise Rollout migriert in Etappen, etwa nach Seitenbereichen oder Nutzergruppen, und bietet dafür minimale Ausfallzeiten, einfachere Rücksetzbarkeit und die Möglichkeit, das Team schrittweise mit dem neuen System vertraut zu machen.
Die Praxis spricht für den gestaffelten Weg. Der gestaffelte Weg gilt als risikoärmer, weil sich Fehler je Etappe begrenzen und einzelne Schritte einfacher zurücksetzen lassen. Eine seriöse Migration braucht ohnehin Zeit: Für kleine bis mittelgroße Sites sind vier bis sechs Monate für Planung, Umsetzung und Monitoring realistisch, bei großen Sites mit komplexen URL-Strukturen entsprechend länger (Search Engine Journal). Wichtig ist in jeder Variante eine vorab getestete Staging-Umgebung, auf der Inhalte, Redirects und Funktionen vollständig geprüft werden, bevor der erste echte Besucher das neue System sieht. Eine sorgfältige Relaunch-Planung verbindet diese Schritte zu einem belastbaren Zeitplan.
Unabhängig von der gewählten Strategie gehört ein getesteter Rollback-Plan zur Grundausstattung. In der Praxis scheitern Migrationen häufig auch daran, dass kein erprobter Rückfallweg existiert und das Vorhaben fälschlich als reines IT-Projekt behandelt wird. Ein sauber dokumentierter Plan legt fest, ab welchen Schwellenwerten zurückgesetzt wird, wer entscheidet und wie das Altsystem im Ernstfall reaktiviert wird. Genau weil sich bei einer Datenmigration nie alle Abhängigkeiten vorab überblicken lassen, ist diese Absicherung kein optionales Extra, sondern Teil eines verantwortungsvollen Vorgehens.
- Staging aufsetzen - vollständige Testumgebung mit migrierten Inhalten und aktiven Redirects, von Suchmaschinen ausgeschlossen
- Funktions- und QA-Tests - Formulare, Suche, Checkout, Schnittstellen und Darstellung auf allen Endgeräten prüfen
- Redirects verifizieren - die wichtigsten Legacy-URLs automatisiert gegen die Zieladressen testen
- Go-Live im Zeitfenster - Umstellung in einer traffic-armen Phase, Redirects und Sitemap zeitgleich aktivieren
- Rollback-Plan bereithalten - getestete Möglichkeit, bei kritischen Fehlern schnell zum Altsystem zurückzukehren
- Monitoring scharf stellen - 404-Logs, Crawl-Statistiken, Rankings und Performance ab Minute eins beobachten
Phase 5: Go-Live und Post-Launch-Monitoring
Mit dem Go-Live ist die Migration nicht beendet, sondern tritt in ihre kritischste Phase ein. In den ersten Wochen entscheidet sich, ob die SEO-Substanz erhalten bleibt. Suchmaschinen müssen die neue Struktur crawlen, die Redirects verarbeiten und die Signale neu zuordnen, was nicht sofort geschieht. Sustained, also anhaltender Traffic-Verlust, weist fast stets auf konkrete Ursachen hin: fehlende Redirects, Redirect-Ketten, Soft-404s oder ineffizientes Crawling. Genau diese Punkte gehören in den ersten Tagen täglich überprüft.
Die neue XML-Sitemap wird unmittelbar in der Search Console eingereicht, um das Crawling zu beschleunigen. Parallel werden 404-Fehler aus den Server-Logs laufend ausgewertet und in zusätzliche Redirects überführt. Ein moderner Stack zahlt sich hier doppelt aus: Bessere Ladezeiten und stabile Core Web Vitals sind nicht nur ein Ranking-Faktor, sondern verbessern auch die Suchfunktion und das Nutzerverhalten im Shop. Auch durchdachte Micro-Interactions für mehr Conversion lassen sich auf einer modernen Plattform leichter umsetzen als auf einem starren Legacy-System.
Eine realistische Erwartungshaltung gehört zu jedem Go-Live. Selbst bei sorgfältiger Umsetzung kann es nach einer Migration zu vorübergehenden Schwankungen kommen, während Suchmaschinen die neue Struktur neu bewerten. Entscheidend ist, diese normale Eingewöhnung von echten Problemen zu unterscheiden, und genau das leistet ein systematisches Monitoring. Bleiben Klicks und Indexierung über mehrere Wochen deutlich unter der Baseline, deutet das auf ungelöste technische Ursachen hin, die gezielt behoben werden. Stabilisieren sich die Werte hingegen schnell, war die Schwankung erwartbar. Dieser Unterschied lässt sich nur erkennen, wenn die Ausgangswerte aus Phase 1 sauber dokumentiert wurden.
Vergleichen Sie nach vier bis sechs Wochen die Post-Launch-Werte mit der vor der Migration gesicherten Baseline aus Phase 1: Rankings, organische Klicks, Indexierungsstatus, 404-Rate und Core Web Vitals. So lässt sich der Erfolg belegen und nachsteuern, statt im Blindflug zu hoffen. Eine professionell begleitete Migration zielt darauf, zur Minderheit der Projekte zu gehören, deren Rankings nach dem Wechsel stabil bleiben oder steigen.
Die Migration als Investition in Zukunftsfähigkeit
Eine CMS-Migration ist anspruchsvoll, aber das Risiko ist beherrschbar, wenn man methodisch vorgeht. Die Mehrheit der gescheiterten Projekte scheitert nicht an der Technik, sondern an fehlender Vorbereitung: kein Content-Audit, kein vollständiges URL-Mapping, kein getestetes Staging und kein Post-Launch-Monitoring. Genau diese vier Bausteine entscheiden darüber, ob die mühsam aufgebaute Sichtbarkeit den Wechsel übersteht.
Der Lohn ist erheblich. Statt Budget dauerhaft in den Betrieb eines Altsystems zu binden, gewinnen Sie ein wartbares, sicheres und schnelles Fundament für künftiges Wachstum. Moderne Systeme reduzieren die Angriffsfläche, beschleunigen Redaktionsprozesse und schaffen die technische Basis für Personalisierung, Mehrsprachigkeit und neue Vertriebskanäle. Als Agentur mit Schwerpunkt auf CMS-Lösungen und E-Commerce begleiten wir Sie durch alle fünf Phasen, vom Content-Audit über die Redirect-Strategie bis zum überwachten Go-Live, damit Ihre Migration zur Investition in Zukunftsfähigkeit wird und nicht zum Risiko für Ihre Sichtbarkeit.
Dieser Artikel basiert auf Daten aus: Ahrefs (Anteil toter Links), Patchstack (Schwachstellen im WordPress-Umfeld 2024, Plugin- und Theme-Anteil), Sucuri (Anteil veralteter Content-Management-Systeme zum Infektionszeitpunkt, WordPress-Anteil an den erfassten Infektionen), Stripe (Entwicklerzeit für Altcode und technische Schuld), Search Engine Journal (Link-Autorität über 301-Redirects, Migrationsdauer, Erholungszeit). Die genannten Zahlen können je nach Branche, Systemgröße und Umsetzung variieren.
Häufig gestellte Fragen zur CMS-Migration
Eine CMS-Migration ist der Umzug einer Website von einem bestehenden Content-Management-System auf ein anderes, modernes System. Dabei werden Inhalte, URLs, Templates und Funktionen übertragen. Eine gut geplante Migration umfasst Content-Audit, URL-Mapping, eine 301-Redirect-Strategie und ein Post-Launch-Monitoring, um die SEO-Substanz zu erhalten.
Das Risiko besteht, es ist aber steuerbar. Rankings gehen vor allem dann verloren, wenn alte Adressen ersatzlos wegfallen oder pauschal auf die Startseite weiterleiten. Mit einem vollständigen URL-Mapping, sauberen 301-Redirects und dem Übertragen aller On-Page-Signale lässt sich der Verlust erfahrungsgemäß weitgehend vermeiden.
Das hängt von Umfang und Komplexität ab. Für kleine bis mittelgroße Websites sind etwa vier bis sechs Monate für Planung, Umsetzung und Monitoring realistisch, bei großen Sites entsprechend länger (Search Engine Journal). Kleinere Projekte gehen schneller. Wichtig ist, ausreichend Zeit für Content-Audit und Tests einzuplanen, statt den Go-Live zu überstürzen.
301-Redirects leiten alte URLs permanent auf ihre neuen Pendants um und reichen die Link-Autorität (PageRank) auf das neue 1:1-Pendant weiter (Search Engine Journal). Ohne sie landen Nutzende und Suchmaschinen auf 404-Fehlerseiten, und jeder externe Link auf eine alte Adresse verliert seine Wirkung, weil er auf einem fremden Server liegt und dort nicht nachgepflegt wird.
Beide Ansätze haben Berechtigung. Der phasenweise Rollout gilt in der Regel als risikoärmer, weil er Ausfallzeiten minimiert und eine einfachere Rücksetzbarkeit bietet. Der Big-Bang-Ansatz kann günstiger sein, exponiert bei Fehlern aber sofort alle Nutzenden. Die Wahl hängt von Größe, Risikotoleranz und Ressourcen ab.
Erfahrungsgemäß ist der richtige Zeitpunkt erreicht, wenn Sicherheitsupdates ausbleiben, Anpassungen nur noch über Workarounds gelingen oder die Wartung einen großen Teil des Budgets bindet. Da 39,1% der Content-Management-Systeme zum Zeitpunkt der Infektion veraltet waren (Sucuri) und technische Schuld kontinuierlich wächst, lohnt sich eine frühzeitige, geplante Migration meist mehr als ein erzwungener Notfall-Wechsel.