Idiomas

SEO para Storyblok

Guía de SEO para Storyblok: renderizado del frontend, campos de metadatos, noindex en vistas previas, sitemaps, imágenes y datos estructurados.

Publicado por primera vez: 27 jun 2026 · Última actualización: 14 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2
1 señal de evidencia en esta página

Storyblok almacena contenido estructurado y lo entrega por REST o GraphQL, pero no renderiza las páginas. El frontend determina el SEO: SSG y SSR entregan HTML completo, mientras que CSR puede retrasar o impedir la lectura. Los campos SEO solo aportan valores; el frontend debe generar metadatos, canónicas, sitemap, robots.txt y JSON-LD. Los entornos de vista previa deben bloquearse con noindex desde el servidor.

TL;DR — Storyblok es un CMS headless visual y orientado a API: almacena contenido en bloques y lo entrega por REST/GraphQL, pero el frontend renderiza las páginas y determina el SEO. SSG y SSR entregan HTML completo; CSR puede entregar HTML vacío y sufrir retrasos. SEO Fields App (seo-metatags) y AI SEO App (sb_ai_seo) solo aportan valores de campos: el frontend debe generar metadatos, canónicas, sitemaps, robots.txt y JSON-LD. En vistas previas, use X-Robots-Tag: noindex servido por el servidor, nunca JavaScript. Use /m/ para imágenes, genere el sitemap desde Content Delivery API y aproveche el contenido estructurado para la búsqueda con IA.

Evidence for this claim The article's described storyblok-seo capabilities must be evaluated against the platform's current documentation rather than assumed to be search-engine behavior. Scope: Platform-specific capability documentation. Confidence: high · Verified: Storyblok documentation Evidence for this claim Regardless of platform, Google needs crawlable URLs, accessible rendered content, descriptive metadata, and valid search directives. Scope: Google requirements independent of platform. Confidence: high · Verified: Google Search Central: SEO Starter Guide

La separación fundamental: Storyblok almacena y el frontend renderiza

Storyblok es un backend. Proporciona un modelo con bloques reutilizables, un editor visual y una Content Delivery API (REST y GraphQL), pero no produce el HTML que rastrean los buscadores. Esa tarea corresponde a un frontend independiente —Next.js, Nuxt, Astro o SvelteKit— que obtiene el contenido y renderiza las páginas.

Storyblok lo expresa así: “Since Google doesn’t load content directly from Storyblok, your team is responsible for a fast and performant website.” (traducción) «Como Google no carga contenido directamente desde Storyblok, el equipo es responsable de que el sitio sea rápido y eficiente». Su guía añade: “AI doesn’t see your CMS directly. Search engines and generative models read what’s rendered on your website or app, not the JSON coming from Storyblok’s APIs.” (traducción) «La IA no ve el CMS directamente; los buscadores y modelos leen lo renderizado, no el JSON de las API de Storyblok». El CMS es casi neutral para SEO: las decisiones del frontend lo determinan todo. Es la arquitectura descrita en SEO para un CMS headless.

Estrategia de renderizado: la decisión SEO más importante

La forma en que el frontend renderiza el contenido es la principal palanca SEO. Los cuatro modos obtienen contenido de la misma CDN o API GraphQL de Storyblok:

SSG — generación de sitios estáticos. El HTML se crea al desplegar y se sirve como archivos estáticos: completo desde la primera petición y muy rápido. El contenido nuevo o editado exige recompilar, por lo que el webhook de publicación debe activar la compilación. Conviene para contenido mayormente estático.

SSR — renderizado en servidor. El HTML se genera para cada petición en un servidor o función perimetral. Se mantiene actualizado y completo; a cambio, aumentan el costo de infraestructura y, ligeramente, el TTFB.

ISR — regeneración estática incremental. Es estático de forma predeterminada y se regenera según un horario o bajo demanda. Es un punto medio para sitios grandes, pero la primera petición posterior a la revalidación puede recibir contenido obsoleto, como se explica en CMS headless.

CSR — renderizado en el cliente (SPA). El servidor envía un armazón casi vacío y el navegador construye el DOM. Googlebot pone la página en una cola que “may stay on this queue for a few seconds, but it can take longer than that” (traducción) «puede permanecer unos segundos, aunque puede tardar más». Los rastreadores que solo leen HTML ven el armazón. Nunca entregue contenido solo con CSR. Google advierte: “If the content isn’t visible in the rendered HTML, Google won’t be able to index it.” (traducción) «Si el contenido no aparece en el HTML renderizado, Google no podrá indexarlo».

Regla práctica: contenido mayormente estático → SSG; contenido volátil → SSR; sitios grandes y mixtos → ISR; CSR solo para superficies privadas no indexadas.

Funciones SEO integradas de Storyblok y sus límites

Storyblok ofrece tres formas de gestionar valores SEO. Las tres solo capturan valores; el frontend aún debe renderizarlos.

SEO Fields App (seo-metatags). Campo nativo con título, descripción, título y descripción de OG, imagen de OG y vista previa del resultado de Google. Requiere el plan Growth y debe añadirse a cada tipo de contenido.

AI SEO App (sb_ai_seo). Genera título, descripción, palabras clave y autor con un LLM en 22 idiomas. Requiere Premium; Management API y un script de Node.js permiten generar valores por lotes.

Modelado manual. Sin requisito de plan: añada seo_title, seo_description, og_title, og_image, noindex (booleano) y canonical_url al modelo. Es la opción más flexible para sitios complejos.

Lo imprescindible: ninguna aplicación de Storyblok renderiza etiquetas por sí sola. Un componente global de cabecera o diseño debe leer los valores de la API y generarlos en el servidor, con alternativas como (seo_title || story.name).

Etiquetas canónicas

Storyblok desconoce la estructura de URL del frontend. Calcule las canónicas allí, normalmente con full_slug y el dominio, y renderícelas en el servidor. Deben ser URL absolutas en todas las plantillas. Consulte canonicalización.

Vista previa y borradores: el riesgo característico de Storyblok

El editor visual carga páginas en un iframe con parámetros _storyblok y _storyblok_tk; la vista previa usa contenido draft y un preview access token. Producción debe usar contenido published y el public access token. Dos espacios separados evitan que un token erróneo exponga borradores en el índice.

La vista previa debe quedar fuera del índice. Google advierte: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (traducción) «Cuando Google encuentra noindex, puede omitir el renderizado y JavaScript; cambiar la etiqueta mediante JavaScript quizá no funcione». Proteja estos entornos con X-Robots-Tag: noindex desde el servidor y Disallow: / en robots.txt. Vigile dominios de vista previa en Search Console.

Sitemaps y robots.txt

Storyblok no genera ninguno; ambos se crean en el frontend:

  • Sitemap: obtenga las historias publicadas mediante Content Delivery API y emita XML. En Astro use @astrojs/sitemap y rutas de Links API; en Next.js, app/sitemap.ts o next-sitemap. Limite con starts_with, pagine sitios grandes y sincronice mediante el webhook de publicación.
  • robots.txt: permita rastrear páginas públicas en producción; la vista previa debe incluir Disallow: / y el encabezado X-Robots-Tag anterior.

Datos estructurados y JSON-LD

Storyblok almacena JSON estructurado, pero schema.org JSON-LD debe generarse en el frontend: Googlebot lee HTML renderizado, no la API. Un componente JsonLd puede asignar campos (story.published_at, story.updated_at, story.name) a un <script type="application/ld+json"> servido por el servidor para Article, BreadcrumbList, Organization, Product o FAQPage.

Imágenes y Core Web Vitals

Los recursos se sirven mediante Amazon CloudFront. El servicio de imágenes mejora las CWV cuando se utiliza correctamente:

  • WebP y transformaciones se activan al añadir /m/ a la URL, por ejemplo https://a.storyblok.com/f/xxxxx/image.jpg/m/800x600. Tamaño, recorte y calidad son parámetros almacenados en caché. Sin /m/ se obtiene el original.
  • Defina width y height para evitar cambios de diseño (CLS).
  • Use fetchpriority="high" y loading="eager" en la imagen LCP, y loading="lazy" bajo el primer pantallazo.
  • Añada un campo explícito alt; filename no es texto alternativo. Consulte texto alternativo.

Redirecciones, i18n y hreflang

Redirecciones. Storyblok no tiene gestor y cambiar un slug no crea un 301. Use una historia redirects_config con bloques redirect_entry (source_url, target_story), cárguela al compilar o solicitar, use resolve_relations para actualizar destinos y refresque mediante el webhook.

Internacionalización. Storyblok admite traducciones por campo, carpeta y espacio. Las respuestas incluyen alternates; úselo para renderizar <link rel="alternate" hreflang="..."> en el servidor e incluya x-default. Consulte hreflang.

Preparación para GEO y búsqueda con IA

El modelo estructurado por componentes favorece la IA: “Storyblok was built around structured data from day one, thanks to its headless, API-first design.” (traducción) «Storyblok se creó en torno a datos estructurados desde el primer día gracias a su diseño headless orientado a API». Los LLM leen HTML renderizado, por lo que se necesitan SSR/SSG, JSON-LD correcto y marcado semántico. El frontend también puede generar llms.txt y llms-full.txt. Consulte búsqueda con IA y llms.txt.

Conclusión

Storyblok es neutral para SEO y traslada la responsabilidad al frontend. Renderice con SSR/SSG, genere los campos meta, proteja la vista previa con noindex en servidor, cree sitemap y robots.txt y use /m/ para imágenes. Así puede superar a un CMS tradicional descuidado; omitir esa capa causa fallos silenciosos. Consulte SEO para CMS headless y SEO con JavaScript.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.