Datos estructurados: cuáles necesita de verdad la web de una empresa
Los datos estructurados no son un factor de posicionamiento. Son una traducción: le dicen a las máquinas qué significa un apartado de texto en lugar de dejar que lo adivinen. Y eso decide cada vez más si una página aparece siquiera en las respuestas.
Lo esencial
- Cuatro tipos bastan para casi cualquier web corporativa: Organization, WebPage o Article, BreadcrumbList y FAQPage.
- Se entregan como JSON-LD en el
<head>, no como marcado dentro del texto corrido. - El error más frecuente es silencioso y caro: datos en el marcado que no aparecen en la propia página.
- Tres tipos muy discutidos se los puede ahorrar una empresa de servicios: solo sirven con una oferta adecuada o con valoraciones reales.
Una máquina que lee una página ve al principio solo texto. Que «Emma Woelk» es una persona, «TEISENDA GmbH» una empresa y «22 de agosto de 2026» una fecha de publicación tiene que adivinarlo, o bien está dicho expresamente.
Los datos estructurados son ese decir expreso. No mejoran ninguna posición. Deciden si una página entra siquiera en consideración para presentaciones ampliadas y para respuestas generadas.
Los cuatro que bastan
1. Organization: una vez, en la página de inicio
Quiénes sois: nombre, dirección, logotipo, año de fundación, perfiles en otras redes. Es la entrada que hace posible que aparezca un logotipo junto al resultado de búsqueda, y el motivo más frecuente de que falte es sencillamente la ausencia de esta entrada.
Importante: el logotipo debe existir como imagen de mapa de bits. Un SVG no se evalúa en este punto.
2. WebPage o Article: en cada página
Qué es esta página: título, descripción, idioma, fecha de publicación y de última revisión. En los artículos, además Article o BlogPosting con el autor como entrada Person propia, con su papel y no solo con el nombre.
Importante: la fecha de modificación tiene que ser cierta. Una fecha que se fija de nuevo en cada carga de la página es una señal que se invalida a sí misma.
3. BreadcrumbList: en todas las subpáginas
Dónde está esta página dentro de la estructura. Visible como ruta en la parte superior y legible por máquina en la cabecera. Ambas cosas van juntas: una ruta en los datos que no existe en la página es un dato falso.
4. FAQPage: donde hay preguntas reales
El apartado de preguntas al final de un artículo. Para los motores de respuesta es el tipo más valioso de todos, porque entrega la pregunta y la respuesta ya como pareja, justo la forma en la que se cita.
Importante: solo para preguntas realmente visibles en la página. Las preguntas inventadas que solo están en los datos son una infracción de las directrices.
Tres que se pueden ahorrar
Product y Offer. Para servicios con oferta a consultar no aportan nada: sin precio ni disponibilidad no se muestran de todos modos. Tienen sentido solo con una tienda real.
AggregateRating. Las estrellas en el resultado de búsqueda son tentadoras y están sujetas a condiciones estrictas: las valoraciones deben ser reales, verificables y visibles en la página. Las valoraciones que uno se pone a sí mismo son una infracción de directrices con riesgo real.
HowTo. Se ha reducido mucho en la presentación y ya no compensa el trabajo de mantenimiento para la mayoría de las webs corporativas.
¿Sabías que…?
Los datos estructurados no son un factor de posicionamiento; Google lo ha aclarado varias veces. Deciden sobre la presentación, no sobre la posición.
Para los motores de respuesta el caso es algo distinto. Un modelo que debe construir una respuesta a partir de una página usa preferentemente lo que está marcado de forma inequívoca: parejas de pregunta y respuesta, autor con su papel, fecha de la última revisión. Así no tiene que adivinar qué va con qué. La utilidad está, pues, menos en el posicionamiento que en la capacidad de ser citado.
Cómo se incorporan
Tres reglas que evitan la mayoría de los problemas.
- JSON-LD, en el
<head>. No como atributos en el texto corrido. El JSON-LD se mantiene separado del diseño y no se pierde en los cambios de maquetación. - Un bloque por página, no cinco. Varias entradas van en un
@graphy se enlazan entre sí mediante@id. Así el artículo remite a la misma organización que está en la página de inicio en lugar de repetirla. - Generarlos desde la misma fuente que el contenido visible. Si el título, la fecha y el autor vienen de los mismos campos que la página, no pueden separarse. Es la prevención más eficaz que existe.
El error más caro es el más silencioso: los datos estructurados dicen algo que no está en la página. Una fecha de modificación de ayer en un texto de 2023. Un autor que no aparece en la zona visible. Preguntas en los datos que no existen en la página.
Ninguna herramienta de comprobación lo detecta: los datos son formalmente válidos. Se detecta en una revisión manual, y entonces la consecuencia no afecta solo al marcado implicado. Por eso la regla «generarlos desde la misma fuente» importa más que cualquier exhaustividad.
Comprobar, en este orden
| Paso | Con qué | Qué se ve |
|---|---|---|
| 1. Sintaxis | validador de marcado de Schema | si el JSON es válido y el tipo correcto |
| 2. Presentabilidad | prueba de resultados enriquecidos | si sería posible una presentación ampliada |
| 3. Realidad | Search Console, sección de mejoras | qué se ha reconocido de verdad en todas las páginas |
| 4. Coincidencia | leerlo uno mismo | si cada dato figura también visible en la página |
El paso cuatro es el único que ninguna herramienta asume, y el único en el que se detectan los errores serios.
Revisa los datos estructurados de esta página en cuanto a exhaustividad y a coincidencia con el contenido visible. Contenido visible de la página: [insertar el texto de la página] JSON-LD de la página: [insertar el bloque] Tareas: 1. Nombra cada dato del JSON-LD que no aparezca en el contenido visible. Es el punto más importante: sé minucioso aquí. 2. Nombra cada dato visible que debería marcarse pero falta (autor con su papel, fecha de modificación, preguntas, ruta). 3. Comprueba si los cuatro tipos básicos están cubiertos con sentido: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Nombra los tipos del bloque que no aportan nada a una empresa de servicios sin tienda y sin valoraciones verificables. 5. Señala cualquier infracción de las directrices, en especial valoraciones puestas por uno mismo y preguntas que no existen en la página. Devuelve al final el JSON-LD corregido completo. No inventes valores: marca lo que falte como [por completar].
Conclusión
Los datos estructurados se sobrevaloran rápido y se hacen mal igual de rápido. Cuatro tipos cubren la necesidad de una web corporativa, y su utilidad está menos en la posición que en poder ser citado.
La regla que lo sostiene todo: no marcar nada que no esté en la página. Quien genera los datos desde la misma fuente que el contenido visible ha resuelto ese problema de forma estructural, y puede ahorrarse en buena medida los controles posteriores.
Preguntas frecuentes
¿Qué datos estructurados necesita la web de una empresa?
Bastan cuatro tipos: Organization una vez en la página de inicio, WebPage o Article en cada página, BreadcrumbList en todas las subpáginas y FAQPage allí donde haya preguntas reales y visibles. Product, AggregateRating y HowTo no suelen compensar en empresas de servicios.
¿Mejoran los datos estructurados el posicionamiento?
No. No son un factor de posicionamiento, sino que deciden la presentación: por ejemplo si pueden aparecer un logotipo, una ruta o preguntas desplegables en el resultado. Para los motores de respuesta aumentan la capacidad de ser citado, porque las parejas de pregunta y respuesta, el autor y la fecha están marcados de forma inequívoca en lugar de tener que adivinarse.
¿Por qué no muestra Google nuestro logotipo?
El motivo más frecuente es una entrada Organization ausente o incompleta en la página de inicio. El segundo motivo más frecuente: el logotipo depositado existe solo como SVG, y en este punto se necesita una imagen de mapa de bits. Incluso con un marcado correcto no hay derecho a que se muestre.
¿Cuál es el error más frecuente con los datos estructurados?
Datos que están en el marcado pero no en el contenido visible: una fecha de modificación falsa, un autor no mencionado, preguntas inventadas. Las herramientas de comprobación no lo señalan, porque los datos son formalmente válidos. Se evita generando el marcado desde la misma fuente que el texto visible.
¿JSON-LD o microdatos?
JSON-LD en el <head>. Es la forma recomendada por Google, se mantiene separada del diseño y no se pierde con los cambios de maquetación. Los microdatos reparten el marcado por el texto corrido y se rompen en cada remodelación de la página.
Marketing que se configura solo
La beta del Studio Engine está abierta. Reserva tu plaza y participa desde el principio.
Unirse a la beta →