Generatore slug URL

Trasforma qualsiasi testo in uno slug compatibile con gli URL.

Solo browser: il tuo testo non lascia mai il tuo dispositivo


Cos'è uno slug URL?

A slug is the human-readable, URL-safe path segment that identifies a page within a site. It sits at the tail of the URL and replaces what would otherwise be an opaque database identifier with a descriptive token. In https://example.com/blog/2026/my-awesome-post, the slug is my-awesome-post. Mechanically, a slug is the output of a deterministic transformation: take an arbitrary input string, strip everything that isn't allowed in a URL path segment, fold case, replace whitespace with a separator, and emit ASCII. The transformation is one-way in practice, you can't reliably reconstruct "My Awesome Post: Take Two!" from my-awesome-post-take-two: which is why slugs are stored alongside the original title, not in place of it.

Buoni slug usano solo lettere minuscole, cifre e trattini. Rimuovono accenti, caratteri speciali e spazi superflui. Questo migliora sia il SEO sia l'esperienza utente · motori di ricerca e umani possono leggere l'URL e capire il contenuto della pagina.

Da dove viene la parola: redazioni del XIX secolo

La parola precede il web di un secolo. Nelle stanze di composizione dell'era Linotype, ogni riga di testo veniva fusa come una singola striscia di metallo, uno "slug", larga circa trenta picas e pesante circa dodici once di piombo. Il termine poi si spostò a significare l'identificatore breve che un editor scriveva in cima a una storia per etichettarla durante la produzione: una sigla di una o due parole come sindaco-bilancio o scuola-incendio che giornalisti, sub-editor e tipografi potevano usare per riferirsi alla storia senza scrivere il titolo completo. Le guide di stile AP e dei principali quotidiani documentano ancora l'uso.

Quando Movable Type, WordPress e i primi docs di Django adottarono "slug" come nome di campo all'inizio degli anni 2000, stavano prendendo in prestito il termine da redazione integralmente. La documentazione di Django chiama il campo slug almeno dalla release 0.91 nel 2005, con la definizione ora canonica: un'etichetta breve contenente solo lettere, numeri, underscore o trattini, generalmente usata negli URL. La metafora atterra precisamente perché sia lo slug fuso in piombo sia lo slug URL sono token brevi, distinti, machine-friendly che puntano a una cosa più lunga.

RFC 3986 e l'insieme dei caratteri non riservati

URL syntax is defined by RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"), published January 2005 by Tim Berners-Lee, Roy Fielding and Larry Masinter, replacing RFCs 2396 and 2732. It is an STD 66 Internet Standard, the IETF's highest maturity tier, reserved for protocols of demonstrated stability and broad implementation. Section 2.3 of RFC 3986 defines the unreserved characters, the only characters that are guaranteed to be safe in any URI component without percent-encoding: A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. That's sixty-six characters total. Everything else is either a reserved character (with structural meaning in some URI component) or "other", anything in the latter group must be percent-encoded if it appears in a URI.

Poiché l'insieme non riservato è l'unico insieme garantito di fare un round-trip pulito attraverso ogni parser URI mai scritto, i generatori di slug convergono su una pipeline quasi identica: minuscolizzare i caratteri alfabetici, mantenere le cifre, mantenere i trattini, sostituire lo spazio bianco con un singolo trattino, e o eliminare-o-traslitterare tutto il resto. Underscore, punto e tilde sono tecnicamente permessi ma convenzionalmente evitati negli slug: il punto si scontra con le estensioni di file, la tilde si legge come una directory home nelle vecchie convenzioni URL, e l'underscore perde contro il trattino per le ragioni SEO trattate sotto.

"Cool URIs Don't Change": Berners-Lee, 1998

La nota di stile di Tim Berners-Lee del 1998 "Cool URIs Don't Change", ospitata sul sito W3C, è il pezzo di filosofia sugli slug più citato mai scritto. La riga di apertura è famosa: un URI cool è uno che non cambia. La nota poi si legge come una polemica contro i design URL che cuociono dettagli implementativi transitori nel path. Le raccomandazioni "da non fare" hanno modellato la pratica degli slug per quasi trent'anni: non mettere estensioni dello strumento di authoring nell'URL: rivelano l'implementazione e si rompono quando migri; non mettere lo status nell'URL: le pagine escono da "current" ma l'URL non dovrebbe; non mettere i nomi degli autori: gli autori se ne vanno; non mettere date a meno che la data sia fondamentale alla risorsa; non mettere ID di sessione, parametri di query o stato di login in un URL canonico.

Lo slug, le parole-trattino-minuscole descrittive e semantiche, è esattamente ciò che è permesso in un URI "cool". Tutto il resto è decorazione strutturale che non dovrebbe sanguinare nell'indirizzo. Il design dei permalink di WordPress, lo SlugField di Django e il to_param di Rails interiorizzano tutti questa guida: emettere un URL che è il significato della pagina, non i meccanismi di come viene servita.

I trattini battono gli underscore: ed è documentato

In un'intervista WebmasterWorld del 2005, l'ingegnere Google Matt Cutts disse che i trattini sono trattati come separatori di parola dal tokenizer di Google, mentre gli underscore sono unificatori di parola. Quindi green-apples viene letto come i due token green e apples, mentre green_apples viene letto come il singolo token green_apples. Per la query "green apples", l'URL con trattino corrisponderebbe al controllo title-keyword; l'URL con underscore no. Cutts riprese questo nel 2007 sul suo blog e in un video del 2011 di Google Webmaster Help su YouTube ("Underscores vs. dashes in URLs"), riaffermando lo stesso consiglio e notando che Google a un certo punto aveva valutato di cambiare il comportamento dell'underscore per agire anch'esso come separatore ma non l'aveva fatto perché avrebbe rotto troppi URL esistenti che usavano intenzionalmente gli underscore come unificatori (__init__.py, nomi di funzioni di programmazione).

La pagina attuale di Google "URL structure best practices for Google Search" raccomanda direttamente i trattini: un URL come /green-dress.html è più utile di /greendress.html, e dovresti usare trattini invece di underscore. La raccomandazione è stata continuamente documentata per oltre vent'anni. L'effetto è piccolo per URL ma si compone su un sito di migliaia di pagine, e convertire trattini in underscore non ha vantaggio: non c'è scenario SEO dove gli underscore vincono. Ogni guida credibile sugli slug finisce con lo stesso consiglio: usa i trattini.

Normalizzazione Unicode: come NFD elimina gli accenti

Lo standard Unicode definisce due modi per codificare molti caratteri accentati: precomposto (un singolo code point, dove é è U+00E9) e decomposto (una lettera base seguita da segni combinatori, dove é è U+0065 più U+0301, l'accento acuto combinatorio). Visivamente identici, byte per byte diversi. Unicode Technical Standard #15 definisce quattro forme di normalizzazione (NFC, NFD, NFKC, NFKD), e per la generazione di slug, NFD è la leva. Se prendi una stringa di input, normalizzi in NFD, poi elimini ogni code point nell'intervallo Unicode da U+0300 a U+036F (il blocco Combining Diacritical Marks), riottieni la lettera ASCII base. Café diventa cafe, naïve diventa naive, François diventa Francois, niño diventa nino, crème brûlée diventa creme brulee.

NFD non piega caratteri che non sono decomponibili in base+marca. La ß tedesca (s netta) non si decompone in ss sotto NFD: richiede traslitterazione esplicita. La ł polacca (l con barra) non si decompone in l. La ø norvegese non si decompone in o. Le þ islandesi (thorn) e ð (eth) hanno bisogno di tabelle di lookup. I browser hanno supportato nativamente String.prototype.normalize() dal 2015 circa (Chrome 34, Firefox 31, Safari 10), motivo per cui anche piccole utility di slugify in JavaScript possono fare il lavoro di eliminazione dei diacritici senza una libreria.

La famiglia delle librerie slugify: cosa distribuisce ogni ecosistema

Il django.utils.text.slugify() di Django è nel framework Python dall'inizio degli anni 2000. Minuscolizza, elimina i caratteri non in [A-Za-z0-9_-], e sostituisce lo spazio bianco con trattini. Da Django 1.9 (2015) un keyword allow_unicode=True commuta a una modalità Unicode-aware che preserva le lettere non ASCII. È l'implementazione di riferimento che tutti gli altri copiano. In Node.js, @sindresorhus/slugify di Sindre Sorhus è il pacchetto slugify più scaricato su npm, con milioni di download settimanali: le funzionalità includono separatori leggibili dagli umani, sostituzioni personalizzabili (così puoi mappare & a and, @ a at), gestione Unicode e minuscolizzazione locale-aware (I turca con/senza punto, ß → ss tedesca). Per gli utenti Python che non usano Django, python-slugify di Val Neekman su PyPI avvolge la libreria di traslitterazione unidecode e aggiunge comportamento specifico per slug: word-splitting regex, caratteri di sostituzione, lunghezza massima, rimozione di stop-word.

Altri ecosistemi seguono lo stesso pattern. PHP ha cocur/slugify di Cocur su Packagist, usato da plugin Laravel e Symfony, e Symfony stesso distribuisce un AsciiSlugger in symfony/string dalla versione 5.0. Ruby on Rails usa String#parameterize, integrato in ActiveSupport almeno da Rails 1.0; la gem friendly_id stratifica history-tracking e gestione delle collisioni sopra. Go ha gosimple/slug con tabelle locali per oltre ottanta lingue. Rust ha la crate slug. Java ha Apache Commons Text e slugify-jvm. La cosa notevole è quanto sia convergente l'API: stringa di input dentro, stringa di slug fuori, con la stessa manciata di opzioni: separatore, lunghezza-max, minuscolo, locale. Lo strumento di Absolutool si trova nella stessa famiglia ma gira interamente nel tuo browser, senza alcuna libreria da installare.

WordPress: il 43% del web esegue questa pipeline

WordPress è il singolo più grande sistema che emette slug sul web: alimenta circa il 43% di tutti i siti web secondo il sondaggio W3Techs del 2026, quindi le sue convenzioni sugli slug sono effettivamente le convenzioni del web sugli slug per la maggior parte dei lettori. Quando un post viene salvato, WordPress auto-genera lo slug dal titolo via sanitize_title() (che chiama sanitize_title_with_dashes() per il caso di rewrite di default): minuscola, elimina HTML, decodifica entità, sostituisce spazio bianco e la maggior parte della punteggiatura con trattini, percent-encode caratteri non sicuri, collassa trattini adiacenti, taglia trattini iniziali/finali. Se il risultato collide con lo slug di un post esistente, WordPress appende -2, -3 e così via. Lo slug è modificabile nell'editor del post: una volta che un post è pubblicato, cambiare lo slug rompe ogni link esistente a meno che il publisher non imposti un redirect. WordPress storicamente non traslitterava i caratteri non ASCII di default; li percent-encode-ava, il che produceva i famosi URL Cirillici brutti come %D0%BF%D1%80%D0%B8... che plugin come Cyr-To-Lat furono scritti per risolvere.

Oltre il latino: traslitterazione per cirillico, CJK, arabo

NFD gestisce solo caratteri che si decompongono in base ASCII + segni combinatori. Per gli script non latini, la pipeline degli slug ha bisogno di traslitterazione: una mappatura da ogni carattere non latino al suo equivalente in script latino. La libreria Python canonica è unidecode, originariamente un port del Text::Unidecode Perl di Sean M. Burke del 2001, che mappa virtualmente ogni carattere nel Basic Multilingual Plane a una stringa ASCII di best-guess: Москва → Moskva, Αθήνα → Athena. Il fallback CJK è la parte controversa: unidecode usa il pinyin mandarino per tutti i caratteri CJK perché il cinese ha la più ampia copertura di caratteri CJK, il che produce romanizzazioni senza senso per il giapponese (東京 → Dong Jing in pinyin, non Tokyo). Strumenti specifici per il giapponese come pykakasi fanno il lavoro di convertire kanji + kana in vero rōmaji. La libreria International Components for Unicode (ICU), mantenuta dal Unicode Consortium e da IBM, fornisce un'API Transliterator con set di regole nominati come Russian-Latin/BGN, Greek-Latin/UNGEGN e Han-Latin che implementano standard di romanizzazione ufficiali. Lo strumento di Absolutool si trova all'estremo più leggero: piega i diacritici latini via NFD ed elimina tutto il resto. Un utente che vuole un titolo russo o cinese sluggato può eseguire un passaggio di traslitterazione separato prima di incollare il testo.

Limiti di lunghezza degli URL: da dove viene la regola dei 2.000 caratteri

Non c'è alcun limite di lunghezza specificato dalla RFC 3986 stessa: la sintassi URI è illimitata. Ogni limite è pratico. Internet Explorer storicamente capava gli URL a 2.083 caratteri (un limite hard cotto nel motore Trident), che è l'origine della ampiamente citata regola empirica dei "2.000 caratteri". Chrome, Firefox, Safari ed Edge moderno supportano URL fino a circa 64.000 a 100.000+ caratteri nella barra degli indirizzi. Il LimitRequestLine di Apache predefinisce a 8.190 byte per l'intera linea di richiesta; il large_client_header_buffers di nginx predefinisce a 8 KB; IIS predefinisce a 16.384 byte per l'URL e 4.096 per la query string. RFC 9110 (HTTP/1.1, 2022) raccomanda in §4.1 che un server "dovrebbe essere capace di gestire URI di lunghezza 8.000 ottetti o più" ma non impone un limite superiore. Per gli slug, ciò che conta è che siano convenzionalmente brevi: tre a sette parole, trenta a sessanta caratteri, per SEO e condivisibilità. John Mueller di Google ha detto in più Webmaster Hangout che la lunghezza dell'URL stessa non è un segnale di ranking, ma URL lunghi possono essere troncati negli snippet dei risultati di ricerca, danneggiare il click-through rate e sembrare poco professionali nelle condivisioni social. La maggior parte dei generatori di slug espone un'opzione di lunghezza-max per questo motivo; questo predefinisce a illimitato e ti permette di impostare un cap.

Rimozione delle stop-word: denso contro grammaticale

Molte librerie di slugify offrono rimozione opzionale di stop-word: scartare parole brevi comuni (a, an, the, of, is, and, or, to, in, for, on) prima di assemblare lo slug. La motivazione è che non aggiungono segnale SEO e gonfiano l'URL. Quindi "The Best Way to Make a Cup of Tea" diventa best-way-make-cup-tea (5 token, 24 caratteri) invece di the-best-way-to-make-a-cup-of-tea (10 token, 35 caratteri). Il compromesso: più corto e denso, ma con occasionale collasso grammaticale (how-to-be-good ridotto a how-good perde significato) e un rischio di rimuovere parole che effettivamente portano intento (art-of-war ridotto a art-war). WordPress non elimina le stop-word di default: è un comportamento opt-in da plugin, e la maggior parte dei generatori di slug moderni le lascia disattive di default e le espone come checkbox. Yoast SEO per WordPress segnala uno slug contenente stop-word come raccomandazione minore piuttosto che errore. Questo generatore non elimina le stop-word automaticamente, sulla base che il publisher conosce l'intento del titolo meglio di una lista di parole statica. Se le vuoi via, modifica direttamente l'output.

Collisioni di slug: cosa fanno i CMS quando due post condividono un titolo

Quando due post auto-generano lo stesso slug ("My Post" e "My-Post!" producono entrambi my-post), il sistema deve risolvere il conflitto. Le strategie più comuni: un suffisso numerico (my-post-2, my-post-3): prevedibile, non collide mai, ma il suffisso non porta differenza semantica; un prefisso di data (2026-04-27/my-post): funziona bene per contenuti blog ed è il default in Jekyll, Hugo e nella maggior parte dei siti di notizie; un suffisso autore (my-post-jane): usato da Medium e blog multi-autore; un suffisso hash casuale (my-post-a3f9): usato da Stack Overflow, Notion e sistemi di shortlink, scambiando leggibilità umana per unicità garantita; o modifica manuale al momento della pubblicazione: editorialmente pulita ma raramente il default perché interrompe il flusso. La scelta pragmatica per la maggior parte dei CMS è il suffisso numerico con modifica manuale come via di fuga. I permalink con prefisso di data sono popolari per contenuti ancorati al tempo dove la data è informazione significativa.

Impatto SEO: lo slug come segnale minore ma visibile

La documentazione di ranking di Google elenca la struttura URL come segnale di ranking minore: contenuto della pagina, backlink, segnali di engagement utente e freschezza portano tutti più peso. Ma le parole dell'URL contribuiscono, e contribuiscono visibilmente. I termini dello slug appaiono nella riga URL dello snippet SERP sotto il titolo, il che influenza il click-through rate anche quando lo slug stesso non è classificato. I termini dello slug possono apparire in grassetto nel SERP se corrispondono alla query dell'utente: peso visivo extra. Il testo di ancora dai link interni ed esterni spesso predefinisce all'URL quando non viene fornito testo del link, quindi uno slug semantico diventa il testo del link e porta le sue parole chiave attraverso l'equity dei link in entrata. I test A/B tra publisher mostrano costantemente che gli slug descrittivi aumentano il CTR di percentuali a una cifra rispetto agli ID opachi. Lo studio dei fattori di ranking del 2020 di Backlinko (1,18 milioni di SERP analizzate) ha trovato che gli URL brevi hanno performato leggermente meglio degli URL lunghi in cima alle SERP.

C'è un'eccezione all'intuizione "più keyword = meglio": il keyword stuffing. L'aggiornamento Exact-Match Domain (EMD) del settembre 2012 ha specificamente ridotto il credito per domini exact-match e slug di bassa qualità (cheap-life-insurance.com/buy-cheap-life-insurance), e Google ha continuato a scontare il keyword stuffing negli URL da allora. Il messaggio del 2026: la presenza di keyword nello slug aiuta modestamente; il keyword stuffing fa male. La singola più grande vittoria SEO da uno slug è non cambiarlo dopo la pubblicazione. I link in entrata si accumulano a un URL. L'autorità della pagina si compone a livello URL. Un redirect 301 preserva la maggior parte ma non tutta l'equity dei link, e solo se il publisher imposta effettivamente il redirect: molti non lo fanno. Il consiglio di Berners-Lee "Cool URIs Don't Change" ha conseguenze SEO dirette: ogni cambio di slug, anche con un redirect, costa una piccola quantità di autorità che richiede tempo per essere recuperata.

Buone pratiche SEO per gli slug

Domande frequenti

Supporta i caratteri accentati?

Sì. Il generatore usa la normalizzazione Unicode (NFD) per rimuovere gli accenti. Per esempio, «cafe» resta «cafe» mentre «café» diventa anch'esso «cafe». Questo garantisce slug puliti, in ASCII puro.

Bisogna usare trattini o trattini bassi?

I trattini sono raccomandati per il SEO. La documentazione ufficiale di Google conferma che i trattini negli URL sono trattati come separatori di parole, mentre i trattini bassi no. Così «mio-articolo» è letto come due parole, mentre «mio_articolo» ne forma una sola.

Cosa succede agli emoji e ai simboli?

Le emoji non sono nell'insieme dei caratteri non riservati dell'URL, e NFD non le decompone: non hanno equivalente latino. Questo generatore le elimina. Altri strumenti percent-encode-ano le emoji (trasformando un singolo carattere in una lunga stringa come %F0%9F%94%A5), che tecnicamente funziona nei browser moderni ma produce URL illeggibili in analytics, condivisioni social e anteprime email. La maggior parte delle guide sugli slug raccomanda di eliminare le emoji del tutto; se vuoi che siano preservate, percent-encode-ale a monte del passaggio dello slug.

Questo strumento sluggherà titoli russi, cinesi o arabi?

Non da solo. NFD piega solo caratteri accentati in script latino; non può traslitterare cirillico, greco, arabo, ebraico o script CJK in latino. Incollare un titolo russo o cinese in questo strumento eliminerà quei caratteri e produrrà uno slug vuoto o quasi vuoto. Il workflow giusto è eseguire un passaggio di traslitterazione prima: unidecode di Python, il pacchetto npm transliteration di JavaScript o le convenzioni di romanizzazione di Wikipedia, e incollare il risultato romanizzato qui. Per il giapponese specificamente, usa uno strumento kana-aware come pykakasi: i traslitteratori CJK generici applicano il pinyin mandarino e producono Dong Jing per 東京 piuttosto che Tokyo.

E se devo cambiare uno slug dopo la pubblicazione?

Imposta un redirect 301 dal vecchio URL a quello nuovo prima di cambiare lo slug. Un 301 ("Moved Permanently") preserva la maggior parte dell'equity dei link che si è accumulata al vecchio URL e dice ai crawler e ai browser di aggiornare i loro segnalibri. Senza un redirect, ogni link in entrata esistente si rompe e perdi l'autorità della pagina che quei link rappresentavano. Anche con un redirect, perdi una piccola quantità di equity che richiede settimane o mesi per essere recuperata. La massima di Berners-Lee, gli URI cool non cambiano, è in parte estetica, in parte una verità SEO: ogni cambio di slug costa qualcosa, quindi vale la pena di azzeccare lo slug la prima volta.

C'è una lunghezza dello slug raccomandata?

La convenzione è da tre a sette parole, circa trenta a sessanta caratteri. Abbastanza lungo per essere descrittivo, abbastanza corto perché lo snippet SERP di Google non lo tronchi e gli umani possano cogliere l'argomento a colpo d'occhio. Non c'è massimo tecnico rigido: la RFC 3986 non ne specifica uno e i browser moderni gestiscono URL nelle decine di migliaia di caratteri, ma Apache, nginx e IIS impongono cap pratici nell'intervallo dei kilobyte, e la regola legacy dei "2.000 caratteri" da Internet Explorer è ancora citata come un soffitto cross-platform sicuro. L'opzione Lunghezza Massima qui ti permette di cappare l'output; impostarla a 0 significa illimitato.

I miei testi vengono memorizzati o inviati da qualche parte?

No. La trasformazione gira interamente nel tuo browser usando il metodo integrato di JavaScript String.prototype.normalize() (supportato da Chrome 34, Firefox 31, Safari 10: circa 2015). Niente viene caricato, nessuna API è chiamata, nessun log è scritto. Puoi verificarlo aprendo il pannello Network di DevTools del tuo browser mentre generi slug: non ci sono richieste in uscita. La pagina è sicura per slug derivati da titoli non pubblicati, documentazione interna, post bozza o qualsiasi altro contenuto che non vuoi che lasci il tuo dispositivo.

Strumenti correlati

Codificatore / decodificatore URL

Codifica o decodifica URL e componenti URI.

Convertitore di maiuscolo/minuscolo

Converti testo tra differenti maiuscole/minuscole.

Contatore di parole

Conta parole, caratteri e tempo di lettura.