Sitemap e canonical em headless WordPress: uma única fonte de verdade, servida pelo front-end
Dois dos sete padrões de SEO para headless WordPress merecem um artigo próprio, porque são os primeiros a falhar e falham em silêncio. O sitemap e o URL canónico são os dois sinais em que o Google mais confia para perceber o que é este site e qual é o URL verdadeiro. Uma implementação headless que erre em qualquer um deles perde o posicionamento que a migração devia preservar.
Este artigo torna o padrão concreto. Parte do princípio de que a decisão de arquitetura (Astro ou Next.js segundo a matriz de decisão) já foi tomada.
Em que consiste o padrão de sitemap e canonical em headless, num parágrafo?
Gere o sitemap a partir da framework de front-end, com URLs que correspondem ao site público real. Apresente o URL canónico como <link rel="canonical"> no head do HTML, com origem no WordPress (Yoast ou Rank Math) e emitido pelo front-end. Desative ou redirecione com 301 o sitemap e o canonical da origem WordPress. Um sitemap, um canonical por página, ambos gerados no servidor.
Porque é que os sites headless WordPress acabam com dois sitemaps?
O WordPress 5.5 introduziu /wp-sitemap.xml como funcionalidade do núcleo. Desde então, todas as instalações WordPress o têm ativo por predefinição. Os plugins de SEO (Yoast, Rank Math) geram os seus próprios sitemaps, que substituem ou complementam o do núcleo. Uma implementação headless que ignore isto acaba com três sitemaps no mesmo nome de anfitrião:
/wp-sitemap.xmldo núcleo do WordPress./sitemap_index.xmldo Yoast ou do Rank Math./sitemap.xmlda framework de front-end.
O Search Console vê sobreposição, por vezes assinala inconsistências, e os URLs efetivamente indexados passam a depender do sitemap que o Google lê primeiro nesse dia. A correção é mecânica:
- A framework de front-end gera o sitemap canónico num único caminho conhecido (usamos
/sitemap-index.xmlporque o Cloudflare Pages o serve sem problemas). - O sitemap da origem WordPress é desativado (o Yoast e o Rank Math têm ambos uma opção para isso) ou redirecionado com 301 para o sitemap do front-end.
- O sitemap do núcleo em
/wp-sitemap.xmltambém é redirecionado com 301 para o equivalente no front-end.
Depois da transição, só um sitemap responde 200 OK. Os restantes devolvem 301 ou 404.
Como se constrói o sitemap do front-end em headless WordPress?
Para um front-end em Astro ou Next.js há duas opções reais:
Geração durante o build. O build do front-end vai buscar à origem WordPress os URLs de todos os artigos, páginas e termos publicados, ordena-os e emite o XML. Funciona para sites com um ritmo de publicação previsível (a maioria). A invalidação da cache resolve-se acionando um novo build a cada publicação.
A pedido, no edge. Uma rota de Cloudflare Worker gera o sitemap a cada pedido, lendo uma lista de URLs em cache que a origem WordPress envia por webhook a cada publicação. Serve sites com uma frequência de publicação tão alta que o tempo de build seria um problema.
Por predefinição, optamos pela geração durante o build. O padrão com Worker fica reservado para sites que publicam mais do que algumas vezes por hora.
Como deve ser apresentado o URL canónico num front-end headless?
O URL canónico tem de estar no head do HTML, na resposta inicial do servidor, antes de correr qualquer script do lado do cliente. O padrão:
<link rel="canonical" href="https://example.com/headless-wordpress-for-woocommerce/" />Três regras.
Primeira: gerar no servidor. O Astro gera-o a partir do frontmatter da página ou do layout. O Next.js gera-o a partir de metadata (App Router) ou de <Head> em caminhos com getServerSideProps. O que deve evitar é atualizar o URL canónico num efeito do lado do cliente; os motores generativos e muitas superfícies AEO leem apenas o HTML inicial.
Segunda: obtê-lo do WordPress. O Yoast e o Rank Math expõem ambos o URL canónico por artigo via REST. O front-end obtém-no durante o build (ou a cada pedido) e apresenta-o no HTML. O WordPress continua a ser a fonte de verdade.
Terceira: autorreferencial por predefinição. Cada URL declara-se a si próprio como canónico, salvo se houver um motivo explícito para apontar para outro (arquivos paginados, URLs filtrados com parâmetros, conteúdo sindicado). Quando aponta para outro URL, o canonical de destino aponta para si mesmo.
Que casos limite de sitemap e canonical prejudicam o SEO headless?
- Barra final inconsistente. Os permalinks do WordPress terminam normalmente em
/. A framework de front-end pode, por predefinição, não usar barra final. Escolha uma variante, redirecione a outra e nunca deixe que ambas existam. - HTTP vs HTTPS, www vs domínio raiz. Normalmente resolvido na CDN, mas o URL canónico tem de declarar a variante escolhida. Declaramos
https://no domínio raiz; tudo o resto é redirecionado com 301 para lá. - URLs filtrados (pesquisa facetada no catálogo). Geram muitas vezes milhares de variantes de URL pobres. O canonical aponta para o URL base sem filtros; também têm
noindexpara ficarem fora do sitemap. - Arquivos paginados. A página 2, a página 3 e seguintes têm cada uma canonical para si mesma, com
rel="prev"erel="next"para maior clareza. Algumas equipas apontam o canonical para a página 1; assim, páginas únicas saem do índice. Não recomendamos. - Conteúdo traduzido. Cada versão linguística tem canonical para si mesma, com
<link rel="alternate" hreflang="...">para as restantes. O mapa hreflang é autorreferencial e tem de ser coerente em todas as versões linguísticas.
Como validar o sitemap e o canonical antes de ir para produção?
Duas verificações que fazemos em cada implementação headless WordPress:
Comparação de sitemaps. Gere o novo sitemap e compare o conjunto de URLs com o sitemap WordPress antigo. Tudo o que falte no novo é uma lacuna de conteúdo. Tudo o que seja novo é suspeito de regressão (muitas vezes um rascunho ou um artigo privado a vazar).
Amostra de canonicals. Para 50 páginas com mais tráfego, peça o URL ao novo front-end e confirme que o canonical no head do HTML corresponde ao próprio URL (ou ao destino esperado, se o canonical apontar intencionalmente para outra página). Uma discrepância é um bug; dez discrepâncias são um padrão que obriga a rever o build do front-end.
Ambas as verificações correm em CI. Um novo build que falhe qualquer uma delas não é publicado.
Artigos relacionados sobre SEO em headless WordPress
Ancorado na lista de verificação dos padrões de SEO para headless WordPress. Complementa o pilar do serviço headless WordPress e a matriz de decisão Next.js vs Astro para as decisões mais amplas sobre o build.
