Qué son los datos estructurados y qué hacen de verdad

Al montar el marcado de esquema de este mismo blog apareció un dato que nadie buscaba: la foto de retrato del autor, 900 píxeles de ancho por 1.252 de alto, estaba declarada como imagen social de todas las páginas. Vertical, en una tarjeta que espera algo cercano a 1,91:1. Ningún validador se había quejado: no había nada inválido. Solo declaraba algo que no servía. Ese es el patrón de esta capa. No falla con un error. Falla en silencio.

¿Qué son los datos estructurados?

Es un formato para describir el contenido de una página a una máquina. No suben posiciones: son el requisito para optar a resultados enriquecidos, que cambian cómo se ve el resultado. En un sitio nuevo casi nunca son la prioridad; en uno de autoridad media dependen del tipo de página; en uno consolidado son mantenimiento.

Respuesta rápida

• Los datos estructurados no suben posiciones. Cambian cómo se presenta el resultado y facilitan la extracción, que son dos efectos distintos.
• Lo que más rinde no es ningún tipo suelto, sino que todos los nodos cuelguen de un mismo @graph y se referencien por @id.
• El fallo más caro es silencioso: una referencia @id a un nodo que no existe deja el JSON válido y la relación ignorada.
• Declarar de más sale peor que no declarar. Un SearchAction sin buscador interno manda al rastreador a un 404.

Qué tipo de problema es esto

El modelo mental dominante trata el marcado como un formulario. Hay campos, se rellenan, y cuantos más se rellenen mejor puntúa la página. De ahí salen las auditorías que enumeran tipos emitidos como si fueran una nota: Article, FAQPage, BreadcrumbList, Organization, cuatro de cuatro, correcto.

Se parece más a una declaración jurada: afirmaciones sobre entidades del mundo, dirigidas a un receptor que no está obligado a creerlas ni a avisar de que no las creyó. Sin acuse de recibo.

De ahí salen las dos consecuencias que gobiernan lo demás. Declarar de más es un pasivo, porque toda afirmación falsa se puede comprobar. Y el único control de calidad es el que uno se monta: los validadores comprueban sintaxis, no verdad.

Casi ninguna definición incluye esa segunda mitad, y la omisión explica la mayoría de las decepciones del sector. Google documenta el marcado como requisito para optar a determinados resultados enriquecidos. No lo documenta como factor de posicionamiento, porque no lo es.

Los dos efectos que se confunden

Presentación y extracción no son lo mismo.

Presentación es lo visible: estrellas de valoración, precio, migas de pan. Cambia el aspecto del resultado, y su efecto se mide en CTR, nunca en posición media.

Conviene saber que esta lista encoge. El desplegable de preguntas frecuentes era el ejemplo favorito de este apartado y Google lo retiró de la búsqueda el 7 de mayo de 2026, después de haberlo restringido en 2023 a sitios oficiales de gobierno y salud. En junio desaparecieron también su filtro de apariencia y su informe en Search Console. El marcado FAQPage sigue siendo válido como vocabulario y no perjudica tenerlo, pero ya no produce nada visible, y cualquier guía que todavía lo ofrezca como forma de ocupar más espacio en el resultado está describiendo una pantalla que ya no existe.

Extracción es lo invisible: que el buscador sepa qué párrafo responde qué pregunta, quién firma y a qué sección pertenece la página. No produce ningún adorno. Produce candidaturas a fragmento destacado y a cita en una respuesta generada, aunque eso lo decide el formato del contenido visible, como está desarrollado en cómo salir en los fragmentos destacados.

El segundo efecto pesa más cada año: las búsquedas sin clic pasaron del 56 % al 69 % entre mayo de 2024 y mayo de 2025, según Similarweb. Cuando dos de cada tres consultas se resuelven sin visitar nada, ser el bloque extraído deja de ser un extra.

La pieza que más importa: un solo grafo

Lo habitual es emitir cada tipo en su propio bloque <script>: uno para el artículo, otro para las migas, otro para las preguntas frecuentes. Valida perfectamente, y entrega tres hechos inconexos: un artículo, una ruta de navegación, unas preguntas. Nada dice que sean de la misma página ni que los firme la misma persona.

Un solo @graph con nodos que se referencian por @id dice otra cosa: que este artículo lo escribió esta persona, la misma de los demás artículos y la misma que firma la página de servicios.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "BlogPosting",
      "@id": "https://ejemplo.com/articulo/#articulo",
      "author":    { "@id": "https://ejemplo.com/#persona" },
      "publisher": { "@id": "https://ejemplo.com/#persona" },
      "image":     { "@id": "https://ejemplo.com/articulo/#imagen" } },
    { "@type": "Person",
      "@id": "https://ejemplo.com/#persona",
      "name": "Nombre Apellido" }
  ]
}

Este blog emite siete nodos por artículo dentro de un único grafo: BlogPosting, WebPage, BreadcrumbList, ImageObject, WebSite, Person y FAQPage, este último colgado del artículo con isPartOf en vez de suelto, para que quede claro de qué página son esas preguntas.

Esa continuidad convierte un nombre repetido en una entidad. Para que un modelo generativo cite a una persona como fuente y no como una cadena de texto frecuente, es justo lo que hace falta, y es donde el marcado se cruza con el trabajo descrito en Generative Engine Optimization.

El fallo más caro es silencioso

Una referencia @id puede apuntar a un nodo que no está en el grafo. Un identificador con una barra de más, un dominio en http cuando el resto va en https, un #persona que en otra plantilla se llamaba #autor.

El JSON sigue siendo válido y ningún validador tiene por qué quejarse: un identificador es una cadena, y está bien formada. El buscador ignora la relación y ya. No hay error en ningún sitio, no aparece en Search Console y no se ve en la página. Solo deja de funcionar la continuidad de entidad que se quería construir.

Aquí eso se probó rompiendo a propósito la referencia del autor, dejando el artículo apuntando a una Person que ya no existía en el grafo. La verificación automática la cazó. Sin ella no había forma de enterarse.

Lo que se descartó a propósito, y por qué

El marcado de este sitio se construyó leyendo lo que emite una instalación real de WordPress con Yoast, que lleva años afinando esa salida contra el Google real. Tres cosas se dejaron fuera a propósito.

• SearchAction en el WebSite. Declara un buscador interno. Aquí no lo hay, y declararlo envía al rastreador a una URL que devuelve 404.
• sameAs vacío. Es el campo de perfiles públicos que confirman que la persona existe. Un perfil inventado o abandonado hace más daño que la ausencia.
• publisher como Person, no como Organization. Esto es una marca personal, e inventar una organización para rellenar un campo declara una entidad que no existe.

El criterio común: un campo vacío no resta. Un campo relleno con algo falso sí.

Las dimensiones se leen del archivo, nunca se escriben a mano

El ImageObject del grafo y las etiquetas og:image:width y og:image:height declaran el tamaño de la imagen. Escribir esos números a mano es una decisión pequeña con consecuencia desproporcionada: la red social recorta según lo declarado, así que un ancho que no coincide con el archivo sale peor que no declararlo.

Lo implantado aquí lee el ancho y el alto de la cabecera del archivo en cada compilación. Esa lectura descubrió el problema de la entrada: alex-gonzalez-go.jpg mide 900x1252, es vertical y estaba puesta como imagen social de todo el sitio. Se cambió por hero-seo-crm.jpg, de 1600x873, que sí encaja en una tarjeta apaisada. El dato no lo dio ningún informe de SEO. Lo dio leer el archivo.

Cuándo NO hacer esto

Tres situaciones convierten el marcado en presupuesto gastado donde no está el problema.

Cuando la página no está indexada, porque un resultado que no existe no se puede presentar mejor. Eso se descarta antes con una revisión de SEO técnico.

Cuando el problema son los clics y no las posiciones. En una auditoría propia sobre un recetario de 312 páginas había una página en posición 1 con 124 impresiones y cero clics: el título que mostraba Google no contenía el nombre del plato que la gente buscaba. Ningún marcado arregla eso.

Y cuando el tipo que se quiere emitir no tiene resultado enriquecido asociado: marcar por marcar alarga el JSON sin cambio observable.

Las tres reglas que decide la documentación, y una que casi nadie cumple

JSON-LD es el formato recomendado, por delante de microdatos y RDFa. La razón práctica pesa tanto como la recomendación: va en un bloque aparte, así que se genera y se revisa sin tocar la maquetación, y un rediseño no puede romperlo por accidente.

No se marca contenido que no sea visible para quien lee la página. Es una regla explícita y se incumple constantemente sin mala intención: valoraciones que no aparecen, autores que no se firman, preguntas frecuentes que no existen en el texto. La prueba es de una frase: si un lector no puede ver ese dato, no debe estar en el marcado.

Y un marcado que no representa el contenido principal de la página no se muestra. Declarar de más no amplía la superficie, la anula.

La que casi nadie cumple no es ninguna de las tres: es que el marcado se genere desde la misma fuente que la página. Escrito a mano artículo por artículo, se desincroniza con el primer cambio de título o de fecha, y a partir de ahí describe algo que ya no existe. No falla nada, no avisa nadie, y el validador sigue en verde.

Dónde encaja esto, y qué va antes

El recorrido operativo completo, con las tres comprobaciones que hay que automatizar porque a mano no se sostienen, está en cómo implementar schema markup.

Y lo que va antes que esto en cualquier orden sensato: que la página se rastree y se indexe, según SEO técnico y por qué Google no indexa mi página.

Lo que no resuelve conviene decirlo también: no hace falta ningún dato estructurado especial para aparecer en las funciones de IA de Google, que lo documenta expresamente, y eso está en AI Overviews y en qué es llms.txt.

Errores que se repiten

• Esperar posiciones. Se vigila lo que no cambia y se abandona el CTR, que sí se mueve.
• Emitir cada tipo en su propio bloque. El buscador recibe hechos inconexos en vez de una entidad.
• Copiar un @id de otra plantilla. Apunta a un nodo inexistente y la relación se descarta sin aviso.
• Escribir a mano el tamaño de la imagen. La tarjeta social recorta según lo declarado, no según el archivo.
• Declarar un SearchAction sin buscador interno. El rastreador acaba en una URL que devuelve 404.
• Marcar contenido que no está visible. Es motivo de acción manual por spam de datos estructurados.

Datos y transparencia

Que JSON-LD es el formato recomendado, que no debe marcarse contenido que no sea visible para quien lee la página, y que un marcado no representativo del contenido principal no se muestra como resultado enriquecido, procede de las directrices generales de datos estructurados de Google, comprobadas el 12 de agosto de 2026. Esa documentación no los presenta como factor de posicionamiento, sino como requisito para optar a resultados enriquecidos.

Las dimensiones de imagen (900x1252 la foto de retrato, 1600x873 la imagen social actual) se leyeron de la cabecera de los archivos con la función del generador de este sitio, en agosto de 2026. Los siete nodos por artículo y las tres omisiones deliberadas son la configuración real de este blog, y la prueba del @id colgante se hizo rompiendo a propósito la referencia del autor aquí mismo. La página en posición 1 con 124 impresiones y cero clics sale de una auditoría propia sobre un sitio de cliente de 312 páginas que no se nombra. El dato de búsquedas sin clic, del 56 % al 69 % entre mayo de 2024 y mayo de 2025, es de Similarweb. Que el marcado no es factor de posicionamiento consta en la documentación de Google, que lo describe como requisito para optar a resultados enriquecidos. El criterio general viene de una cartera de más de 300 millones de impresiones anuales en Search Console, en los sitios que opero.

Lo que esto cambia

Hay una asimetría incómoda en esta capa. Lo que se puede comprobar con un validador es casi todo lo que no importa, y lo que importa no lo comprueba nadie por defecto.

Que un @id exista de verdad, que la imagen tenga el tamaño que dice, que el publisher sea una entidad real y no un nombre inventado para rellenar un campo: nada de eso lo mira ninguna herramienta pública, y todo eso decide si el marcado hace algo. Por eso lo que rinde no es emitir más tipos, sino escribir la comprobación que se ejecuta en cada publicación y falla ruidosamente cuando algo deja de cuadrar.

La pregunta útil antes de ampliar el marcado no es qué tipos faltan. Es otra, y suele incomodar: de todo lo que ya se declara, ¿cuánto es cierto y quién lo está verificando?

Preguntas frecuentes