SEO de Migração de Hospedagem de Sites

TL;DR — Uma migração de hospedagem muda a infraestrutura por trás do seu site enquanto os visitantes continuam usando as mesmas URLs. Construa e teste o novo host primeiro, reduza o tempo de vida (TTL) do DNS antes do lançamento, mantenha o host antigo ativo durante a troca e compare o que ambos os sistemas retornam. Observe DNS, certificados, códigos de status, conteúdo, velocidade e acesso do rastreador. Desligue o host antigo somente depois que seus logs mostrarem que o tráfego chegou a zero.

O que é uma migração de hospedagem?

Uma migração de hospedagem muda onde ou como um site é servido sem alterar as URLs que as pessoas veem. Mudar para uma empresa de hospedagem diferente é um exemplo. Adicionar ou substituir uma rede de entrega de conteúdo (CDN), alterar um servidor de origem ou trocar provedores de DNS pode fazer parte do mesmo projeto.

A URL permanecer a mesma é a condição definidora. https://example.com/page/ devem permanecer https://example.com/page/ antes e depois da mudança.

O Google trata isso como uma mudança de site sem alterações de URL. Se o domínio, protocolo, hostname ou caminho mudar, use o processo completo de migrações de site em vez disso. Você pode estar fazendo duas migrações ao mesmo tempo.

Por que uma mudança de URL igual pode afetar o SEO?

Uma migração de hospedagem pode mudar tudo por trás de um endereço estável. Os mecanismos de busca podem encontrar um código de resposta diferente, servidor mais lento, certificado expirado, desafio de firewall, página em cache desatualizada, imagem quebrada, cabeçalho ausente ou página renderizada.

A mudança mais segura preserva a resposta observável enquanto substitui a infraestrutura. Usuários e rastreadores devem receber a mesma página bem-sucedida do novo sistema que recebiam do antigo.

Quais são os passos básicos?

1. Copie ou conecte o site à nova infraestrutura.
2. Teste a nova origem e CDN sem alterar o DNS público.
3. Reduza o TTL do DNS com antecedência para que a mudança eventual se propague mais rápido.
4. Confirme certificados, cache, regras de segurança e acesso do rastreador.
5. Altere o DNS para enviar tráfego para a nova infraestrutura.
6. Mantenha ambos os ambientes online enquanto os caches de DNS expiram.
7. Monitore logs, erros, velocidade, rastreamento e desempenho de pesquisa.
8. Desligue o host antigo somente quando seus logs não mostrarem tráfego restante.

O Google recomenda essa mesma sequência de preparar, trocar, monitorar e desligar em sua documentação sobre mudança de hospedagem.

O que o TTL do DNS faz?

O TTL do DNS controla por quanto tempo um resolvedor pode armazenar em cache uma resposta DNS. Um TTL mais baixo antes da mudança permite que registros alterados expirem dos caches mais cedo. Isso não faz todos os resolvedores mudarem instantaneamente, e reduzir o TTL no lançamento é tarde demais para caches que mantêm o valor antigo.

O Google sugere reduzir o TTL para um valor baixo conservador, como algumas horas, pelo menos uma semana antes da mudança. Trate isso como um exemplo, não um número universal; seu provedor de DNS e requisitos operacionais decidem o valor exato.

Você precisa de redirecionamentos?

Uma verdadeira migração de hospedagem não precisa de redirecionamentos de SEO porque as URLs públicas não mudam. Adicionar redirecionamentos abrangentes durante uma mudança apenas de host cria novos modos de falha sem resolver o problema de infraestrutura.

Os redirecionamentos existentes ainda precisam se comportar exatamente como antes. Teste-os na nova pilha, incluindo regras legadas antigas que podem estar no servidor web atual, CMS, balanceador de carga ou CDN.

Quando a mudança está completa?

A mudança de hospedagem está completa quando a nova infraestrutura serve as respostas pretendidas consistentemente e a infraestrutura antiga não recebe mais tráfego real de usuários ou rastreadores. O Google recomenda explicitamente verificar os logs do provedor antigo e desligá-lo somente depois que o tráfego chegar a zero.

TL;DR — Trate uma migração de hospedagem, CDN ou DNS com URLs idênticas como um projeto de paridade de resposta e roteamento de tráfego. Inventarie cada hostname e dependência, reduza o TTL do DNS antes do lançamento, configure a nova origem e a borda, valide certificados e controles de segurança, teste de carga com demanda realista de crawlers e usuários e compare respostas brutas e renderizadas. Execute em paralelo a infraestrutura antiga e a nova durante a propagação do DNS. Monitore ambos os fluxos de logs, respostas de DNS, erros, latência, comportamento de cache, atividade de rastreamento e o Search Console. Faça rollback restaurando o roteamento anterior somente quando ocorrer uma falha de infraestrutura pré-acordada.

Decida se esta é realmente uma migração com URLs idênticas

Uma migração de hospedagem com URLs idênticas altera a infraestrutura sem mudar a string exata da URL pública. O esquema, hostname, porta, caminho, tratamento de query e o comportamento da barra final permanecem estáveis.

Classifique o projeto antes de planejá-lo:

Não deixe um gerente de projeto rotular uma mudança de URL como “apenas hospedagem.” O plano de implantação deve incluir todos os tipos de migração que realmente serão enviados.

Construa o inventário de infraestrutura

O inventário de infraestrutura evita que dependências silenciosas se tornem surpresas no dia do lançamento. Registre:

• todos os hostnames públicos, incluindo ativos, imagens, APIs, hosts internacionais e aliases legados;
• registros A, AAAA, CNAME, NS, SOA, CAA, MX, TXT e SRV relevantes;
• emissores de certificados, métodos de validação, Subject Alternative Names e expiração;
• endereços de origem, portas, health checks, balanceadores de carga e comportamento de failover;
• chaves de cache da CDN, regras de cache, redirecionamentos, transformações, workers e métodos de purge;
• regras de WAF, bot, rate-limit, geo, autenticação e allow/deny de IP;
• cabeçalhos de resposta, compressão, comportamento de cookies e cabeçalhos de segurança;
• destinos de logs, retenção, amostragem, campos e fusos horários;
• métodos de verificação do Search Console e de analytics;
• callbacks de terceiros, webhooks, fluxos de pagamento, feeds e IPs na allowlist.

A revisão de DNS deve incluir registros não relacionados à web. Quebrar registros MX, SPF, DKIM, DMARC ou de serviço pode não mudar diretamente o ranqueamento, mas pode quebrar o negócio que você estava tentando proteger.

Estabeleça uma linha de base de paridade de resposta

Paridade de resposta significa comparar os sistemas antigo e novo para a mesma URL solicitada, não apenas verificar se ambos retornam 200.

Capture um conjunto representativo entre templates e comportamentos:

• status e cadeia de redirecionamento;
• URL final e negociação de protocolo;
• título, canonical, diretivas de robots, hreflang e dados estruturados;
• HTML bruto e conteúdo principal renderizado pelo navegador;
• Content-Type, Cache-Control, Vary, compressão e cabeçalhos de segurança;
• imagens, fontes, JavaScript, CSS, PDFs e ativos de mídia;
• cookies e variantes logadas ou personalizadas;
• comportamento mobile e desktop;
• latência, time to first byte e taxa de erro.

Use o Staging vs. Production SEO Diff para verificações de páginas pareadas. Um crawler completo e uma suíte de requisições com script devem cobrir o inventário maior.

Prepare a nova origem

A preparação da origem começa com paridade de conteúdo e configuração. Copie o conteúdo atual, modelos, mídia, regras de robots, redirecionamentos, tratamento de erros e arquivos de verificação. Congele ou sincronize gravações para que o novo banco de dados não seja lançado com dados desatualizados.

Teste a origem diretamente por meio de um hostname controlado, uma substituição local do arquivo hosts ou um mecanismo de pré-visualização específico do provedor. O teste deve preservar o cabeçalho Host de produção, pois hosts virtuais, roteamento de aplicativos, certificados, canônicos e links absolutos geralmente dependem dele.

A nova origem também deve lidar com a carga pós-migração. Aqueça o aplicativo e o banco de dados, confirme os pools de conexão e o autoscaling e teste a demanda não armazenada em cache. As falhas de cache do CDN podem concentrar tráfego na origem imediatamente após o lançamento.

Configure o CDN como um sistema separado

A migração de CDN muda mais do que a geografia. Compare o comportamento antigo e o novo da borda explicitamente:

• composição da chave de cache, incluindo query strings, cookies, cabeçalhos e variantes de dispositivo;
• códigos de status e tipos de arquivo armazenáveis em cache;
• TTL do navegador, TTL da borda, serviço de conteúdo obsoleto, revalidação e proteção da origem;
• redirecionamentos, reescritas, transformações de cabeçalho e funções de borda;
• regras de bypass de cache para contas, carrinhos, busca e páginas personalizadas;
• compressão e otimização de imagens;
• escopo e propagação de purga;
• WAF, gerenciamento de bots, limitação de taxa e proteção da origem.

A documentação atual da Cloudflare, por exemplo, observa que seu cache padrão pode respeitar os cabeçalhos Cache-Control da origem, mas pode ser substituído por regras de borda. Ela também fornece purgas direcionadas ou completas para forçar buscas novas na origem. O comportamento exato é específico do fornecedor, então exporte e compare a configuração em vez de assumir que rótulos equivalentes significam resultados equivalentes. Consulte a documentação de cache da Cloudflare.

Trate a paridade de cache como paridade de conteúdo

A configuração de cache pode servir a página errada de forma correta e rápida. Teste variantes anônimas, autenticadas, localizadas, móveis e de query string. Uma chave de cache que omite um cookie ou cabeçalho significativo pode vazar conteúdo personalizado. Uma chave de cache que inclui todos os parâmetros de rastreamento pode fragmentar o cache e sobrecarregar a origem.

Purgue ou pré-aqueça ativos e páginas críticos de acordo com o plano de lançamento. Não purgue tudo cegamente durante o pico de tráfego, a menos que a origem tenha sido testada para a tempestade de falhas resultante.

Valide o TLS do usuário até a borda e da borda até a origem

A validação de TLS tem duas pernas quando um CDN encerra HTTPS: navegador para CDN e CDN para origem. Confirme a cobertura de hostname, cadeias de certificados completas, suporte a protocolos modernos, renovação e validação estrita da origem.

Certificados somente de origem podem não ser publicamente confiáveis. A Cloudflare alerta que seus certificados Origin CA podem produzir erros de confiança no navegador se o proxy estiver desabilitado ou pausado. Isso importa durante o rollback: um fallback somente DNS para uma origem que usa um modelo de confiança somente de borda pode falhar para os usuários. Consulte a orientação sobre Origin CA da Cloudflare.

Teste cada hostname público, incluindo suposições de curinga e hosts de ativos ou regionais raramente usados. Um certificado de apex válido não prova que todos os subdomínios estão cobertos.

Reduza o TTL do DNS antes da mudança

O planejamento de TTL começa antes da migração. O Google recomenda reduzir o TTL relevante para um valor baixo conservador, como algumas horas, pelo menos uma semana antes da mudança. Um provedor de DNS pode impor mínimos diferentes; registros com proxy também podem ter valores fixos.

A documentação de TTL da Cloudflare explica a troca básica: valores mais longos aumentam a reutilização de cache, enquanto valores mais curtos permitem que as alterações de registro entrem em vigor mais cedo. Registre o TTL original e agende sua restauração somente depois que a nova infraestrutura estiver estável.

As alterações de DNS podem não ser atômicas em sistemas distribuídos. Altere o mínimo possível durante a troca, verifique as respostas de vários resolvedores públicos e mantenha o destino antigo disponível enquanto as respostas em cache permanecerem válidas.

Verifique o acesso do crawler e os controles de segurança

Paridade de segurança não é paridade de número de regras. Um WAF copiado de outro provedor pode desafiar ou bloquear crawlers, remover parâmetros de consulta, reescrever respostas ou limitar a taxa de rastreamento de alto volume de forma diferente.

O guia de hospedagem do Google diz para garantir que firewalls e proteção contra negação de serviço não bloqueiem o Googlebot dos servidores de DNS ou de hospedagem. Verifique o Googlebot usando os métodos de verificação documentados do Google, não apenas uma string de user-agent.

Teste tanto o comportamento comum do crawler quanto picos legítimos. Evite allowlists amplas que desativem a proteção para user agents falsificados. Preserve os logs de segurança para que solicitações bloqueadas possam ser distinguidas de falhas de origem.

Planeje a execução dupla

Execução dupla significa que tanto a infraestrutura antiga quanto a nova podem servir respostas corretas de produção durante a propagação. O ambiente antigo deve continuar recebendo alterações de conteúdo ou dados que afetem o site. Caso contrário, usuários direcionados por respostas DNS em cache podem ver inventários desatualizados, sessões quebradas ou páginas desatualizadas.

Escolha uma estratégia de sincronização:

• um banco de dados de leitura/gravação compartilhado por ambas as pilhas;
• dados replicados com uma política de atraso e conflito compreendida;
• um congelamento controlado de conteúdo durante a troca;
• replicação de eventos unidirecional para pedidos, formulários ou gravações de usuários.

Estado de sessão, uploads, invalidações de cache e trabalhos em segundo plano precisam da mesma decisão. “Ambos os servidores estão ligados” não é um plano de execução dupla se seus estados divergirem.

Execute a troca

A troca de hospedagem deve ser deliberadamente entediante:

1. Pare implantações não relacionadas e confirme a janela de alteração.
2. Execute as verificações finais de paridade, certificado, capacidade e backup.
3. Remova bloqueios temporários de rastreamento ou acesso do novo caminho de produção.
4. Altere apenas os registros de roteamento DNS ou CDN planejados.
5. Confirme as respostas esperadas de vários resolvedores.
6. Solicite páginas protegidas pela rota pública como usuário e crawler.
7. Confirme que os logs estão chegando da borda, da nova origem e da origem antiga.
8. Observe erros, latência, falhas de cache, carga de origem e conversões.

Não use a ferramenta de mudança de endereço do Google para uma mudança apenas de hospedagem. Nenhuma URL pública mudou, então não há mudança de endereço a relatar.

Monitore as evidências que comprovam a mudança

O monitoramento de infraestrutura deve separar o tráfego antigo do novo. Use um marcador de implantação e compare a mesma linha de base de horário da semana onde a sazonalidade importa.

Observe:

• respostas DNS e propagação de resolvedores;
• solicitações de host antigo e novo por usuário e crawler verificado;
• distribuição de códigos de status na borda e na origem;
• erros de TLS, conexão, tempo limite e aplicação;
• percentis de latência e tempo de resposta de origem sem cache;
• taxa de acerto de cache e volume de solicitações de origem;
• solicitações do Googlebot, estatísticas de rastreamento, indexação de páginas e inspeção de URL representativa;
• verificações sintéticas em regiões e redes;
• análises, conversões e transações comerciais críticas.

O Google diz que uma queda temporária na taxa de rastreamento do Googlebot imediatamente após uma mudança de hospedagem pode ser normal, seguida por um aumento nos próximos dias. Baseie qualquer decisão em evidências de acessibilidade e erros, não apenas nesse padrão esperado.

Defina o rollback antes do lançamento

Rollback retorna o roteamento a um estado de infraestrutura conhecido e bom. Não é uma vaga promessa de “mudar o DNS de volta.” Documente:

• os registros, rotas e configurações exatos a restaurar;
• quem pode autorizar e executar a reversão;
• como conteúdo alterado, sessões, formulários, pedidos e uploads serão reconciliados;
• se os certificados e dependências antigos permanecem válidos;
• etapas de limpeza de cache em ambas as rotas;
• os limites de falha que acionam o rollback;
• o tempo máximo seguro de decisão.

Os gatilhos de rollback devem ser observáveis: falhas sustentadas de disponibilidade, quebra material de conversão, conteúdo incorreto generalizado, falhas de certificado, bloqueios de crawlers ou colapso de capacidade que não possa ser corrigido dentro da janela. Uma flutuação temporária na taxa de rastreamento por si só não é um gatilho de rollback.

Aposente a infraestrutura antiga com base em logs, não em um calendário

A aposentadoria do host antigo ocorre depois que os logs mostram que usuários e crawlers não o acessam mais e que todos os serviços dependentes foram migrados. O Google recomenda desligar o host antigo depois que o tráfego dele chegar a zero.

Mantenha exportações de configuração, logs e artefatos de rollback de acordo com os requisitos de negócio. Restaure o TTL do DNS para o valor de estado estável pretendido depois que a estabilidade for comprovada. Remova exceções temporárias de firewall e jobs agendados duplicados para que a migração não deixe uma bagunça permanente de manutenção.

Resumo de IA

• Uma migração de hospedagem altera servidores, CDN, origem ou DNS enquanto as URLs públicas permanecem idênticas.
• Mudanças de URL exigem o processo mais amplo de mudança de site. Uma mudança apenas de host não precisa de novo mapa de redirecionamentos nem de envio de Change of Address.
• Faça um inventário de DNS, TLS, origem, CDN, WAF, cache, logs, verificação, ativos e dependências de negócio antes do lançamento.
• Reduza o TTL do DNS antes da troca, mantenha o valor antigo e restaure-o depois que o novo caminho estiver estável.
• Compare respostas brutas antigas e novas, páginas renderizadas, cabeçalhos, ativos, redirecionamentos, códigos de status, latência e comportamento de negócio.
• Valide o TLS do navegador até a borda e da borda até a origem, além dos certificados em qualquer caminho de rollback.
• Execute os dois ambientes em paralelo e sincronize as gravações até que as respostas de DNS em cache não enviem mais tráfego para a pilha antiga.
• Monitore os dois fluxos de logs, respostas de DNS, erros, carga da origem, comportamento do cache, acesso verificado de crawlers, Search Console e conversões.
• Aposente o host antigo somente quando os logs dele mostrarem que o tráfego chegou a zero.

Documentação oficial

Google

• Changing your web hosting and SEO explica o processo de preparação com a mesma URL, troca de DNS, monitoramento e desligamento.
• Site moves with URL changes se aplica quando esquema, nome do host ou caminho também mudam.
• Verify Googlebot documenta a verificação por DNS reverso/direto e por IPs publicados.
• Crawl Stats report ajuda a monitorar as solicitações do Googlebot e a disponibilidade do host.

Referências de infraestrutura

• Cloudflare DNS TTL explica as compensações de TTL e propagação.
• Cloudflare cache documenta cache de borda, regras de cache e purga.
• Cloudflare Origin CA documenta certificados de borda até a origem e a limitação de confiança do navegador.

Citações da fonte

• “This guide is only for migrations that don’t affect the user-visible URL.” (tradução) «Este guia é apenas para migrações que não afetam a URL visível ao usuário.» Google Search Central. Ir para o guia de hospedagem
• Paráfrase: O Google recomenda reduzir o TTL do DNS antes da mudança, garantir que os firewalls ainda permitam o tráfego verificado do Googlebot, esperar uma queda temporária na taxa de rastreamento e manter o host antigo disponível até que seu tráfego termine. Orientação sobre TTL, orientação sobre firewall, orientação sobre taxa de rastreamento, e orientação sobre desligamento.

Lista de verificação para migração de hospedagem

Escopo e linha de base

• Confirmado que nenhuma URL pública será alterada.
• Inventariados todos os hostnames web, de ativos, de API e regionais.
• Exportadas as configurações de DNS, CDN, WAF, cache, redirecionamentos, TLS e origem.
• Salvas as linhas de base representativas de respostas brutas e renderizadas.
• Registradas as linhas de base de tráfego, erros, latência, rastreamento, indexação e conversões.

Nova infraestrutura

• Sincronizados conteúdo atual, mídia, redirecionamentos, regras de robots e arquivos de verificação.
• Testado o roteamento por cabeçalho Host e cada hostname público.
• Validados os certificados de navegador para borda e de borda para origem.
• Correspondidas chaves de cache, bypass, TTLs, cookies, transformações e comportamento de purga.
• Correspondidos comportamentos de WAF, bot, limite de taxa e acesso à origem.
• Testados sob carga os erros de cache, dependências de aplicação e capacidade do banco de dados.
• Confirmado que os logs de borda, origem, aplicação e segurança são retidos e pesquisáveis.

DNS e lançamento

• Reduzidos os TTLs relevantes antes da mudança e registrados os valores originais.
• Preservados registros não web, DNSSEC, verificação e dependências de serviço.
• Documentados o comando exato de mudança de roteamento e os comandos de reversão.
• Mantidas as infraestruturas antiga e nova ativas com um plano de sincronização de dados.
• Removidos todos os bloqueios temporários de rastreamento ou acesso no caminho de produção.
• Verificadas as respostas de DNS por meio de vários resolvedores independentes.

Após o lançamento

• Comparados status, conteúdo, cabeçalhos, renderização, ativos e redirecionamentos em produção.
• Confirmado que usuários e rastreadores verificados não são desafiados ou bloqueados.
• Observados logs antigos/novos, erros, latência, erros de cache, carga de origem e conversões.
• Verificados os resultados de Estatísticas de rastreamento, Indexação de páginas e Inspeção de URL representativa.
• Restaurado o TTL de estado estável somente após a estabilidade ser comprovada.
• Desativado o host antigo somente após seu tráfego chegar a zero.

A estrutura de paridade em cinco camadas

O modelo de estados da migração

Preparado significa que a nova pilha passa nos testes de paridade e de carga. Alternando significa que as respostas de DNS e as solicitações estão divididas. Estabilizando significa que a nova pilha atende a quase todo o tráfego enquanto a pilha antiga permanece disponível. Concluído significa que o tráfego do host antigo chega a zero e todas as dependências são desativadas ou transferidas.

Não considere o projeto concluído quando o “DNS mudou”. Esse é o início da alternância, não o fim da migração.

Qual plano de migração se aplica?

Falhas comuns em migrações de hospedagem

Algumas regiões ainda alcançam o host antigo

Causa provável: respostas de DNS em cache, comportamento do resolvedor ou registros que não foram alterados de forma consistente. Correção: compare as respostas autoritativas com vários resolvedores públicos, mantenha o host antigo servindo conteúdo atual e inspecione os TTLs em vez de forçar alterações repetidas.

As solicitações do Googlebot caem após o lançamento

Causa provável: um ajuste normal de curto prazo na taxa de rastreamento, um desafio de firewall, falha de DNS, latência ou erros de servidor. Correção: verifique o Crawl Stats e os logs de acesso de bots verificados. A queda documentada de curto prazo do Google não é motivo para ignorar falhas reais de acesso.

As páginas são rápidas, mas mostram conteúdo desatualizado

Causa provável: um TTL de borda, chave de cache, falha de purga ou fonte de dados divergente. Correção: inspecione os cabeçalhos Age, Cache-Control, Vary e os cabeçalhos de status de cache do provedor; teste variantes significativas; faça purgas direcionadas; depois verifique a origem e a borda separadamente.

O site funciona pelo CDN, mas falha quando é contornado

Causa provável: confiança no certificado de origem, roteamento por cabeçalho Host, listas de permissão de firewall ou uma dependência ausente de origem direta. Correção: valide o caminho pretendido de borda para origem e o caminho de reversão documentado. Não exponha uma origem privada apenas para fazer um teste de contorno não planejado passar.

Os ativos falham enquanto o HTML funciona

Causa provável: nomes de host de ativos omitidos, CORS, certificados, URLs absolutas, regras de cache, proteção contra hotlink ou permissões de origem. Correção: rastreie e teste no navegador o inventário de ativos, incluindo fontes, imagens, CSS, JavaScript, PDFs e mídia.

O pico de carga na origem é imediato

Causa provável: caches frios, chave de cache alterada, cache contornado, shielding ausente ou tráfego de bots alcançando a origem diretamente. Correção: restaure as regras de cache pretendidas, aqueça objetos de alto valor com cuidado e adicione capacidade. Faça a reversão se falhas sustentadas ultrapassarem o limite acordado.

Ferramentas para uma mudança de infraestrutura com a mesma URL

• DNS Checker compara tipos de registros comuns por meio de vários resolvedores públicos. Use-o durante a propagação, mas compare o resultado com a zona autoritativa também.
• HTTP Header Checker mostra cabeçalhos em redirecionamentos, incluindo impressões digitais de CDN, compactação, segurança e controles de cache.
• Staging vs. Production SEO Diff compara URLs pareadas em status, canônicos, diretivas, cabeçalhos selecionados, schema e conteúdo.
• Bulk HTTP Status Code Checker verifica status, redirecionamentos, destino e latência em um conjunto representativo de URLs.
• Google Index Checker verifica bloqueadores observáveis de rastreamento e indexabilidade e, em seguida, aponta para o Search Console para a visão do próprio Google.
• Logs de servidor e de borda comprovam para onde o tráfego foi, qual resposta recebeu e quando a infraestrutura antiga está genuinamente sem uso.
• Monitoramento sintético testa a disponibilidade pública e transações críticas de várias redes e regiões.

Prove que a migração de hospedagem funcionou

Teste de propagação de DNS e drenagem do host antigo

• Teste a executar: Consulte o DNS autoritativo e vários resolvedores públicos e, em seguida, faça um gráfico do volume de solicitações na infraestrutura antiga e na nova.
• Resultado esperado: As respostas públicas convergem para a rota pretendida enquanto o tráfego do host antigo diminui para zero.
• Interpretação de falha: Registros inconsistentes, respostas em cache ou nomes de host não rastreados ainda estão roteando tráfego para outro lugar.
• Janela de monitoramento: Do corte até pelo menos o TTL relevante anterior mais longo e até que os logs do host antigo permaneçam em zero.
• Gatilho de reversão: Regiões materiais não conseguem resolver ou alcançar o novo serviço e o problema não pode ser corrigido dentro da janela de recuperação.

Teste de paridade de resposta

• Teste a executar: Compare a linha de base com a produção usando o Staging vs. Production SEO Diff, um rastreador e testes de navegador renderizados.
• Resultado esperado: Status pretendido, canônicos, regras de robots, conteúdo, dados estruturados, links internos, ativos e cabeçalhos são preservados.
• Interpretação de falha: A nova origem, borda ou configuração do aplicativo alterou uma resposta visível para a pesquisa, apesar das URLs estáveis.
• Janela de monitoramento: Imediatamente antes e depois do corte e, em seguida, após cada correção de lançamento.
• Gatilho de reversão: Uma falha de indexabilidade, canônico, conteúdo ou ativo em todo o site afeta modelos protegidos e não pode ser corrigida a quente com segurança.

Teste de acesso e capacidade do rastreador

• Teste a executar: Inspecione logs de rastreador verificados, estatísticas de rastreamento do Search Console, latência da origem, taxas de erro e resultados de teste de carga sem cache.
• Resultado esperado: Rastreadores verificados recebem respostas bem-sucedidas sem desafios, enquanto a origem permanece dentro do envelope de capacidade estabelecido.
• Interpretação de falha: WAF, DNS, TLS, limitação de taxa ou capacidade da origem está impedindo o rastreamento confiável.
• Janela de monitoramento: Contínua durante o lançamento e os primeiros dias de estabilização da taxa de rastreamento.
• Gatilho de reversão: Falhas sustentadas de rastreadores e usuários excedem o limite de erro ou disponibilidade aprovado.

Teste de segurança de cache

• Teste a executar: Solicite variantes anônimas, autenticadas, localizadas, móveis e de consulta enquanto inspeciona chaves de cache e cabeçalhos de resposta.
• Resultado esperado: O conteúdo público é armazenado em cache conforme projetado; respostas privadas ou personalizadas não são compartilhadas; variantes significativas permanecem distintas.
• Interpretação de falha: Regras de chave de cache ou de bypass podem servir conteúdo incorreto ou sobrecarregar a origem.
• Janela de monitoramento: Antes do lançamento, imediatamente após o corte e após qualquer alteração de regra de cache ou de purga.
• Gatilho de reversão: Dados personalizados são expostos, conteúdo obsoleto generalizado é servido ou a origem não consegue sustentar a taxa de falta.

Recursos que valem seu tempo

Meus textos relacionados

• A Website Migration Takes More Than a Checklist to Be Successful covers the broader migration process, baselines, staging, and monitoring.
• Redirects for SEO explains the legacy redirect behavior that must survive an infrastructure move.

Guias relacionados neste site

• Site Migrations covers migration classification and the universal process.
• Website Migration Checklist provides the phase-based project checklist.
• HTTP Status Codes explains the response layer you should preserve and monitor.

Da indústria

• Google: Changing your hosting
• Google: Verify Googlebot
• Cloudflare: DNS TTL
• Cloudflare: Manage DNS records
• Cloudflare: Cache documentation
• Cloudflare: Origin CA
• Bing: IndexNow

Teste-se: SEO de migração de hospedagem de site

Cinco perguntas sobre classificar, lançar e validar uma mudança de infraestrutura com o mesmo URL. Escolha uma resposta para cada uma e depois confira.

Registro de alterações