Datos estructurados y sistemas de IA: utilidad y límites

Respuesta breve

JSON-LD sirve para expresar con un vocabulario compartido qué entidades hay en una página y cómo se relacionan entre sí, y su utilidad depende por completo de que represente contenido visible y datos reales. Reduce ambigüedad para cualquier sistema que decida procesarlo, pero no obliga a nadie a nada: ni un buscador está obligado a mostrar un resultado enriquecido, ni un sistema de IA está obligado a citar una web por llevar marcado. Tratar el schema como una palanca de visibilidad conduce a grafos inflados con propiedades inventadas; tratarlo como una descripción fiel de lo que la página ya dice produce un activo que se puede mantener y auditar.

Puntos clave

• El marcado describe la página; si una propiedad no está confirmada ni es visible, se omite en lugar de rellenarse.
• Un grafo pequeño y coherente, con identificadores estables, es más útil que uno extenso con entidades duplicadas.
• Schema.org define el vocabulario; cada buscador mantiene aparte sus propios requisitos de elegibilidad para resultados.
• Cuando tema y plugin pueden emitir marcado, se asigna un único propietario por entidad para evitar duplicados.
• Un validador confirma sintaxis y propiedades reconocidas; no demuestra que el dato sea cierto ni que alguien vaya a usarlo.
• No hay evidencia en las fuentes oficiales registradas de que añadir datos estructurados fuerce una cita en un sistema de IA.

Un grafo pequeño y coherente

1. Diseñar el grafoPocas entidades, identificadores estables.
2. Elegir tiposSchema.org da el vocabulario; cada buscador, sus requisitos.
3. Un propietarioTema o plugin emiten cada entidad, nunca los dos.
4. Solo lo visibleLo no confirmado se omite, no se rellena.
5. ValidarSintaxis, no verdad; tampoco garantiza una cita.

Diseñar un grafo pequeño

Una web puede conectar Organization, Person, WebSite, WebPage, Service y Article mediante identificadores estables. Cada entidad necesita campos visibles y confirmados. Si falta la biografía del autor, la dirección o el perfil social, se omite la propiedad; no se rellena para que el grafo parezca completo.

El diseño empieza por una decisión de alcance: qué entidades existen de verdad en el proyecto. Una consultoría unipersonal tiene organización, persona, sitio, páginas y artículos. No tiene sedes múltiples, ni catálogo de productos, ni valoraciones agregadas. Modelar solo lo que existe evita el problema más común de los grafos generados automáticamente, que es declarar entidades que nadie puede verificar.

El segundo paso es decidir el nivel de detalle. Un grafo útil responde tres preguntas: quién publica, quién firma y de qué trata esta página concreta. Añadir propiedades más allá de eso rara vez aporta y multiplica el coste de mantenerlo coherente cuando cambian los datos.

Elegir tipos

Schema.org define el vocabulario disponible, mientras cada buscador mantiene sus propios requisitos sobre qué tipos y propiedades pueden dar lugar a un resultado compatible. Esa separación explica por qué un marcado válido puede no producir ningún cambio visible: la validez sintáctica y la elegibilidad son cosas distintas.

Service puede describir un servicio real prestado por la organización. LocalBusiness exige datos locales completos y verificables: dirección pública, horario y ámbito de atención. Un negocio que trabaja por área de servicio sin establecimiento abierto al público no encaja en ese tipo solo porque suene mejor. FAQPage no se añade a cualquier bloque de preguntas ni se utiliza para perseguir una presentación en resultados, y las políticas generales de Google sobre datos estructurados dejan claro que el marcado debe representar el contenido principal de la página.

Cuando dudes entre dos tipos, elige el más general que sigas pudiendo justificar con datos visibles. Un tipo genérico correcto envejece bien; un tipo específico sostenido con propiedades inventadas se convierte en deuda que hay que revisar cada vez que cambia la información del negocio.

Tipos habituales en el grafo de una consultoría: cuándo se justifica cada uno y qué exige.

Tipo	Cuándo se justifica	Qué exige
Organización	La entidad que presta el servicio	Nombre, URL y datos visibles y estables
Persona	Quien firma las piezas	Que la autoría sea real y visible
Sitio y páginas	Siempre: son el soporte del grafo	Identificadores estables que las demás entidades puedan citar
Artículo	Cada análisis publicado	Fechas, autor y publicador coherentes con lo visible
Service	Un servicio real prestado por la organización	Una descripción que coincide con la página
LocalBusiness	Solo con establecimiento abierto al público	Dirección pública, horario y ámbito verificables
FAQPage	Cuando las preguntas son el contenido principal	No añadirse a cualquier bloque de preguntas

Identificadores y propiedad del marcado

Los identificadores son lo que convierte varias piezas sueltas en un grafo. Si la organización se declara en cada plantilla con un identificador distinto, el resultado no es una entidad descrita desde varias páginas: son varias entidades parecidas. Define un identificador estable por entidad, basado en una URL canónica del sitio, y reutilízalo en todas las plantillas que la mencionen.

El segundo problema estructural es la propiedad del marcado. En WordPress pueden emitir JSON-LD el tema, una suite SEO, un plugin de reseñas y un constructor visual a la vez, y ninguno sabe qué hacen los demás. El resultado son dos organizaciones, tres sitios web y artículos con dos autores distintos en la misma página. La solución es organizativa antes que técnica: se decide qué componente es propietario de cada entidad, se desactiva la emisión en los demás y se documenta la decisión para que la siguiente actualización no la deshaga en silencio.

Los identificadores son lo que convierte varias piezas sueltas en un grafo.

Validar

La validación mínima antes de dar por buena una plantilla:

• JSON parseable, sin comas sobrantes ni escapes rotos;
• una sola fuente de verdad por entidad;
• identificadores estables y URLs canónicas absolutas;
• fechas reales de publicación y de modificación;
• imagen accesible y que exista de verdad;
• autor y editor aprobados por quien puede aprobarlos;
• sin reseñas, precios ni métricas inventadas;
• contenido visible que coincide con lo declarado.

La política general de Google sobre datos estructurados indica que el marcado debe representar la página y que la elegibilidad no asegura la visualización de ningún resultado. Su guía sobre optimización para experiencias de IA mantiene esos mismos fundamentos: el marcado ayuda a describir, no a garantizar. En la búsqueda clásica el criterio es idéntico, y el repaso de qué tipos de datos estructurados siguen dando resultado ayuda a decidir cuáles merecen mantenimiento.

Conviene validar más de una plantilla. Los errores rara vez están en la página que se revisó al implementar, sino en la ficha de categoría, en la paginación, en el archivo de autor o en la página de resultados de búsqueda interna, donde la misma lógica produce un grafo que nadie miró.

Qué puede demostrar una validación

Un validador confirma sintaxis, propiedades reconocidas y algunos requisitos de elegibilidad. No demuestra que el dato sea verdadero ni que un buscador o un sistema de IA vaya a utilizarlo. Esa diferencia debe quedar explícita en cualquier auditoría, porque una captura de pantalla con todo en verde se lee con frecuencia como una promesa de resultados.

La prueba completa compara el JSON-LD con lo que ve una persona en la página, busca entidades duplicadas dentro del mismo documento y recorre varias plantillas para detectar inconsistencias. Si faltan datos humanos confirmados, se omite la propiedad en vez de completar el grafo con una suposición razonable: una suposición razonable sigue siendo un dato falso si nadie la ha verificado.

IA y entidades

Un grafo coherente puede reducir la ambigüedad para cualquier consumidor que lo procese, pero cada sistema decide de forma independiente si lo usa, cómo lo pondera y si lo ignora. No existe una relación demostrada entre añadir marcado y obtener citas en respuestas generadas, y presentar esa relación como establecida es exactamente el tipo de afirmación que conviene evitar en un informe. Si se quiere observar el efecto, se hace con un protocolo reproducible para medir citas, no con capturas sueltas.

Lo que sí es defendible es más modesto y más útil: un marcado fiel acompaña a un HTML claro, una autoría identificable, fuentes citadas y menciones reales, y ese conjunto describe mejor de quién es la página y de qué trata. El artículo sobre contenido fácil de citar desarrolla la capa textual de ese mismo trabajo, y GEO frente a SEO explica qué se puede medir de ella sin exagerar.

SEONIDAS

La marca puede usar Organization y sus servicios una vez configurados; la persona y la localización permanecen sin declarar hasta confirmar los datos correspondientes. No se usa ProfessionalService ni LocalBusiness por inferencia, porque el proyecto no publica dirección de establecimiento abierto al público y ese tipo exige información que aquí no existe.

La consecuencia práctica es que el grafo es más pequeño de lo que permitiría el vocabulario. Es una decisión deliberada: cada propiedad que se añada tendrá que seguir siendo cierta dentro de un año y comprobable por cualquiera que la lea.

En cuatro láminas

curl -s https://seonidas.com/ | jq '.["@graph"][]["@type"]'. WebSite publisher → #negocio / ProfessionalService areaServed: ES · sin dirección / Person Jesús Iturbide · worksFor → #negocio. Leído el 8 de septiembre de 2026.

1 propietario por entidad. Tema o plugin emiten cada entidad, nunca los dos: el duplicado no lo señala ningún validador.

JSON-LD: { "@graph": [ / { "@type": "Organization", / "@id": "https://ejemplo.es/#org" }, / { "@type": "Person", / "@id": "https://ejemplo.es/#persona", / "worksFor": { "@id": "https://ejemplo.es/#org" } }, / { "@type": "Article", / "author": { "@id": "https://ejemplo.es/#persona" } } / ] }

Errores frecuentes

• Declarar valoraciones agregadas, precios o número de reseñas que no existen en la página visible.
• Usar LocalBusiness con una dirección que no se publica o que no corresponde a un establecimiento real.
• Dejar que tema y plugin SEO emitan la misma entidad, generando duplicados que ningún validador señala como error.
• Cambiar los identificadores al migrar de plugin y romper todas las relaciones del grafo de golpe.
• Marcar preguntas frecuentes en páginas donde no son el contenido principal.
• Validar solo la portada y un artículo, y no revisar categorías, paginación ni archivos.
• Presentar una validación correcta como prueba de que el marcado va a producir visibilidad.

Preguntas habituales

¿Marcar con JSON-LD hace que un sistema de IA cite mi web?

No. El marcado expresa qué entidades hay en la página y cómo se relacionan, lo que reduce ambigüedad para cualquier sistema que decida procesarlo. No obliga a nadie: ni un buscador está obligado a mostrar un resultado enriquecido, ni un sistema generativo a citar la fuente. Ayuda a que se entienda, no a que se elija.

¿Puedo marcar datos que la página no muestra?

No, y es de los incumplimientos que más caro salen. Las políticas exigen que el marcado represente contenido visible y datos reales. Declarar valoraciones, precios o número de reseñas que no aparecen en la página es motivo de acción manual, y ningún validador lo señala: la sintaxis es correcta aunque el dato sea falso.

El tema y el plugin emiten el mismo marcado. ¿Es un problema?

Sí, y bastante frecuente en WordPress. Dos emisores producen la misma entidad duplicada, a menudo con datos distintos, y el validador no lo marca como error porque cada bloque es válido por separado. La solución es asignar un único propietario por entidad y desactivar el otro, no ajustar los dos hasta que coincidan.

Si el validador sale en verde, ¿está bien?

Está bien la sintaxis. Un validador confirma que las propiedades son reconocidas y que el JSON parsea; no demuestra que el dato sea cierto, que la presentación se vaya a mostrar ni que el tipo siga vigente. Lo que decide la elegibilidad son los requisitos de cada buscador, que se mantienen aparte del vocabulario.

Próximo paso

Inventaría qué componentes de la instalación emiten JSON-LD hoy y qué entidad declara cada uno. Ese inventario suele bastar para encontrar los duplicados sin abrir ningún validador. Después decide un propietario por entidad, apaga el resto, fija identificadores estables y comprueba el resultado en cinco plantillas distintas, no solo en una.

Cuando el grafo esté limpio, la siguiente prueba no es sintáctica sino de contenido: leer el JSON-LD y la página en paralelo, propiedad por propiedad, y marcar cada dato como verificado, pendiente de confirmación o eliminado. Lo que quede pendiente no se publica.

Servicio relacionado

Si esto es lo que te está pasando, posicionamiento en ia es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver posicionamiento en ia