O que é URL amigável e como estruturar URLs para SEO
Uma URL amigável é um endereço de página curto, legível e composto por palavras que descrevem o conteúdo, como ferraoferrao.com.br/blog/url-amigavel/ em vez de ferraoferrao.com.br/index.php?id=42&cat=3a5e. Ela ajuda pessoas e buscadores a entenderem do que a página trata antes mesmo de abri-la. O ponto central deste guia é que implementar decisões de estrutura de URL é fácil antes de publicar e trabalhoso depois.
O que é uma URL e o que a torna amigável
URL é o endereço único de um recurso na web, e uma URL amigável é aquela cujo caminho usa palavras legíveis em vez de códigos. Toda URL tem partes distintas: o esquema e o domínio (https://ferraoferrao.com.br), o caminho que identifica a página (/blog/url-amigavel/), parâmetros opcionais após o ? (?cor=azul) e um fragmento opcional após o # (#secao-2). O que separa uma URL amigável de uma URL técnica é o caminho: /blog/tenis-de-corrida/ comunica o assunto de imediato, enquanto /p?id=90827 não diz nada a quem lê. A documentação oficial do Google recomenda construir URLs de forma lógica e inteligível para humanos, com palavras legíveis no lugar de números de identificação longos.
Palavras descritivas no lugar de IDs e números
Prefira palavras que descrevam o conteúdo, no idioma do seu público, em vez de IDs numéricos. O Google recomenda explicitamente usar exemplo.com.br/wiki/aviacao em vez de exemplo.com.br/index.php?topic=42&area=3a5ebc944f41, porque a palavra ajuda usuários e buscadores a identificar o conceito da página. Para um site em português, isso significa usar termos em português no caminho. Um artigo sobre tênis de corrida fica melhor em /tenis-de-corrida/ do que em /running-shoes/ ou /produto-90827/. A palavra no slug também é o texto que aparece quando alguém compartilha o link, então ela funciona como uma prévia do conteúdo.
Acentos e caracteres especiais na URL
O Google aceita caracteres não-ASCII na URL desde que estejam codificados por percent-encoding, mas o mais seguro na prática é usar slugs sem acento. A documentação atual do Google mudou de postura em relação a conselhos antigos, hoje ela recomenda usar palavras no idioma do público e, quando houver caracteres fora do ASCII, aplicar percent-encoding (por exemplo, gem%C3%BCse no lugar de gemüse). O Google segue o padrão IETF STD 66, que exige que caracteres reservados sejam codificados. Ainda assim, para um site em português, considere que URLs com acento viram uma sequência de % quando copiadas, o que as deixa mais longas, mais difíceis de copiar e colar e sujeitas a truncamento. A recomendação prática é escrever o slug em ASCII, sem acento e sem ç: /geracao-de-conteudo/, não /geração-de-conteúdo/.
Hífen ou underscore para separar palavras
Use hífen (-) para separar palavras no caminho da URL, não underscore (_). O Google recomenda o hífen porque ele ajuda usuários e buscadores a identificar conceitos separados na URL. O underscore é desaconselhado porque historicamente ele é usado para unir palavras que devem ser lidas como um único termo, como em nomes de funções de programação (format_date). Na prática, /tenis-de-corrida/ é a forma recomendada, enquanto /tenis_de_corrida/ e /tenisdecorrida/ são desaconselhadas, a segunda porque junta tudo e dificulta a leitura. Espaços nunca devem aparecer literalmente no caminho, já que viram %20 ou +.
Maiúsculas, minúsculas e barra final criam URLs diferentes
Para o Google, /Apple e /apple são URLs distintas, assim como /pagina e /pagina/, porque URLs diferenciam maiúsculas de minúsculas e a barra final faz parte do endereço. O Google trata cada variação como uma URL própria e, quando várias mostram o mesmo conteúdo, precisa decidir qual manter, um processo chamado canonicalização. A canonicalização costuma resolver bem esses casos e não divide sinais de ranqueamento entre as versões, mas o Google pode escolher uma URL que você não escolheria, além de desperdiçar recursos rastreando todas as variações. A recomendação é padronizar o caminho sempre em minúsculas e estabelecer desde o início um padrão sobre usar ou não barra final, reforçada por links internos consistentes. Servidores como o Apache às vezes adicionam a barra final via redirecionamento, o que soma centenas de milissegundos de latência a cada visita, mais um motivo para padronizar.
O Google indexa o que vem depois da # ?
Na maioria dos casos, o Google ignora tudo que vem depois do # na URL, porque o fragmento serve para apontar para uma seção da página, não para uma página diferente. Para rastreamento e indexação, ferraoferrao.com.br/guia#introducao e ferraoferrao.com.br/guia#conclusao são a mesma página e só a parte antes do # é usada. Por isso, o Google desaconselha usar fragmentos para trocar o conteúdo exibido, já que ele geralmente não suporta esse método. A exceção é quando há JavaScript alterando o conteúdo com base no fragmento. Se o seu site muda o conteúdo por JavaScript, a orientação oficial é usar a History API, que gera URLs reais e indexáveis, em vez de depender do #.
Quando parâmetros e profundidade atrapalham o rastreamento
Parâmetros em excesso são o maior risco de estrutura de URL, porque criam um número enorme de endereços que apontam para conteúdo igual ou parecido e desperdiçam o rastreamento do Googlebot. O Google descreve três padrões problemáticos:
- filtros que se combinam de forma aditiva (mostrar hotéis na praia, depois na praia e com academia, e assim por diante);
- parâmetros irrelevantes que não mudam o conteúdo (UTM, IDs de sessão, referrer);
- calendários infinitos que geram links para datas sem fim.
A recomendação é usar o mínimo de parâmetros possível, remover os que não alteram o conteúdo e, quando necessário, bloquear esses endereços no robots.txt. Já a profundidade de diretórios pesa menos do que se imagina. O Google segue links independentemente de quantos níveis a página está do início, então a estrutura em pastas serve para organizar o site de forma lógica para humanos e ajudar o Google a aprender com que frequência cada seção muda.
Mudar a estrutura de URL é uma mudança de site
Alterar a estrutura de URLs que já estão no ar não é um ajuste pontual e trivial, e sim um evento que o Google classifica formalmente como uma mudança de site, mesmo que você só remova a barra final dos endereços. Para o buscador, trocar um único slug, ou até só remover a barra final dos endereços cai na mesma categoria de reconstruir o site inteiro em um domínio novo e exige o mesmo cuidado. O motivo é que o índice do Google guarda dados por página, então, ao mudar o endereço de uma página, os dados dela precisam ser transferidos para a nova URL, ou se perdem. Caso essa mudança seja necessária, há um roteiro seguro em quatro passos.
- Pesquisar as opções e os efeitos, considerando o momento certo, porque a mudança tem impacto em ranqueamento;
- Criar uma lista das URLs antigas e novas para acompanhar depois;
- Iniciar a migração, aplicando redirecionamento
301de cada URL antiga para a nova e atualizando todas as menções internas (links, formulários, dados estruturados, sitemaps e o arquivorobots.txt); - Monitorar pelo relatório do Google Search Console.
As páginas mais importantes mudam rápido e o resto é reprocessado aos poucos, num processo que pode levar de semanas a meses, e os redirecionamentos devem permanecer no ar por pelo menos um ano. É por isso que vale desenhar a estrutura com calma antes de publicar.
Perguntas frequentes sobre URLs amigáveis
Posso usar acento na URL?
O Google aceita acentos e caracteres não-ASCII desde que estejam codificados por percent-encoding, mas o recomendável é evitar. Slugs com acento viram sequências de % quando copiados, ficam mais longos e mais difíceis de compartilhar. Para um site em português, o mais seguro é escrever o slug em ASCII, sem acento nem ç, como /pao-de-queijo/ em vez de /pão-de-queijo/.
URL com ou sem barra no final?
Tanto faz qual você escolher, desde que seja consistente. Tecnicamente, /pagina e /pagina/ são URLs diferentes para o Google, mas a canonicalização costuma tratá-las como a mesma página sem dividir sinais de ranqueamento. O importante é padronizar uma das formas em todo o site e nos links internos, para o Google e os usuários sempre chegarem à mesma versão.
Underscore atrapalha o SEO?
O Google recomenda hífen (-) em vez de underscore (_) para separar palavras na URL. O underscore é desaconselhado porque costuma ser usado para unir palavras em um único conceito, como em format_date, o que dificulta a identificação de palavras separadas. O efeito prático é pequeno, mas o hífen é a escolha oficialmente recomendada.
Mudar a URL faz perder posição no Google?
Pode causar oscilação temporária, porque o Google trata a mudança de URL como uma mudança de site e precisa reprocessar as páginas. Se a migração for feita com redirecionamento 301 de cada URL antiga para a nova, atualização das menções internas e monitoramento no Search Console, os sinais são transferidos e nada de PageRank se perde. A estabilização pode levar vários meses.
URL curta ranqueia melhor?
Não existe bônus de ranqueamento por URL curta. O que importa é a URL ser legível, descritiva e consistente, sem parâmetros desnecessários. Uma URL mais curta tende a ser esses três, então costuma ser melhor por consequência, não por ser curta em si. A profundidade de diretórios, por sua vez, não penaliza o ranqueamento.
URL amigável é fator de ranqueamento?
A estrutura de URL tem peso pequeno no ranqueamento. O maior benefício de uma URL amigável é para usuários (legibilidade, confiança e facilidade de compartilhar) e para a eficiência de rastreamento, evitando que o Googlebot desperdice recursos com variações duplicadas. Veja URLs amigáveis como boa prática de higiene técnica, não como alavanca de posição.
Higiene de URL na prática
Uma URL amigável reúne poucas decisões simples: palavras descritivas no idioma do público, minúsculas, hífen entre palavras, slug em ASCII, o mínimo de parâmetros e uma escolha consistente sobre a barra final. Todas são fáceis de aplicar antes de publicar e trabalhosas de corrigir depois, quando qualquer troca exige reprocessamento do site. Se você está definindo a estrutura agora, cruze essas escolhas com dois temas que se conectam diretamente: a canonicalização, que decide qual variação de URL o Google mantém, e o HTTPS, que também é uma variação de endereço que precisa ser consolidada.