SEO de Migração de Hospedagem de Sites

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

O que é uma migração de hospedagem?

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

A permanência da URL é a condição que define o processo. https://example.com/page/ deve continuar sendo https://example.com/page/ antes e depois da mudança.

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

Por que uma mudança com a mesma URL pode afetar o SEO?

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

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

Quais são as etapas básicas?

1. Copie o site para a nova infraestrutura ou conecte-o a ela.
2. Teste a nova origem e o CDN sem alterar o DNS público.
3. Reduza o TTL do DNS antecipadamente para que a mudança eventual se propague mais rápido.
4. Confirme certificados, cache, regras de segurança e acesso dos crawlers.
5. Altere o DNS para enviar o tráfego à nova infraestrutura.
6. Mantenha os dois ambientes on-line enquanto os caches de DNS expiram.
7. Monitore logs, erros, velocidade, rastreamento e desempenho na busca.
8. Desligue o host antigo somente quando os logs mostrarem que não há mais tráfego.

O Google recomenda essa mesma sequência de preparação, troca, monitoramento e desligamento 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 uma resposta DNS em cache. Um TTL menor antes da mudança faz com que os registros alterados expirem dos caches mais cedo. Ele não faz todos os resolvedores mudarem instantaneamente, e reduzi-lo no momento do lançamento é tarde demais para os caches que mantêm o valor antigo.

O Google sugere reduzir o TTL para um valor baixo e conservador, como algumas horas, pelo menos uma semana antes da mudança. Trate isso como um exemplo, não como um número universal; seu provedor de DNS e seus requisitos operacionais definem 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 somente de host cria novos modos de falha sem resolver o problema de infraestrutura.

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

Quando a mudança está concluída?

A mudança de hospedagem está concluída quando a nova infraestrutura fornece as respostas esperadas de forma consistente e a infraestrutura antiga não recebe mais tráfego real de usuários ou crawlers. 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 a mesma URL como um projeto de paridade de respostas e roteamento de tráfego. Faça o inventário de 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 a carga realista de crawlers e usuários e compare respostas brutas e renderizadas. Execute a infraestrutura antiga e a nova em paralelo durante a propagação do DNS. Monitore os dois fluxos de logs, respostas DNS, erros, latência, comportamento do cache, atividade de rastreamento e Search Console. Faça rollback restaurando o roteamento anterior somente quando ocorrer uma falha de infraestrutura previamente definida.

Decida se esta é realmente uma migração com a mesma URL

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

Classifique o projeto antes de planejá-lo:

Não deixe um gerente de projeto classificar uma alteração de URL como “apenas hospedagem”. O plano de implantação precisa incluir cada tipo de migração que realmente será lançado.

Crie o inventário da infraestrutura

O inventário de infraestrutura impede que dependências silenciosas se transformem em 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 vencimento;
• endereços de origem, portas, verificações de integridade, balanceadores de carga e comportamento de failover;
• chaves e regras de cache da CDN, redirecionamentos, transformações, workers e métodos de limpeza;
• regras de WAF, bots, limitação de taxa, geolocalização, autenticação e permissão/bloqueio de IPs;
• 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 em listas de permissão.

A revisão do DNS precisa incluir registros que não são da Web. Romper registros MX, SPF, DKIM, DMARC ou de serviços pode não alterar diretamente as classificações, mas pode quebrar o negócio que você estava tentando proteger.

Estabeleça uma linha de base de paridade de respostas

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

Colete um conjunto representativo entre os modelos e comportamentos:

• status e cadeia de redirecionamento;
• URL final e negociação de protocolo;
• título, canonical, diretivas 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 para usuários autenticados ou personalizadas;
• comportamento em dispositivos móveis e desktops;
• latência, tempo até o primeiro byte e taxa de erros.

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

Prepare a nova origem

A preparação da origem começa com a 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 as gravações para que o novo banco de dados não seja lançado desatualizado.

Teste a origem diretamente por meio de um hostname controlado, de uma substituição no arquivo hosts local ou de um mecanismo de prévia específico do provedor. O teste precisa preservar o cabeçalho Host de produção, pois hosts virtuais, roteamento da aplicação, certificados, canonicals e links absolutos costumam depender dele.

A nova origem também precisa suportar a carga após o corte. Aqueça a aplicação e o banco de dados, confirme os pools de conexão e o autoscaling e teste sob carga a demanda sem cache. Os cache misses 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 explicitamente o comportamento antigo e o novo na borda:

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

A documentação atual da Cloudflare, por exemplo, observa que o cache padrão pode respeitar os cabeçalhos Cache-Control da origem, mas pode ser substituído por regras de borda. Ela também oferece limpezas direcionadas ou completas para forçar novas buscas na origem. O comportamento exato varia conforme o fornecedor; por isso, exporte e compare as configurações em vez de presumir que rótulos equivalentes produzem resultados equivalentes. Consulte a documentação de cache da Cloudflare.

Trate a paridade do cache como paridade de conteúdo

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

Limpe ou aqueça previamente ativos e páginas críticos de acordo com o plano de lançamento. Não limpe tudo às cegas durante o pico de tráfego, a menos que a origem tenha sido testada para a tempestade de misses resultante.

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

A validação do TLS tem duas etapas quando um CDN termina o HTTPS: do navegador ao CDN e do CDN à origem. Confirme a cobertura de hostnames, as cadeias completas de certificados, o suporte a protocolos modernos, a renovação e a validação rigorosa da origem.

Certificados exclusivos da origem talvez não tenham confiança pública. A Cloudflare alerta que os certificados Origin CA podem produzir erros de confiança no navegador se o proxy estiver desativado ou pausado. Isso importa durante um rollback: uma reversão somente por DNS para uma origem que usa um modelo de confiança exclusivo da borda pode falhar para os usuários. Consulte as orientações da Cloudflare sobre Origin CA.

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

Reduza o TTL do DNS antes da mudança

O planejamento do TTL começa antes do corte. O Google recomenda reduzir o TTL relevante para um valor baixo e 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 o compromisso básico: valores mais longos aumentam o reaproveitamento do cache, enquanto valores mais curtos permitem que alterações nos registros tenham efeito mais cedo. Registre o TTL original e programe sua restauração somente depois que a nova infraestrutura estiver estável.

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

Verifique o acesso dos crawlers e os controles de segurança

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

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

Teste tanto o comportamento normal de crawlers quanto picos legítimos. Evite uma permissão ampla que desative a proteção para user agents falsificados. Preserve os logs de segurança para distinguir requisições bloqueadas de falhas na origem.

Planeje a execução em paralelo

Executar em paralelo significa que a infraestrutura antiga e a nova conseguem servir respostas corretas de produção durante a propagação. O ambiente antigo precisa continuar recebendo alterações de conteúdo ou dados que afetem o site. Caso contrário, usuários encaminhados por respostas DNS em cache podem ver inventários desatualizados, sessões quebradas ou páginas antigas.

Escolha uma estratégia de sincronização:

• um banco de dados compartilhado para leitura e gravação pelas duas pilhas;
• dados replicados com atraso conhecido e uma política de conflitos definida;
• um congelamento controlado de conteúdo durante o corte;
• replicação unidirecional de eventos para pedidos, formulários ou gravações de usuários.

O estado das sessões, uploads, invalidações de cache e tarefas em segundo plano precisa seguir a mesma decisão. “Os dois servidores estão ligados” não é um plano de execução em paralelo se os estados divergirem.

Execute o corte

O corte da hospedagem deve ser deliberadamente entediante:

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

Não use a ferramenta Change of Address do Google para uma mudança somente de host. Nenhuma URL pública mudou, portanto não há alteração de endereço a relatar.

Monitore as evidências que comprovam a mudança

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

Observe:

• respostas DNS e propagação entre resolvedores;
• solicitações aos hosts 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, timeout e aplicação;
• percentis de latência e tempo de resposta da origem sem cache;
• taxa de acertos do cache e volume de solicitações à origem;
• solicitações do Googlebot, Estatísticas de rastreamento, Indexação de páginas e inspeções representativas de URL;
• verificações sintéticas em diferentes regiões e redes;
• analytics, conversões e transações comerciais críticas.

O Google afirma que uma queda temporária na taxa de rastreamento do Googlebot logo após uma mudança de hospedagem pode ser normal, seguida de um aumento nos dias seguintes. 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

O rollback devolve o roteamento a um estado de infraestrutura conhecido e bom. Não é uma promessa vaga de “voltar o DNS”. 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 as dependências antigos continuam válidos;
• etapas de limpeza de cache nas duas rotas;
• os limites de falha que acionam o rollback;
• o tempo máximo seguro para a decisão.

Os gatilhos de rollback devem ser observáveis: falhas persistentes de disponibilidade, quebra material nas conversões, conteúdo incorreto em grande escala, falhas de certificados, bloqueios de crawlers ou colapso de capacidade que não possa ser corrigido dentro da janela. Uma oscilação temporária na taxa de rastreamento, por si só, não é um gatilho de rollback.

Retire a infraestrutura antiga pelos logs, não pelo calendário

A retirada do host antigo ocorre depois que os logs mostram que usuários e crawlers já não chegam até ele e que todos os serviços dependentes foram transferidos. O Google recomenda desligar o host antigo depois que seu tráfego chegar a zero.

Conserve exportações de configuração, logs e artefatos de rollback conforme os requisitos do negócio. Restaure o TTL do DNS ao valor pretendido de estado estável depois de comprovar a estabilidade. Remova exceções temporárias do firewall e tarefas agendadas duplicadas para que a migração não deixe uma confusão 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.
• Alterações de URL exigem o processo mais amplo de mudança de site. Uma verdadeira mudança apenas de host não precisa de um novo mapa de redirecionamentos nem do envio de Change of Address.
• Faça o inventário de DNS, TLS, origem, CDN, WAF, cache, logs, verificação, ativos e dependências do negócio antes do lançamento.
• Reduza o TTL do DNS antes do corte, registre o valor anterior e restaure-o depois que o novo caminho estiver estável.
• Compare as respostas brutas antigas e novas, páginas renderizadas, cabeçalhos, ativos, redirecionamentos, códigos de status, latência e comportamento do negócio.
• Valide o TLS do navegador até a borda e da borda até a origem, além dos certificados de qualquer caminho de rollback.
• Mantenha os dois ambientes em execução e sincronize as gravações até que as respostas DNS em cache não enviem mais tráfego para a pilha antiga.
• Monitore os dois fluxos de logs, respostas DNS, erros, carga da origem, comportamento do cache, acesso de crawlers verificados, Search Console e conversões.
• Retire o host antigo somente quando os logs mostrarem que o tráfego chegou a zero.

Documentação oficial

Google

• Alteração da hospedagem e do SEO explica o processo de preparação, troca do DNS, monitoramento e desligamento para a mesma URL.
• Mudanças de site com alterações de URL aplica-se quando o esquema, hostname ou caminho também muda.
• Verificar o Googlebot documenta a verificação por DNS reverso/direto e por IPs publicados.
• Relatório de Estatísticas de rastreamento ajuda a monitorar as solicitações do Googlebot e a disponibilidade do host.

Referências de infraestrutura

• TTL do DNS da Cloudflare explica as trocas entre TTL e propagação.
• Cache da Cloudflare documenta o cache na borda, as regras de cache e a limpeza.
• Cloudflare Origin CA documenta os certificados da borda à 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 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.

Checklist de migração de hospedagem

Escopo e linha de base

• Confirmei que nenhuma URL pública mudará.
• Fiz o inventário de todos os hostnames Web, de ativos, APIs e regiões.
• Exportei as configurações de DNS, CDN, WAF, cache, redirecionamentos, TLS e origem.
• Salvei linhas de base representativas das respostas brutas e renderizadas.
• Registrei as linhas de base de tráfego, erros, latência, rastreamento, indexação e conversões.

Nova infraestrutura

• Sincronizei o conteúdo atual, a mídia, os redirecionamentos, as regras de robots e os arquivos de verificação.
• Testei o roteamento pelo cabeçalho Host e todos os hostnames públicos.
• Validei os certificados do navegador até a borda e da borda até a origem.
• Alinhei chaves de cache, bypasses, TTLs, cookies, transformações e comportamento de limpeza.
• Alinhei o comportamento de WAF, bots, limitação de taxa e acesso à origem.
• Testei sob carga os cache misses, as dependências da aplicação e a capacidade do banco de dados.
• Confirmei que os logs da borda, da origem, da aplicação e da segurança são retidos e pesquisáveis.

DNS e lançamento

• Reduzi os TTLs relevantes antes da mudança e registrei os valores originais.
• Preservei registros não Web, DNSSEC, verificação e dependências de serviços.
• Documentei a alteração exata de roteamento e os comandos de rollback.
• Mantive as infraestruturas antiga e nova ativas com um plano de sincronização de dados.
• Removi todos os bloqueios temporários de rastreamento ou acesso no caminho de produção.
• Verifiquei as respostas DNS por meio de vários resolvedores independentes.

Depois do lançamento

• Comparei status, conteúdo, cabeçalhos, renderização, ativos e redirecionamentos em produção.
• Confirmei que usuários e crawlers verificados não recebem desafios nem são bloqueados.
• Monitorei logs antigos/novos, erros, latência, cache misses, carga da origem e conversões.
• Verifiquei Estatísticas de rastreamento, Indexação de páginas e resultados representativos da Inspeção de URL.
• Restaurei o TTL de estado estável somente depois de comprovar a estabilidade.
• Retirei o host antigo somente depois que seu tráfego chegou a zero.

A estrutura de paridade em cinco camadas

O modelo de estados da migração

Preparado significa que a nova pilha passou nos testes de paridade e carga. Trocando significa que respostas DNS e requisições estão divididas. Estabilizando significa que a nova pilha serve quase todo o tráfego enquanto a pilha antiga permanece disponível. Concluído significa que o tráfego do host antigo chegou a zero e todas as dependências foram retiradas ou transferidas.

Não declare o projeto concluído quando “o DNS mudou”. Esse é o início da troca, 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 chegam ao host antigo

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

As solicitações do Googlebot caem depois do lançamento

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

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

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

O site funciona pelo CDN, mas falha quando o CDN é contornado

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

Os ativos falham enquanto o HTML funciona

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

A carga da origem aumenta imediatamente

Causa provável: caches frios, chave de cache alterada, cache contornado, proteção ausente ou tráfego de bots chegando diretamente à origem. Correção: restaure as regras de cache pretendidas, aqueça cuidadosamente objetos de alto valor e adicione capacidade. Faça rollback se as falhas persistentes ultrapassarem o limite acordado.

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

• O DNS Checker compara tipos comuns de registros por meio de vários resolvedores públicos. Use-o durante a propagação, mas compare o resultado também com a zona autoritativa.
• O HTTP Header Checker mostra os cabeçalhos ao longo dos redirecionamentos, incluindo identificadores da CDN, compressão, segurança e controles de cache.
• O Staging vs. Production SEO Diff compara pares de URLs quanto a status, canonicals, diretivas, cabeçalhos selecionados, schema e conteúdo.
• O Bulk HTTP Status Code Checker verifica status, redirecionamentos, destino e latência em um conjunto representativo de URLs.
• O Google Index Checker verifica bloqueios observáveis de rastreamento e indexabilidade e direciona você ao Search Console para consultar a visão do Google.
• Os logs do servidor e da borda comprovam para onde foi o tráfego, qual resposta ele recebeu e quando a infraestrutura antiga deixou de ser usada de fato.
• Monitoramento sintético testa a disponibilidade pública e as transações críticas em várias redes e regiões.

Comprove que a migração de hospedagem funcionou

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

• Teste a executar: consulte o DNS autoritativo e vários resolvedores públicos e depois 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 cai até zero.
• Interpretação da falha: registros inconsistentes, respostas em cache ou hostnames não rastreados ainda estão direcionando o tráfego para outro lugar.
• Janela de monitoramento: desde o corte até pelo menos o maior TTL relevante anterior e até que os logs do host antigo permaneçam em zero.
• Gatilho de rollback: regiões relevantes 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 respostas

• Teste a executar: compare a linha de base com a produção usando o Staging vs. Production SEO Diff, um crawler e testes de navegador renderizados.
• Resultado esperado: status, canonicals, regras de robots, conteúdo, dados estruturados, links internos, ativos e cabeçalhos pretendidos são preservados.
• Interpretação da falha: a configuração da nova origem, da borda ou da aplicação alterou uma resposta visível à busca apesar de as URLs permanecerem estáveis.
• Janela de monitoramento: imediatamente antes e depois do corte e, em seguida, após cada correção do lançamento.
• Gatilho de rollback: uma falha generalizada de indexabilidade, canonical, conteúdo ou ativos afeta modelos protegidos e não pode ser corrigida com segurança em um hotfix.

Teste de acesso de crawlers e capacidade

• Teste a executar: inspecione logs de crawlers verificados, Estatísticas de rastreamento do Search Console, latência da origem, taxas de erro e resultados de testes de carga sem cache.
• Resultado esperado: crawlers verificados recebem respostas bem-sucedidas sem desafios, enquanto a origem permanece dentro do limite de capacidade estabelecido.
• Interpretação da falha: WAF, DNS, TLS, limitação de taxa ou capacidade da origem está impedindo um rastreamento confiável.
• Janela de monitoramento: continuamente durante o lançamento e nos primeiros dias de estabilização da taxa de rastreamento.
• Gatilho de rollback: falhas persistentes de crawlers e usuários excedem o limite de erro ou disponibilidade aprovado.

Teste de segurança do cache

• Teste a executar: solicite variantes anônimas, autenticadas, localizadas, móveis e com query string enquanto inspeciona chaves de cache e cabeçalhos de resposta.
• Resultado esperado: o conteúdo público é armazenado em cache conforme planejado; respostas privadas ou personalizadas não são compartilhadas; variantes relevantes permanecem distintas.
• Interpretação da 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 depois de qualquer alteração em regra de cache ou limpeza.
• Gatilho de rollback: dados personalizados são expostos, conteúdo desatualizado é servido em grande escala ou a origem não consegue sustentar a taxa de misses.

Recursos que valem seu tempo

Textos relacionados meus

• Uma migração de site exige mais do que um checklist para ser bem-sucedida aborda o processo mais amplo de migração, linhas de base, staging e monitoramento.
• Redirecionamentos para SEO explica o comportamento dos redirecionamentos legados que precisa sobreviver a uma mudança de infraestrutura.

Guias relacionados neste site

• Migrações de site aborda a classificação das migrações e o processo universal.
• O Checklist de migração de site fornece o checklist do projeto organizado por fases.
• Códigos de status HTTP explica a camada de resposta que você deve preservar e monitorar.

De todo o setor

• Google: Alterar sua hospedagem
• Google: Verificar o Googlebot
• Cloudflare: TTL do DNS
• Cloudflare: Gerenciar registros DNS
• Cloudflare: Documentação de cache
• Cloudflare: Origin CA
• Bing: IndexNow

Teste seus conhecimentos: SEO de migração de hospedagem de sites

Cinco perguntas sobre classificar, lançar e validar uma mudança de infraestrutura com a mesma URL. Escolha uma resposta para cada pergunta e confira em seguida.

Registro de alterações