Padrões de SEO para headless WordPress: as sete coisas que a maioria das migrações estraga
O headless WordPress vende-se pelos Core Web Vitals, pela reutilização de conteúdo e pela rapidez editorial. Se ninguém estiver atento, enterra pelo caminho sete sinais de SEO concretos. Já fizemos migrações destas em número suficiente para saber quais custam semanas de recuperação e quais se mantêm certas de forma mecânica.
Este artigo é a lista de verificação. Não substitui o pilar do serviço headless WordPress, onde está o argumento de arquitetura. É o que verificamos antes, durante e depois de cada migração, por esta ordem.
Em resumo
- Preserve os URLs canónicos ao nível do URL completo, não apenas do slug.
- Preserve o hreflang no HTML, não só no sitemap.
- Renderize as meta tags e o JSON-LD no servidor, não no cliente.
- Migre o histórico de redirecionamentos antes de mudar os URLs, não depois.
- Mantenha um único sitemap como fonte de verdade, não dois.
- Esconda a origem WordPress do índice dos motores de pesquisa.
- Transporte o texto alternativo das imagens e os dados estruturados de imagem.
Como manter os URLs canónicos numa migração headless
Um URL canónico é uma promessa. Cada link externo, cada entrada no índice do Google, cada partilha nas redes sociais conta com ele. Uma migração headless que corta discretamente um segmento do caminho, muda maiúsculas e minúsculas ou reordena os parâmetros de consulta acabou de quebrar todas essas promessas sem que ninguém dê por isso.
Duas regras. Primeiro, recolha o conjunto completo de URLs canónicos da instalação WordPress antiga antes de tocar no front-end. Exportamos cada artigo, página e página de taxonomia publicados com o URL que o Google tem indexado; essa é a fonte de verdade. Segundo, escreva o canónico na resposta HTML do front-end headless, e não numa alteração ao <head> feita no cliente. Os motores generativos e os motores de resposta analisam o HTML inicial; as meta tags alteradas no cliente não existem para eles.
Se tiver mesmo de mudar um URL, faça um redirecionamento 301 do antigo para o novo e mantenha-o durante pelo menos um ano.
Tags hreflang no HTML do headless WordPress
Os sites WordPress multilingues usam WPML, Polylang ou uma solução própria para gerir as traduções. O mapeamento acaba correto na base de dados. O front-end headless tem depois de renderizar <link rel="alternate" hreflang="..."> para cada variante de idioma na resposta HTML.
O padrão que escapa à maioria das agências: o hreflang tem de ser autorreferencial. A página em inglês lista-se a si própria e todas as alternativas traduzidas. A página em polaco lista-se a si própria e todas as alternativas. As duas listas coincidem. Ferramentas como o relatório de segmentação internacional da Search Console assinalam a discrepância quando um dos lados se esquece de algo.
Tratamos a geração do hreflang como parte do build, e não como uma decisão em tempo de execução. O mapa de caminhos é calculado no build e convertido em hash, e qualquer desvio faz falhar o build.
Renderização no servidor das meta tags e do JSON-LD
A regressão de SEO mais comum que vimos em migrações headless: meta tags e JSON-LD inseridos por JavaScript depois de a página carregar. O navegador vê-os. O Googlebot por vezes vê-os. Os motores generativos, os assistentes de voz e a maioria dos crawlers de LLM normalmente não.
Duas regras. Renderize as meta tags, o canónico, o Open Graph e cada bloco JSON-LD de Schema.org na resposta HTML inicial. Com Astro, é esse o comportamento predefinido. Com Next.js, significa renderizar no servidor (metadados do App Router, ou o caminho antigo com getServerSideProps) e não depender de novas execuções de next/head no cliente.
O mesmo se aplica às imagens: um elemento <img> com alt e src no HTML é indexável. Um <img> injetado depois de um efeito no cliente é invisível para a maioria dos crawlers e para os pipelines de dados de treino de IA.
Reutilizar o JSON-LD do Yoast no headless WordPress
O WordPress com Yoast SEO ou Rank Math já produz bom JSON-LD de Article, Product e Organization. Numa migração headless, a tentação é reescrevê-lo do zero no front-end. Resista.
Leia o JSON-LD existente a partir da origem WordPress, através do endpoint REST ou GraphQL. Passe-o adiante. Acrescente apenas o que o front-end sabe legitimamente e o WordPress não (por exemplo, carimbos temporais do build para dateModified, se o seu fluxo editorial não mexer nas datas). Dois sistemas a gerar JSON-LD sobreposto é o caminho para os relatórios de resultados enriquecidos da Search Console começarem a falhar.
Nas nossas próprias páginas usamos os componentes da fase 0 em src/components/seo/: DirectAnswer, FAQ e Quote. Cada um emite o seu próprio JSON-LD mínimo, sem se sobrepor ao schema Article da página.
Como migrar os redirecionamentos antes de mudar os URLs
A ordem importa. A lista de verificação pré-migração recolhe todos os redirecionamentos internos e externos, incluindo os silenciosos (/wp-content/... para /uploads/..., redirecionamentos por código de país, variantes AMP). O novo front-end publica esses redirecionamentos no dia zero, antes da passagem pública para os novos URLs.
No Cloudflare Pages, mantemos o ficheiro _redirects abaixo do limite da plataforma de 2000 regras. Um build que ultrapassasse o limite falha. Tudo o que precisar de mais de 2000 regras vai antes para um Worker com lógica de redirecionamento com parâmetros.
Quando o DNS público finalmente muda para o novo front-end, nenhum redirecionamento é novo em produção: cada regra foi testada no build durante semanas antes da mudança.
Um único sitemap XML para headless WordPress
O WordPress 5.5 acrescentou um /wp-sitemap.xml predefinido. O Yoast SEO e o Rank Math acrescentam os seus. A framework de front-end headless também gera um sitemap. Três sitemaps no mesmo domínio é a receita para deixar a Search Console de cabeça perdida.
A regra: escolha um sitemap canónico e desative ou redirecione os restantes. Normalmente geramos o sitemap na framework de front-end, para que os URLs correspondam exatamente ao site público, e redirecionamos com 301 o sitemap da origem WordPress para o do front-end. A origem WordPress torna-se assim invisível para a pesquisa.
Como aplicar noindex ao backend do headless WordPress
Uma migração headless deixa a origem WordPress a funcionar, normalmente num subdomínio ou num hostname privado. Continua a servir HTML renderizado, tem um sitemap funcional e responde a pedidos REST. Os motores de pesquisa que encontrem essa origem indexam-na como duplicado do site público, e o duplicado não será o que posiciona.
Três controlos. O robots.txt da origem bloqueia todos os caminhos exceto os endpoints REST e GraphQL. A origem envia X-Robots-Tag: noindex, nofollow nos cabeçalhos HTTP de cada resposta HTML. O sitemap da origem é removido ou devolve 410.
Se a sua origem estiver no mesmo domínio que o site público, sob um prefixo de caminho (por exemplo, /wp-admin/ ou /wp/), aplicam-se os mesmos controlos, limitados a esses caminhos.
Guias relacionados sobre SEO em headless WordPress
Este artigo apoia o pilar do serviço headless WordPress. Para o momento da decisão, veja Headless WordPress, Next.js vs Astro 2026. Para a questão mais ampla da visibilidade, incluindo citações em LLM, o guia de visibilidade em IA e LLM é a nossa descrição de referência do que entregamos em AEO e GEO sobre estas bases de SEO.
