Migração de WordPress para Next.js sem perder um único ranking.

Honestamente? Principalmente porque o Lighthouse nunca chega lá.

Passei muitas manhãs explicando aos fundadores por que o site Elementor construído com carinho deles continua estacionado em 62 no PageSpeed Insights mesmo depois de três plugins de cache, uma CDN e uma mudança de hospedagem recente. Existe um teto. Você consegue levar um front-end WordPress clássico para o baixo 80 se realmente se importar, mas toda atualização de plugin é um risco de regressão e toda versão de page builder vem com mais meio-megabyte que você não pediu.

Os times que vejo migrar se dividem em três grupos bem definidos, e quase nunca se sobrepõem.

O grupo de performance

Um site de marketing SaaS em Series-A, atualmente na WP Engine, pagando por Elementor Pro mais três packs de add-ons. Lighthouse 64 no mobile. INP de 380 ms. Eles têm um time de conteúdo que publica dois posts por semana e um time de engenharia que quer fazer deploy de fluxos de onboarding, não patches do WordPress. A reconstrução em Next.js os leva a 96, e os engenheiros param de mexer em wp-admin.

O bucket de engenharia

Três engenheiros TypeScript. Um deles está de on-call para o site de marketing. Eles abrem wp-admin uma vez a cada duas semanas e xingam. Todo aquele "é PHP 7.4 ou 8.1, qual versão do WooCommerce a agência nos deixou" é um custo para pessoas que felizmente fariam deploy em Astro pela metade da agitação. Migre, dê a eles um repo Next.js ou Astro com CI adequado, e o on-call fica menor.

O bucket de segurança

Menos comum, mais decisivo. Um mandato de nível de conselho que superfícies públicas não devem rodar PHP. Ou um incidente de segurança em que um plugin atrasou três semanas para patch. WordPress headless em uma origem não-pública satisfaz a política sem forçar o time editorial a aprender um novo CMS. O wp.example.com fica privado; o front-end é apenas um site estático no Vercel. A maioria dos pen tests deixa de ser interessante.

Três. Genuinamente três, não o tipo de página de marketing que tudo desaba em mesmo escopo. Cada um se adequa a um time diferente.

Caminho 1 — mantenha WordPress, substitua o front-end

Headless. WordPress fica como a superfície de editor. Yoast continua fazendo sua coisa no admin. ACF continua fazendo sua coisa no admin. O site público é reconstruído em Next.js ou Astro e puxa conteúdo via WPGraphQL. Editores mal percebem o dia da migração além da barra de URL mostrando o novo domínio do front-end. Este é o caminho mais comum que faço escopo; cerca de dois terços das migrações recentes seguiram esse caminho.

Quando é certo: o time editorial está feliz no WordPress, o problema de engenharia é puramente front-end, e você não quer migrar doze mil páginas de metadata do Yoast.

Caminho 2 — sair do WordPress completamente

Migre tudo para Sanity, Payload, Storyblok ou Contentful. Desligue o WordPress no lançamento. Codebase mais novo, modelo de conteúdo mais limpo, nenhum PHP em lugar nenhum. O custo da migração é maior porque você está movendo conteúdo, não apenas reconstruindo o front-end. Vale a pena quando o time editorial especificamente quer sair do WordPress, ou quando o modelo de conteúdo precisa de mais rigor do que o ACF flexible content consegue oferecer.

Quando é o certo: você realmente quer um CMS diferente, não apenas um front-end diferente.

Caminho 3 — híbrido

Alguns conteúdos ficam no WordPress, outros se movem para outro lugar. Padrão de exemplo real: blog permanece no WP porque o time editorial é maduro e o Yoast está fazendo um trabalho real; páginas de produtos se movem para Payload porque o schema precisa de relações e validação adequadas. Front-end é uma única app Next.js lendo de ambos os backends. Mais arquitetura, mas às vezes é a resposta certa.

Quando é o certo: duas formas de conteúdo genuinamente diferentes no mesmo site, e forçar ambas em um único CMS está piorando a vida de alguém.

É aqui que as migrações vivem ou morrem, e é também a parte que os times rotineiramente economizam. Sem um mapa completo você perde rankings no primeiro dia. Com um mapa parcial você os perde lentamente durante seis semanas enquanto se convence de que a queda é apenas sazonalidade.

O mapa é construído a partir de três fontes independentes antes de qualquer código ser enviado.

1. Exportação do Search Console — cada URL que o Google rastreou e considerou indexável nos últimos 16 meses. Esta é a lista canônica do que o Google atualmente espera encontrar no seu domínio.
2. Exportação do Ahrefs ou Semrush — todas as URLs com pelo menos um domínio referenciador apontando para ela, ordenadas por contagem de domínios referenciadores. Essas são as URLs onde a preservação de 301 importa mais. Se você 404 uma página com 200 backlinks, acabou de jogar fora 200 backlinks.
3. Sitemap do WordPress — sua exportação atual do sitemap XML. Captura páginas que podem não ter backlinks ou tráfego orgânico, mas ainda estão na estrutura. Útil como uma terceira passagem para encontrar qualquer coisa que as duas primeiras perderam.

Três listas, deduplicadas, mapeadas para novas URLs, entregues como 301s em vercel.json ou netlify.toml na edge. Não 302s. Não redirecionamentos impulsionados por JavaScript. Não uma meta refresh. URLs genuinamente aposentadas recebem 410. URLs que mudaram de slug recebem 301. O linter de build falha no deploy se alguma URL anterior à migração estiver faltando no mapa.

Já vi uma migração de 5 mil páginas perder 60% de seu orgânico em oito semanas porque o mapa de redirecionamento estava 87% completo e "o resto não vale a pena se preocupar." Os 13% valiam a pena. Sempre valem.

Auditoria de plugins no primeiro dia. Todo plugin ativo vai para um de quatro buckets, e o bucket decide o trabalho.

Permanece como está

Plugins que rodam server-side e nunca tocam o front-end público. WP Migrate DB, BackWPup, analytics server-side, gerenciamento de roles. Continuam funcionando porque nada do seu trabalho envolve renderizar HTML para um visitante. Cerca de 20-25% da contagem de plugins geralmente cai aqui.

Substituído por código

Plugins que injetam HTML ou JavaScript no front-end. A maioria dos plugins de SEO (os transportes de metadados, a saída front-end é customizada). A maioria dos plugins de formulário (substituídos por endpoints Next.js ou por ConvertKit / HubSpot / Mailchimp). A maioria dos plugins de schema (substituídos por templates feitos à mão que emitem JSON-LD mais limpo mesmo assim). Cookie banners são reescritos em TypeScript. Cerca de 30-40% da contagem de plugins.

Substituído pelo serviço

Plugins que envolvem um terceiro. O plugin de embed do HubSpot se torna uma chamada da HubSpot Forms API. O plugin de pagamento Stripe se torna Stripe Elements. Zapier e Make ficam onde estão porque vivem fora do WordPress mesmo assim. Cerca de 10-15% da contagem.

Cortado completamente

Plugins que existem puramente porque o front-end do WordPress precisava deles. Plugins de cache (Vercel cuida disso). A maioria dos plugins de segurança (a superfície de ataque pública desapareceu). Plugins de otimização de performance (preocupação do tempo de build agora). E o sempre divertido grupo "Não tenho ideia de por que isso está aqui, está desativado há dois anos mas nunca deletamos". As contagens de plugins no lado do WordPress geralmente caem 70-80% após a migração. Isso é parte do ganho.

Prévia e rascunhos

Editores clicam em Preview no wp-admin. WordPress gera um token JWT de prévia. O front-end Next.js lê o token, busca o rascunho via WPGraphQL contornando o cache estático, e renderiza. URLs de rascunho são assinadas, nunca indexáveis, nunca em cache publicamente. A UX de prévia em um clique permanece exatamente como era. A maioria dos editores nunca percebe o dia da migração no lado editorial.

Comentários, revisões, papéis

Intocado no back-end. Comentários em posts podem ficar nativos do WordPress e renderizar headless via WPGraphQL, ou ser substituídos por Disqus / Giscus / um sistema customizado se sua equipe quisesse mesmo assim. Revisões são inalteradas — cada post ainda tem seu histórico completo acessível pelo editor do WordPress. Papéis de usuário, permissões, setups multi-autor, tudo preservado.

Yoast e Rank Math

Ambos transportam. Yoast SEO para WPGraphQL expõe todos os campos — palavra-chave de foco, meta title, meta description, canonical, OG, Twitter card, schema breadcrumb — como GraphQL consultável. Rank Math tem o equivalente. O layout Next.js lê a resposta tipada e renderiza meta tags idênticas às que Yoast ou Rank Math teriam gerado no WordPress clássico. Editores continuam editando na mesma UI do plugin; a migração é invisível do lado deles.

Semana 1: discovery e scoping

Auditoria de plugin. Auditoria de conteúdo. Search Console + exportação Ahrefs para fonte do mapa de redirecionamentos. Baseline de performance atual. Decisão sobre caminho um versus dois versus híbrido. Output: SOW escrito com preço fixo e cronograma de pagamento por milestone. No final da semana um você sabe exatamente o que está pagando.

Semanas 2-4: fundação

Repos no seu GitHub, não no nosso. Hosting em suas contas. WPGraphQL (ou novo CMS) configurado. Scaffolding Next.js ou Astro entregue. SEO linter e ingestão do mapa de redirecionamentos conectados. Design tokens migrados. No final da semana quatro a fundação é real e o time está entregando páginas.

Semanas 5-10: build

Templates portados, página por página. Looms diários do lead engineer no seu Slack. Call de revisão mid-build semanal. Tickets em Linear ou Jira ou o que você já usa. Edge cases capturados conforme surgem. Este é o meio entediante do projeto onde a maioria do código real é escrito.

Semanas 10-12: QA pré-launch

Cross-browser manual. Auditoria mobile. Auditoria de acessibilidade em WCAG AA. Core Web Vitals em dispositivo real (não Lighthouse de lab). SEO linter verde. Schema validator verde. Mapa de redirecionamentos verificado URL-por-URL contra exportação do Search Console. O plano de cutover escrito e ensaiado.

Semana 12: lançamento

Cutover de DNS em uma janela que você escolhe. A maioria faz numa terça ou quarta de manhã, baixo tráfego. Front-end já está rodando em um domínio de staging; o cutover é um flip de DNS. Engenharia de prontidão por 24 horas. Search Console enviado com o novo sitemap. Ahrefs e GA anotados.

Semanas 12-16: hyper-care

Monitoramento diário do Search Console para anomalias de índice, avisos de cadeias de redirecionamento, erros de schema. Comparação semanal de tráfego contra a baseline. Correções de bugs priorizadas sobre features. Na semana 16 o site está estável e a gente faz a transição limpa ou entra em um plano de cuidado contínuo.