O Google indexou o site no subdomínio errado: como limpar os resultados

A pergunta mais comum neste cenário é se deve pedir a remoção no Search Console ou esperar. Foi também uma das seis que um gestor de site publicou a 23 de outubro de 2026 no r/DoSEO e no r/TechSEO: o Google tinha indexado artigos do blogue num subdomínio FTP em vez do www, o programador removeu o subdomínio do servidor e os URLs continuavam nos resultados. John Mueller, da Google, respondeu ao fim de um quarto de hora. O mesmo acontece com staging., dev., um IP do servidor ou um subdomínio de uma configuração antiga, e a plataforma é indiferente: WordPress, Shopify com domínio próprio, um frontend headless ou um site estático.

A resposta curta: a remoção oculta, não resolve. O que resolve é aquilo que o nome antigo devolve quando o Google volta a passar por lá, mais os sinais do domínio principal. Todos os prazos deste artigo vêm da documentação do Google Search Central.

#Pedir a remoção no Search Console ou esperar

A ferramenta de remoções tem uma opção para ocultar todos os URLs com um prefixo. Introduza https://ftp.example.com/ e o anfitrião inteiro desaparece dos resultados. A ajuda do Google indica que um prefixo em staging não afeta o www nem o domínio sem www, e o guia de remoção de páginas diz que o pedido produz efeito em menos de um dia. Limites indicados na mesma página de ajuda:

• Um pedido dura cerca de seis meses. Depois disso, os URLs podem voltar se nada mais tiver mudado.
• A ferramenta oculta resultados, não impede o rastreio e não remove nada de forma definitiva. Definitivo é um 404 ou 410, uma palavra-passe ou noindex.
• Se o URL já devolver 404 ou 502/503 no momento do pedido, o Google assume que a página desapareceu e deixa o pedido expirar.
• O Google desaconselha usá-la para escolher a versão certa de um site, porque pode ocultar todas as versões de um URL. Num subdomínio separado a regra do prefixo limita o risco; entre www e sem www, não arrisque.

Vale a pena quando os URLs errados fazem estragos hoje: uma cópia de testes com preços fictícios, um anfitrião de desenvolvimento com páginas a meio, um IP visível nos resultados. Para um blogue duplicado em ftp. que vai receber 301 ou 404 de qualquer forma, Mueller resumiu:

Se os URLs já não funcionam, saem por si próprios.

(u/johnmu, r/TechSEO, 23 de outubro de 2026, tradução própria)

#Como verificar um subdomínio apagado no Search Console

A ferramenta de remoções e a inspeção de URLs só funcionam para URLs numa propriedade de que seja proprietário. A primeira frase de Mueller foi “verifique por DNS” (tradução própria), e há uma razão prática: um anfitrião que já não serve nada não pode alojar um ficheiro HTML de verificação. Uma propriedade de domínio é verificada com um registo DNS (TXT ou CNAME) e abrange todos os subdomínios e os protocolos http, https e ftp. Verifique example.com como propriedade de domínio e ftp.example.com, staging.example.com e qualquer subdomínio esquecido ficam incluídos, com ou sem servidor por trás. O relatório de páginas dessa propriedade mostra todos os anfitriões juntos, o que ajuda a encontrar outros nomes perdidos no índice.

#E se a cópia estiver num domínio que não é seu

Nem todos os anfitriões errados estão sob o seu domínio. Uma cópia de testes pode ficar num subdomínio da antiga agência ou do alojamento, e aí não consegue verificar uma propriedade de domínio nem usar a ferramenta de remoções. A ajuda do Google remete, para páginas que não controla, para a ferramenta de conteúdo desatualizado, pensada para quem não é proprietário do site. Segundo a mesma página, se a página já não existir, o resultado sai do índice; se só parte do conteúdo foi removida, o Google deixa de mostrar a página para essa parte. O proprietário vê esses pedidos num separador próprio da ferramenta.

A condição é a cópia ter desaparecido de facto. Se o anfitrião ainda serve o site inteiro, quem detém o domínio tem de o apagar, protegê-lo com palavra-passe ou acrescentar noindex. Peça-o por escrito, com a lista de URLs do teste com curl e o pedido de apagar também o registo DNS.

Os seus próprios pedidos na ferramenta de remoções podem ser cancelados a partir do histórico, que mostra os pedidos atuais e expirados dos últimos seis meses. É útil quando um prefixo apanhou mais páginas do que pretendia.

#O que devolve agora o subdomínio antigo

Antes de escolher, confirme o que o Google recebe. Uma das respostas no fio foi direta:

Verifique primeiro o que um URL HTTPS antigo devolve realmente agora: uma falha de DNS não é um 404.

(u/inevidimka, r/DoSEO, 23 de outubro de 2026, tradução própria)

dig +short ftp.example.com
curl -sI https://ftp.example.com/blog/artigo-exemplo

Se o dig não devolver nada, o nome já não resolve. Se devolver um IP, o curl mostra se recebe 200 com a página completa, 404 ou 410, um redirecionamento ou um erro TLS porque o certificado não cobre esse nome. Teste vários URLs que o Google mostra de facto. O guia de erros de DNS e de rede do Google usa o dig da mesma forma para verificar registos A, CNAME e NS.

A armadilha mais comum é apagar o anfitrião virtual e deixar o registo DNS. O servidor responde então com o site predefinido, quase sempre o mesmo do www, e o problema regressa.

#Um 404 ou 410 retira os URLs do Google

Sim. A documentação sobre códigos HTTP diz que URLs já indexados que devolvem 4xx são removidos do índice. Todos os 4xx exceto o 429 são tratados da mesma forma, por isso 404 e 410 têm o mesmo efeito, e a frequência de rastreio desses URLs vai diminuindo. Os erros de DNS, tempos esgotados e ligações interrompidas são tratados como erros 5xx, e o guia de DNS afirma que URLs indexados inacessíveis são removidos do índice em poucos dias.

Em ambos os casos é preciso que o Google volte ao URL. Um comentário no fio apontou um número:

O Google desindexa quando vê o erro 404. A desindexação pode demorar até 3 meses

(u/KindlyConnection4420, r/DoSEO, 23 de outubro de 2026, tradução própria)

O Google não publica esse prazo. É a experiência de uma pessoa, não uma regra.

#Porque é que o Google escolheu o subdomínio ftp

O autor da pergunta tinha feito a inspeção de URL. O endereço FTP estava indexado e a obtenção correu bem. O gémeo no www era desconhecido para o Google, sem sitemap nem página de referência. O pormenor que explica tudo:

O canónico declarado pelo utilizador apontava para o próprio URL FTP. O canónico escolhido pelo Google também era o URL FTP.

(u/Gullible-Winter294, r/DoSEO, 23 de outubro de 2026, tradução própria)

Um registo DNS (ftp, staging ou wildcard) aponta para o mesmo servidor que a produção. O servidor responde a esse nome com o site de produção, porque é o anfitrião virtual predefinido. E o modelo gera a etiqueta canonical a partir do nome do pedido, em vez de um URL base configurado, pelo que cada cópia se declara original. O Google fica com duas páginas iguais e escolhe uma.

#Redirecionar o subdomínio antigo com 301

Se os mesmos artigos existem no domínio principal, o redirecionamento página a página é a reparação melhor. Mueller apresentou-o como alternativa:

Em alternativa: altere o DNS para apontar para um site onde possa fazer um redirecionamento 301 de todos os URLs para o www e, opcionalmente, envie um pedido de mudança de endereço no Search Console.

(u/johnmu, r/TechSEO, 23 de outubro de 2026, tradução própria)

O guia de canonicalização classifica os redirecionamentos como sinal forte de que o destino deve ser o canónico, e o redirecionamento transporta as ligações que apontam para o anfitrião errado. O nome tem de resolver e ter um certificado válido, caso contrário o rastreador para no erro TLS. Envie cada URL para o seu par, não tudo para a página inicial. O guia de mudança de site recomenda manter os redirecionamentos, em geral, pelo menos um ano e indica que num site de dimensão média o Google pode levar algumas semanas ou mais a mostrar os novos URLs. A ferramenta de mudança de endereço exige pelo menos 180 dias.

#O WordPress, a Shopify ou o Cloudflare Pages redirecionam sozinhos um nome errado

Cada plataforma protege, em regra, contra um duplicado e deixa o resto consigo.

O WordPress só redireciona entre www e sem www. O código de redirect_canonical() tem o comentário “Only redirect no-www <=> yes-www” e, para qualquer outro nome, mantém o anfitrião pedido. Um pedido a ftp.example.com devolve a página, não um redirecionamento. A etiqueta canonical vem de wp_get_canonical_url(), que chama get_permalink() e segue o endereço do site definido nas opções. Se uma cópia em WordPress declara o anfitrião ftp como canónico, procure em wp-config.php as constantes WP_HOME ou WP_SITEURL construídas a partir de $_SERVER['HTTP_HOST'], ou um plugin que reescreva o canonical. Desde o WordPress 5.3, a opção que desencoraja os motores de pesquisa escreve uma meta etiqueta noindex em vez de Disallow: / no robots.txt, segundo a nota de desenvolvimento do core, que aponta um cabeçalho HTTP como o método mais eficaz para sites de desenvolvimento.

A Shopify permite escolher o domínio que os clientes veem e redirecionar todos os outros para ele na página de domínios da administração. Um domínio ou subdomínio extra sem essa opção é um anfitrião duplicado.

O Cloudflare Pages acrescenta por predefinição X-Robots-Tag: noindex a cada implementação de pré-visualização. O endereço de produção <projeto>.pages.dev é outro anfitrião, e o guia da Cloudflare para redirecionar pages.dev para um domínio próprio usa um Bulk Redirect com estado 301 e preservação do caminho, ou seja, redirecionamento página a página.

O Astro gera os URLs canónicos e o sitemap a partir da opção site em astro.config.mjs. O Next.js compõe os URLs relativos dos metadados, incluindo alternates.canonical, com metadataBase, e um URL relativo sem metadataBase dá erro de compilação. Nos dois casos, o endereço de produção fixo na configuração impede que uma cópia se declare canónica.

#Bloquear o subdomínio antigo no robots.txt piora a situação

A documentação sobre noindex diz que uma página bloqueada no robots.txt não é obtida, a regra noindex nunca é lida e a página pode continuar nos resultados. O guia de canonicalização acrescenta que o Google pode indexar URLs bloqueados sem o conteúdo. Deixe o anfitrião acessível até o 301, o 404 ou o noindex serem lidos.

#Como indexar os URLs do domínio principal

• Gere o canonical a partir de um URL base configurado, para que as páginas do www declarem sempre o www.
• Inclua os URLs do domínio principal no sitemap enviado na propriedade de produção. O Google chama-lhe sinal fraco, mas os sinais somam-se.
• Confirme que ligações internas, hreflang e URLs Open Graph usam o anfitrião principal.
• Faça um teste em direto de alguns URLs do www na inspeção de URL e peça a indexação dos mais importantes.

Se o anfitrião errado surgiu depois de uma mudança de plataforma, o nosso serviço de migração e o artigo sobre porque o Google reverte migrações de domínio tratam do mapa de redirecionamentos. O guia da Search Console e da Indexing API explica o relatório de páginas para acompanhar a evolução.

#Que estados do relatório de páginas vai ver durante a limpeza

O relatório de indexação de páginas na propriedade de domínio mostra os dois anfitriões lado a lado. O significado de cada estado vem da documentação do relatório; os nomes ficam em inglês, como aparecem em muitas contas.

A mesma página indica que o teste em direto da inspeção de URL segue redirecionamentos e testa o URL final sem o dizer. Testar um URL ftp antigo mostra o resultado do www e pode parecer que o redirecionamento não fez nada.

#Tabela de decisão: o que fazer em cada caso

#Como evitar que ambientes de teste apareçam no Google

• Palavra-passe em tudo o que não é produção. O guia para controlar o que partilha diz que a proteção por palavra-passe mantém o conteúdo fora da pesquisa e acaba por removê-lo se já aparecer.
• Cabeçalho X-Robots-Tag: noindex nos anfitriões de teste. A especificação do X-Robots-Tag permite a regra como cabeçalho HTTP, que cobre também PDF e imagens. Defina-o na configuração do servidor para esse nome, não na aplicação, para que uma cópia da base de dados de testes para produção não o leve consigo.
• Apague o registo DNS quando apagar o anfitrião. Um CNAME para um serviço que já não usa é o cenário clássico de tomada de subdomínio: a MDN descreve um atacante a reclamar o nome abandonado no fornecedor e a publicar conteúdo próprio no seu subdomínio.
• Evite DNS wildcard sem necessidade. A documentação da Cloudflare explica que * responde por qualquer nome sem registo próprio. Com um anfitrião virtual predefinido, qualquer gralha num subdomínio serve o seu site.
• Configure o anfitrião predefinido para rejeitar nomes desconhecidos. O nginx envia um pedido cujo Host não corresponde a nenhum server_name para o servidor predefinido dessa porta, que é o primeiro bloco se nenhum tiver default_server, como explica o guia de processamento de pedidos. O Apache usa o primeiro anfitrião virtual da lista, segundo a documentação de anfitriões por nome.

Uma configuração nginx em que nomes desconhecidos recebem a ligação fechada e o anfitrião de testes tem palavra-passe e noindex:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_reject_handshake on;   # nginx 1.19.4+, recusa TLS para nomes desconhecidos
    return 444;                # fecha a ligação sem resposta
}

server {
    listen 443 ssl;
    server_name staging.example.com;
    # aqui ssl_certificate e ssl_certificate_key para este nome
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
    add_header X-Robots-Tag "noindex" always;
}

O parâmetro always faz a diferença. A documentação do módulo de cabeçalhos diz que, sem ele, add_header só se aplica a respostas 200, 201, 204, 206, 301, 302, 303, 304, 307 e 308, pelo que a resposta 401 da autenticação sairia sem noindex. O ssl_reject_handshake exige nginx 1.19.4 ou posterior, e o código 444 é a forma própria do nginx de fechar a ligação.

A configuração de servidor para palavra-passe e cabeçalho noindex está no nosso guia de fluxo de staging. Uma verificação do site inclui a revisão de registos DNS e anfitriões indexados, e a manutenção contínua mantém essa lista atualizada depois de cada mudança de servidor ou de agência.