Modernisierung von Legacy-Websites mit WordPress 2026

Eine Legacy-Unternehmensseite ist 2026 mehr als ein altes Design. Sie ist ein Risiko.

Sie ist ein Lager für technische Schulden, eine Sicherheitslücke, die auf ihre Ausnutzung wartet, und ein Engpass, der das Marketing daran hindert, auf den Markt zu reagieren. Große Unternehmen bleiben oft auf diesen Systemen, weil sich eine Migration wie eine „digitale Herztransplantation“ anhört.

Das Risiko des Bleibens ist inzwischen höher als das Risiko des Wechsels. Drupal 7 bekommt seit dem 5. Januar 2025 keine Sicherheitsupdates mehr, lizenzierte Plattformen stellen jedes Jahr eine Rechnung, und ein gepflegtes WordPress bringt für Import, Weiterleitungen und Integrationen dokumentierte Werkzeuge mit.

Dieser Leitfaden geht die strategischen und technischen Phasen durch, in denen eine alte Unternehmensseite auf WordPress modernisiert wird. Er richtet sich an Tech-Leads, Agenturpartner und interne Teams, die einen CMS-Wechsel planen und nicht erst beim Go-live improvisieren wollen.

#Wie man eine alte Website vor der Migration auditiert

Der erste Schritt einer Modernisierung ist nicht das Bauen, sondern die Inventur.

• Content-Schulden: Braucht Ihr Unternehmen wirklich die News-Beiträge von 2011? Wir analysieren den historischen Traffic mit KI und entscheiden, welche Inhalte migriert, archiviert oder gelöscht werden.
• Technische Schulden: Individuelle Integrationen erfassen, die seit fünf Jahren niemand angefasst hat.
• SEO-Kapital: Die URLs mit der besten Leistung identifizieren, die bei der Migration geschützt werden müssen, damit der Traffic nicht einbricht.

#Woran man erkennt, dass eine Unternehmenswebsite neu gebaut werden muss

• Das CMS bekommt keine Sicherheitsupdates mehr. Drupal 7 hat am 5. Januar 2025 sein Lebensende erreicht, wie das Drupal-Sicherheitsteam angekündigt hat, und viele Unternehmensseiten laufen noch darauf.
• Eine neue Landingpage braucht ein Entwickler-Ticket statt zehn freier Minuten einer Redakteurin.
• Das Marketing will Analytics, ein CRM oder Marketing-Automation anbinden, und die Plattform kann mit keinem dieser Systeme sprechen.

#Checkliste für die Inventur vor der Website-Migration

Auf der Content-Seite: jede Seite mit URL, das News-Archiv, die Mediathek samt PDFs, jedes Formular, Sonderfunktionen wie Suche oder Konfiguratoren und jede Integration mit CRM, ERP oder Analytics. Technisch: Stack, Core Web Vitals, organischer Traffic und Backlinks pro URL, bekannte Schwachstellen und WCAG-Konformität.

Alte Formulareinsendungen und Newsletter-Listen enthalten meist personenbezogene Daten. Entscheiden Sie nach DSGVO, was tatsächlich migriert und was gelöscht wird, statt die ganze Datenbank standardmäßig zu kopieren.

#Welche WordPress-Plugins Funktionen eines alten CMS ersetzen

Alles, was in dieser Tabelle keine Zeile hat, ist Individualentwicklung, und diesen Teil des Projekts sollten Sie am sorgfältigsten abgrenzen.

#Headless oder monolithisches WordPress für Unternehmensseiten

Modernisierung bedeutet nicht immer einen 1:1-Ersatz. Der monolithische Ansatz passt zu Marken, die ihrem Marketingteam maximale Bedienbarkeit im Block-Editor geben wollen. Der entkoppelte Ansatz (Headless) passt zu Unternehmen, die dieselben Inhalte auch an Apps, Kioske und weitere Websites ausliefern.

#Welche WordPress-Architektur zur Größe der Seite passt

Eine Seite mit einigen hundert Unterseiten ist meist mit verwaltetem WordPress gut bedient (Block-Theme, ACF Pro, Redis als Object Cache, Cloudflare oder Bunny.net vor einem Host wie Kinsta oder WP Engine). Viele tausend URLs oder Inhalte, die auch Apps speisen, sprechen für Headless: WPGraphQL mit einem Frontend in Astro oder Next.js. Mehrsprachige Gruppen wählen oft Multisite mit WPML oder Polylang, beschrieben im Leitfaden zur globalen Content-Strategie mit WordPress.

#WordPress-Serveranforderungen für eine Unternehmensmigration 2026

Der Hosting-Vertrag für die neue Seite wird meist unterschrieben, bevor das erste Template existiert, also muss die Laufzeitumgebung früh festgelegt werden. Die offizielle Anforderungsseite von WordPress empfiehlt PHP 8.3 oder neuer, MySQL 8.0 oder neuer oder MariaDB 10.11 oder neuer sowie HTTPS-Unterstützung. WordPress läuft noch auf PHP 7.4 und MySQL 5.5.5, doch dieselbe Seite warnt, dass diese Versionen ihr Lebensende erreicht haben und die Seite Sicherheitslücken aussetzen können.

Der PHP-Zweig entscheidet, wie lange die neue Plattform bis zum ersten erzwungenen Upgrade läuft. Die Daten stammen von der PHP-Seite zu unterstützten Versionen:

Eine Seite, die 2026 auf PHP 8.2 startet, verliert Sicherheitsupdates am Ende desselben Jahres. Schreiben Sie PHP 8.3 oder 8.4 in die Hosting-Spezifikation und den Upgrade-Pfad zum nächsten Zweig in den Wartungsvertrag, damit das Legacy-Problem auf der neuen Plattform nicht von vorn beginnt.

Ist die abzulösende Seite bereits eine alte WordPress-Installation, liegt die Arbeit vor allem im Code (Theme, Plugins, Datenbank). Diesen Weg beschreibt unser Leitfaden zur Modernisierung alter WordPress-Codebasen.

#Wie man Inhalte aus einem alten CMS nach WordPress migriert

Die Migration von Daten aus einem alten, proprietären CMS nach WordPress war früher Handarbeit. Heute ist sie ein skriptgestützter Mapping-Prozess.

• Feldnormalisierung: Unstrukturierte Inhalte werden auf strukturierte WordPress-Blöcke abgebildet. Halten Sie dafür eine Mapping-Tabelle von Quellfeldern auf Zielblöcke oder Meta-Keys.
• Asset-Migration: Tausende Bilder und PDFs umziehen, mit internen Links, Alt-Texten und SEO-Metadaten, besonders wenn URLs in PDFs und E-Mails hartcodiert sind.

#Wie man Inhalte aus einem alten CMS mit WP-CLI importiert

WordPress hat keinen Importer für Sitecore, ein individuelles .NET-Portal oder die meisten proprietären Systeme. Der übliche Weg: aus der alten Plattform mit einem eigenen Skript exportieren, das Ergebnis als WXR-Datei schreiben (das XML-Format, das WordPress selbst exportiert) und diese Datei über die Kommandozeile importieren.

• wp import ist die Kommandozeilen-Schnittstelle zum Plugin WordPress Importer. Die Option --authors nimmt create, mapping.csv oder skip, sodass Autorenkonten aus dem Altsystem per CSV bestehenden Redaktionskonten zugeordnet werden können, statt sie einzeln anzulegen.
• wp media import erzeugt Anhänge aus lokalen Dateien oder URLs. Der Befehl nimmt --post_id, um die Datei der richtigen Seite zuzuordnen, --alt für den Alternativtext und --preserve-filetime, um das ursprüngliche Dateidatum als Veröffentlichungsdatum zu behalten.
• wp search-replace schreibt alte Pfade und Domains in der ganzen Datenbank um. Er behandelt serialisierte PHP-Daten korrekt, und --dry-run zeigt jede Änderung, ohne zu speichern. Diesen Lauf sollten Sie vor dem echten prüfen.

Führen Sie den Import auf Staging aus, vergleichen Sie die Seitenzahl pro Template mit der Inventur und wiederholen Sie ihn erst dann als abschließenden Delta-Import kurz vor dem Launch.

#Phasen einer Website-Migration Schritt für Schritt

1. Vorbereitung. URL-Liste mit Traffic pro URL einfrieren, Redirect-Map entwerfen, Exportskripte für das alte CMS schreiben und eine Staging-Umgebung aufsetzen.
2. Build. Frontend entwickeln, die Funktionsliste umsetzen, Integrationen anbinden, dann den skriptgestützten Import ausführen.
3. Tests. Funktionale QA über Geräte und Browser, Content-QA gegen die Inventur, SEO-QA von Weiterleitungen, Metadaten, Sitemaps und strukturierten Daten, ein Core-Web-Vitals-Durchgang, ein vollständiges WordPress-Sicherheitsaudit und eine Prüfung nach WCAG 2.2.
4. Launch. Zuerst ein schriftliches Rollback-Verfahren vereinbaren, dann DNS umstellen, Weiterleitungen aktivieren, die neue Sitemap in der Google Search Console einreichen und Traffic, Fehler und Performance in den ersten 48 Stunden eng beobachten.
5. Nach dem Launch. Organischen Traffic mit dem Zeitraum vor der Migration vergleichen, verirrte 404er beheben und die Redaktion schulen.

#Cutover und Rollback absichern

Rollback ist nur real, wenn Sie ihn vorher geübt haben. Das alte Artefakt bleibt deploybar (Blue/Green oder zwei Releases), das letzte Backup von Dateien und Datenbank hat einen geprüften Restore-Pfad, und vorab steht fest, nach wie vielen Minuten kritischer Fehler der Rollback startet. Schema-Änderungen, die nicht rückwärtskompatibel sind, brauchen Migrationsskripte in beide Richtungen oder ein Einfrieren der Schreiblast.

#Wie man bei einer Website-Migration die Google-Rankings hält

Ein Modernisierungsprojekt ist gescheitert, wenn Sie Ihre Suchpositionen verlieren.

• URL-Mapping: Wir erstellen eine 1:1-Zuordnung alter URLs zu neuen und führen sie als Redirect-Tabelle (alte URL, neue URL, Statuscode, Owner).
• Erhalt der Metadaten: Wir exportieren jeden Title-Tag und jede Meta-Beschreibung aus dem Altsystem, damit die Kontinuität für Google erhalten bleibt.

Die beste Weiterleitung ist die, die Sie nie brauchen, also lassen Sie URLs unverändert, wo die neue Struktur es zulässt. Neben Titeln und Meta-Beschreibungen müssen Canonical-Tags, hreflang, interne Links und strukturierte Daten mitwandern. Endete die alte Seite auf .aspx oder .cgi, zeigen diese Adressen direkt auf die neuen WordPress-Slugs.

#Was Google bei einem Website-Umzug mit URL-Änderungen empfiehlt

Google beschreibt genau dieses Szenario im Leitfaden zu Website-Umzügen mit URL-Änderungen. Die Punkte, die den Plan einer Unternehmensmigration ändern:

• Nutzen Sie serverseitige permanente Weiterleitungen (301 oder 308) von jeder alten URL auf die neue Adresse und behalten Sie sie so lange wie möglich, in der Regel mindestens ein Jahr.
• Seiten, die Sie bewusst einstellen, sollten auf der neuen Seite mit 404 oder 410 antworten, statt auf die Startseite weiterzuleiten.
• Aktualisieren Sie interne Links auf die neuen URLs aus der Zuordnung, und sorgen Sie dafür, dass jede Sitemap die neuen URLs enthält.
• Entfernen Sie noindex-Tags und robots.txt-Sperren, die nur für die Staging-Phase da waren. Das ist der häufigste Fehler am Launch-Tag, weil Staging zu Recht versteckt ist und die Einstellung mit der Datenbank in die Produktion wandert.
• Das Tool zur Adressänderung in der Search Console ist nur für einen Umzug auf eine andere Domain oder Subdomain gedacht. Ein Relaunch auf derselben Domain braucht es nicht.

Google schreibt außerdem, dass es bei einer mittelgroßen Seite einige Wochen oder länger dauern kann, bis die neuen URLs in der Suche erscheinen, bei großen Seiten länger. Zeigt der organische Traffic etwa vier Wochen nach dem Launch keine Erholung, prüfen Sie in dieser Reihenfolge: fehlende oder falsche Weiterleitungen, den Bericht zur Seitenindexierung in der Search Console, für das Rendering blockierte Ressourcen und Canonical-Tags, die noch auf alte URLs zeigen.

#Wie man eine WordPress-Unternehmensseite absichert

Ein CMS ohne Patches ist ein leichtes Ziel, weil seine bekannten Schwachstellen öffentlich sind und nie behoben werden. Der Wechsel auf ein gepflegtes WordPress erlaubt zwei Schritte, die Sicherheitsteams in Konzernen verlangen:

• Hosting mit Audit-Nachweis: Wählen Sie einen Managed-Anbieter, der Ihrem Sicherheitsteam seinen SOC-2- oder ISO-27001-Bericht vorlegen kann, statt eines Servers, den seit dem Weggang der ursprünglichen Agentur niemand gepatcht hat.
• Redaktion über Unternehmens-SSO: Anmeldung über Okta oder Microsoft Entra ID per SAML oder OpenID Connect, sodass das Entfernen eines Mitarbeiters aus dem Verzeichnis auch seinen Zugang zu wp-admin entfernt.

Die Prüfung vor dem Go-Live gehört in ein vollständiges WordPress-Sicherheitsaudit.

#Wie man WordPress per API an Unternehmenssysteme anbindet

Alte Datenbankverbindungen, die direkt mit der Legacy-Seite „gesprochen“ haben, ersetzen wir durch API-Schichten. WordPress arbeitet als Präsentationsschicht und kommuniziert mit Backend-Systemen wie SAP oder einem proprietären CRM über abgesicherte JSON-Endpunkte.

#Wie man Integrationen an der WordPress-REST-API authentifiziert

Ein CRM, ERP oder PIM, das Inhalte in WordPress schreibt, braucht eigene Zugangsdaten. Laut dem Handbuch zur REST-API-Authentifizierung liefert WordPress seit Version 5.6 Anwendungspasswörter (Application Passwords) mit. Sie werden auf der Seite „Benutzer bearbeiten“ erzeugt und per Basic Auth in Anfragen über HTTPS übertragen.

Legen Sie für jede Integration einen eigenen WordPress-Benutzer an, geben Sie ihm die niedrigste Rolle, die für die Aufgabe reicht, und erzeugen Sie ein eigenes Anwendungspasswort. Endet ein Dienstleistervertrag, kappt der Widerruf dieses einen Passworts den Zugang, ohne ein Redaktionskonto anzufassen. Anfragen aus dem Browser in einer angemeldeten Sitzung nutzen stattdessen Cookie-Authentifizierung und müssen eine wp_rest-Nonce mitschicken, sonst behandelt WordPress sie als nicht authentifiziert.

#Wie man Core Web Vitals nach einer WordPress-Migration verbessert

Legacy-Seiten sind fast immer langsam. Messen Sie vor dem Relaunch eine Baseline der wichtigsten Landingpages (Feldwerte über CrUX, Labor über Lighthouse), damit der Vergleich danach belastbar ist. Die Messdefinitionen stehen bei web.dev: LCP, INP und CLS.

Die Modernisierung auf WordPress bringt dafür:

• Moderne Bildformate: Seit WordPress 6.5 lassen sich AVIF-Dateien hochladen und verwenden wie JPEG oder PNG, sofern Imagick oder GD auf dem Server AVIF unterstützt. Eine automatische Umwandlung bestehender Uploads braucht einen Filter, planen Sie sie also als Teil des Medienimports.
• Edge-Caching: Auslieferung der Unternehmensseite von CDN-Standorten nahe den Besuchern statt von einem einzigen Ursprungsserver.

#Wie man den ROI einer Website-Migration berechnet

Es gibt keine universelle ROI-Zahl. Von Projekt zu Projekt übertragbar ist die Struktur der Rechnung.

Die zwei häufigsten Ausgangslagen verhalten sich unterschiedlich. Bei Drupal 7 gibt es keine Lizenz zu kündigen, der Break-even kommt später, und das stärkere Argument ist das Risiko: Eine Plattform ohne Sicherheitsupdates ist ein Vorfall, der auf sein Datum wartet. Bei einem lizenzierten proprietären CMS wie Sitecore fällt der größte Posten des Jahresbudgets weg, und die Amortisationszeit ist ungefähr Projektkosten geteilt durch jährliche Einsparung.

Ergänzen Sie eine Compliance-Spalte. Der European Accessibility Act gilt seit dem 28. Juni 2025 für viele verbraucherorientierte digitale Dienste in der EU, in Deutschland umgesetzt durch das Barrierefreiheitsstärkungsgesetz (BFSG). Das Modernisierungsprojekt selbst wird nach dem Audit individuell kalkuliert.

#WordPress-Agentur für die Migration alter Unternehmensseiten

Bei WPPoland stützt sich die Migrationsarbeit auf drei Dinge.

1. Migrationserfahrung: Wir haben Datenübernahmen aus Sitecore, Drupal 7 und individuellen .NET-Portalen umgesetzt.
2. SEO-Absicherung: Jede Migration beginnt mit einer eingefrorenen URL-Inventur und einer getesteten Redirect-Map und endet mit einer Prüfung von 404ern, Indexierung und organischem Traffic gegen die Baseline vor der Migration.
3. Zukunftsfähige Builds: Wir reparieren nicht nur die alte Seite, wir legen das Fundament für das Wachstum in 2027 und 2028.

#Häufige Fragen zur Modernisierung einer Legacy-Website

1. Gibt es Ausfallzeit? Nein. Bei einem Blue-Green-Deployment wird die neue Seite parallel gebaut und getestet, und die alte bedient Besucher weiter, bis DNS oder Load Balancer auf die neue zeigen.
2. Wie schulen wir das Team für das neue System? WordPress ist deutlich einfacher zu bedienen als die meisten Altsysteme. Wir hinterlegen eine interne Dokumentation direkt im WordPress-Dashboard.
3. Ist Neubau oder Flicken günstiger? Über die Lebensdauer der Plattform gewinnt meist der Neubau, und der ROI-Abschnitt oben zeigt, wie Sie das mit eigenen Rechnungen prüfen.

#Fazit

Mehr zu Website-Migrationen auf Astro und Next.js finden Sie bei WPPoland. Alte Technik veraltet nicht über Nacht, aber die Kosten des Abwartens wachsen. Läuft Ihre Unternehmensseite noch auf einem fragilen Stack von 2018, tauchen schwache Performance, Sicherheitsrisiko und Reibung in der Redaktion immer wieder auf. Eine strukturierte WordPress-Modernisierung bewahrt, was funktioniert, und ersetzt die Teile, die das Geschäft bremsen.

Wenn eine alte Seite das Team ausbremst, schreiben Sie den aktuellen Stack, die riskanten Integrationen und die wichtigsten Seiten auf. Das reicht für ein brauchbares Modernisierungs-Briefing.

#Was vor einer Website-Migration zu entscheiden ist

Drei Entscheidungen prägen den Zeitplan. Die erste ist das Urteil über die Inhalte: Jede alte Seite wird im Audit als migrieren, archivieren oder löschen markiert, und die URLs mit der besten Leistung kommen auf eine geschützte Liste. Diese Liste wird zur 301-Map, einschließlich alter .aspx- oder .cgi-Adressen, die auf den neuen WordPress-Slugs landen müssen.

Die zweite ist die Architektur. Ein monolithischer Build mit Gutenberg passt zu einem Marketingteam, das täglich editiert, ein entkoppeltes Setup zu einem Unternehmen, das aus denselben Inhalten auch Apps oder Kioske speist. Wer das mitten im Projekt ändert, baut die Templates neu.

Die dritte sind die Integrationen. Listen Sie jedes Backend auf, mit dem die alte Seite spricht, etwa SAP oder ein proprietäres CRM, und entscheiden Sie, welche eine API-Schicht bekommen und welche mit der alten Plattform in Rente gehen. Setzen Sie SSO auf diese Liste, damit der Zugang der Mitarbeitenden zur Seite dem Identity-Provider folgt.

Sind diese drei Punkte geklärt, werden die Zeitrahmen aus den häufigen Fragen, etwa 3 bis 5 Monate für eine mittelgroße Unternehmensseite und 6 bis 12 für ein globales Netzwerk, planbar. Führen Sie Shadow-Migration und Blue-Green-Umschaltung erst durch, wenn die Redirect-Map steht.