Páginas Após Migração de Site Não Indexadas: Guia Completo de Recuperação
A tua migração de site correu bem no browser, mas o Google está com dificuldades em reconhecer os teus novos URLs. Percebe a janela crítica de 90 dias e resolve os problemas de redirect, canonical e verificação que bloqueiam a indexação pós-migração.
Neste guia
As migrações de site estão entre as operações mais arriscadas em SEO. Quer estejas a mudar para um domínio novo, alterar a estrutura de URLs, migrar de HTTP para HTTPS, mudar de plataforma CMS ou consolidar vários sites num só, a migração perturba fundamentalmente a compreensão que o Google tem do teu site. Páginas que estavam indexadas há anos podem subitamente desaparecer dos resultados de pesquisa. Novos URLs que deveriam substituir antigos ficam presos na fila de rastreio. Rankings caem de forma transversal à medida que o Google reavalia todo o teu site na sua nova forma.
Os primeiros 90 dias após uma migração são críticos. Durante este período, o Google está ativamente a voltar a rastrear o teu site, a processar redirects, a avaliar novos URLs, e a decidir se a nova estrutura do site merece a mesma cobertura de indexação e rankings que a antiga. Erros nesta janela podem resultar em meses de tráfego perdido. Mas mesmo migrações bem executadas frequentemente sofrem lacunas de indexação onde algumas páginas do novo site não estão indexadas enquanto as suas contrapartes antigas foram removidas do índice.
Problemas de indexação pós-migração diferem de problemas normais de indexação porque envolvem uma transição entre dois estados. O Google tem de processar em simultâneo a remoção de URLs antigos e a adição de novos, transferir autoridade de páginas antigas para novas páginas através de redirects, e reconciliar a sua compreensão existente do conteúdo do teu site com a nova estrutura. Isto cria oportunidades para confusão, sinais perdidos e lacunas de indexação que não ocorrem nas operações normais do site.
Este guia cobre os problemas específicos de indexação que ocorrem durante e após migrações de site, os passos de diagnóstico para os identificar, e as correções para os resolver rapidamente e minimizar a perda de tráfego durante o período de transição.
A Janela Crítica de 90 Dias Pós-Migração
A resposta do Google a uma migração de site desenrola-se ao longo de aproximadamente 90 dias, embora o cronograma exato varie com base na dimensão do site, frequência de rastreio e âmbito das mudanças. Perceber este cronograma ajuda-te a definir expectativas e a identificar quando atrasos de indexação são normais versus quando indicam um problema.
Nas primeiras uma a duas semanas após a migração, o Google começa a descobrir as alterações. Se configuraste redirects 301 de URLs antigos para URLs novos, o Google encontra estes redirects durante o seu rastreio normal dos teus URLs antigos. Cada redirect diz ao Google que o URL antigo foi permanentemente movido para uma nova localização. O Google processa estes redirects e começa a adicionar os novos URLs à sua fila de rastreio. Durante esta fase, vais ver uma mistura de URLs antigos e novos nos resultados de pesquisa, o que é normal.
Nas semanas dois a quatro, o Google acelera o rastreio dos novos URLs. Se submeteste um novo sitemap com a nova estrutura de URLs e verificaste o novo domínio no Google Search Console, o Google acelera a sua exploração do novo site. Deves ver o rácio de URLs antigos-para-novos no índice a deslocar-se para URLs novos. Alguns URLs antigos vão ainda aparecer nos resultados de pesquisa pois o Google ainda não rastreou e processou todos os redirects.
Nas semanas quatro a oito, a maior parte da transição deve completar-se. A maioria dos URLs antigos deve redirecionar corretamente, a maioria dos novos URLs deve estar indexada, e os rankings devem começar a estabilizar nos níveis pré-migração ou perto deles. Se os rankings estão significativamente mais baixos do que antes, podem existir problemas de redirect, mudanças de conteúdo ou problemas técnicos no novo site a afetar sinais de qualidade.
Nas semanas oito a doze, a confiança do Google no novo site solidifica-se. Quaisquer URLs antigos remanescentes que ainda estejam indexados devem ser processados. Os rankings devem recuperar para os níveis pré-migração assumindo que a migração foi executada corretamente. Se páginas específicas continuam não indexadas neste ponto, têm problemas individuais que precisam de troubleshooting direcionado.
Durante toda esta janela de 90 dias, evita fazer mais alterações importantes ao teu site. Não redesenhes o novo site, não voltes a reestruturar os URLs, e não alteres significativamente o conteúdo. Cada alteração adicional reinicia partes do processo de avaliação do Google e estende o cronograma de recuperação. Trata os 90 dias após a migração como um período de estabilização onde as tuas únicas alterações devem ser correções para problemas relacionados com a migração.
Cadeias de Redirect 301, Loops e Lacunas de Mapeamento
A implementação de redirects é o fator individual mais importante na indexação pós-migração. Cada URL antigo que tinha quaisquer rankings, tráfego ou backlinks tem de redirecionar para a página mais relevante no novo site. Erros na implementação de redirects são responsáveis pela maioria das falhas de indexação pós-migração.
Cadeias de redirect ocorrem quando um redirect aponta para outro redirect, que aponta para outro. Por exemplo, http://dominio-antigo.com redireciona para https://dominio-antigo.com, que redireciona para https://dominio-novo.com/pagina. O Google consegue seguir cadeias de redirect, mas cada salto na cadeia introduz latência e pode perder algum link equity. O Google afirmou que passa PageRank completo através de um único redirect 301 mas tem sido menos claro sobre cadeias. A melhor prática é minimizar cadeias para um máximo de dois saltos e idealmente implementar redirects diretos de um único salto de cada URL antigo para o seu destino final.
Loops de redirect ocorrem quando o URL A redireciona para o URL B, e o URL B redireciona de volta para o URL A. Isto impede o Google de alguma vez chegar a uma página de destino final e resulta num erro de rastreio. Loops ocorrem comumente quando HTTP redireciona para HTTPS e a versão HTTPS também tem uma regra de redirect que envia certos caminhos de volta para HTTP, ou quando redirects www e não-www entram em conflito uns com os outros. Testa a implementação de redirects usando uma ferramenta de verificação de cadeia de redirect que segue o caminho completo de redirect para cada URL.
Lacunas de mapeamento são URLs antigos que não têm qualquer redirect para um URL novo. Quando o Google rastreia um URL antigo e recebe um erro 404 em vez de um redirect, remove esse URL do índice. Se a página equivalente existe no novo site mas não foi mapeada no plano de redirects, o Google não tem forma de ligar a autoridade da página antiga à página nova. A página nova tem de ganhar indexação do zero, perdendo todos os sinais acumulados de ranking.
Para identificar lacunas de mapeamento, compara a tua lista completa de URLs antigos indexados (exportada do Google Search Console antes da migração ou de um rastreio pré-migração) com o teu ficheiro de mapeamento de redirects. Qualquer URL antigo sem um redirect correspondente é uma lacuna. Para URLs antigos que não têm um equivalente direto no novo site, redireciona-os para a página-mãe ou categoria mais relevante em vez de os deixar dar 404. Um redirect para uma página algo-relevante é sempre melhor do que um 404 da perspetiva de link equity.
Depois da migração, monitoriza o Google Search Console em busca de erros de rastreio em URLs antigos. Um pico de erros 404 em padrões de URL antigos indica redirects em falta. Verifica a lista de erros 404 regularmente durante os primeiros 90 dias e adiciona redirects para quaisquer URLs antigos de alto tráfego ou alta autoridade que estejam a devolver erros.
Verificação do Google Search Console e Gestão de Sitemaps
Uma configuração adequada do Google Search Console é crítica para a indexação pós-migração. Se a tua migração envolve uma mudança de domínio, mudança de estrutura de URLs ou mudança de protocolo, a tua configuração do Search Console precisa de atualizações específicas para ajudar o Google a processar a transição corretamente.
Para migrações de domínio (dominio-antigo.com para dominio-novo.com), precisas de ter ambos os domínios antigo e novo verificados no Google Search Console. Não removas a propriedade do domínio antigo. Precisas dela para monitorizar como o Google processa a transição a partir de URLs antigos e para usar a ferramenta de Alteração de Endereço. Na propriedade do Search Console do domínio antigo, navega para Definições e usa a funcionalidade de Alteração de Endereço para notificar formalmente o Google de que o site se mudou para o novo domínio. Isto acelera o processamento da alteração de domínio pelo Google e ajuda a preservar sinais de ranking durante a transição.
Para o novo domínio, verifica-o como uma propriedade de Domínio no Search Console imediatamente após a migração. Submete um novo sitemap XML contendo todos os novos URLs. O novo sitemap deve listar apenas a nova estrutura de URLs. Não incluas URLs antigos no novo sitemap. Se o teu sitemap antigo continua acessível no domínio antigo, deixa-o em vigor temporariamente. O Google vai rastrear o sitemap antigo, encontrar redirects para cada URL e segui-los até aos novos URLs, o que ajuda à descoberta.
Para alterações de estrutura de URLs no mesmo domínio (por exemplo, mudar /blog/titulo-do-post para /artigos/titulo-do-post), submete um sitemap atualizado com os novos padrões de URL. Usa a ferramenta de Inspeção de URL para pedir novo rastreio dos teus URLs novos mais importantes. O Google deve descobrir as alterações de URL através de redirects durante o rastreio normal, mas a submissão de sitemap acelera o processo.
Para migrações de HTTP para HTTPS, adiciona e verifica a versão HTTPS do teu domínio no Search Console se ainda não o fizeste. Submete um novo sitemap com URLs HTTPS. O Google geralmente processa migrações HTTPS sem problemas, mas monitoriza a indexação dos URLs HTTPS ao longo das semanas seguintes para garantir que estão a substituir URLs HTTP no índice.
Um erro comum é submeter um sitemap com URLs antigos no novo site. Após a migração, audita o teu sitemap para garantir que cada URL nele é um URL válido e não-redirecionante no novo site. Um sitemap que referencia URLs antigos ou URLs que redirecionam envia sinais mistos ao Google e pode atrasar a indexação da tua nova estrutura de URLs.
Alterações de Conteúdo e Template Que Afetam a Indexação Pós-Migração
Muitas migrações de site envolvem mais do que apenas uma alteração de URL. Frequentemente coincidem com um redesign, mudança de CMS, reestruturação de conteúdo ou atualização de template. Estas alterações ao nível do conteúdo podem causar independentemente problemas de indexação que se somam aos desafios da migração de URLs.
Quando uma mudança de CMS altera a forma como as páginas são renderizadas, pode introduzir problemas de render de JavaScript que não existiam antes. Se migraste de um CMS renderizado no servidor como WordPress para um framework JavaScript como React ou Vue, páginas que eram anteriormente renderizadas no servidor podem agora ser renderizadas client-side. O Google tem agora de esperar pela sua fila de render de JavaScript para processar páginas que conseguia indexar anteriormente a partir do HTML inicial. Isto por si só pode adicionar dias ao cronograma de indexação para cada página.
Alterações de template podem alterar a estrutura de linking interno do teu site. Um novo design com navegação diferente, widgets de sidebar diferentes, links de rodapé diferentes ou secções de conteúdo relacionado diferentes muda que páginas ligam a que outras páginas. Se links internos importantes foram removidos durante o redesign, algumas páginas podem tornar-se órfãs no novo site mesmo que tivessem linking interno forte no site antigo. Rastreia o teu novo site e compara o grafo de links internos com o site antigo para identificar páginas que perderam suporte de links internos.
Alterações de conteúdo durante a migração, mesmo bem intencionadas, podem afetar a indexação. Se reescreveste títulos de páginas, combinaste ou dividiste páginas, adicionaste ou removeste secções de conteúdo, ou alteraste estruturas de heading, o Google avalia isto como conteúdo novo em vez de o reconhecer como versões atualizadas de conteúdo antigo. Alterações significativas de conteúdo podem fazer com que o Google reavalie a qualidade da página do zero em vez de transferir a autoridade da página antiga através do redirect.
A abordagem mais segura de migração separa a migração de URLs da migração de conteúdo/design. Primeiro, migra os URLs e redirects sem alterar nenhum conteúdo ou template. Deixa o Google processar a alteração de URL e estabilizar a indexação ao longo de quatro a seis semanas. Depois, faz alterações de design e conteúdo gradualmente. Esta abordagem faseada torna fácil diagnosticar problemas porque sabes exatamente que alteração causou que efeito. Fazer tudo de uma vez torna o troubleshooting quase impossível porque problemas de URL, problemas de conteúdo e problemas técnicos estão todos entrelaçados.
Guia passo a passo
Verifica a Implementação de Redirects para Todos os URLs Antigos
Exporta a lista completa de URLs indexados do teu site antigo (de um rastreio pré-migração ou exportação do Search Console). Testa cada redirect usando uma ferramenta de verificação de redirects em massa. Verifica que cada URL antigo redireciona com um 301 (não 302) para o URL novo correto. Identifica e resolve cadeias de redirect (mais de um salto), loops de redirect (redirects circulares) e lacunas de mapeamento (URLs antigos a devolver 404). Prioriza resolver redirects para páginas com o maior tráfego, mais backlinks e rankings mais fortes. Cada redirect em falta ou partido é um sinal de ranking perdido.
Configura o Google Search Console para o Novo Site
Verifica o novo domínio ou estrutura de URLs no Google Search Console como uma propriedade de Domínio. Mantém a propriedade do domínio antigo ativa. Se estás a migrar domínios, usa a ferramenta de Alteração de Endereço na propriedade do Search Console do domínio antigo para notificar o Google da mudança. Submete um novo sitemap XML à nova propriedade contendo apenas a nova estrutura de URLs. Verifica que o sitemap foi lido com sucesso pelo Google nas 48 horas seguintes à submissão. Verifica se há quaisquer problemas de segurança ou ações manuais na nova propriedade que possam bloquear a indexação.
Audita o Novo Sitemap para Garantir Exatidão
Descarrega o teu novo sitemap e verifica cada URL nele. Cada URL deve devolver um código de estado 200, não redirecionar para outro URL, e não carregar uma tag noindex. Cruza o sitemap com a tua lista completa de páginas no novo site para garantir que nenhuma página está em falta. Remove do sitemap quaisquer URLs que redirecionem ou devolvam erros. Se o teu CMS gera automaticamente o sitemap, verifica que foi configurado para a nova estrutura de URLs e não está ainda a gerar padrões de URL antigos. Submete o sitemap limpo ao Google Search Console.
Verifica Bloqueadores Técnicos no Novo Site
Verifica que o robots.txt do novo site permite o rastreio de todas as páginas importantes. Verifica que nenhuma tag noindex global foi deixada do ambiente de staging ou desenvolvimento. Muitas plataformas CMS aplicam noindex a ambientes de staging, e esta definição pode persistir após a migração para o URL de produção. Testa o render do novo site usando a ferramenta de Inspeção de URL em cinco a dez páginas em diferentes secções. Verifica que o conteúdo da página faz render corretamente e que nenhum erro de JavaScript ou de carregamento de recursos impede o Google de ver o conteúdo. Verifica a validade do certificado SSL se estás a migrar para HTTPS.
Monitoriza a Transição de Indexação no Search Console
Começando imediatamente após a migração, monitoriza o relatório de Páginas no Google Search Console para ambas as propriedades antiga e nova diariamente durante as primeiras duas semanas, depois semanalmente durante as dez semanas seguintes. Acompanha o número de páginas indexadas na nova propriedade (deve estar a aumentar), o número de páginas indexadas na propriedade antiga (deve estar a diminuir), o número de erros de rastreio em ambas as propriedades, e quaisquer novas razões de "não indexado" que apareçam. Cria uma folha de cálculo a acompanhar estas métricas ao longo do tempo para conseguires identificar tendências e estagnações no processo de transição.
Pede Indexação para Novos URLs de Alta Prioridade
Identifica as tuas 50 a 100 páginas mais importantes (maior tráfego, maior receita, mais backlinks) e verifica que estão indexadas nos novos URLs. Para quaisquer que ainda não estejam indexadas, usa a ferramenta de Inspeção de URL para pedir indexação individualmente. Para sites maiores com centenas ou milhares de páginas importantes, usa a IndexBolt para submeter novos URLs em massa para indexação mais rápida. Prioriza páginas que tinham rankings fortes antes da migração, pois estas são as páginas onde a indexação atrasada tem o maior impacto no negócio.
Investiga e Resolve Lacunas Persistentes de Indexação Após 30 Dias
Após 30 dias, qualquer página que continua não indexada no novo URL tem provavelmente um problema específico para além da transição normal de migração. Para cada página não indexada, verifica: O redirect do URL antigo está a funcionar corretamente? O novo URL devolve um código de estado 200? O conteúdo no novo URL é substancialmente igual ao URL antigo? Há quaisquer novos problemas de canonical, noindex ou render no novo URL? A página está a receber links internos de outras páginas indexadas no novo site? Resolve cada problema individualmente e volta a submeter para indexação. Páginas que continuam não indexadas após 60 dias sem problemas técnicos identificáveis podem precisar de melhoria de conteúdo para atingir os limiares atuais de qualidade.
Problemas comuns e como resolvê-los
URLs antigos ainda a aparecer nos resultados de pesquisa meses após a migração
Causa: O Google ainda não rastreou e processou os redirects para estes URLs. Isto é comum para URLs antigos que eram rastreados com pouca frequência antes da migração ou para sites com contagens muito grandes de URLs. Também pode indicar que os redirects estão a devolver 302 (temporário) em vez de 301 (permanente), o que faz com que o Google mantenha o URL antigo no índice enquanto trata o redirect como temporário.
Solução: Verifica que os redirects são 301 (permanente) em vez de 302 (temporário). Usa a ferramenta de Inspeção de URL na propriedade do Search Console do domínio antigo para pedir novo rastreio de URLs antigos persistentes, o que vai forçar o Google a encontrar o redirect e processá-lo. Se estás a usar a ferramenta de Alteração de Endereço, verifica que está corretamente configurada. Para sites grandes, usa a IndexBolt para submeter os novos URLs diretamente, o que adiciona as novas páginas ao índice em paralelo com o processamento dos redirects.
Novos URLs a aparecer como 'Rastreado - atualmente não indexado' após a migração
Causa: O Google rastreou os novos URLs mas determinou que não cumprem o limiar de qualidade para indexação. Isto pode acontecer quando a migração envolveu alterações significativas de conteúdo, quando o novo template fornece menos conteúdo do que o antigo (por exemplo, removendo conteúdo de sidebar ou secções de posts relacionados), ou quando a avaliação de qualidade do Google do novo site é mais baixa do que do antigo devido a problemas técnicos como velocidade lenta de página ou problemas de render.
Solução: Compara o conteúdo no novo URL com a versão em cache do URL antigo. Identifica que conteúdo foi removido ou alterado. Restaura qualquer conteúdo único que foi retirado durante a migração. Verifica a velocidade da página e Core Web Vitals no novo site, pois uma degradação significativa de performance pode afetar sinais de qualidade. Verifica que o linking interno a partir da navegação do novo site chega a estas páginas. Se o conteúdo é equivalente, submete os URLs através da IndexBolt para pressionar o Google a reavaliar.
Pico massivo de erros 404 no Search Console após a migração
Causa: URLs antigos que o Google estava anteriormente a rastrear estão agora a devolver 404 porque não foram implementados redirects para eles. Isto acontece comumente quando o mapeamento de redirects foi incompleto, cobrindo apenas as páginas mais importantes em vez de todos os URLs antigos. Também acontece quando o servidor antigo ou alojamento é colocado offline antes de o Google ter processado totalmente a migração.
Solução: Audita a lista de erros 404 no Search Console para a propriedade do domínio antigo. Prioriza implementar redirects para URLs 404 que tinham tráfego, backlinks ou rankings significativos (verifica contra os teus dados pré-migração). Para URLs sem tráfego ou backlinks, um 404 é aceitável pois o Google vai naturalmente removê-los do índice. Mantém o alojamento e a configuração de redirects do domínio antigo ativos durante pelo menos seis meses após a migração para garantir que o Google tem tempo de processar todos os redirects. Não desligues o alojamento do domínio antigo prematuramente.
Rankings caíram significativamente após a migração e não estão a recuperar
Causa: Embora não seja estritamente um problema de indexação, quedas de ranking acompanham frequentemente problemas de indexação durante a migração. Causas comuns incluem cadeias de redirect que diluem link equity, redirects em falta para páginas com backlinks, alterações significativas de conteúdo que o Google avalia menos favoravelmente, velocidade de página mais lenta no novo site, problemas de usabilidade móvel no novo design, e perda de structured data ou rich results que conduziam taxas de clique no site antigo.
Solução: Conduz uma comparação abrangente entre os sites antigo e novo. Verifica a profundidade das cadeias de redirect e resolve quaisquer cadeias com mais de um salto. Verifica que todas as páginas com backlinks têm redirects diretos. Compara Core Web Vitals entre sites antigo e novo. Compara a implementação de structured data. Compara a usabilidade móvel. Aborda cada défice. Se o novo site é tecnicamente sólido e equivalente em conteúdo, os rankings tipicamente recuperam dentro de 60 a 90 dias à medida que a confiança do Google no novo site se constrói. Quedas persistentes de ranking para além dos 90 dias indicam uma diferença substantiva de qualidade que precisa de investigação.
Páginas indexadas tanto nos URLs antigos como nos novos em simultâneo
Causa: O Google está no processo de transição mas ainda não processou totalmente o redirect para estas páginas. Isto resulta no mesmo conteúdo a aparecer em dois URLs no índice, o que pode causar confusão de ranking e divisão de tráfego entre URLs antigos e novos. Tipicamente resolve-se naturalmente em quatro a seis semanas mas pode persistir se os redirects forem implementados como 302 em vez de 301.
Solução: Verifica que todos os redirects são 301 (permanente). Se estás a usar redirects 302, muda-os para 301 imediatamente. Usa a ferramenta de Inspeção de URL para verificar tanto os URLs antigos como os novos. Se o URL antigo aparece como indexado com um redirect, o Google está a processá-lo mas ainda não completou a transição. Isto é normal durante as primeiras semanas. Se persistir para além de seis semanas, pede novo rastreio do URL antigo para forçar o Google a processar o redirect. Garante que as canonical tags nos novos URLs são autorreferenciadas (a apontar para si próprias) e não a apontar para URLs antigos.
Dicas de profissional
Não deixes que uma migração de site apague meses de progresso de SEO. A IndexBolt submete os teus novos URLs diretamente ao Google, acelerando a transição do antigo para o novo e minimizando a lacuna de indexação. Submete a tua lista completa de novos URLs imediatamente após a migração e coloca as tuas novas páginas indexadas em horas em vez de esperar semanas para que o Google processe cada redirect.
100 créditos gratuitos. Sem cartão de crédito. Resultados em menos de 24 horas.
Perguntas frequentes
Quanto tempo deve uma migração completa de site demorar a estar concluída da perspetiva do Google?+
A maioria das migrações de site é totalmente processada pelo Google em 60 a 90 dias. Durante as primeiras duas semanas, vais ver uma mistura de URLs antigos e novos no índice. Pela quarta semana, a maioria dos novos URLs deve estar indexada e a maioria dos URLs antigos deve estar a redirecionar. Pela oitava semana, a transição deve estar substancialmente completa com apenas casos extremos remanescentes. Sites muito grandes (milhões de páginas) podem demorar mais porque a capacidade de rastreio do Google é finita. Se a tua migração não se completou substancialmente em 90 dias, há provavelmente problemas técnicos (redirects partidos, rastreio bloqueado ou problemas de render) que precisam de investigação.
Devo usar redirects 301 ou 302 para uma migração de site?+
Usa sempre redirects 301 (permanente) para migrações de site. Redirects 301 dizem ao Google que a mudança é permanente, o que faz com que o Google transfira sinais de ranking para o novo URL e eventualmente remova o URL antigo do índice. Redirects 302 (temporário) dizem ao Google que a mudança pode ser revertida, o que faz com que o Google mantenha o URL antigo no índice e não transfira totalmente a autoridade. Embora o Google tenha afirmado que eventualmente trata 302s de longa duração de forma semelhante a 301s, usar 301 desde o início evita atrasos e ambiguidades. A única razão para usar 302 é se o redirect for genuinamente temporário e planeias restaurar o URL antigo.
Estou a migrar de HTTP para HTTPS. Tenho ainda de fazer todos estes passos?+
Sim, embora as migrações de HTTP para HTTPS sejam o tipo mais simples e o Google as trate da forma mais suave. Continuas a precisar de implementar redirects 301 de todos os URLs HTTP para os seus equivalentes HTTPS, atualizar o teu sitemap para usar URLs HTTPS, verificar a propriedade HTTPS no Google Search Console, e atualizar canonical tags para usar HTTPS. A principal vantagem de uma migração HTTPS é que o Google a encoraja ativamente, por isso o processamento tende a ser mais rápido. A maioria das migrações HTTPS é totalmente processada em três a quatro semanas. No entanto, os mesmos requisitos de mapeamento de redirects, sitemap e monitorização aplicam-se.
O que acontece aos meus backlinks quando migro para um novo domínio?+
Backlinks ao teu domínio antigo continuam a passar valor ao teu novo domínio através de redirects 301, mas há alguma perda de valor no processo. O Google confirmou que redirects 301 passam a maioria do link equity, mas a quantidade exata não é divulgada. Alguns estudos de SEO sugerem uma perda de 10-15% por salto de redirect. Para maximizar a preservação de valor de backlinks, implementa redirects 301 diretos de um único salto de cada URL antigo para o seu novo equivalente. Para os teus backlinks mais importantes (dos domínios de maior autoridade), considera contactar o site com o link e pedir-lhes que atualizem o link para apontar diretamente para o teu novo URL, contornando o redirect por completo.
Posso migrar o meu site em fases, fazendo uma secção de cada vez?+
A migração faseada é possível mas adiciona complexidade. Migrar uma secção de cada vez (por exemplo, /blog/ primeiro, depois /produtos/, depois o resto) significa que o Google tem de processar várias rondas de alterações em vez de uma alteração abrangente. A vantagem é que limita o raio de explosão de quaisquer erros. Se algo correr mal com a migração do blog, as tuas páginas de produto não são afetadas. A desvantagem é que o cronograma total de migração é mais longo, e gerir redirects torna-se mais complexo quando algumas secções estão na nova estrutura enquanto outras ainda estão na antiga. Para a maioria dos sites, uma única migração bem planeada é preferível a uma abordagem faseada.