PHP-Version aktualisieren: so schützt du Kunden

Der Anruf kommt an einem Dienstagmorgen, kurz nach neun: „Meine Website ist weg, da steht nur noch irgendwas mit ‚critical error'." Du schaust nach, und tatsächlich – wo gestern noch die Seite des Kunden stand, klafft eine weiße Fehlermeldung. Der Grund liegt nicht bei dir und nicht bei einem Angreifer: Der Hoster hat über Nacht den Server von PHP 7.4 auf eine neuere Version umgestellt, angekündigt in einer Mail drei Wochen zuvor, die niemand gelesen hat. Ein betagtes Plugin kommt mit der neuen Version nicht zurecht, und der ganze Auftritt liegt lahm.

Solche Vormittage sind vermeidbar – aber nur, wenn du die PHP-Version deiner Kundenseiten aktiv im Blick hast, statt zu warten, bis Hoster oder Angreifer die Entscheidung für dich treffen. Dieser Beitrag erklärt, warum die Frage 2026 dringlicher ist als je zuvor, wie viele Seiten tatsächlich auf veralteten Versionen laufen und wie du die Umstellung sauber hinbekommst, ohne einen einzigen Kunden-Auftritt zu zerschießen.

Warum du die PHP-Version aktualisieren musst

PHP ist das unsichtbare Fundament des Webs. Die Skriptsprache läuft auf rund drei Vierteln aller Websites, deren serverseitige Technik überhaupt bekannt ist – und WordPress, das allein etwa 43 Prozent des gesamten Webs antreibt, ist komplett in PHP geschrieben. Jede WordPress-, WooCommerce-, TYPO3- oder Laravel-Seite, die du betreust, steht auf dieser Basis. Und diese Basis hat ein Verfallsdatum.

Jede PHP-Version durchläuft einen festen Lebenszyklus: Nach dem Erscheinen gibt es rund zwei Jahre aktive Weiterentwicklung mit Fehlerbehebungen, danach ein weiteres Jahr, in dem nur noch sicherheitskritische Lücken gestopft werden. Ist auch dieses Jahr vorbei, erreicht die Version ihr „End of Life" (EOL) – und ab da fließen gar keine Updates mehr, auch keine Sicherheits-Patches. Der Fahrplan der offiziellen PHP-Dokumentation ist eindeutig: PHP 7.4 bekommt bereits seit November 2022 keine Sicherheitsupdates mehr. PHP 8.1 ist am 31. Dezember 2025 aus dem Support gefallen und damit seit Jahresbeginn ungeschützt. PHP 8.2 folgt zum Ende dieses Jahres, am 31. Dezember 2026. PHP 8.3 läuft bis Ende 2027, PHP 8.4 bis Ende 2028.

Was „End of Life" wirklich bedeutet

Der Begriff klingt harmloser, als er ist. Eine PHP-Version, die ihr Lebensende erreicht hat, funktioniert zunächst weiter – die Seite ist ja nicht plötzlich kaputt. Genau das ist die Falle. Denn wird nach dem EOL eine neue Sicherheitslücke im PHP-Kern bekannt, wird sie für diese Version nicht mehr geschlossen. Sie bleibt offen, dauerhaft, und jeder Angreifer, der die Lücke kennt, kann sie auf jeder Seite ausnutzen, die noch auf der alten Version läuft. Für eine Kundenseite, die Kontaktdaten verarbeitet oder gar einen Shop mit Zahlungen betreibt, ist das kein theoretisches Risiko, sondern eine offene Flanke.

Wie viele Kundenseiten wirklich betroffen sind

Man könnte meinen, veraltete PHP-Versionen seien ein Randproblem von vernachlässigten Alt-Projekten. Die Zahlen sagen etwas anderes. Der Analyse-Dienst Metorik hat Anfang März 2026 die Technik von über 6.000 WooCommerce-Shops ausgewertet. Das Ergebnis: Rund 12 Prozent der Shops liefen noch auf PHP 7.4 – einer Version, die zu diesem Zeitpunkt über drei Jahre ohne Sicherheitsupdates war. Weitere 18 Prozent liefen auf PHP 8.1, das seit dem Jahreswechsel ebenfalls aus dem Support ist. Zusammengerechnet stand also fast ein Drittel dieser Online-Shops auf einer PHP-Version, die keine Sicherheits-Patches mehr erhält – und das bei Seiten, die Bestellungen und Zahlungsdaten abwickeln.

Ein weit verbreiteter Irrtum verschärft das Problem: Viele verlassen sich darauf, dass ihr System schon meckern würde, wenn etwas nicht passt. WordPress läuft technisch aber noch ab PHP 7.4 – und genau diese Version ist eben längst am Ende ihres Lebenszyklus. Die offizielle Mindestanforderung zu erfüllen heißt also gerade nicht, auf einer sicheren Version zu sein. „Läuft noch" und „wird noch gepflegt" sind zwei völlig verschiedene Dinge. Wer das nicht auseinanderhält, hält eine Seite für in Ordnung, die es nicht ist.

Sicherheit und Performance: die zwei Argumente für Kunden

Wenn du einem Kunden erklären willst, warum eine PHP-Aktualisierung Geld und einen Wartungstermin wert ist, hast du zwei starke Argumente – eines defensiv, eines offensiv.

Das defensive ist die Sicherheit. Eine veraltete PHP-Version reiht sich nahtlos in die üblichen Einfallstore ein. Die allermeisten erfolgreichen Angriffe auf WordPress-Seiten laufen ohnehin nicht über den Kern, sondern über veraltete Erweiterungen – ein Zusammenhang, den wir im Beitrag zur WordPress-Wartung als Agentur-Standbein ausführlich beleuchtet haben. Eine ungepatchte PHP-Version ist dieselbe Art von Nachlässigkeit, nur eine Ebene tiefer: Sie betrifft nicht ein einzelnes Plugin, sondern das Fundament, auf dem alles läuft.

Das offensive Argument ist die Geschwindigkeit. Jede neue PHP-Generation ist spürbar schneller als ihre Vorgänger; die Sprünge von PHP 7 zu PHP 8 und weiter zu den 8.x-Versionen haben die Zahl der Anfragen, die ein Server pro Sekunde verarbeiten kann, in Benchmarks für WordPress deutlich erhöht. Eine schnellere Seite kostet weniger Serverleistung, hält bei Lastspitzen besser durch und zahlt direkt auf die Core Web Vitals ein, die über die Sichtbarkeit in der Google-Suche mitentscheiden. Ein PHP-Update ist damit eine der wenigen Maßnahmen, die gleichzeitig Sicherheit und Ladezeit verbessern – und beides lässt sich dem Kunden zeigen.

So aktualisierst du, ohne die Seite zu zerschießen

Der weiße Bildschirm aus dem Eingangsbeispiel entsteht nie durch das Update selbst, sondern durch mangelnde Vorbereitung. Mit einem geordneten Vorgehen ist die Umstellung Routine.

Am Anfang steht, wie so oft, kein technischer Schritt, sondern Übersicht. Lege für jeden Kunden fest, welche PHP-Version aktuell läuft, wann sie das Lebensende erreicht und wo die Seite gehostet ist. Ohne dieses Inventar ist jede Aktualisierung Stückwerk – und genau die vergessene Alt-Subdomain wird später zum Problem, ähnlich wie bei den kürzeren SSL-Zertifikaten, wo ebenfalls gilt: Was du nicht kennst, pflegst du nicht.

Der zweite Schritt ist die Kompatibilitätsprüfung. Prüfe vor jeder Umstellung, ob Theme und alle Plugins mit der Zielversion zurechtkommen. Werkzeuge, die den Code auf veraltete PHP-Funktionen durchsuchen, decken die meisten Stolpersteine im Voraus auf. Das Ergebnis dieser Prüfung entscheidet, ob ein Update ein Fünf-Minuten-Klick ist oder ob vorher ein hakeliges Plugin ersetzt werden muss.

Danach kommt der eigentliche Test – aber niemals live. Richte eine Staging-Umgebung ein, eine identische Kopie der Seite, und erhöhe dort die PHP-Version zuerst. Erst wenn dort alles läuft, Formulare abschicken, der Shop durch den Checkout führt und keine Fehler im Log auftauchen, überträgst du die Änderung auf die Live-Seite. Und bevor du das tust, gehört ein frisches, getestetes Backup dazu, damit du im Ernstfall in Minuten zurückkannst. Wer diese Reihenfolge einhält – Inventar, Kompatibilität, Staging, Backup, Live –, wird von einem PHP-Update nicht mehr überrascht.

Aus der Pflicht ein Agentur-Standbein machen

Der eigentliche Hebel liegt aber nicht in der einzelnen Umstellung, sondern darin, sie nicht mehr reaktiv zu erledigen. Solange du erst dann tätig wirst, wenn der Hoster eine Zwangsumstellung ankündigt oder die Seite schon weiß ist, bleibst du Feuerwehr – schlecht bezahlt und unter Zeitdruck. Machst du das PHP-Management dagegen zum festen Bestandteil eines Wartungsvertrags, drehst du das Verhältnis um: Du überwachst die Lebenszyklen, planst die Updates in ruhigen Phasen und stellst um, bevor überhaupt etwas passiert.

Für den Kunden ist das ein klares Versprechen – seine Seite bleibt sicher und schnell, ohne dass er sich um Versionsnummern kümmern muss. Für dich ist es planbarer, wiederkehrender Umsatz statt hektischer Notfalleinsätze. Und weil der PHP-Lebenszyklus jedes Jahr aufs Neue zuschlägt – Ende 2026 fällt PHP 8.2, Ende 2027 PHP 8.3 –, ist es ein Standbein, das sich nicht abnutzt. Aus dem gefürchteten Dienstagmorgen-Anruf wird so ein Termin, den du selbst bestimmst.