Google vil have 503 under PHP-patchen. Den skal komme fra et lag, der ikke er PHP, og robots.txt skal holdes udenfor

Hvad Google sagde 21. oktober

Samme dag som PHP-projektet udsendte 8.5.12, 8.4.27, 8.3.36 og 8.2.35 med rettelser til to kritiske huller, der lader en angriber køre kode uden at logge ind, skrev Google Search Central på LinkedIn: tager du serveren ned for at patche, så svar 503. Det holder allerede indekserede URL'er i Søgning, mens du arbejder. Generiske 404-sider og fejlsider med status 200 frarådes.

John Mueller tilføjede på Bluesky, at 503'en kan laves uden for PHP, ved at pege DNS et andet sted hen eller via et CDN. Han kaldte rækkefølgen 503, 500, 403, 404, 200 – fra bedst til værst – for "a good model". Search Engine Journal samlede tråden og fandt selv det forbehold, der er artiklens egentlige pointe: Googles eget eksempel fra 2011 på planlagt nedetid sender 503'en med PHP-kode. Det virker ikke, når det er PHP, du har slukket.

Fælden: vedligeholdelsessiden kører selv på PHP

De fleste PHP-sites har allerede en vedligeholdelsestilstand, og næsten alle bygger på samme antagelse: at PHP kører. WordPress' indbyggede "kortvarigt utilgængelig"-side bliver lavet af WordPress selv. Laravels artisan down svarer 503 fra applikationen. Et plugin, der viser en pæn "vi er snart tilbage"-side, er PHP-kode. De virker alle sammen fint, mens du opdaterer et plugin. De virker ikke, mens PHP-binæren bliver skiftet ud, og PHP-FPM genstarter med en ny version.

Hvad Googlebot så ser, afhænger af webserveren foran: en 502 eller 504 fra Nginx, en timeout eller en standardfejlside fra hosten. Ingen af dem fortæller Google, at det er midlertidigt på den måde, en 503 gør, og en hostingudbyders brandede fejlside med status 200 er det værste af det hele, fordi den kan blive indekseret som indhold.

Spørgsmålet til jeres runbook er derfor ikke "har vi en vedligeholdelsesside?", men "hvilket lag svarer, når PHP er væk?". Svaret skal være et lag, der ikke deler skæbne med det, I patcher: en regel eller en worker på CDN'et, en webserverregel, der serverer en statisk fil med 503 uden at røre PHP, eller en midlertidig server, som DNS peger på.

Robots.txt skal holdes uden for reglen

Den hurtige løsning på kanten er en regel, der svarer 503 på alt. Den rammer også /robots.txt, og dér gælder andre regler. Googles guide til at sætte en virksomhed på pause siger direkte, at robots.txt ikke må svare 503, fordi det blokerer al crawling.

Ifølge robots.txt-specifikationen stopper Google med at crawle sitet i de første 12 timer, hvis robots.txt svarer 5xx, men bliver ved med at forsøge at hente filen. Derefter bruges den sidste fungerende kopi i op til 30 dage. Er der ingen kopi i cachen, går Google ud fra, at der ingen begrænsninger er.

For et vindue på 20 minutter er skaden ved en 503 på robots.txt formentlig lille: Google cacher normalt filen i op til 24 timer og forsøger igen, så crawlingen kan genoptages, når den svarer 200. Men det er en risiko uden nogen gevinst. Robots.txt er en statisk fil, og den kan serveres fra kanten med status 200 uanset, hvad origin laver. Det er én undtagelse i reglen.

Hele sitet bremses, ikke kun siderne der fejler

Den mindre kendte konsekvens står i Googles side om HTTP-statuskoder: 5xx og 429 får Google til at sænke crawlhastigheden for sitet, i forhold til hvor mange URL'er der fejler. Når serveren svarer 2xx igen, øges hastigheden gradvist – ikke med det samme. Siden om crawlhastighed fraråder at bruge 503 i mere end 1-2 dage, og statuskodesiden siger, at indekserede URL'er bevares, "but eventually dropped". Google kan heller ikke opdatere titler, beskrivelser eller strukturerede data på en side, der svarer 503.

Gary Illyes har tidligere sagt, at en 503 i 10-15 minutter en gang imellem ikke er noget problem. Det er rammen at planlægge efter: minutter, ikke timer. Har I mere end én applikationsserver bag en load balancer, er den bedste 503 den, I slet ikke sender: patch én server ad gangen, mens de andre svarer normalt.

Til sammenligning er lennartoester.dk et statisk build uden PHP på den server, der svarer. Patchen 21. oktober ramte ikke siden, fordi der ikke var noget at patche. Det er ikke et argument for at bygge alt statisk, men det er et argument for at flytte de sider, der skal kunne findes, væk fra den runtime, der skal kunne opdateres.

Rækkefølgen før næste patch

1. Find ud af, hvem der svarer, når PHP er nede. Stop PHP-FPM på et staging-miljø og se med curl -I, hvilken status og hvilken side der kommer ud. Mange opdager først her, at det er en 502 fra Nginx eller hostens fejlside.
2. Flyt 503'en uden for PHP. En regel på CDN'et eller i webserveren, der kan slås til med én handling, og som returnerer en statisk side med status 503 og en Retry-After-header.
3. Undtag robots.txt. Lad den blive serveret med 200 fra kanten eller som statisk fil, uden om reglen.
4. Undtag også det, der ikke er til Google. Webhooks fra betalingsudbydere og integrationer har deres egne gentagelsesregler. Tjek, om de forsøger igen ved 503, før I lukker dem ude.
5. Hold vinduet kort, og patch rullende, hvis I kan. Mål tiden på staging, så I ved, om I taler om fem minutter eller en time.
6. Tjek bagefter. Crawlstatistik-rapporten i Search Console viser svarene fordelt på statuskode. Kig efter en top på patch-dagen, og om crawlvolumen kommer tilbage på det normale niveau i dagene efter.