JSON-LD resulta mucho más sencillo cuando dejas de verlo como un adorno SEO y lo tratas como una descripción de aquello sobre lo que realmente habla una página. Una URL puede describir un artículo, una persona, una empresa, un producto, un evento o varias entidades relacionadas. JSON-LD asigna nombres, tipos, propiedades y relaciones que las máquinas pueden interpretar sin tener que deducirlos a partir de la interfaz.
Esta guía reúne doce usos prácticos de JSON-LD para sitios modernos. El objetivo no es marcarlo todo, sino elegir el grafo más pequeño y veraz que describa el contenido visible y responda a un propósito real de búsqueda o descubrimiento.
Para qué se utiliza JSON-LD
JSON-LD es un formato de datos enlazados. En una web suele aparecer dentro de un elemento <script type="application/ld+json"> y utilizar el vocabulario de Schema.org. Los buscadores pueden usarlo para comprender entidades y, en los tipos admitidos, evaluar una página para presentaciones especiales en los resultados.
No garantiza rankings ni resultados enriquecidos. Su valor práctico es la claridad: hace explícito qué representa la página, qué datos pertenecen a cada entidad y cómo se relacionan.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "Ejemplos y usos de JSON-LD",
"url": "https://example.com/es/ejemplos-json-ld"
}
</script>1. Organization: definir la empresa responsable del sitio
Utiliza Organization en una página autorizada sobre una empresa, normalmente la portada o la página «Acerca de». Permite relacionar el nombre, la URL canónica, el logotipo, los datos de contacto y los perfiles públicos verificados. Mantén un @id estable y reutilízalo cuando otros objetos hagan referencia a la organización.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Estudio Ejemplo",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.linkedin.com/company/estudio-ejemplo"]
}Adecuado para: agencias, empresas, organizaciones, instituciones y marcas con identidad propia.
2. Person: establecer una identidad profesional o creativa
Utiliza Person cuando la página trate principalmente sobre una persona: un portfolio, un perfil de autor, una página de conferenciante o una web personal. Entre las propiedades útiles están name, url, jobTitle, worksFor y sameAs. Enlaza únicamente perfiles que representen realmente a esa persona.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/#person",
"name": "Alex Rivera",
"url": "https://example.com/",
"jobTitle": "UX Engineer",
"sameAs": ["https://www.linkedin.com/in/alex-rivera"]
}Adecuado para: portfolios, consultores, creadores, autores y perfiles profesionales públicos.
3. WebSite: describir el sitio completo
WebSite representa la web completa, no una página individual. Suele combinarse con Organization o Person e identificarse desde la portada. No debe sustituir la descripción del contenido específico de cada URL.
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"name": "Estudio Ejemplo",
"publisher": { "@id": "https://example.com/#organization" },
"inLanguage": ["en", "es"]
}Adecuado para: declarar el nombre del sitio, su editor, sus idiomas y la relación con la entidad principal.
4. Article y BlogPosting: identificar contenido editorial
Usa Article, BlogPosting o NewsArticle cuando la página sea una obra editorial. El marcado debe coincidir con el titular, el autor, las fechas y la imagen visibles. Google documenta recomendaciones adicionales para los datos estructurados de artículos.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Ejemplos de JSON-LD: 12 usos prácticos",
"datePublished": "2026-09-01",
"dateModified": "2026-09-01",
"author": { "@id": "https://example.com/#person" },
"image": "https://example.com/images/guia-json-ld.jpg",
"mainEntityOfPage": "https://example.com/es/ejemplos-json-ld"
}Adecuado para: artículos de blog, informes, noticias, tutoriales y contenido editorial extenso.
5. BreadcrumbList: hacer explícita la jerarquía
BreadcrumbList describe la posición de una página dentro de una jerarquía. Sus elementos deben corresponder a una ruta de navegación real y lógica, no a una lista inventada únicamente para el marcado. Google mantiene directrices específicas para las migas de pan.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://example.com/es/blog" },
{ "@type": "ListItem", "position": 2, "name": "SEO técnico", "item": "https://example.com/es/blog/seo-tecnico" },
{ "@type": "ListItem", "position": 3, "name": "Ejemplos de JSON-LD" }
]
}Adecuado para: comercio electrónico, documentación, publicaciones y sitios con categorías significativas.
6. Product: describir algo que puede comprarse
Utiliza Product para un producto o una variante concreta. El precio, la disponibilidad, las valoraciones y las reseñas deben reflejar información visible para el usuario. La documentación de productos de Google distingue entre fichas de comerciante y fragmentos de producto.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Cuaderno de campo",
"image": "https://example.com/cuaderno.jpg",
"sku": "FN-01",
"offers": {
"@type": "Offer",
"priceCurrency": "EUR",
"price": "24.00",
"availability": "https://schema.org/InStock",
"url": "https://example.com/productos/cuaderno"
}
}Adecuado para: bienes físicos, variantes y productos digitales comprables. No corresponde a una página genérica de servicios.
7. SoftwareApplication: explicar una aplicación
SoftwareApplication puede describir una aplicación móvil, web, de escritorio u otro software. Utiliza un subtipo más específico, como MobileApplication o WebApplication, cuando encaje con precisión.
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Temporizador Focus",
"applicationCategory": "ProductivityApplication",
"operatingSystem": "Web, iOS, Android",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "EUR"
}
}Adecuado para: páginas de producto de aplicaciones, SaaS, herramientas web y software descargable.
8. Event: publicar un evento real con fecha y lugar
Utiliza Event para algo que sucede en un momento definido: una conferencia, un webinar, un taller, una actuación o un encuentro. El estado y el modo de asistencia son importantes cuando el evento se aplaza, cancela, celebra online o adopta un formato híbrido. Sigue las directrices actuales de Google para eventos.
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Taller de datos estructurados",
"startDate": "2026-10-15T18:00:00+02:00",
"endDate": "2026-10-15T20:00:00+02:00",
"eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
"eventStatus": "https://schema.org/EventScheduled",
"location": { "@type": "VirtualLocation", "url": "https://example.com/taller" }
}Adecuado para: páginas individuales de eventos, no categorías que mezclan todo un calendario.
9. VideoObject: aportar datos sobre un vídeo reproducible
VideoObject ayuda a describir un vídeo insertado en una página. La miniatura, la fecha de publicación, la duración, la descripción y la URL deben ser correctas y accesibles. La documentación de vídeos de Google explica las propiedades y requisitos de indexación.
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "Cómo conecta JSON-LD las entidades de una web",
"description": "Una explicación visual de un grafo conectado de Schema.org.",
"thumbnailUrl": "https://example.com/miniatura-video.jpg",
"uploadDate": "2026-09-01",
"duration": "PT6M20S",
"contentUrl": "https://example.com/videos/json-ld.mp4"
}Adecuado para: páginas donde el vídeo sea una parte principal y reproducible del contenido.
10. JobPosting: estructurar una vacante real
Utiliza JobPosting para un único puesto abierto. La descripción, la empresa, la ubicación, el tipo de empleo, la fecha de publicación y la caducidad deben coincidir con la oferta visible. No mantengas vacantes caducadas como abiertas. Las políticas de Google para ofertas de empleo son especialmente estrictas porque el marcado representa una oportunidad real.
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "Senior UX Engineer",
"datePosted": "2026-09-01",
"validThrough": "2026-10-01T23:59:59+02:00",
"employmentType": "FULL_TIME",
"hiringOrganization": { "@id": "https://example.com/#organization" },
"jobLocationType": "TELECOMMUTE",
"applicantLocationRequirements": { "@type": "Country", "name": "España" }
}Adecuado para: una página dedicada a una sola vacante activa.
11. LocalBusiness: conectar un negocio con una ubicación
LocalBusiness es un subtipo de Organization para negocios con presencia física de atención al público. Elige el subtipo más específico que corresponda. La dirección, el teléfono, el horario y la información geográfica deben coincidir con la página y con otras fuentes autorizadas.
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "Estudio de investigación Ejemplo",
"url": "https://example.com/",
"telephone": "+34 900 000 000",
"address": {
"@type": "PostalAddress",
"streetAddress": "Calle Ejemplo 10",
"addressLocality": "Barcelona",
"postalCode": "08001",
"addressCountry": "ES"
}
}Adecuado para: tiendas, restaurantes, clínicas, estudios y servicios profesionales locales. Un negocio completamente remoto debería utilizar Organization.
12. CreativeWork: representar portfolios y casos de estudio
CreativeWork es útil cuando una página presenta un proyecto, diseño, informe, conjunto de datos u otra creación. Schema.org no define actualmente un tipo CaseStudy; inventarlo produciría vocabulario no válido. Un caso de portfolio puede ser un Article o BlogPosting cuya propiedad about haga referencia a un CreativeWork.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Rediseñando una experiencia de planificación de viajes",
"author": { "@id": "https://example.com/#person" },
"about": {
"@type": "CreativeWork",
"name": "Rediseño de planificación de viajes",
"creator": { "@id": "https://example.com/#person" },
"keywords": ["investigación UX", "diseño de producto", "viajes"]
}
}Adecuado para: portfolios, proyectos de diseño, investigaciones y casos de estudio. Explico este modelo con mayor detalle en JSON-LD para casos de estudio UX.
Cómo combinar varios tipos de JSON-LD
Una página suele necesitar varios objetos conectados. Un artículo puede pertenecer a una web, identificar a una persona como autora, referenciar a una organización como editora e incluir migas de pan. En lugar de duplicar cada entidad, utiliza valores @id estables y conecta los objetos dentro de @graph.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"@id": "https://example.com/#person",
"name": "Alex Rivera"
},
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"author": { "@id": "https://example.com/#person" }
},
{
"@type": "BlogPosting",
"@id": "https://example.com/es/ejemplos-json-ld/#article",
"headline": "Ejemplos y usos de JSON-LD",
"author": { "@id": "https://example.com/#person" },
"isPartOf": { "@id": "https://example.com/#website" }
}
]
}El grafo no mejora simplemente por ser más grande. Añade una entidad cuando aclare una relación real o ayude al propósito de la página.
Cómo elegir el tipo de schema correcto
Empieza por la entidad principal. ¿La página presenta un artículo, producto, evento, persona, empleo o aplicación?
Utiliza el subtipo válido más específico. BlogPosting es más preciso que CreativeWork para un post, siempre que siga siendo correcto.
Comprueba la correspondencia con el contenido visible. Una propiedad no debería afirmar un precio, valoración, autor o disponibilidad que el usuario no pueda verificar.
Consulta por separado la documentación de Google. La validez en Schema.org y la elegibilidad para funciones de Google son preguntas distintas.
Prefiere identificadores estables. Reutiliza los mismos
@idcanónicos para una persona, organización o sitio.
Errores habituales con JSON-LD
Inventar tipos. Si un tipo no existe en Schema.org, escribir su nombre no lo convierte en válido.
Añadir afirmaciones invisibles. El marcado no debe presentar valoraciones, precios, empleos o eventos ausentes de la página.
Usar la entidad equivocada. Product no es una etiqueta genérica para servicios y LocalBusiness no corresponde a cualquier empresa.
Duplicar objetos contradictorios. Plugins, temas y scripts personalizados pueden generar schemas que compiten entre sí.
Mantener datos obsoletos. Empleos caducados, eventos pasados, precios antiguos y disponibilidad incorrecta vuelven poco fiable el marcado.
Esperar que el schema arregle contenido débil. El marcado describe una página; no crea autoridad, relevancia ni utilidad.
Cómo validar JSON-LD antes de publicar
Valida el vocabulario y la estructura del grafo con el validador de Schema.org.
Prueba las funciones admitidas por Google con la prueba de resultados enriquecidos.
Compara cada propiedad importante con el contenido visible.
Inspecciona la URL publicada, no solamente la vista previa del CMS.
Vigila en Search Console los problemas de datos estructurados detectados.
Si implementas JSON-LD mediante un CMS, escapa los valores dinámicos como JSON y prueba varios registros, no solo el ejemplo más limpio. Las comillas, imágenes ausentes, campos opcionales, traducciones y valores vacíos suelen romper las plantillas. Para ver un proceso de implementación concreto, consulta SEO estructural y JSON-LD en Framer (en inglés).
La regla práctica
Usa JSON-LD para expresar lo que una persona atenta ya puede aprender de la página. Elige la entidad principal, descríbela mediante el tipo correcto más específico, conecta las entidades relacionadas con identificadores estables y detente antes de que el grafo se vuelva especulativo. Los mejores datos estructurados no son los más elaborados, sino los más fáciles de verificar y mantener.
