Modernisierung alter WordPress-Codebasen: Strategie 2026 für Unternehmen

Eine alte WordPress-Codebasis ist eine, bei der niemand vorhersagen kann, was eine Änderung kaputt macht. Das Alter ist nicht das Problem, sondern die fehlende Messung. Dieser Leitfaden erzeugt zuerst diese Messwerte und ersetzt danach den Code in einer Reihenfolge, in der sich jeder Schritt zurücknehmen lässt.

Die Websites, um die es geht, erkennt man sofort: gebaut zwischen 2015 und 2020, ein klassisches Theme mit einer functions.php jenseits von zweitausend Zeilen, mehrere individuelle Plugins ohne Upstream-Repository und eine Tabelle wp_options, die seit dem Launch niemand angesehen hat. Meist laufen sie noch. Was nicht mehr funktioniert, ist die Möglichkeit, sie ohne böse Überraschungen zu ändern.

WordPress 7.1.1 erschien am 17. September 2026. Der Abstand zwischen dieser Version und einem Stack von 2018 liegt selten im Core. Er liegt in der PHP-Version darunter, in den Skripten, die das Theme einreiht, und in einer Datenbank, die seit Jahren Zeilen von Plugins ansammelt, die es nicht mehr gibt.

Mehr über professionelle WordPress-Entwicklung erfahren Sie bei WPPoland.

#1. Wie man ein altes WordPress auditiert

Beginnen Sie mit den Zahlen, die sich auf einer Live-Website ablesen lassen, nicht mit einer Meinung über den Code.

#Minimale und empfohlene PHP-Version für WordPress

Untergrenze und Empfehlung sind zwei verschiedene Dinge. Der WordPress-Trunk setzt weiterhin $required_php_version = '7.4' in src/wp-includes/version.php, während die Seite mit den Anforderungen PHP 8.3 oder höher sowie MariaDB 10.11 oder MySQL 8.0 empfiehlt. Anders gesagt: Der Core startet unter 7.4, und unter 7.4 zu starten heißt, ohne Sicherheitspatches zu starten.

Über die Migration entscheiden die Daten auf php.net, nicht ein versprochener Prozentsatz an Verbesserung:

Ein Plan, der auf 8.2 zielt, hat etwa drei Monate Spielraum. Zielen Sie auf 8.3 oder 8.4.

Eine Website auf 7.4, 8.0 oder 8.1 bekam bei den kritischen PHP-Lücken vom 21. Oktober 2026 keine neue Version. Die Schritte für eine solche Website stehen im Beitrag was bei PHP2Shell auf einer WordPress-Website zu tun ist.

#Veraltete Funktionen in Produktion ohne WP_DEBUG protokollieren

Das ist der Teil, den die meisten Audits falsch machen. Der Core feuert do_action( 'deprecated_function_run', ... ) innerhalb von _deprecated_function() bevor er WP_DEBUG prüft; nur der Aufruf von trigger_error() hängt davon ab. Dasselbe gilt für deprecated_hook_run, deprecated_argument_run, deprecated_file_included, deprecated_class_run und deprecated_constructor_run. Ein kleines MU-Plugin liefert Ihnen ein echtes Inventar aus dem Live-Traffic, ohne etwas auf dem Bildschirm auszugeben:

<?php
// mu-plugins/deprecation-log.php
$hooks = array(
	'deprecated_function_run',
	'deprecated_hook_run',
	'deprecated_argument_run',
	'deprecated_file_included',
	'deprecated_class_run',
	'deprecated_constructor_run',
);

foreach ( $hooks as $hook ) {
	add_action(
		$hook,
		static function () use ( $hook ) {
			error_log( $hook . ' ' . wp_json_encode( func_get_args() ) );
		},
		10,
		4
	);
}

Lassen Sie es einen kompletten Geschäftszyklus lang laufen. Ein wöchentlicher Import oder eine quartalsweise Berichtsseite berühren veralteten Code, den kein Crawl des Frontends erreicht.

#WordPress-Checksums mit WP-CLI prüfen

wp core verify-checksums und wp plugin verify-checksums vergleichen die Installation mit den Hashes von WordPress.org. Auf einer Website mit zehn Jahren Geschichte findet das fast immer ein Plugin, das jemand von Hand gepatcht hat, der längst nicht mehr im Team ist. Genau diese Dateien werden beim nächsten Update überschrieben, und sie gehören als Erstes in die Versionsverwaltung.

#Wie viele jQuery-Versionen ein altes WordPress lädt

Bevor Sie jQuery die Schuld geben, zählen Sie die Kopien. Der Core registriert genau eine: script-loader.php deklariert jquery-core in Version 3.7.1 und jquery-migrate in 3.4.1, mit jquery als Alias, der von beiden abhängt. Tauchen auf einer Seite mehrere Versionen auf, stammen sie aus Plugins und Themes, die ihre eigene Kopie unter einem anderen Handle einreihen oder ein <script src>-Tag direkt in den Footer schreiben. wp_scripts()->queue zeigt Ihnen in einer Minute, was wohin gehört. Das Core-jQuery abzumelden, um eine CDN-Kopie zu erzwingen, ist genau die Änderung, die das Backend zerlegt: Lassen Sie den Core-Handle in Ruhe und entfernen Sie die Duplikate.

jquery-migrate verdient eine eigene Entscheidung. Es aus der Warteschlange zu nehmen ist eine Zeile, und wenn sich dann die Konsole mit Fehlern füllt, sind diese Fehler die echte Liste der jQuery-1.x-Muster, die noch im Theme stecken.

Beim Plugin-Inventar gilt dieselbe Logik: Websites mit sehr vielen Plugins sind selten effizient, und jedes Plugin, das eine eigene jQuery-Kopie mitbringt, ist ein Kandidat für die Streichliste.

#PHP-Kompatibilitätsscan mit PHPCompatibilityWP

PHPCompatibilityWP gibt es, damit die Sniffs nicht die Polyfills anmerken, die der Core bereits mitbringt:

vendor/bin/phpcs -p wp-content/themes wp-content/plugins \
  --standard=PHPCompatibilityWP \
  --extensions=php \
  --runtime-set testVersion 8.3-

Ohne testVersion sagt das Ergebnis sehr wenig. Mit dem Parameter erhalten Sie eine Dateiliste, sortiert danach, was Sie von der Zielversion trennt.

Das Inventar, das Sie am Ende der ersten Woche haben sollten, hat vier Spalten: aktuelle PHP-Version, Deprecations pro Endpoint, Dateien mit fehlgeschlagener Checksum-Prüfung und PHPCS-Fehler pro Plugin. Alles Weitere wird anhand dieser Tabelle priorisiert.

Aktualisierung vom 28. Oktober 2026. PHPCompatibilityWP zeigt, was auf einer neueren PHP-Version nicht mehr läuft. Einen großen Teil der Korrekturen automatisiert Rector. Laut den Release Notes ist Version 2.8 vom 26. Oktober 2026 rund 26 % schneller als 2.7, auf PHP 8.3 oder neuer mit der Erweiterung PHPStan Turbo etwa dreimal so schnell. Die Regeln kommen jetzt in einem Durchlauf zum Ergebnis und werden auf Idempotenz getestet, ein zweiter Lauf auf derselben Datei ändert also nichts mehr. Für ältere Projekte empfiehlt die Rector-Dokumentation ->withPhpLevel() und eine schrittweise Anhebung statt des vollständigen ->withPhpSets() auf einmal. Lassen Sie jeden Durchlauf auf einem eigenen Branch laufen und prüfen Sie den Diff vor dem Deployment.

#2. Wie man WordPress mit dem Strangler-Fig-Muster refaktoriert

Versuchen Sie nicht, alles auf einmal zu ändern. Das Strangler-Fig-Muster von Martin Fowler, 2004 geschrieben und im August 2024 überarbeitet, ist die einzige Strategie für eine Neuentwicklung, die eine Website am Laufen hält, die Umsatz macht: Stellen Sie das neue System neben das alte, leiten Sie einen Teil des Traffics auf das neue und lassen Sie das alte schrumpfen, bis nichts mehr abzuschneiden ist.

WordPress bietet dafür zwei natürliche Nahtstellen, und beide liegen im Core.

#Phase 1: Core und Infrastruktur aktualisieren

Bevor Sie Templates verschieben, bringen Sie die Infrastruktur in Ordnung: PHP auf einem unterstützten Zweig, WordPress auf der neuesten stabilen Version, MySQL 8.0 oder MariaDB 10.11 gemäß der Anforderungsseite, HTTPS auf der gesamten Website und Backups, die irgendwann jemand tatsächlich wiederhergestellt hat.

#Phase 2: Templates Route für Route migrieren

Die erste Nahtstelle ist template_include. Das ist ein Filter, also kann eine einzelne Route auf den neuen Code wechseln, während alle anderen weiter über die alten Templates laufen. Das genügt, um die Kontaktseite, den Karrierebereich oder einen Inhaltstyp auf ein neu geschriebenes Template mit eigenen Assets zu bringen, und um sie mit einer Zeile zurückzuholen, wenn die Conversion sinkt.

Die zweite ist die hybride Unterstützung für Block-Templates. locate_block_template() in src/wp-includes/block-template.php steigt vorzeitig aus, solange current_theme_supports( 'block-templates' ) nicht wahr ist, und wenn diese Unterstützung deklariert ist, berücksichtigt die Funktion nur Block-Templates mit gleicher oder höherer Spezifität als das PHP-Template, das die Hierarchie bereits gefunden hat. In der Praxis:

add_action(
	'after_setup_theme',
	static function () {
		add_theme_support( 'block-templates' );
	}
);

Ab dann übernimmt eine Datei templates/page-contact.html im klassischen Theme genau diese Route. single.php, archive.php und der Rest bleiben unverändert. Das ist der Mechanismus, der “Migration auf Blöcke” in eine Reihe kleiner Auslieferungen verwandelt statt in ein Wochenende mit einem Rückfallplan, den niemand getestet hat.

Ordnen Sie die Abschnitte nach Risiko, nicht nach Begeisterung. Ein guter erster Abschnitt ist ein Template mit echtem Traffic, einem messbaren Ergebnis und ohne Checkout. Ein schlechter erster Abschnitt ist die Startseite, denn sie hat den größtmöglichen Wirkungsradius genau an dem Tag, an dem Sie den neuen Code am wenigsten kennen.

#Phase 3: Die alten PHP-Templates stilllegen

Lösen Sie die alten PHP-Templates ab, bis die gesamte Website auf dem modernen Stack läuft. Zwei Regeln sorgen dafür, dass das hält. Jeder Abschnitt bringt seine eigenen Assets mit, damit das neue Template nicht versehentlich das alte globale Stylesheet erbt. Und der alte Code wird in derselben Auslieferung gelöscht, die ihn ablöst, denn ein totes Template, das im Repository bleibt, wird innerhalb von sechs Monaten jemand bearbeiten.

#3. Wie man die Datenbank eines alten WordPress bereinigt

Fast alle Meldungen à la “die Datenbank ist langsam” bei einem alten WordPress laufen auf drei Dinge hinaus, und nur eines davon hat mit der Größe zu tun. Einen breiteren Überblick gibt unser Leitfaden zur Datenbankoptimierung.

#Autoload in wp_options reduzieren

Autoload bezahlen Sie bei jedem Request. Seit WordPress 6.6 speichert die Spalte autoload nicht mehr nur yes und no. Die Entwicklernotiz zur Options API führte on, off, auto-on, auto-off und auto ein, und wp_filter_default_autoload_value_via_option_size() in src/wp-includes/option.php verweigert das automatische Laden jedes serialisierten Werts, der den Filter wp_max_autoloaded_option_size überschreitet, standardmäßig 150000 Bytes. Dieser Schutz greift beim Schreiben der Option. Mit dem Blob, den ein 2019 deinstalliertes Plugin dort hinterlassen hat, macht er nichts.

Lesen Sie die echte Liste per SQL aus, nicht über das Dashboard eines Plugins:

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 25;

Diese vier Werte behandelt wp_load_alloptions() als automatisch geladen. Das ist wichtig, denn wp option list --autoload=on --format=total_bytes in WP-CLI erfasst nur autoload='on' OR autoload='yes'. Auf einer Website mit 6.6 oder neuer, wo neue Optionen als auto angelegt werden, meldet dieser Befehl einen kleineren Autoload-Fußabdruck als den, den Sie bei jedem Seitenaufruf bezahlen. Nutzen Sie die Abfrage, oder lesen Sie die WP-CLI-Zahl im Wissen, was sie auslässt.

#Verwaiste Postmeta bereinigen

Verwaiste Postmeta sind eine Zählung, kein Rätsel. Zählen Sie sie, bevor Sie entscheiden, ob sie eine Rolle spielen:

SELECT COUNT(*)
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Zeilen ohne zugehörigen Beitrag lassen sich löschen, und trotzdem machen Sie vorher einen Datenbank-Dump. Meta, die zu einem bereits entfernten Plugin gehören, sind ein eigener, vorsichtigerer Durchgang: Gruppieren Sie nach meta_key, gleichen Sie die Präfixe mit den Plugins ab, die Sie noch nutzen, und löschen Sie Schlüssel für Schlüssel.

Alte Revisionen sind der dritte Block, und der Wert von post_type bleibt auch auf einer deutschsprachigen Website englisch:

DELETE FROM wp_posts
WHERE post_type = 'revision'
AND post_date < DATE_SUB(NOW(), INTERVAL 6 MONTH);

#Indizes von wp_postmeta, InnoDB und utf8mb4

Die Indizes sind der Teil, den niemand liest. src/wp-admin/includes/schema.php gibt wp_postmeta einen Primärschlüssel auf meta_id, einen Schlüssel post_id und einen auf 191 Zeichen gekürzten Schlüssel meta_key, weil utf8mb4 vier Bytes pro Zeichen verwendet und das historische Indexlimit bei 767 Bytes lag. Einen zusammengesetzten Index auf (post_id, meta_key) gibt es nicht. Eine Abfrage, die nach beiden Spalten filtert, und genau das tut ein Archiv-Template mit viel Meta in jeder Zeile, kann nicht einen einzigen Index für beide nutzen. Auf einer großen Website ist die Lösung ein zusammengesetzter Index, per Migration hinzugefügt, nicht eine weitere Cache-Schicht obendrauf.

Zwei weitere Prüfungen gehören in denselben Durchgang. Stellen Sie sicher, dass alle Tabellen InnoDB sind, denn eine MyISAM-Tabelle, geerbt aus einem Import aus der Zeit von MySQL 5.1, sperrt beim Schreiben und ignoriert Transaktionen. Und stellen Sie sicher, dass der Zeichensatz utf8mb4 ist: Der Core wählt in determine_charset() utf8mb4_unicode_520_ci, wenn der Server es unterstützt, aber eine Datenbank, die vor WordPress 4.2 angelegt und mit mysqldump migriert wurde, bleibt bei utf8 und verliert weiterhin stillschweigend Zeichen außerhalb der Basic Multilingual Plane.

#4. Wie man CSS und JavaScript in einem alten Theme modernisiert

Das Frontend eines alten WordPress ist selten wegen des verwendeten Frameworks langsam. Es ist langsam, weil nichts im Theme weiß, was der Rest einreiht.

#Eine monolithische style.css in Module aufteilen

Ein altes Theme mit einer einzigen, von Hand bearbeiteten style.css und ohne Bundler kann keine eng begrenzte Änderung ausliefern. Ob am Ende Tailwind, CSS Modules oder Custom Properties stehen, ist viel weniger wichtig, als die Frage “welche Selektoren braucht dieses Template” beantworten zu können. Eine Struktur, die das erlaubt, sieht etwa so aus:

styles/
├── critical.css (inline im <head>)
├── components/
│   ├── header.css (auf allen Seiten)
│   ├── blog.css (nur auf Blogseiten)
│   └── product.css (nur auf Produktseiten)
└── utilities.css (gemeinsame Utility-Klassen)

Sobald es einen Build gibt, wird das Laden der Assets pro Template möglich, und genau dieses Laden pro Template verbessert den Rendering-Pfad, nicht die Wahl des Frameworks.

#Skripte mit defer und async in WordPress laden

Nutzen Sie die Ladestrategie, die der Core schon mitbringt. Seit WordPress 6.3 akzeptiert wp_enqueue_script() im letzten Parameter ein Array:

wp_enqueue_script(
	'site-main',
	get_theme_file_uri( 'build/main.js' ),
	array(),
	filemtime( get_theme_file_path( 'build/main.js' ) ),
	array(
		'strategy'  => 'defer',
		'in_footer' => true,
	)
);

Die Falle ist in der Entwicklernotiz zu 6.3 dokumentiert und in WP_Scripts::filter_eligible_strategies() umgesetzt: Der Core durchläuft den Abhängigkeitsbaum, und wenn ein eingereihtes Skript, das von Ihrem abhängt, nicht ebenfalls verzögert geladen wird, wird Ihres blockierend ausgegeben. Sie können defer auf einen Handle setzen, im HTML kein defer-Attribut sehen und nichts im Log finden. Der Core schreibt data-wp-strategy in den Tag, sobald eine verzögerte Strategie registriert wurde, egal ob sie herabgestuft wurde oder nicht, also liefert die Suche nur nach diesem Attribut alle verzögerten Skripte. Das Signal für die Herabstufung ist ein Tag mit data-wp-strategy ohne das passende defer oder async. Ein einziges altes Plugin, das ein blockierendes Skript mit Abhängigkeit von Ihrem Bundle einreiht, genügt, um die ganze Änderung auszuhebeln.

Dieselbe Datei lehnt außerdem eine Strategie auf einem Alias-Handle ab, weshalb wp_script_add_data( 'jquery', 'strategy', 'defer' ) nichts Nützliches bewirkt: jquery hat kein src.

#jQuery aus einem alten Theme entfernen

Der Prozess verläuft schrittweise und stützt sich auf das Inventar aus Abschnitt 1:

1. Die eingereihten Handles mit wp_scripts()->queue auflisten und das Core-jQuery von den doppelten Kopien trennen.
2. Ermitteln, welche Plugins vom Handle jquery abhängen.
3. jquery-migrate aus der Warteschlange nehmen und die Konsolenfehler als Arbeitsliste behandeln.
4. Einfache Funktionen durch natives JavaScript ersetzen.
5. Die Abhängigkeit entfernen, sobald nichts mehr sie anfordert.

#5. Wie man ein altes WordPress absichert

Legacy-Code ist nicht unsicher, weil er alt ist. Er ist unsicher, weil die Angriffsflächen, die er bietet, zu einer Zeit konfiguriert wurden, als andere Standardwerte galten.

#Werkzeuge für Sicherheitsscans in WordPress

Eine geplante Checksum-Prüfung, ein Deprecation-Log und Warnungen zur Dateiintegrität sind mehr wert als ein Scanner, der eine Schweregrad-Punktzahl ausgibt. Die üblichen Werkzeuge für den Rest des Durchgangs sind PHPStan für die statische Analyse von PHP, npm audit für JavaScript-Abhängigkeiten und WPScan für bereits veröffentlichte Schwachstellen.

#Die WordPress-REST-API einschränken

Die REST-API lässt sich nicht abschalten, und Snippets, die das behaupten, sind schlimmer, als gar nichts anzufassen: Der Core nutzt sie für den Block-Editor, Site Health und die Anwendungspasswörter. Was Sie tun können, ist eine Authentifizierung für alles zu verlangen, was nicht ausdrücklich öffentlich ist:

add_filter(
	'rest_authentication_errors',
	static function ( $result ) {
		if ( ! empty( $result ) || is_user_logged_in() ) {
			return $result;
		}

		return new WP_Error(
			'rest_not_logged_in',
			__( 'Der Zugriff auf die REST-API erfordert eine Authentifizierung.' ),
			array( 'status' => 401 )
		);
	}
);

Testen Sie danach ohne Anmeldung die Teile der Website, die von der API abhängen: Kommentarformulare, Suchblöcke, Kontaktformulare auf REST-Endpoints und jeden Headless-Client. Auf einer Marketing-Website eines Unternehmens ist dieser Filter meist harmlos. Auf einer Website mit einer interaktiven Funktion für anonyme Besucher macht er diese kaputt, und das finden Sie besser auf Staging heraus.

Wissen Sie, was bereits eingeschränkt ist, bevor Sie Regeln hinzufügen. Der Users-Endpoint ist ein wiederkehrender Schreck, aber WP_REST_Users_Controller wendet has_published_posts bei Collection-Anfragen an, sobald der Aufrufer current_user_can( 'list_users' ) nicht besteht, und das deckt sowohl nicht angemeldete Besucher als auch Konten mit wenigen Rechten ab. Die berücksichtigten Inhaltstypen sind get_post_types( array( 'show_in_rest' => true ) ), nicht die öffentlichen, und die beiden Listen sind nicht identisch. Der Endpoint liefert also Autoren, die in einem per REST freigegebenen Typ veröffentlicht haben, nicht alle Konten. Die Enumeration von Autoren auf einer Unternehmenswebsite läuft meist über die Weiterleitungen von /?author=1 und über Autorenarchive, nicht über REST.

Anwendungspasswörter funktionieren außerdem nur über HTTPS: wp_is_application_passwords_supported() gibt is_ssl() || 'local' === wp_get_environment_type() zurück. Eine alte Website, die das Backend noch mit gemischten Inhalten über reines HTTP ausliefert, bietet sie nicht an, und deshalb teilen Integrationen auf solchen Websites am Ende das echte Passwort eines Administrators. Das Zertifikat zu reparieren ist die Sicherheitskorrektur, das Anwendungspasswort folgt daraus.

#Die Abhängigkeiten eines alten WordPress aktualisieren

Jede Drittanbieter-Bibliothek wird aktualisiert oder ersetzt:

• PHP-Bibliotheken mit veröffentlichten Schwachstellen
• JavaScript-Komponenten mit aktiven CVEs
• Schriften und Assets, die von Drittanbieter-CDNs geladen werden
• Integrationen gegen bereits abgeschaltete APIs

Erstellen Sie gleichzeitig das Plugin-Inventar, denn jedes Plugin, das Sie entfernen, ist eine Angriffsfläche, die Sie nicht mehr pflegen müssen.

#6. Wie man von einem klassischen Theme auf Gutenberg migriert

#Kompatibilität von altem Theme und Gutenberg

Bei Themes, die zwischen 2015 und 2018 gebaut wurden, wird die Unterstützung schrittweise aktiviert. add_theme_support( 'block-templates' ) ist der Schalter, der die Migration Template für Template aus Abschnitt 2 eröffnet; der Rest sind Einstellungen für den Editor:

add_action('after_setup_theme', function() {
    // Grundlegende Block-Unterstützung
    add_theme_support('wp-block-styles');
    add_theme_support('align-wide');
    add_theme_support('responsive-embeds');

    // Farbpalette des alten Themes
    add_theme_support('editor-color-palette', [
        ['name' => 'Primär', 'slug' => 'primary', 'color' => '#1a1a2e'],
        ['name' => 'Sekundär', 'slug' => 'secondary', 'color' => '#16213e'],
    ]);
});

Das Schema von theme.json ist bei Version 3. Eine Version 4 gibt es nicht, also führt jedes Beispiel, das sie deklariert, dazu, dass der Core die Datei ignoriert.

#Von Elementor oder Divi auf Gutenberg migrieren

Die Migration von Elementor, Divi oder Visual Composer auf Gutenberg folgt einem strukturierten Ablauf:

1. Inventar: jede Seite und ihren aktuellen Builder dokumentieren
2. Priorisierung: mit den Seiten mit dem meisten Traffic beginnen
3. Umsetzung: die Layouts mit Block-Patterns nachbauen
4. Prüfung: visuell und funktional vergleichen
5. Freischaltung: Seite für Seite umstellen, mit Test-Weiterleitungen
6. Aufräumen: den alten Page Builder deaktivieren, wenn alle Seiten migriert sind

Prüfen Sie die Builder-Version gegen die Plugin-API von wordpress.org (api.wordpress.org/plugins/info/1.0/elementor.json für Elementor, die mit Stand 12. Oktober 2026 die 4.3.4 als stabil ausweist) und nicht gegen die readme.txt im Repository, die hinterherhinkt.

#7. Wie man den Erfolg einer WordPress-Modernisierung misst

Versprechen Sie keine Prozentsätze, bevor Sie gemessen haben. Was sich vor dem Start festlegen lässt, ist das Instrument, mit dem jede Größe geprüft wird, und der Ausgangswert der Website im heutigen Zustand.

Auf der geschäftlichen Seite ist die einzige ehrliche Zahl vor dem Start die, die Sie bereits haben: aktueller organischer Traffic, Conversion und Wartungskosten. Verglichen wird danach, gegen genau diese Ausgangsbasis und mit einem vorab festgelegten Messfenster.

#8. Audit und Modernisierung von WordPress mit WPPoland

Bei WPPoland übernehmen wir die Rettung von WordPress-Websites, und zwar immer in dieser Reihenfolge.

1. Due Diligence und Audits: Wir liefern das technische Inventar aus Abschnitt 1, mit Prioritäten und den geschätzten Kosten jedes Eingriffs.

2. Inkrementelle Rollouts: Wir modernisieren in Etappen, jede mit eigenem Abnahmekriterium und eigenem Weg zurück.

3. Gemessene, nicht versprochene Ziele: Bevor wir den Code anfassen, vereinbaren wir, welche Kennzahl sich bewegen soll, mit welchem Instrument sie gemessen wird und in welchem Zeitfenster. Was sich nicht messen lässt, gehört nicht zum Umfang.

4. Wissenstransfer: Wir dokumentieren den Prozess und schulen Ihr Team, damit es den modernisierten Code selbst pflegen kann.

#9. Womit man bei der Modernisierung eines alten WordPress anfängt

Eine alte WordPress-Website ist nicht automatisch eine Last. Zur Last werden technische Schulden, die niemand verwaltet, und der Unterschied zwischen beiden Fällen liegt darin, ob jemand sagen kann, was eine Änderung kostet, bevor sie gemacht wird.

Die Reihenfolge in diesem Leitfaden ist bewusst gewählt. Messen Sie den PHP-Abstand an den Daten von php.net, sammeln Sie Deprecations aus echtem Traffic mit den Hooks, die der Core ohnehin feuert, prüfen Sie die Dateien gegen die Checksums und lösen Sie danach die Templates Route für Route mit template_include oder block-templates ab. Reparieren Sie Autoload und die Postmeta-Indizes, denn sie stecken in jedem Request. Reparieren Sie das Laden der Skripte, denn der Core gibt Ihnen den Mechanismus, und alte Plugins nehmen ihn Ihnen stillschweigend wieder weg. Alles andere ist Geschmackssache, solange das nicht erledigt ist.

Läuft die Website noch auf einem Stack von 2018, ist das erste Ergebnis kein Code. Es ist ein Dokument: PHP-Version, Deprecation-Log, fehlgeschlagene Checksums, Plugin-Liste mit Verantwortlichen und die Templates, die den Traffic tragen.

Steckt Ihre Firmenwebsite im Jahr 2018 fest? Schreiben Sie WPPoland für ein Audit und beginnen Sie mit dem Inventar, nicht mit der Neuentwicklung.

Eine Codebasis aus dem Jahr 2018 lässt sich nicht in einem Sprint retten, sie braucht eine Reihenfolge: Audit, Absicherung, dann Umbau. Genau diese Reihenfolge halten wir in unserer Arbeit an bestehenden WordPress-Installationen ein.

#Weiterführende Ressourcen

• Professionelle WordPress-Entwicklung: Modernisierung für Unternehmen
• WordPress-Geschwindigkeitsoptimierung: Performance nach der Modernisierung
• WordPress-Sicherheitsaudit: Sicherheit für Legacy-Code
• WordPress-Redesign: vollständige visuelle Modernisierung
• Migration zu Astro und Next.js: moderne Architekturen nach dem Refactoring