Nome de host abaixo de um domínio principal, como docs.example.com, que pode ter uma finalidade técnica ou de conteúdo própria e precisa ser planejado como parte da arquitetura geral do site.
A decisão e seus limites
Um subdomínio é um nome de host abaixo de outro nome de domínio, por exemplo docs.example.com abaixo de example.com. Tecnicamente, ele pode ter aplicação, roteamento, cookies, configuração de DNS e presença própria nas buscas. Essa flexibilidade não resolve a questão de arquitetura da informação. A escolha entre subdomínio e subdiretório deve seguir a responsabilidade operacional, os limites do produto, as necessidades de localização ou de plataforma e a jornada do usuário — não um suposto bônus de SEO.
O que inspecionar
Mapeie cada nome de host, sua finalidade, o responsável, o host canônico, o estado do TLS, as regras do robots, o sitemap, a identificação no analytics e os caminhos de links internos. Rastreie páginas representativas atravessando a fronteira e confira se os links apontam diretamente para as rotas canônicas pretendidas. Durante uma migração, mantenha um mapa no nível da URL e teste cada destino, em vez de supor que o roteamento por host inteiro basta.
Um caminho prático de implementação
Use um subdomínio quando ele criar uma fronteira estável e compreensível, como documentação, um app ou uma plataforma separada por região. Dê a ele navegação e política de indexação próprias, mantendo links contextuais para a experiência do domínio principal. Se o conteúdo for movido entre nomes de host, configure redirecionamentos permanentes diretos quando fizer sentido, atualize as tags canonical e as referências no sitemap, e valide a renderização e a medição dos dois lados.
Erros comuns e limites da medição
O atalho arriscado é criar um subdomínio apenas para isolar um trabalho de SEO ou conteúdo duplicado. Isso pode fragmentar a responsabilidade e dificultar as correções em todo o site. Não afirme que um subdomínio herda ou perde autoridade automaticamente; avalie os links, o conteúdo, a acessibilidade e a implementação real da migração.
Exemplo prático de arquitetura. Uma empresa pode colocar a documentação do produto em docs.example.com porque uma plataforma e uma equipe de documentação separadas são responsáveis por ela, enquanto um app voltado ao cliente fica em app.example.com. Isso pode ser uma fronteira coerente se navegação, expectativas de conta, política de busca e responsabilidade estiverem claras. Mover uma pasta de marketing para um subdomínio só porque ela usa outro template é um motivo bem mais fraco. Documente a jornada do usuário entre os hosts antes de escolher o nome de host.
Critérios de verificação. Mantenha um inventário de hosts com finalidade, responsável principal, host público canônico, sitemap, política do robots, cobertura de TLS, escopo do analytics e rotas de entrada principais. Rastreie páginas representativas do domínio principal para o subdomínio e de volta, verificando links internos diretos, comportamento dos redirecionamentos e caminhos no rodapé ou na navegação. Em uma migração, teste os pares de URLs antigos e novos, não apenas a raiz do host. Verifique as jornadas no navegador e no celular se houver cookies, login ou transferência para um app.
Erros comuns. Não duplique o mesmo conteúdo entre o host raiz e o subdomínio sem uma decisão explícita de canonical ou de migração. Não presuma que os sistemas de busca tratam todos os nomes de host como um só site nem como sites totalmente não relacionados; verifique a estrutura real de links e URLs. Uma mudança de nome de host afeta operações, analytics e a confiança do usuário, não só o SEO, por isso precisa de um plano de reversão no nível da rota.