PHP2Shell: Warum der HTTP-Statuscode über SEO-Folgeschäden entscheidet

Welchen Statuscode sollte eine Website liefern, die wegen PHP2Shell offline geht?

HTTP 503 (Service Unavailable), am besten mit einem Retry-After-Header und ausgeliefert außerhalb der verwundbaren PHP-Anwendung. Das hat John Mueller von Google am 21. Oktober 2026 auf Bluesky empfohlen, nachdem zahlreiche Betreiber ihre Websites wegen zweier kritischer PHP-Sicherheitslücken vorsorglich vom Netz genommen hatten. Ein 503 sagt dem Googlebot: Die Inhalte gibt es weiterhin, sie sind nur gerade nicht erreichbar.

Neu ist die Regel nicht, Google dokumentiert sie seit Jahren. Neu ist der Anlass: Wenn viele Websites gleichzeitig und unter Zeitdruck abgeschaltet werden, entstehen genau die Fehler, die aus einer notwendigen Sicherheitsmaßnahme einen vermeidbaren SEO-Schaden machen. Dieser Artikel ersetzt keine Sicherheitsprüfung. Er beschreibt, wie eine Abschaltung für Suchmaschinen sauber aussieht.

Was ist bei PHP2Shell passiert?

Am 20. Oktober 2026 kündigte das PHP-Projekt eine kritische Sicherheitsveröffentlichung an. Am 21. Oktober folgte die Sicherheitsmeldung zu zwei Schwachstellen, die unter Umständen eine Ausführung von Schadcode ohne Anmeldung erlauben. Beide sind mit CVSS 9,2 bewertet. In der Fachpresse hat sich für die beiden Lücken der Name „PHP2Shell“ durchgesetzt, das PHP-Projekt selbst verwendet ihn nicht.

• CVE-2026-109618: Speicherfehler bei der Behandlung von Out-of-Memory-Situationen.
• CVE-2026-109619: veralteter interner Zustand, der von einer späteren Anfrage im selben Worker weiterverwendet werden kann.

Behoben sind beide in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Projekt ruft alle Nutzer auf, sofort zu aktualisieren. Vollständige Übergangslösungen gibt es nicht, die genannten Konfigurationsänderungen verringern das Risiko nur.

Betroffen sind laut PHP-Projekt alle PHP-Installationen, die Webanfragen verarbeiten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das größte Risiko sieht das Projekt bei mod_php. Die Lücken sitzen in PHP selbst und nicht in einem bestimmten CMS: WordPress, Shopware, Drupal oder Eigenentwicklungen sind gleichermaßen betroffen, wenn sie auf einer ungepatchten Version laufen. PHP 8.1 und älter erhalten vom Projekt keine regulären Updates mehr. Für 7.4, 8.0 und 8.1 gibt es minimale Backports im Quellcode, ansonsten sind Linux-Distributionen und LTS-Anbieter gefragt.

Am 23. Oktober legte das Projekt mit einem Nachtrag nach: Bis zum nächsten regulären Bugfix-Release empfiehlt es session.upload_progress.enabled=0, um eine seltene Konfigurationskombination abzusichern. Ob das für eine Website relevant ist, entscheidet das technische Team.

Was hat Google dazu gesagt?

Search Engine Roundtable berichtete am 21. Oktober, dass viele Websites bis zum Patch vorsorglich offline gingen, unter Berufung auf Reuters auch Websites von Behörden, Schulen und Krankenhäusern in Europa. Am selben Tag schrieb Mueller auf Bluesky:

Der zweite Satz ist der wichtigere. Wenn PHP aus Sicherheitsgründen nicht mehr laufen soll, darf auch die Wartungsseite nicht davon abhängen. Webserver, Load Balancer oder CDN können eine statische Seite mit dem richtigen Statuscode ausliefern, ohne dass die verwundbare Anwendung auch nur eine Anfrage sieht. Mueller verweist dazu auf zwei ältere Google-Dokumente: den Blogbeitrag zu geplanten Ausfallzeiten und die Anleitung, eine Website vorübergehend zu pausieren.

Warum 503 und nicht 404, 500 oder ein Timeout?

Für Google sind diese Zustände nicht gleichwertig. Entscheidend ist, was der Crawler aus der Antwort ableiten kann:

• 503 Service Unavailable: vorübergehend nicht verfügbar. Google drosselt das Crawling, behält bereits indexierte URLs zunächst im Index und ignoriert den Inhalt der Fehlerseite. Genau das ist bei einer kurzen Notabschaltung gewollt.
• 500 Internal Server Error: Google behandelt alle 5xx-Fehler beim Crawling grundsätzlich gleich, ein 500 ist also nicht dramatischer als ein 503. Er beschreibt aber einen Defekt, keine geplante Wartung, und entsteht in der Praxis meist unkontrolliert aus der Anwendung, die eigentlich nicht mehr laufen soll.
• 404 und 410: Die Ressource existiert nicht beziehungsweise nicht mehr. Liefert die ganze Website so, entfernt Google die URLs laut eigener Dokumentation aus der Suche. Das gilt ebenso für 403.
• Timeout: Es kommt überhaupt keine verwertbare Antwort. Netzwerk-Timeouts gelten für Google als harte Fehler, die dazu führen können, dass betroffene URLs aus dem Index entfernt werden. Ausgerechnet das bequemste Vorgehen, den Server einfach abzuschalten, ist also das riskanteste.

Eine Sonderrolle hat die Wartungsseite mit Status 200. Für Besucher ist sie verständlich, für Google ist sie ein erfolgreicher Abruf. Erscheint dieselbe Meldung unter tausenden Produkt-, Kategorie- und Ratgeber-URLs, kann Google sie als Soft-404 werten oder den Hinweistext als Inhalt verarbeiten. Ein 503 verhindert das, weil Google den Inhalt von 5xx-Antworten ignoriert.

Ein 503 ist allerdings kein Schutzschild. Google empfiehlt ihn für eine dringende Abschaltung von ein bis zwei Tagen und hält eine Komplettabschaltung insgesamt nur für wenige Tage vertretbar. Bleibt eine Website länger im 503, fallen auch bei korrekter Umsetzung URLs aus dem Index. Während der Abschaltung kann Google außerdem Titles, Beschreibungen und strukturierte Daten nicht aktualisieren.

Wie sieht eine saubere Notabschaltung aus?

Bei größeren Websites sollte das nicht allein Sache der Serveradministration sein. Die IT behebt den Sicherheitsvorfall, SEO sorgt parallel dafür, dass Google währenddessen die richtigen Signale erhält. Fünf Punkte sind entscheidend:

1. Wartungsseite außerhalb der Anwendung ausliefern

Eine statische HTML-Seite, ausgeliefert vom Webserver, Load Balancer oder CDN. Google empfiehlt Inline-CSS, wenig externe Ressourcen und klare Hinweise für Besucher: voraussichtliche Rückkehr, Kontaktweg, wo es weitere Informationen gibt. Entscheidend ist nicht das Design, sondern der Statuscode 503.

2. Retry-After setzen

Der Header gibt einen ungefähren Zeitpunkt oder eine Dauer an, nach der ein erneuter Abruf sinnvoll ist. Google nennt ihn ausdrücklich als Best Practice. Eine Garantie, dass der Googlebot genau dann zurückkommt, ist er nicht.

3. robots.txt erreichbar halten

Der Punkt, der in der Hektik am häufigsten übersehen wird: Die robots.txt darf nicht ebenfalls mit 503 antworten, denn das blockiert laut Google das gesamte Crawling. Sie darf aber auch nicht kurzfristig durch Disallow: / ersetzt werden, weil das Inhalte und unter Umständen URLs aus der Suche entfernen kann. Die Wartungsregel muss die robots.txt also ausnehmen und unverändert ausliefern.

4. Keine zusätzlichen Sperren setzen

Kein vorsorgliches noindex, kein X-Robots-Tag, keine massenhaften 403, 404 oder 410. Und auch nicht das Tool zum Entfernen von URLs in der Search Console: Es macht die Website unsichtbar, auch für Kunden, die wissen wollen, was los ist.

5. Mit curl prüfen

Bevor alle aufatmen, kurz von außen kontrollieren: curl -I https://www.example.com/ muss 503 liefern, curl -I https://www.example.com/robots.txt dagegen 200. Das gilt für jede Domain, Subdomain und Sprachversion, die abgeschaltet wurde.

Was tun, wenn der Ausfall länger dauert?

Nicht jeder Sicherheitsvorfall ist in Stunden erledigt. Zeichnet sich ab, dass eine Website mehrere Tage oder länger nicht regulär laufen kann, reicht ein 503 nicht mehr. Googles grundsätzliche Empfehlung lautet dann, die Website eingeschränkt weiterzubetreiben statt sie ganz abzuschalten, etwa Produktinformationen online zu lassen und nur Warenkorb oder Kundenkonto zu deaktivieren. Für längere Komplettabschaltungen nennt Google eine indexierbare Startseite mit Status 200 als Platzhalter.

Bei einer kritischen Sicherheitslücke gilt aber: Eine verwundbare Anwendung bleibt nicht aus SEO-Gründen online. Welche Teile sicher betrieben werden können, entscheidet das Security- beziehungsweise Incident-Response-Team. Ist die Anwendung selbst nicht sicher, kann eine technisch getrennte, statische Fassung zentraler Seiten eine Brücke sein. Ein pauschales Umleiten aller URLs auf eine einzige Hinweisseite ist dagegen keine gute Idee.

Was nach dem Patch geprüft werden sollte

Mit dem Sicherheitsupdate ist der Vorfall aus SEO-Sicht noch nicht abgeschlossen. Nach der Freigabe gehören diese Punkte auf die Liste:

• Statuscodes je Seitentyp: Startseite, Kategorien, Produkte, Ratgeber und zentrale Landingpages müssen wieder 200 liefern, Weiterleitungen wieder wie vorher funktionieren.
• Caches leeren: Eine Wartungsseite, die im CDN oder Reverse Proxy hängen bleibt, liefert einzelnen Besuchern und Crawlern weiter 503, obwohl die Anwendung längst läuft.
• Indexierungssignale: robots.txt, Canonicals und Meta-Robots auf Reste der Notabschaltung prüfen.
• Search Console und Logfiles: Crawling-Statistik, Serverfehler und indexierte Seiten in den folgenden Tagen beobachten. Google fährt das Crawling nach einer 5xx-Phase schrittweise wieder hoch. Ein kurzer Rückgang ist deshalb noch kein Rankingverlust.

Wer Seiten neu crawlen lassen will, nutzt für wenige URLs die URL-Prüfung der Search Console und für viele die XML-Sitemap. Viele der Prüfpunkte decken sich mit denen nach einem Relaunch, mehr dazu im Playbook zur CMS-Migration.

Was PHP2Shell für Enterprise-Organisationen bedeutet

Große Unternehmen betreiben oft dutzende Websites, Länderauftritte und Microsites auf unterschiedlichen Systemen und PHP-Versionen. Dann muss im Ernstfall schnell klar sein, welche Systeme betroffen sind und wie sie sich einzeln abschalten lassen. Eine pauschale Sperre auf CDN- oder Domainebene trifft sonst auch Websites, die gar nicht verwundbar sind. Bewährt hat sich eine klare Trennung von drei Rollen, idealerweise festgehalten im Incident-Response-Handbuch, bevor der nächste Ernstfall eintritt:

• Security und IT entscheiden, welche Systeme sicher betrieben werden können und wann sie wieder freigegeben werden.
• WebOps und Infrastruktur setzen Abschaltung und Wiederherstellung technisch um.
• SEO definiert die Anforderungen an Statuscodes, robots.txt und Indexierung und übernimmt die Kontrolle danach.

Fazit: ein kleiner Statuscode mit großer Wirkung

PHP2Shell ist zuerst ein Sicherheitsproblem, und die Updates vom 21. Oktober haben Vorrang vor jeder SEO-Überlegung. Wer dafür offline gehen muss, sollte es aber richtig tun: 503 mit Retry-After, ausgeliefert außerhalb von PHP, robots.txt erreichbar und so kurz wie möglich. Ein 503 garantiert keine stabilen Rankings und ist keine Lösung für wochenlange Ausfälle. Er verhindert aber, dass Google eine vorübergehende Abschaltung mit einer dauerhaften Entfernung verwechselt.

Wenn Sie wissen möchten, wie gut Ihre Websites auf solche Situationen vorbereitet sind, unterstütze ich Sie im Rahmen von technischem SEO und Enterprise SEO Consulting.