Sitemap e canonical em headless WordPress: uma única fonte de verdade, servida pelo front-end
A inclusão no sitemap é um sinal canonical fraco; redirecionamentos e rel=canonical são mais fortes. Contexto de implementação: padrões de SEO para headless WordPress, falham em silêncio.
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 de um inventário completo de rotas públicas e apresente um canonical no head do HTML. O inventário pode vir do front-end ou de um backend corretamente configurado. Vários ficheiros subordinados coerentes são válidos.
Porque é que os sites headless WordPress acabam com dois sitemaps
O WordPress disponibiliza sitemaps no núcleo desde a versão 5.5. A disponibilidade depende da configuração e de filtros; plugins SEO podem desativar o gerador do núcleo. Verifique os endpoints reais. Três geradores simultâneos não são inevitáveis.
/wp-sitemap.xmldo núcleo do WordPress./sitemap_index.xmldo Yoast ou do Rank Math./sitemap.xmlda framework de front-end.
Vários sitemaps podem coexistir corretamente. Inventários públicos contraditórios precisam de correção, mas o Google não escolhe páginas indexadas apenas pela ordem de leitura dos ficheiros.
Todos os endpoints ativos devem usar um inventário coerente de rotas públicas. Desative geradores desnecessários na origem ou redirecione o XML quando adequado. Vários ficheiros subordinados podem responder 200 num índice de sitemaps.
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.
Apresente canonical no head do HTML inicial através do layout ou da API de metadados. O Google aceita canonical gerado por JavaScript, mas recomenda um sinal claro sem alterações posteriores. O HTML inicial facilita testes reproduzíveis.
Adapte metadados SEO ao mapa público de rotas. O Yoast tem uma API REST documentada; outros plugins exigem uma integração própria suportada. A resposta canonical não utiliza automaticamente os URLs públicos headless.
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
Os filtros precisam de uma política explícita de indexação. Use canonical para duplicados reais e noindex quando pretende excluir uma página. Não aplique ambos indiscriminadamente a todos os filtros.
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.
Definir o contrato dos URLs públicos
O WordPress guarda identificadores de artigos e os seus próprios permalinks. Um front-end headless pode usar outros prefixos de idioma, percursos de categorias ou regras para a barra final. Defina primeiro a correspondência entre ID, idioma e URL público. Essa correspondência pertence à configuração da aplicação. Substituir o domínio de origem não chega quando o percurso também muda. Uma página subordinada no WordPress pode ter um endereço simples no front-end, enquanto um produto pode usar um segmento de categoria traduzido.
Use o mesmo resolver para ligações internas, entradas do sitemap, canonical, alternativas hreflang e identificadores dos dados estruturados. Esta recomendação de arquitetura evita que funções separadas produzam endereços diferentes para o mesmo conteúdo. Mantenha as exceções editoriais explícitas. Um artigo distribuído por parceiros pode apontar intencionalmente para a publicação original. Substituir todos os domínios destruiria essa decisão. Valide destinos externos separadamente dos endereços próprios e rejeite domínios de desenvolvimento ou pré-visualização antes de publicar o HTML.
A API REST do Yoast devolve resultados SEO associados aos URLs do WordPress. Obter esses dados não os adapta automaticamente às rotas do front-end. Escolha entre montar o head com campos estruturados ou consumir HTML verificado da integração. Não apresente um head completo do plugin e acrescente outro canonical no layout. Inspecione a resposta final, porque dois componentes podem emitir o mesmo dado correto e produzir marcação duplicada.
Construir um inventário completo do conteúdo
O gerador deve obter todas as páginas necessárias da API. A primeira resposta de uma coleção de artigos não é o inventário completo. As taxonomias precisam de uma recolha própria quando o front-end publica arquivos úteis. Registe o número de elementos recebidos e compare com o último build bem-sucedido. Se a origem deixar de responder durante a paginação, interrompa a publicação ou conserve o artefacto completo anterior. Publicar um sitemap encurtado como resultado válido esconde uma falha de integração.
O inventário só deve conter rotas públicas que existem. Um anexo, autor ou termo publicado no WordPress não cria automaticamente uma página headless. Inclua o URL depois de resolver o template e a política de indexação. Exclua rascunhos, áreas autenticadas, pesquisas internas, origens de redirecionamentos e páginas deliberadamente noindex. Guarde o motivo de exclusão de cada registo. Assim, a equipa editorial consegue distinguir uma decisão de publicação de conteúdo perdido durante a leitura da API.
A documentação de sitemaps do Google define o limite de 50 000 URLs ou 50 MB sem compressão por ficheiro. Divida inventários maiores e publique-os através de um índice. Vários sitemaps subordinados são uma organização normal e ajudam a analisar coleções diferentes. Use endereços públicos completos e codificação XML correta. Um ampersand sem escape em loc pode invalidar o documento mesmo que o navegador abra o endereço correspondente.
Lastmod deve refletir uma alteração relevante de conteúdo ou metadados quando existe uma data fiável. O momento do build indica publicação do artefacto e não prova que todos os artigos foram revistos. Atualizar todos os valores em cada deploy retira-lhes utilidade. Determine também se uma atualização técnica feita por um importador alterou realmente o que o leitor vê. Aplique essa decisão de forma coerente no sitemap e nos metadados do artigo.
Separar remoção, canonical e controlo de rastreio
Canonical indica o endereço preferido entre páginas iguais ou muito semelhantes. Não redireciona visitantes nem garante a escolha desse endereço pelo Google. Um redirecionamento permanente é adequado quando um URL antigo foi substituído por conteúdo equivalente. Uma remoção efetiva sem substituto pode devolver 404 ou 410. Encaminhar todos os artigos removidos para a página inicial dificulta a identificação do conteúdo perdido numa migração.
Use noindex quando uma página pública deve ficar fora dos resultados de pesquisa. O Google precisa de a obter para ler a diretiva, como explica a documentação de noindex. Bloquear o mesmo endereço em robots.txt pode impedir essa leitura. Disallow controla o rastreio e não substitui controlo de acesso. Proteja administração privada e pré-visualizações com autenticação, porque instruções para robots não impedem uma pessoa de consultar dados desprotegidos.
Se a origem servia artigos públicos, escolha redirecionamentos para os URLs equivalentes do front-end ou uma política canonical explícita para páginas que continuam acessíveis. Redirecionar apenas o ficheiro XML não redireciona os artigos anteriormente listados. Verifique os URLs antigos e as ligações internas. Se o WordPress serve exclusivamente a API de conteúdo, limite templates públicos desnecessários sem bloquear os endpoints legítimos usados pela aplicação.
Tratar paginação e idiomas como rotas próprias
Cada página útil de arquivo contém elementos diferentes e normalmente deve ter canonical para si própria. O Google já não usa rel=prev e rel=next para identificar paginação, segundo a documentação de paginação. Disponibilize ligações HTML para as páginas seguintes. Um botão que apenas acrescenta resultados por JavaScript não oferece ao robot o mesmo percurso de descoberta. Teste a última página válida e pedidos fora do intervalo para evitar listas vazias que respondem indefinidamente com 200.
O mapa linguístico deve acompanhar as publicações. Um artigo português não deve apontar o canonical para o inglês só porque essa foi a versão de origem. Hreflang liga equivalentes realmente publicados. Cada idioma deve usar o URL público canónico do respetivo artigo. Quando uma tradução é removida, atualize as outras versões e o sitemap linguístico. A página inicial portuguesa não é uma tradução equivalente de um guia técnico removido.
Os filtros exigem uma decisão sobre o catálogo concreto. Uma página de categoria permanente com texto próprio e uma seleção útil pode ser indexável de forma independente. Uma ordem diferente da mesma lista pode apontar para a vista principal. Resultados de pesquisa interna podem ser excluídos. Aplicar a mesma combinação de canonical e noindex a todos os parâmetros ignora estas diferenças. Registe os parâmetros permitidos, as regras de normalização e a intenção de indexação antes de ampliar o router.
Validar o artefacto e a resposta de produção
Um manifesto de rotas deve guardar URL pedido, estado esperado, destino canonical e indexabilidade. Compare-o com XML e HTML gerados. Para cada entrada do sitemap, confirme uma página útil, sem noindex e com o canonical previsto. Para rotas removidas, confirme o redirecionamento ou estado de remoção. Inclua slugs com acentos, caminhos codificados e páginas subordinadas. Verificar apenas a página inicial não deteta falhas no mapeamento dos artigos.
Repita as verificações no domínio de produção depois do deploy. A pré-visualização pode estar correta enquanto a CDN altera a barra final, serve HTML antigo ou acrescenta um X-Robots-Tag inesperado. Compare os cabeçalhos HTTP e o documento inicial. Quando scripts modificam metadados, verifique também o resultado renderizado. Guarde o identificador da versão no relatório operacional para distinguir novos ficheiros de respostas em cache da publicação anterior.
O Search Console mostra o canonical declarado e, depois da indexação, o escolhido pelo Google. Uma diferença exige investigar duplicados, cadeias de redirecionamento, ligações internas e acessibilidade do destino. Não prova concorrência entre dois ficheiros XML. Comece pelo endereço afetado e pelas suas variantes. Depois de corrigir os sinais, permita novo rastreio. Um deploy bem-sucedido não atualiza imediatamente a interpretação guardada pelo motor de pesquisa.
Numa migração portuguesa, teste especificamente slugs com acentos provenientes de importações antigas. A representação recebida pela API pode diferir daquela que o router produz atualmente. Compare ambas usando a normalização da aplicação. Conserve o manifesto anterior para que uma nova importação não altere silenciosamente o conjunto de páginas públicas.
