WordPress lange nicht aktualisiert: So holen Sie den Rückstand kontrolliert auf
Wenn Ihre WordPress-Website seit Monaten oder Jahren kein Update gesehen hat, passen alter Systemkern, Erweiterungen und aktuelle PHP-Versionen auf dem Server nicht mehr direkt zusammen. Hier erfahren Sie Schritt für Schritt, wie Sie den Rückstand über kompatible Zwischenschritte sicher aufholen.
Warum dürfen Sie bei veralteten WordPress-Websites nicht einfach auf „Alle aktualisieren“ klicken?
Wenn Sie WordPress lange nicht aktualisiert haben, darf der erste Schritt niemals der Klick auf „Alle aktualisieren“ im Live-Betrieb sein. Weil der Kern, Ihre Erweiterungen und die PHP-Version auf dem Server voneinander abhängen, führt ein unvorbereitetes Sammel-Update zu abgebrochenen Datenbank-Anpassungen oder einer weißen Seite. Prüfen Sie deshalb zuerst Ihren Versionsstand und sichern Sie Dateien sowie Datenbank extern.
Sobald eine Installation mehrere Jahre stillstand, klafft eine doppelte Versionsschere zwischen Ihrem System und dem aktuellen Stand (WordPress 7.1 mit Wartungsrelease 7.1.3 vom 6. Oktober 2026). Neue Hauptversionen bauen das Datenbank-Schema um, während sich auf dem Server die Skriptsprache PHP weiterentwickelt hat. Deshalb warnt das offizielle WordPress-Upgrade-Handbuch davor, mehr als zwei Hauptversionen auf einmal zu überspringen, und rät zu Zwischenschritten. Ein Direkt-Update überfordert das System.
Wer im Backend trotzdem alle Haken gleichzeitig setzt, bringt diese Abhängigkeiten gegeneinander auf. Entweder verlangen die neuen Plugins bereits eine PHP-Version, unter der Ihr alter WordPress-Kern noch nicht startet, oder der Server bricht den Dateiaustausch wegen einer Zeitüberschreitung ab. Dann streikt die gesamte Website. Sie erreichen danach weder das Frontend noch den Administrationsbereich.
„Wer eine Website zurückholt, die länger niemand gepflegt hat, prüft nach dem Zugang als Erstes, ob das System noch Sicherheitsupdates bekommt. Davon hängt ab, ob Weiterbetrieb oder Neuaufbau der nächste Schritt ist.“
— Sascha Fix
Für diese Sicherheitsupdates gilt bei alten Installationen eine feste Grenze. WordPress pflegt aktiv nur den neuesten Hauptzweig, während das Sicherheitsteam Korrekturen für ältere Zweige freiwillig nachpflegt. Im Juli 2025 endete diese Versorgung für WordPress 4.1 bis 4.6 endgültig, sodass am 6. Oktober 2026 nur noch Zweige ab WordPress 4.7 ein Sicherheitsupdate erhielten. Gleichzeitig suchen Angreifer automatisiert nach bekannten Lücken in Plugins, Themes und Server-Software. Wer Updates aufschiebt, lässt Türen offen.
Welche Vorbereitungen müssen Sie vor dem ersten Update-Schritt treffen?
Vor dem ersten Eingriff legen Sie ein vollständiges Backup außerhalb Ihres Webspace an, indem Sie zuerst die Datenbank exportieren und anschließend sämtliche Dateien sichern. Danach lesen Sie im Backend unter „Werkzeuge“ und „Website-Zustand“ die eingesetzte Version von WordPress, PHP sowie der Datenbank aus und richten für größere Versionssprünge eine getrennte Staging-Umgebung ein.
Ein belastbares Backup ist Ihr wichtigstes Sicherheitsnetz, weil ein Rückschritt nach einer Datenbank-Anpassung ohne Sicherung laut WordPress-Handbuch nahezu unmöglich ist. Verlassen Sie sich dabei nicht allein auf die Automatik Ihres Hosters, sondern speichern Sie eine eigene Kopie auf Ihrem Computer oder in einem getrennten Cloud-Speicher. Ich spiele niemals ein Update ohne frisches externes Backup ein und prüfe vorab, ob sich die Sicherung zurückspielen lässt.
Zu einer vollständigen Sicherung gehören laut offizieller Backup-Dokumentation immer zwei Teile: Ihre Datenbank und sämtliche WordPress-Dateien. Dabei zählt die richtige Reihenfolge. Exportieren Sie zuerst die Datenbank und laden Sie direkt danach die Dateien per FTP oder SFTP (Secure File Transfer Protocol) herunter, damit beide Stände zusammenpassen. Aktivieren Sie im FTP-Programm unbedingt die Anzeige versteckter Dateien, weil sonst die .htaccess fehlt.
Sichern Sie neben dem Ordner wp-content und der wp-config.php auch Ihr aktives Theme und prüfen Sie, ob frühere Anpassungen direkt im Original-Theme statt in einem Child-Theme liegen. Sonst überschreibt ein Update Ihr Design. Alle Einzelschritte erkläre ich in meiner Anleitung zum WordPress-Backup erstellen.
Lesen Sie anschließend unter „Werkzeuge → Website-Zustand → Bericht“ (ab WordPress 5.2) oder im Kundenmenü Ihres Hosting-Anbieters die Versionen von WordPress, PHP und Datenbank aus. Für den aktuellen Betrieb empfiehlt WordPress PHP 8.3+ sowie MariaDB 10.11+ oder MySQL 8.0+; das technische Minimum liegt bei PHP 7.4. Löschen Sie nicht mehr benötigte Plugins komplett und kontrollieren Sie per SFTP den Ordner wp-content/mu-plugins, da Sie Must-Use-Plugins dort nur deaktivieren, indem Sie die Datei entfernen. Ab mehr als zwei Hauptversionen Rückstand arbeiten Sie immer in einer Staging-Kopie. Dort testen Sie das Update, ohne Ihre Live-Website zu gefährden.
In welcher Reihenfolge aktualisieren Sie Core, Plugins und PHP-Version?
Bei wenigen Monaten Rückstand aktualisieren Sie nach dem Backup zuerst Ihre Plugins, danach das Theme und zuletzt den WordPress-Kern. Liegt Ihre Website jedoch mehr als zwei Hauptversionen zurück, heben Sie WordPress und die Erweiterungen zunächst schrittweise auf eine kompatible Brückenversion an, stellen erst dann PHP beim Hoster um und ziehen anschließend auf die aktuelle Version nach.
Bei jahrelangem Rückstand funktioniert die gewohnte Reihenfolge („erst Plugins, dann WordPress, dann PHP“) nicht mehr. Denn aktuelle Plugins verlangen bereits ein neueres WordPress und PHP 8.1+, während ein altes WordPress 5.2 laut der offiziellen Kompatibilitätsübersicht von WordPress nur bis PHP 7.3 startet. Wenn Sie beim Hoster vorschnell auf PHP 8.4 umschalten, bricht die Seite sofort ab. Diesen Konflikt lösen Sie nur über eine Brückenversion:
Ausgangsversionen und Ziel-Kompatibilität prüfen
Lesen Sie Ihre WordPress- und PHP-Version aus und prüfen Sie in der Tabelle unten, bis zu welcher Zwischenversion Ihre jetzige PHP-Version unterstützt wird. Stellen Sie Backup und Staging-Kopie bereit.
Ungepflegte Plugins vorab deaktivieren oder ersetzen
Prüfen Sie alle Erweiterungen vorab auf Kompatibilität. Für ein manuelles Upgrade über mehrere Hauptversionen empfiehlt das WordPress-Handbuch, zunächst alle Plugins zu deaktivieren, damit nichts die Datenbank-Aktualisierung blockiert.
WordPress-Kern über kompatible Zwischenschritte anheben
Überspringen Sie höchstens zwei Hauptversionen auf einmal und heben Sie den Kern über das Release-Archiv bis zur Brückenversion (etwa WordPress 6.2) an. Nach jedem Schritt rufen Sie
/wp-admin/upgrade.phpauf, sichern ein Zwischen-Backup und ziehen kompatible Plugins einzeln nach.PHP-Version beim Hoster auf die Brückenversion oder Zielversion umstellen
Sobald WordPress und die aktiven Erweiterungen die Brückenversion erreicht haben, stellen Sie im Hosting-Menü auf eine neuere PHP-Version wie PHP 8.2 um. Prüfen Sie danach Frontend und Backend.
Zielversion fertigstellen, Funktionen testen und Backup sichern
Aktualisieren Sie WordPress und alle Plugins auf den aktuellen Zweig WordPress 7.1 und heben Sie PHP auf Version 8.4 oder 8.5 an. Nach dem Test aller Formulare schalten Sie die Kopie live und sichern ein Abschluss-Backup.
Kompatibilitätsbrücke: Welche WordPress- und PHP-Versionen zusammenpassen
Die folgende Übersicht zeigt anhand der offiziellen WordPress- und PHP-Daten (Stand Oktober 2026), welche Zweige zusammenarbeiten und wo die Brücke für den PHP-Wechsel liegt:
| Ausgangsversion | Unterstützte PHP-Versionen | Empfohlene Zwischenetappe | Nächster Schritt bis WordPress 7.1 |
|---|---|---|---|
| WordPress 4.7 bis 4.9 | PHP 5.2 bis 7.1 (bei 4.9 bis 7.2) | Unter PHP 7.1 oder 7.2 schrittweise auf WordPress 5.0 und 5.3 | PHP auf 7.4 anheben, weiter auf WordPress 6.2, danach PHP 8.2+ |
| WordPress 5.0 bis 5.2 | PHP 5.2/5.6 bis 7.3 | Unter PHP 7.3 auf WordPress 5.3 bis 5.5, dann 6.2 | Unter WordPress 6.2 auf PHP 8.2 wechseln, dann weiter über 6.6 auf 7.1 |
| WordPress 5.3 bis 5.5 | PHP 5.6 bis 7.4 (kein PHP 8.0) | Unter PHP 7.4 über WordPress 5.8 auf WordPress 6.2 | Unter WordPress 6.2 auf PHP 8.2 wechseln, danach über 6.6 auf 7.1 |
| WordPress 5.6 bis 6.0 | PHP 5.6 bis 8.0 (ab 5.9 bis 8.1) | Direkt auf die Brückenversion WordPress 6.2 | Auf PHP 8.2 oder 8.3 (ab WP 6.4) umstellen und bis 7.1 aktualisieren |
| WordPress 6.1 bis 6.2 | PHP 5.6 bis 8.2 | Bereits auf der zentralen Brückenversion | PHP auf 8.2 umstellen, auf WordPress 6.8 heben, dann PHP 8.4 und 7.1 |
| WordPress 6.4 bis 6.6 | PHP 7.0/7.2 bis 8.3 | Unter PHP 8.3 auf WordPress 6.8 | PHP auf 8.4 oder 8.5 (ab WP 6.9) anheben und auf WordPress 7.1 ziehen |
| WordPress 6.7 bis 7.1 | PHP 7.2 bis 8.4/8.5 (ab 7.0 mindestens PHP 7.4) | Direktes Update im Backend nach Backup | Auf WordPress 7.1.3 aktualisieren und PHP 8.4 oder 8.5 nutzen |
Weil das Backend per Klick nur den Sprung auf die neueste Version anbietet, laden Sie benötigte Zwischenversionen aus dem WordPress-Release-Archiv herunter und spielen sie manuell per SFTP ein. Was darf beim Austausch auf dem Server weg? Entfernen Sie nur die alten Ordner wp-includes und wp-admin, aber niemals wp-config.php, Ihre .htaccess, robots.txt oder den Ordner wp-content (Ausnahme laut Handbuch: wp-content/cache). Laden Sie anschließend die neuen Kerndateien hoch und rufen Sie im Browser /wp-admin/upgrade.php auf.
Danach aktivieren und aktualisieren Sie Ihre Plugins einzeln nacheinander. Große Erweiterungen wie WooCommerce oder Page Builder aktualisiere ich grundsätzlich manuell mit einem frischen Backup direkt davor.
Für den anschließenden PHP-Wechsel gibt die offizielle Übersicht unterstützter PHP-Versionen den zeitlichen Rahmen vor. Da der Sicherheits-Support für PHP 8.1 am 31. Dezember 2025 geendet hat und für PHP 8.2 am 31. Dezember 2026 ausläuft, gehe ich beim Umstieg gleich auf PHP 8.4 (Sicherheitsupdates bis 31. Dezember 2028) oder PHP 8.5 (bis 31. Dezember 2029) und nutze PHP 8.3 (bis 31. Dezember 2027) nur als Zwischenschritt, falls ein benötigtes Plugin PHP 8.4 noch nicht verträgt. Wie Sie die Einstellung im Kundenmenü ändern, zeige ich im Beitrag zum WordPress-PHP-Version aktualisieren.
Was tun Sie, wenn ein Plugin nicht mehr gepflegt wird oder Fehler wirft?
Wenn ein Plugin seit mehreren Hauptversionen kein Update mehr erhalten hat oder im offiziellen Verzeichnis geschlossen wurde, sollten Sie es vor dem Wechsel auf eine neue PHP-Version ablösen. Da ungepflegte Erweiterungen das größte Einfallstor für Angriffe bilden und unter aktuellem PHP fatale Fehler auslösen, ersetzen Sie diese Bausteine durch aktiv gewartete Alternativen oder native Funktionen des Block-Editors.
Ob ein Entwickler seine Erweiterung noch pflegt, sehen Sie im offiziellen Verzeichnis unter wordpress.org/plugins/. Hat er das Plugin über das Feld Tested Up To nicht mit den drei neuesten Hauptversionen von WordPress getestet, blendet das Verzeichnis ein gelbes Warnbanner ein. Ist ein Plugin komplett geschlossen, steht kein Download mehr bereit, und nach 60 Tagen nennt die Seite den Schließungsgrund – etwa ein Sicherheitsproblem oder die Einstellung durch den Autor.
Verwaiste Erweiterungen bremsen den Wechsel auf PHP 8.4 aus und gefährden die gesamte Installation. Im Jahr 2025 lagen laut dem Bericht „State of WordPress Security in 2026“ von Patchstack, einem Sicherheitsanbieter mit eigenen Schutzlösungen, 91 Prozent der 11.334 neu entdeckten Schwachstellen in Plugins. Auf Themes entfielen 9 Prozent und auf den Kern nur 6 Lücken niedriger Tragweite. Für 46 Prozent der veröffentlichten Lücken gab es bei Bekanntgabe keinen Patch.
Angreifer nutzten im selben Berichtszeitraum rund die Hälfte der Schwachstellen mit hoher Tragweite binnen 24 Stunden aus, und von den zehn 2025 am stärksten angegriffenen Lücken waren sechs schon in früheren Jahren veröffentlicht worden. Wie Sie solche Risiken im Alltag abfangen, zeige ich in meinen Ratgebern zu Sicherheitslücken in WordPress-Plugins und zur WordPress-Sicherheit. Für den laufenden Betrieb ab WordPress 5.5 und 5.6 lasse ich automatische Updates daher für kleine Sicherheits-Releases aktiv, während ich große Funktions-Updates manuell nach einem Backup einspiele.
Was tun Sie, wenn die Website nach dem Update weiß bleibt oder Fehler meldet?
Bleibt Ihre Website nach einem Update im Wartungsmodus hängen oder zeigt einen kritischen Fehler, löschen Sie zunächst per Dateizugang die blockierende Datei im Hauptverzeichnis oder nutzen den Wiederherstellungslink aus der Administrator-E-Mail. Wenn ein Plugin den Absturz verursacht, lesen Sie die genaue Ursache über das Fehlerprotokoll aus oder spielen Ihr vorab erstelltes Backup aus Dateien und Datenbank zurück.
Wenn Ihre Seite nach einem abgebrochenen Update dauerhaft „Kurze Zeit nicht verfügbar wegen geplanter Wartungsarbeiten“ meldet, blockiert die temporäre Datei .maintenance im Hauptverzeichnis den Zugriff. Sobald Sie diese Datei per SFTP löschen, lädt die Website wieder normal. Erscheint stattdessen ein kritischer Fehler, sendet WordPress ab Version 5.2 im Recovery-Mode eine E-Mail mit geheimem Zugangslink an den Administrator und pausiert die fehlerhafte Erweiterung. Fehlt die E-Mail, hilft das Fehlerprotokoll.
Dafür tragen Sie in einer Testumgebung kurzzeitig folgende Zeilen für den Debug-Modus in Ihre wp-config.php ein:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
WordPress schreibt PHP-Fehler damit in die Datei wp-content/debug.log, ohne sie Besuchern anzuzeigen. Sobald Sie den dort genannten Plugin-Ordner unter wp-content/plugins/ per SFTP umbenennen, deaktiviert WordPress die Erweiterung sofort. Setzen Sie die Werte in der Konfiguration danach wieder auf false und löschen Sie die Logdatei. Wo Sie zusätzlich die Server-Protokolle Ihres Hosters einsehen, zeige ich im Beitrag WordPress-Error-Logs finden.
Macht ein Update etwas kaputt, setze ich das System auf der Live-Seite immer zuerst auf das Backup direkt vor dem Update zurück, suche die Ursache anschließend in Ruhe in einer Kopie und spiele das Update erst wieder ein, wenn dort alles zuverlässig läuft. Dabei entscheidet die richtige Reihenfolge. Stellen Sie nach einem PHP-Wechsel zuerst beim Hoster die alte PHP-Version wieder her, ersetzen Sie dann die WordPress-Dateien und importieren Sie zuletzt die Datenbank.
Wann können Sie das Update selbst durchführen, und wann ist Unterstützung sinnvoll?
Ein Update in Eigenregie eignet sich, wenn Ihre Website höchstens ein bis zwei Hauptversionen zurückliegt, alle eingesetzten Plugins noch gepflegt werden und Sie ein getestetes Backup besitzen. Sobald jedoch mehrere Jahre Rückstand, eine abgeschaltete PHP-Version, ein geschäftskritischer Online-Shop oder verwaiste Erweiterungen zusammenkommen, schützt eine professionelle Modernisierung in einer abgetrennten Testkopie vor Datenverlust und Ausfallzeiten.
Bevor Sie sich an die Zwischenschritte machen, sollten Sie prüfen, ob die technische Substanz Ihrer Website den Weiterbetrieb trägt. Ich mache das an drei Fragen fest: Bekommt das System noch Sicherheitsupdates, ist die Seite mobil gut bedienbar, und passt die Struktur noch zu Ihrem heutigen Geschäft? Vor einem Neubau prüfe ich außerdem, über welche Seiten Besucher und Anfragen kommen, und empfehle eine Überarbeitung, wenn die Basis trägt.
Entscheidungshilfe: Selbst aktualisieren, modernisieren lassen oder neu bauen
Anhand der folgenden sechs Kriterien ordnen Sie direkt ein, welcher Weg für Ihre Installation passt (alle Preise netto zuzüglich 19 Prozent Umsatzsteuer, Stand Oktober 2026):
| Prüfkriterium | Selbst aktualisieren | Website modernisieren lassen | Altsystem-Ablösung oder Neubau |
|---|---|---|---|
| Versionsrückstand beim WordPress-Kern | Höchstens 1 bis 2 Hauptversionen (ab WordPress 6.7) | Mehrere Hauptversionen Rückstand (z. B. WordPress 4.x oder 5.x auf 7.1) | Eingestelltes Altsystem (z. B. Joomla 3) oder stark verbastelte Eigenbauten |
| Zustand der PHP-Version | Bereits PHP 8.2 oder 8.3 im Einsatz | Veraltetes PHP (z. B. 7.2 bis 8.1) mit Umstieg auf PHP 8.4 oder 8.5 | Alte PHP-Version plus Erweiterungen ohne jeden Nachfolger |
| Plugins und Theme | Alle Erweiterungen werden aktiv gepflegt, Child-Theme vorhanden | Bis zu 5 verwaiste Plugins müssen durch gepflegte Alternativen ersetzt werden | Das gesamte Theme ist nicht mobilfähig oder der Page Builder wurde eingestellt |
| Geschäftskritische Funktionen | Einfache Unternehmensseite ohne komplexe Schnittstellen | Wichtige Kontaktstrecken, mehrstufige Formulare oder Mitgliederbereiche | Komplette Neuausrichtung von Angebot, Struktur und Design gewünscht |
| Technischer Arbeitsablauf | Eigenes Backup anlegen und Updates einzeln durchführen | Kostenlose Bestandsaufnahme, Umbau in abgetrennter Kopie, Freigabe vor Live-Schaltung | Datenübernahme aus eingestellten Erweiterungen oder sauberer Neuaufbau |
| Typischer Kostenrahmen | Eigene Arbeitszeit | PHP-Umstellung: 249 € · Modernisierung: ab 690 € (Website modernisieren) | Altsystem: ab 1.490 € (Website modernisieren) |
Wenn Sie das Update abgeben möchten, übernehme ich die Arbeit über Website modernisieren in fünf festen Schritten, während Ihre Live-Seite dabei unberührt bleibt. Nach einer kostenlosen Bestandsaufnahme zum Festpreis kopiere ich Ihre Website in eine Testumgebung und ziehe WordPress über alle Zwischenversionen nach. Im Paket „Modernisierung“ (ab 690 Euro netto zuzüglich 19 Prozent Umsatzsteuer, Stand Oktober 2026) ersetze ich bis zu fünf verwaiste Plugins, prüfe auf Schadcode und schalte die Seite nach Ihrer Freigabe unter PHP 8.4 oder 8.5 live.
Damit Ihre Website anschließend aktuell bleibt, können Sie die laufende Pflege über meine WordPress-Wartung beauftragen. Die monatlich kündbaren Pakete kosten 39 Euro (Basis), 69 Euro (Plus, mit Austausch verwaister Plugins und vierteljährlichem Wiederherstellungstest) oder 119 Euro im Monat (Shop, jeweils netto zuzüglich 19 Prozent Umsatzsteuer, Stand Oktober 2026). Vor dem Start prüfe ich Ihre Website in einem kostenlosen Erstcheck, und jedes Paket enthält die Bereinigung, falls die Website trotz laufender Wartung gehackt wird. Den Vergleich beider Wege finden Sie unter Modernisieren oder Wartung. So halten Sie Ihre Website technisch aktuell und verringern das Ausfallrisiko.
Häufig gestellte Fragen zu lange nicht aktualisierten WordPress-Websites
Kann ich von WordPress 4.9 oder 5.x direkt auf die aktuelle Version aktualisieren?
Nein, bei einem Rückstand von mehr als zwei Hauptversionen rät das offizielle WordPress-Handbuch von einem direkten Sprung ab. Weil sich zwischen alten Zweigen wie WordPress 4.9 oder 5.x und dem aktuellen Zweig WordPress 7.1 sowohl das Datenbank-Schema als auch die unterstützten PHP-Versionen geändert haben, führen Sie das Upgrade schrittweise über kompatible Zwischenversionen wie WordPress 5.3 und 6.2 durch.
Gehen meine Texte, Bilder oder das Design beim WordPress-Update verloren?
Ihre Seiten, Beiträge und Einstellungen liegen in der Datenbank, während Ihre hochgeladenen Bilder sowie Ihr Theme im Ordner wp-content gespeichert sind. Ein reguläres Update tauscht nur die Systemdateien in wp-admin und wp-includes aus, sodass Ihre Inhalte erhalten bleiben. Wenn Sie jedoch vor Jahren direkte Änderungen am Original-Theme statt in einem Child-Theme vorgenommen haben, überschreibt ein Theme-Update diese Anpassungen.
Aktualisiere ich bei einem großen Rückstand zuerst die Plugins oder zuerst WordPress?
Bei einem geringen Rückstand aktualisieren Sie nach dem Backup zuerst die Plugins und das Theme, bevor Sie den WordPress-Kern nachziehen. Liegt Ihre Installation jedoch mehrere Jahre zurück, verlangen aktuelle Plugin-Versionen bereits ein neueres WordPress und eine neuere PHP-Version. In diesem Fall heben Sie den WordPress-Kern zunächst manuell auf eine kompatible Zwischenversion an und ziehen die Plugins schrittweise nach.
Was mache ich, wenn ein wichtiges Plugin seit Jahren kein Update mehr erhalten hat?
Prüfen Sie im offiziellen WordPress-Plugin-Verzeichnis, ob die Erweiterung das gelbe Warnbanner für drei ungetestete Hauptversionen trägt oder dauerhaft geschlossen wurde. Da 2025 laut Patchstack 91 Prozent aller neuen Sicherheitslücken in Plugins auftraten und für 46 Prozent zum Zeitpunkt der Bekanntgabe kein Patch vorlag, sollten Sie verwaiste Erweiterungen vor dem Live-Gang durch gepflegte Alternativen oder native Block-Funktionen ersetzen.
Wann stelle ich die PHP-Version beim Hoster um – vor oder nach dem WordPress-Update?
Das hängt von Ihrer aktuellen Ausgangsversion ab, weil alte WordPress-Zweige unter neuen PHP-Versionen mit einem fatalen Fehler abbrechen. Läuft Ihre Website noch unter WordPress 5.3 bis 5.5 mit PHP 7.4, aktualisieren Sie zuerst WordPress und Ihre Plugins bis zu einer Brückenversion wie WordPress 6.2. Erst danach schalten Sie beim Hoster auf PHP 8.2 oder höher um und vollenden das Update auf WordPress 7.1.
Was kostet es, eine lange nicht aktualisierte WordPress-Website professionell aktualisieren zu lassen?
Wenn nur Ihre PHP-Version veraltet ist, während WordPress, Theme und Plugins aktuell sind, übernehme ich die PHP-Umstellung inklusive Test in einer Kopie für 249 Euro netto zuzüglich 19 Prozent Umsatzsteuer (Stand Oktober 2026). Liegt WordPress mehrere Hauptversionen zurück, startet die Modernisierung inklusive Austausch von bis zu fünf verwaisten Plugins ab 690 Euro netto zuzüglich 19 Prozent Umsatzsteuer als verbindlicher Festpreis nach einer kostenlosen Bestandsaufnahme (Stand Oktober 2026).
Ihre WordPress-Website liegt mehrere Versionen zurück?
Ich prüfe Ihre Installation kostenlos vorab, nenne Ihnen einen verbindlichen Festpreis und ziehe WordPress, Plugins sowie PHP in einer abgetrennten Kopie sicher nach – ohne Ausfall Ihrer Live-Seite.