Ein WXR-Export, ein Inhaltsmodell, das nicht passt, und Plugin-Logik, die sich nicht übertragen lässt. Der Migrationspfad Schritt für Schritt — einschließlich dessen, was kaputtgeht.
Wenn Sie noch entscheiden, ob Sie wechseln sollen, lesen Sie zuerst corpusctl vs. WordPress — es argumentiert ehrlich, dass die meisten WordPress-Seiten bleiben sollten.
Dieser Artikel geht davon aus, dass die Entscheidung getroffen ist. Es geht darum, sie durchzuführen, ohne mit einem Traffic-Diagramm in Form einer Klippe aufzuwachen.
Tun Sie das vor allem anderen, denn hier bekommen Migrationen ihr echtes Budget.
Gehen Sie die Plugin-Liste durch und sortieren Sie jedes in einen von drei Eimern:
| Eimer | Beispiel | Migriert? |
|---|---|---|
| Speichert Inhalte | Advanced Custom Fields, Custom Post Types | Ja — es steckt im Export |
| Transformiert Inhalte | Shortcodes, Page-Builder, Related-Posts-Blöcke | Teilweise — die Ausgabe steckt im Textkörper, die Logik nicht |
| Liefert Verhalten | Formulare, Buchungen, Mitgliedschaften, E-Commerce, Caching | Nein — neu bauen oder ersetzen |
Der dritte Eimer ist das Projekt. Ein Formular-Plugin wird zu einem Formular-Dienst. Ein Mitgliedschafts-Plugin wird zu Auth plus Gating in Ihrem Frontend. Niemand exportiert das, und es ist der Grund, warum Migrationen lange dauern.
Der zweite Eimer hat eine spezifische Falle: Page-Builder. Wenn Ihre Beiträge mit Elementor, WPBakery oder Ähnlichem gebaut sind, ist der exportierte Textkörper ein Brei aus Shortcodes und Wrapper-Markup, kein sauberes HTML. Planen Sie ein, ihn zu bereinigen oder die betroffenen Seiten von Hand neu zu schreiben. Zählen Sie sie jetzt.
Tools → Export → All content erzeugt eine WXR-Datei: XML, das Beiträge, Seiten, Custom Post Types, Taxonomien, Kommentare und Verweise auf Medien enthält.
Verweise, keine Dateien. Die Bilder liegen weiterhin in wp-content/uploads und müssen separat umziehen.
Zwei Dinge, die es wert sind, geprüft zu werden, bevor Sie der Datei vertrauen:
wp_posts.Der Instinkt ist, zu importieren und dann aufzuräumen. Machen Sie es andersherum.
Ein WordPress-Beitrag mit acht benutzerdefinierten Feldern sind in einem strukturierten CMS meist zwei oder drei richtige Typen. Entscheiden Sie diese Form vor dem Import, sonst tragen Sie WordPress' Modell in ein System, das Sie genau deshalb gewählt haben, um ihm zu entkommen.
In corpusctl gibt es keine eingebauten Inhaltstypen; Sie definieren sie vom Panel oder der API aus, und Felder tragen Rollen — title, slug, body. Die Rolle ist die Art, wie das System weiß, welches Feld die Überschrift ist, unabhängig davon, wie Sie es benannt haben — und das ist es, was berechnete Felder wie Lesezeit und Inhaltsverzeichnis ohne Konfiguration funktionieren lässt.
Ein typisches Mapping:
| WordPress | Wird zu |
|---|---|
| Beitragstitel | Feld mit Rolle title |
| Beitrags-Slug | Feld mit Rolle slug |
| Beitragsinhalt | Feld mit Rolle body, Blöcke |
| Beitragsbild | Medienverweis |
| Kategorien, Tags | Taxonomie-Relation oder ein tags-Feld |
| Autor | separater author-Typ mit einer Relation |
| ACF-Feldgruppe | eigene Felder oder ein verschachteltes Objekt |
Lokalisierung ist eine Feldeigenschaft, keine doppelte Seite. Wenn Sie WPML oder Polylang betrieben haben, ist das der Schritt, in dem diese Struktur einfacher wird.
corpusctls Importer-Modul liest WXR und hat einen Dry-Run-Modus: Es erzeugt einen Plan, ohne etwas zu schreiben.
Die Antwort enthält die Einträge, die es erstellen würde, plus skipped mit einem Grund für jeden und warnings. Lesen Sie beides. Stilles Überspringen ist die Art, wie Sie im zweiten Monat entdecken, dass 400 Beiträge nie angekommen sind.
Import-Limits existieren aus gutem Grund — der Parser lehnt XML mit DOCTYPE-/ENTITY-Deklarationen rundheraus ab, weil das der XML-Bomben-Vektor ist, und Dateien über der Größenobergrenze werden abgelehnt, statt in den Speicher gestreamt zu werden. Wenn Ihr Export eines von beidem auslöst, teilen Sie ihn.
Führen Sie ihn dann echt aus und gleichen Sie die Zahlen ab: Beiträge rein, Beiträge raus, pro Typ.
Das ist die größte Aufgabe und es ist ein normales Web-Projekt, daher ist der einzige migrationsspezifische Rat der über URLs.
Erhalten Sie die URL-Struktur, wenn Sie irgend können. Jede URL, die Sie behalten, ist eine Weiterleitung, die Sie nicht schreiben müssen, und ein Ranking-Signal, das Sie nicht übertragen müssen. Wenn die aktuelle Struktur /2019/03/some-post/ ist und Sie sie hassen, ist ihre Änderung ein separates Projekt — bündeln Sie keine URL-Umstrukturierung mit einer CMS-Migration. Wenn beide schiefgehen, wissen Sie nicht, welche es verursacht hat.
Auf der Leseseite ruft corpusctls Client keine API auf: Veröffentlichter Inhalt wird zur Veröffentlichungszeit in eine unveränderliche, hash-adressierte Datei geschrieben, und der Client löst den Slug lokal zu einem Manifest-Shard auf und ruft dann diese Adresse aus dem nginx-Edge-Cache ab. Zwei Anfragen, beide cachebar, keine berührt die Datenbank.
Block-Renderer kommen mit null Standard-Styling, sodass Ihre Designarbeit Ihre Designarbeit ist — das CMS steuert kein CSS bei, mit dem man streiten müsste.
Jede alte URL braucht einen 301 zu ihrer neuen Heimat. Die Liste, die Leute schreiben:
Die Liste, die sie vergessen:
/some-post/image-name/) — WordPress erzeugt eine pro Medienobjekt, und Google hat sie indexiert/feed/, /comments/feed/, Feeds pro Kategorie/page/2/, /page/3/ …?p=123 und ?page_id=123 Query-String-FormenExportieren Sie die URL-Liste aus der Search Console (Seiten-Bericht) statt aus der Sitemap. Die Sitemap ist das, was Sie veröffentlichen wollten; die Search Console ist das, was Google tatsächlich gefunden hat.
Gehen Sie zu einer verkehrsarmen Stunde live und beobachten Sie dann zwei Wochen lang:
Search Console — Abdeckung auf einen Anstieg der 404er oder „ausgeschlossener“ Seiten; Leistung nach Seitentyp segmentiert, um zu sehen, ob ein Template mehr verloren hat als die anderen.
Server-Logs — das Crawl-Log sagt Ihnen, was Googlebot trifft und was es erhält. Ein 404 im Log ist eine übersehene Weiterleitung, und sie am selben Tag zu beheben kostet nichts, während sie in einem Monat zu beheben Rankings kostet.
Core Web Vitals — Felddaten, nicht Laborwerte. Hier zeigt eine Headless-Migration meist eine echte Verbesserung, weil vorab gebauter Inhalt, der aus dem Cache ausgeliefert wird, keinen langsamen Origin zu verbergen hat.
Löschen Sie die WordPress-Installation mindestens einen Monat lang nicht. Lassen Sie sie laufen, unverlinkt und noindex, sodass Sie überprüfen können, wie eine Seite früher ausgesehen hat.
Redakteure werden sich über die Vorschau beschweren. WordPress zeigt die Vorschau innerhalb des CMS. Die Headless-Vorschau läuft über Ihr Frontend via Draft-Modus, und wenn Sie sie vor der Umstellung nicht verdrahtet haben, wird es das Redaktionsteam am ersten Tag bemerken. Verdrahten Sie sie zuerst. (corpusctls Draft-Modus-Helfer validiert das Geheimnis mit einem Vergleich in konstanter Zeit und lehnt jeden Slug ab, der kein bestätigter relativer Pfad ist, was das Open-Redirect-Loch schließt, das die meisten selbst gebauten Preview-Endpunkte haben.)
Shortcodes hinterlassen Rückstände. Alles, was ein Plugin gerendert hat, erscheint als Rohtext im importierten Textkörper. Durchsuchen Sie den Korpus nach [ nach dem Import.
Kommentare. WXR exportiert sie; die meisten Headless-CMS haben keinen Ort, um sie abzulegen. Wenn Kommentare wichtig sind, planen Sie einen Drittanbieterdienst vor der Umstellung ein, nicht danach.
Der erste Monat ist langsamer. Nach zehn Jahren wissen die Leute, wo in WordPress alles ist. Planen Sie das ein und legen Sie keinen Launch in dieselbe Woche.
Verwandt: corpusctl vs. WordPress · Headless-CMS-SEO: Wo der Traffic verloren geht · Was ist ein Headless-CMS?