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.

#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.

#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.

#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, com 404 ou fecho da 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.