Datos estructurados: para qué los usan realmente los buscadores

Compra elegibilidad, y la elegibilidad no es una promesa

El modelo mental que más decepciones causa es aquel en el que el marcado es una palanca: añade schema, consigue un empujón. No es eso. Los datos estructurados son una capa de traducción. Tu página dice, en prosa pensada para una persona, que este artículo lo escribió Camille Laurent el 18 de agosto y se actualizó en septiembre. El marcado dice lo mismo en una forma que un analizador puede leer sin adivinar. Nada nuevo entra en la página; la máquina simplemente deja de tener que inferir.

Lo que compra esa traducción es algo concreto y acotado: la elegibilidad para un resultado enriquecido. Las propias directrices de Google lo ponen en un aviso destacado: no garantiza que tus datos estructurados aparezcan en los resultados, aunque la página esté correctamente marcada. Que la función se dibuje depende de la consulta, del dispositivo, de la maquetación de esa página de resultados concreta y de si Google confía lo bastante en tu sitio como para renderizarla. Un marcado correcto te lleva de inelegible a elegible. Nada en él te sube una posición.

La confirmación más nítida de que marcado y posicionamiento son sistemas separados viene del lado de la penalización. Google describe una acción manual por datos estructurados como algo que hace que una página pierda la elegibilidad para aparecer como resultado enriquecido, y precisa que no afecta a cómo posiciona esa página en la búsqueda web. Dos mandos independientes. Si el marcado pudiera empujar posiciones hacia arriba, abusar de él las empujaría hacia abajo — y la penalización documentada no hace nada de eso.

JSON-LD ganó, y la razón es el mantenimiento

Hay tres sintaxis para meter schema.org en una página. Microdata y RDFa se basan en atributos: espolvoreas itemscope, itemprop y typeof sobre los elementos HTML que ya contienen los valores, de modo que el marcado vive dentro del marcado. JSON-LD es un bloque autónomo, una etiqueta script de tipo application/ld+json con un objeto JSON corriente, normalmente colocada en el head o al final del body. Las tres se analizan. Google recomienda JSON-LD para datos estructurados si la configuración del sitio lo permite, y lo llama la solución más fácil de implementar y mantener a escala.

La razón no es la elegancia, es el acoplamiento. El marcado por atributos está soldado al DOM: cambia la plantilla, mueve el precio a otro componente, deja que un diseñador cambie un span por un div, y el itemprop se va con él o desaparece en silencio. JSON-LD está totalmente desacoplado de la presentación, lo que significa que sobrevive a los rediseños, puede ensamblarse en el servidor a partir de los mismos datos que renderizan la página, y se revisa en una pull request como un solo objeto legible en lugar de como quince atributos dispersos. Ese desacoplamiento es también su peligro, y de eso trata exactamente la sección siguiente a la próxima.

Qué tipos siguen produciendo algo que se pueda ver

Aquí es donde la mayoría de los consejos publicados se ha estropeado, así que comprueba la fecha de todo lo que leas, esto incluido. Google mantiene una galería de los tipos de datos estructurados que admite, y esa galería es la única autoridad fiable sobre el asunto. Hoy lista Article, Breadcrumb, Product, Event, Recipe, Video, Job posting, Local business, Organization, Review snippet, Q&A, Dataset, Software app, Vacation rental, Discussion forum, Profile page y unos cuantos más. Dos nombres que estaban en todas las listas de SEO no aparecen.

HowTo ya no está. Google retiró los resultados enriquecidos HowTo durante 2023, primero de móvil y luego de escritorio, y eliminó la documentación. FAQPage duró más pero también se fue: desde agosto de 2023 quedó restringido a sitios gubernamentales y de salud reconocidos y con autoridad, y el 7 de mayo de 2026 dejó de aparecer del todo. La documentación de FAQPage se eliminó el 15 de junio de 2026, y los informes asociados — el filtro de apariencia en los resultados, el informe de resultados enriquecidos, el soporte en la prueba de resultados enriquecidos — fueron detrás. Si una lista te dice que añadas schema de FAQ para ganar espacio en el resultado, esa lista lleva al menos un año de retraso, probablemente tres.

Eso no hace inútil el marcado, ni significa que debas arrancarlo. La postura de Google sobre las funciones retiradas es que no hace falta eliminarlas, porque otros buscadores y servicios pueden seguir usándolas. Schema.org es un vocabulario compartido, no un producto de Google: asistentes, agregadores, otros buscadores y un número creciente de cadenas de recuperación de modelos de lenguaje analizan el mismo JSON. La formulación honesta es que FAQPage y HowTo han pasado de un beneficio visible y medible a uno especulativo — lo que sí cambia cuánto tiempo de ingeniería merecen.

Obligatorio frente a recomendado, para los tres que aún rinden

Article es el caso sorprendente: no tiene ninguna propiedad obligatoria. Google recomienda añadir las propiedades que apliquen a tu contenido, y cita author, datePublished, dateModified, headline e image como recomendadas. Eso no es permiso para saltárselas. Una propiedad recomendada es aquella cuya ausencia no invalida el objeto pero sí reduce lo que un consumidor puede hacer con él — un Article sin author es un Article que no puede alimentar ninguna firma aguas abajo. Aporta las que puedas aportar con exactitud, y el consejo de Google es preferir menos propiedades recomendadas, completas y exactas, a todas las posibles mal rellenadas.

BreadcrumbList es el más estricto de los tres y el más barato de acertar. Exige itemListElement, un array ordenado de objetos ListItem, y cada ListItem exige position y name. La propiedad item — la URL a la que apunta esa miga — es obligatoria en todas las entradas salvo la última, donde Google recurre a la URL de la página actual. La lista debe contener al menos dos ListItem para mostrarse; una miga de un solo elemento no es una ruta. Es el tipo con mejor relación entre efecto visible y esfuerzo de implementación, porque sustituye una URL fea por una ruta legible, y porque en un sitio con estructura de URL disciplinada la ruta se genera desde el propio path.

Product queda en medio. Para un fragmento de producto las propiedades obligatorias son name más al menos uno de review, aggregateRating u offers — basta con uno de los tres. En la práctica es offers el que se gana el sitio, porque un precio y un estado de disponibilidad dentro del resultado responden a las dos preguntas que tiene un comprador antes de hacer clic. Fíjate en el aviso que la prueba de resultados enriquecidos puede lanzar si aportas offers sin ninguna valoración: es un aviso, no un error, e inventarse una valoración para callarlo es exactamente el comportamiento del que trata la sección siguiente.

La regla que lo decide todo: marcar lo que es visible

Las directrices de datos estructurados de Google contienen una instrucción que causa más acciones manuales que todos los errores técnicos juntos: no marques contenido que no sea visible para los lectores de la página. Suena obvio hasta que reparas en lo fácil que JSON-LD hace incumplirlo. El bloque vive aparte del HTML, lo genera una plantilla, no se renderiza nunca — así que nadie del equipo lo mira jamás junto a la página. Precisamente por eso se desvía.

Los modos de fallo son mundanos, no maliciosos. Una plantilla de producto emite aggregateRating desde un campo de catálogo mientras la página no muestra reseñas porque aún no se ha escrito ninguna. Una página de precios renderiza un precio en el servidor tras una conversión de divisa, pero el JSON-LD se construyó desde el precio base y ahora contradice lo que lee el visitante. Un bloque de artículo lleva un dateModified que el CMS incrementa en cada republicación mientras la página muestra la fecha original. Cada uno de esos casos es marcado que describe algo que el lector no puede verificar, y cada uno es la misma infracción que falsear cinco estrellas a propósito.

El arreglo de ingeniería cabe en un principio: nunca construyas el JSON-LD desde una segunda fuente de verdad. Ensámblalo exactamente a partir de los mismos objetos que renderizan la página visible, en la misma petición, para que un valor no pueda aparecer en uno y no en el otro. Si el precio mostrado viene de una cadena formateada, deriva el precio del marcado del número que hay detrás de esa cadena, no de una consulta aparte. Después añade un test por plantilla que compruebe que cada valor marcado aparece en algún sitio del HTML renderizado. Ese test caza la desviación de plantilla el día en que ocurre, en vez de en un mensaje de Search Console tres meses después.

Probar: tres herramientas, tres preguntas distintas

El validador de schema.org responde a la pregunta del vocabulario: ¿es schema.org válido, existen los tipos, están bien escritas las propiedades, encajan los objetos anidados en sus rangos esperados? No sabe nada de Google. La prueba de resultados enriquecidos responde a la pregunta de elegibilidad para Google en concreto: con este marcado, ¿es la página elegible para una función que Google admite actualmente, y si no, qué propiedad obligatoria falta? Los informes de resultados enriquecidos de Search Console responden a la tercera y más importante: qué está pasando en el sitio en producción, a escala, en todas las URL, después de desplegar la plantilla.

Úsalas en ese orden y párate en la tercera. El consejo de Google es probar durante el desarrollo y luego vigilar la valide tras el despliegue, porque los problemas aparecen después de publicar, por cuestiones de plantillas y de servido que ninguna comprobación previa puede ver. Una página que pasó la prueba de resultados enriquecidos en el portátil de un desarrollador puede fallar en producción porque una capa de caché elimina la etiqueta script, porque un banner de consentimiento retrasa el renderizado más allá del punto en que el rastreador se rindió, o porque una categoría de cuarenta tiene un null en el campo que alimenta name.

Preguntas frecuentes

¿Son los datos estructurados un factor de posicionamiento?

No. El marcado hace que una página sea elegible para resultados enriquecidos; no la sube ni la baja en los resultados web ordinarios. La prueba más nítida es la penalización: Google describe una acción manual por datos estructurados como algo que le cuesta a la página su elegibilidad para aparecer enriquecida, precisando que no afecta a su posición en la búsqueda web. Dos sistemas separados. Cualquier beneficio indirecto viene de un resultado más informativo que atrae más clics, no de que el marcado se puntúe.

¿Debo eliminar el schema de FAQ y HowTo ahora que no producen nada?

No, y Google lo dice de forma explícita para las funciones retiradas: no hace falta eliminarlas, porque otros buscadores y servicios pueden seguir usándolas. Schema.org es un vocabulario compartido que Google no posee. Lo que debe cambiar es tu presupuesto, no tu HTML — deja de construir marcado FAQ nuevo esperando un retorno visible en Google, y deja de reportar sobre una función cuyo informe de Search Console ya no existe. Si el marcado ya lo genera una plantilla cuyo mantenimiento no cuesta nada, dejarlo es la decisión más barata.

Mi marcado es válido y la prueba de resultados enriquecidos pasa, pero no aparece ningún resultado enriquecido. ¿Por qué?

Porque pasar la prueba demuestra elegibilidad, y la elegibilidad no es visualización. Google afirma que no garantiza que los datos estructurados aparezcan aunque la página esté correctamente marcada. La decisión depende de la consulta, del dispositivo, de la maquetación de esa página de resultados concreta y de la confianza de Google en el sitio. No hay palanca que accionar. La respuesta productiva es confirmar que la página está indexada, que el informe de Search Console muestra el elemento como válido en producción y no solo en la herramienta de prueba, y luego esperar — la visualización suele empezar semanas después del primer rastreo del marcado.

¿Puedo poner el JSON-LD en el head, o debe ir en el body?

Ambas funcionan. Google analiza la etiqueta script dondequiera que aparezca en el documento, y no hay diferencia de posicionamiento ni de elegibilidad entre las dos ubicaciones. Lo que importa mucho más es que la etiqueta llegue al rastreador. Si el bloque lo inyecta JavaScript del lado del cliente, depende de que el renderizado se complete, lo que introduce un modo de fallo que el marcado renderizado en servidor no tiene. Emítelo en el servidor si tu stack lo permite, y si tiene que ser en cliente, verifica con la herramienta de inspección de URL que el HTML renderizado que ve Google lo contiene de verdad.

¿Qué le vale exactamente a un sitio una acción manual por datos estructurados?

Marcado que describe algo que el lector no puede ver. Las directrices de Google dicen sin rodeos que no se marque contenido que no sea visible para los lectores de la página, y el contenido marcado oculto figura como razón para que los datos no aparezcan. En la práctica las faltas son: valoraciones de productos sin reseñas en la página, precios que no coinciden con el precio mostrado, tipos que no corresponden al propósito real de la página, y fechas que se inventa el CMS. La consecuencia es la pérdida de elegibilidad para resultados enriquecidos, no una caída de posiciones — pero la elegibilidad era toda la razón para añadir el marcado.

¿Un generador de marcado schema produce algo que pueda desplegar tal cual?

Produce un esqueleto correcto, que es de verdad la mitad tediosa del trabajo — el tipo adecuado, las propiedades obligatorias presentes, el anidamiento válido, el JSON bien formado. Lo que no puede hacer es conocer tu página. Dos cosas siguen siendo tuyas: comprobar que cada valor que pegas es un valor visible en la página renderizada, y conectar el bloque a tus datos para que siga siendo cierto tras el próximo cambio de contenido. Un generador es la herramienta adecuada para una página puntual o una primera plantilla; es la herramienta equivocada para un catálogo de cuarenta mil productos, que necesita generación desde los mismos objetos que renderizan la página.