Sitemap y canonical en WordPress headless: una sola fuente de verdad, servida desde el front-end
Dos de los siete patrones SEO para WordPress headless merecen un artículo propio, porque son los primeros en fallar y fallan en silencio. El sitemap y la URL canónica son las dos señales en las que Google más confía para saber qué es este sitio y cuál es la URL real. Un proyecto headless que se equivoque en cualquiera de las dos pierde el posicionamiento que la migración pretendía conservar.
Este artículo concreta el patrón. Da por hecho que la decisión de arquitectura (Astro o Next.js según la matriz de decisión) ya está tomada.
¿En qué consiste el patrón de sitemap y canonical en headless, en un párrafo?
Genere el sitemap desde el framework de front-end, con URL que coincidan con el sitio público real. Muestre la URL canónica como <link rel="canonical"> en el head del HTML, tomada de WordPress (Yoast o Rank Math) y emitida por el front-end. Desactive o redirija con un 301 el sitemap y el canonical del origen de WordPress. Un sitemap, un canonical por página, ambos generados en el servidor.
¿Por qué los sitios WordPress headless acaban con dos sitemaps?
WordPress 5.5 introdujo /wp-sitemap.xml como función del núcleo. Desde entonces, todas las instalaciones de WordPress lo tienen activo por defecto. Los plugins de SEO (Yoast, Rank Math) generan sus propios sitemaps, que sustituyen o complementan al del núcleo. Un proyecto headless que lo ignore acaba con tres sitemaps en el mismo nombre de host:
/wp-sitemap.xmldel núcleo de WordPress./sitemap_index.xmlde Yoast o Rank Math./sitemap.xmldel framework de front-end.
Search Console detecta solapamiento, a veces marca inconsistencias, y las URL que se indexan de verdad pasan a depender de qué sitemap lea Google primero ese día. La solución es mecánica:
- El framework de front-end genera el sitemap canónico en una única ruta conocida (usamos
/sitemap-index.xmlporque Cloudflare Pages lo sirve sin problemas). - El sitemap del origen de WordPress se desactiva (Yoast y Rank Math tienen un interruptor para ello) o se redirige con un 301 al sitemap del front-end.
- El sitemap del núcleo en
/wp-sitemap.xmltambién se redirige con un 301 a su equivalente en el front-end.
Tras el cambio, solo un sitemap responde 200 OK. El resto devuelve 301 o 404.
¿Cómo se construye el sitemap del front-end en WordPress headless?
Para un front-end en Astro o Next.js hay dos opciones reales:
Generación durante el build. El build del front-end obtiene del origen de WordPress las URL de todas las entradas, páginas y términos publicados, las ordena y emite el XML. Funciona para sitios con un ritmo de publicación previsible (la mayoría). La invalidación de la caché se resuelve lanzando un nuevo build al publicar.
Bajo demanda en el edge. Una ruta de Cloudflare Worker genera el sitemap en cada petición, leyendo una lista de URL en caché que el origen de WordPress envía por webhook al publicar. Es la opción para sitios que publican con tanta frecuencia que el tiempo de build sería un problema.
Por defecto usamos la generación durante el build. El patrón con Worker lo reservamos para sitios que publican más de unas pocas veces por hora.
¿Cómo debe mostrarse la URL canónica en un front-end headless?
La URL canónica debe estar en el head del HTML, en la respuesta inicial del servidor, antes de que se ejecute cualquier script del lado del cliente. El patrón:
<link rel="canonical" href="https://example.com/headless-wordpress-for-woocommerce/" />Tres reglas.
Primera: generarla en el servidor. Astro la genera desde el frontmatter de la página o desde el layout. Next.js la genera desde metadata (App Router) o desde <Head> en rutas con getServerSideProps. Lo que hay que evitar es actualizar la URL canónica en un efecto del lado del cliente; los motores generativos y muchas superficies AEO solo leen el HTML inicial.
Segunda: tomarla de WordPress. Yoast y Rank Math exponen la URL canónica de cada entrada mediante REST. El front-end la obtiene durante el build (o en cada petición) y la muestra en el HTML. WordPress sigue siendo la fuente de verdad.
Tercera: autorreferencial por defecto. Cada URL se declara a sí misma como canónica, salvo que haya un motivo explícito para apuntar a otra (archivos paginados, URL filtradas con parámetros, contenido sindicado). Cuando apunta a otra, el canonical de destino apunta a sí mismo.
¿Qué casos límite de sitemap y canonical rompen el SEO headless?
- Barra final inconsistente. Los enlaces permanentes de WordPress suelen terminar en
/. El framework de front-end puede trabajar por defecto sin barra final. Elija una variante, redirija la otra y no permita nunca que existan las dos. - HTTP o HTTPS, www o dominio raíz. Suele resolverse en la CDN, pero la URL canónica debe declarar la variante elegida. Nosotros declaramos
https://en el dominio raíz; todo lo demás se redirige allí con un 301. - URL filtradas (búsqueda facetada en un catálogo). Suelen producir miles de variantes de URL pobres. Su canonical apunta a la URL base sin filtros; además llevan
noindexpara quedar fuera del sitemap. - Archivos paginados. La página 2, la página 3 y siguientes llevan cada una un canonical a sí misma, con
rel="prev"yrel="next"para mayor claridad. Algunos equipos apuntan el canonical a la página 1; así, páginas únicas salen del índice. No lo recomendamos. - Contenido traducido. Cada versión de idioma lleva canonical a sí misma, con
<link rel="alternate" hreflang="...">para las demás. El mapa hreflang es autorreferencial y debe coincidir en todas las versiones de idioma.
¿Cómo validar el sitemap y el canonical antes de publicar?
Dos comprobaciones que ejecutamos en cada proyecto WordPress headless:
Comparación de sitemaps. Genere el nuevo sitemap y compare el conjunto de URL con el sitemap heredado de WordPress. Todo lo que falte en el nuevo es un hueco de contenido. Todo lo nuevo es sospechoso de regresión (a menudo un borrador o una entrada privada que se filtra).
Muestra de canonicals. Para las 50 páginas con más tráfico, solicite la URL en el nuevo front-end y compruebe que el canonical del head del HTML coincide con la propia URL (o con el destino esperado si apunta a otra página de forma intencionada). Una discrepancia es un error; diez discrepancias son un patrón que obliga a revisar de nuevo el build del front-end.
Ambas comprobaciones se ejecutan en CI. Un build nuevo que falle cualquiera de las dos no se despliega.
Guías relacionadas sobre SEO en WordPress headless
Anclado a la lista de comprobación de patrones SEO para WordPress headless. Se complementa con el pilar del servicio WordPress headless y la matriz de decisión Next.js vs Astro para las decisiones más amplias sobre el build.
