Ricerca interna e SEO: le pagine dei risultati

Ricerca interna e SEO: le pagine dei risultati

Digita una parola nella casella di ricerca del tuo sito e il sistema genera all'istante una pagina nuova: un URL del tipo /cerca?q=scarpe+running oppure /search?s=scarpe-running, con sotto un elenco di risultati interni. Sono le pagine di ricerca interna, e qualsiasi sito dotato di un motore di ricerca on-site le produce in automatico, spesso senza che nessuno le abbia mai pensate come un vero contenuto. Il problema è che Google le vede comunque: se riesce a raggiungerle tramite un link o un modulo GET le scansiona, e per impostazione predefinita molte piattaforme le lasciano perfettamente indicizzabili.

Il risultato tipico è un numero enorme di URL quasi identici tra loro: un titolo generato automaticamente del tipo Risultati per: scarpe running, zero contenuto originale sopra l'elenco di link, e una combinazione teoricamente infinita di query — ogni parola, ogni variante, ogni errore di battitura digitato da un utente reale crea, in linea di principio, una nuova pagina indicizzabile. Capire quando tenere questi URL fuori dall'indice, quando invece trasformare una query in qualcosa di reale, e come sfruttare i dati che questa ricerca genera ogni giorno è il tema di questo articolo.

Cosa sono (e come riconoscerle) le pagine di ricerca interna

Le pagine di ricerca interna nascono dal motore di ricerca on-site del CMS, dell'e-commerce o del forum: un campo di testo libero collegato a un indice interno — che sia la ricerca nativa di WordPress, un database MySQL con full-text search, o un servizio dedicato come Elasticsearch o Algolia — che restituisce un elenco di contenuti pertinenti alla query digitata.

Si distinguono dalle pagine di filtro o di navigazione a faccette perché non partono da un insieme fisso di valori selezionabili come colore, taglia o fascia di prezzo: l'utente scrive qualunque cosa, quindi il numero di query possibili — e di URL generati — non è enumerabile in anticipo. Il pattern più comune usa un parametro come ?s=, ?q= o ?search=, ma alcuni sistemi creano invece percorsi apparentemente puliti come /cerca/scarpe-running/, il che le rende ancora più difficili da distinguere a colpo d'occhio dai contenuti veri del sito quando si analizzano i log o il file di sitemap.

Il problema di default: crawlabili, praticamente infinite, sottili

Se non si interviene, tre caratteristiche si sommano in modo dannoso per la SEO tecnica del sito. Primo: sono crawlabili, perché nella maggior parte delle installazioni nessuno ha mai impostato un blocco specifico per questo pattern di URL. Secondo: sono, di fatto, infinite — ogni combinazione di parole digitabile da un utente, o da un bot che prova stringhe casuali, genera un nuovo URL tecnicamente valido, spesso restituendo pagine vuote o quasi identiche tra loro. Terzo: sono sottili, nel senso letterale del termine — la pagina è un contenitore di link ad altre pagine, senza un solo paragrafo di testo originale scritto per rispondere a quella query.

  • Spreco di crawl budget: i bot spendono cicli di scansione su un numero enorme di varianti quasi identiche invece che sulle pagine che contano davvero
  • Gonfiaggio dell'indice: migliaia di URL a bassissimo valore finiscono in indice e diluiscono i segnali di qualità complessivi del dominio
  • Contenuto quasi duplicato: query diverse ma simili, come singolare e plurale o con e senza un refuso, restituiscono elenchi di risultati praticamente identici
  • Query imbarazzanti o fuori contesto: se un utente digita qualcosa di offensivo o irrilevante, quella stringa può finire indicizzata insieme al nome del tuo dominio

Perché atterrare su un'altra pagina di ricerca è una brutta esperienza

Immagina un utente che cerca su Google, clicca un risultato aspettandosi una risposta, un articolo o una scheda prodotto, e si ritrova invece su un'altra pagina di risultati — l'elenco di link generato dal motore di ricerca interno del sito che ha appena aperto. Deve cercare di nuovo, questa volta dentro un sistema che non conosce, con una qualità di ricerca quasi sempre inferiore a quella con cui è arrivato. È un passaggio a vuoto: l'utente non ha ottenuto ciò per cui ha cliccato, ha solo ottenuto un'altra lista di possibilità.

Questo è, in sostanza, il motivo per cui i motori di ricerca hanno storicamente scoraggiato l'indicizzazione delle pagine di ricerca interna: mandare un utente da una pagina di risultati a un'altra pagina di risultati non aggiunge valore, sposta soltanto il problema. Non è tanto una questione di penalizzazione algoritmica in senso stretto, quanto di allineamento con l'obiettivo stesso del motore di ricerca: restituire la risposta più diretta possibile, non un ulteriore livello di intermediazione.

La risposta di default: noindex, poi eventualmente il blocco alla scansione

La soluzione standard è semplice da descrivere e va applicata a livello di template, non pagina per pagina: aggiungere un tag meta robots con valore noindex a ogni pagina generata dalla ricerca interna. Trattandosi di pagine HTML renderizzate, e non di file come PDF o immagini, il meta tag nel head è lo strumento corretto; una singola modifica al template dei risultati di ricerca copre automaticamente ogni query possibile, presente e futura.

L'ordine delle operazioni conta. Il primo passo è sempre il noindex, e va lasciato lavorare: Google deve poter scansionare quelle pagine per leggere il tag e rimuoverle dall'indice. Solo dopo aver verificato che non compaiono più nei risultati si può valutare un secondo passo, cioè bloccare la scansione del pattern di URL nel file robots.txt, così da smettere di far sprecare crawl budget ai bot su uno spazio di parametri virtualmente infinito. Fare l'inverso è un errore classico: bloccare la scansione prima che il noindex abbia avuto effetto impedisce a Google di rivedere quelle pagine e vedere il tag, e un URL già indicizzato può restare intrappolato in indice a tempo indeterminato, mostrato in SERP come bloccato dal file robots.txt, senza nemmeno una descrizione.

L'eccezione: quando una query ad alta domanda merita una landing page vera

Qui entra in gioco il giudizio, non la regola automatica. Se i dati di ricerca interna mostrano che una query specifica ricorre con costanza, segno di una domanda reale e ripetuta, la risposta giusta non è provare a far posizionare la pagina di risultati grezza. La risposta è costruire una pagina dedicata, diversa nella sostanza anche se serve la stessa intenzione di ricerca.

Una landing page curata ha caratteristiche che la pagina di ricerca interna non avrà mai: un URL stabile e leggibile invece di un parametro di query, un'introduzione editoriale scritta per inquadrare l'argomento, contenuto originale genuino oltre all'elenco di elementi correlati, e una gestione SEO ordinaria, con meta description scritta ad hoc, canonical su se stessa e inclusione in sitemap. Un e-commerce che vede ricorrere spesso una query come scarpe running larghe non deve sperare che la pagina di ricerca con quella stringa si posizioni: non lo farà, ed è corretto che non lo faccia. Deve invece costruire una pagina reale, per esempio dedicata alle scarpe running larghe, con un paragrafo introduttivo che spiega il problema della vestibilità, una selezione curata di prodotti e tutto ciò che rende una pagina di categoria una pagina vera.

È lo stesso principio, applicato a un caso diverso, delle pagine di filtro o di navigazione a faccette: alcune combinazioni meritano di uscire dall'anonimato del parametro ed entrare a far parte della struttura indicizzabile del sito, altre no. La differenza qui è che il punto di partenza non è un filtro predefinito ma una stringa di testo libero: il segnale che la merita arriva dai dati di ricerca stessi, non da un catalogo di attributi già noti.

I dati di ricerca interna: la fonte di insight più sottoutilizzata che hai già

Ogni query digitata nella casella di ricerca del tuo sito è un segnale di prima mano su una domanda insoddisfatta o su un fallimento di navigazione: qualcosa che l'utente voleva e che il sito non gli ha dato, o non è riuscito a fargli trovare facilmente. Pochi team lo trattano come quello che è, cioè una fonte di keyword research gratuita, già filtrata per intento reale, generata dalle persone che sono già arrivate sul tuo dominio.

Lo stesso elenco di query alimenta anche la decisione, descritta nella sezione precedente, tra lasciare una pagina in noindex o trasformarla in una landing page dedicata. In pratica, ecco i segnali più utili da monitorare con regolarità:

  • Query a zero risultati: indicano lacune dirette nel catalogo o nei contenuti, candidati immediati per nuove pagine, prodotti o articoli
  • Query ad alta frequenza che portano a una pagina esistente ma continuano a essere cercate: spesso un sintomo di problemi di reperibilità, come etichette di menu poco chiare o link interni deboli
  • Formulazioni ricorrenti: il linguaggio reale usato dai visitatori, utile per titoli, intestazioni e testo on-page, spesso diverso dal gergo interno che usa il team
  • Ricerche seguite da nessun click sui risultati: segnalano un disallineamento tra quello che l'utente intendeva e quello che il motore di ricerca interno gli ha restituito

Non trascurare l'usabilità della ricerca in sé

Tutte le decisioni SEO di questo articolo riguardano se e come indicizzare l'output della ricerca interna. Restano indipendenti da un'altra domanda, altrettanto importante: la casella di ricerca funziona bene per chi la usa in questo momento? Che la pagina dei risultati sia in noindex o no, l'utente che l'ha appena aperta è una persona reale, presente sul sito, spesso più vicina alla conversione di chi sta ancora navigando i menu.

Le due discipline, decidere cosa indicizzare e rendere la ricerca utile a chi la usa, vanno affrontate entrambe: nessuna sostituisce l'altra. Nella pratica, significa lavorare su alcuni aspetti molto concreti:

  • Tolleranza agli errori di battitura e alle varianti singolare e plurale, così una query leggermente sbagliata non restituisce zero risultati
  • Gestione dei sinonimi e dei termini di marca rispetto a quelli generici, così due modi diversi di dire la stessa cosa trovano lo stesso catalogo
  • Una schermata di nessun risultato realmente utile, con suggerimenti o categorie correlate, invece di un vicolo cieco
  • Un ordinamento per rilevanza sensato e tempi di risposta rapidi, perché una ricerca lenta o mal ordinata scoraggia l'uso stesso della funzione

Domande frequenti

Devo mettere in noindex tutte le pagine di ricerca interna del mio sito?

Nella grande maggioranza dei casi sì: è la configurazione di default corretta a livello di template, applicata a ogni query generata dal motore di ricerca on-site. L'eccezione è la singola query, o il piccolo gruppo di query, che i dati mostrano essere così ricorrente da meritare una landing page dedicata costruita apposta, e non la pagina di risultati grezza.

Qual è la differenza tra usare noindex e bloccare la scansione con robots.txt?

Il noindex dice a Google di non mostrare quella pagina nei risultati, ma richiede che Google possa ancora scansionarla per leggere l'istruzione. Bloccare la scansione con robots.txt impedisce l'accesso a monte: se lo fai prima che il noindex abbia avuto effetto, un URL già indicizzato può restare intrappolato in indice senza che Google riesca più a verificarne lo stato.

Le pagine di ricerca interna consumano davvero crawl budget?

Sì, in particolare sui siti grandi: uno spazio di query praticamente infinito, se lasciato scansionabile, distoglie risorse di crawling dalle pagine che vuoi davvero far scansionare e aggiornare con regolarità.

Come scelgo quale query trasformare in landing page?

Parti dal volume di ricerche interne ripetute nel tempo, non da un singolo picco isolato, e verifica che dietro la query ci sia un'intenzione abbastanza ampia da giustificare contenuto editoriale originale, e non solo un filtro più stretto di una pagina già esistente.

I dati di ricerca interna servono solo per l'e-commerce?

No. Qualsiasi sito con una casella di ricerca, un blog, una directory, un sito di documentazione, genera lo stesso tipo di segnale: cosa le persone cercano e non trovano è materia prima per pianificare contenuti, a prescindere dal settore.

Aggiornato: 14 settembre 2026

Tutti gli articoli