10 Lektionen aus der Migration von WordPress zu Code (die SEO-Edition)

Wir haben eine echte, mehrsprachige WordPress-Seite zu Code migriert. Die Umstellung selbst lief reibungslos. Jede Seite war da, die Seite war schneller, das Hosting günstiger. Es sah nach einem sauberen Erfolg aus.

Dann kam der Long Tail. Über die folgenden sechs Wochen verbrachten wir rund zehn Nachfolgerunden damit, Schäden zu beheben, die erst nach dem Start auftauchten, in der Google Search Console: Seiten, die 404 zurückgaben, Ketten von Weiterleitungen, die auf Weiterleitungen zeigten, geteilte Ranking-Signale, kaputte Sprach-Tags und Traffic, der leise wegrutschte. Nichts davon war am ersten Tag sichtbar.

Dieser Artikel ist das Playbook, mit dem wir gern angefangen hätten. Er ist für Seitenbetreiber und die Menschen, die ihnen helfen, in klarer Sprache geschrieben, lässt aber die Details nicht aus. Wenn du kurz davor bist, von WordPress wegzugehen, lies das, bevor du den Schalter umlegst, nicht danach.

1. Schrägstriche am Ende können deine Rankings leise ruinieren

Was kaputtging: WordPress hatte fast unseren gesamten Traffic auf URLs indexiert, die auf einen Schrägstrich enden, etwa /blog/post/. Die neue Seite leitete jede einzelne davon auf die Version ohne Schrägstrich weiter, /blog/post. Das klingt harmlos. War es nicht. Deine gesamte indexierte URL-Basis auf einmal weiterzuleiten, sagt Google "jede Seite ist gerade umgezogen", was eine vollständige Neukonsolidierung des Index auslöst. Die Rankings fielen für Monate.

Die Lösung: Liefer beide Formen als normale Seite aus (eine 200-Antwort) und wähl eine als Canonical. Google konsolidiert sie dann sanft über den Canonical-Hinweis statt über eine harte Weiterleitung. Wochen der Erholung statt Monate.

So vermeidest du es: Entscheide deine Schrägstrich-Strategie vor der Umstellung und bilde ab, was WordPress ausgeliefert hat, was fast immer der Schrägstrich am Ende ist. Leite niemals deine gesamte URL-Basis am Starttag per 301 um.

2. WordPress ist nachsichtig bei URLs; Code ist streng

Was kaputtging: WordPress lieferte denselben Inhalt bereitwillig unter leicht falschen Adressen und Varianten aus. Die neue Seite tat das nicht. Sie gab für jede Variante, die nicht exakt passte, einen sauberen 404 zurück. Die Search Console meldete 247 dieser kaputten URLs, von denen wir nicht wussten, dass sie existieren. Eine handgeschriebene Liste von etwa 80 Weiterleitungen flickte nur einen Bruchteil davon.

Die Lösung: Erzeuge die Weiterleitungen automatisch aus deinen Inhalten, statt sie abzutippen. Wir lasen die Informationen aus, die ohnehin bei jedem Artikel gespeichert sind, und erzeugten eine Weiterleitung für jede Kombination falscher Adressen, was auf über 700 Regeln kam.

So vermeidest du es: Pflege niemals eine große Weiterleitungskarte von Hand. Wenn sie sich aus deinen Inhalten ableiten lässt, leite sie ab. Menschen übersehen Fälle; ein Generator nicht.

3. Die Reihenfolge, in der deine Regeln laufen, ist tatsächlich wichtig

Was kaputtging: Eine Weiterleitungsregel, die für die URL ohne Schrägstrich geschrieben war, griff nie für die Version mit Schrägstrich, weil die Plattform die Weiterleitungsregeln vor dem Schritt auswertete, der den Schrägstrich entfernt. Die URL mit Schrägstrich rutschte direkt in einen 404.

Die Lösung: Erstelle zu jeder einzelnen Weiterleitungsregel sowohl die Version mit als auch die ohne Schrägstrich, als Paar. Geh nicht davon aus, dass das System sie für dich normalisiert.

So vermeidest du es: Behandle "mit Schrägstrich" und "ohne Schrägstrich" als zwei URLs, die beide behandelt werden müssen, jedes Mal, für jede Regel.

4. Leite eine fehlende Übersetzung nicht weiter, zeig stattdessen einen Fallback

Was kaputtging: Wenn eine französische Seite noch nicht existierte, leitete unser erster Ansatz den Besucher auf die englische Version weiter. Das funktionierte technisch, brach aber das Erlebnis, das wir wollten. Ein Link zur französischen Seite sollte trotzdem auf Französisch öffnen, mit dem englischen Inhalt im französischen Layout, sodass der Link nie tot ist.

Die Lösung: Wenn keine Übersetzung existiert, leite nicht weiter. Liefer den englischen Inhalt eingebettet in die Hülle der angeforderten Sprache aus, sag Google, dass die englische Seite das Canonical ist, und markiere den Fallback als noindex, damit er in der Suche nicht konkurriert. Leite nur weiter, wenn tatsächlich eine echte Übersetzung unter einer anderen Adresse existiert.

So vermeidest du es: Trenne die beiden Fälle von vornherein. Übersetzung existiert bedeutet weiterleiten. Übersetzung existiert nicht bedeutet einen Fallback ausliefern, ihn auf noindex setzen und das Canonical auf das Original zeigen lassen.

5. Jede Seite braucht ihr eigenes Canonical-Tag

Was kaputtging: Eine gemeinsame, seitenweite Vorlage hatte das Canonical-Tag fest auf die Startseite gesetzt. Also sagte jede Seite der Website Google "die echte Version von mir ist die Startseite". Das ist ein Rezept für massenhafte Deindexierung, bei der Google deine Unterseiten fallen lässt, weil sie alle behaupten, etwas anderes zu sein.

Die Lösung: Erzeuge für jede Seite ein korrektes, seitenspezifisches Canonical und entferne das fest verdrahtete aus dem gemeinsamen Layout.

So vermeidest du es: Prüfe das Canonical-Tag in jeder Vorlage vor dem Start. Ein einziges falsches Canonical in einem gemeinsamen Layout vergiftet die gesamte Seite auf einmal.

6. Sprach-Tags müssen in beide Richtungen zeigen und vollständig sein

Was kaputtging: Auf einer mehrsprachigen Seite waren die Tags, die Google sagen, welche Seiten Übersetzungen voneinander sind (genannt hreflang), unvollständig und einseitig. Die englische Seite zeigte auf die deutsche, aber nicht umgekehrt, und der Sprachumschalter schickte Besucher auf Seiten, die 404 zurückgaben.

Die Lösung: Gib jedem Artikel einen stabilen Übersetzungsschlüssel in seinem Inhalt und steuere dann alles aus diesem einen Schlüssel: die Weiterleitungen, die Sprach-Tags, die Sitemap, den Sprachumschalter, sogar die Social-Preview-Bilder. Eine einzige Quelle der Wahrheit hält sie alle synchron.

So vermeidest du es: Leg diesen Schlüssel pro Artikel von Anfang an fest. Er ist das Rückgrat, an dem die gesamte mehrsprachige Einrichtung hängt.

7. Deine Sitemap muss die neue Seite beschreiben, nicht die alte

Was kaputtging: Die erste Sitemap, die wir auslieferten, trug noch die alte URL-Struktur, verpasste einige Sprachseiten und hatte keine Sprach-Tags. Eine Sitemap ist die Karte, die du Google reichst. Unsere beschrieb eine Seite, die nicht mehr existierte.

Die Lösung: Erzeuge die Sitemap aus derselben Inhaltsquelle wie die Seiten selbst, damit sie niemals auseinanderdriften kann. Nimm einen Eintrag pro Sprache pro Seite auf, echte Zuletzt-geändert-Daten und die Sprach-Tags. Reich sie dann in der Search Console in dem Moment ein, in dem du live gehst.

So vermeidest du es: Pflege die Sitemap niemals von Hand und lass keinen alten Export eines Plugins liegen. Erzeugen, dann bei der Umstellung einreichen.

8. Räum die WordPress-spezifischen Müll-URLs gezielt ab

Was kaputtging: WordPress erzeugt leise ganze Familien von URLs, an die du nie denkst, und Google hat sie alle indexiert. Nach dem Start brachte die Search Console sie wochenlang immer wieder zum Vorschein. Die vollständige Abräumliste, die wir letztlich brauchten, umfasste:

• Taxonomie-Seiten: /category/-, /tag/- und /author/-Archive.
• Feeds: der Haupt-RSS-Feed und, leicht zu vergessen, ein separater Feed für jeden einzelnen Beitrag.
• WordPress-Systemdateien: alles unter /wp-content/ und /wp-includes/.
• Alte lokalisierte Slugs: die übersetzten Seitennamen, die WordPress verwendet hat und die sich von deinen neuen, sauberen Pfaden unterscheiden.
• Preis- und Datumsvarianten: Dinge wie monatliche und jährliche Preisseiten und Slugs mit einer Jahreszahl am Ende.

Die Lösung: Leite jede Familie auf ein sinnvolles Ziel weiter, zum Beispiel alle Taxonomie-Seiten auf deinen Blog-Index.

So vermeidest du es: Exportiere das vollständige WordPress-URL-Inventar, bevor du es abschaltest, aus deiner Sitemap, deinem SEO-Plugin und deinen Server-Logs. Bau die Abräumliste aus diesen echten Daten, nicht aus dem Gedächtnis.

9. Das Migrations-Werkzeug hat seine eigenen versteckten Fallen

Was kaputtging: Einige der schlimmsten Bugs kamen nicht aus unseren Inhalten, sondern aus einer Standardeinstellung im Framework. Eine Voreinstellung sorgte dafür, dass die Seite Besucher leise auf die Sprache zurückschickte, die sie zuletzt angesehen hatten, gespeichert in einem Cookie, sodass Seiten "an" der falschen Sprache klebten, egal welchen Link man anklickte. Ein anderer Verdrahtungsfehler bedeutete, dass der Sprachumschalter selbst außerhalb des Teils der Seite lebte, der von den Übersetzungen wusste, also gab er 404 zurück.

Die Lösung: Halte die Konfiguration einfach und mach die URL zur einzigen Quelle der Wahrheit dafür, welche Sprache ein Besucher sieht, niemals ein Cookie. Teste dann den Umschalter und die Menüs, nicht nur die Artikelseiten.

So vermeidest du es: Geh davon aus, dass die Voreinstellungen auf einen generischen Fall abgestimmt sind, nicht auf deine Migration. Lies, was jede einzelne tut, bevor du ihr vertraust.

10. Es gibt harte Grenzen, also verifiziere mit echten Prüfungen

Was kaputtging: Weiterleitungen automatisch zu erzeugen ist mächtig, kann aber die Anzahl der Regeln explodieren lassen. Unsere erreichte 770 Regeln bei einem Hosting-Limit von 1024, nah genug, um eine echte Beschränkung zu sein. Davon getrennt ging dem Build mittendrin der Speicher aus, weil die Inhaltsmenge groß war.

Die Lösung: Achte auf die Grenzen, die dein Host vorgibt, und gib dem Build genug Ressourcen für eine große Seite. Am wichtigsten: Verifiziere das Ergebnis mit echten Prüfungen. Bestätige für eine Liste tatsächlicher URLs, dass jede den Status zurückgibt, den du erwartest: eine saubere Seite ohne Weiterleitungskette, oder eine Weiterleitung, die in einem einzigen Sprung am richtigen Ziel landet.

So vermeidest du es: Vertrau nicht auf "im Browser sieht es gut aus". Prüfe die Statuscodes und halte die Abdeckungs- und Weiterleitungsberichte der Search Console vier bis sechs Wochen nach dem Start offen, um den Long Tail zu erwischen.

Das Muster hinter allen zehn

Blick über die Liste zurück, und eine Form wiederholt sich. Die Fehler drehen sich fast nie um den Inhalt selbst. Sie drehen sich um die tausend kleinen URL- und Metadaten-Details, die WordPress unsichtbar erledigte und die eine neue Seite gezielt reproduzieren muss: Schrägstriche am Ende, Weiterleitungen, Canonical-Tags, Sprach-Tags, die Sitemap und die Müll-URLs, an die Google sich noch erinnert.

Die gute Nachricht ist, dass sich fast alles davon aus deinen Inhalten erzeugen lässt, statt von Hand gepflegt zu werden, und vor dem Start automatisch geprüft werden kann. Wenn das passiert, bleibt die Migration, die am ersten Tag sauber aussah, in Woche sechs tatsächlich sauber. Das ist der Unterschied zwischen diesen Lektionen selbst zu lernen und sie bereits eingebaut zu haben.

Häufige Fragen

Das Fazit

Die Migration von WordPress zu Code gibt dir eine schnellere, sicherere, günstigere Seite. Aber der Gewinn ist nur echt, wenn deine Rankings den Umzug überleben, und das hängt an Details, die Google langsam prüft, über Wochen. Plan die Schrägstriche, Weiterleitungen, Canonical-Tags, Sprach-Tags und die Sitemap vor dem Start, verifiziere sie mit echten Prüfungen und behalte die Search Console danach im Auge. Oder nutz eine Plattform, die all das für dich erledigt, was genau das ist, wofür ShiftPress gebaut ist.