Von WordPress auf eine andere Plattform umziehen: was mitkommt, was verloren geht.

Beim Umzug von WordPress auf eine andere Plattform lassen sich Inhalte, Bilder und Adressen übertragen; verloren geht meist die Arbeit, die Plugins still erledigt haben: Sitemap, Suchtitel, strukturierte Daten, Weiterleitungen, Formulare. Damit der Umzug die Sichtbarkeit in der Suche erhält, braucht jede alte WordPress-Adresse auf der neuen Website entweder eine Entsprechung oder eine bewusste 404/410-Entscheidung.

Die Entscheidung, WordPress zu verlassen, beginnt meist mit einer Klage: Die Website ist langsam, Plugin-Updates machen Angst, das Design spiegelt das Unternehmen nicht mehr wider. Die neue Plattform kann ein anderes Content-Management-System, ein Static Site Generator oder eine individuell programmierte Website sein. Was es auch wird, der Umzug besteht aus zwei getrennten Aufgaben: die Inhalte zu übertragen und die Arbeit neu aufzubauen, die WordPress unsichtbar erledigt hat. Wird die zweite übersprungen, wirkt die Website neu und schnell, doch ihr Platz in der Suche schmilzt still dahin. Deshalb läuft der gesamte Umzug über eine Migrations-Checkliste, und im Rahmen von Relaunch und Website-Umzug ist der Wechsel weg von WordPress ein eigener Posten.

Was lässt sich problemlos aus WordPress übertragen?

Das WordPress-eigene Exportwerkzeug (Werkzeuge › Daten exportieren) schreibt die Inhalte in eine XML-Datei namens WXR. Laut WordPress-Dokumentation enthält diese Datei Beiträge, Seiten, benutzerdefinierte Inhaltstypen, Kommentare, benutzerdefinierte Felder, Kategorien, Schlagwörter, benutzerdefinierte Taxonomien und Benutzer. Text, Titel, Datum und Kategorieangaben lassen sich so ins neue System importieren. Mediendateien wie Bilder und PDFs werden gesondert kopiert; ändern sich ihre Adressen auf der neuen Website, kommen auch sie in die Weiterleitungstabelle.

Was geht beim Umzug von WordPress verloren?

Verloren geht die Arbeit, die nicht WordPress selbst, sondern Plugins und das Theme erledigt haben. Erledigt ein Plugin eine Aufgabe, verschwindet diese Aufgabe mit dem Plugin:

• Suchtitel und Beschreibungen. Die Titel und Beschreibungen, die Sie Seite für Seite in ein SEO-Plugin eingegeben haben, gehen verloren, wenn sie nicht in ein entsprechendes Feld des neuen Systems übernommen werden, und die Seiten gehen mit Standardtiteln online.
• Sitemap. Die vom Plugin erzeugte Sitemap verschwindet; das neue System muss eine eigene Sitemap erzeugen, und sie muss erneut in der Search Console eingereicht werden.
• Strukturierte Daten. Schemas wie Breadcrumbs, Organisationsangaben und Artikelangaben hat das Plugin ausgegeben; im neuen System müssen sie neu geschrieben werden.
• Weiterleitungen. Regeln, die über Jahre in einem Weiterleitungs-Plugin angelegt wurden, verschwinden über Nacht, wenn sie nicht exportiert werden. Sie sind das Protokoll früherer Umzüge; nehmen Sie sie in die neue Weiterleitungstabelle auf.
• Formulare, Mitgliedschaften, Kommentare, E-Commerce. Jedes davon findet entweder eine Entsprechung im neuen System oder wird bewusst abgeschaltet.
• Redaktionelle Gewohnheiten. Wer die Inhalte über welche Oberfläche aktualisiert, kann sich ändern; das ist keine technische, sondern eine organisatorische Entscheidung und sollte vor dem Umzug getroffen werden.

Wie werden WordPress-Adressen auf der neuen Website abgebildet?

Die Adressstruktur von WordPress ist eigen, und sie ist der Teil des Umzugs, der die meiste Arbeit macht. Laut WordPress-Dokumentation ist bei der Installation der „einfache“ Permalink voreingestellt: eine Adresse der Form ?p=123, die die Datenbank-ID des Beitrags trägt. Viele Websites ersetzen sie durch eine Struktur mit Beitragsname, Jahr oder Monat. Auch Kategorie- und Schlagwortarchive haben eigene Adressen; ihre Standardpräfixe sind category und tag, und laut Dokumentation lassen sie sich ändern, aber nicht ganz aus der Adresse entfernen. Hinzu kommen Seitennummerierung, Autoren- und Datumsarchive, Feeds und Medienadressen.

Jedes Muster wird zu einer eigenen Regel in der Weiterleitungstabelle. Die folgenden Zeilen zeigen die Muster einer typischen WordPress-Website und mögliche Entscheidungen; Adressen und Entscheidungen sind Beispiele, die Entscheidungen für Ihre Website hängen von deren eigenen Inhalten ab.

1. /?p=123 → /yazilar/fuar-notlari/ · 301 (ID → Name, Zeile für Zeile)
2. /2019/05/fuar-notlari/ → /yazilar/fuar-notlari/ · 301 (Musterregel)
3. /category/haberler/ → /yazilar/ · 301 (falls eine entsprechende Liste existiert)
4. /tag/fuar/ → (keine Entsprechung) · 410
5. /2019/05/ → (Datumsarchiv · keine Entsprechung) · 410

Zwei Regeln sind wichtig. Erstens: Schicken Sie Kategorie- oder Schlagwortseiten nicht pauschal auf die Startseite; gibt es keine entsprechende Liste, ist 404 oder 410 die ehrlichere Antwort (Leitfaden zum 404-Fehler). Zweitens: Tragen Sie die alte Adresse jedes exportierten Beitrags als eigene Zeile in die Weiterleitungstabelle ein. Wie Weiterleitungen eingerichtet werden, steht im Leitfaden zur 301-Weiterleitung.

Kann die alte WordPress-Website online bleiben?

Sie sollte es nicht. Bleibt die alte Installation nach dem Launch der neuen Website unter einer anderen Adresse — einer Subdomain oder einer temporären Adresse — erreichbar, sind zwei Kopien desselben Inhalts unter zwei verschiedenen Adressen online, und die Suchmaschine entscheidet selbst, welche sie zeigt. Die alten Adressen sollten auf die neuen weitergeleitet werden, die alte Installation sollte nur als passwortgeschütztes Archiv an einem Ort aufbewahrt werden, auf den allein das Team Zugriff hat. Dieselbe Regel gilt für die Testumgebung der neuen Website: Vor dem Launch sollte sie nicht öffentlich sein, und am Launch-Tag dürfen keine Einstellungen zurückbleiben, die Suchmaschinen aussperren.

Was sollte man statt WordPress wählen?

Eine einzige richtige Antwort gibt es nicht. Für eine Website, deren Inhalte viele Personen häufig aktualisieren oder die Mitgliedschaften oder einen Shop trägt, ist ein anderes Content-Management-System sinnvoll. Für eine Unternehmenswebsite, deren Inhalte sich selten ändern und bei der Geschwindigkeit und eine kleine Angriffsfläche Vorrang haben, bedeutet eine statische Website oft weniger bewegliche Teile. Beide Wege vergleicht der Leitfaden Statische Website oder Content-Management-System. Fällt die Wahl auf eine statische Website, ist die nächste Frage, ob ein fertiger oder ein selbst geschriebener Generator zum Einsatz kommt; das finden Sie in unserem gemessenen Vergleich Astro oder eigener Generator. Aus unseren Projekten wurde die Website von Mikro Yazılım Destek mit Astro gebaut.

Was ändert sich, wenn Sie die Arbeit des Plugins selbst erledigen?

Diese Website nutzt kein WordPress; Seiten, strukturierte Daten, Sitemap, RSS-Feed, robots.txt und llms.txt erzeugt ein einziger, selbst geschriebener Generator. Jede Aufgabe, die in WordPress Plugins überlassen wird, steckt hier also in unserem eigenen Code. Beide Seiten davon haben wir erlebt.

Eines Tages zeigte der Breadcrumb-Bericht der Search Console einen Fehler wegen eines Elements ohne Namen: Einer Stufe im Schema fehlte der Name. Mit einem Plugin hätten wir für die Korrektur auf ein Plugin-Update gewartet; hier haben wir dem Generator eine Regel hinzugefügt, und seitdem wird ein Breadcrumb mit namenlosem Element beim Build abgefangen und stoppt die Erzeugung. Im selben Export markierte der Bericht zur Profilseite das Änderungsdatum der Seite, das nur als Tag ohne Uhrzeit ausgegeben wurde, als ungültige Datums- und Zeitangabe; die Korrektur war eine Datums- und Zeitangabe mit Zeitzone (23. September 2026).

Die Lehre wirkt in beide Richtungen. Wer die Arbeit des Plugins selbst erledigt, macht auch die Fehler selbst; die Search Console zu lesen ist eine Aufgabe, die nach dem Umzug weitergehen muss. Doch auch die Korrektur liegt in Ihrer Hand, und ein einmal gefundener Fehler lässt sich so sperren, dass er nie wieder erzeugt werden kann. Beim Abschied von WordPress lautet die Frage nicht nur „Was geht verloren, wenn die Plugins gehen?“, sondern ebenso „Wer prüft ihren Ersatz, und wie?“.

Ein Plugin zu entfernen entfernt nicht die Arbeit, die es erledigt hat; es ändert nur, wer sie erledigt.

In welcher Reihenfolge geht man beim Umzug von WordPress vor?

• Erstellen Sie die Adressliste der alten Website: WordPress-Sitemap, Search Console und ein Crawl. Exportieren Sie auch die Regeln des Weiterleitungs-Plugins.
• Listen Sie die Plugins auf und notieren Sie, was jedes davon tut: Wo wird diese Aufgabe im neuen System erledigt?
• Exportieren Sie die Inhalte; prüfen Sie Seite für Seite, dass SEO-Titel und -Beschreibungen in ein Feld des neuen Systems übernommen wurden.
• Richten Sie die neue Adressstruktur ein und notieren Sie für jede alte Adresse eine Entscheidung: 301 oder 404/410.
• Testen Sie am Launch-Tag die Weiterleitungstabelle live, Zeile für Zeile; reichen Sie die Sitemap ein.
• Beobachten Sie in den Wochen nach dem Umzug die Search Console; bewahren Sie die alte WordPress-Installation eine Zeit lang als Archiv auf, aber nicht öffentlich zugänglich.

Ein Umzug von WordPress bringt die unsichtbare Arbeit ans Licht, die eine Website über Jahre angesammelt hat. Diese Liste vor dem Umzug zu schreiben, geht immer schneller, als nach dem Umzug die Ursache des Verlusts zu suchen.

Wenn Sie beim Relaunch keinen Traffic verlieren möchten: Website-Relaunch und Migration erfasst die alten Adressen, baut eine kettenfreie 301-Weiterleitungstabelle und überwacht die Website 90 Tage nach dem Umzug.