Umstellen — ohne die Sichtbarkeit mitzunehmen.

Vorab die Grundsatzfrage.

Bevor es um das Wie geht: Ist es das Richtige? Eine Umstellung ist deutlich aufwendiger als ein Neubau, weil der gesamte Altbestand mitgenommen werden muss. Wenn der Anlass „die Seite ist langsam“ lautet, gibt es günstigere Wege (Lohnt es sich?).

Wenn die Entscheidung gefallen ist, gilt der Rest dieser Seite.

Bestandsaufnahme.

1. Seitentypen auflisten: Welche Vorlagen gibt es tatsächlich?
2. Inhaltstypen und Felder erfassen, einschließlich aller Zusatzfelder.
3. Blocktypen zählen, die in Inhalten vorkommen.
4. Plugins durchgehen und nach Frontend oder Backend sortieren.
5. Adressen vollständig erfassen — dazu gleich mehr.
6. Weiterleitungsregeln exportieren.
7. Formulare auflisten samt Empfängern und Bestätigungen.
8. Externe Einbindungen notieren.

Punkt drei ist aufwendiger, als es klingt, und entscheidet über den Preis. Eine gewachsene Seite hat oft zwanzig oder mehr verwendete Blocktypen, teils aus Erweiterungspaketen — jeder davon muss im Frontend dargestellt werden (Kosten).

Ein praktischer Weg, das zu erheben: eine Abfrage über die Datenbank, die zählt, welche Blocktypen wie oft vorkommen. Dann sieht man, welche man abbilden muss und welche in drei alten Beiträgen stehen und besser ersetzt werden.

Adressen vollständig erfassen.

Der wichtigste Arbeitsschritt des ganzen Projekts. Quellen, alle nutzen:

• Die XML-Sitemap — zeigt die gewollten Adressen.
• Serverprotokolle der letzten Monate — zeigen, was tatsächlich aufgerufen wird.
• Search Console — zeigt, was im Index steht und Besucher bringt.
• Bestehende Weiterleitungsregeln — die müssen weiterleben.
• Interne Verlinkung über einen Crawler.
• Dateien: PDFs und Bilder, die direkt verlinkt sind.

Die zweite und sechste Quelle finden, was in keiner Sitemap steht: alte Kampagnenseiten, verlinkte Dokumente, Bilder aus Newslettern, Adressen aus gedruckten Materialien. Genau diese fallen sonst durch und erzeugen Fehlerseiten (SEO).

Ergebnis ist eine Liste, in der zu jeder alten Adresse steht: bleibt gleich, ändert sich zu X, oder entfällt. Die dritte Kategorie braucht eine Entscheidung — Weiterleitung auf etwas Passendes oder bewusst eine Fehlerseite.

Inhalte vorbereiten.

Eine Umstellung ist ein guter Zeitpunkt zum Aufräumen, aber mit Maß. Sinnvoll: Inhalte entfernen, die seit Jahren niemand aufruft; Blocktypen vereinheitlichen; fehlende Alternativtexte ergänzen; Mediathek ausmisten.

Nicht sinnvoll: gleichzeitig die Inhaltsstruktur umbauen. Zwei große Änderungen auf einmal machen es unmöglich, später zuzuordnen, woher ein Problem kommt. Erst umstellen, dann umbauen.

Was dagegen vorher passieren sollte: Zusatzfelder prüfen, ob sie über die Schnittstelle herausgegeben werden. Das ist ein häufiger später Schreck (Custom Post Types).

Plugins durchgehen.

Zeile vier ist die unangenehmste. Inhalte, die mit einem Page Builder gebaut wurden, liegen oft in einem eigenen Format vor, das über die Schnittstelle nicht sinnvoll herauskommt. Dann steht ein Inhaltsumzug an — und der kann je nach Seitenzahl das größte Einzelpaket des Projekts sein (Builder-Inhalte umziehen).

Prüf das früh, am besten vor dem Angebot. Es ist der Punkt, an dem Projekte deutlich teurer werden als gedacht.

In Etappen umstellen.

Alles auf einmal umzustellen ist bei einer gewachsenen Seite riskant. Besser in Abschnitten:

1. Einen abgegrenzten Bereich zuerst — oft der Blog, weil die Struktur einfach ist.
2. Vor dem Hauptbereich einen Pfad umleiten, so dass beide Systeme nebeneinander laufen.
3. Beobachten, ob Sichtbarkeit und Verhalten stabil bleiben.
4. Nächsten Bereich übernehmen.
5. Zum Schluss die Startseite und die wichtigsten Leistungsseiten.

Technisch funktioniert das über eine Regel, die bestimmte Pfade an das neue Frontend weitergibt und den Rest beim alten System lässt. Für Besucher und Suchmaschinen bleibt es eine Website mit einer Domain.

Der Vorteil: Geht etwas schief, betrifft es einen Bereich und nicht alles — und man lernt am kleinen Teil, bevor man den wichtigen anfasst.

Parallelbetrieb.

Vor der Umschaltung sollte das neue Frontend unter einer Testadresse laufen und mit der bestehenden Seite verglichen werden: Seite für Seite, zumindest je Typ eine.

Worauf achten: Ist der Inhalt vollständig? Stimmen Titel und Beschreibung? Sind alle Links da? Funktionieren Formulare? Sehen die Blöcke richtig aus? Ist die mobile Darstellung in Ordnung?

Wichtig: Die Testadresse muss vor Suchmaschinen gesperrt sein — und diese Sperre nach der Umschaltung entfernt werden. Das zu vergessen, ist der teuerste einzelne Fehler bei Umstellungen (Testfassungen).

Die Umschaltung.

1. Vollständige Sicherung des alten Zustands (Backup).
2. Weiterleitungen im Frontend hinterlegt und getestet.
3. Sperre entfernen, Indexierung freigeben.
4. Umschalten, zu einer ruhigen Zeit.
5. Sofort prüfen: Startseite, je ein Seitentyp, Formular, Sitemap.
6. WordPress abschirmen und aus dem Index halten.
7. Sitemap einreichen.
8. Beobachten.

Schritt drei und sechs werden am häufigsten vergessen und wirken gegenläufig: Das Neue muss in den Index, das alte WordPress heraus.

Danach prüfen.

• Fehlerseiten in der Search Console, täglich in der ersten Woche.
• Indexierte Seiten — steigt die Zahl, oder fällt sie?
• Stichprobe alter Adressen aus der Liste.
• Interne WordPress-Adresse nicht im Index.
• Besucherzahlen im Vergleich zum Vorjahreszeitraum.
• Formulareingänge — kommen sie noch an?
• Ladezeitwerte nach einigen Wochen (Core Web Vitals).

Punkt sechs klingt banal und ist ein realer Fall: Nach Umstellungen kommen Kontaktanfragen nicht mehr an, und weil keine Fehlermeldung erscheint, fällt es erst auf, wenn jemand anruft und fragt, warum nicht geantwortet wurde. Trag dir für die erste Woche ein, täglich ein Testformular abzuschicken.

Häufigste Fehler.

• Sperre für Suchmaschinen nach dem Start nicht entfernt.
• Adressliste unvollständig, alte Adressen laufen ins Leere.
• Weiterleitungsregeln nicht übernommen.
• WordPress bleibt öffentlich und erzeugt doppelte Inhalte.
• Builder-Inhalte zu spät geprüft.
• Formulare nicht getestet.
• Alles auf einmal statt in Etappen.
• Kein Rückweg geplant.

Der Rückweg.

Für den Fall, dass es schiefgeht: Lass das alte System einige Wochen lauffähig stehen, mit allen Inhalten und Einstellungen. Dokumentiere, welche Regel umzustellen ist, um zurückzuschalten — und probier es einmal in einer ruhigen Minute aus.

Die Umschaltung zurück ist bei richtiger Vorbereitung eine Sache von Minuten. Ohne Vorbereitung ist sie ein Abend voller Hektik. Der Unterschied kostet eine Stunde Planung (Betrieb).

Wenn du weiterkommen willst.

Wenn du umstellen willst und nicht riskieren magst, dabei Rankings oder Anfragen zu verlieren. Ich schaue mir an, was du vorhast, und sage dir, ob headless passt — und wenn nicht, was stattdessen: Headless WordPress. Geht es nur um Tempo, ist oft Ladezeitarbeit an der bestehenden Seite der günstigere Weg.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich arbeite seit Jahren mit WordPress und baue daneben eigene Plattformen mit Next.js — Lernplattformen mit mehreren tausend Seiten, bei denen WordPress als Redaktionssystem im Hintergrund läuft und das Frontend davon getrennt ist. Das ist also keine Theorie, sondern das, womit ich meine eigenen Projekte betreibe.

Genau deshalb sage ich auch offen, wann es sich nicht lohnt. Headless ist aufwendiger im Bau und im Betrieb, und für eine normale Unternehmenswebsite ist es fast immer die falsche Antwort. Wer mir schreibt und eine fünfzehnseitige Firmenwebsite headless bauen lassen will, bekommt von mir eine Rückfrage und keinen Kostenvoranschlag.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.