Pagine di ricerca interna: perché Google può segnalarti come hackerato (2026)

Google ha appena tolto dal manuale una regola del 2007: non sei più obbligato a bloccare le pagine di ricerca interna del tuo sito. Ma nello stesso podcast in cui lo dice, John Mueller spiega perché dovresti bloccarle lo stesso — e il motivo è molto più serio di una questione di regolamento. Se la barra di ricerca del tuo sito genera pagine indicizzabili, chiunque può usarla per creare sul tuo dominio migliaia di pagine con termini di farmaci, casinò o contenuti per adulti e un numero di telefono. E quando Google se ne accorge, in Search Console il tuo sito viene segnalato come hackerato. Senza che nessuno ti abbia hackerato.

In breve

• Cosa è cambiato il 31 luglio 2026
• Il primo problema: la ricerca interna è uno spazio infinito
• Il problema serio: la tua barra di ricerca è un megafono per gli spammer
• Perché riguarda anche la tua visibilità nelle AI
• Cosa fare: la checklist da 15 minuti
• Le due cose da non fare mai
• L’eccezione: le pagine categoria
• Il fratello maggiore del problema: i filtri dell’e-commerce
• Come tenerlo sotto controllo nel tempo
• Domande frequenti
• Cosa significa per le aziende italiane

Cosa è cambiato il 31 luglio 2026

Il 31 luglio Google Search Central ha pubblicato l’episodio 113 del suo podcast Search Off the Record, intitolato “Should you block your Search result pages?”. Parlano John Mueller e Martin Splitt, cioè le due persone che in Google si occupano di spiegare la Ricerca a chi fa siti.

Mueller dice una cosa che pochi si aspettavano. Nelle vecchie webmaster guidelines — quelle nate nel 2007 — le pagine di risultati della ricerca interna erano elencate tra le cose da bloccare. Classificate come “contenuto generato automaticamente” e come “spazio infinito”. Oggi quella riga non c’è più nelle Search Essentials, il documento che ha sostituito le linee guida.

Le sue parole sono chiare: oggi non è più elencato nelle policy, ma resta qualcosa che ha senso fare per motivi puramente tecnici. E aggiunge la frase che disinnesca il panico: non è che pensiamo che il tuo sito sia spam se lasci indicizzare le pagine di ricerca. È solo che sei molto inefficiente.

Quindi il titolo onesto della notizia è questo: è caduto l’obbligo, è rimasta la raccomandazione. E la raccomandazione poggia su due gambe. Una è noiosa e tecnica. L’altra è quella per cui ho deciso di scrivere questo pezzo.

Il primo problema: la ricerca interna è uno spazio infinito

Ogni sito ha una barra di ricerca. Quasi nessuno ci pensa come a un generatore di pagine, ma è esattamente quello che è.

Quando un visitatore cerca “scarpe rosse”, il tuo sito produce una pagina all’indirizzo tuosito.it/?s=scarpe+rosse. Quella pagina esiste. Ha un URL. È raggiungibile. E se da qualche parte — un link su un forum, un commento, una scansione automatica — quell’indirizzo viene scoperto, Googlebot lo tratta come qualsiasi altra pagina del tuo sito.

Il punto che Mueller sottolinea è che Google non sa che è una pagina speciale. Vede un URL, lo segue, prova a scansionarlo. E poi segue i link che trova dentro. Se il tuo sito ha filtri per categoria, ordinamento alfabetico, ordinamento per data, il numero di combinazioni possibili esplode. Mueller fa l’esempio più grafico: immagina cosa succede quando troviamo cento milioni di pagine nuove sul tuo sito.

Perché il tuo server se ne accorge prima di Google

C’è un dettaglio tecnico che vale più di mille discorsi sul crawl budget: le pagine di ricerca non sono quasi mai in cache.

Una pagina normale del tuo sito, con LiteSpeed o WP Rocket o qualsiasi sistema di cache, viene servita già pronta. Una pagina di ricerca no: ogni volta il sistema deve interrogare il database, capire quali contenuti corrispondono, ordinarli, generare gli estratti. È il tipo di lavoro più costoso che il tuo server possa fare.

Moltiplicalo per qualche migliaio di richieste al giorno da parte di un crawler e hai un sito lento per i clienti veri. Splitt lo dice con parole semplici: un algoritmo di ricerca interno inefficiente può dare parecchio lavoro al server e rendere il sito più lento per tutti gli altri.

La reazione tipica dell’hosting condiviso italiano, a quel punto, è una sola: throttling, o blocco del bot. Con conseguenze che ricadono su tutto il sito, non solo sulle pagine di ricerca.

Google prova a riconoscere il pattern e a smettere. Ma Mueller è onesto anche su questo: non c’è nessun punto in Search Console dove ti diciamo “guarda, l’abbiamo trovato e l’abbiamo sistemato per te”. A volte ci mette un po’. E quanto ti fa male dipende da com’è messo il tuo hosting.

Il problema serio: la tua barra di ricerca è un megafono per gli spammer

Fin qui è manutenzione. La parte che dovrebbe farti aprire il sito adesso è un’altra.

Mueller la introduce così: c’è un punto in cui puoi davvero avere problemi di qualità, ed è quando permetti alle persone di cercare cose che non c’entrano niente con il tuo sito, la pagina dei risultati contiene quei termini ed è indicizzabile.

Tradotto nel concreto: la tua pagina di ricerca, quasi sempre, stampa in cima un titolo tipo “Risultati della ricerca per: [quello che ha scritto l’utente]”. Non importa cosa ha scritto. Il tuo sito lo pubblica.

Come funziona l’attacco, passo per passo

Non serve nessuna intrusione. Nessuna password rubata, nessun plugin bucato. L’attacco usa una funzione che hai messo tu, e che funziona esattamente come dovrebbe.

1. Un gruppo organizzato scansiona il web cercando i CMS più diffusi — WordPress, Drupal, Joomla — che non hanno le pagine di ricerca bloccate. Il pattern degli URL è sempre lo stesso, quindi trovarli è banale.
2. Generano migliaia di URL di ricerca sul tuo dominio, ognuno con dentro termini di farmaci, casinò online, contenuti per adulti, più un numero di telefono, un contatto Telegram o un indirizzo.
3. Da altri siti puntano link verso quegli indirizzi, così Googlebot li scopre e li scansiona.
4. Google indicizza. Il risultato è che nelle SERP compare una pagina del tuo dominio, con il tuo nome, che promuove farmaci illegali e un numero di telefono.

Mueller lo spiega con una frase che merita di essere letta due volte: non è che qualcuno ti ha hackerato il sito per fare questo, perché il tuo sito lo sta facendo liberamente. È tutto lì. Il tuo sito risponde a qualunque cosa gli venga chiesta, e la pubblica.

L’obiettivo dello spammer non è portare traffico da te. È usare l’autorevolezza del tuo dominio — quella che ti sei costruito in dieci anni — per far comparire il suo numero di telefono sotto un nome di cui la gente si fida.

Cosa vedi in Search Console

Quando Google riconosce il fenomeno su larga scala, la conseguenza è quella che Mueller descrive senza giri di parole: potremmo segnalarlo come hackerato, quindi in Search Console potresti vederlo classificato come hacked.

Ecco il paradosso: nessuno è entrato nel tuo sito, ma Google ti tratta come un sito compromesso. E la notifica di sicurezza in Search Console non è una faccenda tecnica di poco conto: è il tipo di segnale che può accompagnarsi a un avviso nel browser, alla perdita di visibilità e a una figura pessima se il tuo cliente cerca il tuo nome su Google in quel momento.

Google prova a intervenire da solo. Ma Mueller mette due paletti importanti. Il primo: forse Google si è occupato solo di una parte del problema, solo di alcune delle query problematiche. Il secondo: non è garantito che ce ne accorgiamo subito, magari ci vuole un mese. Un mese in cui la pagina esiste, è indicizzata e la può trovare chiunque — compreso un tuo cliente.

Se questa dinamica ti sembra familiare, è la stessa logica che ho raccontato in nascondere una pagina da Google: perché robots.txt non basta. Cambia il meccanismo, non cambia la morale: quello che credi di controllare sul tuo sito, spesso, non lo stai controllando.

Perché riguarda anche la tua visibilità nelle AI

Qui aggiungo la parte che nel podcast non c’è, perché è il mio lavoro e perché nel 2026 è la domanda che mi fanno tutti.

I modelli di AI — ChatGPT, Gemini, le AI Overview di Google — costruiscono l’idea che hanno della tua azienda leggendo il web. Leggono il tuo sito, leggono chi parla di te, e provano a capire chi sei, cosa vendi, se sei affidabile.

Un sito con migliaia di pagine spazzatura indicizzate manda tre segnali, tutti sbagliati:

• Confonde l’entità. Se sul tuo dominio esistono pagine che parlano di farmaci e casinò, il legame tra il tuo nome e il tuo settore si sporca. E le AI, come ho scritto in le AI non riescono a verificare la tua azienda, non consigliano l’azienda migliore: consigliano quella che riescono a verificare e a incasellare senza dubbi.
• Diluisce le pagine che contano. Il crawler che sta scansionando la tua pagina di ricerca numero 40.000 non sta scansionando la tua scheda prodotto nuova. Vale per Googlebot e vale per i crawler di OpenAI e Anthropic, che hanno budget di scansione molto più stretti.
• Rompe la fiducia. Un flag “hacked” in Search Console è un segnale di qualità negativo esplicito su tutto il dominio.

Non è una questione di GEO avanzata. È igiene. Ma è esattamente il tipo di igiene che decide chi viene citato e chi no.

Cosa fare: la checklist da 15 minuti

1. Controlla se sei già esposto

Vai su Google e cerca, uno per uno:

• site:tuosito.it inurl:?s=
• site:tuosito.it inurl:search
• site:tuosito.it viagra (o un altro termine palesemente fuori tema: casinò, bitcoin, prestiti)

Se escono risultati che non hai mai scritto tu, il problema è già in corso. Se non esce niente ma le pagine di ricerca sono indicizzate, sei esposto ma non ancora colpito. In entrambi i casi si chiude allo stesso modo.

Controlla anche in Search Console, sezione Indicizzazione delle pagine: se vedi migliaia di URL “scansionati ma non indicizzati” con parametri strani, hai la conferma dal lato crawl.

2. Blocca con robots.txt (la via più pulita)

Mueller è netto: usa e basta il robots.txt e di’ che tutto quello che sta dentro la ricerca è bloccato. E dà anche un’indicazione precisa su come scrivere la regola, cioè larga e una sola, non venti righe che provano a coprire ogni variante.

Su WordPress e WooCommerce, che è il caso della quasi totalità delle PMI italiane con cui lavoro, la ricerca interna vive su /?s=. Le righe da aggiungere al robots.txt sono queste:

User-agent: *
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search/
Disallow: /page/*/?s=

Se usi Rank Math o Yoast, il robots.txt lo modifichi dal pannello senza toccare FTP (in Rank Math: Impostazioni generali → Modifica robots.txt). Se il file è fisico sul server, lo trovi nella root del sito.

Una nota sul perché la regola deve essere larga ma non troppo: bloccare /*?s= intercetta tutte le query, mentre una regola tipo /search senza barra rischia di bloccare anche una pagina legittima chiamata, che so, ricerca-fornitori.php. Il criterio di Mueller è la manutenibilità: una regola pulita che copre tutto il pattern è più facile da mantenere e da capire di un labirinto di testo.

3. Se hai già pagine spam indicizzate

Attenzione all’ordine delle operazioni, perché qui si sbaglia spesso.

Se blocchi subito con robots.txt, Google non potrà più scansionare quelle pagine — e quindi non potrà nemmeno vedere che sono sparite. Restano nell’indice più a lungo, magari come URL nudi senza titolo né descrizione.

La sequenza sensata è: prima fai in modo che quelle pagine restituiscano un noindex (tutti i plugin SEO permettono di impostare “no index” sulle pagine di ricerca con un interruttore), lasci che Google le riscansiona e le tolga, e solo dopo — passate un paio di settimane — metti il blocco in robots.txt per chiudere anche la scansione.

Se invece parti pulito, cioè non hai nulla di indicizzato, vai direttamente di robots.txt. È più semplice e ti fa risparmiare crawl budget da subito.

4. Metti un tetto alla tua ricerca interna

Due accortezze che nessun plugin fa da solo e che valgono più di tante ottimizzazioni:

• Non stampare la query dell’utente nel <title> e nell’H1, o almeno filtrala. Se la pagina dice “Risultati per: [testo libero]”, stai dando allo spammer esattamente la vetrina che cerca.
• Limita la lunghezza della query e scarta quelle che contengono URL o numeri di telefono. Sono venti righe di codice nel functions.php e chiudono il caso alla radice.

Le due cose da non fare mai

Mueller nel podcast smonta due soluzioni che sembrano ovvie e che invece peggiorano la situazione. Le riporto perché le vedo applicate spesso.

Non usare lo strumento di rimozione URL di Search Console come soluzione. Filtra i risultati, non ferma la scansione. Splitt lo liquida così: non risolve il problema vero, nasconde solo il sintomo. E dopo sei mesi le rimozioni scadono e tutto torna com’era. Va bene come pronto soccorso quando hai una pagina imbarazzante in SERP e devi guadagnare tempo, non come cura.

Non servire un errore 500 sugli URL di ricerca. Questa è la peggiore. Mueller è categorico: i nostri sistemi lo riconoscono e dicono, ok, abbiamo provato a scansionare e il server si è rotto, quindi forse stiamo scansionando troppo. Il risultato è che Google riduce la scansione di tutto il sito, comprese le pagine che ti interessano davvero. Il 404 è meno dannoso, ma resta una toppa.

L’eccezione: le pagine categoria

Prima di bloccare tutto quello che assomiglia a una ricerca, un controllo.

Alcuni CMS usano il motore di ricerca interno per generare le pagine di categoria o di tag. Mueller cita Blogger: clicchi su un’etichetta e quello che parte, tecnicamente, è una query di ricerca. In quel caso bloccare significa cancellare dall’indice pagine che valgono.

Perché le pagine categoria, dice Mueller, sono in generale molto preziose: rendono molto più facile per i motori scansionare un sito e capirne il contesto. Su un e-commerce WooCommerce, la categoria di prodotto è spesso la pagina che posiziona meglio dell’intero catalogo.

La regola pratica: guarda l’URL. Se le categorie hanno un percorso proprio (/categoria-prodotto/, /tag/) e la ricerca ne ha un altro (/?s=), blocchi la seconda e lasci in pace la prima. Se invece nel tuo sito coincidono, non bloccare: costruisci pagine categoria vere, con un testo che spiega perché quel gruppo di prodotti esiste.

Il fratello maggiore del problema: i filtri del tuo e-commerce

Se hai un e-commerce, la ricerca interna è solo la metà della storia. L’altra metà si chiama navigazione a faccette, ed è il nome tecnico dei filtri laterali: colore, taglia, prezzo, marca, disponibilità.

Il meccanismo che produce lo spazio infinito è identico. Ogni combinazione di filtri genera un URL. Dieci colori per sei taglie per quattro fasce di prezzo per tre ordinamenti fanno 720 indirizzi diversi — per una sola categoria. Moltiplica per il numero di categorie e capisci perché Mueller parla di cento milioni di pagine senza fare iperbole.

La differenza rispetto alla ricerca interna è che qui non puoi bloccare tutto, perché alcune di quelle pagine servono davvero. “Scarpe da running uomo taglia 44” è una ricerca che le persone fanno, ed è una pagina che può posizionarsi. Il criterio che uso io è semplice e si regge su una domanda sola: qualcuno cerca questa combinazione su Google?

• Sì, e con volume: allora non è un filtro, è una categoria. Merita un URL pulito, un titolo scritto da un essere umano, un testo e un posto nel menu.
• No: allora è un comodo strumento per il cliente che è già sul sito, e basta. Va lasciato usabile ma tenuto fuori dall’indice, con canonical alla categoria madre o con un blocco sui parametri che non hanno valore di ricerca (ordinamento, paginazione infinita, filtri di disponibilità).

Su WooCommerce i sospetti abituali sono i parametri orderby, filter_, min_price, max_price, add-to-cart e le varianti di paginazione. Prima di scrivere qualsiasi regola, però, apri Search Console e guarda: se una di quelle URL porta impression e clic, non toccarla. Le regole si scrivono sui dati, non sui manuali.

Come tenerlo sotto controllo nel tempo

Sistemare il robots.txt una volta non basta, perché un sito si muove: cambi tema, aggiungi un plugin di ricerca avanzata, attivi una nuova lingua, e lo schema degli URL cambia sotto i tuoi piedi. Tre controlli, tre momenti diversi.

Una volta al mese, due minuti. In Search Console, apri il rapporto Indicizzazione delle pagine e guarda il totale delle pagine conosciute. Se il tuo sito ha 300 pagine vere e Google ne conosce 40.000, non serve altra diagnosi. È il singolo numero più sottovalutato di tutto lo strumento.

Una volta ogni tre mesi, dieci minuti. Rifai le ricerche site: con i termini fuori tema. Aggiungi al giro anche una lettura veloce delle statistiche di scansione (Impostazioni → Statistiche di scansione): se vedi una percentuale alta di richieste su URL con punti interrogativi e parametri, il crawler sta lavorando su niente.

Subito, ogni volta che cambi qualcosa di strutturale. Nuovo tema, nuovo plugin di ricerca, nuova lingua, migrazione: ricontrolla che il robots.txt copra ancora il pattern giusto. Un plugin di ricerca AJAX può spostare la ricerca da /?s= a un endpoint completamente diverso, e la tua regola vecchia diventa carta straccia senza avvisarti.

È lo stesso principio che vale per tutto il resto del lavoro sul sito: il controllo periodico costa poco, il recupero costa mesi.

Il trade-off onesto

Non voglio venderti un allarme più grande di quello che è.

Se hai un sito vetrina da trenta pagine, con poco traffico e nessun link in entrata sospetto, la probabilità che qualcuno ti scelga come bersaglio è bassa. Il costo di non fare niente, nella maggior parte dei casi, è un po’ di crawl budget sprecato. Non è la fine del mondo.

Ma il costo della prevenzione è quattro righe in un file di testo. Quindici minuti, zero euro, nessun rischio di rompere qualcosa se la regola è scritta bene. È uno dei rarissimi casi nel mio lavoro in cui il rapporto tra sforzo e rischio evitato non è nemmeno discutibile.

E c’è un caso in cui non è opzionale: se il tuo sito ha già qualche anno di autorevolezza, un buon profilo di link e un dominio che le persone riconoscono, sei esattamente il tipo di bersaglio che rende conveniente l’attacco. Più vale il tuo nome, più conviene a qualcun altro usarlo.

Domande frequenti

Devo per forza bloccare le pagine di ricerca interna del mio sito?

No, non è più un obbligo: dal 2026 Google non elenca più le pagine di ricerca interna tra i contenuti da bloccare nelle Search Essentials. Resta però una raccomandazione tecnica di John Mueller, per due motivi: evitare che Googlebot finisca in uno spazio di scansione infinito e impedire che la tua barra di ricerca diventi un veicolo di spam sul tuo dominio.

Google può segnalare il mio sito come hackerato per colpa della ricerca interna?

Sì. Se qualcuno genera in massa URL di ricerca sul tuo sito contenenti termini di spam — farmaci, casinò, contenuti per adulti — e quelle pagine sono indicizzabili, Google può classificarle come contenuto compromesso. Mueller ha confermato che in Search Console il sito può risultare segnalato come “hacked”, anche se nessuno è mai entrato nel tuo sistema.

Meglio robots.txt o noindex per le pagine di ricerca?

Dipende da dove parti. Se non hai nulla di indicizzato, il robots.txt è la via più pulita: impedisce la scansione, quindi risolve anche il problema di crawl budget e di carico sul server. Se hai già pagine di ricerca nell’indice, usa prima il noindex, aspetta che Google le rimuova, e solo dopo aggiungi la regola in robots.txt.

Come blocco le pagine di ricerca su WordPress e WooCommerce?

La ricerca di WordPress usa il parametro ?s=. Nel robots.txt aggiungi Disallow: /*?s= e Disallow: /search/. Con Rank Math o Yoast puoi modificare il file dal pannello di WordPress, senza toccare l’FTP. Verifica poi che le pagine categoria di WooCommerce non usino lo stesso schema di URL, perché quelle vanno lasciate scansionabili.

Serve a qualcosa lo strumento di rimozione URL di Search Console?

Solo come tampone. Nasconde gli URL dai risultati di ricerca per circa sei mesi, ma non impedisce la scansione e non elimina il problema: quando la rimozione scade, le pagine tornano. Va usato per guadagnare tempo mentre sistemi la causa, mai al posto della soluzione.

Cosa significa per le aziende italiane

Il tessuto delle PMI italiane online è fatto quasi tutto della stessa materia: WordPress, spesso WooCommerce, un tema comprato, una manciata di plugin e un hosting condiviso. È il profilo esatto che gli spammer cercano quando scandagliano il web in cerca di CMS con le pagine di ricerca aperte. Non ti scelgono perché sei tu: ti scelgono perché il tuo indirizzo risponde a uno schema riconoscibile.

La seconda cosa che riguarda noi da vicino è l’hosting. Gran parte delle aziende italiane sta su piani condivisi con risorse limitate. Un crawler che si infila in una ricerca interna non messa in cache non è un problema teorico di crawl budget: è il sito che rallenta il giovedì pomeriggio, il carrello che ci mette otto secondi, il fornitore che dice “è Google che ci sta scansionando troppo”. Chiudere quella porta è anche una questione di velocità e di conversioni, non solo di SEO.

Poi c’è la reputazione, che in Italia pesa più che altrove. Da noi si compra ancora molto per fiducia e per passaparola, soprattutto nel B2B e nel locale. Un cliente che cerca il tuo nome e trova una pagina del tuo dominio con termini farmaceutici e un numero di telefono sconosciuto non apre un ticket: chiude la scheda. E se arriva l’avviso di sicurezza del browser, il danno è immediato e ha bisogno di settimane per rientrare.

C’è infine il livello che oggi conta di più, ed è quello di cui mi occupo tutti i giorni. Nel 2026 non sei più letto solo da Googlebot: sei letto dai crawler di ChatGPT, di Gemini, dei sistemi che decidono chi citare in una risposta. Quei sistemi hanno molto meno tempo e molta meno pazienza. Un dominio con l’ottanta per cento di pagine che non dicono niente è un dominio in cui la risposta buona è più difficile da trovare — e quindi un dominio che si cita di meno. Come ho scritto in agenti AI sul tuo sito, non ti scartano perché sei caro: ti saltano perché non ti capiscono.

La buona notizia è la solita, ed è il motivo per cui continuo a ripeterla: qui non serve budget, serve ordine. Una PMI con un sito pulito, quattro righe di robots.txt scritte bene e un catalogo leggibile compete sulla stessa risposta di un concorrente dieci volte più grande e disordinato. Quindici minuti oggi valgono più di tre mesi di contenuti pubblicati sopra un sito che perde acqua.

Fonte: Google Search Central, Search Off the Record — episodio 113 “Should you block your Search result pages?”, 31 luglio 2026. Ripresa da Search Engine Journal.