Demostrar el E-E-A-T con los datos estructurados

Introducción: los datos estructurados no crean autoridad, la hacen legible

Es el malentendido que vuelve inútil la mayoría de los marcados. Se añade un bloque JSON-LD esperando que produzca credibilidad, y no ocurre nada — porque el marcado no añade nada que no esté ya ahí.

Los datos estructurados son una traducción, no una producción. Traducen a una forma legible por una máquina lo que la página ya demuestra a una persona. Si la página no lo demuestra, la traducción describe el vacío.

Y hay algo peor: una declaración que el contenido no sostiene es más costosa que el silencio, porque es verificable. Sobre esto tenemos un caso propio, y lo contamos en el §4.

1. Lo que significan realmente las cuatro letras

Experiencia — quien escribe ha hecho la cosa. Un artículo sobre la recuperación tras un ataque escrito por alguien que ha gestionado uno no se parece a uno escrito por alguien que ha leído sobre ello.

Competencia — quien escribe conoce el campo. Se demuestra con la precisión y con los límites nombrados, no con un título.

Autoridad — otros la reconocen. No se declara, se constata: citas, referencias, retomas.

Fiabilidad — la más importante de las cuatro para un sitio comercial. Se construye con cosas banales: quiénes son ustedes, cómo contactarles, cuáles son las condiciones, qué ocurre si algo sale mal.

Los datos estructurados cubren bien la cuarta y en parte la segunda. No tocan en absoluto la primera ni la tercera. Saberlo evita esperar de un marcado lo que solo el contenido puede hacer.

2. Qué declarar, y en qué orden

Por rendimiento decreciente, y ninguno de estos puntos requiere una herramienta de pago:

Organization, una vez, en el sitio. Nombre, sitio, logotipos, perfiles oficiales. Es la base que enlaza todo lo demás. Atención a un punto medido por nosotros: si el campo de los perfiles oficiales se declara vacío, algunos motores confunden la marca con una homónima. Declararlo vacío es peor que omitirlo.

Person para la autoría, con una verdadera página de autor. No un nombre al pie del artículo: una página que dice quién es la persona, qué ha hecho, dónde se la encuentra en otros sitios. Sin esa página, el marcado author apunta a la nada.

Article con las fechas. Publicación y última modificación. La segunda cuenta más que la primera en un tema que envejece.

FAQPage solo si la página contiene realmente preguntas. Marcar como preguntas frecuentes párrafos que no lo son es el atajo más extendido y el más fácilmente detectado.

Product con precio y disponibilidad reales en las fichas de producto. El detalle está en el marcado Schema en JSON-LD.

3. Lo que NUNCA hay que declarar

Esta sección es más corta y vale más que la anterior.

• Una valoración media sin reseñas reales. Es la declaración más tentadora y la más arriesgada.
• Un autor que no existe. Un nombre inventado con una página inventada es una falsificación, no una técnica.
• Una fecha de modificación que no corresponde a ninguna modificación. Actualizar la fecha sin tocar el contenido es detectable y no produce nada.
• Un precio distinto del que aparece en el carrito. Más allá de la sanción, es un motivo de reclamación del cliente.

El criterio común, y resume el artículo: una declaración estructurada debe poder derivarse de la página. Si una persona no puede verificarla leyendo, no se declara.

4. Nuestro caso, porque es el más claro

En nuestros propios archivos, una página declaraba una valoración media y un número de reseñas cuando el producto no tenía ningún cliente. La cifra no se había inventado por malicia: venía de una plantilla rellenada con valores de ejemplo que nadie había retirado.

Dos lecciones, y es la segunda la que cuenta:

1. una cifra pública que no puede derivarse de un hecho se vuelve falsa en silencio — ninguna advertencia, ningún error, solo una declaración que deja de ser verdadera;
2. el riesgo no era la sanción, era el descubrimiento. Una visitante que compara la valoración declarada con la ausencia de reseñas en la página pierde la confianza en todo el resto del sitio, incluidas las partes exactas.

De ahí la regla que aplicamos: no declaramos nada que no podamos mostrar. Incluso cuando la declaración nos convendría.

5. El protocolo, en una página

• Organization declarada una vez, con perfiles oficiales reales — nunca un campo vacío
• Una verdadera página de autor para cada firma, antes de marcar author
• Article con fecha de publicación y de última modificación, la segunda actualizada solo ante una modificación real
• FAQPage únicamente en páginas que contienen preguntas verdaderas
• Product con precio y disponibilidad leídos desde la fuente, no escritos a mano
• AggregateRating solo si existen reseñas reales — si no, nada
• Verificar el marcado con la herramienta de prueba, después releer la página y preguntarse: ¿podría una persona verificarlo?

El último punto es el que las herramientas no hacen. Un marcado puede ser técnicamente válido y decir algo falso.

Conclusión

El E-E-A-T no se marca, se gana — y los datos estructurados sirven únicamente para hacerlo legible a una máquina que no sabe leer entre líneas.

El trabajo útil no es, por tanto, añadir bloques JSON-LD: es tener algo que declarar. Una verdadera página de autor, condiciones claras, un contacto humano, reseñas reales. El marcado viene después, y lleva diez minutos.

La prueba que decide: tome una de sus declaraciones estructuradas y busque, en la propia página, lo que la sostiene. Si no lo encuentra, un motor tampoco — y una visitante menos aún.

Para seguir: el enfoque SEO nativo para WordPress, el marcado Schema en JSON-LD y qué cambia la IA en la creación de contenido. Nuestras extensiones premium están disponibles con reembolso íntegro en 14 días : ver el catálogo.