Filtri ecommerce e SEO: quali pagine indicizzare, quali bloccare

Ogni filtro che metti su una categoria moltiplica gli URL del tuo ecommerce. Colore, taglia, prezzo, brand, disponibilità: combini quattro filtri con cinque valori l’uno e ti ritrovi con migliaia di pagine generate da una sola categoria. Alcune valgono oro, intercettano una domanda di ricerca reale e meritano un posto in indice. La grande maggioranza è zavorra: pagine quasi identiche che Google scansiona, confronta e poi scarta, bruciando risorse che potevi spendere meglio.

Il problema vero non è tecnico, è decisionale. La domanda da cui parte tutto è una sola: questa pagina filtro la voglio in indice o no? Robots.txt, canonical, meta robots, parametri URL sono solo gli strumenti con cui esegui quella decisione. Se la decisione è confusa, gli strumenti li userai male, e di solito li usi male combinandone due che si annullano a vicenda (ci arriviamo).

Questa guida è multipiattaforma: vale per Magento, WooCommerce, Shopify, Prestashop o un headless fatto in casa, perché il meccanismo della navigazione a faccette è lo stesso ovunque. Trovi snippet reali di robots.txt, canonical e meta robots, un albero decisionale per scegliere cosa indicizzare partendo dalla domanda di ricerca, e l’errore più comune spiegato con la documentazione Google in mano. Se stai sistemando lo shop da zero, il quadro completo (categorie, schede, varianti, prodotti esauriti, paginazione) sta nella guida alla SEO per ecommerce. Qui scendo solo sui filtri.

Cos’è la navigazione a faccette e perché è un problema SEO

La navigazione a faccette (o faceted navigation) è il sistema di filtri che permette all’utente di restringere un elenco di prodotti combinando più attributi: colore, taglia, prezzo, materiale, brand. Ogni volta che l’utente seleziona un filtro la pagina cambia e, quasi sempre, cambia anche l’URL: si aggiunge un parametro (?colore=rosso) o un segmento di path. Comodissimo per chi compra. Una mina per chi deve far ranking.

Il motivo è l’esplosione combinatoria. I filtri non li sommi, li moltiplichi. Cinque colori, sei taglie, quattro fasce di prezzo, dieci brand: questi quattro attributi da soli generano 5 × 6 × 4 × 10 = 1200 combinazioni per ogni singola categoria. Aggiungi l’ordine in cui l’utente clicca i filtri (rosso-poi-42 contro 42-poi-rosso, stesso risultato ma URL diversi) e i numeri vanno fuori scala. Una categoria, migliaia di URL, e nessuno di quegli URL l’hai scritto a mano.

Da qui nascono tre danni concreti.

Crawl budget eroso. Googlebot ha un tempo finito da dedicare al tuo sito. Se lo spende a scaricare diecimila varianti filtro quasi identiche, scansiona più tardi (o non scansiona affatto) le pagine che ti interessano davvero: nuovi prodotti, schede aggiornate, categorie principali.

Contenuto duplicato. La pagina “scarpe colore rosso” e la pagina “scarpe colore rosso ordinate per prezzo crescente” mostrano gli stessi prodotti con lo stesso testo. Per Google sono doppioni. Quando trova N versioni della stessa cosa deve scegliere quale tenere, e non è detto che scelga quella che vuoi tu.

Diluizione dei segnali. I link interni, l’autorità, le eventuali citazioni esterne si spalmano su decine di URL invece di concentrarsi sulla versione che dovrebbe posizionarsi. Capitale di ranking sparpagliato su pagine che non porteranno mai traffico.

Il primo dei tre Google lo mette nero su bianco nella sua guida alla faceted navigation, dove elenca due effetti e sono tutti e due di scansione: i crawler scaricano una massa di URL da filtro prima di poter capire che sono inutili (overcrawling), e quel tempo non lo spendono sulle URL nuove che servono (scoperta più lenta). Il duplicato e la diluizione dei segnali sono conseguenze della stessa dinamica, ma stanno documentate altrove: il consolidamento dei doppioni Google lo tratta nella guida sulle URL duplicate.

Filtri, ordinamenti e paginazione non sono la stessa cosa

Sono tre meccanismi diversi, con effetti diversi sull’indice, e la gestione SEO corretta cambia per ciascuno. Metterli nello stesso calderone “parametri da bloccare” è il primo errore, ed è quello che vedo ripetere più spesso.

I filtri restringono il set di prodotti. ?colore=rosso ti mostra un sottoinsieme: solo i prodotti rossi. Il contenuto della pagina cambia davvero. Alcune di queste pagine, quelle che corrispondono a una ricerca reale, possono valere come landing. La maggior parte no. La decisione caso per caso vive qui.

Gli ordinamenti generano duplicati puri. ?sort=prezzo-crescente non cambia quali prodotti vedi, cambia solo l’ordine in cui te li mostra. Stessi prodotti, stesso testo, stessa intenzione di ricerca. Una pagina ordinata per prezzo è, agli occhi di Google, il clone della stessa pagina ordinata per popolarità. Gli ordinamenti non hanno mai motivo di stare in indice: canonical alla versione non ordinata e via.

Qui divergo dalla documentazione, e lo dico apertamente. Sulle varianti ordinate la pagina sulla paginazione indica altre due strade, noindex o robots.txt, e non nomina il canonical; la pagina sulla faceted navigation il canonical lo contempla, ma lo mette fra i metodi che definisce meno efficaci nel lungo periodo. Scelgo il canonical perché consolida i segnali invece di buttarli, e perché è l’unica delle tre che non richiede di rendere le pagine ordinate deindicizzabili una per una. Se preferisci seguire la lettera della documentazione, la strada è noindex sulle URL ordinate lasciate scansionabili, oppure Disallow:. In tutti e tre i casi, però, non si combinano fra loro.

La paginazione mostra prodotti diversi. Pagina 2 di una categoria non è un duplicato della pagina 1: contiene prodotti differenti. Sono pagine distinte e legittime, ognuna con il suo contenuto. Chi scrive che le pagine paginate sono “identiche” e vanno messe in canonical alla pagina 1 sta dando un consiglio sbagliato: rischi di nascondere a Google metà del catalogo. E non è una regola mia: la pagina ufficiale su paginazione e caricamento incrementale dice di non usare la prima pagina della serie come pagina canonica e di dare a ognuna il proprio canonical. Sulla stessa pagina Google aggiunge che rel=next e rel=prev non li usa più, anche se altri motori potrebbero.

Mettere insieme questi tre casi è il primo errore. Un ordinamento lo neutralizzi sempre. Un filtro lo valuti. Una paginazione la rispetti.

La domanda che viene prima di tutto: questa pagina filtro la voglio in indice?

Prima di bloccare, classifichi. I filtri sono un generatore automatico di pagine, e tra quelle pagine ce ne sono alcune che corrispondono esattamente a ciò che la gente cerca su Google. Impostarli solo come un problema da arginare (blocca, escludi, nascondi) è metà del lavoro, e di solito è la metà che viene fatta per prima.

“Scarpe rosse taglia 42” è una query che qualcuno digita davvero. Se il tuo ecommerce genera quella pagina via filtro e tu la blocchi insieme a tutte le altre, hai buttato via una landing long-tail già pronta. Al contrario, “scarpe ordinate per prezzo decrescente filtrate per disponibilità in magazzino e colore tortora” non la cerca nessuno: è zavorra che va tenuta fuori.

Prima di toccare robots.txt o canonical, quindi, ti fermi e classifichi. Ogni tipo di pagina filtro cade in una di due categorie: vale come landing oppure è zavorra. La domanda è di marketing, prima che tecnica: non “come blocco questa pagina”, ma “qualcuno la sta cercando, questa cosa?”. Il criterio non è la piattaforma né la struttura dell’URL: è la domanda di ricerca reale.

Nelle due sezioni che seguono trovi i criteri per stare da una parte o dall’altra, e un albero decisionale per non doverci pensare ogni volta.

Quando un filtro va indicizzato (e diventa landing)

Una pagina filtro merita l’indice quando rispetta tre condizioni insieme. Mancarne anche una sola la fa scivolare nella zavorra.

C’è domanda di ricerca. Esiste un volume di ricerca misurabile per quella combinazione, con un intento commerciale o informativo chiaro. Lo verifichi con la keyword research, non a naso: prendi gli attributi dei tuoi filtri e controlli quali combinazioni hanno query reali dietro. Qui il lavoro SEO sui filtri si aggancia al lavoro sulle parole chiave (ne ho parlato nel dettaglio nella guida alla keyword research): è la keyword research che ti dice quali filtri promuovere a landing.

Il filtro mappa una query specifica. Le combinazioni che funzionano sono quelle a uno o due attributi che corrispondono a come la gente cerca: categoria + colore (“divani grigi”), categoria + brand (“zaini Eastpak”), categoria + attributo + misura (“scarpe rosse taglia 42”). Ricerche con domanda propria, distinte dalla categoria madre. Un filtro a quattro attributi incrociati non mappa nessuna query: è solo un percorso di navigazione interno.

Puoi darle contenuto e meta unici. Una landing vera ha un suo title, un suo H1, una sua meta description e idealmente un paragrafo di testo che la differenzi dalla categoria padre e dalle altre varianti. Se la pagina “scarpe rosse” ha esattamente lo stesso title della categoria “scarpe” con “rosse” appiccicato dallo script, non è una landing, è un duplicato con un’etichetta diversa. Devi poterle scrivere qualcosa di suo.

Quando le tre condizioni reggono, quella pagina la tratti come una vera categoria: URL pulito, canonical a se stessa, contenuto unico, link interni che ci puntano, presenza in sitemap. Tutto questo nella sezione su come impostare i filtri da posizionare.

Quando un filtro va bloccato

Tutto il resto va tenuto fuori. In pratica la grandissima maggioranza delle pagine generate. I casi tipici:

Combinazioni multiple di filtri. Tre o più attributi incrociati (“scarpe rosse, taglia 42, brand X, sotto i 50 euro, disponibili”). Domanda di ricerca praticamente nulla, contenuto quasi sovrapponibile a versioni più ampie. Pura combinatoria.

Ordinamenti. ?sort= in ogni sua forma. Non cambiano i prodotti, solo l’ordine. Mai in indice, e si tengono fuori con il canonical alla versione pulita, non con il Disallow.

Filtri senza domanda. Attributi che esistono per comodità di navigazione ma che nessuno cerca: “ordina per data di aggiunta”, “mostra 96 per pagina”, filtri su attributi tecnici di nicchia. Utili all’utente dentro al sito, inutili come pagine di destinazione dalla SERP.

Thin content. Combinazioni che restituiscono due o tre prodotti, o zero. Una pagina con un solo prodotto filtrato non ha massa critica per posizionarsi e spesso è meglio servita dalla scheda prodotto stessa.

L’albero decisionale, ridotto all’osso:

1. È un ordinamento o un parametro di sola visualizzazione (sort, view, numero per pagina)? → Canonical alla versione pulita, sempre. Non anche il Disallow: fra due sezioni vedi perché.
2. È una combinazione di tre o più filtri? → Blocca.
3. C’è volume di ricerca per questa combinazione e puoi darle contenuto unico? → Indicizza come landing.
4. In tutti gli altri casi (filtro singolo senza domanda, thin content) → Blocca.

La lista delle landing da indicizzare la curi a mano, è un elenco corto e ragionato. Tutto ciò che non è in quella lista è zavorra, e per la zavorra serve sapere come la tieni fuori senza fare il pasticcio classico.

L’errore che fanno quasi tutti: robots.txt + noindex insieme

Bloccare una pagina in robots.txt e metterci dentro un noindex non raddoppia la sicurezza: la annulla. L’istinto, quando vuoi togliere dall’indice migliaia di pagine filtro, è fare doppio nodo, così sono sicuro. Sembra prudenza. È un autogol, ed è l’errore che ho visto più spesso: qui si gioca metà della partita.

Il motivo è che robots.txt e noindex agiscono su due fasi diverse, e una esclude l’altra. robots.txt blocca la scansione: dice a Googlebot “questa pagina non scaricarla”. Il noindex (un meta tag o un header HTTP) blocca l’indicizzazione, ma è scritto dentro la pagina. Se Googlebot non scarica la pagina perché glielo hai vietato in robots.txt, non legge mai il noindex che ci hai messo dentro. La direttiva resta lì, perfettamente inutile, perché il messaggero non è mai entrato a leggerla.

Il risultato paradossale è che una pagina bloccata in robots.txt può comparire lo stesso in SERP, mostrata senza descrizione (quella riga grigia “Nessuna informazione disponibile per questa pagina”), se quella pagina è linkata da altre parti del web, che è la condizione posta dalla fonte. Lo dice la documentazione Google su robots.txt: robots.txt non è uno strumento per tenere una pagina fuori dall’indice. E la guida sul blocco dell’indicizzazione è esplicita: perché Google veda il noindex, la pagina non deve essere bloccata da robots.txt.

I due strumenti rispondono a due esigenze diverse.

Vuoi far deindicizzare pagine che sono già in indice o che Google scoprirà comunque? Usi noindex e lasci la pagina crawlabile. Google la scarica, legge il noindex, la toglie dall’indice. Solo dopo che è uscita puoi eventualmente bloccarla in robots.txt per risparmiare crawl budget.

Vuoi solo risparmiare scansione su URL che Google non conosce e che non sono mai stati indicizzati? Usi robots.txt da subito, e accetti che se mai venissero linkate potrebbero comparire senza snippet.

La tabella qui sotto è il riassunto da tenere appeso.

La regola che disinnesca l’errore: non bloccare in robots.txt una pagina su cui hai messo noindex o canonical. Se vuoi che Google legga una direttiva dentro la pagina, la pagina deve restare scansionabile.

Come bloccare i filtri che non servono (con esempi)

Per la zavorra che non è mai stata indicizzata (combinazioni profonde di filtri, filtri senza domanda di ricerca) lo strumento giusto è il robots.txt, che taglia la scansione alla radice. Non è però l’unico, e la gerarchia conta.

Google elenca due modi per impedire la scansione delle URL da navigazione a faccette e li mette sullo stesso piano: il robots.txt e i fragment. Canonical e rel=nofollow finiscono in un secondo gruppo, che la guida introduce come “altri modi per segnalare una preferenza” e liquida con un giudizio esplicito: sono “generalmente meno efficaci nel lungo periodo rispetto ai metodi appena citati”. Vale la pena saperlo prima di scegliere.

Metodo 1: robots.txt, per nome di parametro. L’esempio che Google mostra nella guida non è una regola catch-all, è un elenco di parametri:

user-agent: Googlebot
disallow: /*?*products=
disallow: /*?*color=
disallow: /*?*size=
allow: /*?products=all$

Tradotto su uno shop italiano, con i tuoi nomi di parametro e la sitemap in coda:

User-agent: *
# Blocca le URL generate dai filtri che non diventano landing
Disallow: /*?*colore=
Disallow: /*?*taglia=
Disallow: /*?*prezzo=
Disallow: /*?*brand=

Sitemap: https://www.esempio.it/sitemap_index.xml

Bloccare per nome di parametro è più chirurgico del blocco a tappeto: la categoria senza query string resta crawlabile, e le landing che hai promosso non finiscono sotto la mannaia. Se preferisci una regola sola, la scorciatoia è Disallow: /*?*&: intercetta ogni URL che contiene almeno un &, cioè ogni combinazione da due filtri in su, perché il primo parametro sta dopo il ? e il secondo arriva dopo il primo &. Il rovescio è che blocchi anche le combinazioni a due filtri che volevi indicizzare come landing. Se ne hai, escludile prima con una regola Allow più specifica: è la tecnica che Google stesso indica nel post con cui ha chiuso lo strumento Parametri URL, dove scrive che per avere più controllo si possono usare le regole del robots.txt, “per esempio puoi specificare l’ordine dei parametri in una regola allow”.

Una nota sul separatore. Quando i tuoi filtri generano più parametri nella stessa URL, usa l’ampersand & come separatore standard tra coppie chiave-valore (?colore=rosso&taglia=42). Google scrive che virgola (,), punto e virgola (;) e parentesi quadre ([ e ]) sono difficili da riconoscere per i crawler come separatori di parametri, per il motivo più semplice del mondo: il più delle volte separatori non sono.

Metodo 2: i filtri nel fragment. È il secondo modo che Google mette accanto al robots.txt. Sposti i filtri dopo il cancelletto: /scarpe#colore=rosso&taglia=42. La Ricerca in genere non supporta i fragment in scansione e indicizzazione, quindi, testuale, “se il tuo meccanismo di filtro è basato su fragment non avrà alcun impatto sulla scansione, positivo o negativo”. Quelle combinazioni non nascono proprio come URL: non c’è niente da bloccare perché non c’è niente da scoprire. Il conto lo paghi dall’altra parte, ed è un conto serio: una combinazione che vive solo nel fragment non potrà mai diventare una landing, perché non è un indirizzo che Google può seguire. Va bene per i filtri che vuoi tenere fuori, non per quelli che vuoi posizionare.

rel=nofollow sui link dei filtri. Sta nel secondo gruppo, quello dei segnali che Google giudica meno efficaci nel lungo periodo, e serve a ridurre le probabilità che Googlebot scopra e accodi quelle URL:

<a href="/scarpe?colore=rosso&taglia=42&prezzo=0-50" rel="nofollow">
  Applica filtri
</a>

Con un vincolo che Google mette per iscritto: perché sia efficace, ogni anchor che punta a quella URL deve avere il rel=nofollow. Uno solo dimenticato nel menu, nel footer o in un box “prodotti correlati”, e la regola non vale più. Aggiungi che se quella URL è linkata da fuori o finisce in una sitemap Google può trovarla lo stesso, e il quadro è completo: il nofollow è un segnale di scoperta, non un muro.

404 sulle combinazioni vuote. Quando una combinazione di filtri non restituisce alcun prodotto, non servire una pagina 200 vuota “Nessun risultato”: restituisci uno status 404. È la raccomandazione di Google per la faceted navigation, e nella fonte è più larga di come viene citata di solito: vale anche quando l’URL contiene filtri duplicati o combinazioni prive di senso, e per le URL di paginazione inesistenti. Con un dettaglio operativo che fa la differenza: niente redirect verso una pagina d’errore comune, il 404 va servito sull’URL dove è stato incontrato. Il 410 in quella pagina non compare: puoi usarlo se sai che quella combinazione non tornerà mai, ma è una tua scelta, non una raccomandazione di Google. Una pagina vuota che risponde 200 dice a Google “esisto e sono valida”. Una 404 dice “qui non c’è niente”, che è la verità.

E gli ordinamenti? Fuori dal robots.txt. Qui gli ordinamenti si gestiscono con il canonical alla versione pulita, e le due cose non si sommano: se disallowi ?sort=, Googlebot quella pagina non la scarica, e il canonical che ci hai messo dentro non lo legge nessuno. È l’errore della sezione precedente con un’altra etichetta. Scegline uno: o canonical, con la pagina scansionabile, o Disallow, e allora il canonical non scriverlo proprio.

Come impostare i filtri che vuoi posizionare

Per la lista corta di landing filtro che hai deciso di promuovere il lavoro è opposto: non le nascondi, le tratti come categorie di prima classe. Cinque mosse.

URL pulito, possibilmente in path. Tra /scarpe?colore=rosso e /scarpe/rosse/ la seconda è preferibile per una landing che vuoi posizionare: è leggibile, contiene la keyword, non rischia di cadere nelle regole robots che bloccano i parametri. Per le landing strategiche vale la pena configurare URL in path (su molte piattaforme è un’opzione o un’estensione), con la condizione che Google mette per iscritto: l’ordine logico dei filtri deve restare sempre lo stesso e non devono poter esistere filtri duplicati. Senza quella, il path genera le stesse varianti della query string, solo più belle da guardare. Se resti in query string, almeno usa il separatore & standard e tieni l’ordine dei parametri stabile, così non generi varianti.

Canonical autoreferenziale. La landing punta il canonical a se stessa, non alla categoria madre. Dichiari a Google che quella è la versione buona, quella da indicizzare:

<link rel="canonical" href="https://www.esempio.it/scarpe/rosse/" />

Niente noindex, indicizzazione esplicita. Sulle landing non metti restrizioni. Se vuoi essere esplicito:

<meta name="robots" content="index, follow" />

E, di nuovo, non bloccarle in robots.txt: devono restare scansionabili.

Title, meta description, H1 e testo unici. Questa è la differenza tra una landing e un duplicato. La pagina “scarpe rosse” ha un suo title (“Scarpe rosse da donna e uomo | Esempio”), un suo H1, una sua meta description e un breve paragrafo introduttivo che parla di scarpe rosse, non un testo copiaincollato dalla categoria “scarpe”. Se la tua piattaforma non ti lascia personalizzare i meta delle pagine filtro, quella combinazione non è candidabile a landing finché non risolvi il problema tecnico.

Internal linking e sitemap. Le landing vanno linkate da dentro il sito (menu, box “categorie correlate”, testo delle categorie madri) e incluse nella sitemap XML. Inversamente, la zavorra non deve mai finire in sitemap: la sitemap è la lista delle pagine che vuoi indicizzate, mettere lì le pagine filtro che blocchi è un segnale contraddittorio. Sitemap pulita, solo landing e categorie vere.

Parametri URL e Search Console: cosa è cambiato

Lo strumento Parametri URL di Search Console non esiste più. Se hai letto guide più vecchie ti sarai imbattuto nel consiglio “usa lo strumento Parametri URL per dire a Google come gestire ?sort= e ?colore=“: cancellalo dalla testa.

Google ne ha annunciato la deprecazione il 28 marzo 2022, scrivendo che lo strumento sarebbe sparito nel giro di un mese e che agli utenti non era richiesto di fare niente. Una data di spegnimento, nel post, non c’è: c’è solo quel “entro un mese”. Se la trovi scritta da qualche parte come data certa, è un’addizione fatta a mano, non un fatto documentato.

La motivazione ufficiale sta in una cifra: solo circa l’1% delle configurazioni di parametri impostate nello strumento risultava utile alla scansione. Da lì il verdetto, testuale, sul “poco valore dello strumento sia per Google sia per gli utenti di Search Console”. Nel frattempo, scrive sempre Gary Illyes nello stesso post, negli anni Google era diventato molto più bravo a indovinare quali parametri sono utili su un sito e quali, parole sue, sono “chiaramente inutili”.

Cosa significa in pratica oggi: il controllo sui parametri non passa più da un pannello in Search Console, passa dalle leve viste finora. robots.txt per impedire la scansione dei parametri che non vuoi, rel=canonical per consolidare ordinamenti e varianti sulla versione preferita, URL puliti e coerenti per non confondere l’inferenza automatica. Niente scorciatoie da console: la gestione filtri è una questione di architettura del sito, e te la giochi nel markup e nella configurazione del server, non in un form.

Crawl budget: quando conta davvero

Google indica tre casi in cui la gestione attiva del crawl budget serve davvero, e il terzo è quello che riguarda i filtri. La guida alla gestione del crawl budget li elenca così: siti oltre il milione di pagine uniche con contenuto che cambia con moderata frequenza (una volta a settimana); siti oltre le 10.000 pagine uniche con contenuto che cambia molto rapidamente (ogni giorno); siti con una quota rilevante delle proprie URL classificate da Search Console come “Rilevata, ma attualmente non indicizzata”. Subito sotto, Google mette una precisazione che pesa quanto le soglie: “i numeri qui indicati sono una stima approssimativa per aiutarti a classificare il tuo sito. Non sono soglie esatte”.

Il terzo caso è quello che conta per chi legge questa guida, perché non ha soglia dimensionale. Un catalogo da duemila prodotti non ti mette al riparo da niente: il numero non lo fanno i prodotti, lo fanno le combinazioni. Se fra filtri, ordinamenti e ricerca interna quel catalogo genera decine di migliaia di URL, e Search Console te ne restituisce una fetta grossa sotto “Rilevata, ma attualmente non indicizzata”, sei dentro il terzo caso a prescindere da quanto è corto il listino. Prima di decidere se il problema ti riguarda, conta le URL: le tre cifre da confrontare (sitemap, crawler, Search Console) e cosa dice la distanza fra loro stanno nel capitolo su quante URL ha davvero il tuo shop.

Questo non vuol dire che il crawl budget sia l’unico motivo per gestire i filtri, né il primo. Gli altri due, contenuto duplicato e diluizione dei segnali, fanno danno a qualsiasi scala e non aspettano nessuna soglia.

Dove il crawl budget diventa il problema numero uno: marketplace e cataloghi con centinaia di migliaia o milioni di URL, magazzini che cambiano di continuo, dove la combinatoria dei filtri genera letteralmente milioni di pagine fantasma. Lì ogni richiesta che Googlebot spende su un ?colore=rosso&taglia=42&prezzo=0-50 è una richiesta che non spende su un prodotto nuovo. In quel contesto il robots.txt sui parametri non è igiene, è sopravvivenza. Per tutti gli altri è buona pratica che paga soprattutto in pulizia dell’indice, e in qualche caso, il terzo, in scansione recuperata.

Filtri in JavaScript: bastano a tenere Google fuori?

No. È il consiglio datato che gira ancora su qualche guida: “carica i filtri in JavaScript/AJAX così Google non li vede e non indicizza le combinazioni”. Funzionava forse dieci anni fa. Oggi Google renderizza JavaScript come prassi: la guida sulle basi della SEO per JavaScript scrive che tutte le pagine con status 200 finiscono in coda di rendering, che ci sia JavaScript oppure no. Googlebot esegue il codice, costruisce il DOM finale e indicizza quello che trova dopo il rendering. Nascondere i filtri dietro JS, di per sé, non tiene Google fuori da niente.

Il punto che conta è il tipo di collegamento, non il linguaggio. Un link vero, scritto come <a href="/scarpe?colore=rosso">, è un URL che Googlebot può scoprire, accodare e scansionare, che il click sia gestito da JavaScript oppure no. Quello che Google in genere non trasforma in una nuova URL da scansionare è l’interazione pura, senza un href di destinazione: un filtro applicato da un onclick che aggiorna i prodotti via fetch e non cambia l’URL, o uno stato tenuto solo dentro l’applicazione. Lì non c’è un indirizzo da seguire, quindi non nasce una pagina indicizzabile.

Da qui due conseguenze operative. Primo: se vuoi che alcune combinazioni filtro siano landing posizionabili, devono avere un <a href> reale con un URL pulito, altrimenti Google non le scoprirà mai. Secondo: per i filtri che non vuoi far scansionare ma che hanno comunque un href, gli strumenti primari sono i due della sezione sul blocco, cioè il Disallow in robots.txt e i filtri spostati nel fragment. Il rel=nofollow ci sta accanto come segnale di scoperta (la stessa guida sul JavaScript lo indica come il meccanismo per impedire che i link vengano accodati), ma Google lo mette insieme al canonical fra i metodi “generalmente meno efficaci nel lungo periodo”. Il JavaScript da solo non è una recinzione: nasconde i filtri all’occhio distratto, non al renderer di Google.

Come verificare che la gestione filtri funzioni

Impostato tutto, devi controllare che faccia quello che pensavi. Lo strumento è Google Search Console, e i punti da guardare sono tre.

Rapporto Pagine (Indicizzazione). Ti dice quante pagine sono indicizzate e quante escluse, con il motivo dell’esclusione. Dopo aver sistemato i filtri ti aspetti di vedere crescere le voci coerenti con le tue scelte: “Esclusa dal tag noindex” per le pagine che hai deindicizzato, “Bloccata da robots.txt” per i parametri che hai disabilitato. Se vedi migliaia di URL filtro ancora sotto “Indicizzata”, qualcosa nel piano non sta girando.

“Scansionata ma attualmente non indicizzata”. Questa voce, in un contesto di filtri, è spesso il sintomo del duplicato: Google ha scaricato la pagina, l’ha valutata, l’ha trovata troppo simile ad altre e ha deciso di non tenerla. Se ci finiscono pagine filtro che volevi escludere comunque, è coerente. Se ci finiscono pagine che volevi come landing, è un segnale che quelle landing non sono abbastanza differenziate (contenuto, meta, prodotti) e vanno rese più uniche, o che non meritavano l’indice.

Statistiche di scansione. Nelle impostazioni trovi quante richieste fa Googlebot e su cosa. Su cataloghi grandi è qui che vedi se il crawl budget si sta sprecando: se una fetta importante delle scansioni va su URL con parametri filtro, le tue regole non stanno mordendo abbastanza.

Non esistono numeri magici da raggiungere, e diffida di chi te ne promette. Guardi gli andamenti dopo le tue modifiche e verifichi che vadano nella direzione decisa: meno pagine filtro indicizzate, scansione più concentrata sulle pagine che contano, landing scelte regolarmente in indice. È un controllo qualitativo sui trend, non una metrica assoluta.

Filtri e ricerca AI: cosa cambia

La regola c’è ed è secca: per comparire come link di supporto in AI Overviews o in AI Mode una pagina deve essere indicizzata e mostrabile in Google Search con uno snippet, rispettando i requisiti tecnici della Ricerca. Lo scrive Google nella pagina sulle funzionalità AI, aggiornata a dicembre 2025, dove aggiunge che requisiti tecnici aggiuntivi non ce ne sono e che i controlli sono quelli di sempre: nosnippet, data-nosnippet, max-snippet, noindex.

Tradotto sui filtri: una pagina filtro bloccata in robots.txt o messa in noindex non è candidabile, punto. Non esiste una porta di servizio generativa che scavalchi l’indice. La stessa disciplina che usi per il ranking tradizionale (indicizza le landing che valgono, tieni fuori la zavorra) decide anche chi può finire fra i link di supporto di una risposta AI: non è un livello a parte, è la base.

Da qui in poi passo alle osservazioni mie, che documentazione specifica sulle pagine filtro nei sistemi generativi non ne ho trovata. L’ipotesi ragionevole, da verificare sui propri dati nel tempo, è che le landing filtro ben costruite restino un asset anche nella ricerca generativa. Una pagina “scarpe rosse taglia 42” con contenuto e meta propri risponde a un’intenzione precisa, e le intenzioni precise sono esattamente ciò che i sistemi di risposta provano a soddisfare. Le combinazioni vuote o duplicate non hanno nulla da offrire né alla SERP né a un modello che genera risposte. Su come la ricerca AI cambia il lavoro SEO in generale ho scritto una guida dedicata alla SEO per la ricerca AI, che inquadra il contesto più ampio. Per i filtri il principio è economo: cura le pagine che meritano di esistere, e quelle saranno candidate sia in SERP sia nelle risposte generative.

In sintesi: il flusso decisionale sui filtri ecommerce

Tutto quello visto sopra si comprime in cinque passi, da rifare ogni volta che configuri o rivedi i filtri di una categoria.

1. Separa i tre meccanismi. Ordinamenti e parametri di sola visualizzazione → canonical alla versione pulita, sempre (la mia scelta; Google, sulle varianti ordinate, indica noindex o robots.txt), e mai anche un Disallow sugli stessi URL. Paginazione → ogni pagina con il proprio canonical, prodotti raggiungibili. Filtri → si valutano uno per uno.
2. Chiedi alla domanda di ricerca. Per ogni tipo di pagina filtro: c’è volume e intento dietro questa combinazione? La keyword research è il giudice, non il tuo istinto.
3. Promuovi le landing, blocca la zavorra. Le combinazioni con domanda reale e contenuto unico diventano landing (URL pulito, canonical autoreferenziale, meta unici, sitemap, link interni). Tutto il resto resta fuori.
4. Usa lo strumento giusto per il blocco. robots.txt e filtri nel fragment per impedire la scansione di URL mai indicizzate; noindex (a pagina crawlabile) per deindicizzare ciò che è già in indice; canonical e nofollow come segnali di contorno, che Google giudica meno efficaci nel lungo periodo. Mai robots.txt e noindex sulla stessa pagina. 404 sulle combinazioni vuote.
5. Verifica in Search Console. Controlla il rapporto Pagine, lo “scansionata ma non indicizzata” e le statistiche di scansione, e correggi sui trend.

Questi filtri sono un pezzo di un discorso più largo: categorie, schede prodotto, varianti, duplicati strutturali, prodotti esauriti e paginazione li ho messi nella guida alla SEO per ecommerce, in ordine di priorità. Se gestisci un catalogo e hai messo le mani in queste configurazioni, mi interessa confrontarmi sui pattern che vedi: combinazioni che ti hanno sorpreso diventando landing, casi in cui il blocco ha sbloccato il crawl, situazioni in cui Search Console raccontava una storia diversa dalle attese. Scrivimi i tuoi casi, ragioniamoci insieme.

Domande frequenti

Le risposte rapide alle domande che restano dopo il corpo dell’articolo.