Em 2026, cerca de 72% dos sites de PME portuguesas ainda assentam em WordPress, segundo dados cruzados da ANACOM e do BuiltWith para o domínio .pt. O problema não é o WordPress em si — é a inércia técnica que acumula: plugins desactualizados, temas pesados, base de dados a rebentar pelas costuras e um Largest Contentful Paint que ronda os 4 a 6 segundos em rede móvel. Quando uma empresa do Porto ou de Lisboa decide finalmente migrar para Next.js, acontece algo previsível: 54% perdem tráfego orgânico nos primeiros 90 dias por falta de uma estratégia de redirects coerente. O Google reindexa, encontra 404, perde sinais de autoridade e o ranking desmorona-se.
Este guia é o checklist que aplicamos na Go To Agency sempre que migramos um site WordPress para Next.js sem sacrificar o posicionamento conquistado ao longo de anos. Está pensado para o contexto português: alojamento na Amen.pt, PTisp, WebTuga ou Webhs, conformidade com o RGPD e a CNPD, e particularidades linguísticas do mercado nacional. Vamos passar por seis etapas concretas, com snippets de código testados em produção e prazos realistas de monitorização.
1. Auditoria exaustiva de URLs com Screaming Frog
Antes de tocar numa única linha de código, é preciso saber exactamente o que existe. A grande maioria das migrações falha porque ninguém fez o inventário completo do site WordPress de origem. Páginas órfãs, anexos PDF, taxonomias de categorias, tags, arquivos por data, paginação de blog — tudo isto tem URLs indexadas que precisam de tratamento.
A ferramenta de eleição continua a ser o Screaming Frog SEO Spider, configurado para rastrear o site WordPress em modo completo. Para sites portugueses com mais de 500 URLs, é obrigatório activar a licença paga (149 libras/ano), porque a versão gratuita pára aos 500 endereços e perde-se a visão global.
Configuração recomendada para WordPress:
- User-Agent: Googlebot (Smartphone) para simular indexação real
- Rendering: JavaScript activado se o tema usar blocos dinâmicos
- Crawl depth: ilimitada, com exclusão de
/wp-admin/e/feed/ - Custom extraction: capturar meta-robots, canonical, hreflang e schema.org
Em paralelo, exportar do Google Search Console o ficheiro Pages dos últimos 16 meses (limite máximo da API). Cruzar este export com o crawl do Screaming Frog dá uma matriz fiável: URLs indexadas com tráfego, URLs indexadas sem tráfego, URLs no sitemap mas não indexadas, e URLs órfãs (com tráfego mas sem ligações internas).
Não esquecer de extrair também o sitemap.xml gerado pelo Yoast ou Rank Math, e os ficheiros media-sitemap.xml para imagens. Em sites WordPress portugueses, é comum encontrar entre 1500 e 4000 URLs únicas para um simples site institucional com blog — números que surpreendem o cliente na primeira reunião.
2. Cartografia 1:1 entre URLs antigas e novas
Esta é a etapa que distingue uma migração profissional de um desastre SEO. Cada URL identificada na auditoria deve ter uma correspondência clara no novo site Next.js. Sem excepções, sem improvisos.
O formato de trabalho é uma folha de cálculo (Google Sheets ou Excel) com as seguintes colunas:
- URL antiga (path completo, sem domínio)
- Estatuto HTTP actual (200, 301, 404)
- Cliques 12 meses (Search Console)
- Impressões 12 meses
- URL nova Next.js
- Tipo de redirect (301 directo, 301 com fusão, 410 gone)
- Responsável validação
A regra de ouro para sites portugueses: nunca mudar a estrutura de URLs durante a migração técnica. Se o WordPress servia /servicos/criacao-de-sites/, o Next.js deve servir /servicos/criacao-de-sites/ ou então redireccionar com 301. Misturar uma refundação editorial com uma migração tecnológica é a receita garantida para perder posições nos próximos seis meses.
Casos típicos a tratar com cuidado especial:
- Arquivos de categoria/tag: se gerarem pouco tráfego, redirecionar para a página de blog principal ou para uma página de categoria nova
- Páginas de autor: geralmente eliminar com 410, excepto se o autor tiver autoridade pessoal (E-E-A-T)
- Paginação
/page/2/,/page/3/: redirecionar para a página 1 ou para a nova estrutura paginada - Anexos PDF e media: manter o path absoluto
/wp-content/uploads/2023/05/ficheiro.pdfou redirecionar para/uploads/2023/05/ficheiro.pdf
Para projetos de refundação técnica entre 800 e 3000 URLs, esta cartografia leva tipicamente entre 12 e 20 horas de trabalho concentrado. Vale cada euro investido — é a única garantia de não desaparecer dos resultados do Google.
3. Implementação dos 301 redirects: next.config.js + Cloudflare
Com a cartografia validada, passamos à implementação. Em Next.js 15, existem três camadas possíveis para servir redirects: next.config.js, middleware, e a edge da CDN (Cloudflare, Vercel ou Fastly). A nossa abordagem standard combina duas:
Camada 1 — next.config.js para redirects estáticos
Para volumes até 1500 redirects, o ficheiro next.config.js é perfeitamente adequado e tem a vantagem de ficar versionado em Git. Exemplo:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/blog/2019/05/criar-site-wordpress/',
destination: '/blog/criar-site-portugal-2026',
permanent: true,
},
{
source: '/category/desenvolvimento/',
destination: '/blog?categoria=desenvolvimento',
permanent: true,
},
// ... mais entradas geradas a partir da folha de cálculo
];
},
};Para gerar este array a partir do Google Sheets, usamos um script Node.js que lê o CSV exportado e produz o ficheiro redirects.json, importado depois no next.config.js. Isto separa o conteúdo (redirects) da configuração e facilita as actualizações.
Camada 2 — Cloudflare Workers para volumes massivos
Acima de 1500 redirects, o build do Next.js começa a sofrer (cold starts mais longos na Vercel). A solução é mover os redirects para a edge, via Cloudflare Bulk Redirects ou um Worker dedicado. Isto também é útil para sites portugueses alojados na Amen.pt ou PTisp que queiram manter Cloudflare como camada de cache.
// cloudflare-worker.js
const REDIRECTS = {
'/wp-content/uploads/2018/ficheiro.pdf': '/uploads/2018/ficheiro.pdf',
'/?p=1234': '/blog/artigo-antigo-2018',
};
export default {
async fetch(request) {
const url = new URL(request.url);
const target = REDIRECTS[url.pathname + url.search];
if (target) {
return Response.redirect(new URL(target, url.origin), 301);
}
return fetch(request);
},
};Atenção a um detalhe que falha frequentemente em sites portugueses: URLs com acentos. O WordPress permite /categoria/programação/ mas o Next.js normaliza para /categoria/programa%C3%A7%C3%A3o/. A regra de redirect tem de cobrir ambas as formas, codificada e descodificada, sob pena de criar loops de redirecionamento. Testar exaustivamente com curl -I -L antes de pôr em produção.
4. Search Console Change of Address e gestão de propriedades
Se a migração mantém o mesmo domínio (caso mais comum em Portugal — empresa.pt continua empresa.pt), não é necessário usar a ferramenta Change of Address. Esta serve apenas para mudanças de domínio (ex: empresa-antiga.com para empresa-nova.pt).
Mas há algo que é obrigatório em qualquer migração:
- Submeter o novo sitemap.xml assim que o site entra em produção, mesmo que o domínio seja o mesmo
- Validar o ficheiro
robots.txt: bloqueou-se acidentalmente/api/mas não/_next/? Erro clássico que custa caro - Usar o URL Inspection Tool nas 30-50 URLs mais importantes (homepage, páginas de serviço, artigos top) para forçar a reindexação
- Monitorizar o relatório Coverage durante 14 dias seguidos, com atenção especial a 404, soft 404 e redirect errors
Para sites com mudança de domínio efectiva, o procedimento adiciona-se:
- Verificar ambas as propriedades (antiga e nova) no Search Console com o mesmo método (DNS é o mais robusto, especialmente com Amen.pt ou PTisp)
- Garantir que os 301 estão activos antes de submeter o Change of Address
- Submeter o pedido em Settings > Change of Address
- Manter o domínio antigo activo por no mínimo 180 dias, idealmente 365
Não esquecer também o Bing Webmaster Tools — sim, em Portugal o Bing pesa apenas 3-4% das pesquisas, mas é tráfego qualificado para certos sectores B2B. O mesmo procedimento de submissão de sitemap aplica-se.
5. Ganhos de desempenho mensuráveis
A justificação real para migrar de WordPress para Next.js raramente é apenas técnica — é o desempenho que gera ganhos SEO directos via Core Web Vitals. Em projetos portugueses que acompanhámos no último ano, os resultados típicos são:
- LCP: de 4,2s (WordPress + Elementor + Astra) para 1,1s (Next.js + ISR)
- INP: de 380ms para 60ms
- CLS: de 0,18 para 0,02
- Tamanho HTML: de 280kb para 45kb
- Requests JS: de 38 para 6
Estes ganhos traduzem-se em métricas de negócio reais: +18% de páginas por sessão, +24% de tempo médio na página, e -32% de bounce rate (média de 8 migrações que medimos entre 2024 e 2026 para PMEs portuguesas).
Para alcançar estes números, há decisões arquitecturais não negociáveis:
- Imagens:
next/imagecom formatos AVIF/WebP, dimensões explícitas, e CDN próprio (Vercel Image Optimization ou Cloudflare Images) - Fontes:
next/fontcom display: swap, subset latino-extended para suportar caracteres portugueses (ã, ç, õ) - Scripts terceiros:
next/scriptcom strategy lazyOnload para tudo o que não seja crítico (cookies, analytics, chat) - Cache: ISR (Incremental Static Regeneration) com revalidate de 3600s para páginas editoriais, 60s para listagens dinâmicas
Um ponto particularmente importante para o contexto RGPD/CNPD: o consentimento de cookies não pode bloquear o LCP. A implementação correcta usa next/script com strategy worker e carregamento condicional após o consentimento, sem prejudicar o render inicial. Ferramentas como Cookiebot ou Axeptio funcionam bem com Next.js 15 desde que sejam carregadas após a hidratação principal.
6. Monitorização 30/60/90 dias pós-migração
O trabalho não acaba no dia do go-live. Os primeiros 90 dias são críticos e exigem um protocolo de monitorização disciplinado. Eis o que acompanhamos sistematicamente:
Dias 1-7: vigilância máxima
- Verificação diária do Search Console (Coverage + Performance)
- Crawl completo com Screaming Frog a cada 48h
- Monitorização de erros 5xx via logs Vercel ou Cloudflare
- Validação manual das 50 URLs com mais tráfego histórico
- Verificação de broken internal links com Sitebulb ou Ahrefs
Dias 8-30: estabilização
- Comparação semanal do tráfego orgânico vs. mesmo período do ano anterior
- Monitorização das posições para 30-50 keywords core
- Verificação das Core Web Vitals reais (CrUX, não Lighthouse)
- Auditoria de schema.org com Rich Results Test
- Correção de eventuais redirects em falta detectados via 404 reports
Dias 31-60: optimização
- Análise dos URLs ainda em discovered, currently not indexed
- Reforço do link building interno para páginas com perda de posição
- Refinamento dos meta-titles e meta-descriptions baseado nas novas SERP
- Implementação de melhorias técnicas adicionais (preload hints, resource hints)
Dias 61-90: consolidação
Aos 90 dias, o tráfego orgânico deve estar nos níveis pré-migração ou superior em pelo menos 10%. Se não estiver, há um problema estrutural que exige análise aprofundada — geralmente um conjunto de redirects mal configurados ou uma penalização algorítmica por thin content herdado do WordPress.
Em Portugal, com a sazonalidade típica do mercado (Agosto particularmente fraco em B2B, picos em Setembro/Outubro), é importante normalizar a comparação com dados YoY (year-over-year) e não apenas MoM (month-over-month). Caso contrário, atribui-se erradamente à migração uma queda que é apenas sazonal.
Conclusão: a migração como investimento, não como custo
Migrar um site WordPress português para Next.js em 2026 não é um capricho tecnológico — é uma decisão de negócio com retorno mensurável: melhor SEO, melhor experiência de utilizador, custos de manutenção mais baixos a longo prazo (sem plugins a actualizar nem vulnerabilidades de PHP), e uma base sólida para integrações modernas (CMS headless, edge functions, AI personalisation).
O risco real está em executar mal a migração, não em executá-la. Os 54% de sites portugueses que perdem tráfego nos primeiros 90 dias fazem-no por uma de três razões: não fizeram cartografia 1:1, não implementaram redirects 301 correctos, ou não monitorizaram durante o período crítico. As três falhas são evitáveis com o checklist deste guia.
Se o vosso projeto de migração WordPress para Next.js precisa de uma execução técnica garantida, com SLA de preservação de tráfego orgânico e acompanhamento 90 dias incluído, contactem-nos via pedido de orçamento. Estudamos cada caso individualmente — número de URLs, complexidade do WordPress de origem, especificidades do alojamento (Amen.pt, PTisp, WebTuga, Webhs ou outro), e prazos do negócio.
