«Si nuestro contenido vive en una API, ¿Google puede siquiera verlo?». Es la pregunta que se hace todo equipo antes de pasarse a headless, y casi siempre la plantea alguien que en 2019 vio cómo una app de React renderizada en el cliente le mostraba a un rastreador un <div> vacío. Esa preocupación ya no tiene base, pero la pregunta esconde otra que sí es real: con headless, la responsabilidad del SEO pasa del CMS a ti. Este artículo es el mapa de lo que ahora te toca.
La respuesta corta
Los buscadores posicionan HTML servido desde URL de tu dominio. No saben, ni les importa, si ese HTML se armó desde una base de datos, una API o archivos Markdown. Una arquitectura headless con renderizado en el servidor produce exactamente el mismo resultado rastreable que un CMS tradicional, y a menudo uno mejor, porque controlas cada byte de la página.
El matiz está en la condición: con renderizado en el servidor. Si aciertas con el modelo de renderizado, lo demás es SEO técnico de siempre.
Renderizado: la única decisión que importa
Hay tres formas de convertir el contenido de una API en páginas:
Renderizado en el cliente (CSR): el navegador descarga JSON y construye la página con JavaScript. Google ejecuta JavaScript, pero aplaza el renderizado, y los demás rastreadores, las vistas previas de enlaces y los scrapers de redes sociales se comportan cada uno a su manera. Para el contenido que quieres posicionar, CSR es la opción arriesgada.
Renderizado en el servidor (SSR): tu servidor pide el contenido a la API en cada solicitud y devuelve HTML terminado. Siempre es rastreable y siempre está al día; el costo es una llamada a la API por cada solicitud (con la caché que decidas).
Generación estática (SSG): las páginas se generan de antemano y se sirven como archivos. Es la entrega más rápida posible, pero hay que volver a generar o revalidar cuando cambia el contenido.
Cualquier framework moderno (Next.js, Astro, Nuxt, SvelteKit, TanStack Start) hace SSR o SSG contra una API de contenido como camino por defecto, con la llamada a la API en un loader o en tiempo de compilación. Si te quedas con una sola regla de este artículo, que sea esta: las páginas de contenido público se renderizan en el servidor.
La ventaja de dominio de la que nadie habla
Pasarse a headless suele mejorar el SEO por una razón estructural: pone el contenido en tu dominio principal. Las plataformas alojadas de blogs y documentación viven en subdominios o en sus propios dominios, y la autoridad que ganan tus artículos se queda allí. Con headless, /blog, /help y /changelog son subdirectorios del dominio donde vive tu producto, así que cada backlink a un artículo refuerza todas las demás páginas que tienes. Este factor, por sí solo, suele pesar más que todos los detalles de metaetiquetas que vienen a continuación.
La lista de comprobación que ahora es tuya
Un CMS tradicional se encarga de parte de esto sin que lo veas. Headless te lo pasa a ti, aunque se configura una sola vez en una función auxiliar, porque todo sale de las mismas respuestas de la API.
Metadatos por página
Título, metadescripción, etiquetas de Open Graph y de Twitter, fechas del artículo. Escríbelos como campos en el CMS junto al contenido e inclúyelos en el head del documento desde la misma petición que renderiza la página. Con un backend de contenido que modela los campos de SEO de cada entrada (título, descripción, imagen), esto se reduce a mapear campos y deja de ser un proyecto.
URL canónicas
Cada página declara su URL canónica, calculada a partir del slug de la entrada y nunca copiada de la URL de la solicitud, porque así acabarías canonicalizando variantes con ?utm_source= y errores de mayúsculas. Si una sola función convierte una entrada en su ruta, y la usan por igual las páginas, el sitemap y los feeds, nunca van a discrepar.
Códigos de estado reales
Un slug desconocido debe devolver HTTP 404, no una página de error bien diseñada con estado 200. Los errores soft 404 malgastan presupuesto de rastreo y ensucian el índice. Del mismo modo, si la ruta de tu servidor no consigue llegar a la API de contenido, falla con un 5xx y Cache-Control: no-store en lugar de dejar en la caché de tu CDN un 200 vacío.
Sitemap y feeds
Genera sitemap.xml a partir de los mismos endpoints de listado que usan tus páginas índice, con un lastmod real sacado de las fechas de las entradas. Añade RSS al blog y al registro de cambios: los feeds cuestan poco y los usan tanto los lectores como los rastreadores.
Datos estructurados
Genera JSON-LD (Article para los artículos, FAQPage donde encaje, Organization en la página de inicio) a partir de los datos de la entrada. Un detalle al inyectar JSON-LD desde el código del servidor: escapa cada < del JSON serializado como \\u003c, para que un </script> suelto dentro de un título no pueda salirse de la etiqueta script.
Pon noindex a lo que no debe posicionar
Las páginas de resultados de búsqueda, las rutas de vista previa y las combinaciones paginadas de etiquetas a menudo merecen noindex. Si tu plataforma ofrece un portal alojado en su propio dominio además de la entrega por API, comprueba cómo gestiona la indexación. Las páginas del portal alojado de Kookee llevan noindex a propósito: así, la versión de ese mismo contenido que renderiza tu dominio es la única que compite en los buscadores, sin dudas de contenido duplicado.
Contenido al día y caché con criterio
Con SSR, los cambios publicados aparecen en la siguiente solicitud. Con SSG, decide cuánto retraso aceptas para cada tipo de contenido: un blog puede regenerarse sin prisa; un registro de cambios o una página que depende del estado del servicio necesita revalidarse en cuestión de minutos. En los dos casos, configura la caché de tu CDN a conciencia: claves de caché por URL, TTL razonables y purga al publicar, si tu plataforma tiene webhooks o si lanzas la regeneración al publicar.
Contenido multilingüe
Si sirves varios idiomas, headless vuelve a darte la versión limpia: pide a la API las traducciones de la entrada, sirve cada idioma en su propia URL y genera las alternativas hreflang a partir de la lista de traducciones. Lo que no hará es salvarte de una traducción automática hecha a medias: publica solo los idiomas que mantienes.
Una prueba que puedes hacer hoy
Toma tu página más valiosa y comprueba, con JavaScript desactivado: ¿aparece el texto completo en el código fuente HTML? ¿El título, la descripción y la URL canónica corresponden a esa página? ¿Un slug inventado devuelve 404? Abre sitemap.xml: ¿está la página, con un lastmod verosímil? Son quince minutos y cubren el 90 % de lo que suele fallar.
Headless no perjudica el SEO. Lo perjudican el JavaScript sin renderizar y los códigos de estado incorrectos, y los subdominios de un proveedor le restan autoridad sin que se note. Elige el renderizado en el servidor, saca cada señal de los datos de la entrada que ya pides a la API y mantén la autoridad en el único dominio que debería ganarla: el tuyo.