Copi un indirizzo da un report e ti ritrovi davanti una lunga fila di simboli, parametri e codici. Un URL indica come raggiungere una risorsa online, ma per capire che cosa succede davvero bisogna guardare anche alle sue singole parti. Io partirei da una distinzione pratica: alcuni elementi scelgono la risorsa, altri cambiano il modo in cui viene mostrata.
Un URL è una struttura da leggere, non una sequenza casuale
- Schema e host indicano il protocollo e il server da contattare.
- Percorso e query individuano una risorsa o ne modificano la richiesta, secondo le regole del sito.
- Il fragment porta il browser a una parte della risorsa e non viene inviato al server.
- Parametri persistenti aiutano a rendere gli indirizzi comprensibili e più semplici da gestire.
Ogni parte dell’URL svolge un compito diverso
Prendi https://shop.esempio.it:8443/prodotti/borraccia?colore=verde#materiali. La prima sezione, https, è lo schema: dice al browser quale protocollo usare; shop.esempio.it è l’host, cioè il server da contattare.
La porta 8443 è facoltativa e serve a distinguere un servizio in ascolto su una porta specifica. Dopo il primo slash, /prodotti/borraccia è il percorso; la parte dopo ? è la query e quella dopo # è il fragment.
La distinzione tra standard non è solo accademica. La sintassi generale descritta da RFC 3986 e le regole di parsing del WHATWG URL Standard non coincidono in ogni dettaglio: se stai scrivendo un parser o validando indirizzi inseriti dagli utenti, usa le regole della piattaforma con cui il software deve interoperare.
Query e fragment fanno due lavori diversi
Nel browser, ?colore=verde può chiedere al server di restituire una variante specifica del prodotto. Il server decide come interpretare ogni parametro: il nome da solo non garantisce che abbia un significato universale.
Il fragment, invece, viene elaborato dal browser dopo aver ricevuto la risorsa. Secondo MDN, la parte dopo il cancelletto non viene inviata al server; perciò un link come /guida#installazione può aprire la stessa pagina e portare direttamente alla sezione indicata.
Ne deriva una regola utile per la navigazione: se il contenuto deve essere caricato come pagina o vista distinta, affidati a un percorso o a una query gestita dal server; se devi puntare a una sezione di una pagina già caricata, usa un fragment. Una numerazione costruita soltanto dopo # non crea, da sola, una nuova risorsa lato server.
I parametri superflui moltiplicano gli indirizzi della stessa pagina
Un catalogo può servire lo stesso prodotto con indirizzi diversi: uno pulito, uno con un codice di campagna e un altro con un identificativo di sessione. Se i parametri non cambiano il contenuto, link interni che li trascinano possono produrre varianti inutili e rendere più difficile capire quale indirizzo rappresenti la pagina.
Google Search Central raccomanda URL semplici e l’uso di parametri leggibili quando servono davvero; la documentazione segnala anche che i parametri di tracciamento o sessione possono generare indirizzi temporanei o duplicati. Per un’azienda, questo suggerisce una scelta netta: conserva nel link canonico i parametri che selezionano una variante reale, mentre evita di disseminare nei link interni quelli usati soltanto per attribuire una campagna.
Per esempio, se ?taglia=M mostra un prodotto effettivamente diverso, la variante può aver bisogno di un indirizzo stabile. Se ?utm_source=newsletter serve soltanto a misurare una visita e non cambia la pagina, non dovrebbe diventare la versione condivisa ovunque. Un URL leggibile riduce confusione per chi lo riceve e rende più ordinata la manutenzione del sito.
Un errore nell’indirizzo spesso si riconosce dal punto in cui compare
Quando una pagina non si apre o porta alla vista sbagliata, controlla prima quale componente cambia tra l’indirizzo previsto e quello che hai. La tabella aiuta a isolare il problema senza trattare ogni URL lungo come un errore.
| Situazione | Possibile causa | Che cosa fare |
|---|---|---|
| Il sito non si raggiunge | Schema, host o porta non corrispondono al servizio disponibile | Verifica dominio e protocollo; controlla la porta solo se il servizio la richiede esplicitamente. |
| Si apre la pagina, ma non il filtro richiesto | Il server ignora quel parametro, oppure il valore non è previsto | Controlla il nome e il valore accettati dall’applicazione. |
| La pagina si apre, ma resta in cima | Il fragment non corrisponde a un elemento presente nel documento | Confronta il valore dopo # con l’ID della sezione. |
| Lo stesso contenuto ha molti indirizzi | Parametri di tracciamento, filtri o sessioni creano varianti | Decidi quale URL è stabile e usa segnali coerenti, come un redirect o un’indicazione canonical quando appropriato. |
Se cambi gli indirizzi pubblici di un sito, prepara anche i redirect verso le destinazioni corrette. Un vecchio link salvato in una newsletter o in un documento può continuare a circolare a lungo, e lasciarlo senza percorso di recupero trasforma una modifica interna in una pagina irraggiungibile.
Un URL ben progettato riduce manutenzione e sprechi digitali
Per un sito aziendale, un indirizzo persistente evita di dover correggere ogni documento, QR code o collegamento distribuito quando cambia l’organizzazione dei contenuti. La sostenibilità digitale passa anche da qui: meno copie della stessa pagina e meno link da riparare rendono più semplice mantenere il servizio nel tempo.
Quando progetti una nuova pagina, scegli un percorso breve e descrittivo, poi verifica che query e fragment facciano soltanto ciò per cui sono stati introdotti. Se chi riceve il link riesce a capire dove porterà, e il team può mantenerlo senza inseguire parametri temporanei, l’indirizzo sta già facendo bene il suo lavoro.