Estrutura de URL
Como estruturar URLs para SEO — anatomia, hífens vs. sublinhados, palavras-chave, sensibilidade a maiúsculas, parâmetros e por que alterar URLs quase nunca ajuda.
Idiomas
1 sinal de evidência nesta página
- Ferramenta relacionada ativaCanonicalization Checker
A estrutura de URL é como as partes de um endereço web — esquema, domínio, caminho, string de consulta, fragmento — são organizadas. Ela importa principalmente para rastreamento, usabilidade e compreensão, não para ranqueamento: palavras-chave em URLs são um sinal de 'peso muito leve' na melhor das hipóteses. Use hífens (o Google trata sublinhados como conectores de palavras, hífens como separadores — o Bing não diferencia), mantenha a consistência de maiúsculas (caminhos são sensíveis a maiúsculas), minimize parâmetros e altere URLs existentes 'muito, muito raramente'.
Evidence for this claim Google recommends simple, descriptive, human-readable URLs, hyphens between words, and minimizing unnecessary parameters. Scope: Current Google URL structure guidance. Confidence: high · Verified: Google Search Central: URL structure best practices Evidence for this claim A URI is composed of standardized scheme, authority, path, query, and fragment components; semantics depend on the scheme and server. Scope: Generic URI syntax, distinct from search-engine recommendations. Confidence: high · Verified: IETF RFC 3986: URI Generic SyntaxTL;DR — Uma URL é o endereço de uma página. Boas URLs são legíveis, em minúsculas, usam hífens entre palavras e descrevem sobre o que é a página. Mas não espere que URLs movam muito seu ranqueamento — elas servem principalmente para rastreamento e para humanos. O maior erro é mudar URLs que você não precisa mudar.
O que é uma URL
Uma URL — Localizador Uniforme de Recursos — é o endereço completo de uma página na web. Ao dividi-la, você obtém algumas partes:
https://www.example.com/blog/url-structure/?ref=newsletter#anatomy
└─┬─┘ └┬┘ └────┬────┘└───────┬──────────┘└──────┬──────┘└──┬───┘
scheme sub domain path query string fragment- Esquema —
https://. Use HTTPS; é a versão segura e o padrão esperado. - Subdomínio —
www.(oublog.,shop., etc.). Opcional. - Domínio —
example.com. O nome do seu site. - Caminho —
/blog/url-structure/. As pastas e o “slug” da página. Esta é a parte que você geralmente controla. - String de consulta —
?ref=newsletter. Parâmetros extras, geralmente para rastreamento ou filtragem. - Fragmento —
#anatomy. Salta para um ponto na página. Os mecanismos de busca geralmente o ignoram.
O que torna uma URL boa
Mantenha simples:
- Use palavras, não números.
/blog/url-structure/é melhor que/p?id=4321. - Use hífens entre palavras.
red-shoes, nãored_shoesouredshoes. - Use minúsculas em tudo.
Pageepagepodem ser tratadas como duas URLs diferentes. - Mantenha razoavelmente curta e legível — curta o suficiente para que um humano possa adivinhar o que há na página.
- Combine com a estrutura do seu site. As pastas devem refletir como seu site é organizado.
O que a maioria das pessoas erra
URLs são um fator de ranqueamento muito pequeno. O Google diz há anos que palavras-chave em URLs “have hardly any effect.” (tradução) «quase não têm efeito». Portanto, não se preocupe em encher URLs de palavras-chave, e — mais importante — não saia renomeando um monte de URLs existentes esperando que isso melhore o ranqueamento. Quase nunca melhora, e mudar URLs traz riscos reais (links quebrados, perda de autoridade se os redirecionamentos forem mal feitos). Se suas URLs já funcionam, deixe-as como estão.
Quer saber hífens versus sublinhados nas próprias palavras do Google, as pegadinhas de sensibilidade a maiúsculas e como parâmetros desperdiçam orçamento de rastreamento? Mude para a aba Avançado.
Evidence for this claim Google recommends simple, descriptive, human-readable URLs, hyphens between words, and minimizing unnecessary parameters. Scope: Current Google URL structure guidance. Confidence: high · Verified: Google Search Central: URL structure best practices Evidence for this claim A URI is composed of standardized scheme, authority, path, query, and fragment components; semantics depend on the scheme and server. Scope: Generic URI syntax, distinct from search-engine recommendations. Confidence: high · Verified: IETF RFC 3986: URI Generic SyntaxTL;DR — A estrutura de URL é principalmente uma questão de rastreamento e compreensão, não uma alavanca de ranqueamento. Palavras-chave em URLs são um sinal de “peso muito leve” que desaparece assim que uma página é indexada. Use hífens (o Google une em sublinhados, separa em hífens). A capitalização do caminho pode identificar URLs distintas dependendo do comportamento do servidor, então capitalização mista pode criar caminhos de rastreamento duplicados. Parâmetros são o verdadeiro risco de eficiência de rastreamento. E mudar URLs existentes ajuda “muito, muito raramente” — então não faça, a menos que estejam genuinamente quebradas.
Anatomia de uma URL
Toda URL se decompõe nas mesmas partes, e cada uma tem suas próprias implicações para SEO:
| Parte | Exemplo | Notas |
|---|---|---|
| Esquema | https:// | Use HTTPS. HTTP vs HTTPS é um sinal de canonicalização. |
| Subdomínio | www. | O Google pode tratar subdomínios mais como sites separados do que subpastas. |
| Domínio | example.com | O nome do host não diferencia maiúsculas de minúsculas. |
| Caminho / slug | /blog/url-structure/ | A parte que você controla; diferencia maiúsculas de minúsculas. |
| String de consulta | ?ref=newsletter | Parâmetros — a maior fonte de URLs duplicadas/de baixo valor. |
| Fragmento | #anatomy | O Google “generally doesn’t support URL fragments” (tradução: «geralmente não oferece suporte a fragmentos de URL») para alterar conteúdo. |
Caracteres reservados devem ser codificados em percentual conforme o padrão; use texto não ASCII no idioma dos seus usuários (transliterado quando ajudar) em vez de IDs sem sentido.
URLs afetam o ranqueamento? Quase nada.
Esta é a pergunta que todos realmente querem responder. A resposta honesta: minimamente.
- Palavras-chave na URL são, segundo o próprio Guia de Início do Google, um fator sobre o qual a documentação afirma: “the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.” (tradução) «As palavras-chave no nome do domínio (ou no caminho da URL), por si sós, quase não têm efeito além de aparecerem nas trilhas de navegação.» John Mueller as chamou de “a very small ranking factor” (tradução) «um fator de ranqueamento muito pequeno» e “a very light weight factor… less so after [the page is] indexed.” (tradução) «um fator de peso muito leve… ainda menos depois que [a página] é indexada.» Então, uma palavra-chave na URL pode ajudar o Google durante a descoberta inicial, antes de ele rastrear o conteúdo — mas, uma vez que a página é indexada, é o conteúdo que fala.
- O que importa mais do que a redação da URL é a profundidade de clique — quantos cliques a partir da
página inicial uma página está. Uma estrutura de diretórios lógica ajuda o Googlebot a estimar a
frequência de rastreamento (uma pasta
/policies/raramente muda;/promotions/muda com frequência), mas isso é sobre rastreamento, não ranqueamento.
Conclusão: não reestruture URLs apenas para injetar palavras-chave. O esforço não vale a pena.
Hífens vs. underscores
Esta é a única regra técnica realmente estabelecida, e é específica do Google.
O Google trata um hífen como separador de palavras e um sublinhado como unificador de
palavras. Então, red_shoes é analisado como o token único redshoes, enquanto
red-shoes é analisado como red e shoes. A justificativa de Gary Illyes: “many things
on the internet have an underscore in them, they can’t easily segment at
underscore.” (tradução) «Muitas coisas na internet contêm um sublinhado, então [o Google] não consegue segmentá-las facilmente nesse caractere.» Matt Cutts disse o mesmo em 2007: “we still join on the
underscore and separate on the dash” (tradução) «Ainda unimos no sublinhado e separamos no hífen». A documentação atual do Google ainda recomenda
hífens.
Há uma peculiaridade que vale conhecer: Mueller disse uma vez em 2016 que a diferença “doesn’t matter” (tradução) «não importa», o que confundiu as coisas — mas a documentação atual ainda diz para usar hífens, e essa é a escolha segura.
O Bing é diferente. Um porta-voz do Bing confirmou: “We do not differentiate between dash and underscore in our URL ranking features.” (tradução) «Não diferenciamos entre hífen e sublinhado em nossos recursos de ranqueamento de URL.» Então, sublinhados não prejudicam você no Bing. Mas, como você está otimizando para ambos, use hífens — é correto para o Google e neutro para o Bing.
Comprimento da URL e o mito da canonicalização
Você vai ouvir “URLs mais curtas ranqueiam melhor.” Isso é uma leitura errada.
O comprimento da URL não tem impacto direto no ranqueamento. O que é verdade é mais restrito: quando o Google está escolhendo uma canônica entre URLs duplicadas ou quase duplicadas, ele pode preferir a mais curta e limpa — especificamente uma URL limpa em vez da mesma URL com parâmetros de rastreamento anexados. Como eu disse na minha pesquisa sobre canonicalização: “This has been misinterpreted over the years by SEOs to say that all of your URLs should be shorter. But that’s not what was meant.” (tradução) «Ao longo dos anos, profissionais de SEO interpretaram isso incorretamente como uma recomendação de que todas as URLs fossem mais curtas. Não era isso que se queria dizer.» A preferência é por uma versão limpa, sem parâmetros, em vez de uma duplicata cheia de parâmetros — não uma lei universal de “o mais curto vence”. O comprimento da URL é apenas um dos cerca de 40 sinais de canonicalização que o Google usa, junto com a preferência por HTTPS, www vs. não-www, barra final e maiúsculas/minúsculas.
Sensibilidade a maiúsculas e minúsculas é um risco real
Caminhos, nomes de arquivo e parâmetros de consulta de URL são sensíveis a maiúsculas e minúsculas; o nome do host não é. Então, example.com/Apple e example.com/apple são duas URLs diferentes (mas
Example.com e example.com são o mesmo host).
O Google geralmente consegue perceber quando duas variações de maiúsculas/minúsculas servem conteúdo idêntico e as
canonicaliza — mas você não deveria fazer esse trabalho. Se ambas as versões estiverem
acessíveis e não forem consolidadas, você terá conteúdo duplicado. E há uma aresta
afiada que a maioria das pessoas perde: robots.txt também é sensível a maiúsculas e minúsculas. Uma entrada Disallow
para /Private/ não bloqueia /private/. Padronize em minúsculas e
você evita tudo isso.
Exatamente quais variações de maiúsculas/minúsculas resolvem, redirecionam ou retornam 404 depende do seu servidor e
configuração do aplicativo — não é uma regra universal. Teste as respostas reais
(curl -I ou um rastreador) em vez de assumir.
Barras finais
Uma barra final importa em todos os lugares, exceto na raiz:
- Domínio raiz:
example.comeexample.com/são tratados de forma idêntica — sem diferença. - Todo o resto:
example.com/pageeexample.com/page/são URLs diferentes. Se ambos estiverem acessíveis e nenhum consolidar para o outro, isso é conteúdo duplicado.
Observe que adicionar uma barra final a um arquivo real (page.html/) não carregará o
arquivo. Como escrevi no meu guia de barra final:
“There’s always a risk with changes, so unless your setup is causing issues I
wouldn’t try to force a change to your URLs.” (tradução) «Sempre há risco com mudanças, então, a menos que sua configuração esteja causando problemas, eu não tentaria forçar uma mudança nas suas URLs.» Escolha um formato, aplique-o com
redirecionamentos e indicações de URL preferencial, e mantenha as ligações internas consistentes. Assim como com maiúsculas e minúsculas, o
comportamento real fora da raiz depende do servidor e da aplicação — verifique o que sua
configuração realmente retorna em vez de presumir.
Parâmetros de URL: o verdadeiro problema de rastreamento
Os parâmetros de consulta são onde a estrutura de URL causa mais dano de SEO em escala. Eu os divido de duas maneiras no meu guia de parâmetros de URL:
- Parâmetros ativos alteram o conteúdo da página — filtragem, ordenação, paginação, idioma, busca no site.
- Parâmetros passivos não alteram o conteúdo — IDs de afiliados, tags UTM, IDs de sessão.
Ambos causam problemas. Parâmetros passivos em ligações internas criam URLs duplicadas e desperdiçam o orçamento de rastreamento; parâmetros ativos (especialmente filtros facetados) podem gerar combinações de URL quase infinitas — uma armadilha clássica para rastreadores. A própria orientação de comércio eletrônico do Google adverte exatamente sobre isso: conteúdo não encontrado, o mesmo conteúdo rastreado repetidamente e o rastreador pensando que seu site tem páginas infinitas porque uma URL contém um valor em constante mudança, como um carimbo de data/hora.
Como controlá-los:
rel=canonicalé a principal alavanca agora — aponte as variantes para a URL limpa. Para parâmetros de variantes opcionais, o Google recomenda usar “the URL with the query parameter omitted as the canonical URL.” (tradução) «a URL sem o parâmetro de consulta como URL preferencial.»noindexonde uma página de parâmetro realmente não deveria estar no índice.robots.txtpara manter os bots fora de espaços de parâmetros claramente inúteis (mas lembre-se que ele controla o rastreamento, não a indexação).- E, para medição especificamente: use eventos das ferramentas de análise em vez de parâmetros de URL quando puder — a maioria dessas ferramentas pode registrar os dados sem inchar suas URLs.
Uma nota histórica: a antiga ferramenta de Parâmetros de URL do Google no Search Console foi descontinuada e removida em 2022. As tags canônicas são o substituto.
Como é uma URL limpa
Juntando tudo, o formato alvo:
- Palavras descritivas, não IDs numéricos
- Minúsculas
- Hífens entre palavras
- HTTPS
- Sem parâmetros desnecessários
- Reflete a estrutura de diretórios do seu site
- Estável e permanente (URLs que você não precisará alterar)
Você deve mudar suas URLs? Quase nunca.
Este é o aprendizado prático mais importante. John Mueller, perguntado se mudar URLs para SEO ajuda: “Will it help the site? Very, very rarely… Will a change negatively affect the site for a while until it’s reprocessed? Probably.” (tradução) «Isso ajudará o site? Muito, muito raramente… Uma mudança afetará negativamente o site por um tempo até que seja reprocessado? Provavelmente.»
As razões justificadas para alterar URLs são restritas: URLs genuinamente crípticas/ilegíveis
(example.com/p?=123), referências desatualizadas embutidas na URL ou correção de um
problema de encontrabilidade — não uma preferência estética por caminhos mais curtos, mais limpos ou mais
ricos em palavras-chave em URLs que já funcionam. Se um defeito concreto justificar uma
alteração, faça-a como uma migração real, não como uma correção pontual: crie um mapeamento
completo de URL antiga para nova cobrindo todos os caminhos afetados, coloque redirecionamentos
diretos e permanentes (301) em cada um (evite cadeias de redirecionamento por meio de uma URL antiga
intermediária), atualize ligações internas e tags que indicam a URL preferencial para apontar diretamente para as novas
URLs, atualize seus sitemaps XML e use a ferramenta de mudança de endereço
onde ela se aplicar. Em seguida, monitore tanto as URLs antigas quanto as novas depois — estatísticas
de rastreamento, cobertura no Search Console e registros do servidor — em vez de presumir que o
mapa de redirecionamento está completo porque algumas URLs de amostra funcionaram. Um gerenciamento sólido
de redirecionamentos reduz o risco de perder autoridade, mas nem o Google nem ninguém mais
garante um prazo de recuperação ou que o ranqueamento seja mantido inalterado. O aspecto da
permanência importa mais do que nunca agora que os assistentes de IA citam URLs:
links que quebram com a alteração tornam-se citações quebradas.
Onde isso se encaixa
A estrutura de URL se sobrepõe a vários vizinhos nos mundos de estrutura de site e rastreamento: canonicalização (os ~40 sinais que escolhem uma URL representativa), parâmetros de URL (o mergulho profundo em ativos vs passivos), barra final (trailing slash), arquitetura de site e profundidade de rastreamento (onde a profundidade de clique, não a redação da URL, faz o trabalho real de ranqueamento), e redirecionamentos (como mover URLs sem perder autoridade). Cada um é um mergulho profundo próprio.
Resumo de IA
Uma visão condensada da versão Avançada:
- Uma URL tem seis partes: esquema (
https://), subdomínio, domínio, caminho/slug, string de consulta (?key=value) e fragmento (#section). O nome do host não é sensível a maiúsculas/minúsculas; o caminho é. - URLs mal afetam o ranqueamento. Palavras-chave na URL são, segundo o Google, um sinal com “quase nenhum efeito além de aparecer em trilhas de navegação” — “peso muito leve” e que desaparece após a indexação. A profundidade de clique importa mais do que a redação da URL.
- Hífens vs underscores (específico do Google): o Google separa em hífens
e une em underscores, então
red_shoes=redshoes. Use hífens. O Bing não diferencia entre os dois. - O comprimento da URL não é um fator de ranqueamento. A ideia de “mais curto vence” é uma leitura equivocada da canonicalização: o Google pode preferir uma URL limpa à mesma URL com parâmetros — não “mais curto é melhor” universalmente.
- Sensibilidade a maiúsculas/minúsculas é um risco de conteúdo duplicado. Caminhos/nomes de arquivo são
sensíveis a maiúsculas/minúsculas (
/Apple≠/apple); o mesmo vale pararobots.txt. Padronize em minúsculas. - Barra final: idêntica apenas no domínio raiz; em todos os outros lugares
/page≠/page/. - Parâmetros são o problema real de rastreamento — parâmetros passivos (UTM, sessão, afiliado)
e ativos (filtro/ordenação/paginação) criam duplicatas e desperdício de rastreamento.
Controle com
rel=canonical(principal),noindex,robots.txt; a ferramenta de Parâmetros de URL do GSC foi removida em 2022. - Alterar URLs ajuda “muito, muito raramente” (Mueller) — apenas para URLs verdadeiramente quebradas/ crípticas ou um defeito concreto, nunca por preferência estética. Quando justificado, trate como uma migração completa: mapeamento completo de URL antiga para nova, 301s diretos, ligações internas, indicações de URL preferencial e sitemaps atualizados, além do monitoramento de ambas as URLs antigas e novas depois — sem prazo de recuperação garantido.
Documentação oficial
Documentação de fonte primária dos mecanismos de busca.
- Práticas recomendadas de estrutura de URL — hífens em vez de sublinhados, caminhos descritivos, consistência de maiúsculas e minúsculas, parâmetros mínimos, codificação percentual.
- Guia de introdução ao SEO — URLs como trilhas de navegação nos resultados; palavras-chave no caminho da URL “have hardly any effect” (tradução) «quase não têm efeito».
- Canonicalização — seleção da URL representativa; os cenários comuns de URLs duplicadas (HTTP/HTTPS, www, barra final, maiúsculas/minúsculas, parâmetros).
- Projetando uma estrutura de URL para sites de ecommerce — conteúdo perdido, rastreamento duplicado, rastreamento infinito; caminhos descritivos em vez de IDs numéricos; canônicos com parâmetros omitidos.
Bing / Microsoft
- Diretrizes do Webmaster do Bing — mantenha URLs curtas e ricas em palavras-chave; evite variáveis de sessão e docIDs.
- Melhor que canônico — Normalização de URL — a forma preferida do Bing de reduzir variações de parâmetros.
Citações da fonte
Declarações oficiais do Google e do Bing. Cada link faz deep link para a passagem citada quando a página de origem suporta isso.
Hífens vs. sublinhados
- “We recommend using hyphens (-) instead of underscores (_) to separate words.” (tradução) «Recomendamos usar hífens (-) em vez de sublinhados (_) para separar palavras.» — Google Search Central, documentação de estrutura de URL. Ir para a citação
- Gary Illyes (Google), sobre o motivo: o Google recomenda hífens porque “many things on the internet have an underscore in them, they can’t easily segment at underscore.” (tradução) «Muitas coisas na internet contêm um sublinhado; [o Google] não consegue segmentá-las facilmente nesse caractere.» Cobertura
- Matt Cutts (Google), 2007: “We still join on the underscore and separate on the dash.” (tradução) «Ainda unimos no sublinhado e separamos no traço.» Cobertura
- Porta-voz do Bing: “We do not differentiate between dash and underscore in our URL ranking features.” (tradução) «Não diferenciamos entre traço e sublinhado em nossos recursos de ranqueamento de URL.» Cobertura
Palavras-chave em URLs
- Guia de introdução ao SEO do Google: “the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.” (tradução) «As palavras-chave no nome do domínio (ou no caminho da URL), por si sós, quase não têm efeito além de aparecerem nas trilhas de navegação.» Ir para a citação
- John Mueller (Google): palavras-chave em URLs são “a very light weight factor” — e importam ainda menos depois que uma página é indexada. (tradução) «um fator de peso muito leve» Cobertura
- John Mueller (Google): URLs “provide minimal additional signals for search engines.” (tradução) «fornecem sinais adicionais mínimos para os mecanismos de busca.» Cobertura
Comprimento da URL / canonicalização
- Google: ao deduplicar, tende a escolher a URL mais curta e limpa como canônica — não uma regra universal de “mais curta ranqueia melhor”. Cobertura
Sensibilidade a maiúsculas e minúsculas
- John Mueller (Google): o caminho da URL, o nome do arquivo e os parâmetros de consulta são sensíveis a maiúsculas e minúsculas; o nome do host não é — e
robots.txttambém é sensível a maiúsculas e minúsculas, então seja consistente. Cobertura
Alterando URLs
- John Mueller (Google): “Will it help the site? Very, very rarely… Will a change negatively affect the site for a while until it’s reprocessed? Probably.” (tradução) «Vai ajudar o site? Muito, muito raramente… Uma mudança vai afetar negativamente o site por um tempo até ser reprocessada? Provavelmente.» Cobertura
#:~:text= pode não resolver, a documentação ao redor ainda contém a
linguagem citada. Confirme na página ao vivo antes de tratar como definitivo. Lista de verificação de auditoria de URL
Uma passada para capturar os problemas de URL que realmente causam problemas:
- HTTPS em todos os lugares — nenhuma URL HTTP acessível sem redirecionar para HTTPS.
- Um host preferencial — www e não-www consolidados em uma única versão.
- Minúsculas consistentes — sem caminhos com maiúsculas e minúsculas misturadas criando duplicatas; verifique
se as regras de
robots.txtcorrespondem à capitalização realmente usada. - Hífens, não sublinhados ou palavras concatenadas, separando palavras em slugs.
- Barra final decidida e aplicada — um formato em todo o site (exceto domínio raiz), sustentado por redirecionamentos e indicações de URL preferencial.
- Slugs descritivos, não IDs numéricos (
/url-structure/não/p?id=4321). - Parâmetros sob controle — parâmetros de rastreamento passivos (UTM, sessão, afiliado) não estão em ligações internas; parâmetros ativos (filtro/ordenação) têm indicações da versão preferencial apontando para a URL limpa.
- Sem armadilhas para rastreadores — navegação facetada, calendários ou URLs com carimbo de data e hora não estão gerando espaços de URL quase infinitos.
- Fragmentos não são usados para diferenciar conteúdo (o Google os ignora).
- Caracteres reservados/não-ASCII codificados em percentual corretamente.
- Ambas as versões de URL não estão indexadas — verifique no GSC relatórios divididos entre variantes de capitalização, barra ou parâmetro.
- Nenhuma mudança de URL desnecessária planejada — se as URLs funcionam, deixe-as; se um defeito concreto justifica uma mudança, um mapeamento completo de URL antiga para nova, redirecionamentos 301s diretos, ligações internas, indicações de URL preferencial e sitemaps atualizados, além do monitoramento pós-mudança de ambas as URLs antigas e novas estão na fila (não apenas um redirecionamento e um ping de sitemap).
Os modelos mentais
1. URLs são para rastreamento e humanos, não para ranqueamento. Antes de otimizar uma URL, pergunte o que você está realmente tentando melhorar. Palavras-chave na URL são “muito leves.” Legibilidade e eficiência de rastreamento são os reais benefícios — então otimize para esses, não para um suposto aumento de ranqueamento.
2. Consistência supera otimização. O dano das URLs vem da inconsistência — capitalização mista, ambas as versões com barra ativas, a mesma página acessível com e sem parâmetros. Escolha um formato limpo e aplique-o. Um esquema “imperfeito” consistente supera um esquema “ótimo” aplicado de forma desigual.
3. Os quadrantes de URLs duplicadas. A maioria dos problemas de SEO de URL é uma página acessível como muitas URLs: HTTP/HTTPS, www/não-www, barra/sem barra, capitalização e parâmetros. Cada um é uma decisão de canonicalização. Mapeie quais variantes existem, depois consolide com redirecionamentos (para casos difíceis) ou indicações da versão preferencial (para os casos menos rígidos).
4. Parâmetros: ativos vs passivos. Parâmetros passivos (rastreamento) nunca devem mudar o conteúdo e idealmente nunca devem aparecer em um link interno — empurre esses dados para eventos de análise. Parâmetros ativos (filtro/ordenação/ paginação) mudam o conteúdo e precisam de tratamento deliberado da URL preferencial e da indexação para que não se transformem em uma armadilha para rastreadores.
5. A regra de decisão para mudar uma URL. O padrão é não. Só mude uma URL se ela for genuinamente críptica, quebrada ou não encontrável — e nunca para um ganho marginal de palavra-chave. Quando mudar, 301 + sitemap + mudança de endereço, sempre. O “muito, muito raramente” do Mueller é o precedente.
Melhores práticas de URL — folha de referência
| Faça | Não faça | Por quê |
|---|---|---|
Use https:// | Deixe URLs HTTP acessíveis | HTTPS é o padrão esperado e um sinal de canonicalização |
Separe palavras com hífens (red-shoes) | Use sublinhados (red_shoes) ou junte palavras | O Google une com _, separa com -; o Bing não faz distinção, então hífens são seguros para ambos |
| Mantenha tudo em minúsculas | Misture maiúsculas e minúsculas (/Apple e /apple) | Caminhos e robots.txt diferenciam maiúsculas de minúsculas → URLs duplicadas / regras de bloqueio ignoradas |
| Use palavras descritivas | Use IDs numéricos (/p?id=4321) | URLs legíveis ajudam usuários e trilhas de navegação; IDs não ajudam ninguém |
| Escolha um formato de barra final e aplique-o | Deixe /page e /page/ ambos resolverem | São URLs diferentes em todos os lugares, exceto no domínio raiz → duplicatas |
| Minimize parâmetros de consulta | Coloque parâmetros UTM, de sessão ou de afiliados em ligações internas | Parâmetros passivos desperdiçam orçamento de rastreamento e dividem sinais; use eventos das ferramentas de análise |
| Canonicalize parâmetros de variantes para a URL limpa | Dependa da ferramenta removida Parâmetros de URL do GSC | Essa ferramenta foi descontinuada em 2022; rel=canonical é a alavanca agora |
| Mantenha URLs estáveis | Renomeie URLs perseguindo palavras-chave | Mudar URLs ajuda “muito, muito raramente” e arrisca links quebrados/perda de autoridade |
| Reflita a estrutura do site no caminho | Enterre páginas profundamente ou deixe-as órfãs | Estrutura lógica auxilia a estimativa de frequência de rastreamento e a descoberta |
| Codifique em percentual caracteres reservados/não ASCII | Deixe espaços/caracteres reservados crus em URLs | Exigido pelo padrão de URL; evita URLs quebradas/ambíguas |
Ferramentas para auditar a estrutura de URLs
- Verificador de Canonicalização — teste se uma variante de parâmetro, maiúsculas/minúsculas ou formato envia sinais consistentes de canonicalização e indexabilidade.
- Mapeador de Cadeias de Redirecionamento — inspecione cada salto antes que uma URL alcance seu formato preferido de HTTPS, nome do host, caminho e barra.
- Verificador de Redirecionamento — faça verificações rápidas quando um pequeno conjunto de URLs renomeadas ou normalizadas for publicado.
- Um rastreador de site completo — inventarie caminhos, parâmetros, indicações de URL preferencial, códigos de resposta e destinos das ligações internas em escala; agrupe variantes antes de decidir se são duplicatas.
- Registros do servidor e Search Console — confirme quais formas de URL os rastreadores realmente solicitam e quais o Google registra, em vez de julgar a estrutura apenas a partir de um modelo.
As ferramentas de URL podem mostrar inconsistências, mas não podem justificar uma migração por conta própria. Mudar URLs estáveis ainda exige um motivo de negócio, um mapa completo de redirecionamentos e prova de que o benefício esperado supera o risco da transição.
Teste-se: Estrutura de URL
Cinco perguntas rápidas sobre como as URLs são construídas e o que realmente importa para SEO. Escolha uma resposta para cada uma e depois confira.
Recursos que valem seu tempo
Meus artigos relacionados
- Trailing Slash: Usar ou Não Usar? — quando a barra importa (e a exceção do domínio raiz).
- Parâmetros de URL: Um Guia Completo para SEOs — parâmetros ativos vs passivos e como controlá-los.
- O Google Usa ~40 Sinais de Canonicalização — incluindo HTTPS, www, barra, maiúsculas/minúsculas e a preferência por URLs mais curtas explicada.
- Redirecionamentos para SEO: Um Guia Simples (Mas Completo) — movendo URLs sem perder autoridade.
- O Guia do Iniciante para SEO Técnico — onde a estrutura de URL se encaixa no panorama geral.
Minhas palestras
- A Crash Course in Technical SEO (SlideShare, Beer & SEO Meetup) — inclui estrutura de URL.
- Troubleshooting Technical SEO Problems (SlideShare, Raleigh SEO Meetup) — problemas de URL em contexto.
Do setor
- Práticas recomendadas de estrutura de URL (Google Search Central) — a lista de referência sobre o que fazer e evitar.
- Google e Bing (ainda) tratam sublinhados e hífens de forma diferente (Search Engine Land) — a divisão hífen/sublinhado, com a citação do Bing.
- Alterar URLs por motivos de SEO: quando é aceitável? (Search Engine Land) — a orientação de Mueller de “muito, muito raramente”.
- Google diz que palavras em uma URL são um fator de peso muito leve (Search Engine Roundtable).
- Lembrete: Google sobre sensibilidade a maiúsculas e minúsculas em URLs (Search Engine Roundtable).
- Google: escolhemos URLs mais curtas para canonicalização (Search Engine Roundtable) — a fonte da ideia mal interpretada de que “o mais curto vence”.
- Melhor que canônico — normalização de URL (Blog do Webmaster do Bing) — a abordagem de colapso de parâmetros do Bing.
Registro de alterações
Atualizado em 21 de ago. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.
Atualizado em 18 de jul. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.