Datos estructurados con JSON-LD: ejemplos para copiar y probar
Respuesta corta: Los datos estructurados describen el contenido de una página en una forma que los buscadores pueden leer directamente, y Google recomienda para ello el formato JSON-LD: un bloque de JSON dentro de una etiqueta
<script type="application/ld+json">. Copia uno de los dos ejemplos de abajo, cambia los valores de example.com por datos que se vean en tu página y comprueba el resultado en la Prueba de resultados enriquecidos de Google (Rich Results Test). Un código válido hace que una página pueda optar a resultados enriquecidos; Google no garantiza que aparezcan.
¿Qué son los datos estructurados y qué hace Google con JSON-LD?
Google define los datos estructurados como «a standardized format for providing information about a page and classifying the page content» (Google), es decir, una forma normalizada de dar información sobre una página y clasificar su contenido. Buena parte del vocabulario viene de schema.org, y JSON-LD es una de las tres maneras de escribirlo. Las otras dos, Microdata y RDFa, añaden atributos al HTML visible. JSON-LD, en cambio, lo guarda todo en un bloque aparte, así que puedes añadirlo o repararlo sin tocar el diseño.
Google dice que los tres formatos son igual de válidos siempre que el marcado sea correcto y esté bien implementado. Aun así, recomienda JSON-LD cuando tu configuración lo permita, porque es «the easiest solution for website owners to implement and maintain at scale» (Google), o sea, la solución más fácil de implementar y mantener a gran escala.
Lo que puedes ganar: Google escribe que los datos estructurados «can enable search results that are more engaging to users», a lo que llama resultados enriquecidos. Mantiene una galería de funciones admitidas, entre ellas Article, Breadcrumb, Event, Organization, Product y Recipe. Un punto más de la introducción de Google: para saber cómo se comporta la Búsqueda, fíate de la documentación de Google y no de la de schema.org, que tiene más atributos y objetos de los que Google Search necesita.
Tres reglas de las directrices generales sobre datos estructurados de Google valen antes de que escribas una sola línea de código:
- Describe la página en la que está el marcado, y solo lo que los visitantes ven en ella.
- No bloquees a Googlebot las páginas con datos estructurados, ni con robots.txt ni con
noindexni de otro modo. - Rellena todas las propiedades obligatorias del tipo que uses. Los elementos a los que les falta alguna «are not eligible for rich results», es decir, no pueden optar a resultados enriquecidos.
Ejemplo 1: marcado Organization para tu página de inicio
Google recomienda poner el marcado Organization en tu página de inicio o en una sola página que describa la organización, como «Quiénes somos». No lo necesitas en todas las páginas (Google). El tipo no tiene propiedades obligatorias; Google recomienda añadir las que correspondan. Sustituye todos los valores:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Bicicletas Ejemplo",
"url": "https://www.example.com/",
"logo": "https://www.example.com/images/logo.png",
"description": "Bicicletas Ejemplo fabrica bicicletas a medida.",
"email": "contacto@example.com"
}
</script>
Qué hace cada propiedad, según la página de Google:
name: usa el mismo nombre que usas como nombre del sitio.url: la dirección de tu sitio web, que ayuda a Google a identificar la organización de forma única.logo: al menos 112 × 112 px, rastreable e indexable. Puede ayudar a Google a decidir qué logotipo mostrar en los resultados de búsqueda y en los paneles de conocimiento.descriptionyemail: datos opcionales. Añadeaddress,contactPointosameAs(una página de perfil en otro sitio) solo si te corresponden.
Si encaja un subtipo más específico, Google lo recomienda, por ejemplo OnlineStore para una tienda o un subtipo de LocalBusiness para un restaurante.
Ejemplo 2: Article y migas de pan en una entrada de blog
Google entiende varios elementos en una misma página, ya los anides o los enumeres por separado (Google). Este ejemplo enumera dos elementos en una matriz JSON, cada uno con su propio @context, que es el patrón que Google muestra para elementos individuales:
<script type="application/ld+json">
[
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Cómo elegir un casco de bicicleta",
"image": [
"https://www.example.com/photos/casco-16x9.jpg",
"https://www.example.com/photos/casco-4x3.jpg",
"https://www.example.com/photos/casco-1x1.jpg"
],
"datePublished": "2026-10-12T08:00:00+02:00",
"dateModified": "2026-11-04T09:20:00+01:00",
"author": [
{
"@type": "Person",
"name": "Ana Pérez",
"url": "https://www.example.com/equipo/ana-perez"
}
]
},
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },
{ "@type": "ListItem", "position": 2, "name": "Ciclismo", "item": "https://www.example.com/blog/ciclismo" },
{ "@type": "ListItem", "position": 3, "name": "Cómo elegir un casco de bicicleta" }
]
}
]
</script>
Article. Google acepta Article, NewsArticle y BlogPosting. No indica propiedades obligatorias y recomienda author, datePublished, dateModified, headline e image, para ayudar a Google a «show better title text, images, and date information» (Google). Escribe las fechas en ISO 8601 con zona horaria; si falta, Google usa la zona horaria de Googlebot. Indica cada autor como una entrada propia con tipo, nombre y url. Mantén el titular corto, porque «long titles may be truncated on some devices». Para las imágenes, Google recomienda varios archivos de alta resolución en las proporciones 16x9, 4x3 y 1x1 que tengan relación con el artículo, no logotipos.
Migas de pan (ruta de navegación). Aquí las reglas son estrictas. Una BreadcrumbList necesita al menos dos entradas ListItem, y cada una normalmente necesita position, name e item (la dirección). Solo la última puede omitir item; entonces Google usa la dirección de la propia página (Google). Google recomienda un recorrido típico del usuario en lugar de una copia de la estructura de la URL, e indica que la función está disponible en ordenador. Nuestra lectura de las directrices: muestra la misma ruta en la página, porque no se permite marcar cosas que los lectores no pueden ver.
¿Cómo pruebas JSON-LD antes y después de publicar?
- Prueba de resultados enriquecidos (search.google.com/test/rich-results). Google la llama «the official Google tool for testing your structured data». La página de la herramienta acepta una dirección o código pegado, así que puedes probar un ejemplo antes de publicarlo. Corrige primero los errores críticos; Google dice que los avisos no críticos son opcionales para poder optar a resultados enriquecidos.
- Schema Markup Validator (validator.schema.org). La página de pruebas de Google lo describe como una comprobación de todo el marcado basado en schema.org «without Google feature specific warnings», es decir, sin avisos específicos de las funciones de Google. Úsalo cuando ninguna función de Google encaje con tu tipo.
- Inspección de URLs en Search Console, después de publicar unas cuantas páginas. Google te pide confirmar que la página no está bloqueada por robots.txt,
noindexni un inicio de sesión; rastrear una página nueva puede llevar varios días. - Informes de resultados enriquecidos en Search Console. Google señala que el marcado puede romperse tras la publicación por culpa de las plantillas o de problemas al servir las páginas, así que vuelve a mirar después de cada cambio de plantilla (Google).
Cómo comprobamos los dos ejemplos de arriba el 4 de noviembre de 2026: los dos bloques se leen como JSON válido (con el módulo json de Python), y las propiedades siguen las páginas de Google sobre Organization, Article y Breadcrumb (última actualización: 8 de septiembre de 2026). No los pegamos en la herramienta de Google, así que tu primer intento de pegado es la prueba real.
Lo que JSON-LD no hace
- No garantiza un resultado enriquecido. Google escribe: «Google does not guarantee that your structured data will show up in search results» (Google). Entre sus motivos están que el algoritmo puede decidir que un resultado de texto sencillo encaja mejor y que el marcado puede ser incorrecto de maneras que la prueba no detecta.
- No es una promesa de posición. En estas páginas de Google no encontramos ninguna afirmación de que los datos estructurados mejoren las posiciones. Google describe la ventaja como la posibilidad de optar a resultados enriquecidos. Una acción manual por datos estructurados, añade Google, elimina esa posibilidad y «doesn't affect how the page ranks in Google web search».
- Las respuestas de IA no los necesitan. La guía de Google sobre las funciones de IA generativa dice: «Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add» (Google). Aun así, sigue considerando buena idea los datos estructurados para poder optar a resultados enriquecidos. SEOgrinder no mide si algún sistema de IA nombra tu sitio.
- El marcado FAQ ya no tiene resultado en Google. El registro de cambios de Google dice: «This feature will no longer appear in Google Search starting May 7, 2026» (Google). No añadas marcado FAQPage con ese fin.
Errores frecuentes: 5 fallos con JSON-LD
1. Marcar lo que nadie ve
La directriz de Google: «Don't mark up content that is not visible to readers of the page». El propio ejemplo de Google: si el marcado describe a un artista, el cuerpo de la página debe describir a ese mismo artista.
2. JSON roto
Un solo fallo de sintaxis rompe todo el bloque. El informe de datos estructurados no analizables de Search Console («Unparsable structured data report») nombra tipos de error como una coma o una llave de cierre que faltan, unos dos puntos que faltan y una secuencia de escape incorrecta en una cadena, por ejemplo una barra invertida suelta como \q dentro de un valor de texto. El consejo de Google para encontrar el fallo: empieza con un objeto vacío y vuelve a añadir tu código pieza a pieza.
3. Propiedades obligatorias que faltan
Google dice que los elementos sin sus propiedades obligatorias no pueden optar a resultados enriquecidos. El caso habitual son las entradas de migas de pan sin position, name o item.
4. Un tipo que no encaja con la página
Google pide el tipo aplicable más específico. Sus ejemplos de marcado irrelevante: un sitio de retransmisiones deportivas que marca las emisiones como eventos locales y un sitio de carpintería que marca las instrucciones como recetas.
5. Bloquear la página o sus imágenes
Las páginas con datos estructurados deben seguir abiertas a Googlebot, y las direcciones de imagen del marcado deben ser rastreables e indexables. Una regla Disallow para tu carpeta de imágenes puede deshacer un marcado cuidadoso.
¿Cómo comprueba SEOgrinder los datos estructurados?
SEOgrinder es nuestra herramienta, y la construimos nosotros. Analiza una página, abre el área «Página en Google» y mira dos tarjetas. «Datos estructurados» lista los tipos encontrados en JSON-LD y Microdata. «Comprobación de campos» cuenta las entidades y muestra cuántas son «No válidas» (falta un campo obligatorio) o «Incompletas» (solo faltan campos recomendados), con los nombres de los campos que faltan. En la lista de tareas aparecen como «A los datos estructurados les faltan campos obligatorios», «Datos estructurados incompletos», «Sin datos estructurados» y, para código que no se puede leer, «Un bloque de datos estructurados roto». Después de una corrección, pulsa «Comprobar de nuevo».
Cuatro límites. SEOgrinder lee el HTML que entrega tu servidor, así que no ve el JSON-LD que solo añade un script en el navegador, aunque Google sí puede leerlo. Lee JSON-LD y Microdata, no RDFa. Conoce los campos obligatorios de una lista de tipos comunes, no de todos los tipos. Y no decide si Google mostrará un resultado enriquecido; esa vista previa la da la Prueba de resultados enriquecidos.
El 4 de noviembre de 2026 leímos nuestras propias páginas del mismo modo. Este comando imprime 1 para un artículo y 0 para la página de inicio (para esta, cambia la dirección por https://seogrinder.com/):
curl -sS https://seogrinder.com/es/blog/checklist-seo-auditoria | grep -c 'application/ld+json'
El único bloque del artículo contiene un BlogPosting y una BreadcrumbList con tres entradas (SEOgrinder, Blog, el artículo). En la página de inicio no tenemos datos estructurados.
Preguntas frecuentes
¿JSON-LD es mejor que Microdata?
Para Google, los tres formatos son equivalentes si el marcado es válido. Recomienda JSON-LD porque es el más fácil de implementar y de mantener a gran escala.
¿Necesito datos estructurados en todas las páginas?
No. Añade un tipo solo donde encaje con la página: Organization en la página de inicio o en «Quiénes somos», Article en las entradas. Muchas páginas no tienen ningún tipo adecuado, y no pasa nada.
¿Puedo añadir JSON-LD con un plugin o con JavaScript?
Sí. Google dice que, si usas un CMS, quizá encuentres una página de ajustes o un plugin para datos estructurados, y que Google puede leer el JSON-LD que inserta un script (Google). Comprueba el resultado con la Prueba de resultados enriquecidos y recuerda que SEOgrinder solo ve lo que entrega el servidor.
¿JSON-LD mejora mi posición?
Las páginas de Google describen la posibilidad de optar a resultados enriquecidos, no mejores posiciones. Nadie puede prometer una posición.
Tu siguiente paso
Elige la página que más te importe. Pega el ejemplo 1 o el 2 en la Prueba de resultados enriquecidos con tus propios valores y corrige lo que señale. Publica, analiza después la página con SEOgrinder, abre «Página en Google» y lee la tarjeta «Comprobación de campos». Para ver los datos estructurados en el panorama general, nuestra checklist SEO muestra dónde encajan entre las demás comprobaciones.