URL SEO-friendly: come scriverli bene nel 2026

SEO
Guide

Un URL SEO-friendly è un indirizzo che si capisce leggendolo: poche parole nella lingua di chi cerca, separate da trattini, tutte in minuscolo, senza parametri inutili. Non fa salire una pagina da solo, ma aiuta le persone a scegliere il risultato giusto e aiuta Google a non vedere la stessa pagina sotto due indirizzi diversi. E quando un indirizzo cambia, serve un redirect permanente dal vecchio al nuovo.

Questo articolo sostituisce la nostra guida del 2019, che si concentrava quasi solo sulle regole del file .htaccess. Le regole di base sono rimaste quasi le stesse; è cambiato il contesto, e oggi le indicazioni ufficiali di Google sono più chiare di allora.

Perché l’indirizzo di una pagina conta ancora?

Per due motivi pratici, entrambi scritti nella documentazione di Google.

Il primo riguarda le persone. Nella guida introduttiva alla SEO Google spiega che parti dell’URL possono comparire nei risultati di ricerca come percorso di navigazione (breadcrumb), e che chi cerca le usa per capire se un risultato fa al caso suo. Un indirizzo come /pets/cats.html dice qualcosa; uno fatto di codici casuali no.

Il secondo riguarda la scansione. Indirizzi pieni di parametri, varianti maiuscole e doppioni creano più URL per lo stesso contenuto: Google deve capire quale tenere, e i segnali si disperdono tra le copie.

Quello che l’URL non fa è sostituire il contenuto. Riempirlo di parole chiave non rende migliore una pagina debole: conta che l’indirizzo descriva bene quello che c’è dentro.

Come deve essere fatto un buon URL?

Le linee guida di Google sulla struttura degli URL si riassumono in poche regole.

Parole leggibili al posto dei codici. Google consiglia di usare “parole leggibili invece di lunghi numeri identificativi”. Meglio /wiki/aviazione che /index.php?topic=42&area=3a5ebc94.
Trattini per separare le parole. Google raccomanda il trattino (-) e sconsiglia il trattino basso (_), usato di solito per tenere insieme concetti. Anche le parole attaccate, come vestitoverde, sono sconsigliate.
Tutto minuscolo. Per Google /MELE e /mele sono due URL diversi, ciascuno con il suo contenuto. Se il server li tratta allo stesso modo, Google suggerisce di portare tutto allo stesso formato.
La lingua di chi legge. Le parole dell’indirizzo vanno scelte nella lingua del pubblico: /it/contatti/ per gli italiani, /en/contact/ per chi legge in inglese.
Pochi parametri, nel formato standard. Quando servono (filtri, ordinamenti) si usano = e &, e quelli inutili si tolgono. Google sconsiglia gli ID di sessione negli URL e suggerisce i cookie.
Niente contenuti dietro il #. Google in genere non considera la parte dopo il cancelletto, quindi una pagina che cambia contenuto solo con il frammento (/#/patate) rischia di non essere vista. Chi usa JavaScript per cambiare pagina dovrebbe usare la History API.
Caratteri speciali codificati. Lettere accentate ed emoji vanno codificate secondo lo standard: Google fa l’esempio di gemüse, che diventa gem%C3%BCse. Nella pratica, per un sito italiano conviene togliere gli accenti dagli slug (perche, non perché).

Un confronto veloce

Da evitare	Meglio
`/index.php?id=243`	`/risorse/url-seo-friendly/`
`/Servizi/Siti_Web`	`/servizi/siti-web/`
`/prodotti/#/scarpe-rosse`	`/prodotti/scarpe-rosse/`
`/blog/2019/09/20/post-1/`	`/blog/url-seo-friendly/`

L’ultima riga non è una regola di Google ma una scelta nostra: le date nell’indirizzo invecchiano l’articolo anche quando viene aggiornato, e costringono a cambiare URL proprio quando lo si rinfresca.

Cosa succede quando un URL cambia?

È il momento in cui si perde più traffico, di solito durante un rifacimento del sito. La regola è una sola: ogni vecchio indirizzo deve portare al nuovo con un redirect permanente.

La documentazione di Google sui redirect spiega che i redirect permanenti (codici 301 e 308) sono un segnale che la pagina di arrivo deve diventare quella canonica, e che il nuovo indirizzo prende il posto del vecchio nei risultati. Google consiglia, quando possibile, un redirect lato server: è il metodo che interpreta con più probabilità nel modo corretto. I redirect via JavaScript vanno usati solo se le altre strade sono chiuse.

Nella guida ai trasferimenti di sito Google aggiunge due cose utili: i redirect 301 e gli altri redirect permanenti non fanno perdere PageRank, e ogni nuova pagina dovrebbe avere un tag rel="canonical" che punta a sé stessa.

In concreto, prima di cambiare gli indirizzi:

Si fa l’elenco di tutti i vecchi URL, compresi quelli degli articoli e delle categorie.
Si decide, per ciascuno, dove deve portare: la pagina nuova equivalente, non la home.
Si impostano i redirect sul server e si controlla che ognuno faccia un solo salto, senza catene.
Si aggiornano i link interni, così il sito non passa dai redirect per collegare le sue stesse pagine.

Come si fa con .htaccess?

Su un server Apache il file .htaccess resta lo strumento più comune per i redirect, ed è anche l’esempio che Google stesso mostra. Due casi frequenti.

Spostare una pagina a un nuovo indirizzo, con il modulo mod_alias:

Redirect permanent "/vecchia-pagina" "https://www.example.com/nuova-pagina/"

Togliere l’estensione .html dagli indirizzi, con mod_rewrite:

RewriteEngine On
# Chi chiede /pagina.html viene mandato a /pagina
RewriteCond %{THE_REQUEST} \s/([^\s?]+)\.html[\s?]
RewriteRule ^ /%1 [R=301,L]
# /pagina mostra il file pagina.html, senza cambiare indirizzo
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.+)$ $1.html [L]

La prima regola guarda la richiesta originale (THE_REQUEST) e non l’indirizzo già riscritto: così le due regole non si rimandano la palla all’infinito.

Per le maiuscole c’è una trappola. Il modo più semplice per portarle in minuscolo è una RewriteMap con la funzione int:tolower, ma la documentazione di Apache precisa che la mappa non si può dichiarare in un file .htaccess: va dichiarata nella configurazione del server o del virtual host, e solo dopo si può usare nelle regole. Apache stesso presenta l’esempio come illustrativo e, per rendere gli URL insensibili alle maiuscole, suggerisce il modulo mod_speling. Se non si ha accesso alla configurazione del server, la strada più pulita è non generare mai URL con maiuscole.

Un’avvertenza vale per tutto il resto: .htaccess è una toppa, non una soluzione. Se gli indirizzi sono sbagliati in partenza, conviene correggerli dove nascono, cioè nel CMS o nel codice del sito, e lasciare al server solo i redirect dei vecchi indirizzi.

E se il sito non usa Apache?

Molti siti oggi non girano su Apache. Chi usa WordPress gestisce gli indirizzi dalle impostazioni dei permalink; chi pubblica su piattaforme come Vercel o Netlify dichiara i redirect in un file di configurazione del progetto, con la stessa logica: vecchio indirizzo, nuovo indirizzo, codice permanente.

Questo sito, per esempio, è costruito con Astro, un generatore di siti statici: gli indirizzi nascono dal nome del file (questo articolo vive in /risorse/url-seo-friendly-htaccess/, lo stesso indirizzo della versione del 2019) e i redirect dal vecchio sito WordPress sono una semplice tabella nel codice. Il principio non cambia con lo strumento.

In breve: la lista di controllo

Parole leggibili, nella lingua di chi legge, separate da trattini.
Tutto minuscolo, senza accenti né caratteri strani.
Niente parametri inutili, niente ID di sessione, niente contenuti dietro il #.
Un indirizzo per ogni pagina, con il suo rel="canonical".
Quando un URL cambia, un redirect 301 dal vecchio al nuovo, in un solo salto.

Se stai rifacendo il sito e temi di perdere le posizioni conquistate negli anni, il passaggio degli indirizzi è la prima cosa da pianificare. Nel nostro portfolio trovi i siti che abbiamo costruito, come quello in cinque lingue di Dimora Murat, con una versione completa per ogni lingua. Se vuoi parlarne sul tuo caso, scrivici.