O que faz um bom slug de URL: estabilidade, legibilidade e o conflito entre as duas
Publicado a 26/11/2025 · 14 min de leitura · Ferramentas de marketing e SEO
Camille Laurent — Redatora de Finanças na OneKitly
Fiscalidade · Finanças pessoais
Verificado a partir de 5 fontes
Um slug é a parte legível do caminho de um URL, e pedem-lhe duas coisas incompatíveis: manter-se idêntico para sempre, porque cada ligação e cada sinal de classificação apontam para a cadeia exata, e ler-se bem, porque tanto as pessoas como os motores o veem. Otimizar a legibilidade implica reescrevê-lo quando o título melhora; otimizar a estabilidade implica nunca lhe tocar. A Google recomenda hífenes em vez de sublinhados, palavras na língua do leitor e codificação percentual para tudo o que sai do ASCII — e é aí que a legibilidade parte, porque um slug alemão de 27 caracteres passa a 37 codificado e um CJK de quatro passa a 36. Este site resolve o conflito separando as duas funções: um identificador interno que nunca muda e um segmento público derivado do título próprio de cada língua, limitado a 70 caracteres, com palavras vazias removidas apenas se esse limite for ultrapassado. Na execução de 9 de agosto de 2026 isso produziu seis slugs públicos distintos para as 1736 ferramentas e os 631 artigos, com duas colisões resolvidas de forma determinista. Se tiver de mudar um slug, redirecione de forma permanente: os rastreadores da Google seguem até dez saltos de redirecionamento, por isso as cadeias sobrevivem mas não são grátis, e um redirecionamento temporário não passa sinal canónico nenhum.
Um slug tem duas funções que puxam em sentidos opostos: é um identificador permanente e é um texto legível. Comprimento, hífenes, palavras vazias, datas, caracteres não ASCII e o padrão identificador + slug que consegue ambas as propriedades — com os números reais de um site que localiza 1736 slugs de ferramentas em seis línguas.
Duas funções, uma só cadeia
O slug é o último segmento do caminho de um URL — a parte que diz o que a página é. É ao mesmo tempo um identificador, porque as ligações, os favoritos, as linhas de analítica e a memória de classificação de um motor são todas indexadas pela sequência exata de bytes, e uma etiqueta, porque aparece na barra de endereço, numa mensagem partilhada e muitas vezes no próprio resultado. Os identificadores querem ser imutáveis. As etiquetas querem ser melhoradas. É toda a tensão, e cada regra sobre slugs é uma forma de a gerir.
O lado identificador é o caro de errar. Mude um slug e cada ligação externa passa a apontar para um URL que já não existe. Um redirecionamento permanente repara isso: a documentação da Google indica que o processo de indexação usa um redirecionamento permanente como sinal de que o destino deve ser canónico, enquanto um redirecionamento temporário explicitamente não é usado assim. O tipo de redirecionamento importa, portanto, mais do que se supõe, e o instinto comum de pôr um 302 porque a mudança parece reversível é precisamente o erro inverso.
Os redirecionamentos também se acumulam. A documentação da Google indica que por omissão os seus rastreadores seguem até dez saltos de redirecionamento. Dez é um orçamento generoso, mas é um orçamento, e um site que renomeia os seus slugs de dois em dois anos gasta-o em silêncio: uma ligação de oito anos pode já estar a quatro saltos da página. Cada salto é ainda uma ida e volta a mais para uma pessoa com ligação lenta. A regra prática não é «nunca encadear» mas «achatar»: quando acrescentar o salto número dois, reescreva o salto número um para apontar ao destino final.
Hífenes, sublinhados e porque existe a convenção
O guia da Google sobre estrutura de URL é aqui invulgarmente direto: recomenda hífenes em vez de sublinhados para separar palavras, porque ajuda utilizadores e motores a identificar melhor os conceitos no URL. A razão é histórica e mecânica, não estética. Um tokenizador corta pelos caracteres que não são caracteres de palavra, e o sublinhado foi tradicionalmente tratado como carácter de palavra — a convenção que permite que um identificador como max_speed continue a ser um único token no código-fonte. Assim, sapatos_vermelhos pode ser tokenizado como um termo e sapatos-vermelhos como dois.
Se algum motor moderno continua a comportar-se assim não é algo que alguém de fora possa verificar, e também não importa muito: a convenção é hoje tão universal que um slug com sublinhados sinaliza sobretudo um site que ninguém olha há uma década. O único ponto onde a distinção ainda morde com força é um hífen dentro de uma palavra composta. Em alemão um composto é uma só palavra, por isso um slug que o separa com hífen parte um termo que devia ficar inteiro. Este site resolve isso derivando o slug alemão do título alemão, que já escreve o composto numa palavra, em vez de traduzir um slug inglês palavra a palavra.
Comprimento, e onde um resultado deixa de mostrar o caminho
Ninguém publica um limite de caracteres para slugs, porque não existe. O que existe é um orçamento de exibição: um resultado mostra o nome do site e um caminho encurtado, e a barra de endereço de um navegador tem largura finita. Ambos truncam, ambos truncam de forma diferente num telemóvel, e nenhum está documentado. Uma regra de comprimento escolhe-se, portanto, não se consulta. Este site escolheu 70 caracteres, e o corpus contém já slugs que o atingem exatamente — o mais longo é o slug português de 70 caracteres quantos-montantes-parede-preciso-estrutura-por-espacamento-comprimento.
O interessante é o que acontece quando um título ultrapassa o orçamento. Truncar a meio de uma palavra produz um slug que se lê como um erro. Truncar numa fronteira de palavra faz perder as palavras que vieram no fim, que na maioria das línguas são as específicas. O gerador aqui faz outra coisa: primeiro remove as palavras vazias — o, a, os, as, de, do, da, um, uma, e, para, seu, sua em português, e as listas correspondentes nas outras cinco línguas — e só depois suprime palavras finais, sem nunca descer abaixo de três. Essa ordem importa, porque uma palavra vazia é a única parte de um slug que não leva sinal de pesquisa e custa caracteres reais.
Há um segundo corte que acontece antes de tudo isso. Um título do tipo «Título principal: o qualificativo» ou «Título principal (um aparte)» contém duas coisas, e só o título pertence a um caminho — o qualificativo é para isso que serve uma meta-descrição. O gerador, portanto, elimina os parênteses e corta nos primeiros dois-pontos ou travessão antes sequer de sluguificar. Essa regra sozinha elimina a maioria dos problemas de comprimento antes de a lista de palavras vazias ser consultada.
A questão do não ASCII, resolvida seis vezes
O guia da Google recomenda usar palavras na língua do leitor, transliteradas quando aplicável, e codificar em percentagem tudo o que saia do intervalo ASCII. Essas duas frases estão em tensão para qualquer língua com acentos, e a tensão mede-se. Codifique a locução alemã grundstücksfläche-berechnen e 27 caracteres passam a 37 — uma expansão de 37,0 %, porque ü e ä custam seis caracteres cada um, %C3%BC e %C3%A4. Um slug espanhol com um só ñ cresce 19,2 %. Um slug cirílico de quinze caracteres passa a 85, 5,67 vezes mais. Um slug CJK de quatro caracteres passa a 36, nove vezes mais.
Que isso importe ou não depende inteiramente de onde o URL vai ser visto. Um navegador moderno descodifica o caminho de volta a caracteres legíveis na barra de endereço, por isso um leitor no site vê os acentos. Cole o mesmo URL num e-mail em texto simples, num cliente de mensagens que não descodifica, num relatório de analítica, numa folha de cálculo, numa linha de log ou num diapositivo impresso, e o leitor vê os sinais de percentagem. Um URL é copiado mais vezes do que é escrito, e a cópia aterra no contexto feio com frequência suficiente para isto ser um custo real, não teórico.
Este site divide a diferença por língua em vez de fingir que uma resposta serve às seis. O alemão converte ä, ö, ü e ß em ae, oe, ue e ss, que é a convenção alemã habitual para texto ASCII e dá grundstuecksflaeche-berechnen em 29 caracteres — oito a menos do que a forma codificada, e legível em todo o lado. As outras cinco retiram o diacrítico, por isso contraseñas passa a contrasenas e régime passa a regime. Nenhuma escolha está errada; são respostas diferentes à pergunta sobre o que um leitor dessa língua espera que uma palavra despojada pareça.
Seis línguas, seis slugs, um só identificador
O padrão que consegue ambas as propriedades ao mesmo tempo é antigo e pouco glamoroso: manter um identificador estável que nunca muda e deixar que a parte legível seja derivada em vez de escrita. Os fóruns e os gestores de incidentes fazem-no com um id numérico seguido de um slug, de modo que /42/um-titulo-velho e /42/o-que-quer-que-seja resolvem ambos, e o slug pode ser reescrito sem partir uma ligação. Este site faz o mesmo com um identificador de texto em vez de um número: o nome em registo de uma ferramenta ou de um artigo nunca se mexe, e o segmento público é gerado a partir do título próprio desse item em cada língua.
A execução de 9 de agosto de 2026 cobriu 1736 ferramentas e 631 artigos em seis locales. Nada recaiu no identificador por falta de texto utilizável, e exatamente dois slugs de ferramentas e dois de artigos colidiram dentro de um locale e foram desambiguados acrescentando a parte distintiva do identificador — de forma determinista, por isso uma nova execução produz uma saída idêntica byte a byte. A divergência é o número interessante: em francês, espanhol, português e italiano os 1736 slugs de ferramentas diferem todos do identificador, em alemão 1705 deles, e em inglês apenas 397, porque os identificadores eram ingleses à partida.
Derivar o slug do título traduzido resolve ainda um problema em que ninguém pensa até o encontrar: a elisão. Uma ferramenta francesa chamada Calculateur d'IMC não deve tornar-se calculateur-dimc, e uma italiana chamada Calcolatrice dell'IVA não deve tornar-se calcolatrice-delliva. O gerador converte o apóstrofo em fronteira e depois elimina a partícula elidida, pelo que ficam calculateur-imc e calcolatrice-iva. É uma regra própria da língua, sem equivalente inglês, e é o tipo de coisa que uma tabela de tradução escrita à mão falha na entrada número quatrocentos.
Datas, e as outras coisas que expiram dentro de um caminho
Uma data num slug é uma promessa de que se vai arrepender. Não é uma questão de classificação — ninguém mostrou que um ano num caminho ajude ou prejudique — é uma questão de manutenção. Assim que o artigo é atualizado, o caminho diz algo falso, e as duas saídas são más: deixá-lo desatualizado, ou renomear e redirecionar. Os blogues que põem /2019/03/ no caminho têm o mesmo problema um nível acima, e costumam resolvê-lo nunca atualizando nada.
A mesma lógica vale para tudo o que descreve um estado e não um assunto: um número de versão, um preço, uma época, um país para onde envia neste momento, a palavra «novo». Ponha o estado na página e nos dados estruturados, onde mudá-lo não custa nada, e deixe o caminho descrever a coisa. Se a data for mesmo parte da identidade — as regras fiscais de um ano concreto, o calendário de uma época concreta — então pertence ali, porque essa página trata realmente daquele ano e nunca será atualizada para tratar de outro.
| Decisão | Se otimizar a legibilidade | Se otimizar a estabilidade | O que este site faz |
|---|---|---|---|
| Língua do segmento | A língua do leitor | Uma só língua em todo o lado | Seis, derivados do título próprio de cada língua |
| Caracteres acentuados | Mantê-los e aceitar os escapes de percentagem | Retirá-los e aceitar a perda | O alemão mapeia para ae/oe/ue/ss; as outras cinco retiram o diacrítico |
| Separador de palavras | O hífen — a Google recomenda-o explicitamente | O hífen — a mesma resposta, nada a negociar | O hífen, com o apóstrofo tratado como fronteira |
| Comprimento | Tão longo quanto o título precisar | Curto, para nunca ter de encurtar mais tarde | Limitado a 70 caracteres; as palavras vazias caem só acima disso |
| Data no caminho | Útil quando a página é mesmo sobre aquele ano | Nunca — garante uma futura mudança de nome | Sem data; a data de publicação vive na página e no seu esquema |
| Renomear um slug | Sempre que o título melhorar | Nunca, assim que algo lhe aponta | Livremente — o identificador nunca se mexe, só muda o segmento público |
Perguntas frequentes
- Mudar um slug de URL prejudica o posicionamento?
- Custa-lhe as ligações acumuladas se não redirecionar, e custa um pouco mesmo redirecionando. A documentação da Google indica que um redirecionamento permanente serve ao processo de indexação como sinal de que o destino deve ser canónico, por isso um redirecionamento permanente bem posto preserva o sinal; um temporário explicitamente não. O irrecuperável é tudo o que não segue redirecionamentos — um URL impresso, uma citação escrita à mão, uma cópia colada num documento. A resposta honesta é que a mudança de nome em si é barata e a cauda de referências partidas não é: renomeie quando o slug antigo estiver mesmo errado, não quando o novo ficasse um pouco melhor.
- Que comprimento deve ter um slug?
- Não há limite publicado: escolha um e aplique-o. Este site usa 70 caracteres, que seguram com folga um título nas seis línguas sem sair do que um resultado e uma barra de endereço mostram sem truncar num telemóvel. O que importa mais do que o número exato é a ordem das operações quando o ultrapassa: elimine primeiro o subtítulo depois dos dois-pontos, depois as palavras vazias, depois as palavras finais — e nunca corte a meio de uma palavra, porque um slug que acaba num fragmento lê-se como um erro, não como uma página.
- Devo traduzir os meus slugs ou mantê-los em inglês?
- Traduza-os se tiver traduções reais da página. O guia de URL da Google recomenda usar palavras na língua do seu público, transliteradas quando aplicável, e a razão é simples: a um leitor alemão que aterra numa página alemã cujo caminho acaba numa palavra inglesa mostraram-se dois nomes para uma só coisa. O modo de falha a evitar é um caminho traduzido à máquina numa página que de resto é inglesa — isso é pior do que não mexer. Derive o slug do título traduzido que já tem, não de uma tradução à parte do próprio slug.
- Posso usar caracteres acentuados ou não latinos diretamente num slug?
- Tecnicamente sim — o navegador codifica-os por si e o guia da Google limita-se a dizer que os caracteres não ASCII devem ser codificados em percentagem. Na prática, decida onde o URL vai ser lido. Numa barra de endereço descodifica-se de volta à forma acentuada e fica bem. Em texto simples não: um slug alemão de 27 caracteres passa a 37 caracteres de escapes, um cirílico de 15 passa a 85, e um CJK de quatro passa a 36. Para uma língua em escrita latina, transliterar ou retirar o diacrítico compra legibilidade em todo o lado quase de graça. Para uma escrita não latina a troca é realmente mais dura, porque retirar não é opção e os seus leitores nunca verão a forma codificada no próprio navegador.
- O padrão identificador + slug vale o número feio no URL?
- Vale a pena sempre que os títulos mudem e as ligações contem, o que descreve a maioria do conteúdo que vive mais de um ano. O número compra-lhe a capacidade de reescrever a parte legível à vontade, sem redirecionamento nem cadeia, porque a resolução nunca dependeu dela. O custo é um caminho com ar de gerado por máquina. Este site segue a via intermédia: o identificador é uma cadeia legível em vez de um número, não aparece de todo no caminho público, e o slug por língua remapeia-se para ele — assim um título renomeado muda seis slugs públicos e não parte nada por dentro.
Artigos que podem interessar-lhe
Todos os guias →Ferramentas relacionadas
Fontes
- Google Search Central — Keep a simple URL structure — hyphens over underscores, percent-encoding for non-ASCII, words in the audience's language
- Google Search Central — Redirects and Google Search — a permanent redirect is a canonical signal, a temporary one is not
- Google Search Central — HTTP status codes and network errors — "By default, Google's crawlers follow up to 10 redirect hops"
- IETF — RFC 3986, Uniform Resource Identifier (URI): Generic Syntax — percent-encoding and path segments
- WHATWG — URL Standard — percent-encode sets and how browsers render encoded paths
Detetaste um erro neste artigo?