Datos estructurados y JSON-LD: guía práctica de implementación SEO

Los datos estructurados ayudan a los motores de búsqueda a entender de qué trata una página. JSON-LD es la forma más común de agregarlos porque mantiene los datos legibles por máquinas separados del HTML visible.

Los datos estructurados pueden hacer que una página sea elegible para funciones de búsqueda mejoradas, pero no garantizan rich results. Google y otros motores deciden qué mostrar según calidad de página, intención de búsqueda, reglas de elegibilidad y muchas otras señales.

Referencias útiles:

Qué hacen los datos estructurados

Los datos estructurados dan significado explícito al contenido de una página. En vez de ver solo texto, un motor de búsqueda puede entender que una página es un artículo, producto, aplicación de software, breadcrumb trail, sección FAQ u otro tipo reconocido.

Buenos datos estructurados deben:

Coincidir con el contenido visible de la página.
Usar el tipo Schema.org más específico y relevante.
Incluir propiedades requeridas y recomendadas.
Mantenerse precisos cuando el contenido cambia.
Validarse antes del despliegue.

No uses datos estructurados para describir contenido que los usuarios no pueden ver. Es un problema común de calidad y puede hacer que el markup no sea elegible.

Por qué JSON-LD suele ser el mejor formato

Existen varios formatos de datos estructurados, pero JSON-LD suele ser el más fácil de mantener.

Formato	Cómo se agrega	Mantenimiento
JSON-LD	Bloque `<script type="application/ld+json">`	Limpio y separado del HTML
Microdata	Atributos dentro de elementos HTML	Fácil de romper con cambios de template
RDFa	Atributos dentro de elementos HTML	Potente pero más complejo

Con JSON-LD, el markup frontend puede cambiar sin reescribir cada atributo de datos estructurados.

Patrón básico de JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data and JSON-LD: Practical SEO Implementation Guide",
  "description": "Learn how to add JSON-LD structured data safely.",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

Los campos centrales son:

@context: normalmente https://schema.org.
@type: el tipo Schema.org, como Article.
Propiedades: campos que describen la entidad, como headline, author o datePublished.

Markup de Article

Usa Article, BlogPosting o NewsArticle para contenido editorial. Elige el tipo que mejor coincida con la página. Para posts normales de blog, BlogPosting suele ser adecuado.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Split a PDF Safely",
  "description": "A practical guide to extracting and splitting PDF pages.",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

Sé honesto con las fechas. No actualices dateModified solo para que el contenido parezca fresco si la página no cambió realmente.

Markup BreadcrumbList

Los datos estructurados de breadcrumbs ayudan a los motores de búsqueda a entender la jerarquía de la página.

<script type="application/ld+json">
{
  "@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": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

El breadcrumb trail en JSON-LD debe coincidir con la navegación que los usuarios pueden entender en la página.

Markup FAQPage

Agrega FAQPage solo cuando la página realmente contiene preguntas y respuestas visibles. No agregues FAQs falsas solo para apuntar a rich results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does structured data guarantee rich results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Structured data can make a page eligible, but search engines decide whether to show enhanced results."
      }
    },
    {
      "@type": "Question",
      "name": "Should JSON-LD match visible page content?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Markup should describe content that users can also see on the page."
      }
    }
  ]
}
</script>

FAQ markup no es un atajo para ocupar más espacio en búsqueda. Úsalo solo cuando mejora la claridad para usuarios.

Markup SoftwareApplication

Para herramientas online, apps o software descargable, SoftwareApplication puede describir lo que ofrece la página.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

Incluye solo campos verdaderos. Si agregas ratings, reviews, precios o claims de plataforma, deben estar respaldados por contenido visible y el estado real del producto.

Múltiples bloques JSON-LD

Puedes incluir más de una entidad de datos estructurados en una página. Por ejemplo, un artículo de blog también puede tener breadcrumbs.

Puedes usar bloques script separados:

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

O usar un array:

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

Los bloques separados suelen ser más fáciles de generar desde templates.

Flujo de validación

Usa un flujo simple antes de publicar:

Genera JSON-LD desde los mismos datos fuente que usa la página.
Verifica que el markup sea JSON válido.
Ejecuta la URL o el código en el Rich Results Test.
Después de indexar, monitorea reportes de datos estructurados en Search Console.
Revisa templates después de cambios importantes de diseño, routing o CMS.

Pasar la validación significa que la sintaxis y algunas reglas de elegibilidad se cumplen. Aun así no garantiza un rich result.

Errores comunes

El markup no coincide con el contenido visible

Si JSON-LD dice que la página tiene reviews, FAQs, precios o detalles de autor, los usuarios deben poder verificar esos detalles en la página.

Tipo incorrecto

No uses Product para toda página de herramienta solo porque los rich results de producto se ven atractivos. Usa el tipo que corresponde a la página.

Ratings falsos o sin respaldo

El markup de reviews y ratings necesita reseñas visibles reales. No inventes aggregate ratings.

Fechas inconsistentes

datePublished y dateModified deben coincidir con el ciclo real del contenido. Actualiza fechas modificadas solo cuando ocurran cambios significativos.

URLs rotas

URLs de imagen, logo, canonical y página deben ser absolutas, rastreables y estables.

Desajuste de idioma

En sitios multilingües, cada página localizada debe tener datos estructurados en el mismo idioma que la página, con canonical y alternate links correctos gestionados en otra parte de la página.

Consejos de implementación

Genera datos estructurados desde tu CMS o metadata de página, no a mano en cada página.
Escapa correctamente texto generado por usuarios para que el JSON siga siendo válido.
Mantén un template reutilizable por tipo de página.
Prueba páginas representativas, no solo la homepage.
Revalida después de cambiar rutas, slugs, perfiles de autor o generación de imágenes.
Trata warnings como oportunidades de mejora, pero prioriza errores.

Checklist final

Antes de publicar JSON-LD, confirma:

El markup describe contenido visible de la página.
El tipo Schema.org encaja con la página.
Los campos requeridos están presentes.
Las URLs son absolutas y rastreables.
Fechas, autores, títulos y descripciones coinciden con la página.
La página pasa el Rich Results Test cuando aplica.
Search Console se monitorea después del despliegue.

Los datos estructurados no son un truco para forzar resultados de búsqueda más ricos. Son una forma limpia de hacer explícito el significado de la página. Cuando son precisos, mantenidos y alineados con el contenido visible, mejoran la probabilidad de que los motores de búsqueda entiendan correctamente el contenido.