Site offline door het PHP-lek? Zo beperk je de schade in Google

Sinds woensdagochtend gaan in Nederland de ene na de andere website uit voorzorg offline. In PHP, de programmeertaal onder WordPress, WooCommerce en Magento, zitten twee kritieke lekken die samen PHP2Shell heten. De fix kwam woensdagmiddag rond half vier uit, iets eerder dan de aangekondigde 16.00 uur (PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35), maar niet elke host of webbouwer voert die dezelfde avond door, dus veel sites blijven nog even dicht. Wat je tegen het lek zelf moet doen, staat in het beveiligingsadvies van het PHP-team.

Ik krijg vandaag vooral een andere vraag: wat doet dat offline gaan met mijn plek in Google? Google raadt het eigenlijk af om je hele site dicht te zetten. Moet het toch, dan is een paar dagen met het juiste signaal het minste kwaad, en juist dat signaal gaat vaak mis.

Wat Google wil zien als je site tijdelijk dicht is

Google heeft hier een eigen pagina over, Temporarily pause or disable a website. Het eerste advies daar is je site online te houden en alleen functies uit te zetten, zoals de winkelwagen. Bij dit lek is dat te weinig, want PHP zelf is kwetsbaar en een aanvaller heeft geen inlog nodig. Dan blijft de tweede route over:

Wat je niet moet doen: de site afschermen met een 403, 404 of 410, een noindex zetten of de verwijdertool in Search Console gebruiken. Volgens Google haal je daarmee je URL's uit de zoekresultaten. Bij de 503 raadt Google een Retry-After-header aan met een datum of een duur, en een statische foutpagina met de CSS erin, zodat de server zo min mogelijk werk heeft. In een oudere uitleg uit 2011 schrijft Google ook dat Googlebot die header kan gebruiken om te bepalen wanneer hij terugkomt.

Een 503 betekent voor Google "kom later terug". Pagina's die al in de index staan blijven daar voorlopig, maar als de fout aanhoudt, vallen ze eruit (How HTTP status codes affect Google's crawlers). Google noemt de hele site dichtzetten daarom een uiterste maatregel voor "a few days at most", met merkbare gevolgen, ook als je het netjes doet.

John Mueller van Google zei het woensdag nog eens op LinkedIn: haal je een PHP-site offline om de update te regelen, geef dan een 503 en laat verzoeken niet uitlopen op een time-out, een 404 of een 500. Dat kan volgens hem ook buiten PHP om, via je DNS of je CDN.

Hoe grote Nederlandse sites het vandaag deden

We hebben woensdag tussen 15.08 en 15.13 uur met curl opgevraagd wat acht sites teruggeven die vanochtend in het nieuws waren: de homepage, de robots.txt en waar het kon een dieper gelegen pagina. We vroegen ze op als gewone browser vanaf een Nederlands adres. Om 15.20 uur hebben we Tweakers en RTL nog eens opgevraagd met de user-agent van Googlebot (niet vanaf een adres van Google). De tabel gaat dus over de pagina's die wij opvroegen, niet over elke URL van die sites.

Bij deze organisaties weegt veiligheid zwaarder dan vindbaarheid, dus ik lees dit niet als een rapport. Voor een webshop of dienstverlener ligt het anders, en daar laten deze acht mooi zien wat elke aanpak betekent.

MijnOverheid, RTL en Tweakers zitten het dichtst bij Googles advies. Hun pagina's geven een 503, RTL zet er ook een Retry-After bij. Alleen geeft de robots.txt bij alle drie ook een 503, en dat raadt Google af. Dat Tweakers er een noindex bij zet, maakt waarschijnlijk niets uit, want Google negeert de inhoud van een pagina met een 5xx-status.

DigiD geeft op de pagina's die we opvroegen een gewone 200 met een onderhoudstekst. Google kan zo'n pagina aanmerken als soft 404, een foutpagina die zich voordoet als een gewone pagina. Een 200 beschrijft Google alleen voor de homepage, als plaatshouder bij een langere sluiting.

Het NCSC zet een noindex op een pagina met een 200. Voor een gewone site is dat de route die Google afraadt, omdat het URL's uit de zoekresultaten haalt.

De Tweede Kamer en de Autoriteit Persoonsgegevens gaven vanaf ons adres geen antwoord. Notubiz zit achter Cloudflare, dat bij ons na 20,1 seconden een 522 gaf, de foutcode voor een server erachter die niet reageert. Google behandelt een time-out of een verbroken verbinding "similarly to 5xx", dus voor de crawler lijkt dat op een serverfout. Dat zijn precies de time-outs en 5xx-fouten waar Mueller voor waarschuwt.

De robots.txt is het stuk dat iedereen vergeet

Google is op twee plekken net iets anders over een robots.txt met een 503. Op de pagina over tijdelijk sluiten staat dat het "all crawling" blokkeert. In de specificatie van robots.txt staat hoe dat precies loopt: de eerste 12 uur crawlt Google je site niet, daarna gebruikt Google tot 30 dagen de laatste versie die wel lukte. Bij een 503 probeert Google het in die tijd vrij vaak opnieuw.

Bij een site die één dag op 503 staat, maakt dat weinig uit, want Googlebot krijgt dan toch niets. Het gaat pas wringen als je na twee dagen een homepage met een 200 neerzet: met een 503 op je robots.txt ziet Google die homepage de eerste 12 uur niet. Dat is mijn eigen inschatting, Google schrijft het niet zo op.

De grotere reden zit in WordPress. Daar is de robots.txt meestal geen bestand, want PHP maakt hem op het moment dat iemand erom vraagt. Zet je een 503 op je hele site maar laat je de robots.txt erbuiten, dan gaat dat verzoek alsnog naar PHP. En dat wil je vandaag juist niet.

Zet daarom een echt bestand robots.txt in de hoofdmap van je site. Twee regels zijn genoeg:

User-agent: *
Disallow:

Zo zet je een WordPress-site op 503

De onderhoudsmodus van WordPress of een onderhoudsplug-in helpt hier niet, want die draaien zelf in PHP. Het verzoek moet worden afgevangen voordat het bij PHP komt, dus in de webserver.

Op een Apache-server doe je dat in het bestand .htaccess. Zet dit helemaal bovenaan, boven het blok van WordPress, en zet een statisch bestand onderhoud.html in dezelfde map. Die pagina mag geen losse CSS-bestanden, afbeeldingen of lettertypen laden, want die krijgen ook een 503. Zet de opmaak er dus in.

# Tijdelijk dicht vanwege het PHP-lek: alles 503, behalve robots.txt en de onderhoudspagina
ErrorDocument 503 /onderhoud.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} !^/onderhoud\.html$
RewriteRule ^ - [R=503,L]
<IfModule mod_headers.c>
  Header always set Retry-After "86400"
</IfModule>

Die 86400 is een dag in seconden. Verwacht je langer dicht te zijn, zet er dan een hoger getal neer. Dit werkt alleen als het bestand robots.txt echt bestaat, anders stuurt WordPress dat verzoek toch weer naar PHP. Draait je host LiteSpeed in plaats van Apache, dan leest die dezelfde .htaccess, maar test het daar extra goed met de controle hieronder.

Heb je een eigen VPS met nginx, let dan op één valkuil. Een return 503 in location / vangt niet alles, want verzoeken naar bijvoorbeeld /wp-login.php vallen onder de PHP-regel location ~ \.php$ en gaan gewoon door naar PHP. Zet de 503 daarom op serverniveau in het blok voor poort 443, boven de locations:

error_page 503 @onderhoud;
if ($uri !~ ^/robots.txt$) {
return 503;
}
location = /robots.txt { try_files $uri =404; }
location @onderhoud {
default_type text/html;
add_header Retry-After 86400 always;
return 503 ”<!doctype html><meta charset=utf-8><title>Tijdelijk dicht</title><p>We zijn tijdelijk dicht voor onderhoud.</p>”;
}

De onderhoudspagina staat hier in de config zelf. Verwijs je naar een bestand dat er niet is, dan geeft nginx een 404 op elke URL, en dat is precies wat je niet wilt. Laad daarna de config opnieuw met nginx -t && nginx -s reload. Bij nginx mag de robots.txt ontbreken: dan krijgt Google een 404 en leest die dat als "er zijn geen beperkingen".

Zit je bij een beheerde WordPress-host, dan kun je dit vaak niet zelf instellen en moet je host of je CDN de 503 zetten. Vraag dat dan expliciet, inclusief de robots.txt.

De andere route die Mueller noemt, is je DNS tijdelijk naar een andere server laten wijzen die alleen een 503 en een robots.txt teruggeeft. Dan komt geen enkel verzoek meer bij je eigen server met PHP. Houd er wel rekening mee dat een DNS-wijziging even nodig heeft voordat iedereen hem ziet, en dat je mail niet mee moet verhuizen: pas alleen de records voor je website aan.

Controleer het met curl

Kijk daarna altijd wat je server echt teruggeeft, met een gewoon GET-verzoek. Het ?x=1 erachter zorgt dat je geen oude versie uit een cache krijgt:

curl -s -o /dev/null -D - "https://www.jouwsite.nl/?x=1"
curl -s -o /dev/null -D - "https://www.jouwsite.nl/wp-login.php?x=1"
curl -s -o /dev/null -D - "https://www.jouwsite.nl/robots.txt"

De eerste twee moeten 503 teruggeven met een Retry-After, de robots.txt een 200, of bij nginx zonder bestand een 404.

Zit je achter Cloudflare of een ander CDN, dan staat er ook iets als cf-cache-status in de headers. Een CDN kan nog een oude versie van een pagina met een 200 uitserveren, of na afloop juist een 503 blijven tonen. Leeg de cache daarom als je de 503 aanzet, en nog een keer als je hem weer weghaalt. Een robots.txt die uit de cache van het CDN komt, is hier trouwens handig, want dat verzoek bereikt je server met PHP dan niet eens.

Duurt het langer dan twee dagen

Blijft je site langer dicht, bijvoorbeeld omdat je host nog niet heeft bijgewerkt of omdat er voor je oude PHP-versie geen kant-en-klare update is, dan verandert Googles advies. Zet dan een homepage neer die gewoon een 200 geeft en die vertelt wat er aan de hand is en wanneer je terug bent. Mensen die je bedrijfsnaam googelen, vinden dan nog steeds iets van jou.

Houd er rekening mee dat een 503 ook verkeer tegenhoudt dat je wel wilt hebben, zoals de meldingen van je betaalprovider en de verlenging van je SSL-certificaat via Let's Encrypt. Bij een dag maakt dat weinig uit, bij een week wel.

Search Console helpt je in die periode minder. Volgens Google mislukt een nieuwe verificatie zolang de site dicht is, en verliezen de rapporten data naarmate er pagina's uit de index vallen.

Als je site weer online is

1. Haal de regels uit .htaccess of de nginx-config, verwijder de tijdelijke robots.txt en onderhoud.html, en leeg de cache van je CDN. Je eigen robots.txt (met de regel naar je sitemap) komt dan vanzelf terug.
2. Controleer met curl dat je homepage en een paar diepere pagina's weer een 200 geven, zonder noindex.
3. Vraag in Search Console via URL-inspectie opnieuw indexering aan voor je homepage en een paar belangrijke pagina's.
4. Dien je sitemap opnieuw in, zodat Google de rest sneller langsloopt.
5. Kijk de dagen erna in Search Console onder Instellingen, Crawlstatistieken of de serverfouten verdwijnen en het aantal crawlverzoeken weer oploopt.

Heb je in de haast een noindex gezet of je pagina's een 404 laten geven, haal die dan als eerste weg en loop stap 3 en 4 meteen af.