CMS-Migration und Replatforming-SEO

TL;DR — Eine CMS-Migration verschiebt Ihre Website in ein anderes System, wie den Wechsel einer Publishing-Plattform, Commerce-Plattform oder Frontend-Architektur. Bewahren Sie, worauf Suchmaschinen und Nutzer bereits vertrauen: URLs, Inhalte, Titel, Kanonische, Robots-Regeln, strukturierte Daten, interne Links, Bilder und gerenderte Seiten. Wenn sich URLs ändern müssen, mappen und leiten Sie jede alte URL auf ihren nächsten Ersatz weiter. Testen Sie die neue Plattform im Staging, vergleichen Sie sie mit der aktuellen Website, proben Sie den Launch und behalten Sie einen Rollback, der sowohl die Anwendung als auch ihre Daten wiederherstellt.

Was ist eine CMS-Migration?

Eine CMS-Migration ersetzt das Content-Management-System oder die Plattform, die eine Website erstellt und ausliefert. WordPress zu einem Headless-System, Drupal zu einem anderen Enterprise-CMS oder eine E-Commerce-Plattform zu einer anderen sind häufige Beispiele.

Das sichtbare Design kann ähnlich bleiben, während sich die technische Ausgabe vollständig ändert. Die neue Plattform kann andere URLs, HTML, Metadaten, Navigation, Filter, Paginierung, Bilder, strukturierte Daten, Weiterleitungen und Robots-Anweisungen erzeugen.

Sind alle CMS-Migrationen URL-Migrationen?

Nein. Eine CMS-Migration kann jede öffentliche URL identisch halten. Das ist normalerweise die sicherere Option, wenn die bestehende URL-Struktur funktioniert.

Sobald sich ein Schema, Hostname, Pfad, die Trailing-Slash-Konvention, ein Dateiname oder ein bedeutungsvoller Parameter ändert, wird das Projekt auch zu einer URL-Migration. Fügen Sie die Mapping-, Weiterleitungs-, Internlink-, Kanonisch- und Sitemap-Arbeit aus dem Leitfaden für Website- Migrationen hinzu.

Was bedeutet „SEO-Parität“?

SEO-Parität bedeutet, dass die neue Plattform das nützliche, suchsichtbare Verhalten der alten bewahrt. Es geht nicht um pixelgenaue Design-Parität.

Vergleichen Sie für jeden wichtigen Seitentyp:

• indexierbare URL und Statuscode;
• Titel, Beschreibung, Überschriften und Hauptinhalt;
• Kanonische, Robots-Anweisungen und hreflang;
• strukturierte Daten;
• crawlbare interne Links und Navigation;
• Bilder, Videos, PDFs und andere Medien;
• mobile und gerenderte Ausgabe;
• Leistung und Serverzuverlässigkeit.

Parität umfasst auch beabsichtigte Verbesserungen. Dokumentieren Sie diese separat, damit eine nützliche Änderung nicht mit einem Migrationsfehler verwechselt wird.

Warum verlieren CMS-Migrationen Traffic?

CMS-Migrationen verlieren normalerweise Traffic, weil die neue Plattform ein wichtiges Verhalten nicht reproduziert. Häufige Beispiele sind alte URLs, die 404 zurückgeben, Kanonische, die auf Staging verweisen, verschwindende Kategorie-Links, Hauptinhalte, die erst nach einem Klick laden, Produktvarianten, die zu indexierbaren Duplikaten werden, oder alte Weiterleitungen, die nie übertragen werden.

Der Plattformname ist selten die Ursache. Die erzeugte Website ist es.

Was ist der grundlegende Prozess?

1. Inventarisieren Sie die URLs, Vorlagen, Inhalte, Signale, Links, Assets, Weiterleitungen und Integrationen der aktuellen Website.
2. Entscheiden Sie, ob die URLs gleich bleiben.
3. Schreiben Sie messbare Paritätsanforderungen für jede Vorlage und jedes Systemverhalten.
4. Mappen Sie Inhaltsfelder und migrieren Sie Daten in das neue CMS.
5. Crawlen und rendern Sie Staging und vergleichen Sie es mit der gespeicherten Baseline.
6. Testen Sie Weiterleitungen, falls sich URLs ändern.
7. Proben Sie Content-Freeze, finalen Datensync, Deployment, Cache-Purge und Rollback.
8. Starten Sie, validieren Sie die Produktion sofort und überwachen Sie nach Vorlage und URL-Kohorte.

Die Checkliste für Website-Migrationen liefert die gemeinsame phasenbasierte Projektsequenz. Dieser Leitfaden konzentriert sich darauf, was ein neues CMS innerhalb jeder Phase ändern kann.

Sollten Sie während der Migration jedes alte SEO-Problem beheben?

Beheben Sie Fehler mit hoher Sicherheit, wenn die neue Plattform sie sonst reproduzieren würde, aber kombinieren Sie nicht jedes Redesign, jede Inhaltsüberarbeitung, jede Architekturänderung und jede URL-Bereinigung in einem Release. Google empfiehlt, nach Möglichkeit jeweils eine große Sache zu ändern, in seiner Anleitung zum Website-Umzug.

Trennen Sie unbedingt zu behebende Fehler von optionalen Verbesserungen. Sie benötigen eine stabile Baseline, um zu diagnostizieren, was nach dem Launch passiert ist.

TL;DR — Ein Replatforming ist eine Vertragsmigration zwischen zwei Seiten-Generierungssystemen. Inventarisieren Sie jede aktuelle URL-Quelle, Vorlage, Inhaltsfeld, interne Verlinkungsregel, Indexsteuerung, kanonische URL, hreflang-Anmerkung, Schema-Objekt, Medien-URL, Facette, Weiterleitung und Integration. Entscheiden Sie vor der Verhärtung der Plattformkonfiguration, ob der Umfang gleiche URLs oder geänderte URLs umfasst. Übersetzen Sie das Inventar in Paritätstests, nicht in eine generische Checkliste. Migrieren Sie Daten, crawlen Sie rohes HTML und gerendertes DOM auf der Staging-Umgebung, vergleichen Sie nach Vorlage und geschützter URL-Kohorte, proben Sie den Cutover und das Daten-Rollback, und überwachen Sie dann Kohorten getrennt, damit eine defekte Vorlage nicht in den gesamtweiten Gesamtzahlen verborgen bleibt.

Klassifizieren Sie das Replatforming, bevor Sie den Plan auswählen

Eine CMS-Migration kann mehrere Änderungen enthalten:

Schreiben Sie jede Ebene in den Umfang. Eine „CMS-Migration“, die auch URL-Struktur, Hosting, Rendering und Navigation ändert, sind vier Migrationen, die einen Launch teilen.

Entscheiden Sie frühzeitig: gleiche URLs versus geänderte URLs

Die URL-Erhaltung ist in der Regel die Standardoption, wenn bestehende URLs nützlich sind und die neue Plattform sie unterstützen kann. Akzeptieren Sie „die Plattform kann das nicht“ nicht, ohne die Kosten für Weiterleitungen, erneutes Crawlen, aktualisierte Integrationen, verlorene Deep Links und operative Komplexität zu messen.

Eine URL-Änderung kann dennoch gerechtfertigt sein, wenn die aktuelle Struktur instabil ist, veraltete Technologie offenlegt, Duplikate erzeugt oder die neue Informationsarchitektur nicht darstellen kann. Die Entscheidung sollte getroffen werden, bevor Themes, Routen, Importe und Feeds um ein neues Muster herum aufgebaut werden.

Geänderte URLs benötigen den vollständigen Workstream zur URL-Struktur-Migration: Master-Inventar, explizite Disposition, Eins-zu-eins- oder begründete Viele-zu-eins-Zuordnung, permanente Weiterleitungen, direkte interne Links, aktualisierte Anmerkungen, neue Sitemaps und Überwachung.

Erstellen Sie das Inventar des Ist-Zustands aus mehreren Systemen

Die aktuelle CMS-Datenbank ist nicht das Website-Inventar. Kombinieren Sie:

• crawlbare URLs aus einem oder mehreren Crawls;
• XML-Sitemaps und Feed-Exporte;
• Analytics-Landingpages und Search Console-Seiten;
• Server-Logs, einschließlich verwaister oder veralteter URLs, die Crawler weiterhin anfordern;
• Backlink- und Kampagnen-Landingpages;
• Medienbibliotheken, PDFs, Bilder, Videos und herunterladbare Assets;
• interne Suche, facettierte Navigation, Paginierung und Sortiermuster;
• Weiterleitungsregeln aus CMS, Server, CDN und Anwendungscode;
• API-, App-, E-Mail-, Paid-, Affiliate-, Lokalisierungs- und Feed-Konsumenten.

Weisen Sie jeder URL eine Inhaltseinheit, Vorlage, Indexierbarkeitsstatus, kanonisches Ziel, Verkehrs-/Link-Bedeutung und beabsichtigtes Ziel zu. Das Inventar ist das Abstimmungsprotokoll nach dem Import.

Inventarisieren Sie das Inhaltsmodell, nicht nur den Seiteninhalt

Die Inhaltsmodell-Zuordnung beschreibt, wie Felder und Beziehungen migriert werden. Enthalten sind:

• Titel, Zusammenfassungen, Inhaltsblöcke, Autoren, Daten und Aktualisierungsdaten;
• Taxonomien, Eltern, Sammlungen, Kategorien und Tags;
• Slugs, Gebietsschemavarianten, kanonische Überschreibungen und Robots-Steuerungen;
• Bildquelle, Alt-Text, Bildunterschriften, Abmessungen, Bildausschnitte und Fokuspunkte;
• verwandte Inhalte, Breadcrumbs, primäre Navigation und kontextuelle Links;
• Produktkennungen, Preise, Verfügbarkeit, Bewertungen, Varianten und Angebote;
• Eigenschaften strukturierter Daten und Entitätsbeziehungen;
• Weiterleitungen, Aliase, unveröffentlichte Zustände, Zeitplanung und Berechtigungen.

Das Vorhandensein von Feldern reicht nicht aus. Testen Sie Transformationsregeln, Null-Verhalten, Kodierung, Markdown- oder Rich-Text-Konvertierung, eingebettete Komponenten und Referenzen. Ein migriertes Feld, das leer gerendert wird, ist immer noch verlorener Inhalt.

Parität in Akzeptanzkriterien umwandeln

Paritätsanforderungen sollten pro Vorlage geschrieben werden. Eine Produktseite und ein Artikel teilen nicht denselben Inhalt, dasselbe Schema, dieselbe Paginierung oder denselben internen Linkvertrag.

Definieren Sie für jede Vorlage:

• erwarteter Status und Indexierbarkeit;
• kanonische Generierungsregel;
• Robots-Meta- und X-Robots-Tag-Verhalten;
• Titel, Beschreibung, H1 und Quellfelder für Hauptinhalte;
• erforderliche Typen strukturierter Daten und Ausrichtung sichtbarer Eigenschaften;
• Breadcrumb-, Navigations-, verwandte Link- und Paginierungsregeln;
• hreflang- und Gebietsschemverhalten;
• Asset-Verhalten und Bildmetadaten;
• Roh-HTML-Anforderungen und Anforderungen an das gerenderte DOM;
• Leistungs- und Verfügbarkeitsgrenzen;
• Analyse- und Einwilligungsverhalten.

Trennen Sie Entscheidungen zum Erhalten, Entfernen und Verbessern. Das verhindert, dass das QA-Team einen bekannten Fehler wiederherstellt oder einen versehentlichen Verlust als Verbesserung akzeptiert.

Roh-HTML und gerenderte Ausgabe testen

Die Rendering-Strategie ist eine Replatforming-Entscheidung, kein Implementierungsdetail für Entwickler. Die JavaScript-SEO-Dokumentation von Google erklärt, dass es JavaScript-Seiten crawlt, rendert und dann indexiert. Sie sagt auch, dass serverseitiges Rendering oder Pre-Rendering weiterhin eine gute Idee ist, weil es Benutzern und Crawlern hilft, und nicht alle Bots JavaScript ausführen.

Vergleichen Sie für jede geschützte Vorlage das Roh-HTML mit dem gerenderten DOM:

• Ist der Hauptinhalt ohne Benutzerinteraktion vorhanden?
• Sind Links echte <a href>-Elemente mit auflösbaren Zielen?
• Stimmen Statuscodes mit Fehlerzuständen überein, oder gibt jede Route eine Soft-404-Hülle zurück?
• Sind kanonische und Robots-Anweisungen vorhanden und konsistent?
• Können erforderliches JavaScript, CSS, APIs und Assets gecrawlt werden?
• Entfernen Hydration- oder API-Fehler Inhalte?
• Enthält das mobile Rendering äquivalente Hauptinhalte und Metadaten?

Google warnt, dass es beim Auftreten von noindex das Rendering überspringen kann. Das Entfernen eines anfänglichen noindex per JavaScript kann daher fehlschlagen. Setzen Sie die beabsichtigte Indexierbarkeit in die ursprüngliche Antwort.

Kanonische und Indexsteuerungslogik erhalten

Kanonische Regeln degenerieren oft von bewusster Vorlagenlogik zu „selbstkanonisch für alles“. Das kann Duplikate freilegen, die durch Filter, Tracking-Parameter, Paginierung, Druckansichten oder Varianten entstehen.

Dokumentieren Sie jede Regel als Eingaben und erwartete Ausgaben. Testen Sie:

• absoluter kanonischer Host, Schema, Pfad, Schrägstrich und Kodierung;
• Selbstkanonische auf beabsichtigten indexierbaren Seiten;
• kanonische Ziele für doppelte Varianten;
• Robots-Meta- und X-Robots-Tag-Interaktionen;
• kanonisches Verhalten bei Nicht-200-Antworten;
• Sitemap-Aufnahme nur der beabsichtigten kanonischen URLs;
• Konsistenz über Desktop, Mobil und gerenderte Ausgabe.

Verwenden Sie den Canonicalization Checker auf repräsentativen Seiten und validieren Sie dann Vorlagen in großen Mengen mit einem Crawler.

Strukturierte Daten aus dem neuen Quellmodell neu aufbauen

Strukturierte Daten werden selten automatisch übertragen, weil sich die neuen Vorlagen und Felder ändern. Ordnen Sie jede Eigenschaft ihrer neuen Quelle zu und bestätigen Sie dann, dass das Markup sichtbare Seiteninhalte beschreibt.

Google empfiehlt, strukturierte Daten während der Entwicklung mit dem Rich Results Test zu testen und nach der Bereitstellung die Rich-Suchergebnis-Berichte zu überwachen, da Vorlagen- oder Bereitstellungsprobleme sie beschädigen können. Siehe Googles Einführung in strukturierte Daten.

Validieren Sie sowohl Syntax als auch Eignung. Ein bestandener Validator garantiert kein Rich-Suchergebnis, und ein syntaktisch gültiges Objekt kann dennoch das falsche Produkt, den falschen Artikel, die falsche Breadcrumb, den falschen Autor, den falschen Preis oder die falsche Verfügbarkeit beschreiben.

Bewahren Sie die Funktion interner Links, nicht nur die Anzahl der Links

Parität interner Links bedeutet, dass wichtige Seiten über gleichwertige oder bessere Crawl-Pfade auffindbar bleiben. Vergleichen Sie:

• primäre und Hilfsnavigation;
• Breadcrumbs und Kategorie-Hierarchie;
• verwandte Produkte, verwandte Artikel und kontextuelle Links;
• Paginierung und Load-More-Fallbacks;
• Fußzeile, Sprach- und Marktauswahl;
• Links im migrierten Inhalt;
• Waisenanzahl, Klicktiefe und Inlink-Verteilung.

Ein neues Design kann die gleiche Gesamtzahl an Links beibehalten, während die Links entfernt werden, die tiefe Seiten tatsächlich unterstützt haben. Analysieren Sie Änderungen nach Ziel und Vorlage.

Behandeln Sie Facetten, Parameter und interne Suche als Produktanforderungen

Plattformen führen häufig neues Filter- und Sortierverhalten ein. Dokumentieren Sie, welche Kombinationen crawlbar, indexierbar, kanonisiert, verlinkt oder blockiert sein sollen. Testen Sie Parameterreihenfolge, leere Ergebnisse, Mehrfachauswahl, Paginierung und mobiles Verhalten.

Kopieren Sie keine pauschale Robots-Regel von der alten Plattform, wenn die neue unterschiedliche Pfade generiert. Robots-Ausschluss kann das Crawling reduzieren, kann aber keine Signale konsolidieren oder bereits indexierte URLs allein entfernen.

Nutzen Sie den Faceted Navigation Auditor, um Parametermuster zu untersuchen, und validieren Sie dann die gewählten Crawl- und Index-Steuerungen der Website.

Migrieren Sie Medien als erstklassige URLs

Medienmigration umfasst mehr als das Kopieren von Dateien. Bewahren Sie oder mappen Sie explizit:

• Bild-, Video-, PDF- und Download-URLs;
• Alt-Text, Bildunterschriften, Titel und umgebenden Kontext;
• Bildabmessungen, Formate, responsive Varianten und stabile Quell-URLs;
• Videoplayer, Thumbnails, Transkripte und strukturierte Daten;
• PDF-Status, kanonische Header, Links und Zugriffskontrollen;
• CDN-Pfade, signierte URLs, Hotlink-Regeln und Cache-Verhalten.

Googles aktuelle Mobile-First-Empfehlungen raten, wichtige mobile und Desktop-Inhalte, Metadaten, strukturierte Daten und crawlbare Ressourcen gleichwertig zu halten. Sie warnen auch, dass die Änderung von Bild-URLs zu vorübergehenden Verlusten in der Bildersuche führen kann, während neue URLs verarbeitet werden. Siehe Best Practices für Mobile-First-Indexierung.

Übertragen Sie Redirects und Fehlerverhalten

Legacy-Redirects können im CMS, in .htaccess, nginx, Anwendungs-Middleware, Load-Balancern und CDN-Regeln leben. Exportieren und vereinheitlichen Sie die Regeln vor dem Start. Eine neue Plattform beginnt oft mit einer leeren Redirect-Tabelle und verwirft stillschweigend Jahre gesammelter URL-Historie.

Testen Sie auch echte fehlende Inhalte. Die Plattform sollte einen echten 404 oder 410 zurückgeben, nicht eine 200-Vorlage mit „nicht gefunden“-Text. Bewahren Sie individuelle Fehlerseiten, ohne das HTTP-Ergebnis zu verschleiern.

Wenn sich URLs ändern, testen Sie jede gemappte alte URL. Nutzen Sie den Redirect Map Builder für das Überprüfungsprotokoll und den Bulk HTTP Status Code Checker für die Bereitstellungsprüfung.

Halten Sie Staging privat und testbar

Staging-Zugriff muss Schutz und autorisiertes Crawling in Einklang bringen. Bevorzugen Sie Authentifizierung, VPN oder Netzwerksteuerungen und geben Sie QA-Systemen expliziten Zugriff. Wenn temporäre Robots- oder noindex-Steuerungen existieren, dokumentieren Sie die Kontrollen in einem Start-Entfernungsprotokoll und weisen Sie nach, dass diese in der Produktion nicht vorhanden sind.

Erstellen Sie einen Staging-Crawl aus dem vollständigen Zielinventar, nicht nur aus der Navigation. Vergleichen Sie ihn mit der Baseline nach Vorlage und Wichtigkeitskohorte. Der Staging vs. Production SEO Diff hilft bei gepaarten Stichproben; ein vollständiger Crawl deckt systemische Abdeckung ab.

Migration vor dem Launch abgleichen

Der Abgleich beantwortet vier Fragen:

1. Wurde jede beabsichtigte Inhaltseinheit importiert?
2. Hat jede Einheit die erwartete öffentliche URL oder einen bewussten No-URL-Zustand erzeugt?
3. Hat jedes erwartete Ziel seinen Vorlagenvertrag erfüllt?
4. Hat jede alte URL die genehmigte Disposition erhalten?

Verwenden Sie Zählungen nach Inhaltstyp, Gebietsschema, Status, Indexierbarkeit und Vorlage. Seitenweite Summen können übereinstimmen, während eine gesamte Sprache, Kategorie, Autorenarchiv oder Medienklasse fehlt.

Cutover und Rollback proben

Die Probe sollte ein produktionsnahes Datenvolumen und die tatsächliche Reihenfolge umfassen:

• Content-Freeze oder Delta-Sync-Start;
• finaler Datenbank- und Medienimport;
• Bereitstellung von Redirect- und Edge-Regeln;
• Aktivierung von Anwendung, Cache, Warteschlange, Suchindex und Feeds;
• DNS- oder Load-Balancer-Umstellung, falls sich die Infrastruktur ändert;
• Produktions-Smoke-Tests und Crawl;
• Rollback von Code, Konfiguration, Datenbankschema und Schreibvorgängen.

Das Datenbank-Rollback ist der schwierige Teil. Das Zurücksetzen des Anwendungscodes, nachdem Benutzer Bestellungen, Konten, Kommentare oder Inhalte im neuen Schema erstellt haben, kann Daten verlieren oder beschädigen. Definieren Sie Roll-Forward-Fixes und Abgleich neben dem technischen Rollback.

Produktion in Abhängigkeitsreihenfolge validieren

Die Produktionsvalidierung sollte von systemischen Fehlern zur Seitendetailprüfung übergehen:

1. DNS, TLS, Status und Host-Verfügbarkeit.
2. Robots.txt, Authentifizierung, WAF und globale Robots-Direktiven.
3. Startseite plus eine Seite von jeder geschützten Vorlage.
4. Kanonische URLs, hreflang, Schema, Links, Assets und Rendering.
5. Vollständige Redirect- und Zielinventare.
6. Analytics, Einwilligung, Formulare, Checkout, Feeds, APIs und Suche.
7. Crawl-, Indexierungs-, Traffic- und Conversion-Kohorten.

Beheben Sie Vorlagenfehler vor einzelnen URLs. Ein fehlerhaftes kanonisches Teil kann Millionen von Seiten betreffen.

Nach dem Launch nach Kohorte überwachen

Kohortenüberwachung gruppiert URLs nach dem, was sich geändert hat. Nützliche Kohorten umfassen Seiten mit gleicher URL, weitergeleitete Seiten, Produkte, Kategorien, Artikel, Gebietsschemata, gerenderte Vorlagen, Medien, Facetten und am häufigsten verlinkte Seiten.

Verfolgen Sie erfolgreiche Antworten, Redirect-Fehler, kanonische Abweichungen, Indexierbarkeit, Render-Vollständigkeit, interne Links, Sitemap-Status, von Google ausgewählte kanonische URLs, Klicks, Impressionen, Conversions und Crawler-Aktivität. Vergleichen Sie äquivalente Zeiträume und kommentieren Sie unabhängige Kampagnen, Saisonalität, Algorithmusänderungen und Messungs- Updates.

Eine aggregierte Traffic-Linie kann Ihnen nicht sagen, ob eine neue Vorlage fehlgeschlagen ist, während eine andere gewachsen ist.

KI-Zusammenfassung

• Eine CMS-Migration ändert das System, das Seiten generiert; sie kann auch URLs, Rendering, Design, Architektur, Hosting und Integrationen ändern.
• Entscheiden Sie den Umfang „gleiche URL“ versus „geänderte URL“, bevor die Routing- und Importfunktionen der Plattform gebaut werden.
• Erstellen Sie das Inventar aus Crawls, Sitemaps, Logs, Analytics, Search Console, Backlinks, Medien, Redirects und nachgelagerten Verbrauchern.
• Mappen Sie Inhaltsfelder, Beziehungen, Taxonomie, Metadaten, Medien, Schema und Workflow- Zustände, nicht nur Fließtext.
• Definieren Sie testbare Verträge pro Vorlage für Status, Indexierbarkeit, kanonische URL, Robots, Inhalt, Links, Schema, hreflang, Assets, Rendering und Leistung.
• Vergleichen Sie rohes HTML und gerenderte Ausgabe. Primärinhalte und crawlbare Links sollten nicht von Benutzerinteraktion abhängen.
• Behandeln Sie Facetten, Paginierung, interne Suche, Legacy-Redirects und echtes 404-Verhalten als Plattformanforderungen.
• Gleichen Sie importierte Einheiten, generierte Ziele, Vorlagentests und jede alte URL-Disposition vor dem Launch ab.
• Proben Sie die endgültige Synchronisierung, Bereitstellung, Validierung und datenbewusstes Rollback.
• Überwachen Sie nach dem Launch nach Vorlage und Änderungskohorte, nicht nur seitenweiten Traffic.

Offizielle Dokumentation

Google

• Umzüge mit URL-Änderungen decken URL-Zuordnung, Weiterleitungen, Annotationen, Links, Sitemaps und Monitoring ab.
• Hosting ändern gilt, wenn sich auch die Infrastruktur ändert, die öffentlichen URLs aber nicht.
• JavaScript-SEO-Grundlagen erklären Crawling, Rendering, Indexierung, Canonical- und Robots-Verhalten.
• Best Practices für Mobile-First-Indexierung decken Inhalte, Metadaten, Schema, Medien und Ressourcenparität ab.
• Einführung in strukturierte Daten empfiehlt Validierung während der Entwicklung und nach dem Launch.
• Allgemeine Richtlinien für strukturierte Daten erklären technische und qualitative Anforderungen.

Bing

• Website-Migration mit Bing deckt CMS-Migrationen, Audits, Weiterleitungen, Logs und Monitoring ab. Die Referenz auf das Site Move Tool ist veraltet; verwenden Sie aktuelle Bing Webmaster Tools und IndexNow.
• IndexNow benachrichtigt Bing und teilnehmende Suchmaschinen über hinzugefügte, aktualisierte oder gelöschte URLs.

Zitate aus der Quelle

• “Plan your changes to your site one after the other, not everything at the same time.” (Übersetzung) „Planen Sie Ihre Änderungen an Ihrer Website nacheinander, nicht alles gleichzeitig.“ Google Search Central. Zur Anleitung springen
• Sinngemäß: Für geänderte URLs besagt Googles Umzugsdokumentation, dass sich jedes Ziel selbst als kanonisch kennzeichnen sollte. Canonical-Anleitung
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution” (Übersetzung) „Wenn Google auf das noindex-Tag stößt, kann es das Rendering und die JavaScript-Ausführung überspringen.“ Google Search Central. Zur noindex-Anleitung springen
• Sinngemäß: Google empfiehlt weiterhin serverseitiges Rendering oder Pre-Rendering als leistungsfreundliche Bereitstellungsoption für Nutzende und Crawler. Rendering-Anleitung
• “Be sure to check your structured data using the Rich Results Test during development” (Übersetzung) „Überprüfen Sie Ihre strukturierten Daten während der Entwicklung unbedingt mit dem Rich Results Test.“ Google Search Central. Zur Validierungsanleitung springen

CMS-Migrations-Checkliste

Umfang und Entscheidungen

• Alle Änderungsebenen aufgelistet: CMS, Daten, Vorlagen, Rendering, Architektur, URL, Infrastruktur, Analysen und Integrationen.
• Umfang mit gleicher URL oder geänderter URL vor der Routenimplementierung genehmigt.
• Entscheidungen zu Beibehalten, Entfernen und Verbessern getrennt.
• Verantwortliche und Bestehen/Nichtbestehen-Gates pro Vorlage zugewiesen.

Inventar und Migration

• Crawls, Sitemaps, Logs, Analysen, Search Console, Backlinks und Feeds kombiniert.
• Medien, Facetten, Paginierung, interne Suche, Redirects, APIs und Apps inventarisiert.
• Jedes Inhaltsfeld, jede Beziehung, Taxonomie, jedes Gebietsschema und jeder Workflow-Status zugeordnet.
• Entitätszahlen und URLs nach Inhaltstyp, Gebietsschema, Vorlage und Status abgeglichen.

Staging-QA

• Autorisierte Crawler können auf Staging zugreifen, während die öffentliche Auffindbarkeit verhindert wird.
• Roh-HTML und gerendertes DOM auf jeder geschützten Vorlage getestet.
• Status, Titel, Überschriften, Inhalt, Kanonische URLs, Robots, Hreflang und strukturierte Daten verglichen.
• Navigation, Breadcrumbs, verwandte Links, Paginierung und Body-Links verglichen.
• Facetten, Parameter, Suche, leere Ergebnisse, Varianten und echte Fehler getestet.
• Medien-URLs, Metadaten, Formate, Einbettungen und strukturierte Daten getestet.
• Legacy-Weiterleitungen importiert, vereinfacht und getestet.
• Analytics, Consent, Formulare, Checkout, Feeds, APIs und Suche getestet.

Launch und Monitoring

• Finaler Content-/Datensync und Einfrierungssequenz geprobt.
• Anwendungs- und Datenbank-Rollback- oder Roll-Forward-Plan geprobt.
• Temporäre Staging-Kontrollen im Entfernungsprotokoll enthalten.
• Produktion in systemischer Reihenfolge von Vorlage zu URL validiert.
• Sitemaps enthalten die beabsichtigten erfolgreichen kanonischen URLs.
• Monitoring nach Vorlage, Gebietsschema, Wichtigkeit und Änderungskohorte segmentiert.

Der Replatforming-Vertrag

Verwenden Sie vier verknüpfte Protokolle:

1. Entitätsprotokoll: jeder Content-Datensatz und jede Beziehung, die migriert werden muss.
2. URL-Protokoll: jede alte URL und ihr Ergebnis als gleich, verschoben, konsolidiert, eingestellt oder ausgeschlossen.
3. Vorlagenvertrag: jedes generierte Seitenverhalten und seine Bestanden-/Nicht bestanden-Tests.
4. Abhängigkeitsprotokoll: jeder Feed, jede Integration, jedes Asset, jede Verifizierung, jede Weiterleitung, jeder Job und jeder Geschäftsprozess, den die Plattform unterstützt.

Die Migration ist nur dann abgeglichen, wenn die Protokolle übereinstimmen. Eine Content-Entität ohne erwartete URL oder eine öffentliche URL ohne zugehörige Entität oder beabsichtigtes Systemverhalten muss überprüft werden.

Die Paritätsmatrix

Benötigt die CMS-Migration einen Workstream für URL-Umzüge?

Replatforming-Fehler, die Verluste verursachen

URLs nach dem Plattformaufbau wählen. Warum es scheitert: Routing, Importe, Vorlagen, Feeds und Weiterleitungen verhärten sich um zufällige Standardwerte. Stattdessen: die Entscheidung zwischen Beibehalten und Ändern vor der Implementierung treffen.

Eine visuelle Übereinstimmung als SEO-Parität bezeichnen. Warum es scheitert: Status, Roh-HTML, Kanonische URLs, Robots, Links, strukturierte Daten, mobiler Inhalt und Fehler können hinter demselben Design abweichen. Stattdessen: Vorlagenverträge in Roh- und gerenderten Antworten testen.

Nur die Sitemap migrieren. Warum es scheitert: Sitemaps lassen verwaiste, weitergeleitete, Legacy-, parametrisierte und Asset-URLs aus, die weiterhin Traffic oder Links erhalten. Stattdessen: Crawls, Logs, Analytics, Search Console, Backlinks und Feeds kombinieren.

Jede Verbesserung beim Launch umsetzen. Warum es scheitert: gleichzeitige Content-, Architektur-, Rendering-, URL- und Designänderungen erschweren die Fehlerdiagnose. Stattdessen: erforderliche Fehler von späteren Verbesserungen trennen und Änderungen wo praktikabel stufenweise umsetzen.

Rollback als Code-Bereitstellung behandeln. Warum es scheitert: Schreibvorgänge im neuen Schema, Bestellungen, Uploads und Content-Bearbeitungen überleben möglicherweise kein Anwendungs-Rollback. Stattdessen: auch Datenabgleich und Roll-Forward-Fixes planen.

Häufige Replatforming-Fehler

Zielbestände sind niedriger als das Quellinventar

Wahrscheinliche Ursache: fehlgeschlagene Importe, ausgeschlossene Status, Gebietsschema-Lücken, nicht unterstützte Inhaltstypen oder Entitäts-Deduplizierung. Behebung: Gleichen Sie nach Inhaltstyp, Gebietsschema, Workflow-Status und Vorlage ab, anstatt eine Gesamtsumme zu vergleichen.

Seiten geben 200 zurück, verlieren aber Inhalte bei Crawls

Wahrscheinliche Ursache: Client-Rendering, blockierte Ressourcen, API-Fehler, interaktionsabhängiges Laden oder Hydrierungsfehler. Behebung: Vergleichen Sie rohes und gerendertes HTML, Konsolen-/Netzwerkfehler und die gerenderte Ansicht der URL-Inspektion auf repräsentativen Seiten.

Google wählt unerwartete Kanonische aus

Wahrscheinliche Ursache: kopierte kanonische Regeln, alte/Staging-Ziele, doppelte Routen, Konflikte bei internen Links, Sitemap-Konflikte oder erheblich geänderte Inhalte. Behebung: Richten Sie die kanonische Vorlage, direkte Links, Weiterleitungen und Sitemap an der beabsichtigten URL aus und ermöglichen Sie dann ein erneutes Crawling.

Kategorie- oder Produktseiten werden zu Crawl-Fallen

Wahrscheinliche Ursache: neue Facettenrouten, Parameterreihenfolge, unendliche Kombinationen, Kalenderpfade oder crawlbarer interner Suchindex. Behebung: Definieren Sie erlaubte Kombinationen, verlinken Sie nur nützliche Seiten, geben Sie ehrliche Leerzustände zurück und wenden Sie kanonische oder Index-Steuerungen gemäß der Produktanforderung an.

Legacy-Links beginnen 404 zurückzugeben

Wahrscheinliche Ursache: Weiterleitungen existierten außerhalb des alten CMS oder die neue Regel-Engine hat die Reihenfolge geändert. Behebung: Erstellen Sie Regeln aus jeder alten Ebene, glätten Sie Ketten und testen Sie das vollständige historische URL-Inventar.

Strukturierte Daten bestehen, beschreiben aber die falsche Entität

Wahrscheinliche Ursache: falsches Feld-Mapping oder eine Vorlage, die übergeordnete Daten, Platzhalterwerte oder veralteten Cache rendert. Behebung: Vergleichen Sie Markup mit sichtbarem Inhalt und Quelldatensätzen. Nur die Syntaxvalidierung kann semantische Genauigkeit nicht beweisen.

Tools für die CMS-Migrations-QA

• SEO Migration Planner & Validator kombiniert Kartenüberprüfung, Weiterleitungsprüfung, Status alter URLs und Sitemap-Vergleich.
• Redirect Map Builder hilft bei der Überprüfung von exakten, unsicheren, konsolidierten, nicht zugeordneten und zurückgezogenen URL-Ergebnissen, wenn sich Pfade ändern.
• Staging vs. Production SEO Diff vergleicht Status, Weiterleitungen, Kanonische, Direktiven, ausgewählte Header, Schema und Inhalt.
• Canonicalization Checker diagnostiziert beobachtbare kanonische Signale auf einer repräsentativen Seite.
• Schema Validator prüft die Syntax strukturierter Daten und extrahierte Entitäten; verwenden Sie den Rich Results Test von Google für die Eignung für Google-Funktionen.
• Faceted Navigation Auditor untersucht Crawl- und Parameterrisiken, die durch neue Filter eingeführt werden.
• Link Analyzer prüft gerenderte interne Links auf repräsentativen Vorlagen.
• Bulk HTTP Status Code Checker validiert Ziel- und historische URL-Kohorten nach der Bereitstellung.

Beweisen Sie, dass die CMS-Migration korrekt ausgeliefert wurde

Entitäts-zu-URL-Abgleichstest

• Durchzuführender Test: Verknüpfen Sie den Quell-Entitätsexport, den Ziel-Entitätsexport, das erwartete URL-Ledger und den Ziel-Crawl anhand der stabilen Inhalts-ID.
• Erwartetes Ergebnis: Jede in Frage kommende Entität hat ihren genehmigten Status und ihre URL; jedes öffentliche Ziel hat eine besitzende Entität oder einen dokumentierten Systemzweck.
• Fehlerinterpretation: Importlücken, Duplikate, Routenkollisionen oder ausgeschlossene Status haben dazu geführt, dass Inhalte fehlen oder unbeabsichtigte Seiten erstellt wurden.
• Überwachungsfenster: Vor dem Start, nach der endgültigen Synchronisierung und nach jeder Importreparatur.
• Rollback-Auslöser: Ein geschützter Inhaltstyp oder ein geschütztes Gebietsschema kann vor der Startentscheidung nicht abgeglichen werden.

Vorlagenvertragstest

• Durchzuführender Test: Eine stratifizierte Stichprobe aus jeder geschützten Vorlage crawlen und rendern, dabei Status, Inhalt, Metadaten, Kanonische URLs, Direktiven, Schema, Links, Assets und mobile Ausgabe vergleichen.
• Erwartetes Ergebnis: Jede Erhaltungsanforderung wird erfüllt und jede Abweichung lässt sich einer genehmigten, beabsichtigten Änderung zuordnen.
• Fehlerinterpretation: Eine Komponente, ein Feld-Mapping, eine Route oder eine Rendering-Ebene verändert systemisch die suchsichtbare Ausgabe.
• Überwachungszeitraum: Auf der Staging-Umgebung, unmittelbar nach dem Launch und nach Vorlagenkorrekturen.
• Rollback-Auslöser: Eine seitenweite oder hochwertige Vorlage verliert Indexierbarkeit, Inhalt, kanonische Integrität oder kritische Funktion und kann im Zeitfenster nicht repariert werden.

Redirect- und Fehlerzustandstest

• Durchzuführender Test: Jede alte URL durch den Bulk HTTP Status Code Checker oder einen vollständigen Crawler laufen lassen und bekannte fehlende Routen testen.
• Erwartetes Ergebnis: Verschobene URLs erreichen über eine permanente Weiterleitung genehmigte Äquivalente; erhaltene URLs bleiben erfolgreich; entfernte URLs geben geplanten 404 oder 410 zurück.
• Fehlerinterpretation: Fehlende Regeln, falsche Reihenfolge, Ketten, Soft 404s oder Catch-all-Routing verschleiern die beabsichtigte Behandlung.
• Überwachungszeitraum: Staging wo möglich, Launch-Stunde und nach jeder Regeländerung.
• Rollback-Auslöser: Systemisches Regelversagen macht geschützte URLs unverfügbar oder leitet sie an irrelevante Ziele weiter.

Datenbewusste Rollback-Probe

• Durchzuführender Test: Das dokumentierte Rollback in einer produktionsnahen Probe ausführen, einschließlich Schreibvorgängen, die nach dem Cutover erstellt wurden.
• Erwartetes Ergebnis: Code, Schema, Inhalt, Bestellungen, Sitzungen, Uploads, Warteschlangen und Integrationen erreichen einen definierten konsistenten Zustand ohne stillen Verlust.
• Fehlerinterpretation: Der Plan kann Software wiederherstellen, aber keine Daten abgleichen, die von der neuen Plattform erzeugt wurden.
• Überwachungszeitraum: Vor dem Launch und nach wesentlichen Schema- oder Cutover-Änderungen.
• Rollback-Auslöser: Es existiert kein sicherer Rollback- oder Roll-Forward-Pfad für kritische Schreibvorgänge.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• A Website Migration Takes More Than a Checklist to Be Successful behandelt den gemeinsamen Projektprozess, Staging, Parität und Überwachung.
• Redirects for SEO behandelt die Redirect- Ebene, die übertragen oder neu aufgebaut werden muss, wenn ein Plattformwechsel Routen ändert.

Verwandte Anleitungen auf dieser Website

• Site Migrations behandelt Migrationstypen, gemeinsame Risiken und den universellen Prozess.
• Website Migration Checklist bietet eine projektbereite Abfolge.
• Website Redesign SEO Checklist gilt, wenn sich Vorlagen ändern, während URLs stabil bleiben.
• JavaScript SEO behandelt Rendering und Discovery ausführlicher.

Aus der Branche

• Google: Umzüge mit URL-Änderungen
• Google: JavaScript-SEO-Grundlagen
• Google: Mobile-First-Indexierung
• Google: Strukturierte Daten
• Bing: Website-Migration mit Bing
• Bing: IndexNow

Testen Sie sich: CMS-Migration und Replatforming-SEO

Fünf Fragen zu Umfang, Parität, Rendering, Abgleich und Rollback. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Änderungsprotokoll