Mueller ha detto come spegnere un sito PHP

Il 503 va impostato fuori da PHP, via DNS o CDN, ma resta temporaneo.

C’è un paradosso nell’emergenza PHP di questi giorni. La mossa più prudente per un sito vulnerabile, cioè staccarlo dalla rete, può diventare la più costosa per il traffico organico e per le conversioni se il server, una volta spento, risponde nel modo sbagliato. Lo ha ricordato John Mueller di Google in un breve post pubblicato su Bluesky nei giorni scorsi: chi mette offline un sito PHP per gestire quelli che chiama, tra virgolette, “aggiornamenti non pianificati” dovrebbe usare un HTTP 503 invece di lasciare che le richieste vadano in timeout o restituiscano un 404 o un 500. Non è una notizia dell’ultima ora: è un consiglio di qualche giorno fa, che vale la pena leggere con attenzione prima di prendere la prossima decisione sotto pressione.

Spegnere il sito per salvarlo, e perderlo nei risultati

Il contesto è un’allerta di sicurezza. Lo scorso 21 ottobre la CISA ha diffuso un avviso sulle vulnerabilità critiche di PHP e, secondo l’agenzia, le organizzazioni che non sono in grado di applicare subito le patch dovrebbero mettere offline i sistemi PHP. È un’indicazione chiara, pensata per chi gestisce infrastrutture e deve ridurre l’esposizione nel minor tempo possibile.

Il punto sollevato da Mueller arriva da un mondo diverso, quello della ricerca organica, e riguarda non il se ma il come. Un sito spento “a mano”, senza curare il codice di stato, comunica ai crawler qualcosa di molto diverso da un sito temporaneamente in manutenzione. Un 404 dice che la pagina non esiste, un 500 segnala un errore del server, un timeout non dice nulla di utile. Per chi lavora sulle conversioni la conseguenza è semplice: la sicurezza è salva, ma una parte del funnel che parte da Google rischia di non tornare quando il sito si riaccende. Se il 503 è la risposta corretta, viene da chiedersi perché non basti impostarlo e dimenticarsene.

Il 503 non è un interruttore, è un timer

Il comportamento atteso del 503 è documentato. Servire un codice 503 Service Unavailable, come riportato in un approfondimento su come i codici di stato influenzano i crawler di Google, garantisce che gli URL già indicizzati vengano preservati in Search mentre si lavora. In altre parole, il segnale dice a Google: questa risorsa esiste, ma adesso non è disponibile, ripassa più tardi.

Il limite sta proprio in quel “più tardi”. La stessa guida di Google Search sui downtime pianificati, a cui Mueller rimanda nel suo post e che risale già al 2011, avverte che i codici 503 che durano nel tempo possono essere interpretati come un segno che il server è ormai indisponibile in modo permanente e possono portare alla rimozione degli URL dall’indice. Il 503 quindi protegge l’indicizzazione solo finché resta temporaneo. Lasciato acceso troppo a lungo, finisce per produrre lo stesso effetto che voleva evitare.

C’è poi un dettaglio che rende il caso attuale più delicato. Quella guida parla di downtime pianificati, mentre qui nessuno ha pianificato nulla: lo spegnimento è imposto da una vulnerabilità e la sua durata dipende da quando si riesce ad aggiornare, non da un calendario deciso in anticipo. Mueller suggerisce anche una soluzione pratica a un problema evidente, cioè che se PHP è il componente vulnerabile non conviene affidare a PHP la risposta 503. Il downtime, scrive, si può gestire fuori da PHP, puntando il DNS altrove o passando per una CDN. Resta da capire se esistano alternative che evitino del tutto di spegnere il sito.

Chi era già protetto prima che se ne parlasse

La CDN citata da Mueller come luogo in cui gestire il downtime, per qualcuno, lo ha reso quasi superfluo. Cloudflare ha sviluppato e distribuito protezioni WAF a partire da inizio ottobre 2026, attivate circa 9 ore prima della divulgazione pubblica delle vulnerabilità. È un dato di contesto, non una raccomandazione: un web application firewall non sostituisce la patch, e la scelta dipende dall’architettura di ciascun sito. Mostra però che tra “tutto acceso e vulnerabile” e “tutto spento” esiste una fascia intermedia, e che chi aveva già quella protezione ha potuto affrontare la scelta con meno urgenza.

Chi lavora con i dati dovrebbe notare soprattutto ciò che manca. Nessuno ha pubblicato numeri su quanto a lungo un 503 resti innocuo prima che Google cominci a rimuovere URL: la guida parla genericamente di codici “che durano nel tempo”, senza una soglia. E non esistono, almeno nelle fonti disponibili, misurazioni su quanto traffico e quante conversioni si perdano per ogni ora di sito offline, né confronti tra uno spegnimento pulito con 503 e una protezione a livello di CDN. Qualsiasi affermazione su questi valori oggi sarebbe aneddotica.

Sono proprio le prime cose da misurare: la durata del 503 confrontata con l’andamento degli URL indicizzati, le sessioni organiche e le conversioni perse per ora di downtime, il costo di un WAF rispetto a quello di qualche ora di buio. Meglio raccoglierle e annotarle la prossima volta che una CVE costringe a spegnere tutto, prima che la scelta la faccia l’emergenza.