Um detalhe aparentemente pequeno de codificação de caracteres acabou virando assunto sério no universo do SEO técnico. John Mueller, Search Advocate do Google, afirmou em um post no Bluesky nesta segunda-feira que URLs com colchetes brutos (“[” e “]”) e suas versões codificadas em porcentagem (%5B e %5D) são, para o Google, duas URLs diferentes. Ele chegou a admitir que “provavelmente deu uma resposta errada sobre isso no passado” para algumas pessoas, já que ele mesmo imaginava que as duas formas fossem equivalentes.
Segundo Mueller, o Google rastreia as duas versões normalmente. Se o buscador perceber que o conteúdo é idêntico nos dois casos, ele elimina a duplicidade e escolhe uma única versão para exibir. Por isso, a recomendação é simples: escolha um único formato e use-o de forma consistente em todos os links internos, tags canônicas, sitemaps e dados estruturados. A mesma lógica de duplicidade, segundo ele, também vale para espaços, sinais de mais e o famoso “%20”.
Por que colchetes codificados viram outra URL aos olhos do Google
A explicação de Mueller tem origem técnica: ele recorreu à RFC 3986, o padrão da internet para sintaxe de URIs, que coloca colchetes e sinais de mais no conjunto de caracteres reservados. De acordo com a Seção 2.2 dessa norma, uma URI que troca um caractere reservado pela sua versão codificada em porcentagem “não é equivalente” ao original.
A discussão surgiu a partir de uma pergunta de Vanessa Fox, ex-funcionária do Google e responsável pelo desenvolvimento do Webmaster Central da empresa. Ela questionou, em uma resposta no Bluesky (depois de levantar a dúvida nos comentários do primeiro episódio do podcast Non-Canonical Cabinet), se o Google tratava a forma codificada de uma URL como uma URL diferente. Como exemplo, ela usou ?filter[]=123 e ?filter%5B%5D=123 — uma versão aparecendo em links, outra sendo usada na identificação da versão canônica. Ao rodar um teste em JavaScript comparando as duas URLs, o resultado retornado foi “false”, ou seja, diferentes.
Mueller aproveitou para destacar outro ponto curioso: o uso de colchetes brutos em uma query string também é, tecnicamente, inválido segundo a RFC 3986. Isso porque a norma restringe o uso de colchetes ao hostname, especificamente para delimitar endereços IPv6 brutos. Ele ainda esclareceu que a caixa das letras na codificação não faz diferença — ou seja, “%5B” e “%5b” são equivalentes, seguindo as regras da RFC 3986 para caracteres hexadecimais.
O que o Google faz quando encontra as duas versões
Mueller detalhou o comportamento do Google quando um servidor entrega o mesmo conteúdo tanto para a URL com colchetes brutos quanto para a versão codificada:
Dito isso, *talvez* seu servidor torne essas URLs “soft-equivalentes” ao servir o mesmo conteúdo. Nós rastrearíamos as duas versões; se percebermos o mesmo conteúdo (talvez até no nível de checksum), nós as deduplicaríamos e escolheríamos uma.
Além disso, ele explicou que um navegador costuma codificar os colchetes antes de enviar a URL digitada pelo usuário na barra de endereço. No entanto, quando a URL com colchetes é solicitada via JavaScript (ou outro código), os colchetes podem ser enviados exatamente como estão, sem codificação. Por isso, sua recomendação é direta: sempre codifique os colchetes quando precisar usá-los em uma URL — “sempre codifique, nunca mostre [ ]”.
A documentação do Google já falava sobre isso
Na prática, essa orientação não é novidade: a documentação do Google sobre estrutura de URL já pede a codificação de caracteres como colchetes. O texto afirma que a Google Search segue o padrão definido pela IETF STD 66 (que contém justamente a RFC 3986) e que “caracteres definidos pela norma como reservados devem ser codificados em porcentagem”.
Essa questão havia sido tratada originalmente no primeiro episódio do Non-Canonical Cabinet, que abordava emojis e caracteres não ingleses em URLs — casos em que os navegadores costumam codificar automaticamente o caminho da URL. Os colchetes, porém, representam um caso à parte, já que o padrão os reserva como delimitadores, não como caracteres comuns de conteúdo.
Sites que já usam colchetes brutos: dá para continuar assim?
Vanessa Fox comentou ainda que estava pensando em um site específico que usa a notação de colchetes inválida (ou seja, sem codificação) em toda a sua estrutura. Apesar disso, o site parece indexar normalmente, e a decisão da equipe responsável foi deixar como está, já que converter tudo para o formato válido daria trabalho demais.
Mueller respondeu que não esperaria problemas vindos dessa estrutura, mas fez uma ressalva: “não montaria um site novo assim”. Ele acrescentou que, nesse cenário, prestaria atenção redobrada a todos os links internos — incluindo metadados ligados a rel=canonical e dados estruturados — para garantir que tudo seguisse um padrão uniforme. Mueller também mencionou que, com base em problemas que o próprio Google enfrentou há mais de dez anos com o funcionamento desses caracteres, outros rastreadores, indexadores ou programas de busca podem não ser “tão exatos nessa lógica” ao processá-los.
Por que isso importa para quem cuida de SEO
O recado prático de Mueller é claro: quando existem múltiplas versões de uma mesma URL com conteúdo idêntico, o Google decide sozinho qual delas vai preservar como principal. Se todas as suas URLs seguirem o mesmo padrão — seja bruto, seja codificado —, a chance de o Google escolher a versão que você preferia é maior. A solução mais segura, segundo a própria documentação do Google, é codificar os colchetes na URL. Mueller espera que um site já existente, construído com colchetes brutos, continue funcionando sem sobressaltos; ainda assim, a tarefa de quem administra esses sites é garantir que links internos e metadados apontem sempre para a mesma versão da URL.
O que fazer a partir de agora
Mueller sugeriu checar como os rastreadores e sistemas de busca que realmente importam para o seu site lidam com URLs com colchetes. Ele não citou nomes específicos de crawlers ou fetchers que poderiam ter dificuldades, mas reforçou que alguns deles podem não seguir a mesma exatidão do Google ao processar esse tipo de URL. Até o dia 20 de outubro, o Google ainda não havia publicado o segundo episódio da série em vídeo “Non-Canonical Cabinet”, que deve tratar de robots.txt.
Com informações de searchenginejournal.com.
