2026-01-14 · Redacción Baduno · 8 blog.readMin · Blog & Conocimiento
Datos estructurados: Schema.org explicado de forma comprensible
La información adicional legible por máquina convierte los resultados de búsqueda en resultados enriquecidos con valoraciones, preguntas frecuentes y datos de empresa. Así funciona.
Qué son los datos estructurados
Bloques JSON invisibles en el código fuente describen lo que hay en la página: esto es una empresa con esta dirección, esto es un artículo con esta fecha, esto es un FAQ con estas preguntas. Los buscadores no tienen que adivinar: leen.
Qué beneficios aporta
Habilitación para representaciones avanzadas (extractos de FAQ, migas de pan, panel de organización), mejor comprensión de las relaciones y entradas más limpias en el grafo de conocimiento. No es un turbo de ranking, pero más superficie y confianza en el resultado de búsqueda.
Los tipos más importantes para empresas
Organization con datos de registro, WebSite, Service o Product con Offer, Article para artículos especializados, FAQPage y BreadcrumbList. En varios idiomas: cada versión lingüística lleva su propia marca traducida.
No olvides validar
El Rich-Results-Test muestra lo que Google lee, el Schema-Validator comprueba la sintaxis. Un marcado incorrecto es peor que ninguno: cuesta confianza y, en el peor caso, la representación avanzada.
Datos estructurados y hreflang: Combinación perfecta para sitios multilingües
Una fuente frecuente de errores en sitios web multilingües es el uso inconsistente de datos estructurados y etiquetas hreflang. Mientras que hreflang indica a los motores de búsqueda las alternativas de idioma y región de una página, los datos estructurados revelan el tipo de contenido. Ambos son independientes pero se complementan: una página de producto en alemán debe incluir una etiqueta hreflang que apunte a la variante en inglés y, en el bloque de datos estructurados, marcar el mismo ID de producto con diferentes ofertas e idiomas. Importante: cada versión de idioma debe tener su propio bloque JSON-LD con valores adecuados; de lo contrario, se generan contradicciones. La prueba de resultados enriquecidos de Google a menudo muestra errores cuando, por ejemplo, la organización en la versión alemana contiene una dirección en inglés. Por lo tanto, revise siempre ambas marcas en paralelo después de cada implementación de idioma.
Mantenimiento y actualización: ¿Quién gestiona los datos?
Los datos estructurados no son un proyecto único. Si cambian los precios, horarios de apertura o detalles del producto, los bloques JSON-LD deben actualizarse. Idealmente, el sistema de gestión de contenidos debe encargarse del llenado dinámico. Si falta esta automatización, se necesita un responsable claro en el equipo, como el editor para datos de artículos y preguntas frecuentes, y el desarrollador para datos organizativos. Evite los silos de datos: un número de teléfono desactualizado en el bloque Organization perjudica la confianza. Planifique revisiones trimestrales de todos los datos estructurados, al menos antes de cada relanzamiento importante. Es útil un panel centralizado que muestre todas las páginas marcadas y su estado de validación.
Creación y revisión de datos estructurados asistida por IA
Las herramientas modernas de IA pueden generar automáticamente JSON-LD a partir de texto no estructurado, por ejemplo, para páginas de preguntas frecuentes o artículos. Esto acelera el trabajo, pero conlleva riesgos: la IA a menudo pasa por alto matices contextuales (como un precio incorrecto o una fecha desactualizada). Por lo tanto, la revisión por parte de un editor nativo es indispensable. Utilice la IA para el borrador inicial y luego haga que una persona valide los valores. También en sitios multilingües, la IA ayuda con las traducciones de datos estructurados, pero las etiquetas hreflang y los ID específicos de idioma deben establecerse manualmente. Un enfoque probado: la IA crea el bloque estándar en inglés, un editor local corrige y completa los campos específicos del país.
La información adicional legible por máquina convierte los resultados de búsqueda en resultados enriquecidos con valoraciones, preguntas frecuentes y datos de empresa. Así funciona.
Marcar contenido dinámico: FAQs, reseñas y productos
Con frecuencia, los errores ocurren en contenidos dinámicos. Las páginas de FAQ deben tener una entrada JSON-LD por cada pregunta, no toda la lista como un único objeto Question. En las reseñas, la escala de valoración debe indicarse correctamente (por ejemplo, bestRating y worstRating). Las páginas de producto con variantes requieren bloques AggregateOffer con toda la información de precio y disponibilidad. Utilice plantillas en el CMS que generen automáticamente los tipos correctos. Pruebe cada página dinámica individualmente en la prueba de resultados enriquecidos, ya que los errores solo se vuelven visibles con valores concretos. Un error común: el uso de 'Review' en lugar de 'AggregateRating' para valoraciones medias.
Combinación de varios tipos de Schema.org en una página
En una sola página puede utilizar varios tipos de Schema.org en paralelo, siempre que describan diferentes aspectos del contenido. Una página de producto puede incluir simultáneamente un bloque Product (con precio, disponibilidad), un bloque Organization (para el fabricante) y un bloque Review (para valoraciones). Es importante que cada tipo esté en un script JSON-LD propio o vinculado de manera consistente mediante @id. Ejemplo: el bloque Product referencia al bloque Organization con "brand": {"@id": "#organisation"}. Evite información contradictoria, como direcciones diferentes en los bloques Organization y LocalBusiness. Cada tipo debe marcarse correctamente y según el idioma: una página en francés debe contener valores en francés en todos los bloques. Utilice el CMS para gestionar los tipos de forma modular, de modo que no tenga que ajustar cada bloque manualmente. Verifique en la prueba de Rich Results que todos los bloques sean aceptados; algunas pruebas solo muestran el primer bloque. Una combinación limpia de varios tipos aumenta las posibilidades de obtener resultados enriquecidos como carruseles, cajas de producto o panel de organización.
Trabajar con @id y referencias para datos vinculados
Schema.org permite referenciar objetos mediante @id para evitar datos redundantes. En lugar de repetir la organización completa en cada página, defina un bloque Organization central con un @id único (p. ej., "https://ejemplo.de/#empresa") y refiérase a él en otros bloques mediante "@id": "https://ejemplo.de/#empresa". Esto es especialmente útil en sitios multilingües: la organización sigue siendo la misma, solo varían campos específicos del idioma como "name" o "description". Asegúrese de que el @id sea coherente en todas las versiones de idioma, es decir, la misma URI para alemán, inglés, etc. Las referencias también pueden usarse para autores de artículos, marcas de productos o elementos de reseñas. Valide con el Schema Validator que todas las referencias @id sean resolubles. Un error: si el @id referenciado no está definido en el mismo código fuente de la página o en otra página, la validación falla. Por lo tanto, almacene las entidades centrales en un archivo global (p. ej., organisation.json) e intégrelas mediante JavaScript, o use el CMS para una inclusión dinámica. Una estructura limpia de @id facilita a los motores de búsqueda la vinculación de información y mejora la coherencia en el Knowledge Graph.
Marcar correctamente BreadcrumbList: consejos y dificultades
Marcar BreadcrumbList puede parecer sencillo, pero en la práctica suelen aparecer errores que comprometen el éxito de los rich snippets. Una implementación correcta comienza con la comprensión de la jerarquía: cada entrada de la lista necesita un objeto ItemListElement, que a su vez contiene un objeto ListItem. La propiedad position es crucial: numera los elementos de forma ascendente, comenzando con 1 para la página de inicio. Evite omitir la página de inicio; aunque no aparezca en el breadcrumb visible, debe estar presente en los datos estructurados. Un error común es usar URLs absolutas sin considerar la versión de idioma: asegúrese de que la URL en el breadcrumb apunte a la variante de idioma correcta, p. ej., /de/produkte en lugar de /en/products. Además, el nombre de los elementos debe ser específico del idioma: 'Startseite' en alemán, 'Home' en inglés. Utilice el campo name para el texto mostrado y evite abreviaturas que puedan confundir a los motores de búsqueda. Después de la implementación, pruebe cada ruta con la prueba de Rich Results, ya que especialmente en breadcrumbs generados dinámicamente es fácil intercambiar posiciones o crear entradas duplicadas. Tenga en cuenta además que Google muestra un máximo de diez elementos; por lo tanto, una navegación más corta y precisa es preferible a una excesivamente larga.
Objetos anidados y referencias: @id y @context
Los datos estructurados complejos suelen utilizar la vinculación de varios tipos mediante referencias @id. Un ejemplo típico es una página de producto que contiene tanto una oferta (Offer) como una reseña (Review). En lugar de empaquetar todos los datos en un bloque monolítico, es más limpio definir bloques separados con valores @id únicos y luego referenciarlos. El valor @id debe ser único dentro de la página y de todo el dominio; idealmente, utilice la URL absoluta del objeto con un fragmento como #product-1. Evite IDs genéricos como #producto, ya que pueden causar conflictos en varias páginas. Otro aspecto importante es @context: por defecto se utiliza el vocabulario de Schema.org, pero para extensiones propietarias se puede especificar un contexto propio. Asegúrese de que extensiones verificadas como health-lifesci o bib no terminen accidentalmente en páginas comerciales. En sitios multilingües, las referencias @id deben ser específicas del idioma: la página de producto en alemán referencia el ID de oferta alemán, no el inglés. Una técnica útil es el uso de @reverse para relaciones inversas, por ejemplo, cuando un producto referencia a una organización, pero la organización no tiene una lista directa de todos sus productos. Pruebe estas concatenaciones en el validador de esquemas, ya que un simple error de dos puntos puede provocar un fallo de validación. Planifique tiempo suficiente para la depuración de objetos referenciados: son una fuente frecuente de errores en implementaciones extensas.
blog.faqT
¿Puedo añadir datos estructurados posteriormente en páginas antiguas?
Sí, los datos estructurados pueden añadirse en cualquier momento. Asegúrese de que toda la información esté actualizada. Utilice el Rich-Results-Test de Google para verificar la implementación correcta. En el caso de muchas páginas, se recomienda un enfoque gradual según el tipo de contenido.
¿Con qué frecuencia deben actualizarse los datos estructurados?
Siempre que cambien los datos subyacentes (precios, horarios, detalles del producto). Planifique al menos una revisión general trimestral. Los sistemas dinámicos pueden rellenar datos automáticamente, lo que reduce el esfuerzo de actualización y las fuentes de error.
