Sitemap y canonical en WordPress headless: una sola fuente de verdad, servida desde el front-end
La inclusión en el sitemap es una señal canonical débil; las redirecciones y rel=canonical son más fuertes. Contexto de implementación: patrones SEO para WordPress headless, fallan en silencio.
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
Genera el sitemap desde un inventario completo de rutas públicas y emita un canonical en el head del HTML. El inventario puede proceder del front-end o de un backend correctamente configurado. Varios archivos subordinados coherentes son válidos.
Por qué los sitios WordPress headless acaban con dos sitemaps
WordPress ofrece sitemaps del núcleo desde la versión 5.5. Su disponibilidad depende de configuración y filtros; los plugins SEO pueden desactivar el generador del núcleo. Revisa los endpoints reales. Tres generadores simultáneos no son inevitables.
/wp-sitemap.xmldel núcleo de WordPress./sitemap_index.xmlde Yoast o Rank Math./sitemap.xmldel framework de front-end.
Varios sitemaps pueden coexistir correctamente. Corrige inventarios públicos contradictorios, pero Google no selecciona páginas indexadas únicamente por el orden de lectura del XML.
Todos los endpoints activos deben usar un inventario coherente de rutas públicas. Desactiva generadores innecesarios del origen o redirige su XML cuando corresponda. Varios archivos subordinados pueden responder 200 dentro de un índice de sitemaps.
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.
Emite canonical en el head del HTML inicial mediante el layout o la API de metadatos. Google admite canonicals generados con JavaScript, pero recomienda una señal clara sin modificaciones posteriores. La salida inicial facilita pruebas reproducibles.
Adapta los metadatos SEO al mapa público de rutas. Yoast tiene una API REST documentada; otros plugins requieren su propia integración compatible. La respuesta canonical no utiliza automáticamente las direcciones públicas headless.
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
Los filtros necesitan una política explícita de indexación. Usa canonical para duplicados reales y noindex cuando pretendes excluir una página. No apliques ambos indiscriminadamente a todos los filtros.
Cómo validar el sitemap y el canonical antes de publicar
Dos comprobaciones que ejecutamos en cada proyecto WordPress headless:
Comparación de sitemaps. Genera el nuevo sitemap y compara 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, solicita la URL en el nuevo front-end y comprueba 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.
Definir el contrato de las URL públicas
WordPress guarda identificadores de entradas y sus propios enlaces permanentes. Un front-end headless puede tener otros prefijos de idioma, rutas de categorías o reglas para la barra final. Define primero la correspondencia entre ID, idioma y URL pública. Esta correspondencia forma parte de la configuración de la aplicación. Cambiar el dominio de origen no basta cuando también cambia la ruta. Una página subordinada en WordPress puede tener una ruta plana en el front-end, mientras un producto utiliza una categoría traducida.
Usa el mismo resolver para enlaces internos, sitemap, canonical, alternativas hreflang e identificadores de datos estructurados. Esta recomendación de arquitectura evita que funciones independientes generen direcciones distintas para el mismo contenido. Mantén explícitas las excepciones editoriales. Una entrada sindicada puede apuntar deliberadamente a la publicación de un socio. Sustituir todos los dominios cambiaría el significado de esa decisión. Valida los destinos externos por separado y rechaza dominios de desarrollo o previsualización antes de publicar HTML.
La API REST de Yoast devuelve información SEO asociada a las URL de WordPress. Obtener estos datos no adapta automáticamente sus direcciones al mapa de rutas público. Decide si el front-end construye el head con campos estructurados o consume HTML comprobado de la integración. No emitas el head completo del plugin y otro canonical desde el layout. Revisa la respuesta final porque dos componentes pueden publicar el mismo dato correcto y producir marcado duplicado.
Obtener un inventario completo del contenido
El generador debe leer todas las páginas necesarias de la API. La primera respuesta de una colección no representa todas las publicaciones. Las taxonomías necesitan su propio inventario cuando existen archivos útiles en el front-end. Registra cuántos elementos recibe y compara con el último build correcto. Si el origen deja de responder durante la paginación, detén la publicación o conserva el artefacto completo anterior. Un sitemap reducido presentado como resultado válido oculta un fallo de integración.
El inventario debe contener únicamente rutas públicas que existen. Un adjunto, autor o término publicado en WordPress no crea automáticamente una página headless. Incluye la URL después de resolver la plantilla y la política de indexación. Excluye borradores, áreas autenticadas, búsquedas internas, fuentes de redirecciones y páginas deliberadamente noindex. Guarda la causa de cada exclusión. Así, el equipo editorial puede distinguir una decisión de publicación de una entrada perdida durante la lectura de la API.
La documentación de sitemaps de Google establece un límite de 50 000 URL o 50 MB sin comprimir por archivo. Divide los inventarios mayores y publícalos mediante un índice. Varios archivos subordinados son una organización normal y permiten analizar colecciones distintas. Usa direcciones públicas completas y escapa XML correctamente. Un ampersand sin escapar en loc puede invalidar el documento aunque el navegador abra la dirección correspondiente.
Lastmod debe proceder de una modificación relevante del contenido o los metadatos cuando existe una fecha fiable. La hora del build representa la publicación del artefacto y no demuestra que se haya revisado cada artículo. Sustituir todos los valores en cada despliegue elimina su utilidad. Determina también si un importador cambió contenido visible o solo información técnica. Aplica la misma decisión al sitemap y a los metadatos de la entrada.
Separar eliminación, canonical y rastreo
Canonical indica la dirección preferida entre páginas duplicadas o muy similares. No redirige al visitante ni garantiza que Google seleccione ese destino. Una redirección permanente sirve cuando una dirección antigua tiene un equivalente nuevo. Una eliminación real sin sustituto puede responder 404 o 410. Enviar todas las entradas eliminadas a la portada dificulta identificar el contenido perdido durante la migración.
Usa noindex cuando una página pública debe quedar fuera de los resultados. Google necesita rastrearla para leer la directiva, como explica su documentación de noindex. Bloquear esa misma URL en robots.txt puede impedir la lectura. Disallow controla el rastreo y no sustituye el control de acceso. Protege la administración privada y las previsualizaciones mediante autenticación. Las instrucciones para robots no impiden que una persona consulte información desprotegida.
Si el origen servía artículos públicos, elige redirecciones a sus equivalentes del front-end o una política canonical explícita para las páginas que siguen accesibles. Redirigir únicamente el XML no redirige las entradas que contenía. Revisa las direcciones antiguas y los enlaces internos. Si WordPress solo debe entregar la API de contenido, restringe plantillas públicas innecesarias sin bloquear los endpoints legítimos utilizados por la aplicación.
Completar paginación y variantes de idioma
Cada página útil de archivo tiene entradas diferentes y normalmente debe declarar su propio canonical. Google ya no utiliza rel=prev y rel=next para identificar paginación, según la documentación de paginación. Ofrece enlaces HTML a páginas posteriores. Un botón que solo añade resultados con JavaScript no ofrece al robot la misma vía de descubrimiento. Prueba la última página válida y direcciones fuera del intervalo para evitar resultados vacíos que responden indefinidamente con 200.
El mapa de idiomas debe actualizarse junto con las publicaciones. Un artículo español no debe declarar el inglés como canonical solo porque fue el texto original. Hreflang conecta equivalentes realmente publicados. Cada idioma debe apuntar a la dirección pública canónica de su propia entrada. Si eliminas una traducción, actualiza las demás versiones y el sitemap del idioma. La portada española no equivale al artículo técnico que acaba de desaparecer.
Los filtros requieren una decisión sobre el catálogo concreto. Una categoría permanente con texto propio y selección útil puede ser indexable de forma independiente. Otro orden de los mismos productos puede apuntar a la vista principal. Los resultados de búsqueda interna pueden excluirse. Aplicar la misma combinación de canonical y noindex a todos los parámetros ignora estas diferencias. Documenta parámetros permitidos, normalización e intención de indexación antes de ampliar el router del catálogo.
Verificar el artefacto y la respuesta pública
Un manifiesto de rutas debe guardar dirección solicitada, estado esperado, destino canonical e indexabilidad. Compáralo con XML y HTML generados. Para cada entrada del sitemap, comprueba que existe una página útil, sin noindex y con el canonical previsto. Para rutas eliminadas, comprueba redirección o estado de eliminación. Incluye slugs con tildes, rutas codificadas y páginas anidadas. Una prueba limitada a la portada no detecta errores de correspondencia entre entradas y direcciones.
Repite las comprobaciones en el dominio de producción tras desplegar. La previsualización puede ser correcta mientras la CDN cambia la barra final, entrega HTML antiguo o añade un X-Robots-Tag inesperado. Compara cabeceras HTTP y documento inicial. Si los scripts modifican los metadatos, revisa también el resultado renderizado. Guarda el identificador de versión para distinguir un artefacto nuevo de una respuesta almacenada de la publicación anterior.
Search Console muestra el canonical declarado y, después de indexar, el seleccionado por Google. Una diferencia exige investigar duplicados, cadenas de redirecciones, enlaces internos y accesibilidad del destino. No demuestra competencia entre dos archivos XML. Empieza por la URL afectada y sus variantes. Tras corregir las señales, deja tiempo para otro rastreo. Un despliegue correcto no actualiza inmediatamente la interpretación guardada por el buscador.
En una migración española, revisa slugs con tildes procedentes de importaciones históricas. Una dirección recibida de la API y la producida por el router pueden tener representaciones distintas. Compáralas con la misma normalización que aplica el front-end. Conserva el manifiesto anterior para detectar si una importación posterior cambia silenciosamente el conjunto de páginas públicas.
