Mettere il sito in manutenzione è una decisione che quasi tutte le imprese prima o poi devono prendere, e la domanda SEO è sempre la stessa: quanto posso restare offline senza perdere posizioni su Google? Questa settimana è diventata urgente. Il 21 ottobre PHP, il linguaggio su cui girano WordPress e buona parte dei siti aziendali, ha pubblicato aggiornamenti d'emergenza per due vulnerabilità critiche, e molti gestori hanno spento i siti per installarli. Qui trovi i tempi documentati da Google, l'errore sul robots.txt che ferma la scansione e una procedura divisa tra titolare e fornitore.
Un sito in manutenzione di norma non perde posizionamento se risponde con il codice HTTP 503 e il file robots.txt continua a rispondere normalmente. Google indica il 503 per chiusure di uno o due giorni al massimo; oltre, conviene una home page informativa con codice 200. Da evitare: pagine di cortesia con 200, 404 e robots.txt in errore.
01Cosa è successo con PHP2Shell e perché riguarda la SEO
Il 21 ottobre è uscito l'avviso di sicurezza ufficiale: due vulnerabilità con punteggio CVSS 9.2 (CVE-2026-109618 e CVE-2026-109619), soprannominate PHP2Shell, permettono di eseguire codice sul server da remoto senza autenticazione (in inglese «unauthenticated remote code execution»). Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Il progetto PHP scrive che non esistono mitigazioni complete e che aggiornare è l'unica scelta sicura; PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti ufficiali.
Secondo Search Engine Roundtable molti siti sono stati spenti per precauzione durante l'aggiornamento, e The Hacker News riporta tentativi di sfruttamento osservati già il 21 ottobre. Lo stesso giorno John Mueller di Google ha scritto su Bluesky: «If you're taking PHP sites down to schedule time to deal with "unplanned updates", use HTTP 503 instead of letting responses time out / 404 / 500», aggiungendo che il 503 si può servire fuori da PHP, puntando il DNS altrove o dalla CDN. Il dettaglio conta: se il problema è PHP, la pagina di manutenzione non può dipendere da PHP.
02Cosa vede Google quando il sito è in manutenzione
Googlebot non guarda la pagina di cortesia: legge il codice di stato HTTP, il numero di tre cifre con cui il server dichiara l'esito della richiesta. Ecco cosa dice la documentazione di Google sui codici di stato, con il nostro ordine dal più adatto al meno adatto per una chiusura temporanea:
- 503"Servizio non disponibile". Google rallenta la scansione e conserva per un po' le pagine già indicizzate, che però vengono tolte se l'errore persiste. È il codice che Google raccomanda per la manutenzione e l'unico pensato per accompagnarsi all'intestazione
Retry-After. - 500 e timeoutPer Googlebot gli altri errori 5xx hanno effetti simili al 503: scansione rallentata, pagine conservate per un po'. Un server che non risponde affatto è trattato come errore di rete. Il rischio vero è che siano errori casuali che nessuno controlla, e che colpiscano anche il robots.txt.
- 404 e 410Dicono che la pagina non esiste più. Le pagine escono dall'indice e, alla riapertura, devono essere riscansionate per rientrare.
- 200Il più insidioso. Il server dice "tutto bene" e mostra il messaggio di manutenzione: Google può indicizzare quel testo al posto dei tuoi contenuti. Mueller lo ricordava già nel 2013, come riporta Search Engine Journal.
C'è un secondo meccanismo, meno noto. Secondo la stessa documentazione, gli errori 5xx e il codice 429 ("troppe richieste") fanno rallentare la scansione dell'intero sito, non solo delle pagine in errore. Quando il server torna a rispondere con 200, Google aumenta gradualmente la velocità di scansione. Nelle tabelle mostrate da Gary Illyes a Barcellona, riportate da Search Engine Roundtable, la capacità di scansione si adegua di solito in un tempo tra 4 ore e 1-2 settimane, e nei casi più lenti, in fase di recupero, in 1-3 settimane. Per un sito di poche centinaia di pagine questo rallentamento passa quasi sempre inosservato.
03Quanto tempo puoi restare in manutenzione senza perdere posizioni?
Le guide italiane più lette dicono "poco tempo" o "non più di qualche giorno". Le indicazioni di Google, messe insieme, danno un criterio per fasce di durata:
- MinutiNessun effetto da temere. Alla domanda sui 503 intermittenti, Gary Illyes ha risposto nel 2024 che un 503 prolungato riduce la scansione, ma che «10-15 minutes every now and then is not "extended" by any means» (SEJ).
- Ore, fino a 1-2 giorniÈ la finestra per cui Google indica il 503, sia nella guida su come mettere in pausa un sito sia in quella su come ridurre la frequenza di scansione, che sconsiglia di andare oltre 1-2 giorni.
- Più giorniQui il rischio diventa concreto: se Googlebot trova il 503 sullo stesso URL per più giorni, scrive Google, l'URL può essere tolto dall'indice. La guida definisce la chiusura dell'intero sito una misura estrema, da usare per alcuni giorni al massimo.
- SettimaneGoogle avverte che anche poche settimane di chiusura possono avere effetti negativi sull'indicizzazione. Per chiusure lunghe suggerisce una home page indicizzabile con codice 200 che spieghi la situazione, oppure di limitare le funzioni (per esempio disattivare il carrello) lasciando online il resto.
Due precisazioni. Primo, "tolto dall'indice" non significa perso per sempre: le pagine possono rientrare, ma devono essere riscansionate e i tempi non sono garantiti. Secondo, i numeri di Google sono indicazioni operative, non soglie esatte. Il nostro criterio: sotto le 24 ore il 503 è la scelta corretta; se prevedi più di due giorni, prepara fin da subito la versione ridotta del sito invece di sperare che la manutenzione finisca prima.
04L'errore che ferma tutto: il robots.txt in 503
La soluzione più semplice è una regola che risponde 503 a ogni richiesta. Così però risponde 503 anche /robots.txt, il file che dice ai crawler cosa possono scansionare, e Google lo sconsiglia esplicitamente nella guida sulla messa in pausa, e la ragione sta nella specifica di Google sul robots.txt:
- Prime 12 oreSe robots.txt risponde con un errore 5xx, Google smette di scansionare tutto il sito e continua solo a riprovare a leggere il file. Timeout e connessioni interrotte valgono come errori del server.
- Fino a 30 giorniDopo le prime 12 ore Google usa l'ultima versione del file letta correttamente, se ne ha una. Il blocco totale riguarda quindi soprattutto le prime 12 ore, cioè proprio la durata tipica di una manutenzione d'emergenza.
- Altri crawlerLo standard RFC 9309 è più netto: con un robots.txt in errore 5xx il crawler deve considerare il sito interamente vietato.
In pratica, la regola di manutenzione deve avere un'eccezione: robots.txt risponde 200 con il suo contenuto normale, tutto il resto risponde 503. Altro errore frequente: aggiungere Disallow: / al robots.txt "per non far vedere il cantiere a Google". Google lo sconsiglia: il blocco ferma la scansione, ma non dice a Google che la chiusura è temporanea.
05Come mettere il sito in manutenzione senza danni SEO: la procedura
Il primo passo e l'ultimo li fa il titolare; gli altri richiedono accesso all'hosting, al server o alla CDN e sono lavoro del fornitore.
- 1 · TitolareChiedi se lo spegnimento serve davvero. Su un hosting condiviso la patch la installa il provider, ma su molti servizi la versione di PHP la scegli tu dal pannello: se sei su 8.1 o precedente devi passare a un ramo supportato. Aggiornare WordPress o i plugin non aggiorna PHP, come ricorda Malwarebytes. Chiedi conferma scritta della versione installata, non solo programmata. Se è corretta non c'è niente da spegnere; resta da controllare che il sito non sia stato compromesso prima (passo 7).
- 2 · FornitoreServi il 503 da un livello che resta acceso. Un plugin di manutenzione di WordPress gira su PHP, quindi qui non basta: il 503 va servito dalla configurazione del web server (Apache o Nginx), da una regola della CDN o da un server temporaneo, come indicato da Mueller.
- 3 · FornitorePrepara la pagina come chiede Google. HTML statico, quasi nessuna risorsa esterna, intestazione
Retry-Aftercon la durata in secondi (Retry-After: 7200per due ore) o la data di riapertura stimata, e nel testo cosa può fare il visitatore: quando torna il sito, un telefono o una mail per le urgenze. - 4 · FornitoreLascia fuori robots.txt. Deve continuare a rispondere 200 con il contenuto di sempre. Niente
noindex, niente 403, 404 o 410, niente blocchi geografici: Google ricorda che scansiona in genere dagli Stati Uniti, quindi un sito "aperto solo all'Italia" gli risulta chiuso. - 5 · FornitoreVerifica il codice, non lo schermo. Da terminale,
curl -I https://www.tuodominio.it/una-pagina/deve mostrare503, ecurl -I https://www.tuodominio.it/robots.txtdeve mostrare200. Alcuni plugin e alcune guide tra i primi risultati in italiano propongono di reindirizzare tutto a una pagina maintenance.html: in quel caso Google riceve un redirect verso una pagina che risponde 200, che può essere trattata come soft 404 o indicizzata come contenuto. - 6 · FornitoreDopo la riapertura, controlla Search Console. Nelle Statistiche di scansione (Impostazioni) le risposte 5xx devono sparire e le richieste tornare ai livelli precedenti; con il Controllo URL verifica due o tre pagine importanti. Se la manutenzione è durata più giorni, richiedi l'indicizzazione delle pagine principali dal Controllo URL.
- 7 · TitolareApri il rapporto Problemi di sicurezza. Se il sito è stato attaccato prima della correzione, il rapporto Problemi di sicurezza di Search Console lo segnala e Google può mostrare avvisi nei risultati e nel browser. Dopo la pulizia si chiede un riesame, che secondo Google richiede di solito da alcuni giorni ad alcune settimane.
Due scenari tipici. Uno studio di commercialisti di Treviglio su hosting condiviso di solito non deve spegnere niente: verifica nel pannello di essere su una versione di PHP supportata, ottiene dal provider la conferma della patch e controlla il rapporto sicurezza nei giorni successivi. Un negozio online di Seriate su un server virtuale con PHP fuori supporto può avere buone ragioni per spegnere: il fornitore serve il 503 dalla CDN, con robots.txt escluso, e se l'aggiornamento richiede più di un giorno passa a una home statica con codice 200 che spiega come ordinare per telefono.
06Sito offline, AI Overview e ChatGPT: cosa cambia
Per AI Overview e AI Mode il discorso coincide con la SEO classica: Google scrive che per comparire come link nelle funzioni IA una pagina deve essere indicizzata e idonea allo snippet, come spiegato nel nostro articolo su come comparire nelle AI Overview. Una manutenzione breve con 503 non cambia nulla; pagine uscite dall'indice dopo giorni di errori escono anche da lì, finché non vengono riscansionate.
Per ChatGPT, Claude e Perplexity la situazione è meno documentata. Nessuno dei tre spiega come i suoi crawler trattano un 503, quindi non conviene dare per scontato che si comportino come Googlebot. Due cose però si possono dire. La prima: se robots.txt risponde con un errore 5xx, lo standard RFC 9309 prevede che un crawler conforme consideri il sito tutto vietato. OpenAI dichiara di rispettare robots.txt ma non documenta come gestisce un 5xx su quel file, quindi è prudente assumere il caso peggiore anche per OAI-SearchBot, di cui abbiamo parlato nell'articolo su come indicizzare il sito su ChatGPT. La seconda è un'ipotesi ragionevole: quando un assistente apre una pagina in tempo reale per rispondere a un utente (ChatGPT-User, Claude-User, Perplexity-User) e trova il sito chiuso, per quella risposta la tua pagina semplicemente non c'è.
07Cosa ne pensiamo
Con una vulnerabilità che permette di prendere il controllo del server, la sicurezza viene prima della SEO: qualche ora di 503 fatto bene costa quasi nulla al posizionamento, un sito compromesso costa molto di più. Se il tuo fornitore ti chiede di spegnere il sito per aggiornare, la risposta giusta è sì, a patto che lo faccia nel modo descritto sopra.
Il rischio SEO vero, nel nostro lavoro di SEO tecnico, raramente è la durata della manutenzione: quasi sempre è il codice sbagliato. Pagine di cortesia con 200, redirect verso una pagina statica, robots.txt che finisce dentro la regola del 503, plugin di sicurezza che rispondono 403 a Googlebot. Per questo consigliamo a ogni impresa di avere una pagina di manutenzione statica già pronta sulla CDN o sul server, provata con curl, da attivare in pochi minuti. Va preparata in un giorno tranquillo, perché in piena emergenza nessuno controlla i codici di stato. E se la manutenzione si allunga oltre il previsto, è meglio passare per tempo a una versione ridotta del sito con codice 200 che lasciare il 503 acceso per una settimana.
Per capire se un calo dopo la riapertura dipende dalla manutenzione o da altro, parti dai tempi di recupero della scansione descritti nel nostro articolo sui tempi di indicizzazione di Google. Le tabelle di Illyes indicano 1-3 settimane nei casi più lenti: noi usiamo le tre settimane come soglia di lavoro, oltre la quale cerchiamo altre cause nelle Statistiche di scansione. Il traffico va letto a parte, nel rapporto Prestazioni, perché scansione e posizionamento non si muovono insieme.
→In sintesi
Per una manutenzione breve servi un 503 da un livello che resta acceso, con robots.txt escluso dalla regola, e verificalo con curl; oltre i due giorni passa a una versione ridotta del sito con codice 200. Dopo la riapertura controlla Statistiche di scansione e Problemi di sicurezza in Search Console.
FAQDomande frequenti su sito in manutenzione e SEO
-
→Mettere il sito in manutenzione fa perdere posizionamento?
Di norma no, se la chiusura è breve e il server risponde con il codice 503. Google conserva le pagine già indicizzate e rallenta la scansione finché il sito non torna disponibile. Il posizionamento è a rischio se il 503 dura più giorni o se la pagina di manutenzione usa codici sbagliati come 200 o 404.
-
→Quanto tempo può restare offline un sito senza perdere posizioni su Google?
Google indica il 503 per chiusure di uno o due giorni al massimo. Se trova il 503 sullo stesso URL per più giorni, può togliere l'URL dall'indice, e anche poche settimane di chiusura possono danneggiare l'indicizzazione. Per periodi più lunghi è meglio tenere online una home page informativa con codice 200.
-
→Che codice HTTP deve restituire una pagina di manutenzione?
Il codice 503 Service Unavailable, possibilmente con l'intestazione Retry-After che indica quando il sito tornerà disponibile. Il file robots.txt invece deve continuare a rispondere 200: se risponde con un errore 5xx, Google interrompe la scansione dell'intero sito.
-
→La modalità manutenzione di WordPress va bene per la SEO?
Va bene se restituisce davvero 503, e lo si verifica con curl o con uno strumento che mostra il codice di stato. Alcuni plugin reindirizzano a una pagina che risponde 200, ed è da evitare. Se il problema da risolvere è PHP stesso, il 503 va servito dal web server o dalla CDN.
-
→Devo bloccare Google con robots.txt durante la manutenzione?
No. Google sconsiglia di bloccare la scansione con robots.txt durante una chiusura temporanea, e anche di usare noindex o lo strumento di rimozione degli URL. Il segnale corretto è il 503 sulle pagine, con robots.txt che resta accessibile e invariato.
↗Fonti
- PHPPHP News Archive 2026: Security advisory, critical remote code execution vulnerabilities (21 ottobre 2026)
- GoogleDisattivare o mettere in pausa temporaneamente un sito web
- GoogleReduce the Google crawl rate
- GoogleHow HTTP status codes affect Google's crawlers
- GoogleHow Google interprets the robots.txt specification
- GoogleSearch Console: report Problemi di sicurezza
- GoogleJohn Mueller su Bluesky (21 ottobre 2026)
- IETFRFC 9309: Robots Exclusion Protocol
- SEJSearch Engine Journal: Google Reminds Sites To Serve A 503 During PHP Patch Downtime (21 ottobre 2026)
- SEJSearch Engine Journal: Google on the SEO impact of 503 status codes (aprile 2024)
- SERSearch Engine Roundtable: Google On Taking Sites Down When Fixing PHP2Shell (21 ottobre 2026)
- SERSearch Engine Roundtable: Google Search data on crawling, indexing and serving timelines (5 ottobre 2026)
- SicurezzaThe Hacker News: PHP issues emergency patches for two critical PHP2Shell RCE flaws
- SicurezzaMalwarebytes: PHP2Shell, why websites are going offline for emergency security updates