Cómo añadir JSON-LD a un artículo de blog en 2026

Al terminar esta guía tendrás tres bloques JSON-LD en cada artículo del blog: Article (o BlogPosting), BreadcrumbList y, cuando la página lo merezca, FAQPage. Cada bloque es válido, se renderiza en el servidor y pasa el validador de schema.org. Es exactamente la estructura que publicamos en cada artículo de este sitio.

JSON-LD significa JavaScript Object Notation for Linked Data. Es el formato de datos estructurados que Google recomienda frente a Microdata y RDFa, porque el marcado vive en una sola etiqueta <script> en lugar de entremezclarse con tu HTML visible. Esa separación es la clave: el marcado y el diseño dejan de estorbarse, y puedes generar el bloque a partir de los mismos datos que renderizan la página.

Una advertencia honesta antes del código. En 2026 los datos estructurados aportan menos en la búsqueda clásica de Google que hace dos años. En agosto de 2023 Google limitó los rich results de FAQ a sitios autorizados de gobierno y salud, y el 7 de mayo de 2026 dejó de mostrarlos por completo en la búsqueda. Los rich results de HowTo se retiraron del escritorio en septiembre de 2023. Así que el motivo para publicar este marcado hoy no es un fragmento con estrellas. Es la legibilidad automática para los motores que ahora están al frente de tu embudo: ChatGPT, Perplexity, Gemini y las AI Overviews de Google leen los datos estructurados para decidir de qué trata una página y si la citan.

Qué necesitas antes de empezar

• Un blog con páginas de artículo renderizadas en el servidor. Si el texto del artículo lo inyecta JavaScript en el navegador, corrige eso primero: los rastreadores y los motores de IA necesitan el contenido y el marcado en el HTML inicial.
• Una URL canónica estable y absoluta por artículo (https://tudominio.com/blog/slug).
• Los metadatos reales del artículo al renderizar: título, fecha de publicación, fecha de última actualización, autor, URL de la imagen de portada, categoría.
• Acceso a validator.schema.org y a la prueba de resultados enriquecidos de Google para verificar.

Paso 1: publica un bloque Article en cada artículo

Article es el tipo base para el contenido editorial. Google acepta tres subtipos: Article, NewsArticle y BlogPosting. Para un blog usa BlogPosting. Hereda todas las propiedades de Article y señala que el contenido es una entrada, no un teletipo de noticias ni una página estática.

La guía de Google ya no lista campos estrictamente obligatorios, pero espera headline e image, y lee datePublished, dateModified, author y publisher para entender la frescura y la procedencia. Este es el bloque que publicamos:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://yourdomain.com/blog/json-ld-guide#article",
  "headline": "How to add JSON-LD to a blog article",
  "image": "https://yourdomain.com/covers/json-ld.jpg",
  "datePublished": "2026-07-04T09:00:00Z",
  "dateModified": "2026-07-04T09:00:00Z",
  "author": { "@type": "Organization", "name": "Your Studio" },
  "publisher": {
    "@type": "Organization",
    "name": "Your Studio",
    "logo": { "@type": "ImageObject", "url": "https://yourdomain.com/logo.png" }
  },
  "mainEntityOfPage": "https://yourdomain.com/blog/json-ld-guide"
}

Dos detalles que casi todos fallan. Mantén headline por debajo de 110 caracteres, porque Google trunca los más largos. Y fija dateModified a partir de tu señal real de frescura del contenido, no de una fila de base de datos que cualquier migración toca. Si dateModified miente, el ranking por frescura juega en tu contra.

Paso 2: añade un BreadcrumbList en cada página

BreadcrumbList indica a los motores dónde se sitúa la página en la jerarquía del sitio. Es barato de publicar, todavía produce la ruta de migas en la búsqueda de Google y ofrece a los motores de IA una estructura de rutas limpia para razonar. Publica uno en cada artículo:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://yourdomain.com/blog" },
    { "@type": "ListItem", "position": 2, "name": "How to add JSON-LD to a blog article", "item": "https://yourdomain.com/blog/json-ld-guide" }
  ]
}

Paso 3: añade FAQPage solo cuando la FAQ es real

FAQPage sigue siendo un tipo válido de schema.org y Google lo sigue analizando, aunque el resultado enriquecido visual haya desaparecido. Sigue siendo uno de los bloques de mayor valor para la cita en IA, porque entrega al motor un par pregunta-respuesta limpio que puede tomar literalmente. Hay una regla que no se negocia: las preguntas y respuestas del marcado deben existir, visibles, en la página. Marcar preguntas que el usuario no puede ver es una infracción de spam de datos estructurados, y es la vía más rápida a una acción manual.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does JSON-LD still help SEO in 2026?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, for machine-readability. The rich results are mostly gone, but AI engines parse the markup to understand and cite your page."
      }
    }
  ]
}

Omite este bloque en las entradas que no llevan una FAQ genuina. Un FAQPage vacío o inflado no aporta nada e invita a la marca de spam.

Paso 4: renderízalo en el servidor con Next.js

Como JSON-LD es dato, no código ejecutable, la documentación de Next.js recomienda una etiqueta <script type="application/ld+json"> normal renderizada desde un Server Component, no el componente next/script. Construye el objeto, conviértelo a texto e insértalo en tu página o layout:

export default function ArticlePage({ post }) {
  const jsonLd = buildBlogPosting(post)
  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(jsonLd).replace(/</g, "\u003c"),
        }}
      />
      <Article post={post} />
    </>
  )
}

El .replace(/</g, "\u003c") no es opcional. JSON.stringify no escapa los corchetes angulares, así que una secuencia </script> dentro de cualquier campo (un título, una respuesta) puede salir de la etiqueta y abrir un agujero XSS. Sustituir < por su escape Unicode lo cierra. Es el único detalle de seguridad que casi todos los tutoriales se saltan.

Paso 5: verifica antes de publicar

Haz tres comprobaciones, en orden:

1. Validador de schema.org. Pega la URL en validator.schema.org. Detecta errores de tipo y propiedades mal formadas.
2. Prueba de resultados enriquecidos de Google. Confirma que Google puede analizar el bloque, incluso para tipos que ya no producen un resultado enriquecido.
3. Código fuente, no el inspector. Busca application/ld+json en el HTML en bruto. Si solo aparece en el DOM hidratado y no en el código fuente, se renderiza en el cliente y muchos rastreadores lo perderán.

Fallos frecuentes y cómo resolverlos

Bloques duplicados tras la hidratación. Una etiqueta script colocada en un Server Component puede renderizarse dos veces: una en el HTML del servidor, otra cuando React hidrata. Renderízala una sola vez, arriba en el árbol, y confirma que en el código fuente hay un único bloque.

dateModified que se aleja de la realidad. Si cualquier escritura de fila actualiza tu columna updated_at, no conectes dateModified a ella. Ánclalo a una señal real de actualización editorial, o los motores aprenderán que tus fechas de frescura son ruido.

Marcar contenido invisible. El marcado FAQ o HowTo cuyo texto no está en la página infringe las políticas de datos estructurados de Google. Mantén el marcado como un espejo de lo que ve el lector.

URL relativas para imágenes o @id. Usa URL absolutas https en todo el JSON-LD. Las rutas relativas se resuelven de forma inconsistente entre parsers.

¿Y HowTo?

Publica un bloque HowTo solo en entradas realmente procedimentales, un paso a paso como este. Google retiró los rich results de HowTo del escritorio en septiembre de 2023, así que no hay recompensa visual, pero el marcado sigue ayudando a un motor de IA a reconstruir tus pasos en orden. Mantén el text de cada paso corto y concreto, y apunta la url de cada paso al título correspondiente.

Ese es todo el conjunto: BlogPosting y BreadcrumbList en cada entrada, FAQPage cuando las preguntas son reales, HowTo cuando la entrada es procedimental. Cuatro bloques, todos renderizados en el servidor, todos validados. Para el mapa más amplio de qué tipos de schema merecen un lugar en un blog, lee nuestro artículo sobre los 7 tipos de schema markup que todo blog necesita. Para entender por qué este marcado importa más para los motores de IA que para Google ahora, lee qué es la GEO y en qué se diferencia de la SEO.