Volver a « Bases SEO técnicas »
Bases SEO técnicas4 min de lectura

Los datos estructurados de Schema.org: cómo implementarlos

Tipos prioritarios (Organization, Product, FAQPage, Article, BreadcrumbList), un ejemplo comentado de JSON-LD y herramientas de validación.

Una vez entendido el principio de los datos estructurados, queda la pregunta práctica: qué tipos de Schema.org implementar primero, cómo escribir el JSON-LD correspondiente y cómo comprobar que el marcado es válido.

Los tipos prioritarios

Cinco tipos cubren la gran mayoría de las necesidades de un sitio:

  • Organization: la identidad de la empresa (nombre, logo, redes sociales, datos de contacto) — normalmente se define una sola vez, en la página de inicio o de forma global.
  • Product: una ficha de producto, con precio, disponibilidad y reseñas.
  • FAQPage: una lista de preguntas y respuestas, especialmente útil para ser recogida directamente en la respuesta de una IA generativa.
  • Article: contenido editorial (blog, noticias, guía), con autor, fecha de publicación y de actualización.
  • BreadcrumbList: las migas de pan, que hacen explícita la posición de una página en la jerarquía del sitio.

Existen otros tipos para necesidades más específicas: Event para un evento con fecha y lugar, LocalBusiness para un negocio con dirección física y horarios, Review para una reseña individual distinta de una valoración agregada, o HowTo para contenido estructurado en pasos. Es mejor implementar correctamente los cinco tipos prioritarios antes de extender el marcado a tipos más especializados cuyo beneficio depende en gran medida del sector de actividad.

Ejemplo comentado de JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nombre del producto",
  "description": "Descripción breve y factual del producto.",
  "brand": {
    "@type": "Brand",
    "name": "NombreDeMarca"
  },
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

Cada propiedad debe reflejar información realmente presente y verificable en la página: el precio mostrado debe coincidir con el precio marcado, y la valoración media debe corresponder a reseñas reales y consultables.

Para una página de preguntas frecuentes:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "¿Cuánto tarda la puesta en marcha?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "La puesta en marcha suele tardar entre 2 y 5 días laborables según la complejidad del proyecto."
      }
    }
  ]
}
</script>

Dónde colocar el código

El JSON-LD se inserta generalmente en el <head> o justo antes del cierre del <body>, sin ninguna dependencia del maquetado visual de la página — a diferencia de un marcado HTML5 semántico, que permanece estrechamente ligado a la estructura visual del documento. Esta es una de las ventajas de JSON-LD frente a las sintaxis alternativas (microdata, RDFa), que requieren anotar directamente las etiquetas HTML visibles. Esta independencia respecto al renderizado visual también permite generarlo dinámicamente a partir de una base de datos (ficha de producto, sistema de gestión de contenidos) sin intervención manual en cada página, lo que lo convierte en una solución especialmente adecuada para sitios con un gran número de páginas similares.

Herramientas de validación

Antes de publicar, son necesarias dos comprobaciones: la validación sintáctica (¿el JSON está bien formado, sin comas de más ni comillas que falten?) y la validación semántica (¿los tipos y propiedades utilizados existen en el vocabulario de Schema.org, y son coherentes entre sí?). Las herramientas de prueba de resultados enriquecidos de Google y los validadores de Schema.org de la comunidad permiten detectar ambas categorías de errores antes de publicar, y comprobar que no falta ninguna propiedad obligatoria para el tipo utilizado.

Conviene repetir esta comprobación después de cada cambio en la plantilla que genera el marcado, no solo en el momento de la implementación inicial: una actualización del CMS, un cambio en la estructura de la base de datos o una actualización del tema pueden romper silenciosamente un bloque de JSON-LD generado dinámicamente, sin que nada lo señale visualmente en la página.

Combinar varios tipos en una misma página

Una página puede llevar legítimamente varios bloques de Schema.org a la vez: una ficha de producto puede combinar Product para la ficha en sí, BreadcrumbList para las migas de pan, y Organization para la identidad de la marca que lo vende. Estos bloques pueden declararse por separado en varias etiquetas <script>, o agruparse en un mismo bloque mediante la propiedad @graph, que permite vincular explícitamente varias entidades entre sí dentro de un único documento JSON-LD. Este segundo enfoque se vuelve preferible en cuanto las entidades necesitan hacerse referencia mutuamente (el autor de un artículo, la marca de un producto), ya que evita duplicar información entre varios bloques independientes.

Errores frecuentes

  • Marcado duplicado o contradictorio entre varios bloques de JSON-LD en la misma página.
  • Datos marcados que ya no coinciden con el contenido visible tras una actualización (precio cambiado en la página pero no en el JSON-LD).
  • Usar un tipo de Schema.org que no corresponde realmente al contenido (marcar una entrada de blog como Product).
  • JSON mal formado que invalida silenciosamente todo el bloque.
  • Multiplicar los tipos secundarios antes de haber implementado y validado correctamente los tipos prioritarios.

Esta lección cierra la parte de marcado técnico del módulo. La checklist técnica completa que sigue recoge todos los puntos vistos hasta ahora en forma de lista práctica, antes de pasar a los fundamentos propiamente dichos del GEO.