Migrações de sites

TL;DR — Migração de site é qualquer grande mudança que possa mover URLs ou alterar como o Google as lê — novo domínio, HTTPS, plataforma, pastas ou redesign. Para proteger o tráfego, envie cada página antiga à nova página mais equivalente com redirecionamento 301 e mantenha-o por muito tempo. Uma queda temporária é normal; se não houver recuperação, algo quebrou.

O que é uma migração de site

“Migração” parece dramático, e às vezes é. Significa uma mudança significativa que pode afetar como os mecanismos encontram, leem e ranqueiam páginas. Um domínio novo e a troca de http:// para https:// são migrações. Mudar blog.example.com para example.com/blog/ e até fazer um redesign com as mesmas URLs também contam, porque o conteúdo e os templates mudam.

Elas são agrupadas porque compartilham o mesmo risco e o mesmo roteiro.

A regra mais importante

Quando uma URL muda, informe a navegadores e mecanismos para onde a página foi. Use um redirecionamento 301 (permanente), que diz “this page moved here for good.” Tradução: “esta página mudou definitivamente”. Os redirecionamentos realmente transferem os sinais das URLs antigas. O Google afirma que 301 e outros permanentes não causam perda de PageRank.

O mais importante: mapeie cada página antiga para a única página nova mais relevante. Não jogue tudo na página inicial. Sem equivalente exato, use a categoria mais próxima. O Google trata muitas URLs antigas redirecionadas à home como erros 404 leves.

O que as pessoas entendem errado

• “Redirects lose my link credit.” Tradução: “Redirecionamentos perdem autoridade de links.” Não perdem; permanentes não custam PageRank.
• “The Change of Address tool moves my site for me.” Tradução: “A ferramenta Mudança de endereço move meu site.” Não; ela só informa ao Google sobre um novo domínio. Os redirecionamentos fazem o trabalho e a ferramenta não vale para HTTPS ou pastas.
• “My traffic dropped, the migration failed.” Tradução: “Meu tráfego caiu; a migração falhou.” Geralmente não. Uma oscilação temporária é normal; aguarde algumas semanas. Evidência desta afirmação Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Escopo: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Site move with URL changes
• “I can take the redirects down after a few months.” Tradução: “Posso remover os redirecionamentos após alguns meses.” Mantenha-os muito mais — idealmente por anos, na prática para sempre.

Mude uma coisa de cada vez

O maior risco é mudar coisas demais simultaneamente. Novo domínio, plataforma e estrutura de URLs no mesmo dia são três migrações empilhadas, com riscos multiplicados. Se puder dividir em fases, divida.

Quer o processo completo — sete fases, estratégia de redirecionamento e checklist por tipo? Abra a aba Avançado.

TL;DR — Risco = quantidade de mudança × simultaneidade. Redirecionamentos 301/308 são a espinha dorsal — transferem sinais sem perder PageRank; Mudança de endereço, sitemaps, links internos e canonicals dão apoio. Mapeie antigo→novo 1:1, não redirecione tudo à home (404 leve), evite cadeias e mantenha os redirecionamentos muito além de “12 meses”. Espere oscilação e recuperação; queda permanente significa falha — geralmente bloqueio de staging, hreflang/canonical removido, noindex indevido ou destino errado. A seguir: processo universal em 7 fases e os 7 tipos.

Este hub cobre classificação, princípios, modelo de risco, decisões por tipo e diagnóstico de recuperação. Use o Checklist de migração de website para tarefas executáveis, responsáveis, critérios de liberação e condições de aceitação.

O que uma migração realmente é (e os 7 tipos)

Migração é mudança significativa em estrutura de URLs, domínio, plataforma, protocolo ou hospedagem que possa afetar rastreamento, indexação e ranqueamento — desde uma troca simples para HTTPS até rebranding de centenas de milhares de URLs em novo domínio e CMS.

Antes de escrever um redirecionamento, classifique a migração — e reconheça que casos reais combinam vários tipos. Eis os sete, aproximadamente por risco:

Os números correspondem às seções abaixo; a tabela está por risco. Risco = quanto você muda × quanto muda de uma vez. Redesign com mesmas URLs é baixo; domínio + URLs + plataforma simultâneos compõem três riscos altos. O Google recomenda mudar uma coisa de cada vez.

O processo universal de migração

Aplica-se a todo tipo antes das etapas específicas. Após muitas migrações, a constante é: um checklist sozinho não garante sucesso. Ele evita esquecimentos; processo e participação de SEO em cada fase fazem a migração funcionar.

Fase 1 — Planejamento

• Classifique todos os tipos envolvidos. Nomeie-os para dimensionar o risco real.
• Alinhe expectativas com a liderança antes do lançamento. O tráfego quase certamente oscilará; uma queda temporária é normal.
• Tenha sempre um plano de reversão. Deve ser possível voltar ao estado original em caso extremo.
• Lance em período de baixo tráfego. Preferencialmente segunda–quinta, fora da alta temporada, com equipe disponível.
• Defina um gerente de projeto de SEO e use um sistema de gestão. Dev, conteúdo, analytics e SEO precisam de um dono das dependências.

Fase 2 — Benchmark e rastreamento do site antigo

Você não pode validar a migração sem uma imagem de “antes”. Capture-a enquanto o site antigo está no ar:

• Rastreamento completo do site antigo (Screaming Frog, Ahrefs Site Audit ou equivalente). Salve como baseline.
• Capture por URL: status, títulos, descrições, canonical, hreflang, headings, links internos e Core Web Vitals.
• Registre ranqueamentos das páginas-chave.
• Exporte benchmarks de tráfego do GSC (3/6/12 meses) e GA4 por página/sessão.
• Exporte principais páginas por backlinks (Ahrefs + relatório Links do GSC).
• Reúna redirecionamentos existentes de CMS, CDN, .htaccess/servidor, relatório Página com redirecionamento e analytics.
• Audite problemas legados antes de carregar canonicals errados, inchaço de índice ou bloqueios.

Fase 3 — Mapeamento de URLs

Crie uma planilha um a um: cada URL antiga → sua única URL nova mais relevante. Sem exceção.

• Páginas removidas com equivalente próximo: redirecione ao conteúdo ativo mais relevante. Não envie muitas URLs a um destino irrelevante como a home. Evidência desta afirmação Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. Escopo: Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Site move with URL changes
• Sem equivalente: retorne 410 ou 404; não use a home, pois vira 404 leve.
• Rastrear cada URL é essencial: o mapa define o que era e o que será. Esse mapa é a migração.

Fase 4 — Estratégia de redirecionamento

Esta é a espinha dorsal do projeto.

• Use 301 ou 308 para mudanças permanentes. O Google recomenda redirecionamentos permanentes no servidor.
• 301 transfere PageRank. A documentação diz que permanentes não causam perda; guias que afirmam o contrário estão desatualizados. Evidência desta afirmação Google says 301 and other permanent redirects do not cause a loss in PageRank. Escopo: Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Site move with URL changes
• Evite cadeias. Aponte antigo → novo diretamente. O Google prefere até 3 e menos de 5; segue cerca de 10 saltos, mas cada um adiciona risco e atraso. Inconsistência de barra final (/page vs /page/) cria cadeias silenciosas.
• Redirecione ativos como imagens e PDFs.
• No servidor. JavaScript é último recurso.
• Não confunda temporário e permanente. 302/307 mantém URL antiga indexada e sinais no lugar; use só quando realmente temporário.
• Mantenha muito além de “um ano”. O mínimo do Google é “pelo menos 1 ano”, mas usuários se beneficiam indefinidamente. Bing sugere 1–2 anos. Minha regra: enquanto houver tráfego ou links — na prática, sem prazo. Evidência desta afirmação Google recommends keeping site-move redirects as long as possible, generally for at least one year. Escopo: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Site move with URL changes

Fase 5 — Staging e testes pré-lançamento

• Bloqueie a indexação do staging com noindex e/ou Disallow; registre que o bloqueio deve sair no lançamento.
• Use hostname temporário (ex.: beta.example.com) para testes públicos.
• Teste todos os redirecionamentos antigo → novo, em um salto e ao destino correto.
• Compare o crawl do staging com o baseline: títulos, descrições, canonical, hreflang, dados estruturados, robots, links e velocidade.
• Confirme canonicals para o site ao vivo, não staging.
• Valide analytics (GA4, GSC, tag manager), formulários, checkout e conversões.
• Garanta que Googlebot não esteja bloqueado por firewall ou proteção DoS.

Fase 6 — Lançamento

• Remova imediatamente todos os bloqueios noindex e robots.txt de staging — o desastre mais comum.
• Ative todos os 301 simultaneamente.
• Atualize e reenvie o sitemap XML de produção apenas com URLs canonical novas. Se um sitemap antigo ajudar a descobrir/monitorar redirecionamentos, envie-o separado e temporário; nunca misture inventários e remova-o depois. Veja a orientação do Google.
• Verifique amostras com inspeção de URL do GSC.
• Envie Mudança de endereço apenas para domínio.
• No Bing, envie por IndexNow; a antiga ferramenta Site Move foi descontinuada.
• Garanta capacidade do servidor. O Google rastreará mais intensamente após a mudança.

Fase 7 — Monitoramento pós-lançamento

• Espere oscilação temporária. O Google prevê flutuação; uma queda não prova falha. Em cópia idêntica de URLs/conteúdo para outro domínio, pode nem haver queda.
• Conheça o prazo. Site médio pode levar semanas; grandes, mais. Estabilização completa costuma levar meses.
• Diagnostique quedas sem recuperação. Geralmente são tags/diretivas ausentes ou indevidas: hreflang removido, noindex, canonicals quebrados.
• Valide redirecionamentos em massa — 301 correto, sem cadeia nem 404 final.
• Monitore seleção canonical. Muitos links ainda para a URL antiga podem mantê-la indexada; atualize links internos e busque links externos diretos.
• Monitore no GSC: indexação, desempenho, estatísticas de rastreamento e ações manuais. Registre rankings semanalmente no primeiro mês. O Bing recomenda logs por pelo menos três meses.

O redirecionamento funcionou? Meça sem se enganar

Não julgue por uma captura do dia do lançamento. Defina URLs antigas e novas, grupos e métricas antes e acompanhe as mesmas coortes em quatro marcos:

Em cada marco, compare o período pós-mudança com um período equivalente anterior e exclua o dia da mudança. Ele mistura estados, implantação parcial, cache, QA e descontinuidades de rastreamento. Mantenha a coorte e as métricas fixas; segmente marca, dispositivo, país, template ou tipo apenas se isso tiver sido planejado.

Antes de atribuir ganho/perda, anote releases, conteúdo, tracking, sazonalidade, campanhas e o histórico de atualizações confirmadas. Uma atualização simultânea confunde a atribuição; relate a incerteza e use evidência direta: respostas, cobertura, canonical e logs.

“Sem mudança” é resultado válido. O trabalho do redirecionamento costuma ser preservar acesso, sinais e conversões. Desempenho estável com respostas limpas em um salto pode ser sucesso. Registre-o sem inventar crescimento.

O planejado Verificador de impacto antes/depois pertence aqui: poderá padronizar exclusão do dia e comparações 7/14/30/90. Até lá, use planilha/relatório e salve datas, filtros, cohort e anotações.

Os 7 tipos de migração

O processo universal é a maior parte do trabalho. A seguir, particularidades de cada tipo — armadilhas e obrigações.

Tipo 1 — Mudança de domínio / rebranding

O que é: mover todas as páginas de oldbrand.com para newbrand.com — novo domínio e propriedade GSC, idealmente sem mudar URLs simultaneamente.

Risco: máximo. Toda URL muda, links externos precisam de atualização e o histórico do GSC se divide.

Armadilhas e obrigações:

• Não combine domínio, redesign e URLs. A documentação do Google alerta para perda provável. Mova o domínio primeiro; reestruture depois.
• Investigue o histórico do novo domínio. Confira archive.org e ações manuais antigas.
• Não deixe o domínio antigo expirar. Renove-o e mantenha redirecionamentos.
• Não encadeie mudanças (A → B → C); a ferramenta não aceita cadeia.

Ferramenta Mudança de endereço — o que faz e não faz. Ela orienta o Google a priorizar o rastreamento e a indexação do novo site, encaminha sinais e favorece as novas canonicals por 180 dias.

• Funciona para domínio ou subdomínio sem escopo de caminho, não páginas/pastas.
• Você deve ser proprietário verificado de propriedades qualificadas. Uma propriedade de domínio ou um prefixo de URL raiz pode servir; um prefixo limitado a um caminho, não. Veja requisitos e elegibilidade.
• É mudança estrita 1:1, não fusão/parcial.
• É opcional. Os 301s fazem o trabalho; a ferramenta acelera/esclarece.

A janela de 180 dias não é prazo do redirecionamento. Depois dela, a ferramenta deixa de vincular os sites; por isso os redirecionamentos precisam durar mais. Mínimo de um ano e, realisticamente, muito mais.

Tipo 2 — HTTP → HTTPS

O que é: mover de HTTP sem criptografia para HTTPS (TLS/SSL). Toda URL muda de http:// para https://. HTTPS é sinal leve desde 2014; hoje HTTP é desvantagem ativa.

Risco: baixo–médio se correto; alto com certificado ou conteúdo misto.

Armadilhas e obrigações:

• NÃO use Mudança de endereço. Use as diretrizes de mudança de site.
• Use 301 por URL, não regra que envia tudo à home HTTPS.
• Corrija conteúdo misto. Recursos HTTP geram alertas e sinais conflitantes. URLs relativas e CSP upgrade-insecure-requests ajudam.
• Google prefere HTTPS como canonical, exceto com certificado inválido, dependências inseguras, redirecionamento a HTTP ou conflitos.
• Cuidado com HSTS. Ative após TLS estar sólido, começando com max-age baixo.
• Use certificado forte (RSA 2048 bits ou EC; A/A+ no Qualys) e flag Secure em cookies.

Tipo 3 — Troca de plataforma / CMS

O que é: mudar CMS ou tecnologia (WordPress → headless, Magento → Shopify), frequentemente arrastando URLs, templates, links e renderização.

Risco: alto, porque várias coisas mudam juntas.

Armadilhas e obrigações:

• Espere mudanças de URL; planeje o mapa antes de escolher a plataforma.
• Redirecionamentos não migram sozinhos. Reúna regras de CMS, CDN, .htaccess/servidor e GSC.
• Reimplemente dados estruturados e valide após lançar.
• Teste renderização JavaScript em front-end headless/SPA.
• Compare velocidade e mobile. Temas novos podem ser pesados; o Google indexa mobile.
• Padronize barra final para evitar cadeias.
• Reimplante analytics e verificações antes do lançamento.
• Se URLs, links e templates mudarem juntos, espere estabilização mais longa.

Tipo 4 — Estrutura de URLs / reestruturação do site

O que é: mudar caminhos no mesmo domínio — ex.: /category/post/ → /post/. O domínio permanece; o conteúdo pode mudar ou não.

Risco: médio. A autoridade do domínio permanece, mas cada URL precisa de redirecionamento e o grafo interno deve ser atualizado.

Armadilhas e obrigações:

• Links internos são esquecidos. As equipes redirecionam as URLs, mas deixam antigos o rel=canonical, a navegação, o rodapé e os links no corpo, dificultando a escolha da nova canonical.
• Canonicalização pode atrasar. Backlinks e links internos antigos podem manter a preferência pela URL antiga; atualize links diretamente.
• NÃO use Mudança de endereço para reestruturações no mesmo domínio; adicione redirecionamentos e atualize sitemaps.
• Atualize breadcrumbs, navegação e sitemaps para os novos caminhos; sitemaps só com URLs novas.

Tipo 5 — Redesign do website (mesmas URLs)

O que é: domínio e URLs permanecem, mas templates, texto, navegação, imagens ou SEO on-page mudam. É o tipo de menor risco — não risco zero.

Risco: baixo, mas mudanças on-page ainda alteram ranqueamento.

Armadilhas e obrigações:

• Elementos on-page quebram silenciosamente. Redesigns removem/alteram <title>, descrições, headings e dados estruturados. Compare com o baseline.
• Observe links internos. Nova navegação pode remover links valiosos para páginas profundas.
• Compare Core Web Vitals antes/depois. CSS, JS, fontes e imagens mudam velocidade.
• Seja deliberado ao mudar conteúdo. “Mesma URL” pode esconder redução de conteúdo.
• Use a orientação do Google para mudança sem alterações de URL.

Tipo 6 — Subdomínio ↔ subpasta

O que é: mover conteúdo entre subdomínio e subpasta — geralmente blog.example.com → example.com/blog/. A consolidação reúne autoridade antes dividida entre hosts.

Risco: médio–alto. O Google trata subdomínio e raiz separadamente em muitos aspectos, causando reindexação real.

Armadilhas e obrigações:

• São entidades separadas para o Google, com orçamento e sinais parcialmente distintos. Consolidar pode ajudar, mas leva tempo.
• NÃO use Mudança de endereço em subdomínio → subpasta da mesma raiz; use canonicals/redirecionamentos.
• Propriedades GSC: acompanhe cobertura do subdomínio cair e da raiz crescer.
• Redirecione toda URL do subdomínio ao equivalente e atualize links internos diretamente; outreach nos principais backlinks ajuda.
• Reconcilie analytics e reconfigure GA4/cross-domain.

Tipo 7 — Consolidação de domínios / fusão de sites

O que é: combinar dois ou mais sites em um — por exemplo, incorporar concorrente adquirido ou unir sites de países/produtos.

Risco: muito alto. Não é mudança 1:1; a entidade combinada é, em muitos sentidos, um novo site para o Google. Martin Splitt descreve a fusão como criação de site novo a partir de uma combinação.

Armadilhas e obrigações:

• Não use Mudança de endereço. Ela exige 1:1; fusão é trabalho por URL.
• Espere alguma perda de tráfego. Sites A, B e C movidos para D podem gerar confusão; planeje estabilização longa.
• Remova duplicações primeiro. Escolha a canonical dos temas sobrepostos antes de redirecionar.
• Redirecione por URL ao conteúdo mais relevante, nunca domínio inteiro à home.
• Mantenha propriedade GSC de cada site e monitore queda nelas e crescimento no principal.

Escolha o guia especializado

Use o guia correspondente à decisão ou falha que precisa resolver:

• SEO para migração de hospedagem — servidor, CDN, DNS ou host com URLs estáveis.
• SEO para migração de CMS — plataforma/CMS, templates, renderização e paridade de dados.
• Migração de estrutura de URLs — caminhos, taxonomia ou pastas no mesmo domínio.
• Migração por divisão/carve-out — seção de um site movida para propriedade separada.
• Integração de SEO pós-aquisição — integração de sites, marcas e conteúdo adquiridos.
• Perda de tráfego pós-migração — visibilidade/tráfego que não se recupera.

Onde isso se encaixa

Migração toca muitos temas: redirecionamentos, canonicalização, HTTPS, hreflang e Mudança de endereço. Cada um tem análise própria, mas a espinha dorsal é igual: mapear antigo→novo 1:1, usar permanentes, mantê-los e monitorar sinais.

Resumo por IA

Uma versão condensada da seção Avançado:

• Migração é uma grande mudança em URLs, domínio, plataforma, protocolo ou hospedagem que afeta rastreamento, indexação e posicionamento. Risco = volume × simultaneidade.
• 7 tipos por risco: redesign → HTTP→HTTPS → URLs → subdomínio↔subpasta → CMS → domínio/rebranding → fusão.
• 7 fases: planejar/classificar → benchmark/crawl → mapa 1:1 → redirecionamentos → staging/testes → lançamento → monitoramento.
• 301/308 são a espinha dorsal. Transferem sinais e não perdem PageRank; outras ferramentas dão apoio.
• Mapeie 1:1. Nunca envie tudo à página inicial (404 leve), evite cadeias (~3–5 saltos) e mantenha os redirecionamentos muito além de “12 meses”.
• Espere oscilação e recuperação. Queda persistente geralmente é bloqueio de staging, hreflang/canonical removido, noindex ou destino errado.
• Mudança de endereço: só domínio, 1:1, opcional; não HTTPS, reestruturação interna ou fusão.
• Bing: Site Move foi descontinuado (~2021); use IndexNow. Mantenha redirecionamentos 1–2 anos.

Documentação oficial

Documentação de fontes primárias dos mecanismos de busca.

Google

• Mudança de site com alteração de URLs — roteiro principal: redirecionamentos, timing, expectativas e duração.
• Mudança sem alterar URLs — host/infraestrutura/redesign, DNS e firewall.
• Redirecionamentos e Pesquisa Google — permanentes, temporários e risco de JavaScript.
• Mudança de endereço — escopo, propriedades, exclusões e orientação.
• Consolidar URLs duplicadas — preferência HTTPS e força do 301.
• Canonicalização — como o Google escolhe canonical (sugestão, não diretiva).
• Ativar HTTPS (web.dev) — TLS, conteúdo misto e HSTS.

Bing / Microsoft

• Migração de website com Bing — orientação, duração e logs.
• IndexNow — mecanismo atual de envio ao Bing; Site Move foi descontinuado.

Citações das fontes

Declarações registradas do Google. Cada link leva ao trecho citado.

Google — redirecionamentos e PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” Tradução: “Redirecionamentos permanentes não causam perda de PageRank.” — Search Central. Ir para a citação
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” Tradução: “mantenha poucos redirecionamentos na cadeia, idealmente no máximo 3 e menos de 5”. Ir para a citação
• “Keep the redirects for as long as possible, generally at least 1 year.” Tradução: “Mantenha os redirecionamentos pelo maior tempo possível, geralmente pelo menos 1 ano.” Ir para a citação
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” Tradução: “Não redirecione muitas URLs antigas a um único destino irrelevante, como a página inicial.” Ir para a citação

Google — expectativas e prazo

• “Expect temporary fluctuation in site ranking during the move.” Tradução: “Espere oscilação temporária no ranqueamento durante a mudança.” Ir para a citação
• “a medium-sized website can take a few weeks for most pages to move in our index” Tradução: “um site médio pode levar algumas semanas para que a maioria das páginas mude em nosso índice”. Ir para a citação
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” Tradução: “Verifique os redirecionamentos do site antigo ao novo. Vemos frequentemente pessoas apontando para URLs erradas (inexistentes).” Ir para a citação

Google — ferramenta Mudança de endereço (janela de 180 dias)

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” Tradução: “Mantenha os redirecionamentos por pelo menos 180 dias — mais se ainda houver tráfego da Pesquisa Google.” — Ajuda do Search Console. Leia a fonte
• “After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site.” Tradução: “Depois de 180 dias, o Google não reconhece relação entre os sites e trata o antigo como não relacionado.” Leia a fonte

Google — canonical HTTPS e sinais de redirecionamento

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” Tradução: “O Google prefere páginas HTTPS equivalentes como canonical, salvo problemas ou sinais conflitantes.” Ir para a citação
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” Tradução: “O Googlebot segue o redirecionamento, mas o pipeline de indexação não o usa como sinal de que o destino deve ser canonical.” (sobre temporários) Ir para a citação

Google — alertas de lançamento e infraestrutura

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” Tradução: “Garanta que isso não bloqueie o acesso do Googlebot ao DNS ou aos servidores do provedor.” (firewall/DoS) Ir para a citação
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” Tradução: “é normal ver queda temporária na taxa de crawl logo após o lançamento, seguida de aumento constante.” Ir para a citação

Checklist mestre de migração

Execute-o em toda migração e acrescente a lista específica do tipo.

Pré-lançamento

• Todos os tipos classificados; riscos altos não empilhados.
• Partes interessadas avisadas sobre queda temporária; lançamento em período de baixo tráfego.
• Plano de reversão documentado/testado.
• Rastreamento completo do site antigo salvo.
• Rankings, GSC 3/6/12 meses, GA4 e backlinks exportados.
• Redirecionamentos de CMS, CDN, servidor e GSC reunidos.
• Mapa antigo→novo 1:1; removidas → 410/404, não home.
• 301/308 em um salto, incluindo imagens/PDFs.
• Staging bloqueado (noindex/robots.txt), com remoção anotada.
• Rastreamento do staging comparado: títulos, metas, canonicals, hreflang, schema, robots, links e velocidade.
• Canonicals do staging apontam ao vivo.
• Todos os redirecionamentos testados.
• Analytics, verificações, formulários e conversões testados.
• Firewall/DoS não bloqueia Googlebot.

Dia do lançamento

• Bloqueios de staging (noindex, robots.txt) removidos e verificados.
• Todos os 301 ativados.
• Sitemaps de produção só com novas canonicals e reenviados.
• Se útil, sitemap antigo separado e temporário, com responsável/condição de remoção.
• Amostras verificadas na inspeção de URL.
• Mudança de endereço enviada (apenas domínio).
• URLs enviadas ao Bing por IndexNow.
• Capacidade para crawl mais intenso confirmada.

Pós-lançamento

• Lista antiga rastreada; cada URL retorna 301 ao destino correto.
• Links internos apontam diretamente às URLs novas.
• GSC monitorado: indexação, desempenho, crawl e ações manuais.
• Rankings semanais no primeiro mês.
• Contato feito com os responsáveis pelos principais links externos.
• Redirecionamentos mantidos por anos, não só 180 dias.
• Em queda persistente: hreflang, noindex, canonicals e redirecionamentos verificados primeiro.

Checklists específicos por tipo

Tipo 1 — Mudança de domínio / rebranding

• Histórico do novo domínio verificado (archive.org); renovação do antigo garantida.
• Propriedade confirmada em GSC sem escopo de caminho: Domain ou prefixo raiz.
• 301 da home antiga → nova ativo.
• Canonicals, links e sitemaps atualizados ao novo domínio.
• Mudança de endereço enviada por subdomínio e variante www/não-www.
• Arquivo disavow transferido; não combinado com redesign/URLs.

Tipo 2 — HTTP → HTTPS

• Certificado válido (RSA/EC 2048 bits), Qualys A/A+; 301 por URL http→https.
• Conteúdo misto corrigido; CSP upgrade-insecure-requests.
• Canonicals, sitemaps, robots.txt, hreflang em HTTPS; cookies Secure.
• HSTS só após estabilidade, com max-age baixo primeiro.
• Mudança de endereço não usada.

Tipo 3 — Troca de plataforma / CMS

• Mapa antigo→novo criado antes de fechar a plataforma.
• Regras de CMS + CDN + servidor + GSC reunidas, inclusive .htaccess.
• Barra final padronizada; dados estruturados reconstruídos/validados.
• Renderização JS, mobile e velocidade testados.
• GA4/GSC/tag manager reimplantados.

Tipo 4 — Estrutura de URLs / reestruturação

• Mapa completo e 301 por URL.
• TODOS os links internos atualizados.
• rel=canonical e sitemaps com URLs novas.
• Mudança de endereço não usada.
• Crawl confirma ausência de links internos a URLs antigas.

Tipo 5 — Redesign (mesmas URLs)

• Elementos on-page antigos salvos e comparados após lançar.
• Links internos valiosos preservados.
• Core Web Vitals comparados.
• Mudanças de conteúdo deliberadas; analytics funcionando.

Tipo 6 — Subdomínio ↔ subpasta

• Subdomínio rastreado; mapa blog.example.com/post/ → example.com/blog/post/ criado.
• 301 de cada URL e links internos diretos à subpasta.
• Mudança de endereço não usada na mesma raiz.
• Ambas as propriedades GSC monitoradas; analytics reconfigurado.

Tipo 7 — Consolidação / fusão de domínios

• Cada site auditado (crawl, rankings, backlinks, GSC).
• Conteúdo sobreposto deduplicado e canonical escolhida antes.
• 301 por URL ao destino mais relevante, nunca tudo à home.
• Mudança de endereço não usada; estabilização longa planejada.
• Propriedade GSC mantida para cada site e principal.

Os modelos mentais

1. Risco = volume de mudança × simultaneidade. Primeiro, classifique os tipos. Redesign nas mesmas URLs é uma mudança de baixo risco; domínio + URLs + plataforma são três riscos altos compostos. Se puder, faça em etapas — uma coisa de cada vez.

2. Redirecionamentos fazem o trabalho; o restante sinaliza. Os 301 transferem os sinais. Mudança de endereço, sitemaps, links internos e canonicals são sinais de apoio que aceleram e limpam o processamento. Construa os redirecionamentos primeiro; os demais são aceleradores, não substitutos.

3. Mapeamento 1:1 supera enviar tudo à home. Cada URL antiga vai à nova mais relevante. Muitas para a home viram 404 leves e perdem sinais por página. Sem equivalente? Use 410/404 adequado.

4. A janela da ferramenta não é a vida do redirecionamento. Mudança de endereço encaminha sinais por 180 dias; redirecionamentos devem durar anos, enquanto houver tráfego ou links. São dois prazos, e o mais longo mantém a mudança.

5. Uma queda é normal; queda persistente é bug. Espere oscilação e recuperação em semanas/meses. Se não voltar, procure bloqueio de staging, hreflang removido, noindex, canonicals quebrados ou destinos errados.

6. Links internos importam tanto quanto redirecionamentos para canonical. Mesmo com tudo perfeito, links de navegação, rodapé, corpo e externos para a URL antiga podem mantê-la indexada. Atualize os links internos diretamente e entre em contato com os responsáveis pelos principais links externos.

Guia rápido de migração

Qual redirecionamento usar

Qual ferramenta/sinal para cada migração

Equivalentes do Bing

Fatos rápidos

• 301 não perde PageRank — mito morto desde ~2016.
• Cadeias: mantenha abaixo de ~3–5 saltos (Googlebot segue ~10).
• 180 dias = janela da ferramenta, não prazo de 301; mantenha quase para sempre.
• Reindexação: “algumas semanas” em site médio; mais em grande.
• Principal causa de queda persistente: tags ausentes/indevidas (hreflang, noindex, canonicals), não a mudança.

Que tipo de migração é esta — e Mudança de endereço se aplica?

Percorra a árvore uma vez para a maior mudança e repita para cada mudança adicional do mesmo release. Plataforma + caminhos + domínio são três migrações, não uma.

Playbook: o tráfego caiu após o lançamento e não se recupera

Use após a oscilação esperada não se estabilizar. Vá de falhas de acesso gerais a conflitos por URL; não culpe “a mudança” antes de validar a implementação.

Etapa 1 — Confirme que a queda é real e delimitada. Compare as mesmas páginas, consultas, mercados e definições do benchmark. Se só o relatório sumiu, corrija a medição. Se URLs antigas perdem e novas equivalentes ganham, monitore a transição normal. Se ambas perdem, avance.

Etapa 2 — Procure bloqueio geral de crawl/indexação. Busque produção como crawler e inspecione robots.txt, meta robots, X-Robots-Tag, autenticação, firewall, DNS e status. Remova noindex, Disallow: /, barreira de login ou bloqueio de bot e rastreie novamente.

Etapa 3 — Execute novamente o mapa completo. Teste todo o inventário, começando por páginas com mais links/tráfego. Corrija 404s, destinos irrelevantes, loops e cadeias; aponte diretamente ao equivalente final.

Etapa 4 — Compare páginas novas com o baseline. Canonicals, hreflang, títulos, headings, conteúdo, schema, links e HTML renderizado. Corrija primeiro qualquer problema de template que aponte para staging/antigo.

Etapa 5 — Verifique sinais de consolidação. Novas URLs devem ser autocanonical, links devem apontar diretamente e sitemaps de produção só conter novas canonicals. Sitemap antigo deve ser separado e removido quando perder utilidade. Amostre a canonical escolhida no GSC; remova sinais conflitantes e aguarde novo crawl.

Etapa 6 — Verifique capacidade e evidência do servidor. Leia estatísticas e logs do Googlebot. Se erros, latência, limites ou firewall aumentarem durante o pico pós-mudança, restaure capacidade/acesso. Caso saudável, escale grupos restantes por tipo/template.

Etapa 7 — Use rollback apenas para regressão comprovada. Reverta quando o gatilho acordado for atingido e a comparação vincular a queda a defeito reversível. Não reverta pela volatilidade do primeiro dia; isso cria outra migração.

Mitos de migração que causam falhas reais

“Permanent redirects lose link credit.” Tradução: “Redirecionamentos permanentes perdem autoridade.” Errado: o Google diz que não perdem PageRank. O risco não é o 301 em si; é destino errado, cadeia, loop ou beco sem saída. Faça: mapeie cada URL ao equivalente e teste a resposta final.

“Change of Address moves the site for me.” Tradução: “Mudança de endereço move o site por mim.” Errado: é sinal opcional para mudança 1:1 de domínio inteiro; não cria redirecionamentos nem serve para HTTPS, caminhos, movimentos parciais ou fusões. Faça o mapa primeiro e use-a apenas quando couber.

“Any traffic drop proves the migration failed.” Tradução: “Qualquer queda prova que a migração falhou.” Errado: oscilações de ranking, crawl e sitemap antigo são esperadas. Defina benchmarks e critérios de rollback antes; diagnostique queda persistente ou estrutural, não ruído normal.

“Redirects can come down after a few months.” Tradução: “Redirecionamentos podem ser removidos após alguns meses.” Errado: um ano é piso de processamento, não expiração de favoritos, backlinks ou usuários. Mantenha enquanto URLs antigas tiverem tráfego/links — geralmente para sempre — e controle o domínio antigo.

Ferramentas para mapear e verificar migração

• Construtor de mapa de redirecionamentos — cole conjuntos antigo/novo para propor mapa 301 com confiança, não correspondentes, lista 410, achatamento, overrides e exportações. Toda sugestão precisa de revisão editorial.
• Mapeador de cadeias — rastreie saltos, status, mudanças de host/caminho, meta refresh e regras; use em staging e falhas.
• Verificador de redirecionamento — confirme status, saltos e destino de URL/lote pequeno; crawl completo prova o mapa.
• Crawler de site inteiro — salva baseline, testa lista e compara títulos, canonicals, hreflang, diretivas, links, schema e renderização.
• Google Search Console — indexação, desempenho, sitemaps, crawl, inspeção e — só em domínio qualificado — Mudança de endereço.
• Logs do servidor — provam acesso dos bots, respostas e demanda por URLs antigas.

Prove que a migração foi publicada conforme o mapa

Teste completo de redirecionamentos antigos

• Teste: rastreie o inventário antigo completo em produção e investigue falhas com Mapeador ou Verificador.
• Esperado: cada URL movida retorna um único 301/308 no servidor ao equivalente; removidas retornam 404/410 planejado.
• Falha: 200 antigo, cadeia, loop, destino irrelevante ou 404 inesperado indica mapa/regra incorreto.
• Janela: imediatamente após lançar, após correções e no monitoramento inicial.
• Rollback: regra sistêmica envia seção protegida a destinos errados ou a torna inacessível e não pode ser corrigida no lugar.

Teste de indexabilidade e canonical das páginas novas

• Teste: rastreie novas URLs para status, robots e canonicals; use inspeção em páginas valiosas.
• Esperado: 200, sem bloqueio/noindex, canonical nova pretendida; após crawl, Google confirma nas amostras.
• Falha: diretiva de staging, canonical antiga/staging, autenticação ou canonical do Google divergente.
• Janela: sinais técnicos imediatos; canonical/indexação exigem crawl e podem levar semanas.
• Rollback: bloqueio geral ou defeito de canonical em template afeta conjunto protegido e não pode ser removido rapidamente.

Teste de destinos de links e sitemaps

• Teste: rastreie links internos e analise sitemaps contra o conjunto canonical aprovado.
• Esperado: navegação aponta diretamente às novas URLs; sitemaps atuais só têm canonicals novas com sucesso. Sitemap antigo opcional é separado, temporário e tem condição de remoção.
• Falha: links antigos, inventários mistos ou sitemap antigo sem utilidade atrasam/obscurecem a transição.
• Janela: imediato no site/arquivos; confirme processamento pós-lançamento.
• Rollback: regressão de navegação/gerador envia crawlers a URLs antigas, staging ou não canonical e não pode ser corrigida com segurança.

Recursos que valem seu tempo

Meus textos relacionados

• Uma migração de website exige mais que um checklist — guia completo, erros e monitoramento.
• Redirecionamentos para SEO: guia iniciante — tipos, cadeias e duração.
• Tudo bem remover 301 após um ano? Testamos — experimento próprio sobre longo prazo.
• Canonicalização: guia iniciante — escolha de canonical quando URLs competem.
• Guia iniciante de SEO técnico — contexto amplo.

Oficial

• Mudança de site com URLs alteradas — roteiro principal do Google.
• Mudança de endereço — escopo, propriedades e redirecionamentos.
• Migração de website com Bing — framework e duração.

De outros profissionais

• r/TechSEO — depuração de casos extremos e quedas.
• Mueller sobre chaves para migração bem-sucedida — URLs, links internos e por que 301 não basta.
• Migração limpa leva tempo; improvisada leva muito mais — conselho sobre fusões.
• HTTP para HTTPS: use 301 — 301 por URL.
• Migração com Bing — oito etapas, 1–2 anos e logs.
• Mudando domínios: evitando armadilhas — histórico e canonical não substitui 301.
• Ative HTTPS nos servidores — TLS, conteúdo misto e HSTS.

O Google recomenda manter redirecionamentos pelo maior tempo possível, geralmente pelo menos um ano. Evidência desta afirmação Google recommends keeping site-move redirects as long as possible, generally for at least one year. Escopo: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Site move with URL changes Ele diz esperar oscilação temporária e que a maioria das páginas de um site médio pode levar algumas semanas para mudar no índice. Evidência desta afirmação Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Escopo: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Confiança: alta · Verificado: 2026-07-14 Google Search Central: Site move with URL changes Quando possível, mude uma grande coisa de cada vez.

Teste seus conhecimentos: migrações de sites

Cinco perguntas sobre tipos, redirecionamentos e diagnóstico pós-lançamento. Escolha uma resposta e confira.

Registro de alterações