SEO para Strapi

TL;DR — Strapi es un CMS «headless»: almacena contenido y lo entrega mediante una API, pero no incluye un sitio web. Por eso, Strapi no determina el SEO; lo hace el frontend que convierte el contenido en páginas. La regla principal es generar el HTML en un servidor o durante la compilación (SSR o SSG), no por completo en el navegador. Las tareas que WordPress y Yoast resolvían —títulos, sitemaps y robots.txt— deben configurarse por separado.

Qué es realmente Strapi

Strapi es un CMS headless de código abierto basado en Node.js. «Headless» significa que solo cubre la parte posterior del sitio, donde se redacta y almacena el contenido, sin tema, páginas ni renderizado. El contenido se obtiene mediante una API REST o GraphQL. Strapi puede alojarse en infraestructura propia o mediante Strapi Cloud.

Como no incluye un sitio web, Strapi se conecta con un frontend independiente. Next.js, Nuxt, Astro y Gatsby son opciones habituales que obtienen el contenido y construyen las páginas que ven las personas y Googlebot.

El concepto principal

Strapi es neutral para el SEO. El resultado depende de cómo el frontend construya la página. Hay dos métodos seguros y uno arriesgado:

• Durante la compilación (SSG): las páginas se generan previamente como archivos HTML. Es rápido y apto para buscadores.
• En un servidor, por solicitud (SSR): el servidor genera la página completa y la envía. También es apto para buscadores.
• En el navegador (CSR): el servidor envía una estructura casi vacía y JavaScript la completa después. Es la opción arriesgada.

Google puede leer posteriormente páginas renderizadas en el navegador, pero el proceso es más lento y menos fiable. El comportamiento de los rastreadores de IA varía según el proveedor; un rastreador que solo obtiene el HTML inicial recibe la estructura vacía que entrega CSR. El HTML debe generarse en el servidor o durante la compilación para que el contenido esté presente desde la primera respuesta.

El problema de los ajustes SEO ausentes

Al migrar de WordPress con Yoast a Strapi, los títulos, las metadescripciones, los sitemaps y las etiquetas canónicas no aparecen automáticamente. No existe una capa de complementos que lo haga en segundo plano. Se requiere:

• Añadir campos SEO, como título, descripción, canónica e imagen social, a los tipos de contenido. Un complemento comunitario de SEO puede añadir estos campos.
• Conectar esos campos con el HTML de la página en el frontend.
• Generar un sitemap y robots.txt.

Estas tareas no son complejas, pero no ocurren por sí solas.

Riesgos que pueden pasar inadvertidos

• Borradores indexados. Strapi dispone de un flujo de borrador y publicación. El contenido no publicado debe mantenerse fuera de los resultados y de la API pública.
• Sitios de vista previa indexados. Las URL de vista previa o pruebas pueden convertirse en copias duplicadas si Google las descubre. Deben bloquearse.
• Panel de administración y API sin procesar. El acceso /admin y el JSON de /api/... no deben aparecer en los resultados.

La pestaña Advanced explica los cuatro modos de renderizado, el complemento SEO, los sitemaps, la gestión de borradores y vistas previas, Strapi Cloud frente al alojamiento propio y las migraciones.

TL;DR — Strapi es un CMS headless exclusivamente de backend (REST + GraphQL, autohospedado o Strapi Cloud) sin capa de renderizado, por lo que es neutral para SEO: el frontend decide. SSG/SSR entregan HTML completo; CSR es arriesgado para rastreadores que solo obtienen el HTML inicial; ISR puede servir una primera petición obsoleta. Modele campos SEO en los tipos de contenido. El complemento @strapi/plugin-seo los almacena y previsualiza, pero no genera HTML, sitemaps ni robots.txt. Excluya borradores mediante el flujo de publicación, proteja las vistas previas con noindex en el host, mantenga /admin y el JSON de /api/* fuera de búsqueda y cree sitemap.xml y robots.txt en el frontend.

Strapi no determina el SEO; lo hace el frontend

El concepto principal es que Strapi no tiene capa de renderizado. Ofrece almacenamiento, modelo de contenido, interfaz de edición y API. La indexabilidad, los metadatos, la velocidad y los datos estructurados dependen del framework que consume la API. Strapi solo almacena y entrega los campos correctos.

Por eso, decir que Strapi es perjudicial para SEO plantea mal el problema. El equipo de Strapi afirma: “headless architectures require developers to take ownership of SEO aspects that traditional content management systems handle automatically.” (traducción) «Las arquitecturas headless exigen que el desarrollo asuma tareas SEO que los CMS tradicionales gestionan automáticamente». Strapi con Next.js y SSG puede superar a WordPress descuidado; una SPA React sin metadatos puede fracasar. El backend es el mismo y cambia el renderizado. Es el principio descrito en SEO con JavaScript.

Los cuatro modos de renderizado

• SSG — generación de sitios estáticos. El HTML se crea al compilar y se sirve como archivos estáticos: completo desde la primera petición, con TTFB y Core Web Vitals rápidos. El contenido nuevo exige recompilar.
• SSR — renderizado en servidor. El HTML se genera en cada petición. Se mantiene actualizado, pero la latencia de Strapi se suma al TTFB.
• ISR — regeneración estática incremental. Las páginas se regeneran en segundo plano tras una ventana de revalidación. Es un buen punto medio con una trampa.
• CSR — renderizado en el cliente. Se entrega un armazón casi vacío y el navegador construye el DOM. Google pone la página en cola: “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page” (traducción) «Googlebot pone en cola para renderizar las páginas con estado HTTP 200, salvo que robots indique que no deben indexarse». Otros rastreadores lo procesan peor. Úselo solo en paneles privados; evítelo en contenido público.

La trampa de ISR: al vencer la revalidación, la siguiente petición todavía puede recibir la página obsoleta; la versión nueva llega en la posterior. Para precios o inventario, use SSR. ISR conviene a contenido que cambia cada horas o días.

Modelado de contenido SEO en Strapi

El frontend no puede renderizar lo que el modelo no contiene. Añada a cada tipo de contenido público un componente SEO con, al menos:

• metaTitle, metaDescription
• canonicalURL
• ogImage (y campos de Open Graph / Twitter)
• una directiva robots, por ejemplo un booleano preventIndexing para controlar noindex

Use el campo UID para slugs: se genera desde el título y exige unicidad. En sitios multilingües, active i18n por tipo, localice slug y campos SEO y genere <link rel="alternate" hreflang="..."> mediante la relación localizations. SALT.agency señala que el título “can either be populated with the Strapi SEO Plugin or by creating a text field where the title tag will be stored, with conditions added such as not being shorter than or not exceeding a set amount of characters.” (traducción) «Puede rellenarse con Strapi SEO Plugin o guardarse en un campo de texto con límites de longitud».

El frontend lee los campos y rellena <head> mediante generateMetadata en Next.js, useSeoMeta en Nuxt o el diseño de Astro. Los metadatos presentes en HTML son más fiables que los inyectados con JS porque Google los ve en la primera petición.

Qué hace y qué no hace Strapi SEO Plugin

El complemento comunitario (@strapi/plugin-seo, antes @strapi-community/plugin-seo) es la herramienta habitual. “embeds a side panel in every Content-Type edit view where you can set meta titles, descriptions, canonical URLs, and social share images,” (traducción) «Integra un panel lateral en cada tipo de contenido para definir títulos, descripciones, URL canónicas e imágenes sociales». También muestra una vista previa y analiza legibilidad y palabras clave.

Lo que no hace, pese a una confusión frecuente:

• No genera el HTML de <head>; el frontend renderiza los campos.
• No genera el sitemap; en Strapi 5 se usa Webtools o strapi-5-sitemap-plugin.
• No escribe robots.txt ni implementa datos estructurados; corresponde al frontend.

El complemento mejora la experiencia editorial y almacena campos limpios, pero el frontend debe producir la salida SEO real.

Excluir borradores, vistas previas, /admin y /api del índice

Strapi presenta aquí más modos de fallo que una plataforma alojada como Shopify.

• Draft/Publish. Los borradores llevan publishedAt: null; la API solo devuelve entradas publicadas a peticiones sin autenticar. Nunca envíe un token autenticado en peticiones públicas, o los borradores quedarán accesibles. El sitemap debe respetar el estado de publicación.
• Vista previa y pruebas. Los despliegues suelen ser públicos. Protéjalos con X-Robots-Tag: noindex en el host, Disallow: /, metaetiqueta noindex y autenticación HTTP. Vigile hosts inesperados en Search Console.
• Panel /admin. Confirme <meta name="robots" content="noindex">, evite enlaces públicos y protéjalo con contraseña.
• JSON de /api/*. Puede desperdiciar rastreo y filtrar datos. Coloque la API en cms.example.com o api.example.com, bloquee el subdominio y exclúyalo del sitemap. Si comparte dominio, use Disallow: /api/.

Sitemaps y robots.txt se crean en el frontend

No existe Yoast, así que ambos deben implementarse. Hay dos vías para el sitemap:

1. Complemento dentro de Strapi: genera XML e incluye solo entradas publicadas. En Strapi 5, use Webtools (strapi-plugin-webtools + webtools-addon-sitemap) o strapi-5-sitemap-plugin. El antiguo strapi-plugin-sitemap solo llega a Strapi 4. Su documentación afirma: “this setting will make sure that all draft pages are excluded from the sitemap.” (traducción) «Este ajuste garantiza que todas las páginas en borrador queden excluidas del sitemap».
2. Generado en el frontend: sitemap.ts en Next.js, @astrojs/sitemap en Astro o módulos de Nuxt que obtienen URL publicadas. Ofrece mayor control de URL, lastmod y changefreq.

robots.txt se sirve desde el frontend (robots.ts en Next.js o public/robots.txt en Astro). Incluya Sitemap:, bloquee vistas previas con Disallow: / y nunca bloquee .js o .css, pues impediría renderizar.

El patrón clave es el flujo de webhook: publicar en Strapi → recompilar o revalidar en Vercel/Netlify → regenerar sitemap → avisar a Google Search Console e IndexNow. Como las actualizaciones pasan por una API, conectar IndexNow al webhook resulta especialmente útil.

Strapi Cloud frente a alojamiento propio

El alojamiento afecta al tiempo de respuesta de la API de forma distinta según el renderizado:

• SSG/ISR: la velocidad importa al compilar, no en ejecución; no afecta al TTFB del usuario.
• SSR: la latencia se suma directamente al TTFB en cada petición y afecta al LCP.

Strapi Cloud ofrece infraestructura gestionada y CDN de recursos. Autohospedado permite controlar caché (Redis), índices y proximidad geográfica. En ambos casos, almacene la API en caché o use ISR. La CDN de Strapi Cloud sirve la API y los recursos, no el frontend; las Core Web Vitals se miden en el frontend alojado por separado en Vercel, Netlify o Cloudflare Pages.

Migraciones hacia o desde Strapi

WordPress → Strapi es una ruta habitual y donde suelen surgir fallos SEO:

• Asigne cada slug al campo UID; todo cambio requiere redirección 301 mediante strapi-plugin-redirect-urls o Smart Redirect Manager.
• Migre títulos, descripciones y og:image desde wp_postmeta, y el texto alternativo a alternativeText.
• Inventaríe todas las URL, incluidas etiquetas, archivos paginados y parámetros, y cree el mapa antes de publicar.
• Migre las URL canónicas explícitamente; no presuponga que el frontend acertará.
• Tras lanzar, compare rastreos de Screaming Frog, valide datos estructurados, reenvíe sitemaps a GSC y Bing y active IndexNow.

El SEO de Strapi es una aplicación de SEO con JavaScript y renderizado; SEO para CMS headless explica la versión independiente de plataforma.

Resumen de IA

Resumen de la versión avanzada:

• Strapi es neutral para SEO. Es un CMS headless de backend (REST + GraphQL, autohospedado o Strapi Cloud) sin capa de renderizado; el frontend decide.
• El modo de renderizado es el producto: SSG/SSR entregan HTML completo; CSR es arriesgado; ISR es un punto medio que puede servir una primera petición obsoleta. Use SSR para datos volátiles.
• Modele campos SEO: metaTitle, metaDescription, canonicalURL, ogImage, booleano preventIndexing, UID para slugs y localizations para hreflang.
• El complemento SEO almacena y previsualiza campos, pero no genera HTML de <head>, sitemaps ni robots.txt. En Strapi 5, use Webtools o strapi-5-sitemap-plugin; strapi-plugin-sitemap solo admite Strapi 4.
• Excluya lo indebido: borradores sin tokens públicos; vistas previas con noindex, Disallow: / y autenticación; /admin con noindex y contraseña; JSON de /api/* bloqueado, preferiblemente en otro subdominio.
• Cree sitemap.xml y robots.txt en el frontend; nunca bloquee .js/.css y conecte webhook → recompilación → sitemap → GSC + IndexNow.
• Alojamiento: con SSR, la latencia de la API afecta directamente a TTFB/LCP; use caché o ISR. La CDN de Strapi Cloud sirve API y recursos, no el frontend.
• Migraciones: evite 301s rotos, metadatos perdidos y CSR accidental mediante un inventario completo de URL y un mapa de redirecciones previo.

Documentación oficial

Documentación de fuente primaria de los buscadores. Como Strapi no renderiza, son pertinentes las guías de JavaScript y renderizado.

Google

• Fundamentos de SEO para JavaScript — título oficial: “Understand JavaScript SEO Basics” (traducción) «Fundamentos de SEO para JavaScript»; explica rastreo, renderizado e indexación.
• Renderizado dinámico, solución obsoleta — título oficial: “Dynamic Rendering (deprecated workaround)” (traducción) «Renderizado dinámico, solución obsoleta»; recomienda SSR, renderizado estático o hidratación.
• Renderizado para aplicaciones de contenido — título oficial: “Rendering for Content-Driven Web Apps” (traducción) «Renderizado para aplicaciones de contenido»; compara SSR, SSG y CSR.
• Corregir problemas de búsqueda con JavaScript — título oficial: “Fix Search-Related JavaScript Problems” (traducción) «Corregir problemas de búsqueda con JavaScript»; diagnostica diferencias del DOM.
• Bloquear la indexación con noindex — título oficial: “Block Search indexing with noindex” (traducción) «Bloquear la indexación con noindex»; explica metaetiqueta, X-Robots-Tag y cómo excluir /admin.
• Introducción a robots.txt — título oficial: “Introduction to robots.txt” (traducción) «Introducción a robots.txt»; aclara su alcance.

Bing / Microsoft

• El nuevo Bingbot evergreen (Microsoft Edge) — título oficial: “The new evergreen Bingbot (Microsoft Edge)” (traducción) «El nuevo Bingbot evergreen»; procesa JS con menos constancia que Google.
• IndexNow / indexnow.org — protocolo para conectar al webhook de publicación.

Citas de la fuente

Declaraciones textuales de Google, el equipo de Strapi y profesionales. Cada enlace apunta al pasaje citado.

Google: cómo se procesan páginas JavaScript

• “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page.” (traducción) «Googlebot pone en cola para renderizar todas las páginas con estado HTTP 200, salvo que robots indique que no deben indexarse». — Documentación de Google Search Central. Ir a la cita

Google: el renderizado dinámico está obsoleto

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (traducción) «El renderizado dinámico era una solución provisional, no una solución a largo plazo para contenido generado con JavaScript». — Google recomienda “server-side rendering, static rendering, or hydration.” (traducción) «renderizado en servidor, estático o hidratación». Ir a la cita

Strapi: headless traslada la responsabilidad al desarrollo

• “SEO in headless CMS architectures is a more technical challenge that requires careful implementation, as headless architectures require developers to take ownership of SEO aspects that traditional content management systems handle automatically.” (traducción) «El SEO en arquitecturas headless es un reto más técnico que exige implementar con cuidado tareas que los CMS tradicionales automatizan». — Strapi Blog. Leer el artículo
• “When using the draft/publish functionality in Strapi, this setting will make sure that all draft pages are excluded from the sitemap. This ensures that only published content appears in search engine sitemaps.” (traducción) «Al usar borrador/publicación, este ajuste excluye del sitemap todas las páginas en borrador para que solo aparezca contenido publicado». — Strapi Blog. Leer el artículo
• “The official SEO plugin embeds a side panel in every Content-Type edit view where you can set meta titles, descriptions, canonical URLs, and social share images.” (traducción) «El complemento SEO integra un panel lateral en cada tipo de contenido para definir títulos, descripciones, URL canónicas e imágenes sociales». — Strapi Blog. Leer el artículo

Profesionales: headless elimina valores predeterminados

• “Headless CMS platforms remove a lot of the defaults that traditional CMS platforms handle automatically — meta tags, canonical URLs, structured data, sitemaps, none of these come out of the box in a headless setup.” (traducción) «Las plataformas headless eliminan muchas funciones automáticas: metaetiquetas, URL canónicas, datos estructurados y sitemaps no vienen incluidos». — Successive Digital. Leer el artículo
• “The title can either be populated with the Strapi SEO Plugin or by creating a text field where the title tag will be stored, with conditions added such as not being shorter than or not exceeding a set amount of characters.” (traducción) «El título puede rellenarse con Strapi SEO Plugin o almacenarse en un campo de texto con límites de longitud». — SALT.agency. Leer el artículo

Dos listas: estado SEO de Strapi y migración

Comprobación del estado SEO

• El frontend entrega contenido en HTML desde la primera petición (SSR o SSG), no solo tras ejecutar JavaScript.
• Ningún tipo público depende de CSR para el contenido principal; muchos rastreadores solo leen el HTML inicial.
• Cada tipo público incluye un componente SEO (metaTitle, metaDescription, canonicalURL, ogImage, preventIndexing) asignado a <head>.
• Los slugs usan UID y las URL preferidas son absolutas desde un único SITE_URL.
• El frontend nunca envía tokens autenticados en peticiones públicas.
• Las vistas previas devuelven X-Robots-Tag: noindex desde el host, Disallow: / y, cuando sea posible, autenticación HTTP.
• /admin tiene noindex, contraseña y ningún enlace público.
• El JSON de /api/* se bloquea en robots.txt y se excluye del sitemap.
• sitemap.xml enumera solo URL publicadas y preferidas.
• robots.txt incluye Sitemap: y no bloquea .js/.css.
• Un webhook activa recompilación o revalidación → sitemap → GSC + IndexNow.

Lista de migración (WordPress → Strapi)

• Inventario completo de URL: entradas, páginas, etiquetas, categorías, archivos y parámetros.
• Slugs asignados a UID y mapa de redirecciones 301 listo antes del lanzamiento (strapi-plugin-redirect-urls / Smart Redirect Manager).
• Títulos, descripciones y og:image migrados al componente SEO.
• Texto alternativo migrado a alternativeText.
• URL preferidas verificadas en el frontend nuevo.
• Renderizado confirmado como SSR/SSG, no CSR accidental.
• Datos estructurados comprobados con Rich Results Test.
• Sitemaps reenviados a Google Search Console y Bing Webmaster Tools e IndexNow activo.

Modelos mentales

1. Strapi no determina el SEO; lo hace el frontend. Como no tiene capa de renderizado, antes de investigar pregunte: ¿cómo renderiza el frontend este contenido? Casi todos los problemas dependen de ello.

2. Regla para elegir el modo. Elija según la frecuencia de cambio:

• Mayormente estático → SSG.
• Siempre actualizado o volátil → SSR.
• Cambios horarios o diarios con velocidad estática → ISR.
• Privado y no indexable → CSR es aceptable.
• Público que debe posicionarse o citarse → nunca CSR.

3. Reconstruya lo que hacía el complemento. Cada función automática de Yoast pasa a ser explícita: campos SEO → <head> → sitemap → robots.txt → URL preferidas → datos estructurados. Si falta algo, esa función no se reimplementó.

4. El complemento almacena; el frontend renderiza. Ofrece campos y vistas previas, pero no emite HTML, sitemaps ni robots.txt. Mantenga separadas ambas responsabilidades.

5. Cuatro elementos nunca deben llegar al índice. Borradores, despliegues de vista previa, /admin y JSON de /api/*. Contrólelos con publicación, noindex en host, contraseña y bloqueo robots, respectivamente.

SEO para Strapi: hoja de referencia rápida

Modos de renderizado

Qué hacen Strapi y los complementos frente al frontend

Cuatro controles de exclusión del índice

Reglas rápidas

• Strapi es neutral para SEO; el modo de renderizado es el producto.
• Use UID para slugs y URL absolutas desde un SITE_URL.
• El complemento SEO almacena campos; no genera HTML, sitemap ni robots.
• Nunca bloquee .js/.css en robots.txt.
• Conecte webhook → recompilación → sitemap → GSC + IndexNow.
• Con SSR, almacene la API en caché o use ISR para proteger el LCP.

¿Cómo debe renderizarse una página de Strapi?

Guía de incidente: páginas publicadas desaparecen de búsqueda

1. Confirme la respuesta pública. Revise estado, redirecciones, HTML de origen, URL preferida y robots; corrija antes de analizar contenido.
2. Siga la publicación. Relacione el evento con webhook, compilación, revalidación y caché; repare la cadena si está obsoleta.
3. Revise el alcance de la plantilla. Compare tipos afectados y sanos; inspeccione asignación de campos y rutas.
4. Revise la exposición. Excluya borradores, vistas previas, /admin y API, manteniendo rastreables las rutas públicas.
5. Valide la recuperación. Confirme HTML completo y estado indexable, y espere el rastreo normal sin reenvíos repetidos.

Errores de SEO en Strapi

• Tratar el complemento SEO como capa de renderizado. Crea campos; el frontend debe generarlos y validarlos.
• Obtener contenido esencial solo en el navegador. Use SSG, regeneración o SSR para páginas indexables.
• Exponer borradores y vistas previas. Exija acceso y envíe noindex visible para el servidor.
• Incluir URL de API en sitemaps. Enumere rutas HTML públicas, no recursos /api.
• Bloquear toda la API sin revisar la arquitectura. Proteja endpoints privados sin romper compilaciones o renderizado legítimo.

El contenido está publicado, pero la página sigue obsoleta

Causa probable: fallo de webhook, compilación, revalidación o caché. Solución: siga el ID por cada paso y purgue la ruta afectada. Comprobación: el HTML de producción contiene la revisión publicada.

Los campos SEO están completos, pero faltan etiquetas

Causa probable: la consulta omite el componente o la plantilla no lo asigna. Solución: incluya los campos y renderícelos durante SSG/SSR. Comprobación: curl devuelve título, URL preferida y robots esperados.

Un borrador o vista previa es indexable

Causa probable: host público o noindex solo en el cliente. Solución: añada autenticación y exclusión en servidor. Comprobación: las peticiones sin autenticar no acceden a una respuesta indexable.

Falta un tipo de contenido en el sitemap

Causa probable: la consulta, filtro, relación de idioma o asignación de rutas lo excluye. Solución: corrija la consulta e incluya solo rutas publicadas preferidas. Comprobación: las entradas responden con páginas 200 indexables.

Comparar datos de la API con el HTML de producción

curl -fsS 'https://cms.example.com/api/articles/SLUG' > strapi.json
curl -fsSL 'https://www.example.com/SLUG/' > page.html
grep -Eio '<title>[^<]+|<link[^>]+rel="canonical"[^>]*|<meta[^>]+name="robots"[^>]*' page.html

Use la respuesta de la API solo desde un entorno autorizado y no escriba tokens en registros. La comparación comprueba la entrega, no la decisión de indexación de Google.

Inspeccionar valores renderizados de la cabecera

Ejecute en la consola de DevTools:

({title: document.title, canonical: document.querySelector('link[rel="canonical"]')?.href, robots: document.querySelector('meta[name="robots" i]')?.content});

Demostrar un cambio SEO en Strapi

Prueba de entrega de contenido

Ejecución: publique una revisión controlada y siga Strapi, webhook, compilación, caché y HTML en vivo. Resultado esperado: una ruta preferida sirve la misma revisión. Interpretación del fallo: entrega o invalidación obsoleta. Ventana: SLA habitual. Reversión: producción mezcla versiones.

Prueba de renderizado de origen

Ejecución: compare HTML de origen y renderizado en tipos representativos. Resultado esperado: contenido, enlaces, metadatos y URL preferidas aparecen y coinciden. Interpretación: la salida esencial depende del navegador. Ventana: cada versión. Reversión: una plantilla pierde contenido o señales.

Prueba de exposición

Ejecución: solicite sin credenciales rutas de vista previa, borrador, administración, API y públicas. Resultado esperado: las sensibles quedan protegidas y las públicas rastreables. Interpretación: controles mal delimitados. Ventana: cada cambio de rutas o seguridad. Reversión: borradores públicos o páginas públicas bloqueadas.

Herramientas para SEO en Strapi

• @strapi/plugin-seo (complemento comunitario) — añade componente SEO, vista previa y análisis al panel. Instale con yarn add @strapi/plugin-seo. Almacena campos, pero no los renderiza.
• Complemento de sitemap de Webtools (strapi-plugin-webtools + webtools-addon-sitemap) — opción mantenida para Strapi 5; genera sitemap.xml desde contenido publicado y lo divide a escala. strapi-5-sitemap-plugin es una alternativa ligera. strapi-plugin-sitemap solo admite Strapi 4.
• strapi-plugin-redirect-urls / Smart Redirect Manager — gestiona redirecciones 301/302 para migraciones y slugs.
• Inspección de URL (Google Search Console) — muestra cómo se rastreó y renderizó una URL, y si CSR omitió contenido.
• Rich Results Test — confirma JSON-LD tras cambios de renderizado.
• Screaming Frog SEO Spider — compara HTML de origen y renderizado, rastreos previos y posteriores, y detecta URL expuestas.
• Ahrefs Site Audit — detecta URL preferidas rotas, metadatos ausentes, cadenas y problemas de indexabilidad.
• Bing Webmaster Tools — muestra renderizado, indexación y envíos de IndexNow.

Evaluación: SEO para Strapi

Cinco preguntas breves sobre SEO con Strapi. Seleccione una respuesta y compruébela.

Recursos recomendados

Mis textos relacionados

• Problemas y prácticas recomendadas de SEO con JavaScript — referencia sobre renderizado, rastreo e indexación del frontend.
• Guía para principiantes de SEO técnico — contexto general de renderizado y rastreo.

Mis ponencias

• SEO con JavaScript — Ungagged 2019 (SlideShare) — separación de frontend y backend y renderizado sin estado de Googlebot. La recomendación de renderizado dinámico está obsoleta.

En este sitio

• SEO para un CMS desacoplado — versión independiente de plataforma.
• SEO con JavaScript — base de renderizado para Strapi.

Del sector

• Prácticas recomendadas de SEO para React (Sam Underwood, Ahrefs) — aplicable al frontend habitual de Strapi; lo escribió un colega de Patrick.
• Prácticas recomendadas para CMS headless y Strapi (Strapi Blog) — traslado de la responsabilidad SEO.
• Complementos SEO: guía completa para Strapi 5 (Strapi Blog) — funciones de SEO y sitemap, incluidos borradores.
• Guía SEO para Strapi (SALT.agency) — modelado independiente de campos SEO.
• Consejos y trucos de SEO para Strapi (Notum Tech) — del equipo del complemento original.
• SEO para CMS headless: errores comunes (Successive Digital) — entornos duplicados y valores predeterminados ausentes.
• Complemento de sitemap de Webtools — solución mantenida para Strapi 5; strapi-plugin-sitemap solo admite Strapi 4.
• @strapi/plugin-seo — paquete y referencia del componente SEO.

Datos que conviene citar

• Strapi es de código abierto y admite dos modelos de despliegue. Es un CMS Node.js con REST y GraphQL, autohospedado o en Strapi Cloud. La elección afecta a la latencia, que solo repercute en Core Web Vitals con SSR, no SSG/ISR. Fuente
• El complemento divide automáticamente al superar 50 000 URL en un índice y excluye borradores cuando está activo Draft/Publish. En Strapi 5 corresponde a Webtools, no al complemento independiente anterior. Fuente
• El renderizado varía entre rastreadores de IA; la suposición segura es solo HTML. No existe una especificación común. Quien solo lee la respuesta inicial ve un armazón vacío con CSR. SSR/SSG coloca contenido en el HTML de origen y es la opción más segura para IA, Google y Bing. Contexto
• Google dejó obsoleto el renderizado dinámico. Prerrenderizar un frontend CSR ya no es la solución recomendada; Google señala SSR, renderizado estático o hidratación. Fuente

Registro de cambios