Eine Website muss wegen eines Sicherheitsupdates kurz vom Netz. Für Betreiber ist das eine technische Routine. Für Google kann dieselbe Situation drei völlig unterschiedliche Dinge bedeuten: eine geplante Wartung, einen ernsthaften Defekt — oder eine Seite, die es nicht mehr gibt. Welche Lesart der Crawler wählt, hängt fast ausschließlich an einer dreistelligen Zahl: dem HTTP-Statuscode, den der Server während der Ausfallzeit zurückliefert.
Die richtige Antwort lautet in fast allen Fällen 503 Service Unavailable. Wie man sie sauber ausliefert, auch wenn ausgerechnet PHP gerade nicht läuft, und welche Fehler wir in Wartungsfenstern immer wieder sehen, zeigen wir in diesem Beitrag — mit Konfigurationsbeispielen für Apache und Nginx und einem Blick darauf, was KI-Crawler in dieser Zeit mitbekommen.
01 · AnlassPHP2Shell und Googles Erinnerung an den 503
Am 21. Oktober 2026 wurden zwei kritische PHP-Sicherheitslücken öffentlich, die in der Branche unter dem Namen PHP2Shell laufen. Laut Search Engine Roundtable erlauben sie im schlimmsten Fall Remote Code Execution ohne Anmeldung; gepatchte Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. CERT-EU bewertete die Lücken mit einem CVSS-Wert von 9.2 und riet, ungepatchte Systeme notfalls vom Netz zu nehmen, wie PPC Land zusammenfasst.
Noch am selben Tag meldete sich Google zu Wort. Das Search-Central-Team erinnerte auf LinkedIn daran, während der Patch-Downtime einen 503 statt eines 404 oder einer 200-Fehlerseite auszuliefern. John Mueller ergänzte auf Bluesky, man solle Antworten nicht in einen Timeout laufen lassen und den 503 notfalls außerhalb von PHP erzeugen — über die Serverkonfiguration, ein CDN oder eine umgeleitete DNS.
Der Hinweis ist nicht neu. Google hat ähnlich schon 2021 bei Log4j argumentiert. Neu ist die Dringlichkeit: Eine Lücke, die praktisch jede PHP-Installation betrifft, zwingt sehr viele Websites gleichzeitig in ein Wartungsfenster — und genau in diesen Stunden entscheidet die Serverantwort darüber, ob die Arbeit spurlos bleibt.
Warum aus einem Sicherheitsupdate ein SEO-Thema wird
Während Sie patchen, ruft der Googlebot Ihre Seiten weiter ab. Er weiß nicht, warum eine Seite nicht antwortet — er sieht nur den Statuscode. Ein 503 sagt: „gleich wieder da“. Ein 404 sagt: „gibt es nicht mehr“. Eine 200-Wartungsseite sagt: „das hier ist jetzt der Inhalt“.
02 · SignaleStatuscodes: Was Google während der Wartung sieht
Bei jedem Abruf liefert der Server neben dem eigentlichen Inhalt einen Statuscode. Für Besucher ist er unsichtbar, für Crawler ist er das wichtigste Signal überhaupt. Google beschreibt in der Dokumentation zu den Auswirkungen von HTTP-Statuscodes recht genau, wie es die einzelnen Klassen behandelt.
Der entscheidende Unterschied liegt zwischen 4xx und 5xx. Ein 404 ist für Google eine Aussage über die Ressource: Sie ist weg. Google entfernt solche URLs aus dem Index und crawlt unbeirrt weiter. Ein 503 ist eine Aussage über den Server: Er kann gerade nicht. Google reduziert daraufhin die Abrufrate und behält bereits indexierte Seiten vorerst im Index.
„Vorerst“ ist dabei das wichtige Wort. Auch ein 503 schützt nicht unbegrenzt — die Dokumentation spricht davon, dass URLs bei anhaltenden Serverfehlern irgendwann doch aus dem Index fallen.
03 · DauerWie lange darf eine Website einen 503 ausliefern?
Eine feste Stundenzahl nennt Google nicht. Die konkreteste Aussage steht in der Anleitung zum Reduzieren der Crawling-Frequenz: Serverfehler sollen dafür nicht länger als ein bis zwei Tage eingesetzt werden. Werden dieselben URLs über mehrere Tage hinweg mit 5xx beantwortet, können sie aus dem Index entfernt werden.
Das heißt nicht, dass nach exakt 48 Stunden die Rankings verschwinden. Google wertet aus, wie oft und über welchen Zeitraum der Crawler den Fehler tatsächlich zu sehen bekommt. Eine Seite, die nur selten gecrawlt wird, bemerkt ein dreistündiges Wartungsfenster unter Umständen gar nicht. Eine stark frequentierte Shop-Domain wird dagegen dutzendfach in dieser Zeit abgefragt.
Unsere Faustregel aus Wartungseinsätzen: Ein Patch-Fenster, das sich in Stunden erledigen lässt, ist mit einem sauberen 503 unkritisch. Alles, was absehbar länger als einen Tag dauert — eine PHP-Migration über mehrere Major-Versionen, ein Serverumzug, ein Restore nach einem Befall —, braucht einen anderen Plan. Dazu mehr in Abschnitt 09.
04 · FehlerbilderWarum Wartungsplugins oft das falsche Signal senden
Fast jedes CMS bringt einen Wartungsmodus mit, und für WordPress gibt es Dutzende Plugins dafür. Besucher sehen eine freundliche Meldung wie „Wir sind gleich wieder für Sie da“. Für den Crawler zählt aber nicht der Text, sondern der Statuscode im Header — und der ist in unseren Audits erstaunlich oft falsch.
Fehlerbild 1: Die Wartungsseite antwortet mit 200
Optisch ist alles in Ordnung, technisch meldet der Server „Anfrage erfolgreich“. Google kann den Wartungstext dann als regulären Seiteninhalt behandeln — für jede einzelne URL. In der Search Console tauchen solche Seiten typischerweise als Soft 404 auf. Schlimmstenfalls landet der Hinweis „Wartungsarbeiten“ als Snippet in den Suchergebnissen.
Fehlerbild 2: Die Seiten antworten mit 404 oder 403
Manche Konfigurationen sperren während der Wartung einfach alles. Für Google sehen die betroffenen URLs dann aus wie gelöschte Seiten. Da 4xx-Codes die Crawling-Frequenz nicht senken, ruft der Googlebot im gewohnten Tempo weiter ab und sammelt in kurzer Zeit sehr viele Belege dafür, dass die Inhalte verschwunden sind.
Fehlerbild 3: Timeout oder 500
Läuft eine Anfrage ins Leere oder bricht mit einem 500 ab, erkennt Google zwar eine Störung und drosselt das Crawling. Der Code unterscheidet aber nicht zwischen Absturz und geplanter Arbeit — und ein Timeout liefert oft gar keinen verwertbaren Code. Für ein kontrolliertes Wartungsfenster ist der 503 die eindeutigere Wahl.
So sehen Sie den echten Statuscode
Öffnen Sie in den Browser-Entwicklertools den Tab Netzwerk und laden Sie die Seite neu — die Spalte „Status“ zeigt den Code. Oder im Terminal: curl -sI https://ihre-domain.de/. Steht in der ersten Zeile 200, obwohl die Wartungsseite angezeigt wird, sendet Ihr Plugin das falsche Signal.
05 · TechnikDen 503 ohne PHP ausliefern
Hier liegt der Kern des aktuellen Hinweises — und der Punkt, den fast alle Wartungsanleitungen übersehen. Die meisten Wartungsseiten werden von PHP selbst erzeugt: die .maintenance-Datei von WordPress genauso wie jedes Wartungsplugin. Muss aber ausgerechnet PHP gepatcht, neu gestartet oder vorübergehend abgeschaltet werden, kann die Wartungsseite nicht mehr ausgeführt werden. Statt eines sauberen 503 bekommt der Crawler dann einen 500, einen 502 vom Proxy oder einen Timeout.
Die Lösung: Den 503 eine Ebene vor PHP erzeugen. Je nach Hosting kommen dafür in Frage:
- Webserver-Konfiguration: Apache oder Nginx beantworten Anfragen direkt mit 503 und einer statischen HTML-Datei.
- CDN: Ein vorgeschalteter Dienst wie Cloudflare liefert die Wartungsantwort aus, ohne den Ursprungsserver zu fragen.
- Reverse Proxy: Eine zusätzliche Serverebene antwortet, solange die Anwendung dahinter nicht verfügbar ist.
- Temporärer Wartungsserver: Die Domain zeigt per DNS vorübergehend auf eine andere Infrastruktur — wegen der DNS-Laufzeiten nur sinnvoll, wenn die TTL vorher abgesenkt wurde.
Apache: 503 per .htaccess
Auf den meisten Shared-Hosting- und Plesk-Umgebungen mit Apache reicht ein Block am Anfang der .htaccess. Die Regeln werden vom Webserver ausgewertet, nicht von PHP. Ihre eigene IP bleibt ausgenommen, damit Sie die Seite nach dem Update prüfen können:
# ── Wartungsmodus: am Anfang der .htaccess einfügen ──
ErrorDocument 503 /wartung.html
RewriteEngine On
# robots.txt und die Wartungsseite selbst normal ausliefern
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} !^/wartung\.html$
# eigene IP ausnehmen (Beispieladresse ersetzen)
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteRule ^ - [R=503,L]
# Retry-After nur bei 503-Antworten setzen (mod_headers)
<IfModule mod_headers.c>
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"
</IfModule>Die Datei wartung.html ist eine schlichte, statische HTML-Seite ohne PHP-Bestandteile — mit Firmenname, kurzer Erklärung und Telefonnummer. Wichtig: nach der Wartung den Block wieder entfernen oder auskommentieren. Wir hinterlegen dafür in Kundenprojekten eine fertige Vorlage, die nur ein- und auskommentiert wird.
Nginx: 503 vor dem PHP-FPM-Block
Bei Nginx läuft die Wartung typischerweise über eine Schalterdatei. Existiert sie, beantwortet der Server alles außer der robots.txt mit 503:
# Wartung aktivieren: touch /var/www/maintenance.on
# Wartung beenden: rm /var/www/maintenance.on
error_page 503 /wartung.html;
location = /wartung.html {
root /var/www/static;
add_header Retry-After 3600 always;
internal;
}
location = /robots.txt {
try_files $uri =404; # bleibt statisch mit 200 erreichbar
}
location / {
if (-f /var/www/maintenance.on) { return 503; }
try_files $uri $uri/ /index.php?$args;
}Wer ohnehin ein CDN vorgeschaltet hat, kann die Wartungsantwort auch dort konfigurieren — dann bleibt selbst ein komplett abgeschalteter Ursprungsserver für Crawler eindeutig „vorübergehend nicht verfügbar“. Websites ohne PHP-Abhängigkeit haben dieses Problem übrigens gar nicht erst: Statische HTML-Websites sind von PHP-Lücken wie PHP2Shell schlicht nicht betroffen.
06 · HeaderRetry-After: einen Zeitpunkt für den nächsten Versuch nennen
Zusätzlich zum 503 kann der Server den Header Retry-After senden. Er nennt Crawlern und Clients eine Empfehlung, wann sich ein neuer Abruf lohnt. Die zugehörige Spezifikation steht in RFC 9110. Eine vollständige Antwort sieht so aus:
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html; charset=UTF-8Der Wert 3600 steht für 3.600 Sekunden, also eine Stunde. Alternativ ist ein fester Zeitpunkt im HTTP-Datumsformat möglich, etwa Retry-After: Tue, 27 Oct 2026 06:00:00 GMT. Der Header ist ein Hinweis, keine Verabredung: Google sagt nicht zu, exakt zu diesem Zeitpunkt wiederzukommen. Er kostet aber nichts und macht die Antwort eindeutiger.
07 · Crawling-RegelnDie robots.txt muss erreichbar bleiben
Ein Detail mit großer Wirkung: Die eigentlichen Seiten dürfen während der Wartung einen 503 liefern — die robots.txt sollte das nicht. Google beschreibt in seiner robots.txt-Spezifikation eine eigene, deutlich strengere Fehlerbehandlung für diese Datei.
Konkret: Kann Google die robots.txt wegen eines 5xx nicht abrufen, stoppt es in den ersten zwölf Stunden das Crawling der gesamten Website. Bis zu 30 Tage greift es danach auf die zuletzt erfolgreich abgerufene Version zurück. Was danach passiert, hängt davon ab, ob die übrige Website erreichbar ist. Deshalb nehmen beide Konfigurationsbeispiele oben die robots.txt ausdrücklich aus — sie bleibt eine statische Datei mit 200.
Ebenfalls keine gute Idee: während der Wartung pauschal Disallow: / zu setzen oder Seiten auf noindex umzustellen. Beides sendet ein dauerhaftes Signal für ein vorübergehendes Problem und kann die Sichtbarkeit länger beeinträchtigen als die Wartung selbst.
08 · GEOWas KI-Crawler und Bing in dieser Zeit sehen
Die Diskussion dreht sich fast nur um Google. Während eines Wartungsfensters klopfen aber auch andere an: der Bingbot, der unter anderem Copilot und die Websuche hinter ChatGPT mit Daten versorgt, sowie die Index-Crawler der KI-Anbieter wie OAI-SearchBot oder PerplexityBot. Welcher Assistent auf welchen Index zugreift, haben wir im Beitrag zum neuen Search Funnel aufgeschlüsselt.
Für alle diese Systeme gilt dasselbe Grundprinzip: Sie sehen nur die Serverantwort. Eine Wartungsseite mit 200 ist für sie gültiger Inhalt — und kann im ungünstigen Fall als Momentaufnahme einer Seite gespeichert werden, auf deren Grundlage später Antworten entstehen. Ein 503 dagegen ist nach HTTP-Standard eindeutig als vorübergehend definiert und wird von seriösen Crawlern entsprechend behandelt.
Ehrlicherweise müssen wir dazu sagen: Wie lange einzelne KI-Anbieter einen Ausfall tolerieren, bevor sie Inhalte neu bewerten, ist uns aus keiner öffentlichen Dokumentation bekannt. Gerade deshalb ist ein korrekter 503 hier die sicherste Option — er ist das Signal, das jeder standardkonforme Client versteht. Wer zusätzlich eine llms.txt pflegt, sollte sie wie die robots.txt behandeln und während der Wartung statisch erreichbar halten.
„Ein Crawler kennt keine Absicht. Er kennt nur den Statuscode — und den entscheiden Sie, bevor die Wartung beginnt.“— Jörg Strömsdörfer · DieWebAG© · Oktober 2026
09 · RankingsWas mit Rankings passiert — und was bei längeren Ausfällen hilft
Die wichtigste Frage zuerst: Verliert eine Website durch eine kurze Wartung automatisch ihre Rankings? Nein. Google ist darauf ausgelegt, vorübergehende Störungen zu erkennen. Wer für einige Minuten oder wenige Stunden einen sauberen 503 ausliefert, muss mit keinem nachhaltigen Verlust rechnen. Wie stark eine Wartung nachwirkt, hängt von fünf Faktoren ab:
- Dauer: Je länger der Ausfall, desto größer das Risiko, dass URLs anders bewertet oder entfernt werden.
- Häufigkeit: Eine einmalige Wartung ist etwas anderes als eine Domain, die regelmäßig Serverfehler produziert.
- Umfang: Ist eine einzelne Funktion betroffen — oder die gesamte Domain mit allen Unterseiten?
- Crawling-Frequenz: Häufig besuchte Seiten werden während eines Ausfalls mehrfach geprüft, selten besuchte unter Umständen gar nicht.
- Zustand danach: Liefert die Seite nach dem Update wieder korrekte Inhalte, Canonicals, Weiterleitungen und Statuscodes?
Gerade Punkt fünf unterschätzen viele. In der Praxis entstehen die nachhaltigeren Probleme oft nicht während der Wartung, sondern danach: ein Plugin, das unter der neuen PHP-Version still versagt, ein Cache, der noch die Wartungsseite ausliefert, ein Kontaktformular ohne Funktion.
Wenn die Arbeiten länger als ein bis zwei Tage dauern
Für längere Abschaltungen empfiehlt Google in der Anleitung zum vorübergehenden Pausieren einer Website einen anderen Weg: die Website möglichst erreichbar lassen und nur einzelne Funktionen einschränken. Statt einer Wartungsseite unter jeder URL bleibt eine echte, indexierbare Startseite mit HTTP 200 — mit Informationen zum Unternehmen, Kontaktmöglichkeiten und einem Hinweis auf die Einschränkung.
- Der Shop bleibt sichtbar, nur der Bestellprozess wird vorübergehend deaktiviert.
- Informations- und Leistungsseiten bleiben erreichbar.
- Nur die betroffenen dynamischen Funktionen werden gewartet.
- Die neue PHP-Version wird vorab in einer Staging-Umgebung getestet.
Für lokale Unternehmen ist in dieser Zeit außerdem das Google-Unternehmensprofil der wichtigste Kontaktpunkt: Telefonnummer, Öffnungszeiten und ein kurzer Beitrag zur Einschränkung erreichen Suchende auch dann, wenn die Website gerade nur eingeschränkt läuft.
10 · AblaufWordPress und PHP-Updates: der Ablauf in drei Phasen
Für WordPress-Websites folgt aus alldem eine klare Konsequenz: Ein Sicherheitsupdate ist nicht erledigt, wenn die Seite wieder lädt. Es ist erledigt, wenn sie auch für Crawler wieder korrekt antwortet. So gehen wir in der WordPress-Betreuung vor:
Vor dem Update
Zuerst klären, welche PHP-Version läuft und welche Abhängigkeiten bestehen: WordPress-Core, aktives Theme, Plugins, individuelle Erweiterungen und Schnittstellen. Im Idealfall wird die neue Version zuerst in einer Staging-Umgebung getestet. Ein vollständiges Backup von Dateien und Datenbank ist Pflicht — und die statische Wartungsseite liegt fertig auf dem Server, bevor sie gebraucht wird.
Während des Updates
Der 503 wird auf Webserver- oder CDN-Ebene aktiviert, nicht im CMS. Dann wird er geprüft — nicht an der sichtbaren Seite, sondern auf HTTP-Ebene, per Entwicklertools, Monitoring-Dienst oder curl -sI. Parallel kontrollieren wir, dass /robots.txt weiterhin mit 200 antwortet.
Nach dem Update
Die Startseite und die wichtigsten Unterseiten müssen wieder mit 200 antworten. Stichproben lohnen sich besonders bei Leistungsseiten, Kontakt- und Anfrageformularen, Weiterleitungen, Canonical-Tags, robots.txt, XML-Sitemap, strukturierten Daten und allen Funktionen, die an PHP oder einzelnen Plugins hängen. In den Tagen danach zeigt die Search Console unter „Crawling-Statistiken“, ob der Googlebot die Serverfehler registriert hat und wieder normal abruft. Wer die Seite systematisch durchleuchten lassen möchte, findet im Website-Audit den passenden Rahmen.
Checkliste: Wartung ohne vermeidbare SEO-Schäden
noindex und kein Disallow: / als WartungslösungSEO ist kein Grund, einen Patch aufzuschieben
Bei einer Lücke wie PHP2Shell ist das Risiko eines kompromittierten Servers ungleich größer als jeder Rankingverlust — ein gehackter Server mit eingeschleustem Spam ist für die Sichtbarkeit das weitaus schlimmere Szenario. Erst patchen, dann optimieren. Der richtige Statuscode sorgt nur dafür, dass das eine das andere nicht beschädigt.
11 · FAQHäufige Fragen zu HTTP 503, PHP-Updates und SEO
Ist der HTTP-Statuscode 503 schlecht für SEO?
Nicht grundsätzlich. Bei einer kurzen, geplanten Wartung ist HTTP 503 der passende Statuscode: Google drosselt das Crawling und behält indexierte URLs zunächst im Index. Hält der Fehler jedoch mehrere Tage an, können URLs aus dem Index fallen.
Wie lange kann meine WordPress-Website im Wartungsmodus bleiben?
So kurz wie möglich. Google rät davon ab, Serverfehler länger als ein bis zwei Tage auszuliefern. Eine Garantie, dass innerhalb dieses Zeitraums nichts passiert, gibt es nicht — entscheidend ist, wie oft der Crawler den Fehler zu sehen bekommt.
Verliere ich durch ein PHP-Update meine Google-Rankings?
Ein korrekt durchgeführtes PHP-Update führt nicht automatisch zu Rankingverlusten. Probleme entstehen, wenn die Website lange nicht erreichbar ist, falsche Statuscodes wie 404 oder 200 sendet oder nach dem Update technische Fehler auftreten.
Reicht ein WordPress-Wartungsplugin aus?
Nur, wenn es tatsächlich HTTP 503 zurückgibt und im geplanten Szenario funktioniert. Wartungsplugins laufen selbst über PHP. Wird PHP gepatcht oder abgeschaltet, fällt auch die Wartungsseite aus — dann muss der 503 vom Webserver oder einem CDN kommen.
Warum muss die robots.txt während einer Wartung erreichbar bleiben?
Liefert die robots.txt einen Serverfehler, stoppt Google in den ersten zwölf Stunden das Crawling der gesamten Website und greift danach bis zu 30 Tage auf die zuletzt bekannte Version zurück. Die Datei sollte deshalb auch während der Wartung statisch mit HTTP 200 ausgeliefert werden.
Sehen ChatGPT, Perplexity und Bing eine Wartungsseite?
Ja, ihre Crawler sehen dieselbe Serverantwort wie der Googlebot. Eine Wartungsseite mit Statuscode 200 ist für sie regulärer Inhalt. Ein 503 ist nach HTTP-Standard eindeutig als vorübergehend definiert und damit das sicherste Signal für alle Crawler.
Wann ist HTTP 200 bei einer Wartung sinnvoll?
Wenn eine Website länger als ein bis zwei Tage eingeschränkt bleibt. Dann empfiehlt Google eine regulär erreichbare, indexierbare Startseite mit HTTP 200 und Hinweisen zur Einschränkung — nicht aber eine Wartungsseite, die unter jeder URL mit 200 ausgeliefert wird.
Fazit: Ein kleines Serversignal mit großer Wirkung
Website-Wartungen und PHP-Sicherheitsupdates gehören zum professionellen Betrieb einer Website. Wer dabei nur darauf achtet, dass die Seite hinterher wieder lädt, übersieht die eigentliche Frage: Wie haben Suchmaschinen und KI-Crawler die Website während des Ausfalls wahrgenommen?
Der HTTP-Statuscode 503 kommuniziert eine kurzfristige Nichterreichbarkeit technisch korrekt — für Google, für Bing und für jeden standardkonformen KI-Crawler. Er sollte gezielt, zeitlich begrenzt und möglichst unabhängig von der PHP-Anwendung eingesetzt werden, die gerade gewartet wird. Dazu gehören eine erreichbare robots.txt und eine Kontrolle danach.
Aus unserer Sicht endet professionelle Website-Wartung deshalb nicht beim erfolgreichen Update. Sie umfasst die technischen SEO-Signale vor, während und nach den Arbeiten — genau das ist Bestandteil unserer laufenden SEO-Betreuung und unserer technischen SEO. Wenn Sie unsicher sind, ob Ihre Wartungsseite das richtige Signal sendet, prüfen wir das gern über das Kontaktformular.
Quellen und weiterführende Informationen
- Google: Auswirkungen von HTTP-Statuscodes auf Google-Crawler
- Google: Website vorübergehend pausieren oder deaktivieren
- Google: Crawling-Frequenz des Googlebot reduzieren
- Google: Wie Google die robots.txt-Spezifikation interpretiert
- IETF: RFC 9110 — Retry-After
- Search Engine Roundtable: Google zum Abschalten von Websites wegen PHP2Shell (21.10.2026)
- PPC Land: Google rät beim PHP-Patch zu 503 statt 404
- Search Engine Journal: Google erinnert an 503 bei Server-Downtime
Jörg Strömsdörfer
Seit 2009 Kopf hinter DieWebAG© in Köln-Rodenkirchen. Begleitet Unternehmen von der ersten Keyword-Recherche bis zur fertigen Kampagne und schreibt regelmäßig über das, was zwischen klassischem SEO und generativer Suche gerade wirklich passiert.