Datos estructurados: los tipos de Schema que realmente generan resultados

Los datos estructurados cumplen dos funciones esenciales, y la segunda se ha convertido en la más determinante:

Primera función: obtener resultados enriquecidos (rich snippets) en las páginas de búsqueda de Google: valoraciones con estrellas, preguntas frecuentes desplegables, rutas de navegación (breadcrumbs), precios y fechas de eventos. Ocupan mayor espacio visual y elevan el CTR.

Segunda función: proporcionar a los modelos de inteligencia artificial hechos inequívocos y legibles por máquina sobre su empresa. Un modelo que procesa texto en lenguaje natural debe deducir qué servicios presta su empresa y en qué mercados opera. Un modelo que procesa un nodo de tipo Organization o Service no necesita deducir nada: lee aserciones exactas. Cuando un asistente generativo responde con precisión sobre su empresa, esa certidumbre procede frecuentemente de los datos estructurados.

La primera función es ampliamente conocida; la segunda es la razón por la cual implementaciones que hace tres años se consideraban «suficientes» hoy resultan obsoletas.

Utilice exclusivamente JSON-LD

Existen tres formatos de marcado (Microdatos, RDFa y JSON-LD). Emplee siempre JSON-LD.

Es el formato recomendado expresamente por Google, se aloja dentro de una única etiqueta <script> sin fragmentarse por el código HTML y sobrevive a los rediseños visuales de plantillas que suelen invalidar los Microdatos.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme Fabricación",
  "url": "https://example.com/"
}
</script>

Conectar el grafo de entidades mediante @id

Esta es la diferencia técnica entre una implementación que aporta valor real y una que simplemente valida sin errores sintácticos.

La mayoría de sitios publican bloques aislados: una Organization en la portada, un Service en otra página y un BlogPosting en el blog, sin referencias mutuas. Cada bloque valida individualmente, pero no comunican cómo se relacionan entre sí.

Utilice identificadores @id para articular el grafo:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Acme Fabricación",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/es/servicios/mecanizado-cnc/#service",
      "name": "Fresado CNC",
      "provider": { "@id": "https://example.com/#organization" },
      "areaServed": { "@type": "Place", "name": "Unión Europea" }
    }
  ]
}

Ahora el servicio está vinculado explícitamente a una organización concreta con un área de cobertura definida. Un rastreador o modelo puede responder «¿quién ofrece fresado CNC y en qué región opera?» a partir exclusivamente del marcado técnico.

La propiedad @graph permite agrupar todas las entidades en un único bloque estructurado y limpio.

Tipos de Schema prioritarios

Ordenados por impacto en un sitio web corporativo:

Organization (o LocalBusiness para negocios físicos o ProfessionalService para agencias y consultoras). Es el nodo central. Incluya name, url, logo, address, telephone, email, perfiles sociales oficiales en sameAs y areaServed.

WebSite — declarado en la página principal. Añadir potentialAction con SearchAction puede activar la caja de búsqueda directa en Google.

BreadcrumbList — en todas las páginas internas. Sustituye la URL cruda en los resultados de búsqueda por una ruta de navegación legible. Es el resultado enriquecido más sencillo de conseguir y uno de los más omitidos.

Service o Product — en las páginas que describen la oferta comercial. Product con la propiedad offers y un price real permite mostrar precios en los resultados.

FAQPage — en páginas de preguntas frecuentes. Tiene un valor excepcional para la extracción de información por motores de IA, al estructurar directamente pares de pregunta y respuesta.

BlogPosting o Article — en artículos editoriales. Incluya headline, datePublished, dateModified, author, image y wordCount.

El error que provoca penalizaciones manuales

Nunca incorpore aggregateRating en el nodo de su propia Organization utilizando reseñas recopiladas internamente por usted mismo.

Las directrices oficiales de Google sobre datos estructurados son tajantes: las reseñas autocomplacientes (self-serving reviews) sobre la propia organización no son aptas para resultados enriquecidos y constituyen una causa documentada de acción manual algorítmica.

Las valoraciones con estrellas pertenecen a nodos Product, LocalBusiness o servicios específicos, y deben corresponder a reseñas reales y visibles en el propio texto de la página.

Requisitos técnicos indispensables

• El contenido marcado debe ser visible para el usuario: marcar un bloque de preguntas o precios que no se muestran en pantalla constituye una infracción de políticas.
• Las propiedades obligatorias son estrictas: omitir una propiedad requerida anula la obtención del resultado enriquecido, aunque el JSON sea sintácticamente válido. Product exige name y offers o review. FAQPage exige al menos una Question con su respectiva acceptedAnswer.
• Formato ISO 8601 para fechas: utilice 2026-09-08 o 2026-09-08T10:00:00+02:00.
• La propiedad sameAs debe apuntar a perfiles oficiales bajo su control directo (LinkedIn, X, YouTube corporativos), siendo la señal más fiable para la desambiguación de entidades.

Propiedades clave para la visibilidad en motores de IA

• description en Organization, redactada con rigor técnico y sin frases publicitarias.
• knowsAbout: listado de temáticas y tecnologías en las que su empresa acredita especialización.
• areaServed: especificación de mercados y países atendidos.
• availableLanguage: idiomas en los que presta atención comercial.
• makesOffer: vinculación formal entre la empresa y su catálogo de servicios.

Gestión en sitios web multilingües

Cada versión idiomática requiere su propio marcado estructurado con textos traducidos y el atributo inLanguage correctamente configurado. Los identificadores @id deben diferenciarse por idioma (por ejemplo, https://example.com/es/servicios/#service), preservando la concordancia con las etiquetas hreflang.

Verificación y auditoría

• Prueba de resultados enriquecidos de Google: comprueba si el marcado genera fragmentos enriquecidos en el buscador.
• Validador de Schema.org: verifica la conformidad sintáctica con el estándar.
• Nuestro validador gratuito de datos estructurados: comprueba la conexión del grafo, la coherencia de entidades y la ausencia de infracciones en valoraciones.