Patrones SEO para WordPress headless: las siete cosas que rompen la mayoría de las migraciones
WordPress headless se vende por los Core Web Vitals, la reutilización de contenido y la rapidez editorial. Si nadie está atento, por el camino entierra siete señales SEO concretas. Hemos hecho suficientes migraciones de este tipo para saber cuáles cuestan semanas de recuperación y cuáles se mantienen bien de forma mecánica.
Este artículo es la lista de verificación. No sustituye al pilar del servicio de WordPress headless, que expone el argumento de arquitectura. Es lo que revisamos antes, durante y después de cada migración, en ese orden.
En resumen
- Conserve las URL canónicas a nivel de URL completa, no solo del slug.
- Conserve el hreflang en el HTML, no solo en el sitemap.
- Renderice las metaetiquetas y el JSON-LD en el servidor, no en el cliente.
- Migre el historial de redirecciones antes de cambiar las URL, no después.
- Mantenga un único sitemap como fuente de verdad, no dos.
- Oculte el origen de WordPress del índice de los buscadores.
- Traslade el texto alternativo de las imágenes y sus datos estructurados.
Cómo conservar las URL canónicas en una migración headless
Una URL canónica es una promesa. Cada enlace externo, cada entrada en el índice de Google y cada vez que alguien comparte la página en redes sociales cuentan con ella. Una migración headless que recorta en silencio un segmento de la ruta, cambia mayúsculas y minúsculas o reordena los parámetros de consulta acaba de romper todas esas promesas sin que nadie se dé cuenta.
Dos reglas. Primero, recopile el conjunto completo de URL canónicas de la instalación antigua de WordPress antes de tocar el front-end. Exportamos cada entrada, página y página de taxonomía publicadas con la URL que Google tiene indexada; esa es la fuente de verdad. Segundo, escriba la canónica en la respuesta HTML del front-end headless, no en una modificación del <head> hecha en el cliente. Los motores generativos y los motores de respuesta analizan el HTML inicial; para ellos, las metaetiquetas modificadas en el cliente no existen.
Si tiene que cambiar una URL, redirija con un 301 de la antigua a la nueva y manténgalo al menos un año.
Etiquetas hreflang en el HTML de WordPress headless
Los sitios WordPress multilingües gestionan las traducciones con WPML, Polylang o una solución propia. El mapeo termina siendo correcto en la base de datos. Después, el front-end headless tiene que renderizar <link rel="alternate" hreflang="..."> para cada variante de idioma en la respuesta HTML.
El patrón que se le escapa a la mayoría de las agencias: el hreflang tiene que ser autorreferencial. La página en inglés se incluye a sí misma y a todas las alternativas traducidas. La página en polaco se incluye a sí misma y a todas las alternativas. Las dos listas coinciden. Herramientas como el informe de segmentación internacional de Search Console señalan la discrepancia cuando uno de los lados olvida algo.
Tratamos la generación del hreflang como parte del build, no como una decisión en tiempo de ejecución. El mapa de rutas se calcula en el build y se convierte en hash, y cualquier desviación hace fallar el build.
Renderizado en el servidor de metaetiquetas y JSON-LD
La regresión SEO más habitual que hemos visto en migraciones headless: metaetiquetas y JSON-LD insertados con JavaScript después de cargar la página. El navegador los ve. Googlebot a veces los ve. Los motores generativos, los asistentes de voz y la mayoría de los rastreadores de LLM normalmente no.
Dos reglas. Renderice las metaetiquetas, la canónica, el Open Graph y cada bloque JSON-LD de Schema.org en la respuesta HTML inicial. Con Astro, es el comportamiento predeterminado. Con Next.js, significa renderizar en el servidor (metadatos del App Router, o la ruta heredada con getServerSideProps) y no depender de que next/head se vuelva a ejecutar en el cliente.
Lo mismo vale para las imágenes: un elemento <img> con alt y src en el HTML es indexable. Un <img> inyectado después de un efecto en el cliente es invisible para la mayoría de los rastreadores y para los pipelines de datos de entrenamiento de IA.
Reutilizar el JSON-LD de Yoast en WordPress headless
WordPress con Yoast SEO o Rank Math ya genera un buen JSON-LD de Article, Product y Organization. En una migración headless, la tentación es reescribirlo desde cero en el front-end. No caiga en ella.
Lea el JSON-LD existente desde el origen de WordPress mediante el endpoint REST o GraphQL. Páselo tal cual. Añada solo lo que el front-end sabe legítimamente y WordPress no (por ejemplo, marcas de tiempo del build para dateModified si su flujo editorial no toca las fechas). Dos sistemas generando JSON-LD solapado es la forma en que los informes de resultados enriquecidos de Search Console empiezan a fallar.
En nuestras propias páginas usamos los componentes de la fase 0 en src/components/seo/: DirectAnswer, FAQ y Quote. Cada uno emite su propio JSON-LD mínimo sin solaparse con el schema Article de la página.
Cómo migrar las redirecciones antes de cambiar las URL
El orden importa. La lista de verificación previa a la migración recoge todas las redirecciones internas y externas, incluidas las silenciosas (/wp-content/... a /uploads/..., redirecciones por código de país, variantes AMP). El nuevo front-end publica esas redirecciones el día cero, antes del cambio público a las nuevas URL.
En Cloudflare Pages mantenemos el archivo _redirects por debajo del límite de la plataforma de 2000 reglas. Un build que superaría el límite falla. Todo lo que necesite más de 2000 reglas va a un Worker con lógica de redirecciones con parámetros.
Cuando el DNS público por fin apunta al nuevo front-end, ninguna redirección es nueva en producción: cada regla se ha probado en el build durante semanas antes del cambio.
Un único sitemap XML para WordPress headless
WordPress 5.5 añadió un /wp-sitemap.xml predeterminado. Yoast SEO y Rank Math añaden los suyos. El framework del front-end headless también genera un sitemap. Tres sitemaps en el mismo dominio son la receta perfecta para volver loca a Search Console.
La regla: elija un sitemap canónico y desactive o redirija los demás. Normalmente generamos el sitemap desde el framework del front-end, para que las URL coincidan exactamente con el sitio público, y redirigimos con 301 el sitemap del origen de WordPress al del front-end. Así el origen de WordPress se vuelve invisible para la búsqueda.
Cómo aplicar noindex al backend de WordPress headless
Una migración headless deja el origen de WordPress en funcionamiento, normalmente en un subdominio o en un nombre de host privado. Sigue sirviendo HTML renderizado, tiene un sitemap operativo y responde a consultas REST. Los buscadores que encuentren ese origen lo indexarán como un duplicado del sitio público, y el duplicado no será el que se posicione.
Tres controles. El robots.txt del origen bloquea todas las rutas excepto los endpoints REST y GraphQL. El origen envía X-Robots-Tag: noindex, nofollow en las cabeceras HTTP de cada respuesta HTML. El sitemap del origen se elimina o devuelve un 410.
Si su origen está en el mismo dominio que el sitio público, bajo un prefijo de ruta (por ejemplo, /wp-admin/ o /wp/), se aplican los mismos controles, limitados a esas rutas.
Guías relacionadas sobre SEO en WordPress headless
Este artículo complementa el pilar del servicio de WordPress headless. Para el momento de decidir, consulte WordPress headless, Next.js vs Astro 2026. Para la cuestión más amplia de la visibilidad, incluidas las citas en LLM, la guía de visibilidad en IA y LLM es nuestra referencia de lo que entregamos en AEO y GEO sobre estas bases SEO.
