Struttura degli URL: principi di URL SEO-friendly

Cos’è la struttura degli URL

La struttura degli URL è l'insieme di regole con cui si formano gli indirizzi delle pagine di un sito: lunghezza, gerarchia delle cartelle, formato dello slug, uso dei parametri e protocollo. Una buona struttura è leggibile dalle persone, comprensibile per un crawler e resta invariata per anni. Una cattiva crea duplicati, rompe l'indicizzazione e obbliga a riscrivere redirect a ogni svolta della strategia di marketing.

L'URL è uno dei pochi segnali SEO che Google ha apertamente indicato come fattore di posizionamento per più di quindici anni. Non è il fattore più forte, ma è tra i più economici: lo configuri una volta in fase di sviluppo e lavora per anni senza modifiche. Gli errori a questo livello si pagano cari — ogni URL cambiato richiede un redirect 301 e una nuova valutazione da parte del motore di ricerca.

Gli URL in numeri

Anatomia di un URL: sette parti

Prima di costruire la struttura, scomponiamo di cosa è fatto un URL. L'RFC 3986 descrive sette componenti; nel contesto SEO contano tutte tranne user-info e fragment:

https://www.example.com:443/blog/seo/url-structure/?utm=email#summary
│  │   │            │   │                          │            │
│  │   │            │   │                          │            └─ fragment (anchor)
│  │   │            │   │                          └────────────── query (GET parameters)
│  │   │            │   └─────────────────────────────────────── path
│  │   │            └─────────────────────────────────────────── port (usually hidden)
│  │   └──────────────────────────────────────────────────────── host (domain)
│  └──────────────────────────────────────────────────────────── subdomain
└─────────────────────────────────────────────────────────────── scheme (protocol)

Perché l’URL conta per la SEO

Gli URL influenzano il posizionamento in modo diretto e indiretto. Il contributo diretto è piccolo — Google ha confermato più volte che una keyword nell'URL dà solo un boost «minuscolo». L'impatto indiretto è molto più grande: gli URL modellano il CTR dello snippet, la fiducia degli utenti e la prevedibilità per il crawler.

Questi segnali si sommano. Ciascuno è debole da solo, ma nella combinazione gli URL diventano un vantaggio silenzioso e persistente — soprattutto per la coda lunga, dove la competizione per ogni punto di CTR è critica.

Le nove regole di un buon URL

Le raccomandazioni di Google sugli URL sono appena cambiate in quindici anni. Le nove regole qui sotto compilano documentazione ufficiale e ricerche empiriche di Backlinko, Ahrefs e Moz. Valgono per qualunque stack — da WordPress a Next.js.

• Usa caratteri latini (a meno che il pubblico non sia solo locale). Il cirillico funziona tecnicamente via punycode, ma si copia male nei messenger, si rompe in stampa e abbassa il CTR nei risultati internazionali. /blog/url-structure/ è meglio dello stesso slug scritto in caratteri cirillici.
• Separa le parole con trattini, non con underscore. Google raccomanda esplicitamente i trattini. L'underscore _ unisce le parole durante il parsing: url_structure per il bot è un token unico, non due parole.
• Solo minuscole. Gli URL sono tecnicamente case-sensitive (su server UNIX). /Page/ e /page/ sono due indirizzi diversi, che creano duplicati. Forza le minuscole a livello di server.
• Lunghezza: più corta di quanto sembri necessario. L’ottimale è 50–75 caratteri. Se l’URL è più lungo, in genere hai parole extra nello slug o categorie ridondanti.
• Profondità delle cartelle: massimo tre livelli. /category/subcategory/page/ è il tetto per la maggior parte dei siti. Il crawler raggiunge meno spesso le pagine più profonde, e gli utenti faticano a navigare.
• No stop word. Elimina congiunzioni e articoli dallo slug: /how-to-fix-error/ è meglio di /how-to-fix-an-error-in-the-code/. Le stop word non aiutano né il posizionamento né la leggibilità.
• Keyword: una volta, e presto. Non ripetere la keyword due volte (/seo/seo-guide/). Posizionala più vicina possibile al dominio: più vicina alla radice, più alto il peso.
• No ID o hash nello slug. /article-12384/ o /post-a3f9b2c8/ sono privi di senso per le persone e non aggiungono semantica. Usa slug descrittivi che traducano l’argomento.
• L'URL non deve cambiare. Un indirizzo pubblicato è un impegno. Qualsiasi modifica richiede un redirect 301 e perde una parte del valore. Pensa alla struttura in anticipo.

Profondità e gerarchia delle cartelle

La struttura delle cartelle in un URL non è solo estetica — è una mappa del sito per il crawler e per l'utente. La profondità di clic (quanti clic dalla home a una pagina) correla con la frequenza con cui Google re-scansiona una pagina e con la rapidità di scoperta dei nuovi contenuti.

La profondità dell'URL non è la profondità di clic. Una pagina può vivere fisicamente in /shop/laptops/macbook-pro-14/ ed essere comunque a un clic dalla home grazie a una forte link building interna. Il motore di ricerca considera entrambi i segnali: il path dell'URL e la distanza reale nel grafo dei link.

www, HTTPS, slash finale e maiuscole

Quattro impostazioni tecniche che producono duplicati più spesso. Ciascuna si risolve una volta a livello di server — ma se la salti, il motore di ricerca vede fino a otto versioni della stessa pagina:

http://example.com/page
http://example.com/page/
https://example.com/page
https://example.com/page/
http://www.example.com/page
http://www.example.com/page/
https://www.example.com/page
https://www.example.com/page/

HTTPS

Obbligatorio dal 2018: Chrome marca i siti HTTP come «non sicuri» e Google usa HTTPS come debole segnale di posizionamento. La configurazione è un singolo redirect in nginx o apache:

# nginx — 301 from HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

www o non-www

Tecnicamente equivalenti. A livello DNS www è un sottodominio, ma Google e Yandex lo trattano come alias quando è configurato un 301. Senza www è leggermente più corto e più moderno; con www è più comodo per i cookie (li puoi separare per sottodominio). Regola chiave: scegli una variante e reindirizza con 301 tutto il traffico verso di essa.

# nginx — 301 from www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Slash finale

Lo slash finale (/page/ contro /page) — due indirizzi diversi per il server. Convenzione: le directory finiscono con /, i file no. Sui siti moderni ogni pagina è una directory, quindi la strategia è unica: sempre con slash finale (o sempre senza). Next.js e WordPress usano lo slash finale per impostazione predefinita.

// next.config.ts — enforced trailing slash
const nextConfig = {
  trailingSlash: true,  // /blog/page/  instead of  /blog/page
};
export default nextConfig;

Maiuscole

Gli URL sono case-sensitive sulla maggior parte dei server (Linux/UNIX). /Page/ e /page/ sono due URL, due duplicati. Forza l’intero path in minuscolo al reverse proxy o a livello applicazione:

# nginx — redirect URLs to lowercase (Lua module)
location ~ [A-Z] {
    rewrite ^/(.*)$ /$1 last;
    set_by_lua_block $lower_uri {
        return ngx.var.uri:lower()
    }
    return 301 $lower_uri;
}

Template di URL per tipo di pagina

Tipi di contenuto diversi richiedono template di URL diversi. Qui sotto pattern collaudati per sei tipi di pagina presenti nel 90% dei siti web.

Per l'e-commerce — un tema a parte. Una scheda prodotto può vivere secondo due schemi: /shop/category/product/ (con categoria) o /shop/product/ (piatto). Il primo è meglio per la SEO delle categorie (l'URL segnala l'appartenenza), il secondo per spostare i prodotti tra categorie senza redirect. La scelta dipende da quanto spesso i prodotti cambiano categoria.

Localizzazione e URL multilingua

Per un sito multilingua gli URL sono la prima parte della strategia. Google raccomanda tre approcci, ciascuno con i suoi compromessi:

Le sottocartelle vincono nell’80% dei casi. Sono più facili da gestire, più economiche per SSL e hosting, e tutto il valore dei link lavora per un solo dominio. È esattamente l’approccio di spiderhead.dev: lingua principale sulla radice, le altre in sottocartelle (/ru/, /de/…).

Gli slug negli URL localizzati sono un tema discusso. Tradurre lo slug dà un CTR migliore per ogni lingua e segnala la pertinenza con più precisione. Il rovescio della medaglia — è più difficile da mantenere: serve gestire hreflang e redirect quando le traduzioni cambiano. Per la maggior parte dei progetti il compromesso è tradurre solo gli slug del blog e mantenere uno slug unico per le pagine tecniche.

Errori comuni e come correggerli

Gli otto errori di URL più comuni che emergono negli audit SEO. Ciascuno si corregge in uno sprint; il costo dell'inazione è la perdita graduale di posizioni e crawl budget.

• Duplicati via parametri GET. Tag UTM, ordinamenti e filtri creano centinaia di varianti di una pagina. Correzione: rel="[canonical](/glossary/canonical)" verso l’URL principale + URL Parameters in GSC.
• Slash finale misto. Alcune pagine con /, altre senza. Il motore di ricerca vede duplicati. Correzione: convenzione unica + 301 da tutte le varianti non conformi.
• Cirillico negli URL di un progetto globale. Uno slug in cirillico, una volta copiato, diventa una sequenza illeggibile di %D1%83.... Correzione: traslitterazione (/uslugi/).
• Gerarchia troppo profonda. /shop/electronics/computers/laptops/apple/macbook-pro/ — sei livelli. Correzione: struttura piatta con categorie come facet.
• ID nell’URL invece dello slug. /article?id=12384 o /post/12384/. Correzione: passa a URL semantici + 301 dai vecchi ID.
• Cambiare un URL senza 301. Qualsiasi cambio di indirizzo senza redirect = perdita di valore e traffico. Correzione: configura sempre un 301 quando rinomini.
• Maiuscole negli URL. /Catalog/ e /catalog/ sono due duplicati. Correzione: imponi le minuscole sul server.
• Catene di redirect infinite. A → B → C → D. Ogni anello perde peso. Correzione: sempre 301 direttamente all’URL finale.

# Check redirect chains via curl:
curl -sILo /dev/null -w "%{http_code} %{url_effective}\n" \
     -L https://example.com/old-page/

# Find URLs with uppercase letters in nginx logs:
grep -E 'GET /[a-z]*[A-Z]' /var/log/nginx/access.log | head

# URL audit via Screaming Frog:
# 1. Run a full site crawl
# 2. Open the URL tab → Underscores / Uppercase / Non ASCII Characters
# 3. Export the list of problematic URLs and plan redirects

FAQ

Le risposte alle domande più comuni sulla struttura degli URL, quelle che emergono negli audit e nei redesign.

Riepilogo

La struttura degli URL è una decisione che prendi una volta e con cui convivi per anni. Un buon URL è corto, leggibile, rispecchia la gerarchia dei contenuti ed è stabile nel tempo. Tre principi cardine — caratteri latini minuscoli, trattini invece di underscore, massimo tre livelli di cartelle — chiudono l'80% degli errori comuni.

Parti da un audit degli URL attuali: Screaming Frog → report «Underscores», «Uppercase», «Non ASCII Characters». In un’ora hai la mappa dei problemi. Poi costruisci una tabella old → new, configura i 301 e aggiorna i link interni. Non affrettare una migrazione di massa prima della stagione di picco: Google impiega 4–8 settimane per rivalutare.