Estrutura de URL: boas práticas do Google para rastreamento e leitura

O Google atualizou em 21 de outubro de 2026 a documentação do Google Search sobre estrutura de URL. A página separa os requisitos técnicos de rastreamento das recomendações de legibilidade.

Sem os 3 requisitos, o rastreamento fica ineficiente

URLs fora dos requisitos provavelmente levam a um rastreamento ineficiente. Nas palavras da página, isso inclui taxas de rastreamento extremamente altas ou nenhum rastreamento.

A primeira parte da documentação é normativa. Três pontos definem se a URL atende ao Google Search:

• Seguir o IETF STD 66. O Google Search suporta as URLs definidas por esse padrão. Os caracteres classificados como reservados precisam estar em percent encoding.
• Não usar fragmentos para trocar conteúdo. O Google Search, de modo geral, não suporta fragmentos de URL. O exemplo dado é https://example.com/#/potatoes. Se o site usa JavaScript para mudar o conteúdo, a orientação é usar a History API.
• Usar uma codificação comum para parâmetros. O sinal de igual separa chave e valor e o ampersand adiciona novos parâmetros. Para listar vários valores de uma mesma chave, vale qualquer caractere que não conflite com o IETF STD 66 — a vírgula é o exemplo citado.

O formato recomendado aparece assim: https://example.com/category?category=dresses&sort=low-to-high&sid=789. O desaconselhado usa dois-pontos e colchetes (?[category:dresses][sort:price-low-to-high][sid=789]) ou vírgulas simples e duplas para separar chaves e parâmetros.

Boas práticas: palavras descritivas no idioma do público

O Google recomenda aplicar as boas práticas quando possível, organizando o conteúdo para que as URLs sejam lógicas e inteligíveis para humanos.

• URLs descritivas. Prefira palavras legíveis a números de identificação longos. A documentação compara https://example.com/wiki/Aviation com https://example.com/index.php?topic=42&area=3a5ebc944f41daa6f849f730f1.
• O idioma do público. Use palavras no idioma de quem busca — e, quando for o caso, transliteradas. Se o público pesquisa em alemão, palavras em alemão; se em japonês, palavras em japonês.
• Percent encoding quando necessário. Nos atributos href dos links internos, caracteres ASCII não reservados podem ficar sem codificação. Já os caracteres fora do ASCII devem ser codificados.

Hífen no lugar de sublinhado e menos parâmetros

Hífen em vez de sublinhado, caixa padronizada e o mínimo de parâmetros completam as recomendações de forma.

• Hífens entre palavras. O Google recomenda hífen em vez de sublinhado. O argumento é histórico: sublinhados costumam indicar conceitos que ficam juntos, como nomes de funções em linguagens de programação (format_date). O hífen sinaliza a fronteira entre palavras.
• O mínimo de parâmetros. Sempre que possível, corte da URL os parâmetros que não mudam o conteúdo.
• Atenção a maiúsculas e minúsculas. O tratamento de URLs é sensível a caixa, como em qualquer cliente HTTP que siga o IETF STD 66: /APPLE e /apple são endereços distintos, com conteúdo próprio. Se o servidor trata os dois como iguais, a recomendação é converter todo o texto para a mesma caixa, para facilitar a identificação de que apontam para a mesma página.

Sites multi-regionais ganham estrutura própria

Para sites multi-regionais, vale adotar uma estrutura que facilite o geotargeting. As opções são domínio de país ou subdiretório: https://example.de ou https://example.com/de/ em um gTLD.

O detalhamento de versões por idioma está em hreflang: como indicar versões de idioma e região.

Filtros e calendários multiplicam endereços

URLs muito complexas, sobretudo com múltiplos parâmetros, criam um número desnecessariamente alto de endereços para conteúdo idêntico ou similar. O efeito prático: o Googlebot pode consumir muito mais banda do que o necessário, ou o Google Search pode não conseguir indexar todo o conteúdo do site.

A página lista 4 origens frequentes desse excesso:

1. Filtros aditivos. Quando os filtros de uma listagem se combinam (hotéis na praia e com academia, por exemplo), o número de visões dos mesmos dados explode. Criar muitas listas ligeiramente diferentes é redundante, já que o Googlebot precisa apenas de algumas listas de onde consiga chegar à página de cada item.
2. Parâmetros irrelevantes. Parâmetros de referral, de ordenação de compras e de sessão incham a contagem de URLs. A orientação é evitar IDs de sessão nas URLs e considerar o uso de cookies.
3. Calendários dinâmicos. Um calendário gerado sem limites de data inicial e final cria links para datas futuras e passadas. Para espaços infinitos desse tipo, a recomendação é adicionar nofollow aos links de páginas futuras geradas dinamicamente.
4. Links relativos quebrados. Um link pai-relativo (../../category/stuff) colocado na página errada pode criar espaços infinitos se o servidor não responder com o código HTTP correto para páginas inexistentes; por exemplo, pode gerar endereços falsos. A correção indicada é usar URLs raiz-relativas nos links.

Bloqueio no robots.txt contém o excesso de URLs

Se o Google Search já rastreia essas URLs problemáticas, a documentação recomenda bloquear o acesso do Googlebot com um arquivo robots.txt. O alvo típico são URLs dinâmicas, como as que geram resultados de busca, e as que criam espaços infinitos, como calendários e funções de ordenação e filtro.

O passo a passo está em como criar um robots.txt. Para navegação facetada, a página remete ao guia específico de gerenciamento de rastreamento dessas URLs.

Em mudanças de endereço, o roteiro está em como migrar um site com mudança de URL sem perder tráfego.