Modernisierung von Legacy-Websites mit WordPress 2026

Eine Legacy-Unternehmensseite ist 2026 selten nur „alt“. Sie ist ein System aus veraltetem Theme-PHP, Plugin-Ketten, einer PHP-Laufzeit unterhalb des Hosting-Standards und Content, der niemand mehr pflegt - und trotzdem noch in Suchergebnissen steht.

Dieser Guide beschreibt eine Engineering- und Strategie-Reihenfolge: Audit, Schuldenabbau, Migrationsentscheidung, Core Web Vitals, Staging und Rollback. Er richtet sich an Tech-Leads, Agenturpartner und interne WordPress-Teams, die eine Modernisierung planen und nicht erst beim Go-Live improvisieren wollen.

Offizielle Anker: Moving WordPress, Migrating a WordPress site, Performance optimization und die Core Web Vitals auf web.dev.

#Warum Legacy-Sites 2026 riskanter werden

Drei Kräfte treffen gleichzeitig auf:

1. Laufzeit-Druck. Hosting-Anbieter und WordPress-Kompatibilität erwarten aktuelle PHP-Versionen. Alte Themes und Plugins brechen oft erst beim Upgrade sichtbar.
2. Sicherheits-Oberfläche. Ungepatchte Plugins und Custom-Code ohne Maintainer erhöhen die Angriffsfläche; Updates werden blockiert, weil niemand Regressionen testen kann.
3. Messbarkeit. Such- und UX-Signale laufen über Feldmetriken (LCP, INP, CLS). Eine Seite, die „optisch ok“ wirkt, kann im CrUX-Report trotzdem unter dem „good“-Schwellenwert liegen.

Modernisierung heißt hier nicht automatisch neues Design. Sie heißt: Risiken und Abhängigkeiten sichtbar machen, dann gezielt ersetzen.

#Legacy-PHP-Themes auditieren

Ein Theme-Audit ist der erste harte Filter. Ziel ist eine Inventarliste, keine Meinungsrunde.

#Was Sie im Theme-Code prüfen

• Template-Hierarchie und Overrides. Welche Dateien überschreiben Core-Verhalten (single.php, page.php, Custom Templates)? Gibt es hardcodierte Queries außerhalb von WP_Query?
• Direkte DB-Zugriffe. #raw SQL oder $wpdb ohne prepare() sind Migrations- und Sicherheitsrisiken.
• Enqueue-Chaos. Globale jQuery-Plugins, doppelte Bibliotheken, CSS ohne Conditional Loading.
• Child-Theme-Lage. Liegt Custom-Code im Parent? Dann ist jedes Update ein Konflikt.
• Block-Bereitschaft. Fehlt theme.json, fehlen Block-Templates oder Styles, steckt die UI in klassischen PHP-Templates fest.

#Praktische Audit-Artefakte

Erzeugen Sie vor dem ersten Refactor drei Dateien (Wiki, Ticket oder Repo-Docs):

1. Theme-Inventory - Liste aller Custom-Templates und der Post Types, die sie bedienen.
2. Hook-Map - Actions/Filters in functions.php und Includes, gruppiert nach Zweck (SEO, Assets, Shortcodes, Integrationen).
3. Breakage-Notes - bekannte PHP-Warnungen, Deprecated-Calls, fehlende Escapes.

Ohne diese drei Artefakte wird „Redesign“ schnell zu Blindflug: Designer ändern Layouts, während unbekanntes PHP weiter Daten schreibt.

#Plugin-Schulden inventarisieren und abbauen

Plugin-Schulden sind oft teurer als Theme-Schulden, weil sie Daten schreiben und Cron-Jobs erzeugen.

#Inventur-Methode

Exportieren Sie die aktive Plugin-Liste und bewerten Sie jedes Plugin nach vier Achsen:

Plugins ohne Maintainer und ohne klaren Job gehören auf die Deactivate-Liste, nicht in den Migrations-Scope. Deaktivieren Sie auf Staging zuerst, messen Sie Frontend und Admin, dann entfernen Sie und prüfen Sie verwaiste Meta-Keys.

#Typische Schuldenmuster

• Doppelte SEO-Plugins (zwei Sitemap-/Title-Generatoren).
• Page-Builder plus Custom-Theme mit parallelen Layout-Systemen.
• Security-Suites, die Caching und REST blockieren, ohne dass jemand die Regeln kennt.
• Backup-Plugins auf demselben Host wie Production, ohne Offsite-Ziel.

Ziel des Abbaus: weniger Update-Kollisionen, kürzere Deploy-Fenster, klarere Ownership.

#PHP-Version und Kompatibilitätsmatrix

PHP ist kein „Hosting-Detail“. Es ist die Laufzeit, an der Theme, Plugins und Custom-MU-Plugins scheitern oder skalieren.

#Vorgehen

1. Lesen Sie die aktuelle Runtime (phpversion() oder Hosting-Panel) und die von WordPress empfohlenen Anforderungen für Ihre Core-Version.
2. Bauen Sie eine Kompatibilitätsmatrix: Plugin × PHP-Zielversion × letzter erfolgreicher Smoke-Test.
3. Starten Sie Upgrades auf Staging: PHP-Zielversion zuerst auf Staging, dann Theme/Plugins, dann Production-Fenster.
4. Loggen Sie Deprecations und Fatals getrennt. Fatals blockieren Go-Live; Deprecations gehören in die nächste Sprint-Liste.

Ein häufiges Anti-Pattern: Production bleibt auf einer alten PHP-Version, während Staging schon „fertig“ modernisiert wirkt. Dann ist der Cutover der erste echte Test - und der schlechteste Zeitpunkt für Überraschungen.

#Content-Migration und URL-Kapital

Content-Migration ist der Teil, den Marketing spürt und Engineering unterschätzt. WordPress dokumentiert den Umzug von Installationen und Domains in Moving WordPress und den Admin-Leitfaden Migrating a WordPress site. Die Prinzipien gelten auch, wenn Sie von einem anderen CMS kommen: Serialisierung, Pfade und Redirects.

#Inventory vor dem Export

• Traffic-gestützte Priorität. Seiten mit organischem Traffic und Conversions migrieren zuerst; tote Archive können 410 oder Archiv-Status bekommen.
• Mediathek. Dateinamen, Alt-Texte, Größen - besonders wenn URLs in PDFs und E-Mails hartcodiert sind.
• Strukturierte Felder. ACF, Meta Boxes, Shortcodes: Mapping-Tabelle von Quellfeldern auf Zielblöcke oder Meta-Keys.
• Taxonomien. Kategorie-Slugs, die in Permalinks sitzen, sind Redirect-Kandidaten.

#Migrationsmuster

1. In-Place Upgrade - gleiche Domain, gleiche Permalinks, Theme/Plugins modernisiert. Geringstes SEO-Risiko, wenn URLs stabil bleiben.
2. Shadow Migration - neue Umgebung parallel; Redirect-Map und Content-Diff vor DNS-/Deploy-Cutover.
3. CMS-zu-WordPress - Export (XML, DB, API), Mapping der Felder, Import; danach manuelle QA der Top-URLs.

Unabhängig vom Muster: halten Sie eine Redirect-Tabelle (alt → neu, Statuscode, Owner). Ohne sie verlieren Sie Ranking-Kapital an 404er, die niemand in der Crawl-Statistik liest.

#Redesign vs. Rebuild: Entscheidung ohne Theater

Beide Worte werden synonym benutzt. Sie sind es nicht.

#Redesign

• Visuelle und UX-Schicht ändert sich.
• Content-Modell, Permalinks und viele Integrationen bleiben.
• Geeignet, wenn Theme-PHP und Plugins wartbar sind und die Hauptschuld in Templates/CSS liegt.

#Rebuild

• Neues Theme (oder Block-Theme), oft neues Content-Modell, manchmal Headless-Frontend.
• Integrationen werden neu angebunden.
• Geeignet, wenn Parent-Theme tot ist, Page-Builder und Custom-Code unentwirrbar sind oder PHP-Upgrades strukturell scheitern.

#Entscheidungsfragen

1. Können wir PHP auf die Zielversion heben, ohne dass das Theme abstürzt?
2. Gibt es einen Maintainer für die kritischen Plugins?
3. Liegt mehr als die Hälfte der Custom-Logik in undokumentierten Theme-Includes?
4. Müssen Permalinks ohnehin geändert werden (Multi-Brand, Legal, Internationalisierung)?

Wenn 1 und 2 „nein“ sind und 3 „ja“, ist Rebuild oft der kürzere Weg - nicht weil er billiger wirkt, sondern weil Refactoring eines toten Themes endlos wird. Wenn Permalinks stabil bleiben können, priorisieren Sie Redesign oder inkrementelles Strangler-Pattern: neue Templates/Blöcke Seite für Seite, altes PHP nur noch für Reststrecken.

#Core Web Vitals in die Modernisierung einbauen

Performance ist kein Polier-Schritt nach dem Launch. WordPress beschreibt Optimierungshebel in der Performance-Dokumentation. Die Messdefinitionen liegen bei web.dev: LCP, INP, CLS und der Überblick Web Vitals.

#Was Sie vor dem Redesign messen

• Baseline auf Production (Feld über CrUX/PSI, Labor über Lighthouse) für die Top-Landingpages.
• TTFB als Frühindikator für Origin/Caching - nicht als Ersatz für LCP.
• Asset-Budget: Hero-Bildgröße, kritisches CSS, Anzahl der Blocking-Scripts.

#Typische Legacy-Ursachen

Bauen Sie CWV-Checks in die Definition of Done für Templates und Blocks: kein Merge ohne Labor-Vergleich gegen Baseline auf Staging. Feldwerte brauchen Zeit nach dem Launch - planen Sie eine Nachmessung, nicht nur einen Go-Live-Screenshot.

#Staging, Cutover und Rollback

Ohne Staging und Rollback-Plan ist jede Modernisierung ein einmaliger Deploy-Hoffnungswurf.

#Staging-Mindeststandard

• Produktionsnahe PHP-Version, gleiche Major-Version von WordPress.
• Anonymisierte oder geschützte Kopie der Datenbank (keine echten Kundendaten öffentlich).
• Search-Replace von URLs nach der Dokumentation zu Moving WordPress - serialisierte Daten nicht mit Blind-Replace zerstören.
• Smoke-Tests: Login, Checkout/Formular (falls vorhanden), Top-20-URLs, Sitemap, kritische Integrationen.

#Cutover-Checkliste

1. Wartungsfenster kommunizieren (intern und, wenn nötig, öffentlich).
2. Letztes Backup (Dateien + DB) mit geprüftem Restore-Pfad.
3. DNS/Deploy-Schritt dokumentiert; Owner und Zeitstempel.
4. Redirect-Map live und getestet.
5. Monitoring: Error-Log, Uptime, Such-Console-Crawl-Fehler in den ersten 48 Stunden.

#Rollback, der wirklich funktioniert

Rollback ist nur real, wenn Sie ihn vorher geübt haben:

• Blue/Green oder zwei Releases - altes Artefakt bleibt deploybar.
• DB-Kompatibilität - Schema-Änderungen, die nicht rückwärtskompatibel sind, brauchen Migrationsskripte in beide Richtungen oder ein Freeze der Schreiblast.
• Zeitfenster - definieren Sie vorab, nach wie vielen Minuten kritischer Fehler der Rollback startet (nicht „wir schauen morgen“).

Ein dokumentierter Rollback-Drill auf Staging kostet einen halben Tag und spart den peinlichsten Incident nach dem Relaunch.

#Betriebsmodell nach dem Go-Live

Modernisierung endet nicht mit dem grünen Deploy.

• Update-Politik. Wer patched Core, Themes, Plugins - und in welchem Rhythmus auf Staging vor Production?
• Observability. PHP-Error-Log, Object-Cache-Hitrate, CWV-Feldwerte monatlich.
• Content-Governance. Wer darf Blöcke und Plugins freigeben? Ohne Governance wächst die Schuldenliste wieder.
• Integrationen. CRM, SSO, Tag-Manager: Owner und Failover notieren.

Interne Verweise für angrenzende Themen: WordPress-Migrationen zu Astro und Next.js und der Leitfaden Wann eine Website neu aufbauen.

#Kurz-Fahrplan für Teams

1. Theme- und Plugin-Audit mit Inventory und Hook-Map.
2. PHP-Zielversion auf Staging; Kompatibilitätsmatrix füllen.
3. Content-Inventory und Redirect-Map; Migrationsmuster wählen.
4. Redesign vs. Rebuild entscheiden und Scope einfrieren.
5. CWV-Baseline setzen; Budgets in Templates/Blocks verankern.
6. Staging-Smoke, Cutover, geübter Rollback.
7. Betriebsmodell (Updates, Logs, Ownership) für die ersten 90 Tage festlegen.

Wenn Sie an einem dieser Schritte vorbeigehen, zahlen Sie den Preis später - meist als Notfall-Deploy ohne Tests.

#Fazit

Legacy-Modernisierung mit WordPress ist eine Reihenfolge aus Audit, Schuldenabbau, Content- und URL-Disziplin, bewusster Architekturentscheidung und messbarer Performance - abgesichert durch Staging und Rollback. Design allein repariert weder PHP-Warnungen noch Plugin-Schulden.

Nutzen Sie die WordPress-Migrations- und Performance-Dokumentation als operative Basis und web.dev als Messdefinition für Core Web Vitals. Dann ist der Relaunch ein kontrollierter Cutover, kein Glücksspiel.