Com ou sem www: como definir a versão única do site

Não existe versão melhor para o Google: www.exemplo.com.br e exemplo.com.br funcionam igualmente bem no ranqueamento. O que prejudica é deixar as duas respondendo com status 200 ao mesmo tempo, junto com as variações de http, https e barra final. Cada combinação é, tecnicamente, uma URL diferente, e o buscador precisa escolher qual delas representa a página.

Este artigo trata da parte prática: como escolher a versão, como forçá-la com redirecionamento 301 e canonical no servidor e na página, e como testar, uma por uma, as variações que costumam escapar. A discussão conceitual sobre conteúdo duplicado fica de fora; aqui o foco é a configuração e a verificação.

Por que www, http e barra final geram URLs diferentes

Para o rastreador, uma URL é uma cadeia de caracteres completa: protocolo, host, caminho e parâmetros. Mudar qualquer parte gera outro endereço. A página https://www.exemplo.com.br/blog/ e a página https://exemplo.com.br/blog são, em princípio, duas URLs distintas, e o servidor pode responder a ambas com o mesmo HTML.

Um site com configuração padrão costuma responder em até oito combinações da home: http ou https, com ou sem www, com ou sem barra no final. Em páginas internas a conta cresce, porque entram também maiúsculas e minúsculas no caminho, index.html e parâmetros de rastreamento. O Google agrupa URLs muito parecidas e escolhe uma como canônica, mas essa escolha é um palpite dele, não uma decisão sua. Quando o palpite muda, a URL que aparece nos resultados muda junto, e o histórico de sinais pode ficar dividido entre endereços.

A solução tem duas camadas que se complementam. O redirecionamento 301 é a instrução forte: quem pedir a versão errada nunca recebe conteúdo, só é enviado à versão certa. O canonical é a instrução de apoio: dentro do HTML de cada página, declara qual endereço você considera o principal. Usar só a segunda é frágil, porque o canonical é tratado como uma dica, e não como uma ordem.

Como escolher entre www e sem www

Do ponto de vista de SEO, a escolha é neutra. Não há documentação do Google indicando preferência por um formato. O que importa é escolher um e manter para sempre. Os critérios práticos são outros, e vale pesá-los antes de decidir.

O mais relevante é o DNS. O domínio raiz, sem www, exige um registro A ou AAAA (ou um recurso equivalente de apontamento no apex), porque a especificação do DNS não permite um registro CNAME convivendo com outros registros na raiz. O subdomínio www aceita CNAME normalmente. Isso importa quando o site está atrás de um CDN ou de uma plataforma que pede CNAME: com www, a troca de infraestrutura é mais simples, e você não depende de recursos específicos do provedor de DNS.

• Com www: facilita CNAME para CDN e plataformas, isola cookies do site principal de outros subdomínios e dá mais flexibilidade de infraestrutura. É a escolha comum em sites grandes, com vários subdomínios.
• Sem www: endereço mais curto, bom para divulgação impressa e marca. Funciona bem quando o provedor de DNS oferece apontamento na raiz (muitas vezes chamado de CNAME flattening ou ALIAS).
• Site novo: escolha pelo que a hospedagem e o DNS suportam com menos atrito e registre a decisão no material do projeto.
• Site antigo: mantenha a versão que já tem mais links externos e mais histórico, exceto se houver motivo técnico forte. Mudar de uma para outra exige migração completa de redirecionamentos.

Forçando uma única versão com 301

A regra de ouro é redirecionar em um único salto. Se alguém pede http://exemplo.com.br/pagina, o ideal é receber um 301 direto para https://www.exemplo.com.br/pagina, e não um 301 para https, depois outro para www, depois outro para a barra final. Cadeias desperdiçam rastreamento e deixam a resposta mais lenta. Em termos de configuração, isso significa uma regra que calcula o destino final completo, em vez de várias regras empilhadas.

O exemplo abaixo, em Apache com mod_rewrite no arquivo .htaccess, leva qualquer requisição que não esteja em https ou que não use o host www para a versão definitiva. A ideia é ilustrativa: adapte ao seu ambiente e teste em um ambiente de homologação antes de publicar.

RewriteEngine On RewriteCond %{HTTPS} off [OR] RewriteCond %{HTTP_HOST} !^www\.exemplo\.com\.br$ [NC] RewriteRule ^(.*)$ https://www.exemplo.com.br/$1 [R=301,L]

Em Nginx, o padrão é manter um bloco server só para redirecionar as variações e outro bloco para servir o site. O bloco de redirecionamento escuta nas portas 80 e 443 para os hosts indesejados e responde com return 301 https://www.exemplo.com.br$request_uri. Usar a variável request_uri preserva o caminho e os parâmetros, evitando o erro comum de mandar todo mundo para a home.

Atenção ao certificado. Para redirecionar https://exemplo.com.br para a versão com www, o servidor precisa apresentar um certificado válido também para o host que está sendo redirecionado. Sem isso, o navegador mostra um aviso antes de chegar ao 301, e o redirecionamento nunca é visto. Emita o certificado cobrindo os dois hosts, com e sem www.

A barra final: regra simples, erro frequente

Em teoria, /blog e /blog/ podem ser recursos diferentes. Na prática, a maioria dos sites entrega o mesmo conteúdo nos dois formatos, e é aí que nasce a duplicidade. A convenção antiga diz que a barra final indica um diretório e a ausência indica um arquivo, mas frameworks modernos e gerenciadores de conteúdo tornaram essa distinção irrelevante. Escolha um padrão e aplique em todo o site.

O Google não prefere um formato ao outro. A diferença aparece no tratamento da raiz: para a home, https://www.exemplo.com.br e https://www.exemplo.com.br/ são equivalentes, porque o navegador sempre envia a barra na requisição. Só nos caminhos internos a escolha faz diferença.

O erro mais frequente é aplicar a regra da barra de forma cega. Arquivos com extensão, como .css, .js, .jpg e .pdf, não devem receber barra. Endpoints de API e URLs com parâmetros também podem quebrar. A regra deve excluir o que tem extensão de arquivo e o que é gerado por scripts. Outro erro clássico é criar um laço: o servidor remove a barra, e o aplicativo, como o WordPress com permalinks configurados para terminar em barra, a adiciona de volta. O navegador reclama de redirecionamentos em excesso, e o rastreador desiste. Se o aplicativo já impõe um padrão, não contradiga esse padrão no servidor; alinhe os dois.

Para quem usa WordPress, o próprio núcleo já redireciona para a versão definida na estrutura de links permanentes e no endereço do site. Vale conferir em Configurações, Geral, se o endereço do WordPress e o endereço do site usam exatamente o host escolhido, com ou sem www. Uma divergência ali produz redirecionamentos estranhos que nenhuma regra no servidor resolve sozinha.

Canonical, sitemap e links internos alinhados à versão escolhida

O 301 resolve a entrada pelo servidor, mas o restante do site também precisa concordar. Cada página deve trazer uma tag link rel canonical apontando para a URL absoluta definitiva, com protocolo, host e barra final no padrão escolhido. Canonical relativo é arriscado, porque depende do host em que a página foi carregada e pode replicar a variação que você tenta eliminar.

O sitemap XML deve listar apenas URLs na versão final. Se ele mistura http e https, ou www e sem www, você está entregando ao buscador um mapa que contradiz os redirecionamentos. O rastreador segue o sitemap, recebe 301 e perde tempo. Em sites grandes, isso consome orçamento de rastreamento à toa.

Os links internos também contam. Menus, rodapés, breadcrumbs e links dentro de artigos devem apontar diretamente para a URL final. Um link que depende do 301 funciona, mas adiciona um salto desnecessário em cada clique e em cada rastreamento. Ao migrar de versão, pesquise e substitua em massa os links absolutos gravados no banco de dados do gerenciador de conteúdo; essa é a parte que mais costuma ser esquecida.

Por fim, hreflang, dados estruturados e tags Open Graph também carregam URLs absolutas. Se elas apontam para a versão antiga, você mantém sinais contraditórios espalhados pelo HTML. Uma varredura do código-fonte procurando o host indesejado resolve a maioria desses casos em poucos minutos.

Como verificar todas as variações, uma por uma

Configurar não basta; é preciso testar. O método mais direto é pedir ao servidor, pela linha de comando, os cabeçalhos de cada variação da home e de uma página interna. Com o curl, o comando curl -I -L --max-redirs 5 seguido da URL mostra cada salto, o código de status e o destino. O resultado esperado é sempre o mesmo: no máximo um 301 e uma resposta final 200 na versão escolhida.

Monte uma pequena tabela de testes antes de publicar qualquer mudança e repita depois. Ela deve cobrir, no mínimo, as combinações a seguir, tanto para a home quanto para uma página interna e para um arquivo com extensão.

• http com www e http sem www: devem levar, em um salto, à versão final em https.
• https com o host indesejado: um único 301 para o host escolhido, sem aviso de certificado.
• Com e sem barra final em uma página interna: uma delas responde 200 e a outra faz 301 para ela.
• Caminho com letras maiúsculas e index.html ou index.php: decida se redireciona ou se devolve 404, e registre a regra.
• URL com parâmetros de rastreamento: o canonical da página deve apontar para a versão sem eles.
• Arquivos como imagens, CSS e PDF: não podem ganhar barra e não devem entrar em laço.

Verificação no Google e o que esperar depois

No Search Console, a ferramenta de inspeção de URL mostra a URL canônica declarada pelo usuário e a URL canônica selecionada pelo Google. Inspecione a home e algumas páginas em cada variação. Se a selecionada for diferente da declarada, algo ainda sinaliza a versão errada: um link interno, uma entrada no sitemap, um redirecionamento que não dispara em certas condições ou um conteúdo realmente diferente entre as versões.

Se o seu site tem propriedade de domínio no Search Console, os dados de todas as variações aparecem juntos, o que ajuda a acompanhar a transição. Com propriedade de prefixo de URL, cada combinação de protocolo e host é uma propriedade separada, então vale cadastrar a versão final e acompanhar a antiga até que ela pare de receber impressões. No relatório de páginas, procure por status como página alternativa com tag canônica adequada e duplicada sem canônica selecionada pelo usuário; eles mostram onde ainda há divergência.

Não espere mudança instantânea. O Google precisa rastrear de novo as URLs antigas, enxergar o 301 e consolidar os sinais. Em sites pequenos isso costuma levar dias; em sites grandes, semanas. Mantenha os redirecionamentos por tempo indeterminado, já que links externos antigos continuam apontando para a versão antiga e ainda entregam valor. Remover a regra depois de alguns meses devolve o problema sem aviso.

Por fim, registre a decisão. Versões de host, protocolo e barra final mudam quando alguém troca de hospedagem, liga um CDN ou instala um plugin de redirecionamento que briga com as regras existentes. Repetir a tabela de testes depois de qualquer mudança de infraestrutura é o que separa um site consistente de um que volta a duplicar URLs sem ninguém perceber.