URL e robots.txt: cosa chiarisce Google su trattini e codifica

Google ha aggiornato il 23 ottobre 2026 due indicazioni della propria documentazione tecnica: la separazione delle parole negli URL e la codifica dei percorsi nelle regole del file robots.txt. Sono chiarimenti utili per chi gestisce un sito, soprattutto quando un catalogo genera molti indirizzi, filtri e varianti.

Il punto da cui partire è la natura della novità. I due registri ufficiali descrivono aggiornamenti delle guide, sincronizzati con la serie video The Non-Canonical Cabinet. Non annunciano una nuova penalizzazione per gli URL con underscore né un cambiamento dell’algoritmo di ranking. La conseguenza pratica è un’occasione per verificare le implementazioni, evitando di trasformare una precisazione in una migrazione generalizzata.

Quali indicazioni sono state aggiornate

Nel changelog di Search Central, Google segnala un chiarimento sull’uso di trattini e underscore per separare le parole. Nel changelog dedicato al crawling, la modifica dello stesso giorno riguarda la raccomandazione di usare la codifica percentuale nei percorsi delle regole robots.txt.

Le due questioni sono collegate dalla gestione degli indirizzi, ma richiedono controlli diversi. La prima riguarda la scelta di uno slug leggibile, come il nome di una categoria. La seconda riguarda il modo in cui un percorso viene rappresentato quando si definisce quali URL un crawler può richiedere. Un indirizzo comprensibile può comunque essere accompagnato da una regola robots troppo ampia o scritta per un percorso differente.

Non si tratta di un rollout destinato a un paese o a una lingua specifici. Le modifiche documentate descrivono raccomandazioni tecniche; i changelog non identificano un mercato di lancio o una data di attivazione di nuove funzionalità.

Perché Google consiglia i trattini negli URL

La guida alla struttura degli URL raccomanda il trattino, -, per separare le parole, preferendolo all’underscore, _. L’obiettivo dichiarato è aiutare utenti e motori di ricerca a riconoscere i concetti presenti nell’indirizzo. La documentazione richiama anche l’uso storico dell’underscore nei nomi che rappresentano un concetto unito, come alcuni identificatori nella programmazione.

Per una nuova categoria, un esempio comprensibile è /smartphone-ricondizionati/. Lo slug comunica l’argomento anche quando viene letto fuori dal contesto della pagina. Lo stesso criterio può guidare la creazione di un nuovo articolo o di una scheda prodotto, senza inserire nell’indirizzo ogni caratteristica commerciale disponibile.

Una scelta pratica per un catalogo è mantenere nello slug elementi abbastanza stabili. Se il nome dell’indirizzo contiene una promozione temporanea, l’URL può diventare poco chiaro appena cambia l’offerta. Questa è una valutazione di manutenzione: non deriva dal chiarimento un obbligo di abbreviare tutti gli indirizzi o una formula garantita per migliorare il posizionamento.

Gli URL esistenti richiedono una migrazione?

La presenza di un underscore, da sola, non basta a giustificare il cambio di migliaia di indirizzi. Prima di intervenire, bisogna identificare il problema che si vuole risolvere. Una struttura incoerente introdotta durante il rifacimento del sito è un caso diverso da un catalogo stabile, collegato correttamente e già utilizzato da clienti e sistemi esterni.

La guida di Google alle migrazioni con cambio di URL ricorda che il trasferimento richiede una mappatura degli indirizzi, reindirizzamenti permanenti e aggiornamenti dei collegamenti e delle sitemap. Durante la rielaborazione possono verificarsi oscillazioni nella ricerca.

Per decidere, confronta il beneficio atteso con il costo di queste operazioni. In un e-commerce, aggiungi all’inventario feed, campagne, integrazioni e link nelle comunicazioni ai clienti. Se manca un vantaggio concreto, applicare una convenzione coerente ai nuovi URL può essere una scelta più proporzionata. L’aggiornamento del 23 ottobre non fornisce una stima di guadagno che renda automaticamente conveniente la migrazione.

Che cos’è la codifica percentuale

Un percorso può essere mostrato in modo leggibile e avere anche una rappresentazione codificata. Per esempio, /caffè/ può essere rappresentato come /caff%C3%A8/: la lettera accentata è espressa attraverso i byte UTF-8 codificati con il simbolo percentuale e cifre esadecimali. La sintassi generale è definita nello standard RFC 3986 sugli URI.

Questo esempio aiuta a capire perché copiare un indirizzo dalla barra del browser non sempre basta per un controllo tecnico. L’interfaccia può mostrare caratteri leggibili mentre un’esportazione, un log o uno strumento presenta la forma codificata. Prima di confrontare le stringhe, occorre capire quale rappresentazione si sta osservando.

La codifica deve rispettare la struttura dell’indirizzo. Convertire senza criterio tutti i caratteri di una stringa già codificata può alterarla: il simbolo percentuale potrebbe diventare a sua volta %25. Per questo è preferibile usare le funzioni del proprio linguaggio o CMS sul componente corretto dell’URL e verificare l’output, anziché sostituire caratteri manualmente sull’intero indirizzo.

Cosa significa il chiarimento per robots.txt

Nella specifica di Google per robots.txt, i percorsi possono contenere caratteri UTF-8 oppure la loro forma codificata. Google spiega che il confronto avviene sulle rappresentazioni codificate e raccomanda la codifica percentuale anche per agevolare l’interpretazione da parte di strumenti di terze parti. Il documento non dice che tutti i percorsi scritti con caratteri non ASCII abbiano smesso di funzionare.

Per un controllo, prendi una regola effettiva e confrontala con gli indirizzi che dovrebbe interessare. Un esempio ipotetico è una sezione /caffè/ che il gestore ha già deciso di escludere dalla scansione. La verifica consiste nel confrontare anche /caff%C3%A8/, controllando che il risultato sia quello previsto. L’esempio illustra la rappresentazione del percorso; non suggerisce di bloccare quella categoria sul proprio sito.

La specifica ricorda inoltre che il confronto dei percorsi distingue maiuscole e minuscole e che il file vale per lo stesso host, protocollo e porta. Un test su un sottodominio diverso, quindi, non dimostra come si comporti la regola sull’host principale.

Scansione, indicizzazione e canonicalizzazione hanno scopi diversi

Per evitare errori, la decisione tecnica va collegata al risultato desiderato. Se vuoi impedire una richiesta del crawler, stai intervenendo sulla scansione. Se vuoi escludere una pagina dai risultati, il tema è l’indicizzazione. Se più indirizzi rappresentano contenuti uguali o molto simili, devi valutare quale URL presentare come preferito.

La documentazione di Google su noindex spiega che il crawler deve poter accedere alla pagina per leggere la direttiva. Bloccare l’URL in robots.txt può impedirgli di vederla; inoltre, un indirizzo bloccato può comunque comparire nell’indice se scoperto attraverso altri collegamenti. Inserire noindex direttamente in robots.txt non è un metodo supportato.

Per i duplicati, la guida alla canonicalizzazione descrive segnali come reindirizzamenti e rel="canonical". robots.txt non va usato come strumento per scegliere l’URL canonico. La distinzione evita una correzione apparentemente semplice che finisce per rendere meno osservabile il problema.

Il caso dei filtri in un catalogo ampio

Nei negozi online, gli indirizzi più difficili da governare spesso nascono dalle combinazioni di filtri. Un catalogo di smartphone può offrire marca, capacità, colore, condizione e fascia di prezzo. Prima di scrivere una regola generale, occorre decidere quali combinazioni rappresentino pagine utili e quali siano soltanto stati temporanei di navigazione.

La guida di Google alla navigazione a faccette descrive il rischio di generare uno spazio molto ampio di URL che assorbe risorse di scansione. Questo contesto rende importante una gestione intenzionale dei filtri. Non implica che ogni pagina filtrata debba essere bloccata.

Come proposta operativa, separa le categorie con un obiettivo editoriale e commerciale dalle combinazioni prodotte liberamente dall’interfaccia. “iPhone ricondizionati” potrebbe essere una pagina da curare; una sequenza occasionale di sei filtri richiede una valutazione diversa. È un esempio di analisi, non una conclusione sulla domanda di ricerca di quelle pagine: per decidere servono contenuti, assortimento e dati del sito.

Un controllo misurabile prima di modificare le regole

Puoi iniziare con trenta URL scelti per coprire casi diversi: categorie, prodotti, indirizzi con caratteri accentati, filtri e pagine che devono restare accessibili. Il numero è una proposta di lavoro, non un campione rappresentativo. Per ciascuno registra il comportamento atteso e quello rilevato, insieme alla regola applicabile e alla forma del percorso.

Prima della modifica, salva una copia della configurazione e l’esito dei controlli. Poi prova la nuova regola su un ambiente adatto o con un analizzatore compatibile con le specifiche di Google. Verifica anche gli URL che devono rimanere consentiti: una regola può risolvere il caso cercato e contemporaneamente bloccare pagine commerciali importanti.

Il registro può contenere tre colonne essenziali: URL, esito atteso ed esito effettivo. Se una categoria deve restare accessibile e il test la indica come bloccata, la regola richiede una revisione prima del rilascio. Se invece tutti gli esempi concordano, hai verificato quei casi, senza dimostrare ancora la correttezza su ogni possibile combinazione del catalogo. Aggiungi nuovi casi quando emergono differenze nei log o nelle segnalazioni.

Il primo risultato da misurare è la corrispondenza tra decisione e comportamento tecnico. Dopo il rilascio, osserva le richieste effettive nei log, quando disponibili, e verifica le pagine prioritarie in Search Console. Se cambia il traffico, annota anche prezzi, disponibilità e altre modifiche avvenute nel periodo: una variazione successiva alla correzione non ne dimostra automaticamente la causa.

Conclusionii

I chiarimenti di Google aiutano a rendere più coerenti due parti della gestione tecnica del sito: la creazione degli URL e la scrittura delle regole di scansione. La risposta utile è verificare convenzioni, codifica e comportamento effettivo, partendo dalle pagine che contano per utenti e attività.

Per un sito esistente, una migrazione richiede una motivazione autonoma e un piano completo. Per un nuovo catalogo, conviene definire subito indirizzi leggibili e criteri chiari per i filtri. In entrambi i casi, un controllo documentato su URL consentiti e bloccati offre un risultato verificabile, sul quale basare eventuali interventi più estesi.