1. Home
  2. Blog
  3. Sito in manutenzione e SEO

Sito in manutenzione e SEO: quanto puoi stare offline senza perdere Google

Dopo gli aggiornamenti d'emergenza di PHP del 21 ottobre molti siti sono stati spenti in fretta. Per Google qualche ora di chiusura non è un problema: lo diventano il codice di stato sbagliato, il robots.txt in errore e un 503 lasciato acceso per giorni.

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.

La risposta breve

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:

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:

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.

Prima di attivare la manutenzione, prova la regola con curl: le pagine devono rispondere 503, il robots.txt 200.

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:

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.

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

↗Fonti

Analisi gratuita

Il tuo sito è pronto per la prossima manutenzione?

Controlliamo come risponde il tuo sito a Google durante una chiusura, prepariamo con il tuo fornitore una pagina 503 statica già provata e verifichiamo in Search Console che scansione e sicurezza siano tornate a posto. Prima call di 30 minuti, senza impegno.

Parliamoci →