Le regole del digitale stanno cambiando.
O sei visibile o sei fuori. Noi ti aiutiamo a raggiungere i clienti giusti — quando ti stanno cercando.
Contattaci ora
Il 503 è corretto per un fermo temporaneo, ma la manutenzione di WordPress e Magento non basta.
John Mueller di Google consiglia di restituire un codice HTTP 503 quando un sito PHP viene spento per aggiornamenti non pianificati, evitando timeout, 404 o 500. Il suggerimento si lega all'allerta della CISA su vulnerabilità critiche di PHP, che spinge molte aziende offline. La riserva: il consiglio guarda soprattutto all'interesse di Google a scansionare il web in modo ordinato.
C’è un caso in cui la scelta più prudente per un sito PHP è spegnerlo. In quel momento il pulsante “manutenzione” di WordPress o Magento non serve a nulla. Da qui parte il consiglio che John Mueller di Google ha pubblicato ieri su Bluesky. Riguarda le pause non pianificate, quelle che nessuno mette in calendario ma che a volte vanno fatte in fretta. Nel suo breve post su Bluesky Mueller scrive che chi mette offline un sito PHP per gestire “aggiornamenti non pianificati” dovrebbe restituire un codice HTTP 503. Non dovrebbe invece lasciare che le richieste vadano in timeout o finiscano in un 404 o in un 500.
Spegnere sì, ma con il codice giusto
Il messaggio è asciutto, come spesso accade con Mueller, ma contiene due indicazioni precise. La prima riguarda il codice di risposta. Il 503, “Service Unavailable”, è il modo standard con cui un server comunica che in quel momento non è disponibile. Le alternative sono il timeout, cioè la pagina che non risponde mai, il 404 di “pagina non trovata” o il 500 di errore generico. Secondo Mueller sono tutte scelte peggiori.
La seconda indicazione è meno ovvia. Mueller spiega che questa gestione si può fare al di fuori di PHP: puntando il DNS altrove, cioè cambiando l’indirizzo a cui risponde il dominio, oppure tramite una CDN, la rete di server che si interpone tra il sito e i visitatori. Il post rimanda poi a una guida del blog di Google Search sui downtime pianificati, pubblicata già nel 2011. In quella guida Google spiega che durante un’interruzione programmata conviene restituire un 503, perché comunica ai crawler, i programmi che scansionano il web per conto dei motori di ricerca, che il fermo è temporaneo.
Resta però una domanda. Perché complicarsi la vita con DNS e CDN,
quando WordPress e Magento hanno già una loro modalità di manutenzione pronta all’uso?
Perché la modalità manutenzione non basta
La risposta sta nell’ordine in cui avvengono le cose quando qualcuno visita una pagina. Come descritto dai ricercatori di Sansec nella loro analisi tecnica, le modalità di manutenzione di Magento e WordPress in questo caso non aiutano. Il motivo è che PHP elabora ogni richiesta prima che l’applicazione controlli se la manutenzione è attiva.
Si può pensare a un negozio con il cartello “chiuso per lavori” appeso dietro il bancone. Il cliente deve comunque entrare, attraversare il locale e arrivare alla cassa prima di leggerlo. Se il problema sta proprio nella porta d’ingresso, il cartello non protegge nessuno. Un sito WordPress o Magento in “manutenzione” funziona allo stesso modo: mostra un messaggio di cortesia ai visitatori, ma sotto il cofano PHP continua a girare e a ricevere tutto quello che arriva dall’esterno. Se la falla da tenere chiusa è in PHP,
quella modalità non chiude nulla.
Il tempismo del consiglio si spiega con il contesto. Sempre ieri l’agenzia statunitense per la cybersicurezza ha diffuso un’allerta su vulnerabilità critiche di PHP che richiedono un aggiornamento immediato. Secondo la CISA, le organizzazioni che non possono aggiornare subito, o che usano ancora PHP 8.1 o versioni precedenti non più supportate, dovrebbero mettere offline i sistemi basati su PHP finché non saranno corretti o aggiornati. Per molte aziende questo significa spegnere il sito in attesa della patch e restare offline per ore, forse per giorni.
Mueller non entra nel merito della sicurezza. Si limita a far notare che, se spegnere è inevitabile, conviene farlo in un modo che i motori di ricerca capiscano. È un consiglio sensato, anche se va ricordato che arriva da chi guarda il problema dal lato di Google, che ha tutto l’interesse a scansionare il web nel modo più ordinato possibile. Resta quindi da capire che cosa vede Google mentre il sito è spento.
Cosa legge Googlebot in quei giorni
Dal lato del crawler il quadro è abbastanza chiaro. Nella documentazione di Google sui codici di stato HTTP si legge che gli errori server della famiglia 5xx e il codice 429 (“troppe richieste”) spingono i crawler di Google a rallentare temporaneamente la scansione. In pratica Googlebot trova il server in difficoltà, riduce le visite e ripassa più tardi.
La differenza tra le varie risposte è tutta qui. Un 503 dice esplicitamente: chiuso per ora, torna dopo. Un 404 dice un’altra cosa, cioè che quella pagina non c’è. Un timeout non dice niente: il crawler aspetta, non riceve risposta e non sa se il sito sia in pausa, rotto o abbandonato. Il 503 è l’unico dei tre che comunica in modo esplicito che la pausa è temporanea, mentre gli altri lasciano a Google il compito di interpretare il silenzio o l’errore.
Per chi gestisce un e-commerce o un sito su WordPress o Magento, quindi, un fermo per sicurezza è anche una decisione che pesa sulla SEO. Il momento peggiore per scoprire come si serve un 503 dal DNS o dalla CDN è quello in cui arriva un’allerta e il sito va spento in fretta. Ha più senso chiarirlo prima con chi gestisce hosting, DNS o CDN, in modo da poter staccare la spina senza che Google scambi una chiusura temporanea per un abbandono.
