Gerador de slug URL

Transforme qualquer texto em um slug compatível com URLs.

Apenas no navegador, o seu texto nunca sai do seu dispositivo


O que é um slug de 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.

Bons slugs usam apenas letras minúsculas, números e hífens. Eles removem acentos, caracteres especiais e espaços supérfluos. Isso melhora tanto o SEO quanto a experiência do usuário · os motores de busca e os humanos conseguem ler a URL e entender o conteúdo da página.

De onde vem a palavra, redacções do século XIX

A palavra precede a web num século. Nas salas de composição da era Linotype, cada linha de texto era fundida como uma única tira de metal (um «slug») com cerca de trinta picas de largura e pesando aproximadamente doze onças em chumbo. O termo derivou então para significar o curto identificador que um editor escrevia no topo de uma história para a etiquetar ao longo da produção: um handle de uma ou duas palavras como mayor-budget ou school-fire que jornalistas, sub-editores e tipógrafos podiam usar para se referir à história sem digitar o título completo. Os guias de estilo da AP e dos grandes diários ainda documentam essa utilização.

Quando o Movable Type, o WordPress e os primeiros docs do Django adoptaram «slug» como nome de campo no início dos anos 2000, estavam a tomar emprestado o termo da redacção de forma integral. A documentação do Django chama ao campo slug pelo menos desde a versão 0.91 em 2005, com a definição agora canónica: uma etiqueta curta que contém apenas letras, números, underscores ou hífenes, geralmente usada em URLs. A metáfora encaixa precisamente porque tanto o slug fundido em chumbo como o slug de URL são tokens curtos, distintos e machine-friendly que apontam para algo mais longo.

RFC 3986 e o conjunto de caracteres não reservados

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.

Como o conjunto não reservado é o único garantido para fazer ida e volta limpamente através de qualquer parser de URI alguma vez escrito, os geradores de slug convergem para um pipeline quase idêntico: passar a minúsculas os caracteres alfabéticos, manter os dígitos, manter os hífenes, substituir espaços em branco por um único hífen, e ou retirar ou transliterar tudo o resto. Underscore, ponto e til são tecnicamente permitidos mas convencionalmente evitados em slugs, o ponto colide com extensões de ficheiro, o til lê-se como directório home em convenções antigas de URL, e o underscore perde para o hífen pelas razões de SEO cobertas abaixo.

«Cool URIs Don’t Change», Berners-Lee, 1998

A nota de estilo de 1998 de Tim Berners-Lee «Cool URIs Don’t Change», alojada no site do W3C, é a peça mais citada de filosofia de slug alguma vez escrita. A linha de abertura é famosa: um cool URI é aquele que não muda. A nota lê-se depois como uma polémica contra os designs de URL que cozem detalhes de implementação transitórios no path. Os não-fazer recomendados moldaram a prática de slug durante quase trinta anos: não pôr extensões de ferramenta de autoria na URL (revelam a implementação e partem quando se migra; não pôr estado na URL) as páginas saem de «actual» mas a URL não devia; não pôr nomes de autores, os autores seguem caminho; não pôr datas a menos que a data seja fundamental ao recurso; não pôr IDs de sessão, parâmetros de query ou estado de login numa URL canónica.

O slug (as palavras descritivas, semânticas, minúsculas-com-hífenes) é exactamente o que é permitido num URI «cool». Tudo o resto é decoração estrutural que não devia sangrar para o endereço. O design de permaliks do WordPress, o SlugField do Django e o to_param do Rails interiorizam todos esta orientação: emitir uma URL que é o significado da página, não a mecânica de como é servida.

Os hífenes ganham aos underscores, e está documentado

Numa entrevista da WebmasterWorld em 2005, o engenheiro da Google Matt Cutts disse que os hífenes são tratados como separadores de palavras pelo tokenizer da Google, enquanto que os underscores são uniões de palavras. Portanto green-apples é lido como os dois tokens green e apples, enquanto que green_apples é lido como o único token green_apples. Para a consulta «green apples», a URL com hífenes corresponderia à verificação de palavra-chave do título; a URL com underscores não. Cutts voltou a este tema em 2007 no seu blog e num vídeo Google Webmaster Help de 2011 no YouTube («Underscores vs. dashes in URLs»), reafirmando o mesmo conselho e notando que a Google em determinada altura avaliou alterar o comportamento do underscore para também actuar como separador, mas não o fez porque teria partido demasiadas URLs existentes que usavam intencionalmente underscores como uniões (__init__.py, nomes de funções de programação).

A página actual da Google «URL structure best practices for Google Search» recomenda directamente os hífenes: uma URL como /green-dress.html é mais útil que /greendress.html, e deve usar-se hífenes em vez de underscores. A recomendação tem sido continuamente documentada há mais de vinte anos. O efeito é pequeno por URL mas acumula-se ao longo de um site com milhares de páginas, e converter hífenes para underscores não tem qualquer vantagem, não há cenário de SEO em que os underscores ganhem. Cada guia de slug credível termina com o mesmo conselho: usar hífenes.

Normalização Unicode, como o NFD remove acentos

O standard Unicode define duas formas de codificar muitos caracteres acentuados: pré-composto (um único code point, onde é é U+00E9) e decomposto (uma letra base seguida de marcas combinatórias, onde é é U+0065 mais U+0301, o acento agudo combinatório). Visualmente idênticos, byte a byte diferentes. O Unicode Technical Standard #15 define quatro formas de normalização (NFC, NFD, NFKC, NFKD) e para a geração de slugs, o NFD é a alavanca. Se pegar numa string de entrada, normalizá-la para NFD, e depois retirar todos os code points no intervalo Unicode U+0300 a U+036F (o bloco Combining Diacritical Marks), obtém de volta a letra ASCII base. Café torna-se cafe, naïve torna-se naive, François torna-se Francois, niño torna-se nino, crème brûlée torna-se creme brulee.

O NFD não dobra caracteres que não sejam decomponíveis em base+marca. O ß alemão (s aguda) não se decompõe em ss sob NFD, requer transliteração explícita. O ł polaco (l com traço) não se decompõe em l. O ø norueguês não se decompõe em o. O þ islandês (thorn) e ð (eth) precisam de tabelas de consulta. Os navegadores suportam nativamente String.prototype.normalize() desde aproximadamente 2015 (Chrome 34, Firefox 31, Safari 10), razão pela qual mesmo pequenas utilidades JavaScript de slugify podem fazer o trabalho de remoção de diacríticos sem biblioteca.

A família de bibliotecas slugify, o que cada ecossistema oferece

django.utils.text.slugify() do Django está no framework Python desde o início dos anos 2000. Passa a minúsculas, retira caracteres não em [A-Za-z0-9_-], e substitui espaços em branco por hífenes. Desde o Django 1.9 (2015) uma palavra-chave allow_unicode=True muda para um modo Unicode-aware que preserva letras não-ASCII. É a implementação de referência que toda a gente copia. Em Node.js, o @sindresorhus/slugify de Sindre Sorhus é o pacote slugify mais descarregado no npm, com milhões de downloads semanais, as funcionalidades incluem separadores legíveis, substituições personalizáveis (de modo a poder mapear & para and, @ para at), tratamento de Unicode e minúsculas locale-aware (I com/sem ponto turco, ß → ss alemão). Para utilizadores de Python que não usam Django, o python-slugify de Val Neekman no PyPI envolve a biblioteca de transliteração unidecode e adiciona comportamento específico de slug: divisão de palavras por regex, caracteres de substituição, comprimento máximo, remoção de stop-words.

Outros ecossistemas seguem o mesmo padrão. O PHP tem o cocur/slugify da Cocur no Packagist, usado por plugins de Laravel e Symfony, e o próprio Symfony oferece um AsciiSlugger em symfony/string desde a versão 5.0. O Ruby on Rails usa String#parameterize, incorporado no ActiveSupport pelo menos desde o Rails 1.0; o gem friendly_id sobrepõe rastreamento de histórico e tratamento de colisões. O Go tem gosimple/slug com tabelas de locale para mais de oitenta línguas. O Rust tem o crate slug. Java tem o Apache Commons Text e slugify-jvm. O notável é o quão convergente a API é: string de entrada, string de slug à saída, com o mesmo punhado de opções, separador, comprimento máximo, minúsculas, locale. A ferramenta da Absolutool senta-se na mesma família mas corre inteiramente no seu navegador, sem biblioteca a instalar.

WordPress: 43 % da web corre este pipeline

O WordPress é o maior sistema individual de emissão de slugs na web, alimenta cerca de 43 % de todos os sites segundo o levantamento da W3Techs de 2026, portanto as suas convenções de slug são efectivamente as convenções de slug da web para a maioria dos leitores. Quando um post é guardado, o WordPress gera automaticamente o slug a partir do título via sanitize_title() (que chama sanitize_title_with_dashes() para o caso de rewrite por defeito): minúsculas, retira HTML, descodifica entidades, substitui espaços em branco e a maior parte da pontuação por hífenes, percent-encode caracteres inseguros, colapsa hífenes adjacentes, apara hífenes iniciais/finais. Se o resultado colidir com o slug de um post existente, o WordPress acrescenta -2, -3, e assim por diante. O slug é editável no editor de post, uma vez publicado um post, alterar o slug parte qualquer link existente a menos que o editor configure um redireccionamento. O WordPress historicamente não transliterava caracteres não-ASCII por defeito; fazia-lhes percent-encode, o que produzia as URLs cirílicas famosamente feias como %D0%BF%D1%80%D0%B8... que plugins como o Cyr-To-Lat foram escritos para corrigir.

Para além do latino: transliteração para cirílico, CJK, árabe

O NFD só lida com caracteres que se decompõem em base ASCII + marcas combinatórias. Para escritas não latinas, o pipeline de slug precisa de transliteração: um mapeamento de cada carácter não latino para o seu equivalente em escrita latina. A biblioteca canónica em Python é unidecode, originalmente um port do Text::Unidecode Perl de Sean M. Burke de 2001, que mapeia praticamente todos os caracteres do Basic Multilingual Plane para uma string ASCII de «melhor palpite»: Москва → Moskva, Αθήνα → Athena. O fallback CJK é a parte controversa: o unidecode usa pinyin mandarim para todos os caracteres CJK porque o chinês tem a maior cobertura de caracteres CJK, o que produz romanizações sem sentido para japonês (東京 → Dong Jing em pinyin, não Tokyo). Ferramentas específicas para japonês como pykakasi fazem o trabalho de converter kanji + kana em rōmaji adequado. A biblioteca International Components for Unicode (ICU), mantida pelo Unicode Consortium e pela IBM, fornece uma API Transliterator com conjuntos de regras nomeados como Russian-Latin/BGN, Greek-Latin/UNGEGN, e Han-Latin que implementam padrões oficiais de romanização. A ferramenta da Absolutool senta-se na ponta mais leve: dobra diacríticos latinos via NFD e descarta tudo o resto. Um utilizador que queira um título russo ou chinês com slug pode correr um passo de transliteração separado antes de colar o texto.

Limites de comprimento de URL, de onde vem a regra dos 2.000 caracteres

Não há limite de comprimento especificado pelo próprio RFC 3986, a sintaxe URI é ilimitada. Cada limite é prático. O Internet Explorer historicamente limitou as URLs a 2.083 caracteres (um limite duro cozido no motor Trident), o que é a origem da regra empírica amplamente citada dos «2.000 caracteres». O Chrome, Firefox, Safari e Edge moderno suportam URLs até cerca de 64.000 a 100.000+ caracteres na barra de endereços. O LimitRequestLine do Apache vale por defeito 8.190 bytes para a linha de pedido inteira; o large_client_header_buffers do nginx vale por defeito 8 KB; o IIS vale por defeito 16.384 bytes para a URL e 4.096 para a query string. O RFC 9110 (HTTP/1.1, 2022) recomenda no §4.1 que um servidor «ought to be capable of handling URIs of length 8.000 octets or longer» mas não chega a impor um limite superior. Para os slugs, o que importa é que são convencionalmente curtos (três a sete palavras, trinta a sessenta caracteres) para SEO e partilhabilidade. O John Mueller da Google disse em vários Webmaster Hangouts que o comprimento da URL em si não é um sinal de ranking, mas URLs longas podem ser truncadas em snippets de resultados de pesquisa, prejudicar o CTR, e parecer pouco profissionais em partilhas sociais. A maioria dos geradores de slug expõe uma opção de comprimento máximo por esta razão; este por defeito é ilimitado e permite-lhe definir um tecto.

Remoção de stop-words: denso vs gramatical

Muitas bibliotecas de slugify oferecem remoção opcional de stop-words, descartar palavras curtas comuns (a, an, the, of, is, and, or, to, in, for, on) antes de montar o slug. A justificação é que não acrescentam sinal SEO e enchem a URL. Por isso «The Best Way to Make a Cup of Tea» torna-se best-way-make-cup-tea (5 tokens, 24 caracteres) em vez de the-best-way-to-make-a-cup-of-tea (10 tokens, 35 caracteres). O trade-off: mais curto e mais denso, mas com colapso gramatical ocasional (how-to-be-good reduzido a how-good perde significado) e o risco de remover palavras que efectivamente carregam intenção (art-of-war reduzido a art-war). O WordPress não retira stop-words por defeito (é comportamento de plugin opt-in) e a maioria dos geradores de slug modernos deixa-o desactivado por defeito e expõe-no como uma checkbox. O Yoast SEO para WordPress sinaliza um slug que contenha stop-words como recomendação menor em vez de erro. Este gerador não retira stop-words automaticamente, com o argumento de que o editor conhece melhor a intenção do título do que uma lista estática de palavras. Se as quiser fora, edite a saída directamente.

Colisões de slug: o que os CMS fazem quando dois posts partilham um título

Quando dois posts geram automaticamente o mesmo slug, «My Post» e «My-Post!» produzem ambos my-post: o sistema tem de resolver o conflito. As estratégias mais comuns: um sufixo numérico (my-post-2, my-post-3) (previsível, nunca colide, mas o sufixo não carrega diferença semântica; um prefixo de data (2026-04-27/my-post)) funciona bem para conteúdo de blog e é o por defeito no Jekyll, Hugo e na maioria dos sites de notícias; um sufixo de autor (my-post-jane) (usado pelo Medium e blogs multi-autor; um sufixo de hash aleatório (my-post-a3f9)) usado pelo Stack Overflow, Notion e sistemas de shortlinking, trocando legibilidade humana por unicidade garantida; ou edição manual no momento da publicação, editorialmente limpo mas raramente o por defeito porque interrompe o fluxo. A escolha pragmática para a maioria dos CMS é o sufixo numérico com edição manual como saída de emergência. Os permaliks com prefixo de data são populares para conteúdo ancorado no tempo onde a data é informação significativa.

Impacto SEO: o slug como sinal menor mas visível

A documentação de ranking da Google lista a estrutura de URL como um sinal de ranking menor, o conteúdo da página, backlinks, sinais de engagement do utilizador e frescura todos carregam mais peso. Mas as palavras da URL contribuem, e contribuem visivelmente. Os termos de slug aparecem na linha de URL do snippet SERP por baixo do título, o que influencia o CTR mesmo quando o próprio slug não está em ranking. Os termos de slug podem aparecer a negrito na SERP se corresponderem à consulta do utilizador, peso visual extra. O texto âncora de links internos e externos costuma valer por defeito a URL quando nenhum texto de link é fornecido, por isso um slug semântico torna-se o texto do link e carrega as suas palavras-chave através da equidade de link de entrada. Os testes A/B em editores mostram consistentemente que slugs descritivos aumentam o CTR em percentagens de um dígito sobre IDs opacos. O estudo de factores de ranking de 2020 da Backlinko (1,18 milhões de SERPs analisadas) descobriu que URLs curtas ligeiramente superaram URLs longas no topo das SERPs.

Há uma excepção à intuição «mais palavras-chave = melhor»: o keyword stuffing. A actualização Exact-Match Domain (EMD) de Setembro de 2012 reduziu especificamente o crédito para domínios e slugs exact-match de baixa qualidade (cheap-life-insurance.com/buy-cheap-life-insurance), e a Google continuou a descontar o keyword stuffing em URLs desde então. A conclusão de 2026: a presença de palavras-chave no slug ajuda modestamente; o keyword stuffing prejudica. O maior ganho SEO individual de um slug é não o alterar após a publicação. Os links de entrada acumulam-se para uma URL. A autoridade de página compõe-se ao nível da URL. Um redireccionamento 301 preserva a maior parte mas não toda a equidade de link, e só se o editor efectivamente configurar o redireccionamento, muitos não o fazem. O conselho «Cool URIs Don’t Change» de Berners-Lee tem consequências SEO directas: cada alteração de slug, mesmo com redireccionamento, custa uma pequena quantidade de autoridade que demora tempo a recuperar.

Boas práticas de SEO para slugs

Perguntas frequentes

Ele suporta caracteres acentuados ?

Sim. O gerador usa a normalização Unicode (NFD) para remover acentos. Por exemplo, « cafe » continua « cafe » enquanto « café » também vira « cafe ». Isso garante slugs limpos, em ASCII puro.

Devo usar hífens ou underscores ?

Os hífens são recomendados para SEO. A documentação oficial do Google confirma que os hífens nas URLs são tratados como separadores de palavras, enquanto os underscores não são. Assim, « meu-artigo » é lido como duas palavras, enquanto « meu_artigo » forma apenas uma.

O que acontece a emojis e símbolos?

Os emojis não estão no conjunto de caracteres não reservados de URL, e o NFD não os decompõe, não têm equivalente latino. Este gerador descarta-os. Outras ferramentas fazem percent-encode aos emojis (transformando um único carácter numa string longa como %F0%9F%94%A5), o que tecnicamente funciona em navegadores modernos mas produz URLs ilegíveis em analytics, partilhas sociais e previews de email. A maioria dos guias de slug recomendam retirar os emojis inteiramente; se os quiser preservar, faça percent-encode antes do passo de slug.

Isto vai gerar slugs de títulos russos, chineses ou árabes?

Não por si só. O NFD apenas dobra caracteres acentuados de escrita latina; não consegue transliterar escritas cirílica, grega, árabe, hebraica ou CJK para latina. Colar um título russo ou chinês nesta ferramenta vai descartar esses caracteres e produzir um slug vazio ou quase vazio. O fluxo correcto é correr um passo de transliteração primeiro (unidecode do Python, o pacote npm transliteration do JavaScript, ou as convenções de romanização da Wikipédia) e colar o resultado romanizado aqui. Para japonês especificamente, use uma ferramenta kana-aware como pykakasi: os transliteradores CJK genéricos aplicam pinyin mandarim e produzem Dong Jing para 東京 em vez de Tokyo.

E se eu precisar de alterar um slug após publicar?

Configure um redireccionamento 301 da URL antiga para a nova antes de alterar o slug. Um 301 («Moved Permanently») preserva a maior parte da equidade de link que se acumulou na URL antiga e diz a crawlers e navegadores para actualizarem os seus marcadores. Sem redireccionamento, qualquer link de entrada existente parte e perde-se a autoridade de página que esses links representavam. Mesmo com redireccionamento, perde-se uma pequena quantidade de equidade que demora semanas ou meses a recuperar. A máxima de Berners-Lee (cool URIs don’t change) é em parte estética, em parte uma verdade SEO: cada alteração de slug custa alguma coisa, por isso vale a pena fazer o slug bem à primeira.

Há um comprimento de slug recomendado?

A convenção é de três a sete palavras, aproximadamente trinta a sessenta caracteres. Suficientemente longo para ser descritivo, suficientemente curto para que o snippet SERP da Google não o trunque e os humanos consigam captar o tópico de relance. Não há máximo técnico rígido (o RFC 3986 não especifica um e os navegadores modernos lidam com URLs de dezenas de milhares de caracteres) mas o Apache, nginx e IIS impõem tectos práticos na faixa dos kilobytes, e a regra herdada dos «2.000 caracteres» do Internet Explorer ainda é citada como tecto seguro entre plataformas. A opção Comprimento Máximo aqui permite-lhe limitar a saída; defini-la para 0 significa ilimitada.

Os meus textos são guardados ou enviados para algum lugar?

Não. A transformação corre inteiramente no seu navegador usando o método incorporado String.prototype.normalize() do JavaScript (suportado desde o Chrome 34, Firefox 31, Safari 10, aproximadamente 2015). Nada é carregado, nenhuma API é chamada, nenhum log é escrito. Pode verificar isto abrindo o separador Network das DevTools do seu navegador enquanto gera slugs, não há pedidos de saída. A página é segura para slugs derivados de títulos não publicados, documentação interna, posts rascunho ou qualquer outro conteúdo que não queira que saia do seu dispositivo.

Ferramentas relacionadas

Codificador / decodificador de URL

Codifique ou decodifique URLs e componentes de URI.

Conversor de caixa

Converta texto entre diferentes caixas.

Contador de palavras

Conte palavras, caracteres e tempo de leitura.