Datos estructurados: declarar lo que eres en vez de esperar que lo deduzcan

Hay una frase que resume para qué sirven los datos estructurados mejor que cualquier definición técnica: dejas de esperar que te interpreten y empiezas a declarar lo que eres.

Una página web, vista por una máquina, es un montón de texto con etiquetas de formato. Que un párrafo esté en negrita no dice si es importante o si solo es un énfasis de estilo. Que haya un número de diez dígitos no dice si es un teléfono, un código de producto o una cifra de facturación. Que haya un nombre no dice si es el autor, un cliente mencionado o el fundador.

Los datos estructurados resuelven esa ambigüedad. Son etiquetas invisibles para el visitante que le dicen a la máquina, en un vocabulario que todas comparten, qué es cada cosa.

Cómo se ven y dónde van

El vocabulario se llama Schema.org y lo mantienen conjuntamente Google, Microsoft, Yahoo y Yandex. El formato recomendado es JSON-LD: un bloque de código dentro de una etiqueta <script> en la cabecera o el cuerpo de la página, que el navegador no muestra.

Un ejemplo mínimo de declaración de organización:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "THK Marketing",
  "foundingDate": "2012",
  "telephone": "+52-222-375-2741",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Puebla",
    "addressRegion": "Puebla",
    "addressCountry": "MX"
  }
}

Lo que cambia respecto a tener esa misma información suelta en el texto es que aquí no hay nada que deducir. foundingDate es la fecha de fundación porque lo dice la etiqueta, no porque una máquina haya inferido que «desde 2012» en el pie significa eso.

Los cinco tipos que de verdad importan

Schema.org tiene más de ochocientos tipos. Una empresa B2B necesita cinco, y un sexto si tiene domicilio con atención presencial. Lo demás es ruido.

Qué ganas de verdad, dividido en dos

Aquí conviene separar el beneficio en dos cosas distintas, porque se confunden y eso lleva a expectativas equivocadas.

Para buscadores: resultados enriquecidos

Los datos estructurados no son un factor de posicionamiento. Google lo ha dicho de forma bastante consistente y conviene repetirlo porque hay mucha propuesta comercial que insinúa lo contrario.

Lo que sí hacen es habilitar los resultados enriquecidos: las migas de pan en vez de la dirección cruda, las preguntas desplegables debajo de un resultado, la imagen en miniatura. Y eso tiene un efecto medible pero indirecto: el mismo puesto con un resultado más rico recibe una proporción mayor de clics. No subes de posición; aprovechas mejor la que ya tienes.

Para una empresa que ya aparece en la primera página de sus búsquedas importantes, esto puede ser la diferencia entre cuatro y seis visitas de cada cien. Para una que está en la página tres, no cambia nada —el problema está en otra parte.

Para motores generativos: información que pueden sostener

Este es el beneficio que casi no se explica y que hoy pesa más.

Cuando un modelo de lenguaje lee tu página para redactar una respuesta, tiene que decidir qué afirmar y con qué confianza. Un texto corrido le obliga a interpretar; una declaración estructurada le da certeza. Y un modelo que puede sostener una afirmación con confianza la incluye en su respuesta; uno que no está seguro la omite o la matiza hasta hacerla inútil.

El bloque de preguntas frecuentes declarado como FAQPage es el caso más claro. El modelo no tiene que deducir que ese párrafo responde a esa pregunta: viene emparejado. Es la forma más directa que existe de entregar material citable.

El riesgo que nadie menciona

Los datos estructurados son una declaración, y una declaración falsa tiene consecuencias.

Google aplica acciones manuales por datos estructurados engañosos. Las más frecuentes:

• Valoraciones inventadas. Declarar cuatro coma ocho estrellas sobre doscientas reseñas que no existen. Es la infracción más sancionada.
• Preguntas frecuentes que no están en la página. Marcar como FAQPage un contenido que el visitante no ve. La regla es que los datos estructurados describen lo que la página muestra; si la pregunta no está visible, no se declara.
• Tipos que no corresponden. Declararse Product sin vender un producto, o Course sin impartir un curso, para capturar un resultado enriquecido que llama más la atención.

La sanción no es sobre la página: es sobre el sitio. Se retiran los resultados enriquecidos de todo el dominio, y recuperarlos requiere corregir y pedir revisión. Es un intercambio terrible: se arriesga la señal de todo el sitio por un adorno en una página.

Cómo comprobar si los tuyos están bien

Tres herramientas, ninguna de pago, en este orden:

La prueba de resultados enriquecidos de Google. Se pega la dirección y dice qué tipos detectó, qué resultados enriquecidos habilitan, y qué errores o advertencias hay. Es la que más se parece a lo que hará Google de verdad.

El validador de Schema.org. Más estricto y menos opinable: valida contra el vocabulario completo, no solo contra lo que Google usa. Útil para cazar errores de sintaxis que la primera herramienta tolera.

El informe de mejoras de Search Console. La diferencia importante es la escala: las dos anteriores revisan una página; esta te dice que tienes ciento cuarenta artículos con el mismo campo faltante. Es donde se detectan los errores de plantilla, que son los que de verdad cuestan.

El error de criterio más común

Es este: tratar los datos estructurados como una tarea de la lista técnica, hecha una vez al lanzar el sitio y no revisada nunca más.

El problema es que se rompen en silencio. Un rediseño cambia la plantilla y se cae el bloque de autor. Alguien actualiza un artículo y la fecha de modificación no se mueve porque se escribió a mano. Se añade una sección nueva sin migas de pan. Nada de eso produce un error visible: la página se ve perfecta y la señal se degradó.

Dos hábitos lo evitan:

Que se generen del contenido, no se escriban a mano. Si la fecha de modificación sale del archivo y el autor sale de un dato único de la categoría, no pueden desincronizarse. Si están copiados en cada plantilla, un día dejarán de coincidir.

Que el informe de Search Console se mire al menos cada trimestre. Cinco minutos. Es el único lugar donde se ve el problema a escala de sitio en vez de página por página.

Lo que esto significa en la práctica

Los datos estructurados no son la parte emocionante del trabajo. No se ven, no se presentan en una junta, y nadie felicita a nadie por un BreadcrumbList bien puesto.

Pero son la diferencia entre un sitio que hay que interpretar y uno que viene explicado. Y en un momento en que lo que decide tu visibilidad es cada vez más una máquina leyendo tu página en dos segundos para decidir si te cita, venir explicado dejó de ser un detalle de implementación.

Es, además, de lo poco en esta disciplina que se hace una vez y dura años.

Si quieres recorrer las seis comprobaciones sobre tu propio sitio, el documento descargable de esta sección las incluye con las herramientas y lo que hay que buscar en cada una.