Três anos atrás, um cliente me ligou numa quinta-feira à tarde em pânico absoluto. Ele havia passado uma migração de Drupal para WordPress para uma agência de desenvolvimento barata, o site foi ao ar numa sexta-feira e na segunda-feira o tráfego orgânico dele tinha caído 67%. Desaparecido. Seis anos de equity em SEO, simplesmente... evaporado. Sem redirecionamentos. Milhares de URLs quebradas. Orçamento de crawl do Google incinerado.
Aprendizado principal: migrações de Drupal para WordPress falham no mapeamento de URLs e tradução de taxonomia, não na mudança de CMS; entregue um mapa de redirecionamento completo e transporte de metadados para preservar rankings.
Já reconstruí esse tipo de desastre mais vezes do que tenho vontade de contar. Depois de mais de 12.000 migrações na Seahawk Media, posso dizer com bastante confiança: a mudança técnica de Drupal para WordPress é na verdade a parte fácil. A preservação de SEO é onde tudo dá errado, e onde absolutamente não precisa dar.
Este é o manual que sigo. Todas as vezes.
---
Por Que Migrações de Drupal para WordPress São um Campo Minado de SEO
Drupal e WordPress geram URLs de forma diferente. O sistema de path padrão do Drupal, combinado com módulos como Pathauto, geralmente produz estruturas de URL que não têm nenhuma sobreposição com o que WordPress gera nativamente. Um nó Drupal em /content/our-services/web-design vira /our-services/web-design ou até /web-design no WordPress, dependendo de como você configura os permalinks. São URLs diferentes. Google as vê como páginas diferentes. Sem um redirecionamento, a antiga está morta.
E não é só URLs. O sistema de taxonomia do Drupal mapeia para categorias e tags do WordPress, mas não perfeitamente. Tipos de conteúdo personalizados no Drupal viram Custom Post Types no WordPress, e se você não criar esses CPTs antes de migrar, seu conteúdo cai no bucket errado completamente. Já vi um site de notícias powered by Drupal onde 800 nodes "article" foram importados como Posts padrão do WordPress, sobrescrevendo a estrutura de arquivo customizada que seu linking interno dependia.
Aqui está o que a maioria dos devs ignora: toda decisão estrutural que você toma no WordPress antes da migração afeta diretamente quais redirecionamentos você vai precisar depois. Acerte a arquitetura primeiro. Redirecionamentos são um patch, não um plano.
---
Passo 1: Auditoria Pré-Migração, Saiba o que Você está Movendo Antes de Mover
Não mexa na instalação Drupal até ter um crawl completo do site ao vivo. Eu uso Screaming Frog configurado para fazer crawl de até 500.000 URLs (a versão paga). Exporte tudo: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, links internos recebidos, contagens de palavras.
Também puxe seus dados do Google Search Console. Filtre por cliques dos últimos 16 meses (não 3, não 6-16, porque você quer pegar conteúdo sazonal). Exporte toda URL que recebeu pelo menos um clique. Estas são suas URLs protegidas. Perder rankings em qualquer uma delas e o cliente vai notar.
O que estou especificamente procurando:
- Conteúdo duplicado já existente no site Drupal (corrija antes de migrar, não depois)
- Páginas de conteúdo fino com menos de 200 palavras que não ranqueiam para nada, essas podem ser consolidadas ou deletadas em vez de migradas
- Padrões de URL não-padrão como URLs /node/1234 que Drupal às vezes expõe mesmo quando Pathauto está ativo
- Páginas de arquivo de taxonomia que ranqueiam, caminhos /tags/, /category/, /topic/ que têm impressões reais no Search Console
Este último pega as pessoas constantemente. Páginas de termo de taxonomia Drupal frequentemente rankeam para queries de cauda longa. Se você não recriar equivalentes de arquivos de taxonomia WordPress e redirecionar os paths antigos, você acabou de jogar fora tráfego passivo.
---
Passo 2: URL Mapping, A Planilha que Ninguém Quer Construir
Entediante? Sim. Inegociável? Também sim.
Construa um mapa de URL no Google Sheets (ou Airtable se preferir, já usei os dois). Coluna A é toda URL Drupal. Coluna B é a URL WordPress correspondente para a qual ela será resolvida. Coluna C é um status: exact match, redirect needed, consolidate, ou delete.
Para um site de 300 páginas, isso leva meio dia. Para um site de 8.000 páginas, que a Seahawk trabalhou para um cliente de educação superior lá em 2021, leva um time de três pessoas mais ou menos quatro dias de trabalho mais uma sexta-feira muito tediosa. Vale a pena toda vez.
Algumas regras que sigo:
- Preserve slugs sempre que possível. Se Drupal tem /blog/how-to-fix-crawl-errors, faça WordPress usar o mesmo slug. Na maioria das vezes você consegue. As configurações de permalink em WordPress Configurações → Permalinks permitem que você combine qualquer padrão que Drupal estava usando.
- Nunca redirecione para a homepage. Devs preguiçosos fazem isso. Mata link equity e confunde usuários. Toda URL antiga recebe um destino específico.
- Fique atento a URLs paginadas. Paginação do Drupal parece ?page=1. WordPress usa /page/2/. Mapeie essas ou deixe como 404s (o que geralmente é tranquilo, páginas paginadas raramente têm link equity significativo, mas confirme no GSC primeiro).
- Documente as query strings separadamente. Coisas como /search?keys=wordpress não precisam de redirecionamentos. /events?date=2023-06 talvez precise, dependendo de essas páginas estarem rankando.
---
Passo 3: Migração de Conteúdo, FG Drupal to WordPress e o que Realmente Acontece
O plugin FG Drupal to WordPress faz o trabalho pesado na maioria das migrações. Ele se conecta diretamente ao seu banco de dados Drupal, puxa nodes, usuários, termos de taxonomia e mídia. Para Drupal 7, funciona muito bem. Para Drupal 9/10, você precisa da versão premium, que custa cerca de €99 da última vez que verifiquei. Vale cada centavo comparado à migração manual.
O que o plugin trata bem:
- Conteúdo do corpo do node (incluindo imagens incorporadas se você configurar o caminho de mídia corretamente)
- Termos de taxonomia mapeados para categorias/tags do WordPress
- Custom fields básicos se você estiver na tier premium
O que não funcionará e você precisará corrigir manualmente:
- Drupal Views, essas são layouts/queries de página customizadas. Você vai reconstruir essas no WordPress usando plugins como WPGridBuilder ou apenas loops WP_Query customizados
- Webforms, mapeie estas para Gravity Forms ou WPForms manualmente; a lógica não se transfere
- Grupos de campos complexos, a Field API do Drupal suporta algumas estruturas de dados genuinamente estranhas. Você precisará exportar essas para CSV e importar via WP All Import
- Regiões de conteúdo em blocos, o sistema de blocos do Drupal não tem nada a ver com widgets/FSE blocks do WordPress. Decisão de design, não uma tarefa de migração
Uma coisa que sempre faço após FG Drupal to WordPress terminar: executar uma contagem de linhas. Quantos nodes havia no Drupal? Quantas entradas de posts/CPT agora estão no WordPress? Elas devem corresponder (menos qualquer coisa que você deliberadamente excluiu). Uma discrepância de 3% em um site com 5.000 nodes é 150 páginas faltando. Vá encontrá-las.
---
Passo 4: Implementando Redirecionamentos Sem Destruir Seu Servidor
Uma vez que o mapa de URL está construído e o conteúdo está ativo no ambiente de staging do WordPress, é hora dos redirecionamentos. Duas ferramentas: o plugin Redirection para sites menores (menos de ~1.000 redirecionamentos) e regras .htaccess para qualquer coisa maior em Apache, ou blocos nginx.conf em Nginx.
Por que a divisão? O plugin Redirection processa redirecionamentos via PHP, o que significa um hit no servidor para cada verificação de redirecionamento. Com 5.000 redirecionamentos e 50.000 pageviews diárias, isso é overhead real. Redirecionamentos em nível de servidor são uma ordem de magnitude mais rápidos.
Para migrações grandes, exporto o mapa de URL do Google Sheets, escrevo um script rápido para gerar os blocos RewriteRule e os coloco em .htaccess antes do go-live. Leva 20 minutos. Economiza horas debugando um site lento pós-lançamento.
Uma coisa que as pessoas não pensam: cadeias de redirecionamento. Se o Drupal já tinha redirecionamentos em lugar (muitos sites Drupal maduros têm, via módulo Redirect), você precisa encontrá-los e colapsar a cadeia. A → B → C precisa se tornar A → C. A própria documentação do Google é bem clara de que cadeias desaceleram a transferência de PageRank, mesmo que não a eliminem.
---
Passo 5: Pós-lançamento, A Janela de 72 Horas
Saia do ar numa terça ou quarta. Nunca sexta. Aprendi isto da forma difícil com um cliente em 2018, lançamos uma migração de 1.200 páginas numa sexta à noite e descobrimos uma estrutura de permalink mal configurada às 18h. Na segunda, o Google já havia rastreado e indexado uma onda de URLs quebradas.
Aqui está o que monitoro nas primeiras 72 horas:
- Relatório de Cobertura do GSC, fique atento a um pico de 404s. Alguns são esperados (caminhos antigos do sistema Drupal). Um pico em suas money pages não é.
- Re-rastreamento do Screaming Frog, rastreie o site WordPress ao vivo na manhã seguinte ao lançamento. Compare a contagem de URLs com sua baseline anterior à migração.
- Spot-checks de redirecionamento, teste manualmente seus 20 URLs Drupal com maior tráfego do GSC. Cole-os num navegador. Eles chegam onde deveriam?
- Tags canônicas, confirme que o WordPress está gerando a canônica correta em cada página. Yoast e Rank Math fazem isto automaticamente, mas verifique mesmo assim.
- Submissão do sitemap XML, envie o novo sitemap no GSC imediatamente. Não espere o Google encontrá-lo.
Uma coisa que faço e que a maioria das pessoas pula: envie também o antigo XML sitemap do Drupal no GSC após o lançamento, apontando para o domínio antigo ou subdomínio se você o manteve temporariamente. Isso diz exatamente ao Google quais URLs antigas rastrear, seguir os redirecionamentos e atualizar seu índice mais rápido.
---
Etapa 6: A Verificação de Saúde SEO de 30 Dias
Uma migração não termina no lançamento. O índice leva tempo para atualizar. Aqui está o que observo aos 30 dias:
- Mudanças de posição de ranking, use Ahrefs ou Semrush para comparar posições de palavras-chave 30 dias antes da migração versus 30 dias depois. Espere flutuação menor (5-10 posições) em alguns termos. Uma queda de 30+ posições em uma palavra-chave primária precisa de investigação.
- Alvos de backlink, se você tinha backlinks externos apontando para URLs específicas do Drupal, verifique se essas URLs estão redirecionando corretamente. O relatório Lost Backlinks do Ahrefs expõe isso. Alvo de backlink quebrado é equity de link que você está ativamente perdendo.
- Regressão de velocidade de página, sites WordPress às vezes são mais lentos que sites Drupal bem ajustados. Execute uma auditoria Lighthouse nas suas 5 páginas mais importantes e compare com sua baseline pré-migração.
- Taxa de indexação, quantas das suas URLs submetidas estão indexadas? Aos 30 dias, você quer pelo menos 80% de suas páginas de conteúdo principal indexadas. Qualquer coisa abaixo de 60% sugere um problema de rastreabilidade (verifique robots.txt e certifique-se de que você não bloqueou acidentalmente o Googlebot em WordPress Settings → Reading).
Seahawk teve um cliente fintech no ano passado onde a verificação de 30 dias revelou 340 páginas de produto tendo sido acidentalmente configuradas como noindex por uma ação em massa do Yoast mal configurada durante a migração. Detectado aos 30 dias: consertável em uma tarde. Detectado aos 6 meses: provavelmente um buraco de ranking que você ainda está tentando preencher.
---
FAQ
Quanto tempo realmente leva uma migração de Drupal para WordPress?
Depende inteiramente do tamanho do site e complexidade do conteúdo. Um site brochura de 50 páginas: 2-3 dias incluindo QA. Um arquivo de notícias com 5.000 páginas com tipos de conteúdo customizados: 6-10 semanas. O trabalho de SEO, auditoria, mapeamento de URL, implementação de redirecionamento, monitoramento pós-lançamento, normalmente adiciona 30-40% a qualquer que seja a estimativa de desenvolvimento principal. Não deixe ninguém te dizer o contrário.
Vou perder posicionamentos após migrar de Drupal para WordPress?
Flutuação de curto prazo é normal e quase inevitável. Se você fez corretamente o mapeamento de URL, redirecionamentos e tags canônicas, a maioria dos rankings se estabiliza dentro de 6-12 semanas. Os sites que vi sofrer perdas permanentes tinham o mesmo problema: sem redirecionamentos, ou redirecionamentos em massa apontando para a homepage. Faça o trabalho. Os rankings voltam.
Devo migrar todo o conteúdo do Drupal ou começar do zero?
Depende do que o conteúdo está fazendo por você. Puxe seus dados de GSC. Qualquer conteúdo com zero cliques nos últimos 16 meses e sem backlinks é candidato para exclusão em vez de migração. Migrar conteúdo fino e de baixo valor incha seu site WordPress e pode diluir o orçamento de rastreamento. Seja implacável. Dito isto, nunca delete uma URL que tem algum backlink externo, mesmo que a página em si seja ruim, redirecione-a para algo relevante.
Qual é o melhor tema WordPress para usar após uma migração de Drupal?
Honestamente, a escolha do tema tem quase nenhum impacto em SEO se você estiver usando HTML bem estruturado e mantendo a velocidade da página sob controle. Eu padronizo GeneratePress pelo seu markup limpo e overhead mínimo, ou Kadence se o cliente quer mais flexibilidade de design. Evite temas page-builder-pesados que geram 400KB de CSS não utilizado em cada carregamento de página.
Preciso de um desenvolvedor ou consigo fazer isso sozinho?
Para um site pequeno com menos de 50 páginas com conteúdo simples e sem tipos de post customizados? Você provavelmente consegue se virar com FG Drupal to WordPress e o plugin Redirection, seguindo os passos acima. Para qualquer coisa maior, ou qualquer coisa com CPTs, taxonomias complexas, ou uma footprint de SEO significativa existente, contratar um desenvolvedor. O custo de consertar uma migração feita errado é sempre maior que o custo de fazer certo da primeira vez.
---
A migração em si é talvez 40% do trabalho. Os outros 60% são a infraestrutura de SEO que você constrói ao redor dela, o mapeamento, os redirecionamentos, o monitoramento, a paciência de observar os dados por 30 dias antes de declarar vitória. Já vi sites WordPress lindamente construídos desaparecerem em buscas porque o trabalho de redirecionamento foi desleixado, e já vi instâncias WordPress precárias, mal temáticas, mantiverem todo ranking porque o mapa de URL foi meticuloso.
Acerte as coisas chatas. O resto tende a seguir.