Schema markup: datos estructurados sin spam

Un bloque de JSON-LD válido puede superar la Prueba de resultados enriquecidos y aun así no producir ningún resultado enriquecido. No es un fallo de las pruebas. Los datos estructurados describen el contenido en un formato legible por máquinas; no sustituyen al contenido, no garantizan una función de búsqueda ni actúan como un interruptor de posicionamiento.

El error habitual es empezar por «¿qué tipo de schema debería añadir este sitio?». Una pregunta de partida mejor es: ¿qué entidad describe principalmente esta página?, ¿qué datos pueden ver realmente los visitantes? y ¿qué presentación admite actualmente Google para ese contenido?

Datos estructurados, Schema.org y schema markup

Los datos estructurados son información organizada en un formato legible por máquinas. Schema.org ofrece un vocabulario de tipos de entidades y propiedades. El schema markup es la implementación de ese vocabulario en una página mediante JSON-LD, Microdata o RDFa.

Google Search admite los tres formatos para muchas funciones y suele recomendar JSON-LD porque está separado del HTML de presentación y es más fácil de mantener. El formato no puede rescatar unos datos inexactos. Un Product en JSON-LD perfectamente formado que declare un precio ausente de la página sigue incumpliendo las expectativas de coherencia.

¿Mejora el schema el posicionamiento?

El schema no debería venderse como un factor directo de posicionamiento. Los datos estructurados pueden ayudar a los sistemas a entender una página y hacerla apta para ciertos resultados enriquecidos. Una presentación más destacada puede influir en el porcentaje de clics en algunas situaciones, pero Google no garantiza que se muestre ni siquiera cuando el marcado es correcto.

Los resultados también dependen de:

• Si la página puede rastrearse e indexarse.
• Si el contenido cumple las políticas de Search y las específicas de cada función.
• Si los datos son precisos, completos, actuales y visibles.
• La consulta, el dispositivo, la ubicación y la elección de presentación de Google.
• Si la función sigue admitida en la documentación vigente.

La disponibilidad de los resultados enriquecidos cambia. Consulta la Search Gallery oficial en lugar de fiarte de un artículo antiguo o de la lista de tipos de un plugin.

Elige un tipo a partir del contenido principal de la página

No marques todas las páginas con todos los tipos que parezcan remotamente relacionados. Identifica la entidad principal:

• Un artículo editorial: Article, BlogPosting o un subtipo adecuado.
• Una página de producto que se puede comprar: Product con oferta, precio y disponibilidad reales.
• La ubicación física de un negocio: LocalBusiness o un subtipo preciso.
• Una receta: Recipe.
• Una página centrada en un vídeo: VideoObject.
• Un perfil de organización: Organization.
• Una ruta jerárquica: BreadcrumbList.

Una categoría que lista productos no es automáticamente un único Product. Una guía de compra de portátiles no debería identificarse como producto solo porque trate varios modelos. El tipo debe representar lo que la página ofrece realmente.

Empieza por los datos de origen, no por una cadena JSON

El schema mantenible se genera a partir de las mismas fuentes que renderizan la página visible:

Si una plantilla muestra el precio de la base de datos mientras el JSON-LD almacena una cifra introducida a mano en el CMS, divergirán durante la primera promoción. Los datos estructurados deben ser otra representación de la misma verdad y no un segundo repositorio de contenido.

Un ejemplo mínimo de BlogPosting

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/image-seo#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/image-seo"
  },
  "headline": "Image SEO and alt text",
  "image": [
    "https://example.com/images/image-seo-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/alex#person",
    "name": "Alex Nguyen",
    "url": "https://example.com/authors/alex"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

Esto solo ilustra la estructura. Durante la implementación, verifica las propiedades obligatorias y recomendadas en la documentación vigente de Article. No copies nunca a producción las fechas, las URL ni los autores de ejemplo.

@id conecta entidades estables

Un @id no tiene por qué ser una página independiente que abra un visitante. Es un identificador estable dentro del grafo, normalmente una URL absoluta con un fragmento:

• https://example.com/#organization
• https://example.com/#website
• https://example.com/authors/alex#person
• https://example.com/products/a#product

Cuando el publisher de un artículo y la Organization de todo el sitio hacen referencia al mismo @id, los sistemas pueden tratarlos como una sola entidad en lugar de objetos sin relación con nombres coincidentes.

Los identificadores deben permanecer estables entre renderizados. No generes un UUID aleatorio en cada solicitud. No uses un mismo @id para entidades diferentes, como la organización y su sitio web.

Varios elementos en una misma página

Una página puede contener varios elementos de datos estructurados válidos:

• WebPage describe la página.
• BlogPosting describe el artículo.
• BreadcrumbList describe su ruta.
• Organization o Person se referencia como publisher o autor.
• VideoObject describe un vídeo principal incrustado.

Los objetos pueden ser independientes o conectarse en @graph. Importan más las relaciones precisas y la ausencia de contradicciones que la disposición. Cuando un vídeo es solo un anuncio sin relación, añadir VideoObject para buscar una función de vídeo tergiversa la página.

No hace falta repetir un objeto Organization grande dentro de cada nodo. Define una entidad canónica y referencia su @id para que el grafo sea claro.

Propiedades required y recommended

La documentación de cada función separa las propiedades required de las recommended. Si faltan datos required, el elemento no es apto. Los campos recommended pueden mejorar lo completo del resultado, pero solo cuando existan datos genuinos.

Un principio sólido es menos propiedades, pero precisas y completas. No añadas:

• aggregateRating sin valoraciones reales.
• Un priceValidUntil inventado para eliminar un warning.
• «Admin» como autor cuando no existe un perfil ni responsabilidad editorial.
• Un logotipo genérico como imagen de un contenido sin relación.
• Enlaces sameAs a perfiles que la entidad no posee.

Un warning no es una orden de inventar información. Indica que falta una propiedad recomendada; el equipo de producto debe decidir si existe una fuente fiable.

El contenido marcado debe ser visible y coherente

Google exige que los datos estructurados representen el contenido principal y prohíbe el marcado de información oculta a los lectores. Ejemplos de riesgo:

• El JSON-LD dice $99 mientras la página dice «contáctanos».
• El schema indica InStock mientras la compra está desactivada.
• El marcado declara cinco reseñas de cinco estrellas que no se muestran.
• Las respuestas de FAQ existen solo en el JSON-LD.
• Una oferta de empleo caducada conserva un validThrough futuro.

«Visible» no significa que cada propiedad técnica deba convertirse en texto en bruto de la página. Las URL, los identificadores y las relaciones del grafo pueden seguir siendo metadatos. Las afirmaciones de cara al usuario, como el precio, la valoración, los detalles del evento, las preguntas y el autor, deben corresponder con la experiencia.

El schema de Product expone enseguida los problemas de datos

El precio y el inventario cambian con frecuencia. El marcado de Product debería crearse en la misma solicitud o canalización que la interfaz. Estandariza:

• La moneda con el código ISO adecuado.
• Los precios numéricos sin símbolos de moneda en los campos de datos.
• La disponibilidad con la URL correcta de schema.org.
• Las ofertas asociadas a la variante correcta.
• Los canonical de las variantes y los ID de producto coherentes.
• Las valoraciones agregadas solo a partir de reseñas legítimas de ese producto.

En los productos con variantes, lee la documentación vigente de variantes de producto en lugar de combinar a voluntad el color, el precio y el SKU en un solo objeto. Si una página no vende el artículo ni tiene una oferta genuina, no crees una oferta falsa para que desaparezcan los errores.

LocalBusiness no puede fabricar ubicaciones

Cada ubicación necesita un nombre, una dirección, un teléfono, un horario, una zona de servicio y una URL reales. Su página de destino debe aportar un valor correspondiente. Crear 200 páginas de ciudades casi idénticas y añadir LocalBusiness no crea 200 oficinas.

Los datos del schema deben coincidir con las páginas de contacto, los perfiles de empresa y los datos internos gestionados. Cuando cambie el horario en un festivo, actualiza la interfaz y el JSON-LD desde la misma fuente.

Las reseñas y las valoraciones son áreas de alto riesgo de spam

No marques:

• Reseñas escritas por la propia empresa sobre sí misma.
• Valoraciones copiadas de otro producto.
• Puntuaciones agregadas sin reseñas de origen.
• Testimonios de toda la empresa como valoraciones de cada servicio.
• Datos ocultos presentes solo en scripts.

Infringir las directrices de calidad puede eliminar la posibilidad de resultados enriquecidos y dar lugar a una acción manual por datos estructurados. Eso no borra necesariamente todo el posicionamiento web, pero el riesgo no compensa una fila de estrellas decorativas.

El schema FAQ no es una opción por defecto en todos los artículos

Las FAQ visibles pueden seguir siendo útiles para los lectores, pero el marcado no debería activarse solo porque un plugin ofrezca una casilla. La elegibilidad y la disponibilidad pueden cambiar según la época, el sector y la política. Antes de un despliegue amplio:

1. Confirma que el tipo sigue en la Search Gallery y se aplica al sitio.
2. Lee las directrices completas específicas de la función.
3. Asegúrate de que cada pregunta y respuesta aparezca en la página.
4. Evita repetir las mismas FAQ en miles de URL.
5. Mide los resultados en lugar de tratar «valid» como un éxito.

El schema no debería dictar la estructura editorial. Escribe una FAQ cuando los lectores la necesiten y después determina si encaja algún marcado admitido.

Prueba en tres capas

Capa 1: JSON y sintaxis del schema

Un analizador debe poder leer el JSON-LD: las comas, las llaves, los escapes y los tipos de datos deben ser correctos. Una comilla sin escapar en el nombre de un producto puede invalidar todo el bloque.

Capa 2: Prueba de resultados enriquecidos

Esta herramienta comprueba los tipos admitidos por Google e informa de errores y warnings. Resuelve los errores; evalúa los warnings según los datos reales disponibles. «Valid» significa técnicamente apto en el momento de la prueba, no que se vaya a mostrar con seguridad.

Capa 3: la página en producción y Search Console

Inspecciona la URL desplegada con la inspección de URL, revisa el HTML real y monitoriza los informes de resultados enriquecidos. Una prueba en staging no puede exponer todos los fallos de caché, locale, feature flags, consentimiento o datos reales de productos.

Ejecuta el SEO Checker para tomar muestras de las señales de la página y una auditoría SEO gratuita para encontrar patrones anómalos de metadatos o canonical antes de culpar al schema.

Prueba datos incompletos y hostiles

Una plantilla suele verse perfecta con un producto de muestra completo y falla en los extremos:

• Sin imagen.
• Precio cero o no publicado.
• Dos monedas.
• Nombres con comillas y saltos de línea.
• Autor ausente.
• Fecha de modificación anterior a la de publicación tras una migración.
• Número de reseñas igual a cero.
• Producto retirado.
• Una página en inglés que recibe datos de organización en vietnamita no deseados.

Crea fixtures para estos casos. Comprueba que el JSON se analiza, que las URL absolutas usan la locale correcta, que las propiedades required aparecen solo cuando procede y que se omite un objeto cuando faltan datos esenciales.

Fallos de implementación habituales

Dos plugins generan la misma entidad

El tema emite Article, un plugin de SEO emite BlogPosting y un plugin de reseñas crea otro Product con un ID distinto. El resultado contiene autores, imágenes o valoraciones contradictorios. Haz un inventario de todos los scripts application/ld+json y asigna un único propietario a cada entidad.

El schema contiene URL de staging

Las variables de entorno o las cachés pueden hacer que el @id, la imagen y las URL canonical apunten a un dominio de pruebas. Busca en el HTML de producción cada hostname inesperado.

Locales mezcladas

Una página en inglés puede tener un headline en inglés pero migas de pan y nombres de organización en vietnamita. Define qué campos son compartidos y cuáles se localizan; verifica inLanguage cuando se use.

JavaScript inyecta el marcado demasiado tarde

Google puede renderizar JavaScript, pero depender de una solicitud del cliente que falla o se bloquea hace los datos menos estables. Cuando el servidor ya posee los datos, renderizar el JSON-LD en el HTML inicial suele ser más sencillo y fiable.

Usar schema para disfrazar un contenido débil

Un marcado detallado no puede compensar una página de producto vacía ni un artículo copiado. Los datos estructurados describen el valor; no crean un valor que la página no tiene.

Monitoriza tras el despliegue

Trata el schema como un contrato de lanzamiento:

• Pruebas unitarias de los generadores con fixtures.
• Valida o haz snapshots de las plantillas principales.
• Rastrea staging y producción para contar elementos y errores.
• Alerta cuando la cobertura del marcado caiga bruscamente.
• Monitoriza los informes de mejoras y las acciones manuales.
• Registra las fechas de lanzamiento para comparar CTR, impresiones y errores.

Cuando Google cambia la compatibilidad de un tipo de resultado enriquecido, no hace falta entrar en pánico y eliminar todas las declaraciones útiles de schema.org. Distingue el marcado de entidades que aclara el contenido del que se mantiene únicamente para una función de búsqueda. Compara el coste de mantenimiento con el beneficio real.

Lista de verificación previa a la publicación

• ¿El tipo representa el contenido principal?
• ¿La función está admitida en la documentación vigente de Google?
• ¿Las propiedades required están completas y proceden de datos reales?
• ¿Las afirmaciones importantes son visibles para los visitantes?
• ¿Las URL, las imágenes y los valores de @id son absolutos, rastreables y del dominio correcto?
• ¿El canonical y mainEntityOfPage identifican la misma URL estratégica?
• ¿Las fechas, los precios, la disponibilidad y las valoraciones se actualizan automáticamente?
• ¿Crea otro plugin un objeto duplicado?
• ¿Se supera la Prueba de resultados enriquecidos?
• ¿Pueden unos datos ausentes invalidar el JSON?
• ¿Se ha comprobado la producción y Search Console?

Conclusión

Un buen schema markup es una descripción honesta y estructurada del contenido visible. Empieza por el modelo de datos y la propiedad de las fuentes y no por un fragmento de JSON-LD copiado. Elige un tipo preciso, usa identificadores estables, aporta propiedades genuinas y completas, prueba los casos límite y monitoriza tras el lanzamiento.

No fabriques valoraciones para eliminar warnings, no marques afirmaciones ocultas ni prometas resultados enriquecidos como una certeza. Cuando la interfaz y los datos estructurados se generan desde la misma verdad, el schema se convierte en ingeniería mantenible y no en una capa decorativa frágil.

Referencias: introducción de Google Search Central a los datos estructurados, directrices generales de datos estructurados y documentación de Schema.org.