Datos estructurados JSON-LD: qué necesita un sitio web normal

Los datos estructurados describen el contenido de una página con el vocabulario común de schema.org. En lugar de deducir por el diseño que «Ana Pérez» es la autora y «24 de octubre de 2026» la fecha de publicación, el buscador lee esos datos de un bloque específico y los compara con el texto visible.

En la práctica el marcado aporta tres cosas:

• claridad: las entidades de la página (organización, artículo, navegación) se nombran de forma explícita en vez de deducirse del contexto;
• compatibilidad con posibles resultados enriquecidos: si la página cumple los requisitos, el buscador puede mostrar algo más que un enlace azul;
• coherencia: si todas las páginas describen igual al autor, al editor y las fechas, el sitio es más fácil de mantener y de auditar.

Lo que el marcado no hace: no sube una página en los resultados por sí solo, no arregla un contenido débil y no reemplaza las comprobaciones técnicas básicas, como el rastreo y una etiqueta canonical correcta. La elegibilidad para un resultado enriquecido la decide Google y nunca está garantizada, ni siquiera con un código impecable. La introducción de Google a los datos estructurados ofrece una visión general.

Los datos estructurados pueden escribirse en tres formatos: JSON-LD, microdatos y RDFa. Google recomienda JSON-LD y la razón es práctica. Los microdatos se mezclan con las etiquetas HTML, así que cualquier cambio en la plantilla puede romperlos. JSON-LD vive en un bloque aparte y no depende de la estructura de la página.

Un bloque tiene este aspecto:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Example page",
  "url": "https://example.com/page"
}
</script>

Puedes colocarlo en el head o en el body; ambos funcionan. Algunas reglas que conviene recordar:

• @context siempre es https://schema.org;
• @type indica el tipo de entidad: Organization, BlogPosting, BreadcrumbList;
• todas las URL son absolutas, con https:// y el dominio;
• el contenido debe ser JSON válido: comillas rectas, sin comas finales y sin comentarios;
• una página puede tener varios bloques o uno solo con un arreglo @graph.

El navegador nunca ejecuta un script de tipo application/ld+json, solo contiene datos. Por eso estos bloques normalmente no necesitan un permiso especial en una política de seguridad de contenido. Esa política se explica en el artículo sobre cabeceras de seguridad y SEO.

El vocabulario de schema.org es enorme, pero un sitio de empresa, un blog o un servicio pequeño casi nunca necesita cientos de tipos. Un mínimo razonable es este:

El resto de tipos son para páginas que realmente son eso. Product va en la ficha de un producto, LocalBusiness en un negocio con dirección física, SoftwareApplication en la página de una aplicación, VideoObject en una página centrada en un vídeo. Añadirlos «por si acaso» a páginas con otro contenido no está permitido: las políticas de Google exigen que el marcado coincida con lo que ve el usuario.

Lo mismo vale para las reseñas y las valoraciones. Las reseñas inventadas, o las que un negocio escribe sobre sí mismo, incumplen las normas y pueden costarte la elegibilidad para resultados enriquecidos. Si en la página no hay reseñas reales, tampoco hay marcado de reseñas ni de valoraciones. Los requisitos completos están en las políticas de datos estructurados de Google.

En la página de inicio resulta cómodo describir la organización y el sitio en un único bloque @graph. Cada nodo recibe un @id y las demás páginas se refieren a él en lugar de copiar los datos.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/",
      "logo": "https://example.com/images/logo-512.png",
      "sameAs": ["https://www.linkedin.com/company/example"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Studio",
      "inLanguage": "es",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

El campo sameAs debe apuntar solo a perfiles reales que te pertenezcan. Si no tienes ninguno, omite el campo. El logotipo tiene que estar disponible en la dirección indicada y ser un archivo grande y nítido. Los requisitos del logotipo se describen en la documentación de Google sobre Organization.

En un sitio multilingüe, inLanguage coincide con el idioma de la página que contiene el bloque. Cómo conectar entre sí las versiones por idioma se explica en la guía de hreflang.

Un artículo de blog se describe con BlogPosting (un subtipo de Article). El conjunto mínimo de campos es el título, las fechas, el autor, el editor y la imagen. Las fechas usan el formato ISO 8601, por ejemplo 2026-10-24.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/robots-txt-guide#article",
  "headline": "How to write a robots.txt file",
  "description": "A practical guide to robots.txt rules and common mistakes.",
  "datePublished": "2026-10-24",
  "dateModified": "2026-10-24",
  "inLanguage": "en",
  "author": {
    "@type": "Organization",
    "name": "Example Studio",
    "url": "https://example.com/"
  },
  "publisher": { "@id": "https://example.com/#organization" },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/robots-txt-guide"
  },
  "image": "https://example.com/images/robots-txt-cover.png"
}

Cambia dateModified solo cuando hayas actualizado el contenido de verdad, no con cada cambio de plantilla. Todos los campos de Article se explican en la documentación de Google sobre artículos.

Para la navegación añade un BreadcrumbList. Cada elemento tiene una posición, un nombre y una URL, y el último es la página actual.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "robots.txt guide", "item": "https://example.com/blog/robots-txt-guide" }
  ]
}

La ruta del marcado debe coincidir con las migas de pan que ve el visitante en la página. Hay más detalles en la documentación sobre breadcrumb.

En este sitio, cada artículo lleva JSON-LD de BlogPosting y de BreadcrumbList.

FAQPage describe una página que contiene preguntas con sus respuestas. La condición clave: las preguntas y respuestas son visibles en la página y las respuestas del marcado coinciden con el texto visible. Marcar texto oculto o distinto incumple las normas.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does JSON-LD improve rankings?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not by itself. It helps search engines interpret the page, and eligibility for rich results is decided by Google."
      }
    },
    {
      "@type": "Question",
      "name": "Where do I place the JSON-LD block?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "In the head or the body of the page, as a script block of type application/ld+json."
      }
    }
  ]
}

Una nota honesta sobre las expectativas. Desde agosto de 2023 Google muestra resultados enriquecidos de preguntas frecuentes solo para sitios conocidos de gobierno y de salud. En un sitio normal el marcado sigue siendo válido e inofensivo, pero es poco probable que aparezca un resultado ampliado. Escribe el FAQ pensando en el lector y trata el marcado como un extra: mantiene los datos estructurados coherentes con el contenido visible y no perjudica. Las reglas están en la documentación de Google sobre FAQPage.

En este sitio, el FAQ del final de cada artículo es visible en la página y ese mismo FAQ está marcado en JSON-LD como FAQPage.

La mayoría de los problemas de JSON-LD son aburridos y se repiten de un sitio a otro. Estos son los que aparecen con más frecuencia:

• el bloque no se interpreta como JSON: una coma de más, comillas tipográficas en lugar de rectas, un bloque sin cerrar;
• falta @context y el validador no sabe qué vocabulario se usa;
• URL relativas en vez de absolutas;
• el marcado describe algo que no está en la página: un precio sin producto, un autor que no se muestra, reseñas escritas por el propietario;
• duplicados: la plantilla añade Organization en cada bloque y un plugin lo añade otra vez;
• valores obsoletos: una fecha que no cambia tras editar o un logotipo antiguo.

Así se ve un bloque roto:

{
  "@type": "Organization",
  "name": "Example Studio",
  "url": "/",
  "logo": "/images/logo.png",
}

Hay tres errores: falta @context, las URL son relativas y la coma tras el último campo invalida el JSON. La versión corregida:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo-512.png"
}

Si un CMS o un plugin genera el marcado, revisa el resultado en el código fuente de la página y no los ajustes del plugin.

Conviene validar en varios niveles, porque cada herramienta responde a una pregunta distinta.

1. El código fuente de la página (view-source) muestra lo que el servidor devuelve de verdad, antes de que se ejecute ningún script. Busca application/ld+json y confirma que el bloque está.
2. El Schema Markup Validator (validator.schema.org) comprueba el marcado frente al vocabulario de schema.org.
3. La Prueba de resultados enriquecidos de Google (Rich Results Test) indica qué resultados enriquecidos puede respaldar el marcado y si hay errores críticos.
4. Los informes de mejoras de Google Search Console reúnen errores y avisos de todo el sitio una vez rastreadas las páginas.

El escáner gratuito de SEOAudit es pasivo: lee la URL indicada y unos pocos recursos públicos de apoyo. En datos estructurados informa de si hay JSON-LD, si los bloques se interpretan como JSON, si se declara @context y qué valores de @type aparecen, y ofrece pistas deterministas sobre las propiedades recomendadas para los tipos habituales. Analiza hasta diez bloques de hasta 200 KB cada uno. El escáner no comprueba la corrección semántica frente a schema.org ni afirma que una página reúna los requisitos para un resultado enriquecido; para eso sirve la Rich Results Test.

El marcado es solo una parte de una auditoría SEO técnica. A su lado están el rastreo, las etiquetas canonical y la seguridad, para la que existe una comprobación de seguridad aparte. Y si te preguntas cómo leen tu sitio los asistentes de IA, consulta la página sobre la visibilidad en búsqueda con IA.