Durante anos, uma pequena guerra de pedantismo foi travada em nossas barras de endereços. Em um canto estão marcas como Google, Instagram e Facebook. Este grupo optou por redirecionar example.com para www.example.com. No canto oposto: GitHub, DuckDuckGo e Discord. Este grupo optou por fazer o inverso e redirecionar www.example.com para example.com.
“WWW” pertence a um URL? Alguns desenvolvedores têm opiniões fortes sobre o assunto. Exploraremos os argumentos a favor e contra depois de um pouco de história.
O que há com os Ws?
Os três Ws representam "Rede mundial de computadores", uma invenção do final dos anos 1980 que apresentou ao mundo navegadores e sites. A prática de usar “WWW” decorre de uma tradição de nomear subdomínios de acordo com o tipo de serviço que eles fornecem:
- um servidor web em www.example.com
- um servidor FTP em ftp.exemplo.com
- um servidor de IRC em irc.exemplo.com
Problema de domínio sem WWW 1: Vazamento de cookies para subdomínios
Os críticos de domínios “sem WWW” apontaram que, em certas situações, subdominio.example.com seria capaz de ler os cookies definidos por example.com. Isso pode ser indesejável se, por exemplo, você for um provedor de hospedagem na web que permite que os clientes operem subdomínios em seu domínio. Embora a preocupação seja válida, o comportamento era específico do Internet Explorer.
RFC 6265 padroniza como os navegadores tratam os cookies e chama explicitamente esse comportamento de incorreto.
Outra fonte potencial de vazamentos é a Domain valor de quaisquer cookies definidos por example.com. Se o Domain o valor é explicitamente definido como example.com, os cookies também serão expostos aos seus subdomínios.
| Valor do cookie | Exposto a example.com | Exposto a subdominio.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
Em conclusão, contanto que você não defina explicitamente um Domain value e seus usuários não usam o Internet Explorer, nenhum vazamento de cookie deve ocorrer.
Problema de domínio sem WWW 2: dores de cabeça com DNS
Às vezes, um domínio “sem WWW” pode complicar a configuração do Sistema de Nomes de Domínio (DNS).
Quando um usuário digita example.com na barra de endereços do navegador, o navegador precisa saber o endereço IP (Internet Protocol) do servidor da Web que está tentando visitar. O navegador solicita esse endereço IP dos servidores de nomes do seu domínio – geralmente indiretamente por meio dos servidores DNS do provedor de serviços de Internet (ISP) do usuário. Se seus servidores de nomes estiverem configurados para responder com um Uma gravação contendo o endereço IP, um domínio “sem WWW” funcionará bem.
Em alguns casos, você pode querer usar um Nome canônico (CNAME) registro para o seu site. Tal registro pode declarar que www.example.com é um pseudônimo de exemplo123.somecdnprovider.com, que instrui o navegador do usuário a procurar o endereço IP de exemplo123.somecdnprovider.com e envie a solicitação HTTP para lá.
Observe que o exemplo acima usou um subdomínio WWW. Não é possível definir um registro CNAME para example.com. Conforme RFC 1912, os registros CNAME não podem coexistir com outros registros. Se você tentou definir um registro CNAME para example.com, os registros do servidor de nomes (NS) para example.com contendo os endereços IP dos servidores de nome do domínio não teriam permissão para existir. Como resultado, os navegadores não seriam capazes de descobrir onde estão seus servidores de nomes.
Alguns provedores de DNS permitirão que você contorne essa limitação. Cloudflare chama sua solução Nivelamento de CNAME. Com essa técnica, os administradores de domínio configuram um registro CNAME, mas seus servidores de nomes expõem um registro A.
Por exemplo, se o administrador configurar um registro CNAME para example.com apontando para exemplo123.somecdnprovider.com, e um recorde A para exemplo123.somecdnprovider.com existe apontando para 1.2.3.4, o Cloudflare exporia um registro A para example.com apontando para 1.2.3.4.
Em conclusão, embora a preocupação seja válida para proprietários de domínio que desejam usar registros CNAME, alguns provedores de DNS agora oferecem uma solução alternativa adequada.
Benefícios sem WWW
A maior parte do argumentos contra WWW são práticos ou cosméticos. Os defensores do “sem WWW” argumentaram que é mais fácil dizer e digitar example.com do que www.example.com (o que pode ser menos confuso para usuários menos experientes em tecnologia).
Os oponentes do subdomínio WWW também apontaram que abandoná-lo traz uma vantagem de desempenho humilde. Os proprietários de sites podem economizar 4 bytes de cada solicitação HTTP ao fazer isso. Embora essas economias possam aumentar para sites de alto tráfego como o Facebook, a largura de banda geralmente não é um recurso escasso.
Benefícios da WWW
Um argumento prático a favor da WWW é em situações com domínios de nível superior mais recentes. Por exemplo, www.exemplo.miami é imediatamente reconhecível como um endereço da web quando exemplo.miami não é. Isso é menos preocupante para sites que têm domínios de nível superior reconhecíveis, como .com.
Impacto na classificação do seu mecanismo de pesquisa
O consenso atual é que sua escolha não influencia o desempenho do mecanismo de pesquisa. Se você deseja migrar de um para o outro, configure redirecionamentos permanentes (HTTP 301) em vez de temporários (HTTP 302). Redirecionamentos permanentes garantem que o valor de SEO de seus URLs antigos seja transferido para os novos.
Dicas para apoiar os dois
Os sites geralmente escolhem example.com or www.example.com como seu site oficial e configurar redirecionamentos HTTP 301 para o outro. Em teoria, é possível suportar ambos www.example.com e example.com. Na prática, os custos podem superar os benefícios.
Do ponto de vista técnico, você deve verificar se sua pilha de tecnologia pode lidar com isso. Seu sistema de gerenciamento de conteúdo (CMS) ou site gerado estaticamente teria que gerar links internos como URLs relativos para preservar o nome de host preferido do visitante. Suas ferramentas de análise podem registrar o tráfego para ambos os nomes de host separadamente, a menos que você possa configurar os nomes de host como aliases.
Por fim, você precisará dar um passo extra para proteger o desempenho do mecanismo de pesquisa. O Google considerará as versões “WWW” e “não-WWW” de um URL como conteúdo duplicado. Para desduplicar o conteúdo em seu índice de pesquisa, o Google exibirá qualquer um dos dois que achar que o usuário preferirá – para o bem ou para o mal.
Para preservar o controle sobre como você aparece no Google, ele recomenda a inserção de tags de link canônico. Primeiro, decida qual nome de host será o oficial (canônico).
Por exemplo, se você escolher www.example.com, você terá que inserir o seguinte trecho no etiquetar https://example.com/my-article:
Este snippet indica ao Google que a variante “sem WWW” representa o mesmo conteúdo. Em geral, o Google prefere a versão que você marcou como canônica nos resultados de pesquisa, que seria a variante “WWW” neste exemplo.
Conclusão
Apesar da intensa campanha de ambos os lados, ambas as abordagens permanecem válidas desde que você esteja ciente dos benefícios e limitações. Para cobrir todas as suas bases, certifique-se de configurar redirecionamentos permanentes de um para o outro e está tudo pronto.
