O que é um slug de URL e como escrever um que aguente

Um slug de URL é o pedaço legível no fim de um endereço web que dá nome a uma página específica: o what-makes-a-good-url-slug do endereço da página que você está lendo. Ele vem depois do domínio e das pastas de seção, identifica a página e não o site, e em quase toda plataforma de publicação você pode editá-lo. Sua única função é dizer a uma pessoa o que ela está prestes a abrir quando o link chega sem nenhum outro contexto em volta.

Divida um endereço em suas partes e fica óbvio qual é qual. Em example.com/blog/what-makes-a-good-url-slug/, o domínio diz quem publica, /blog/ diz de que tipo de coisa se trata e o último segmento diz qual delas. Mude o slug e você passa a apontar para outra página — que é exatamente por que mudá-lo é uma decisão maior do que parece.

Para que o slug serve de verdade

Duas coisas, e as duas puxam na mesma direção.

Ele é uma prévia. Os links são colados em mensagens, e-mails e documentos sem mais nada em volta: sem título, sem miniatura, sem a frase que os cercava. Um endereço que termina em ?p=4127 — o que o WordPress serve até você definir uma estrutura de links permanentes — não diz nada a quem recebe e parece algo em que não se deve clicar. Um slug como returns-and-refunds responde à pergunta antes de a página carregar.

Ele é uma descrição que os buscadores conseguem ler. A própria orientação do Google sobre estrutura de URL é usar palavras em vez de identificadores opacos, e os resultados de busca continuam mostrando a URL, ou uma trilha de navegação construída a partir dela, embaixo do título. Isso vale alguma coisa. Não vale muita coisa: as palavras de um slug são um sinal fraco perto do conteúdo da página, e reescrever uma URL não faz uma página pior ganhar de uma melhor. Trate isso como um retoque final, não como uma alavanca, e você vai tomar decisões sensatas a respeito.

Como é um bom slug

• Minúsculas, sempre. Na maioria dos servidores os caminhos diferenciam maiúsculas de minúsculas, então /About/ e /about/ podem funcionar como duas páginas separadas competindo uma com a outra.
• Hífens, não underscores. O Google diz há anos que lê um hífen como separação de palavras e um underscore como junção, o que faz de url_slug um único token para ele.
• De três a seis palavras. Não existe penalidade por comprimento nem prêmio pela brevidade em si. Corte o enchimento e mantenha as palavras que alguém realmente digitaria.
• Descreve a página, não o site. /blog/acme-blog-post-about-shipping/ desperdiça metade dos caracteres com coisas que o domínio já disse.
• Nada que expire. Um ano, um número de versão ou um "10" na frente de uma lista acabam ficando errados mais cedo ou mais tarde, e corrigir isso significa mudar a URL. Algumas plataformas colocam a data de publicação no caminho automaticamente; se a sua faz isso e você escreve algo atemporal, desligue antes de publicar, não depois.
• Único no site inteiro. Dois posts chamados "Getting Started" produzem o mesmo slug, e a maioria dos sistemas de conteúdo resolve o conflito silenciosamente pendurando um -2 no segundo.

Por que o "deixa em minúsculas e troca espaços por hífens" quebra

Essa é a primeira implementação de todo mundo, e ela sobrevive até o primeiro título com pontuação de verdade.

• Sequências de separadores. Dois-pontos seguidos de um espaço viram dois separadores, então "Slugs: a guide" se transforma em slugs--a-guide a menos que você junte as repetições.
• As pontas. Um título que termina em ponto de interrogação deixa um hífen sobrando no fim; um que abre com aspas deixa outro na frente.
• Os apóstrofos. Trate-os como separadores e "don't" vira don-t. Eles devem ser apagados, não substituídos, para sair dont.
• Os ampersands. Apagar o caractere perde a palavra. "Terms & conditions" deveria virar terms-and-conditions, não terms-conditions.
• Os acentos. Uma regra que apaga tudo fora da faixa ASCII come os acentos, então "café" chega como caf.

Esse último é a armadilha que vale a pena entender, porque a correção padrão corrige só uma parte. O Unicode pode escrever a letra é de duas formas: como um único caractere, ou como um e simples seguido de uma marca de acento combinante. As bibliotecas de slug exploram isso: normalizam o texto para a forma decomposta e depois jogam fora as marcas combinantes. Uma linha de código, e é, ñ, ü, å e ç se reduzem todas às suas letras simples.

Isso não faz nada por ß, ø, æ, œ, ł ou þ. Essas não são versões acentuadas de nada — são letras próprias, sem nenhum caractere base dentro delas para revelar — então escapam da etapa de normalização e acabam apagadas pelo filtro ASCII. "Straße" sai como strae, silenciosamente, e ninguém percebe até que um leitor alemão perceba. A única cura é uma tabela de correspondências que soletre essas letras, e por isso gerar o slug com algo que já traga uma ganha de escrever você mesmo a expressão regular pela quinta vez. Cole uma lista de títulos, um por linha, e você recebe a versão sem acentos, aparada e limitada no comprimento de cada um.

Um slug pode estar em cirílico, grego ou chinês?

Tecnicamente sim. Uma URL só pode conter um conjunto estreito de caracteres ASCII, então todo o resto recebe percent-encoding: é convertido em bytes UTF-8, com cada byte escrito como um sinal de porcentagem e dois dígitos hexadecimais. Os navegadores fazem isso automaticamente e depois escondem, então um slug russo ou grego parece perfeitamente limpo na barra de endereços.

A codificação aparece no instante em que o link sai do navegador. As letras cirílicas ocupam dois bytes cada uma em UTF-8, e cada byte custa três caracteres para codificar, então cada letra vira seis caracteres de ruído hexadecimal em um e-mail de texto puro, uma mensagem de chat ou uma célula de planilha. Os caracteres chineses e japoneses ocupam três bytes, então custam nove. Se você quiser ver exatamente no que um slug se transforma antes de se comprometer com ele, passe-o pelo codificador de URL e olhe a versão que é copiada. O percent-encoding, explicado direito cobre por que uma única letra acentuada produz dois escapes e como os links acabam codificados duas vezes.

Ou seja, é uma decisão de critério, não técnica. Um site cujos leitores são todos gregos não perde nada usando grego nas suas URLs. Para um site cujos links são compartilhados internacionalmente, o melhor é transliterar — e transliterar é genuinamente difícil, porque a grafia latina correta da mesma letra cirílica muda entre o russo e o ucraniano. As ferramentas genéricas, a nossa incluída, descartam esses caracteres e avisam quantos sumiram em vez de chutar uma grafia.

Vale a pena tirar palavras como "the" e "of"?

Às vezes. Remover as stop words encurta a URL e não tira nada de que o leitor precise: the-history-of-the-slug e history-slug apontam para a mesma ideia.

O modo de falha é que alguns títulos são quase só palavras pequenas. "The Who" se reduz a who. "To Be or Not to Be" se reduz a not, porque uma lista que contém "to", "be" e "or" come cinco das seis palavras. Um filtro automático não distingue uma palavra de enchimento de uma que sustenta o sentido, então, se você ligar a opção, leia o resultado antes de publicar em vez de confiar na saída.

A outra coisa para ficar de olho é que o filtro roda depois que o ampersand foi escrito por extenso, então o "and" recém-criado é uma stop word como qualquer outra e é removido de novo. "Terms & conditions" dá terms-and-conditions normalmente e terms-conditions com as stop words ligadas. Nenhum dos dois está errado, mas escolha um de propósito.

O que acontece se você mudar um slug depois de publicar?

Todos os links para o endereço antigo quebram: os links de outras pessoas, os favoritos, a entrada que está no índice do Google, a URL da newsletter que você já enviou. Para a web, a página não foi movida. Ela foi apagada e uma nova apareceu.

A solução é um redirecionamento 301 do caminho antigo para o novo, que diz aos navegadores e aos rastreadores que a página foi movida permanentemente e transfere os sinais de ranqueamento acumulados. Configure antes da mudança ou ao mesmo tempo, nunca depois, e então mantenha indefinidamente: um link antigo pode ficar anos sem receber um clique dentro de um documento e ainda funcionar quando alguém finalmente o abrir.

E esse é o verdadeiro argumento para dedicar um minuto ao slug logo no começo. É uma das poucas coisas de uma página que é genuinamente cara de consertar depois. O título, as imagens e o texto podem ser reescritos nesta mesma tarde sem nenhuma consequência.

Última atualização 19 de setembro de 2026