Schema.org bien hecho: lo que los validadores no miden y los LLMs sí leen

El problema no es la ausencia de schema. La ausencia es fácil de detectar y de corregir. El problema que encontramos con más frecuencia en diagnósticos es otro: schema sintácticamente válido pero semánticamente inútil para un LLM. El validador dice ✓. El motor generativo no sabe quién eres.

La combinación más común que vemos al auditar: un bloque Organization sin @id, un sameAs que apunta al LinkedIn personal del founder en lugar del perfil corporativo, y —cuando hay productos— aggregateRating declarado sin un solo objeto Review que lo respalde.

Cualquier auditor SEO clásico marcaría esto como no crítico. Para los LLMs es información activamente dañina: el motor aprende que eres una entidad con rating 4.8, detecta que no tiene fuentes que lo confirmen, y descarta la declaración. En el mejor caso te ignora; en el peor, baja tu score de confiabilidad de entidad.

Las cuatro correcciones

En los diagnósticos de identidad que ejecutamos, cuatro cambios concentran la mayor parte del impacto en cobertura de LLMs. Ninguno requiere tocar contenido:

1. Agregar @id canónico a cada Organization y SoftwareApplication o Product. El @id debe ser una URL estable de tu propio dominio (ej. https://tudominio.com/#organization). Sin él, el motor no puede resolver si la entidad que describe esta página es la misma que ya indexó desde otra fuente.
2. Reemplazar sameAs personales por corporativos. Los LLMs usan sameAs como señal de identidad cross-fuente. LinkedIn corporativo, Wikidata, Crunchbase y GitHub organization son los destinos más leídos. El LinkedIn del founder describe una persona, no la empresa.
3. Quitar aggregateRating sin Review. Un rating declarado sin reseñas reales es una señal de inconsistencia que los motores detectan. Viola además las directrices de Google Rich Results. Sin reseñas verificables: sin rating.
4. Dar a cada producto su propio nodo con @id distinto. Cuando todos los productos comparten el nodo Organization padre, el motor te ve como una marca monolítica. Cada SoftwareApplication o Product con su propio @id —enlazado al Organization vía provider— permite que el motor cite el producto correcto según la consulta.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "@id": "https://tudominio.com/productos/nombre#software",
  "name": "Nombre del producto",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "provider": {
    "@id": "https://tudominio.com/#organization"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/QXXXXXXX",
    "https://www.linkedin.com/company/tu-empresa/",
    "https://www.crunchbase.com/organization/tu-empresa"
  ]
}

Por qué funcionan estas correcciones

Los motores generativos no leen schema directamente. Leen un índice que otro proceso construyó leyendo schema. Ese proceso tiene tres responsabilidades:

• Reconocer entidades (¿es este un producto, una persona, una empresa?)
• Resolverlas (¿es esta entidad la misma que ya tengo indexada desde otra fuente?)
• Conectarlas (¿este producto pertenece a esta empresa?)

Los @id canónicos resuelven el segundo problema. Los sameAs a Wikidata resuelven el primero por consenso —si Wikidata dice que esta empresa existe, el motor le da más peso—. Los enlaces provider resuelven el tercero. Sin las tres señales, el motor te ve como un objeto suelto en el espacio; con las tres, formas parte del grafo.

De los motores que monitoreamos, Perplexity es el que reacciona más rápido a cambios en schema. Su pipeline de retrieval refresca fuentes con frecuencia alta para dominios que ya tiene indexados, y cada respuesta expone un array citations[] que es first-class en su API. Un dominio con schema bien estructurado se vuelve fuente más fácilmente citable —no necesariamente más autoritativa, pero sí más cómoda de citar—. ChatGPT, Claude y Gemini reflejan los cambios en semanas, no días.

Diagnóstico de 30 minutos

Si tu sitio tiene schema, vale la pena correr este diagnóstico antes de cualquier otra jugada del playbook AEO:

1. Abre tu schema en Schema.org Validator —no en Rich Results Test; miden cosas distintas—.
2. Verifica que cada entidad principal tenga @id canónico que apunte a una URL real de tu dominio.
3. Verifica que sameAs apunte a entidades corporativas, no a perfiles personales.
4. Si tienes aggregateRating, confirma que existan objetos Review reales que lo respalden. Si no los tienes, quita el rating.
5. Si tienes múltiples productos, verifica que cada uno tenga su propio nodo con @id distinto enlazado al Organization.

Los primeros cuatro son correcciones de 1 a 2 horas. El quinto depende del tamaño de tu catálogo, pero es el que más cambia la granularidad con que los motores citan tu marca.

No es magia: es plomería bien hecha, leída por motores que aprendieron a confiar en plomería bien hecha. El schema.org no garantiza visibilidad, pero su ausencia o su inconsistencia la bloquea.