WWW vs. Não-WWW

TL;DR — www.example.com e example.com são nomes de host distintos, comumente configurados para servir o mesmo site. Nenhum dos formatos tem vantagem inerente de SEO, então nenhum é “melhor” para SEO. A única tarefa real é escolher um, redirecionar o outro para ele e ser consistente em todos os lugares. Qual você escolhe geralmente depende de como sua hospedagem e DNS estão configurados, não de SEO.

O que www e não-www realmente são

O www em um endereço web é um subdomínio — o mesmo tipo de coisa que blog.example.com ou shop.example.com. É apenas uma convenção muito antiga que passou a significar “este é o site.” A versão sem ele — example.com — é chamada de domínio raiz, domínio apex ou domínio raiz. Nomes diferentes, mesma coisa.

Ambos geralmente apontam para exatamente as mesmas páginas. Então a pergunta “www ou não?” não é realmente sobre qual é um site melhor — é sobre qual você quer que os mecanismos de busca e navegadores tratem como o endereço.

Isso afeta seu ranqueamento?

Não. Esta é uma das questões mais resolvidas em todo o SEO. O Google disse a mesma coisa por duas décadas: não tem preferência entre www e não-www, e mudar de um para o outro — feito corretamente — não move seu ranqueamento.

Então não perca o sono sobre qual é “mais amigável para SEO.” Nenhum é. O que pode te prejudicar é fazer isso de forma descuidada: deixar ambas as versões carregarem sem escolher um vencedor, então a mesma página existe em dois endereços e os mecanismos de busca têm que adivinhar qual mostrar.

Como fazer certo

1. Escolha um — www ou não-www. Qualquer um serve.
2. Redirecione o outro para ele com um redirecionamento permanente (301), para que qualquer pessoa que visite o errado caia no certo.
3. Aponte tudo para sua escolha — seus links internos, seu sitemap e quaisquer tags canônicas devem usar a mesma versão.

É isso. Costumava haver uma configuração no Google Search Console onde você dizia ao Google sua preferência diretamente, mas o Google a removeu — vou cobrir o que a substituiu na versão Avançada.

O que a maioria das pessoas erra

As pessoas tratam isso como uma decisão de SEO quando na verdade é uma decisão de encanamento. A razão pela qual tantos sites acabam em www não tem nada a ver com ranqueamento e tudo a ver com como os nomes de domínio (DNS) funcionam nos bastidores — algumas configurações literalmente não podem apontar o domínio raiz para onde precisam sem etapas extras. Quer a mecânica de DNS, a pegadinha do certificado que morde as pessoas no meio da troca, e por que o antigo conselho de “domínio sem cookies” está morto? Mude para a aba Avançado.

TL;DR — www é um subdomínio; não-www é o domínio apex/raiz. O Google tem dito que não há diferença de ranqueamento desde 2005, reafirmado por Mueller em março de 2024 (“when the canonical URL switches, it just switches” (tradução) «quando a URL preferencial muda, ela simplesmente muda»). A configuração de Domínio Preferido do GSC foi removida em 18 de junho de 2019 — o substituto não é um botão, mas um conjunto de sinais concordantes: rel=canonical, inclusão no sitemap apenas da versão escolhida, e um redirecionamento permanente da outra. Os sinais de preferência podem discordar, então consistência entre todos eles importa mais do que qualquer configuração única já importou. A razão real pela qual os sites padrão usam www é DNS — um CNAME não pode ficar no apex da zona, então domínios raiz precisam de A/AAAA ou ALIAS/ANAME/achatamento de CNAME. Cuidado com a armadilha de TLS/HSTS na versão da qual você redireciona; lembre-se de que cookies restritos ao host não atravessam nomes de host a menos que você defina Domain para o apex, e abandone o obsoleto argumento de domínio sem cookies.

www é um subdomínio; não-www é o apex

Comece pelo ponto conceitual, porque tudo o que vem depois depende dele: www é um subdomínio, estruturalmente idêntico a blog. ou shop.. example.com é o domínio apex (também “bare” ou “root”) — o apex da zona, onde ficam os registros SOA e NS do domínio. Essa distinção parece pedante até você chegar ao DNS, onde é a história toda.

Como www é um subdomínio, é tentador recorrer a tudo o que o Google já disse sobre subdomínios para responder à pergunta sobre ranqueamento — mas essa é a evidência errada para essa tarefa. A frase frequentemente citada de Mueller de que o Google trata subdomínios e subdiretórios “da mesma forma” algoritmicamente responde a uma pergunta diferente: onde organizar conteúdo genuinamente diferente, como um blog em blog.example.com versus /blog/. www versus não-www não é esse tipo de escolha — é conteúdo idêntico acessível em dois hostnames, o que é uma questão de canonicalização, não de arquitetura da informação. A evidência direta e específica de www para “nenhuma diferença de ranqueamento” vem a seguir.

www vs não-www afeta o ranqueamento? Não.

Esta é a pergunta que todos realmente querem responder, e a resposta está estável há mais tempo do que quase qualquer coisa em SEO. O post original do Google de 2005 sobre o assunto já o enquadrava como uma questão de URL duplicada/consolidação, não de ranqueamento. Quase vinte anos depois, em março de 2024, John Mueller respondeu a um proprietário de site cuja migração para a Cloudflare havia alterado silenciosamente a URL preferencial de www para não-www: “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (tradução) «A mudança não prejudicará a visibilidade, os ranqueamentos nem a indexação na pesquisa: se a URL preferencial trocar, apenas ocorrerá a troca. Talvez haja uma breve oscilação, mas a situação se normaliza rapidamente.»

A única ressalva que ele acrescenta é a distinção que sustenta tudo: “A única vez que causaria mudanças maiores é se você mudar os canônicos para um domínio diferente… com uma mudança de www/não-www, tudo está dentro do mesmo domínio e você deveria ficar bem.” É por isso que isso é de baixo drama: www e não-www são o mesmo domínio registrado. Você não está mudando de domínio, está escolhendo um hostname.

Então trate “isso afeta o ranqueamento” como já resolvido — não — e gaste seu esforço nas partes que realmente dão trabalho: a configuração de DNS e o redirecionamento.

Seja preciso também sobre o que a consistência compra: escolher um hostname e alinhar seus sinais remove a ambiguidade de duplicação para os rastreadores. Isso não garante ranqueamento, tráfego, ou que um AI Overview ou chatbot cite você — nada sobre canonicalizar corretamente promete um resultado, apenas dá aos mecanismos de busca e aos sistemas de resposta de IA um endereço claro para apontar em vez de dois.

A história: a configuração de Domínio preferido do GSC

Por anos, o Google Search Console teve uma configuração de Domínio preferido: você dizia ao Google se queria exibir seu site como www ou não-www, e ele obedecia. Essa é a configuração que muitos tutoriais antigos ainda mandam você alterar. Ela não existe mais.

O Google anunciou sua remoção no post de 18 de junho de 2019 Bye Bye Preferred Domain setting: “À medida que avançamos com a migração para a nova experiência do Search Console, vamos nos despedir de uma de nossas configurações: domínio preferido.” E, crucialmente, ele parou de honrar configurações antigas: “Observe que com a descontinuação não usaremos mais nenhuma configuração de domínio preferido existente do Search Console.” Então, mesmo que você a tenha definido anos atrás, ela não está fazendo nada agora.

O que a substituiu não é um novo botão — é uma combinação de sinais que você precisa manter em concordância. O Google detalhou as opções nesse mesmo post: “Use a tag de link rel=“canonical” em páginas HTML / Use o cabeçalho HTTP rel=“canonical” / Use um sitemap / Use redirecionamentos 301 para URLs aposentadas.” Na prática, isso significa:

1. Um redirecionamento 301 da versão que você não escolheu para a que escolheu.
2. Tags rel=canonical apontando para a versão escolhida.
3. Um sitemap que lista apenas a versão escolhida — a orientação do Google de 2005 já alertava para não enviar ambas: ter as duas listadas “não afetará a indexação do seu site, desde que você tenha enviado um Sitemap apenas para uma versão.”

Por que “dica, não regra” significa que consistência vence

Aqui está a parte que torna a antiga mentalidade de configuração única perigosa. A documentação de canonicalização do Google é explícita ao afirmar que todas essas são sugestões: “indicar uma preferência canônica é uma dica, não uma regra.” O Google pondera vários fatores — HTTP vs HTTPS, redirecionamentos, inclusão no sitemap e anotações rel=canonical — e pode ainda escolher a versão que você não queria se seus outros sinais (backlinks, links internos) apontarem para o outro lado.

É exatamente por isso que a consistência em todos os sinais importa mais do que qualquer configuração individual já importou. Uma tag canônica apontando para não-www enquanto metade dos seus links internos e o seu sitemap apontam para www é uma mensagem contraditória. Escolha uma e faça tudo concordar — este é o mesmo princípio de “consistência supera otimização” que percorre o trabalho de estrutura de URL e canonicalização neste cluster; www vs não-www é apenas um dos aproximadamente 40 sinais de canonicalização catalogados lá.

Então por que tantos sites usam www por padrão? DNS.

Esta é a pergunta que quase todos os outros artigos ignoram, e é a resposta real: DNS, não SEO, não branding.

Um registro CNAME é o botão fácil para apontar um hostname para um CDN ou host: você faz CNAME de www.example.com para o hostname do seu provedor, e simplesmente funciona — e continua funcionando se o provedor mudar de IP. Mas a especificação DNS não permite que um CNAME viva no ápice da zona. O ápice deve conter registros SOA e NS, e um CNAME precisa ser o único registro no seu nó — essas duas regras conflitam, então um CNAME puro em example.com é ilegal segundo a especificação (RFC 1912 / 2181), e a maioria dos provedores de DNS o rejeita.

Para obter o mesmo comportamento de “apontar para meu CDN” no domínio raiz, você precisa de um dos seguintes:

• um registro A/AAAA (exige um IP estático, que muitas configurações de CDN/host não fornecem), ou
• um registro ALIAS / ANAME específico do provedor, ou o CNAME flattening da Cloudflare — todos os quais simulam um CNAME no ápice resolvendo-o no lado do servidor. Nem todo provedor de DNS suporta esses recursos.

Esse atrito é muito provavelmente a razão real pela qual tantas plataformas usam www por padrão: é o hostname que sempre pode receber um CNAME simples. É uma decisão de hospedagem/DNS vestida de decisão de SEO.

Cookies são limitados ao hostname que você escolhe

A escolha do hostname tem uma segunda consequência fácil de passar despercebida: o escopo do cookie. Um cookie definido sem um atributo Domain é um cookie restrito ao host — ele é enviado de volta apenas para o host exato que o definiu. Defina um cookie de sessão em www.example.com sem o atributo Domain, e ele nunca chegará a example.com (ou a qualquer outro subdomínio), e vice-versa.

Se você quiser que um cookie seja compartilhado entre o ápice e seus subdomínios, defina Domain para o ápice explicitamente — por exemplo, Domain=example.com. De acordo com a RFC 6265, o valor de Domain de um cookie precisa corresponder ao host atual ou a um host pai dele, então você pode definir Domain=example.com a partir de uma página servida em www.example.com, e o cookie depois se aplica a example.com e a todos os subdomínios — mas você não pode definir Domain para um domínio não relacionado.

Isso importa mais durante uma migração. Se seus cookies de sessão ou preferências forem restritos ao host na versão que você está desativando, esse estado não é transferido pelo 301 para o novo hostname — os visitantes podem ser desconectados ou perder uma preferência salva na primeira visita após a mudança. Defina Domain para o ápice antes da migração se você precisar de continuidade entre os dois hostnames enquanto o redirecionamento estiver ativo, ou planeje um novo login único no dia da mudança.

O argumento obsoleto de domínio sem cookies

Você ainda verá conselhos para usar um domínio separado sem cookies (geralmente o domínio raiz, ou um subdomínio dedicado de assets) para arquivos estáticos. Isso era uma otimização real da era HTTP/1.1: cada requisição a um domínio com cookies enviava os bytes do cookie junto, mesmo para imagens e CSS, então servir assets estáticos de um host sem cookies economizava overhead. O GTmetrix e o PageSpeed costumavam sinalizar isso.

Isso está praticamente morto hoje. A compressão de cabeçalhos HPACK do HTTP/2, junto com o uso quase universal de CDNs para assets estáticos, elimina a maior parte do benefício, e dividir assets em um host separado agora custa uma configuração de conexão extra. Não escolha www vs não-www — nem crie um subdomínio de assets — por esse motivo em 2026.

A armadilha do HSTS e do certificado

Aqui está a pegadinha prática que pega as pessoas no meio da troca, e é genuinamente pouco abordada em outros lugares. Quando você redireciona um hostname para o outro, o hostname do qual você redireciona ainda precisa do seu próprio certificado TLS válido. Um 301 de https://www.example.com para https://example.com só dispara depois que o navegador completa um handshake TLS com www.example.com — então, se www não tiver um certificado válido (ou um certificado que não o cubra), o visitante recebe um aviso de segurança de página inteira antes do seu redirecionamento ser executado. Cubra ambos os hostnames, com certificados separados ou um único certificado SAN/wildcard.

O HSTS torna isso mais crítico. Uma política de HSTS é específica do host — uma política definida em example.com não protege automaticamente www.example.com, e vice-versa. includeSubDomains só se propaga em uma direção: a política de um domínio pai pode abranger seus subdomínios, mas a política de um subdomínio nunca abrange o domínio pai. Portanto, se o domínio estiver na lista de pré-carregamento do HSTS ou exigir HTTPS, garanta que o certificado e o HSTS sejam coerentes em ambos os nomes de host; caso contrário, a exigência de HTTPS exibirá o aviso de certificado ausente antes do redirecionamento.

O Bing não tem equivalente ao Preferred Domain

O Bing nunca teve uma opção de domínio preferido. Na prática, o Bing Webmaster Tools trata www, não-www e cada combinação de HTTP e HTTPS como propriedades separadas para verificação e relatórios. Mesmo depois de escolher a versão preferencial e redirecionar as demais, você gerenciará as variantes como propriedades distintas. O mecanismo de consolidação é o mesmo do Google: configure o 301 no servidor e mantenha as indicações de URL preferencial e as URLs do sitemap coerentes com sua escolha.

Como realmente escolher um e fazê-lo valer

1. Escolha com base na realidade de DNS/hosting, não em SEO. Se o seu host/CDN precisa de um CNAME e seu provedor de DNS não faz ALIAS/flattening, o www é o caminho de menor resistência. Se o seu DNS suporta flattening de apex e você prefere o domínio raiz mais limpo, vá de não-www. A preferência de marca é um bom desempate — é um empate real.
2. Redirecione a outra versão com 301 — um 301 permanente, não um 302. (Um 302 sinaliza “temporário” e não consolida da forma que você quer.)
3. Faça as tags canônicas, o sitemap e os links internos concordarem com o vencedor.
4. Verifique se os cookies de login/preferência são exclusivos do host. Se você precisar que sessões ou preferências salvas sobrevivam à troca, defina Domain para o apex antes de ativar o redirecionamento — caso contrário, prepare-se para visitantes serem desconectados uma vez.
5. Garanta que ambos os hostnames tenham certificados válidos para que o redirecionamento nunca dispare um aviso.
6. Adicione/verifique as propriedades no Google Search Console (as propriedades de domínio cobrem todas as variantes) e no Bing Webmaster Tools (verifique as variantes separadamente).

Depois, deixe como está. Como mudar URLs em geral, re-litigar www vs não-www em um site que funciona é esforço gasto sem ganho de ranqueamento.

Resumo de IA

Uma visão condensada da versão Avançada:

• Definições: www é um subdomínio; example.com é o domínio apex, nu ou raiz. Ambos servem o mesmo conteúdo, então esta é uma escolha de consolidação da URL preferencial, não de ranqueamento.
• Sem diferença de ranqueamento — o Google afirma isso desde 2005; Mueller (março de 2024): quando a URL preferencial muda dentro do mesmo domínio, “it just switches,” (tradução) «ela simplesmente muda», talvez com uma breve soluço. O caso de risco é mudar para um domínio diferente, não www/não-www. (A fala separada de Mueller sobre subdomínios e subdiretórios serem tratados “the same” (tradução) «da mesma forma» responde a uma pergunta de organização de conteúdo, não a esta pergunta de ranqueamento — não confunda as duas.) Consistência também não é garantia de ranqueamentos, tráfego ou citações de IA — apenas dá aos rastreadores e mecanismos de resposta um endereço claro.
• A configuração de Domínio Preferido do GSC foi removida em 18 de junho de 2019 e configurações antigas não são mais honradas. A substituição é um pacote de sinais concordantes: rel=canonical + sitemap listando apenas a versão escolhida + um 301 do outro.
• Os sinais de preferência são uma dica, não uma regra — o Google ainda pode escolher a versão que você não queria, então todos os sinais devem concordar. www/não-www é um dos ~40 sinais de canonicalização.
• A razão real pela qual os sites usam www por padrão é DNS: um CNAME não pode ficar no apex da zona (conflito SOA/NS, RFC 1912/2181), então domínios nus precisam de A/AAAA ou ALIAS/ANAME/achatamento de CNAME. www sempre pode aceitar um CNAME simples.
• Cookies são limitados ao nome do host: um cookie restrito ao host (sem atributo Domain) não cruza de www para não-www ou vice-versa; defina Domain=example.com antes de migrar se sessões ou preferências precisarem sobreviver à mudança.
• O argumento de domínio sem cookies é obsoleto pós-HTTP/2 (HPACK + CDNs).
• Armadilha de TLS/HSTS: o nome do host do qual você redireciona ainda precisa de um certificado válido, ou um aviso de segurança dispara antes do 301. HSTS é específico do host; includeSubDomains só flui de pai → subdomínio.
• O Bing não tem alternância de domínio preferido — ele trata www/não-www/HTTP/HTTPS como propriedades separadas.
• Recomendação: escolha um com base em DNS/hospedagem, aplique um 301 ao outro (não 302), alinhe as indicações de URL preferencial, o sitemap e as ligações internas, certifique ambos os nomes de host e pare de mexer nisso.

Documentação oficial

Documentação de fonte primária dos mecanismos de busca.

Google

• Bye Bye Preferred Domain setting (2019) — a remoção de 18 de junho de 2019 e a lista exata do que a substitui (tag/cabeçalho canônico, sitemap, 301s).
• What is URL canonicalization — os fatores que o Google pondera (HTTP/HTTPS, redirecionamentos, sitemap, rel=canonical) e o enquadramento de “dica, não regra”.
• Consolidate duplicate URLs — o artigo do centro de ajuda para o qual o post de 2019 aponta para declarar sua versão preferida.
• www vs non-www versions of a site (2005) — o post fundamental (agora carrega o banner de conteúdo desatualizado do Google; use para histórico).
• SEO Starter Guide — enquadramento geral de URLs duplicadas / consolidação.

Bing / Microsoft

• Bing Webmaster Guidelines — a postura geral de canonicalização do Bing; sem alternância de domínio preferido.
• Better than canonical: URL Normalization — a abordagem de normalização do Bing (301 preferido, rel=canonical secundário).

Citações da fonte

Declarações registradas do Google. Cada link é um link profundo que salta para a passagem citada na página de origem.

Google, 2005 — o enquadramento original

• “Two URLs to a site—one that is prefaced with www and one that is not (for instance, https://www.example.com/ and https://example.com/)—often point to the same location on a server. But depending on the server configuration, they may point to different locations, so search engines can’t assume they are the same.” (tradução) «Duas URLs de um site — uma com www e outra sem — geralmente apontam para o mesmo local no servidor. Porém, conforme a configuração do servidor, elas podem apontar para locais diferentes; por isso, os mecanismos de busca não podem presumir que sejam iguais.» — Vanessa Fox, Google. Ir para a citação
• “Note that having both versions of the site’s URL listed in your account won’t affect the indexing of your site as long as you have submitted a Sitemap for only one version—the version you want to be indexed.” (tradução) «Observe que ter as duas versões da URL do site listadas na sua conta não afetará a indexação do seu site, desde que você tenha enviado um Sitemap apenas para uma versão — a versão que você deseja que seja indexada.» — Vanessa Fox, Google. Ir para a citação

Google, junho de 2019 — a remoção do domínio preferido

• “As we progress with the migration to the new Search Console experience, we will be saying farewell to one of our settings: preferred domain.” (tradução) «À medida que avançamos com a migração para a nova experiência do Search Console, nos despediremos de uma de nossas configurações: domínio preferido.» — Daniel Waisberg, Google. Ir para a citação
• “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” (tradução) «Observe que com a descontinuação, não usaremos mais nenhuma configuração existente de domínio preferido no Search Console.» — Daniel Waisberg, Google. Ir para a citação
• “Use rel=“canonical” link tag on HTML pages” (tradução) «Use a tag de link rel=“canonical” em páginas HTML» — a primeira das quatro opções de substituição: tag que indica a URL preferencial, cabeçalho HTTP equivalente, sitemap e redirecionamentos 301. Ir para a citação

Google — a canonicalização é uma dica, não uma regra

• “There are a handful of factors that play a role in canonicalization” (tradução) «Há alguns fatores que desempenham um papel na canonicalização» — a lista do Google inclui HTTP vs HTTPS, redirecionamentos, presença de sitemap e anotações rel=canonical; “indicating a canonical preference is a hint, not a rule.” (tradução) «Indicar uma preferência canônica é uma dica, não uma regra.» Ir para a citação
• “The canonical page will be crawled most regularly; duplicates are crawled less frequently in order to reduce the crawling load on sites.” (tradução) «A página preferencial será rastreada com mais regularidade; as duplicatas serão rastreadas com menos frequência para reduzir a carga de rastreamento nos sites.» Ir para a citação

John Mueller, Google — março de 2024, sobre a troca de canônicos www ⇄ não-www

• “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (tradução) «Isso não causará problemas de visibilidade, ranqueamento nem indexação na pesquisa: quando a URL preferencial muda, ela simplesmente muda. Pode haver uma pequena oscilação, mas tudo volta ao normal muito rapidamente.» — John Mueller, no Reddit.
• “The only time it would cause bigger changes is if you switch canonicals to a different domain, and the domains have something different set up… with a www/non-www switch it’s all within the same domain and you should be fine.” (tradução) «A única situação em que isso causaria mudanças maiores seria trocar as URLs preferenciais para outro domínio com configuração diferente… em uma mudança entre www e não-www, tudo permanece no mesmo domínio e não deve haver problema.» — John Mueller, no Reddit. Ambas as citações são respostas de Mueller no Reddit, conforme relatado por Barry Schwartz no Search Engine Roundtable (19 de março de 2024); o tópico original do Reddit não foi re-buscado de forma independente, então trate o SERoundtable como a fonte de registro.

John Mueller, Google — subdomínios tratados da mesma forma (contexto de apoio, não específico de www)

• “In general, we see these the same… I would personally try to keep things together as much as possible… Use subdomains where things are really kind of slightly different.” (tradução) «Em geral, vemos estes da mesma forma… Eu pessoalmente tentaria manter as coisas juntas o máximo possível… Use subdomínios onde as coisas são realmente um pouco diferentes.» — John Mueller, sobre subdomínios vs subdiretórios. Leia a cobertura Isso responde a uma pergunta de organização de conteúdo (subdomínio vs. subdiretório para conteúdo diferente), não a pergunta de ranqueamento www/não-www — citado apenas para mostrar que www é estruturalmente um subdomínio como qualquer outro, não como evidência de “nenhuma diferença de ranqueamento.” Essa afirmação se baseia no post de 2005 e na resposta de Mueller de 2024 acima.

Qual você deve escolher — e como?

Não há uma resposta certa de SEO aqui, então esta árvore orienta você pela realidade de DNS/hospedagem e depois entrega os passos de aplicação. Comece no topo.

Lista de verificação de consolidação www/não-www

Uma passada para confirmar que uma versão é canônica e a outra é redirecionada de forma limpa:

• Uma versão escolhida como canônica (www ou não-www) — a escolha orientada pela realidade de DNS/hospedagem, não por uma vantagem imaginária de SEO.
• O DNS resolve o domínio raiz corretamente — A/AAAA, ou ALIAS/ANAME/ achatamento de CNAME (um CNAME puro no domínio raiz é inválido e será rejeitado).
• Um único 301 (permanente, não 302) do host não preferido para o preferido, definido em exatamente um lugar (sem regras conflitantes → sem loop de redirecionamento).
• Ambos os hostnames apresentam um certificado TLS válido (SAN ou curinga cobrindo www e não-www), para que o redirecionamento nunca acione um aviso de segurança do navegador.
• HSTS é coerente em ambos os hosts — lembre-se de que includeSubDomains flui apenas de pai → subdomínio.
• Cookies definem Domain=example.com (não deixados apenas no host) antes de migrar, se sessões ou preferências precisarem sobreviver à mudança.
• rel=canonical em cada página aponta para a versão escolhida.
• O sitemap XML lista apenas as URLs da versão escolhida — não envie ambos.
• Links internos usam a versão escolhida de forma consistente (sem links absolutos para o outro host).
• Nenhum subdomínio de ativos sem cookies criado apenas pela razão obsoleta da era HTTP/1.1.
• Google Search Console — uma propriedade de Domínio adicionada (cobre todas as variantes).
• Bing Webmaster Tools — variantes verificadas como propriedades separadas.
• Você não está planejando mudar uma configuração funcional por SEO — não há ganho.

www vs não-www — folha de referência rápida

A decisão de relance

Realidade do DNS: apex vs www

Fatos rápidos

• Domínio preferido removido: 18 de junho de 2019 (e configurações antigas não são mais honradas).
• Sinais de canonicalização: ~40, e www/não-www é um deles.
• Domínio estático sem cookies: obsoleto pós-HTTP/2 (HPACK + CDNs).
• Cookies de host apenas: não cruzam www ↔ não-www a menos que Domain=example.com esteja definido.
• HSTS includeSubDomains: propaga apenas de pai → subdomínio.

Redirecione uma versão para a outra

Escolha uma versão canônica e faça o 301 da outra para ela. Configuração para os três servidores web comuns — ajuste a direção conforme sua escolha.

Apache (.htaccess) — redirecionar não-www → www

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

Apache (.htaccess) — redirecionar www → não-www

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

Nginx — redirecionar não-www → www (bloco de servidor dedicado, sem if a cada solicitação)

server {
    listen 443 ssl;
    server_name example.com;
    # This host still needs a valid cert, or the 301 never fires:
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://www.example.com$request_uri;
}

Nginx — redirecionar www → não-www

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/www.example.com.pem;
    ssl_certificate_key /etc/ssl/www.example.com.key;
    return 301 https://example.com$request_uri;
}

IIS (web.config) — redirecionar não-www → www

<rule name="Redirect to www" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^example\.com$" />
  </conditions>
  <action type="Redirect" url="https://www.example.com/{R:1}"
          redirectType="Permanent" />
</rule>

Mantenha a regra em um único lugar — uma segunda regra apontando na outra direção (em um plugin, CDN ou configuração do CMS) é a causa clássica de um loop de redirecionamento www/não-www.

Verifique o redirecionamento e ambos os certificados

macOS / Linux — confirme que há um único 301 direto e que ambos os hosts apresentam um certificado válido:

# Follow the redirect chain — you want ONE 301 to the canonical host
curl -sIL https://example.com/ | grep -Ei 'HTTP/|^location:'

# Check the cert on the host you redirect FROM (must be valid, or the 301 never fires)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates

Windows (PowerShell)

# Inspect the redirect without auto-following it
Invoke-WebRequest -Uri "https://example.com/" -MaximumRedirection 0 `
  -ErrorAction SilentlyContinue | Select-Object StatusCode, Headers

Se o cabeçalho Location apontar para a versão escolhida com um 301, e ambos os hosts apresentarem um certificado válido, você terminou.

O que não fazer

Servindo ambas as versões sem redirecionamento. O único resultado genuinamente prejudicial: toda página acessível tanto em www quanto sem www, sem nenhuma consolidação. Agora os mecanismos de busca veem URLs duplicadas e precisam adivinhar uma canônica. Isso — não a escolha entre www/não-www — é o que causa problemas.

Usando um 302 em vez de um 301. Um 302 diz “temporário”. Você quer a consolidação permanente e a transferência de autoridade de um 301. Reserve os 302 para movimentações genuinamente temporárias.

Duas regras de redirecionamento conflitantes. Uma regra no seu CMS envia não-www → www enquanto uma regra de CDN envia www → não-www — um loop infinito de redirecionamento (“muitos redirecionamentos”). Aplique a escolha em exatamente uma camada.

Esquecendo o certificado no host de origem do redirecionamento. Redirecionar www → não-www, mas certificar apenas o domínio raiz significa que os visitantes de https://www. encontram um aviso de segurança antes do 301 ser executado. Cubra ambos os hostnames.

Mudando uma configuração consolidada e funcional “por SEO”. Não há ganho de ranqueamento, apenas o pequeno risco de um redirecionamento mal feito ou uma interrupção temporária. Se funciona, não mexa.

Perseguindo a antiga configuração de Domínio Preferido do GSC. Ela não existe desde junho de 2019 e configurações antigas são ignoradas. Seguir um tutorial que manda ativá-la desperdiça tempo e dá uma falsa sensação de que o trabalho está feito — o trabalho real é o 301 + canônica + sitemap.

Criando um subdomínio de assets sem cookies para velocidade. Esse truque da era HTTP/1.1 está obsoleto pós-HTTP/2; hoje a conexão extra geralmente custa mais do que os bytes de cookies removidos economizam.

Misturando sinais. Uma tag canônica apontando para não-www enquanto seu sitemap e links internos apontam para www é uma dica contraditória. Como a canonicalização é uma dica, não uma regra, faça todos os sinais concordarem.

Falhas comuns na canonicalização de hostname

Ambos os hostnames retornam 200

Sintoma: www.example.com/page e example.com/page carregam de forma independente. Causa provável: O DNS aponta ambos os hosts para o site, mas nenhum redirecionamento de host preferido é imposto. Correção: Escolha o host estabelecido, redirecione permanentemente o alternativo em um único salto e alinhe canônicas, links internos e sitemaps.

O hostname alternativo mostra um erro de certificado

Sintoma: HTTPS falha antes que o navegador possa seguir o redirecionamento. Causa provável: O certificado cobre apenas o hostname preferido. Correção: Mantenha DNS e TLS válidos no host que redireciona; a conexão HTTPS deve ser bem-sucedida antes que um redirecionamento HTTP possa ser recebido.

Requisições de hostname em loop ou formando uma cadeia

Sintoma: Requisições saltam entre hosts ou passam por saltos separados de HTTP, HTTPS, hostname e barra. Causa provável: Regras de CDN, origem e aplicação discordam sobre o destino. Correção: Defina uma política de URL final e faça cada rota alternativa apontar diretamente para ela na camada controlada mais cedo possível.

Revise um plano de migração de hostname

Cole os registros DNS, hostnames de certificado, regras de redirecionamento, amostras de canônicas, hosts de sitemap, configuração de analytics e um mapa de URL representativo:

Audit this www/non-www migration plan. Identify contradictions between DNS, TLS,
redirects, canonicals, internal links, sitemaps, and measurement. For every issue,
state the observed evidence, the likely user or crawler impact, the exact check to
run, and whether it blocks launch. Do not claim one hostname has an SEO ranking
advantage. Return a pre-launch table and a post-launch verification sequence.

Ferramentas para escolher e impor um único hostname

• Mapeador de cadeias de redirecionamento — rastreie mudanças de HTTP/HTTPS, www/não-www, barra e caminho juntas para que terminem em uma URL em um único salto.
• Verificador de canonicalização — encontre páginas cuja indicação de host preferencial conflita com sua resposta ou destino final de redirecionamento.
• Verificador de redirecionamentos — verifique caminhos correspondentes em ambos os nomes de host após uma mudança de configuração.
• Ferramentas de inspeção de DNS e TLS — confirme que ambos os nomes de host resolvem e apresentam certificados válidos, incluindo aquele que existe apenas para redirecionar.
• Um rastreador de site completo — localize ligações internas, indicações de URL preferencial, anotações hreflang e URLs de sitemap que ainda emitem o host alternativo.

Verifique URLs equivalentes em ambos os hosts

Teste a executar: Envie caminhos www e não-www correspondentes ao Redirect Chain Mapper. Resultado esperado: O host preferido carrega com sucesso e o alternativo redireciona permanentemente para o mesmo caminho no host preferido em um único salto. Interpretação de falha: Regras ausentes, direção reversa ou descarte de caminhos e consultas. Janela de monitoramento: Imediata após a implantação. Gatilho de reversão: Loops de redirecionamento, redirecionamentos amplos da página inicial ou erros no host preferido.

Verificar TLS e sinais emitidos

Teste a executar: Conecte-se a ambos os nomes de host HTTPS e, em seguida, rastreie as indicações de URL preferencial, as ligações internas e as URLs do sitemap. Resultado esperado: Ambos os certificados são válidos e todo sinal de SEO emitido usa o nome de host preferencial. Interpretação de falha: A versão alternativa não consegue entregar seu redirecionamento ou uma fonte de modelo ou configuração ainda usa o host antigo. Janela de monitoramento: Imediata para TLS; após um rastreamento completo, para os sinais de todo o site. Gatilho de reversão: Surgem erros de certificado ou um grande conjunto de indicações conflitantes de URL preferencial.

Teste-se: WWW vs. Não-WWW

Cinco perguntas rápidas sobre o que a escolha www/não-www realmente é e como aplicá-la. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus artigos relacionados

• O Google usa cerca de 40 sinais de canonicalização — o panorama mais amplo em que www/não-www se insere, incluindo como o Google pondera redirecionamentos, indicações de URL preferencial e sitemaps.
• Redirecionamentos para SEO: um guia simples, mas completo — como migrar entre versões com 301s sem perder autoridade.
• Barra final: usar ou não usar? — a mesma lógica de “escolha um e aplique-o de forma consistente” usada para outro sinal de canonicalização.
• O guia para iniciantes em SEO técnico — onde a canonicalização e a consolidação do nome do host se encaixam no panorama geral.

Minhas palestras

• Como a pesquisa funciona (SlideShare) — minha explicação sobre rastreamento, renderização, indexação e ranqueamento, o fluxo do qual a canonicalização faz parte. Minha ressalva padrão se aplica: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) «Esta é a minha compreensão dos sistemas… não será 100% completa nem precisa.»

Da indústria

• Adeus à configuração de domínio preferido (Google Search Central) — a remoção de junho de 2019 e seu substituto, direto da fonte.
• O que é canonicalização de URL (Google Search Central) — o enquadramento de “dica, não regra” e os fatores que o Google pondera.
• Google: canonicalizar de WWW para não-WWW não afeta seus ranqueamentos na pesquisa (Search Engine Roundtable, Barry Schwartz) — a resposta de Mueller de março de 2024: “it just switches” (tradução) «ela simplesmente muda».
• WWW ou não-WWW: qual é melhor para SEO? (Search Engine Journal, Winston Burton) — uma boa visão geral: sem diferença significativa; escolha uma versão e aplique um 301 à outra.
• Por que a raiz de um domínio não pode ser um CNAME — e outros detalhes sobre DNS (freeCodeCamp) — a restrição de apex/CNAME explicada de forma simples.
• Achatar CNAME (documentação de DNS da Cloudflare) — como um provedor simula um CNAME no apex.
• Redirecionamentos HSTS: WWW para não-WWW e HTTP para HTTPS (Sentinel Stand) — o problema de certificado e HSTS ao redirecionar entre hosts.

Registro de alterações