Nos últimos anos tornou-se comum encontrar, videos, tutoriais e até mesmo influencers dando recomendações para remover o www dos websites e utilizar somente o chamado naked domain:

https://empresa.com.br

em vez de:

https://www.empresa.com.br

Uma das justificativas frequentemente apresentadas é que uma URL sem www seria “melhor para SEO”, mais moderna ou mais eficiente para mecanismos de busca.

Do ponto de vista técnico, esse argumento é fraco.

Não existe vantagem inerente de SEO simplesmente por retirar o www.

Por outro lado, utilizar www como hostname principal de uma aplicação Web pode oferecer vantagens reais em áreas muito mais importantes:

arquitetura DNS;
integração com WAF/CDN;
independência de endereços IP;
migração de infraestrutura;
failover;
disaster recovery;
separação de serviços;
gerenciamento de cookies;
segurança entre subdomínios.

Por esse motivo, em muitos ambientes corporativos, a arquitetura:

empresa.com.br
      ↓
    301/308
      ↓
www.empresa.com.br

continua sendo uma excelente escolha.

Primeiro: remover o WWW não melhora SEO

É importante começar eliminando um mito.

Para mecanismos de busca, tanto:

https://empresa.com.br

quanto:

https://www.empresa.com.br

podem ser utilizados normalmente.

O que realmente importa é definir qual endereço será o canônico.

Se a organização optar por www, uma arquitetura correta seria:

https://empresa.com.br/produto
            ↓
          301/308
            ↓
https://www.empresa.com.br/produto

E todos os demais sinais devem ser consistentes:

Canonical URL → https://www.empresa.com.br/produto

Sitemap       → https://www.empresa.com.br/...

Links internos → https://www.empresa.com.br/...

Structured Data → https://www.empresa.com.br/...

O problema de SEO aparece quando as duas versões ficam disponíveis independentemente:

https://empresa.com.br/produto      → 200
https://www.empresa.com.br/produto  → 200

sem canonicalização adequada.

Portanto:

SEO exige consistência. Ele não exige naked domain.

Então por que utilizar WWW?

Porque www não é apenas uma tradição antiga.

Tecnicamente:

empresa.com.br

www.empresa.com.br

ocupam posições diferentes dentro da arquitetura DNS.

empresa.com.br é o zone apex, também chamado de:

apex domain;
root domain;
naked domain.

Já:

www.empresa.com.br

é um hostname convencional.

Essa diferença oferece ao www algumas vantagens arquiteturais interessantes.

1. WWW pode utilizar CNAME de forma natural

Uma das maiores vantagens aparece quando o website utiliza WAF, CDN ou outra infraestrutura distribuída.

Por exemplo, um cliente protegido pela XLabs Security pode utilizar:

www.empresa.com.br. CNAME web.armor.zone.

A arquitetura passa a ser:

Usuário
   │
   ▼
www.empresa.com.br
   │
   │ CNAME
   ▼
web.armor.zone
   │
   ▼
XLabs Security
   │
   ├── WAF
   ├── CDN
   ├── TLS
   ├── proteção contra ataques
   ├── cache
   └── observabilidade
   │
   ▼
Origin

O hostname público continua sendo:

www.empresa.com.br

independentemente de alterações internas realizadas na infraestrutura.

Essa camada de indireção é extremamente útil.

2. O naked domain possui restrições diferentes no DNS

No apex:

empresa.com.br

precisam existir registros fundamentais da própria zona DNS.

Por isso não se utiliza um CNAME DNS convencional no apex da mesma maneira que podemos utilizar em:

www.empresa.com.br

Dependendo do provedor DNS, torna-se necessário utilizar mecanismos como:

ALIAS;
ANAME;
Apex Alias;
CNAME Flattening;
recursos equivalentes;
ou registros A/AAAA diretamente.

Esses mecanismos podem funcionar muito bem.

O problema não é sua existência.

A questão é que passamos a depender de funcionalidades específicas do DNS autoritativo para reproduzir algo que, com:

www.empresa.com.br CNAME destino.example

é uma operação DNS extremamente simples e padronizada.

3. WWW reduz o acoplamento com endereços IP

Outra solução comum para colocar o naked domain diretamente em uma infraestrutura é utilizar:

empresa.com.br. A 203.0.113.10
empresa.com.br. A 203.0.113.11

Isso cria um relacionamento direto entre o hostname público e determinados endereços.

Em caso de mudança de infraestrutura pode ser necessário modificar:

A
AAAA

e considerar:

TTL;
caches DNS;
resolvers;
IPv4;
IPv6;
propagação;
failover.

Com:

www.empresa.com.br CNAME web.armor.zone.

a abstração é muito maior.

A XLabs pode modificar a infraestrutura por trás de:

web.armor.zone

sem exigir que o cliente publique novos IPs para o website.

4. Migrações ficam mais simples

Considere uma empresa que precisa alterar a infraestrutura de entrega de sua aplicação.

Com:

www.empresa.com.br
        ↓
      CNAME
        ↓
infraestrutura atual

é possível mudar o destino daquela camada de abstração.

Conceitualmente:

www.empresa.com.br
        │
        ▼
web.production.example
        │
        ├── infraestrutura A
        │
        └── infraestrutura B

Isso pode simplificar:

migrações;
blue/green;
failover;
disaster recovery;
troca de WAF;
troca de CDN;
alteração de PoPs.

O CNAME não cria alta disponibilidade sozinho, mas fornece uma abstração extremamente conveniente para construí-la.

5. O naked domain pode ficar responsável somente pelo redirect

Uma arquitetura simples e previsível é:

empresa.com.br
      │
      │ 301/308
      ▼
www.empresa.com.br
      │
      ▼
XLabs Security WAF/CDN
      │
      ▼
Origin

Nesse modelo:

empresa.com.br

possui uma função simples:

encaminhar o usuário para o hostname oficial da aplicação.

Enquanto:

www.empresa.com.br

é efetivamente o website.

A organização passa a possuir uma separação bastante clara:

empresa.com.br          → redirect
www.empresa.com.br      → website
api.empresa.com.br      → APIs
app.empresa.com.br      → aplicação
static.empresa.com.br   → assets
mail.empresa.com.br     → e-mail

Essa organização pode parecer apenas estética, mas possui consequências interessantes para arquitetura e segurança.

6. O naked domain continua disponível

Recomendar www não significa abandonar:

empresa.com.br

Muito pelo contrário.

Ele continua funcionando normalmente.

Por exemplo:

https://empresa.com.br
        ↓
       301
        ↓
https://www.empresa.com.br

Assim, tanto quem digitar:

empresa.com.br

quanto quem utilizar:

www.empresa.com.br

chegará ao mesmo website.

Do ponto de vista de marca e usabilidade, nada é perdido.

7. Os dois hostnames precisam de alta disponibilidade

Existe, entretanto, uma observação importante.

Se:

empresa.com.br

redireciona para:

www.empresa.com.br

o apex também precisa permanecer disponível.

Usuários podem chegar até ele através de:

digitação manual;
bookmarks;
backlinks;
e-mails;
QR Codes;
documentos;
resultados antigos;
aplicativos;
sistemas legados.

Portanto:

empresa.com.br

não deve existir em um servidor improvisado apenas para fazer redirect.

Idealmente, o redirect também deve estar em infraestrutura resiliente.

8. TLS acontece antes do redirect

Outro ponto importante.

Para executar:

https://empresa.com.br
        ↓
       301
        ↓
https://www.empresa.com.br

o navegador primeiro executa:

DNS
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
301

Isso significa que o domínio raiz também precisa possuir um certificado TLS válido.

Caso contrário, o usuário poderá receber um erro de certificado antes mesmo do redirect acontecer.

Uma implementação adequada deve portanto contemplar TLS para:

empresa.com.br

www.empresa.com.br

9. Atenção aos certificados wildcard

Um certificado:

*.empresa.com.br

pode contemplar:

www.empresa.com.br
api.empresa.com.br
app.empresa.com.br

mas o próprio:

empresa.com.br

precisa ser contemplado explicitamente quando necessário.

Por isso é comum existir:

empresa.com.br
*.empresa.com.br

no mesmo certificado ou em certificados apropriados.

Isso é especialmente importante quando o apex participa do redirect HTTPS.

10. WWW também cria uma fronteira arquitetural interessante para cookies

Outro benefício aparece na segurança de sessões.

Considere uma aplicação principal em:

www.empresa.com.br

Se ela criar:

Set-Cookie: session=SECRET;
Secure;
HttpOnly;
SameSite=Lax;
Path=/

sem declarar Domain, o navegador cria um host-only cookie.

Isso significa que a sessão pertence especificamente a:

www.empresa.com.br

e não é automaticamente enviada para:

api.empresa.com.br
static.empresa.com.br
marketing.empresa.com.br
blog.empresa.com.br
legacy.empresa.com.br

A arquitetura fica muito clara:

                empresa.com.br
                      │
                     301
                      │
                      ▼
              www.empresa.com.br
                      │
               cookie de sessão
                  host-only
                      │

   api.empresa.com.br        marketing.empresa.com.br
          │                            │
     sem cookie                    sem cookie

11. O problema dos cookies configurados para o domínio inteiro

Compare isso com:

Set-Cookie: session=SECRET;
Domain=empresa.com.br;
Secure;
HttpOnly

Nesse caso o cookie pode ficar disponível para subdomínios compatíveis.

Por exemplo:

www.empresa.com.br
api.empresa.com.br
blog.empresa.com.br
static.empresa.com.br
marketing.empresa.com.br
support.empresa.com.br
legacy.empresa.com.br

Uma requisição aparentemente inocente como:

GET /logo.png HTTP/1.1
Host: static.empresa.com.br

pode carregar:

Cookie: session=SECRET

caso o cookie tenha sido definido com esse escopo.

Isso aumenta desnecessariamente a superfície da sessão.

12. O problema fica mais sério com serviços terceirizados

Empresas modernas frequentemente possuem estruturas como:

empresa.com.br
├── www
├── api
├── blog
├── marketing
├── suporte
├── status
└── legacy

Nem todos esses sistemas necessariamente pertencem à mesma infraestrutura.

Alguns podem estar hospedados em:

SaaS;
plataformas de marketing;
ferramentas de suporte;
sistemas de terceiros;
aplicações antigas;
infraestrutura de parceiros.

Imagine:

marketing.empresa.com.br CNAME plataforma-terceira.example.

Para o navegador, entretanto, o hostname continua sendo:

marketing.empresa.com.br

Portanto, um cookie com:

Domain=empresa.com.br

pode ser enviado naquela requisição.

É exatamente por isso que cookies de sessão deveriam possuir o menor escopo possível.

13. WWW não é uma solução mágica para cookies

É importante deixar essa ressalva.

Uma aplicação hospedada diretamente em:

empresa.com.br

também pode criar corretamente um host-only cookie.

Por exemplo:

Set-Cookie: session=SECRET;
Secure;
HttpOnly;
SameSite=Lax;
Path=/

Portanto:

Naked domain não significa automaticamente cookie inseguro.

A vantagem de www é principalmente de organização e estabelecimento de uma fronteira explícita para a aplicação.

A aplicação está em:

www.empresa.com.br

e a sessão pertence ao:

www.empresa.com.br

Isso reduz ambiguidades arquiteturais.

14. Para sessões críticas, utilize `__Host-`

Uma configuração particularmente interessante é:

Set-Cookie: __Host-session=SECRET;
Secure;
HttpOnly;
SameSite=Lax;
Path=/

sem Domain.

Cookies com prefixo:

__Host-

possuem restrições que reforçam seu vínculo ao hostname que os criou.

Isso ajuda a proteger contra determinados cenários envolvendo manipulação de cookies por subdomínios.

Para aplicações críticas, é uma proteção que merece ser considerada.

15. Subdomain Takeover torna cookies amplos ainda mais perigosos

Imagine:

old.empresa.com.br

apontando para algum serviço que a empresa deixou de utilizar.

Se o registro DNS permanecer configurado e um atacante conseguir assumir o recurso correspondente, ele pode passar a controlar:

old.empresa.com.br

Esse cenário é conhecido como:

Subdomain Takeover.

Agora combine isso com:

Domain=empresa.com.br

em um cookie de sessão.

Temos:

cookie com escopo amplo
          +
subdomínio comprometido
          =
risco significativamente maior

Por isso, segmentação e isolamento são importantes.

16. Cookie Tossing e Cookie Injection

Um subdomínio comprometido também pode tentar criar:

Set-Cookie: session=ATTACKER_VALUE;
Domain=empresa.com.br;
Path=/

Dependendo da aplicação e de como cookies duplicados são processados, isso pode contribuir para problemas como:

Cookie Tossing;
Cookie Injection;
Cookie Shadowing;
Session Fixation;
inconsistências de parsing.

Cookies host-only e __Host- ajudam a construir uma barreira melhor contra essa classe de problema.

17. E quanto ao SEO? O que realmente merece atenção?

Se uma organização está considerando remover o www para “melhorar SEO”, provavelmente existem dezenas de otimizações muito mais importantes.

Conteúdo útil e original

O conteúdo precisa realmente responder ao que o usuário procura.

Priorize:

conhecimento real;
informações originais;
profundidade técnica;
atualização;
exemplos;
demonstrações;
respostas completas.

Publicar conteúdo superficial apenas para repetir palavras-chave dificilmente representa uma estratégia sustentável.

Titles bem construídos

Evite:

<title>Produtos</title>

Prefira algo que realmente explique a página:

<title>Web Application Firewall e CDN para Aplicações Web | Empresa</title>

Cada página importante deve possuir um título específico e descritivo.

Meta descriptions úteis

Evite keyword stuffing:

<meta
 name="description"
 content="WAF WAF CDN segurança firewall WAF CDN segurança">

Prefira uma descrição voltada ao usuário:

<meta
 name="description"
 content="Proteja aplicações Web contra ataques e vulnerabilidades utilizando WAF, CDN e análise contínua de tráfego.">

Estrutura de conteúdo

Um bom website deveria possuir uma hierarquia compreensível.

Por exemplo:

Home
 │
 ├── Produtos
 │    ├── WAF
 │    ├── CDN
 │    └── Web IPS
 │
 ├── Soluções
 │
 ├── Suporte
 │
 └── Blog
      ├── Vulnerabilidades
      ├── Segurança Web
      └── Pesquisas

Isso ajuda tanto usuários quanto crawlers.

Links internos

Uma página importante não deveria ficar completamente isolada.

Se um artigo sobre uma vulnerabilidade possui relação com:

WAF

ou:

proteção de aplicações

é útil criar links internos contextuais entre esses conteúdos.

Isso facilita descoberta e entendimento da estrutura do website.

Sitemap XML

Mantenha um sitemap atualizado:

https://www.empresa.com.br/sitemap.xml

utilizando sempre o hostname canônico.

Se a decisão é utilizar www, não deveria existir no sitemap uma mistura de:

empresa.com.br/pagina1
www.empresa.com.br/pagina2
empresa.com.br/pagina3

Consistência é fundamental.

Canonical corretamente configurado

Em uma arquitetura www, a página:

https://www.empresa.com.br/produto

pode apresentar:

<link
 rel="canonical"
 href="https://www.empresa.com.br/produto">

As demais variantes devem direcionar para ela.

Robots e noindex

Revise cuidadosamente:

robots.txt

<meta name="robots">

Um simples:

Disallow: /

ou:

<meta name="robots" content="noindex">

esquecido em produção pode causar um impacto muito maior em SEO do que qualquer escolha entre www e naked domain.

Performance e Core Web Vitals

Sites rápidos proporcionam uma experiência melhor.

Avalie:

tempo de resposta do backend;
cache;
CDN;
imagens;
JavaScript;
CSS;
fontes;
recursos de terceiros;
estabilidade visual;
responsividade.

Nesse ponto, uma infraestrutura CDN corretamente dimensionada pode trazer benefícios concretos.

Mobile

O website deve funcionar corretamente em dispositivos móveis.

Não apenas visualmente.

É importante garantir que a versão mobile possua:

conteúdo;
links;
metadados;
structured data;
imagens;
navegação

equivalentes ao necessário para compreender a página.

Dados estruturados

Quando aplicável, utilize dados estruturados como:

Article
Organization
Product
BreadcrumbList

Eles ajudam mecanismos de busca a compreender a natureza do conteúdo.

Não são uma forma mágica de ganhar posições, mas fazem parte de uma implementação técnica de SEO bem construída.

Imagens

Otimize:

tamanho
formato
dimensões
carregamento
alt text
nome de arquivo

Em vez de:

IMG00091823.jpg

algo como:

arquitetura-waf-cdn.jpg

pode ser mais compreensível.

E utilize um alt que realmente descreva a imagem.

Status HTTP corretos

Não transforme tudo em:

HTTP 200

Uma página inexistente deve normalmente ser:

ou:

Redirects permanentes devem utilizar:

ou:

quando apropriado.

Também evite cadeias como:

http://empresa.com.br
 ↓
https://empresa.com.br
 ↓
https://www.empresa.com.br
 ↓
https://www.empresa.com.br/home

Quando for possível fazer:

http://empresa.com.br
 ↓
301
 ↓
https://www.empresa.com.br/

Search Console e medição

SEO deve ser medido.

Acompanhe:

cliques;
impressões;
consultas;
CTR;
indexação;
crawling;
sitemaps;
Core Web Vitals;
páginas excluídas;
erros;
rich results.

É muito mais produtivo descobrir por que uma página com milhares de impressões recebe poucos cliques do que remover www esperando uma melhoria abstrata.

Checklist: antes de retirar o WWW por SEO

Antes de realizar uma mudança estrutural no domínio, pergunte:

Existe algum estudo demonstrando que o www está prejudicando nosso SEO?
Nossa canonicalização está correta?
Os redirects estão corretos?
O sitemap utiliza somente a URL canônica?
Existem conteúdos duplicados?
O website possui páginas órfãs?
Os links internos estão bem estruturados?
Nossos títulos são bons?
O conteúdo realmente responde às buscas?
O mobile está correto?
Os Core Web Vitals estão bons?
Existem problemas de crawling?
Existem noindex indevidos?
O robots.txt está correto?
As imagens estão otimizadas?
O backend está rápido?
Utilizamos dados estruturados quando necessário?
Estamos acompanhando Search Console?

Se vários desses itens ainda precisam ser resolvidos, trocar:

www.empresa.com.br

por:

empresa.com.br

provavelmente está muito longe de ser a prioridade correta.

Nossa recomendação

Na XLabs Security, quando não existe uma necessidade específica em sentido contrário, vemos vantagens arquiteturais relevantes em utilizar:

www.empresa.com.br

como hostname canônico da aplicação Web.

E manter:

empresa.com.br

como uma entrada válida que direciona permanentemente para:

www.empresa.com.br

Por exemplo:

                    Internet
                       │
                       ▼
                 empresa.com.br
                       │
                    301/308
                       │
                       ▼
              www.empresa.com.br
                       │
                     CNAME
                       │
                       ▼
                 web.armor.zone
                       │
                       ▼
                XLabs Security
                 WAF / CDN
                       │
                       ▼
                     Origin

Essa arquitetura permite unir:

canonicalização adequada;
simplicidade DNS;
utilização natural de CNAME;
abstração da infraestrutura;
maior flexibilidade operacional;
facilidade de migração;
melhor organização dos serviços;
possibilidade de isolamento de cookies;
integração limpa com WAF/CDN.

Conclusão

Retirar www pode ser uma decisão estética ou de branding.

O que não deveria ser é uma decisão baseada na ideia de que:

“naked domain ranqueia melhor.”

Essa vantagem simplesmente não é inerente à arquitetura.

Por outro lado, www oferece propriedades técnicas concretas que continuam extremamente úteis em ambientes modernos.

O desenho:

empresa.com.br
      ↓
    301/308
      ↓
www.empresa.com.br
      ↓
     WAF/CDN
      ↓
    aplicação

estabelece uma separação clara entre o domínio organizacional e o hostname responsável pela aplicação Web.

Em ambientes corporativos que dependem de WAF, CDN, múltiplos pontos de presença, failover e serviços distribuídos, essa distinção pode representar uma vantagem operacional real.

E, se o objetivo for melhorar SEO, os investimentos deveriam estar principalmente em:

conteúdo, performance, crawling, indexação, estrutura, links, mobile, Core Web Vitals e experiência do usuário.

Não nas três letras www.

Primeiro: remover o WWW não melhora SEO

Então por que utilizar WWW?

1. WWW pode utilizar CNAME de forma natural

2. O naked domain possui restrições diferentes no DNS

3. WWW reduz o acoplamento com endereços IP

4. Migrações ficam mais simples

5. O naked domain pode ficar responsável somente pelo redirect

6. O naked domain continua disponível

7. Os dois hostnames precisam de alta disponibilidade

8. TLS acontece antes do redirect

9. Atenção aos certificados wildcard

10. WWW também cria uma fronteira arquitetural interessante para cookies

11. O problema dos cookies configurados para o domínio inteiro

12. O problema fica mais sério com serviços terceirizados

13. WWW não é uma solução mágica para cookies

14. Para sessões críticas, utilize __Host-

15. Subdomain Takeover torna cookies amplos ainda mais perigosos

16. Cookie Tossing e Cookie Injection

17. E quanto ao SEO? O que realmente merece atenção?

Conteúdo útil e original

Titles bem construídos

Meta descriptions úteis

Estrutura de conteúdo

Links internos

Sitemap XML

Canonical corretamente configurado

Robots e noindex

Performance e Core Web Vitals

Mobile

Dados estruturados

Imagens

Status HTTP corretos

Search Console e medição

Checklist: antes de retirar o WWW por SEO

Nossa recomendação

Conclusão

14. Para sessões críticas, utilize `__Host-`