Cómo elegir los Datos estructurados de Google y Schema y mejorar la visibilidad SEO

Implementar datos estructurados en una web parece, a primera vista, una tarea puramente técnica: seleccionar un tipo de Schema, generar un fragmento JSON-LD, validarlo y añadirlo al código.

Sin embargo, una implementación puede ser técnicamente válida y, al mismo tiempo, representar de forma incorrecta la estructura de un negocio.

Esto sucede cuando todas las páginas utilizan el mismo tipo de Schema, cuando los servicios aparecen como entidades aisladas o cuando Google recibe versiones diferentes de una misma empresa, marca o autor. En estos casos, el problema no está necesariamente en la sintaxis del código, sino en la arquitectura de los datos estructurados.

Google y Schema definen los datos estructurados como un formato estandarizado que permite proporcionar información explícita sobre una página y clasificar su contenido. Esta información puede ayudar al buscador a comprender qué representa la URL y, en determinados casos, hacerla elegible para resultados enriquecidos.

Por tanto, una estrategia de Schema no debería limitarse a responder qué marcado podemos añadir. Antes debemos preguntarnos:

• ¿Cuál es la entidad principal de la web?
• ¿La empresa y la marca son la misma entidad?
• ¿Quién presta cada servicio?
• ¿Qué relación existe entre la organización, sus servicios y sus contenidos?
• ¿Google recibe una representación coherente del negocio en todas las páginas?

El verdadero valor de los datos estructurados aparece cuando dejamos de tratarlos como fragmentos independientes y empezamos a utilizarlos como una arquitectura conectada.

Vayamos poco a poco:

¿Qué son los datos estructurados de Google/Schema?

Los datos estructurados son una capa de información que se incorpora al código de una página para describir de forma explícita su contenido (si quieres mas información sobre como implementar datos estructurados, entra aquí).

Una persona puede entrar en una web y entender, por su diseño y sus textos, que está consultando una página de servicios, un producto, un artículo o la información de una empresa. Para un buscador, esta interpretación puede ser más compleja.

Los datos estructurados ayudan a precisar cuestiones como:

• Qué empresa es responsable del sitio.
• Qué producto o servicio se describe.
• Quién ha escrito un contenido.
• Qué precio tiene un producto.
• Qué relación existe entre una marca y una organización.
• Cuál es la sede física de un negocio.
• Qué entidad constituye el tema principal de una página.

Google explica que esta información actúa como una serie de pistas explícitas sobre el significado de la página. Además, puede utilizarse para generar resultados de búsqueda más completos y visuales, conocidos como resultados enriquecidos.

En mi caso, cuando doy clases, siempre hago la siguiente pregunta:

En España, «¿qué es 693 73 33 69?» y los alumnos contestan «un móvil«. Sin embargo, en otros países los números telefónicos tienen otro formato; precisamente los datos estructurados lo que hacen es darle una entidad a dicho dato, permiten identificar un teléfono, una dirección o información de una película de forma inequívoca.

Datos estructurados generales y datos estructurados para SEO

El concepto de dato estructurado no pertenece exclusivamente al SEO.

En bases de datos, analítica o inteligencia empresarial, se utiliza para hablar de información organizada mediante campos, filas, columnas y relaciones predefinidas. Es el caso de una tabla de clientes, un inventario de productos o un sistema de gestión comercial.

En SEO, normalmente empleamos el término Datos Estructurados para referirnos al marcado semántico incorporado a las páginas web, basado principalmente en el vocabulario de Schema.org.

Ambos conceptos comparten una misma idea: organizar la información para que pueda ser interpretada y procesada con menor ambigüedad. Sin embargo, su aplicación es diferente.

En una web, los datos estructurados no sustituyen al contenido visible ni a la optimización SEO tradicional. Añaden una capa que describe ese contenido de manera más explícita.

¿Es lo mismo hablar de Schema.org, JSON-LD y resultados enriquecidos?

Uno de los errores más habituales consiste en utilizar los conceptos Schema, JSON-LD y rich results como si fueran sinónimos.

Aunque están relacionados, representan elementos diferentes.

¿Qué es Schema.org?

Schema.org es un vocabulario que permite describir entidades, características y relaciones.

Dentro de este vocabulario encontramos tipos como:

• Organization
• Brand
• Service
• Product
• Person
• Article
• LocalBusiness
• WebSite
• WebPage
• Offer

Cada tipo dispone de propiedades con las que podemos ampliar su descripción. Por ejemplo, un servicio puede incluir información sobre:

• Su nombre.
• Su categoría.
• El proveedor.
• La marca asociada.
• El área geográfica en la que se ofrece.
• Las condiciones de contratación.
• El catálogo al que pertenece.

Schema.org define Service como un servicio prestado por una organización. Entre sus propiedades se encuentran provider, brand, areaServed, serviceType, offers y hasOfferCatalog.

¿Qué es JSON-LD?

JSON-LD es uno de los formatos que pueden utilizarse para implementar el vocabulario de Schema.org en una página.

Google admite JSON-LD, microdatos y RDFa. Aunque los tres formatos pueden ser válidos, recomienda generalmente JSON-LD porque suele resultar más sencillo de implementar, mantener y escalar.

Un bloque JSON-LD puede incluir elementos como:

• @context: indica el vocabulario utilizado.
• @type: define el tipo de entidad.
• @id: establece un identificador único y reutilizable.
• @graph: agrupa diferentes entidades conectadas.
• Propiedades como provider, brand, publisher o mainEntity.

Por tanto, Schema.org es el vocabulario y JSON-LD es uno de los formatos utilizados para expresarlo.

¿Qué son los resultados enriquecidos?

Los resultados enriquecidos son presentaciones especiales que Google puede mostrar cuando una página reúne los requisitos técnicos, de contenido y calidad correspondientes.

Dependiendo del tipo de contenido, pueden incluir:

• Precios.
• Disponibilidad.
• Valoraciones.
• Imágenes.
• Fechas.
• Información de eventos.
• Rutas de navegación.
• Datos de empresas.
• Detalles de productos.

No todos los tipos disponibles en Schema.org cuentan con una experiencia visual específica en Google. (si quieres la lista de formatos, entra aquí)

La galería de datos estructurados compatibles con la Búsqueda incluye funciones para productos, artículos, eventos, recetas, empresas locales, organizaciones, ofertas de empleo, vídeos y otros contenidos. Sin embargo, no incluye un rich result general específico para Service o Brand.

Esto no significa que estos tipos carezcan de utilidad. Su función puede ser principalmente semántica: describir una entidad y conectarla con el resto de la arquitectura.

¿Existe un tipo de Schema que mejore más el posicionamiento?

No existe evidencia documentada de que Google asigne un multiplicador de ranking directo por utilizar un tipo de Schema en lugar de otro. Implementar Product no concede automáticamente más autoridad algorítmica que implementar Service. Del mismo modo, utilizar Brand no implica que la página vaya a posicionarse por encima de otra que utilice Organization.

La diferencia se encuentra en:

• Lo que representa cada tipo.
• Las propiedades que permite declarar.
• Las funciones de búsqueda para las que puede generar elegibilidad.
• El modo en que se conecta con otras entidades.
• La correspondencia entre el marcado y el contenido visible.

Google señala que una acción manual por datos estructurados puede provocar que una página pierda su elegibilidad para resultados enriquecidos, pero no modifica directamente su ranking en los resultados web convencionales. También advierte que una implementación correcta no garantiza que el resultado enriquecido llegue a mostrarse.

Por tanto, no se trata de encontrar el Schema que “pesa más”, sino de seleccionar el que describe correctamente cada entidad.

¿Por qué el dato estructurado Product parece tener un impacto mayor?

Product puede generar un efecto más visible porque Google dispone de numerosas experiencias de búsqueda relacionadas con productos.

Cuando se cumplen los requisitos, una página puede mostrar información como:

• Precio.
• Disponibilidad.
• Valoraciones.
• Reseñas.
• Gastos de envío.
• Política de devoluciones.
• Imágenes.
• Variantes del producto.

Esta información puede aparecer en resultados de texto, Google Imágenes, Google Lens y otras experiencias comerciales.

Una presentación más completa puede favorecer la visibilidad y la interacción del usuario. Sin embargo, no debe interpretarse como una recompensa algorítmica ni como una garantía de mejora del CTR.

La página se vuelve elegible para determinadas funciones, pero Google decide qué formato muestra en función de la consulta, el dispositivo, la ubicación y otros factores.

¿Qué sucede con el dato estructurado de Service?

Service permite describir de forma explícita un servicio y relacionarlo con su proveedor, marca, categoría o área de cobertura. Sin embargo, Google no documenta actualmente un resultado enriquecido general dedicado a los servicios. Por ello, sus efectos suelen ser menos visibles que los de Product.

Su valor se encuentra en la capacidad de representar correctamente:

• Qué servicio se ofrece.
• Quién lo presta.
• Bajo qué marca se comercializa.
• En qué territorio está disponible.
• Qué otros servicios forman parte del catálogo.
• Qué página tiene ese servicio como entidad principal.

No debería utilizarse Product para describir artificialmente un servicio con el único objetivo de intentar obtener precios, estrellas o elementos visuales adicionales. El marcado debe corresponderse con la naturaleza real del contenido.

En mi opinión, aunque no haya documentación que lo pruebe, Google siempre premiará a aquellos que le facilite entender información.

Product, Service, Organization y Brand: qué función tiene cada uno en Schema

La elección depende de la entidad que se quiere representar, no de un supuesto peso SEO.

Tipo de Schema	Función principal	Potencial visual en Google
Product	Describir un producto y sus ofertas	Alto
Service	Describir un servicio, su proveedor y cobertura	Sin rich result general específico
Organization	Identificar y desambiguar una empresa u organización	Puede influir en información corporativa y determinados elementos visuales
LocalBusiness	Representar una empresa con presencia física	Relevante para información empresarial y local
Brand	Identificar una marca asociada a productos, servicios u organizaciones	Sin rich result propio documentado
Article o BlogPosting	Identificar un contenido editorial	Variable
Offer	Describir las condiciones bajo las que se ofrece un producto o servicio	Normalmente asociado a otra entidad

Cuándo utilizar el dato estructurado Product

Product debe utilizarse cuando la página describe un producto real, físico o digital.

Puede estar conectado con:

• Una marca.
• Un fabricante.
• Una oferta.
• Un precio.
• Una disponibilidad.
• Una valoración.
• Una variante.

Cuando la página permite comprar el producto, también puede ser necesario representar la oferta y cumplir los requisitos específicos de las fichas de comerciantes.

Cuándo utilizar el dato estructurado Service

Service debe emplearse cuando la entidad principal es un servicio.

Por ejemplo:

• Consultoría SEO.
• Instalación de alarmas.
• Limpieza de edificios.
• Transporte de mercancías.
• Servicios jurídicos.
• Desarrollo web.
• Recarga de vehículos eléctricos.

Un servicio puede conectarse directamente con la organización mediante provider y con una marca mediante brand.

Schema.org admite igualmente propiedades como serviceType, areaServed, offers y hasOfferCatalog.

Cuándo utilizar el dato estructurado de Organization

Organization representa a la empresa, institución, asociación o entidad responsable de la actividad.

Google recomienda añadir este marcado a la página principal para ayudarle a comprender los datos administrativos y desambiguar la organización frente a otras entidades. Algunas propiedades también pueden influir en elementos visuales, como el logotipo mostrado en los resultados o en determinados paneles.

Una entidad Organization puede incluir:

• Nombre oficial.
• Nombre alternativo.
• URL.
• Logotipo.
• Datos de contacto.
• Dirección.
• Identificadores legales o empresariales.
• Perfiles oficiales mediante sameAs.
• Marca o marcas mantenidas por la organización.

Cuándo utilizar el Schema de Brand

Brand representa una identidad comercial asociada a productos, servicios o una organización y no debe considerarse un sustituto automático de Organization.

Una empresa puede operar con una marca idéntica a su nombre corporativo, pero también puede existir una organización que mantenga varias marcas o una marca comercial diferente de la razón social.

La propiedad brand puede utilizar como valor una entidad Brand o una Organization, y puede incorporarse en productos, servicios, personas u organizaciones.

La arquitectura correcta debe reflejar la situación real del negocio:

• Si empresa y marca coinciden, puede bastar con una organización coherentemente definida.
• Si la marca tiene una identidad diferenciada, puede ser conveniente declararla como entidad propia.
• Si una organización mantiene varias marcas, deben establecerse las relaciones correspondientes.
• Los productos y servicios deben conectarse con la marca que realmente los comercializa.

El error más frecuente: implementar nodos de Schema aislados

Muchas implementaciones generan un bloque diferente en cada página, pero no mantienen una arquitectura común.

El resultado puede parecerse a esta estructura:

Service

Service

Service

Article

Organization

Person

Aunque todos los nodos sean válidos, Google puede recibir una representación fragmentada si no se establecen relaciones entre ellos.

Entre los problemas más habituales relacionado a los datos estructurados se encuentran:

• Cada página crea una organización diferente.
• El nombre de la empresa cambia entre plantillas.
• Los identificadores @id no son consistentes.
• Los servicios no indican quién es su proveedor.
• Los artículos no comparten un publisher común.
• La marca no está relacionada con la organización.
• Las personas aparecen sin conexión con sus perfiles o contenidos.
• La home se presenta como un servicio más, sin identificar claramente la empresa.

Un validador puede comprobar que el código tiene una sintaxis correcta, pero no siempre puede determinar si la arquitectura representa adecuadamente el negocio.

Por qué la arquitectura de datos estructurados es una decisión estratégica

La arquitectura de datos estructurados define qué entidades existen en la web y cómo se relacionan.

No debe diseñarse página por página de forma independiente. Debe partir de una representación global del negocio.

Permiten definir la entidad principal de la web

En una empresa de servicios, la entidad central suele ser una Organization o un subtipo más específico, como LocalBusiness, cuando existe una actividad local y una presencia física relevante.

A partir de esa entidad principal pueden conectarse:

• La marca.
• El sitio web.
• Las ubicaciones.
• Los servicios.
• Los catálogos.
• Los autores.
• Los artículos.
• Los datos de contacto.

La página de inicio no debería tratarse simplemente como otro servicio. Es el principal punto de referencia para definir quién opera la web y cómo se relacionan el resto de sus elementos.

Permiten seleccionar una entidad principal para cada plantilla

Cada URL debe tener una función clara dentro de la arquitectura.

Tipo de página	Entidad principal recomendada
Página de inicio	WebSite y Organization
Quiénes somos	AboutPage y Organization
Página de servicio	Service
Página de producto	Product
Listado de servicios	CollectionPage u OfferCatalog
Artículo de blog	Article o BlogPosting
Página de autor	ProfilePage y Person
Página de contacto	ContactPage
Sede física	Subtipo apropiado de LocalBusiness
Caso de éxito	Article, BlogPosting o CreativeWork, según el formato

Esto no significa que cada página solo pueda contener un tipo. Puede incluir diferentes entidades relacionadas, pero debe existir una jerarquía comprensible.

Permiten utilizar identificadores estables

@id permite asignar un identificador único a cada entidad.

Por ejemplo:

https://www.ejemplo.com/#organization
https://www.ejemplo.com/#brand
https://www.ejemplo.com/#website
https://www.ejemplo.com/servicio-seo/#service
https://www.ejemplo.com/equipo/nombre/#person

Cuando una página necesita mencionar a la organización, debe reutilizar el mismo identificador en lugar de crear una nueva versión de la empresa.

Esta consistencia permite conectar los diferentes nodos del grafo.

Cómo conectar Organization, Brand, Service y Offer

Una buena arquitectura no consiste necesariamente en anidar toda la información dentro de un único bloque. Las entidades pueden declararse dentro de otras o como nodos independientes conectados mediante @id.

Lo importante es que las relaciones sean claras y consistentes.

Conectar un servicio con su proveedor

Una estructura conceptual puede ser:

Service
├── provider → Organization
├── brand → Brand
├── areaServed → territorio
├── serviceType → categoría
└── mainEntityOfPage → URL del servicio

Schema.org define provider como el proveedor, operador o responsable de prestar un servicio. También admite que otra entidad actúe como vendedor, aunque el proveedor siga siendo quien ejecuta el servicio.

Conectar una organización con su oferta

Cuando se utiliza makesOffer, la relación debe conducir normalmente a una entidad Offer.

Dentro de la oferta, itemOffered identifica el producto o servicio ofrecido:

Organization
└── makesOffer
    └── Offer
        └── itemOffered
            └── Service

Schema.org define itemOffered como el elemento que forma parte de una oferta y admite, entre otros valores, entidades de tipo Product y Service.

Conectar los contenidos editoriales

Los artículos también deben integrarse en la arquitectura:

BlogPosting
├── author → Person
├── publisher → Organization
├── isPartOf → WebSite
├── about → temática o entidad principal
└── mainEntityOfPage → URL del artículo

De este modo, los contenidos dejan de ser páginas editoriales aisladas y pasan a formar parte del ecosistema de la organización.

Ejemplo de arquitectura semántica para una empresa de servicios

Una arquitectura simplificada podría representarse así:

Organization
├── Brand
├── WebSite
├── ContactPoint
├── LocalBusiness
├── Person
└── OfferCatalog
    ├── Offer
    │   └── Service 1
    ├── Offer
    │   └── Service 2
    └── Offer
        └── Service 3

WebSite
├── AboutPage
├── ContactPage
├── ServicePage
└── Blog
    ├── BlogPosting
    ├── BlogPosting
    └── BlogPosting

La arquitectura definitiva dependerá de la estructura corporativa y comercial.

No todas las empresas necesitan una entidad Brand independiente. Tampoco todas requieren LocalBusiness, OfferCatalog o una colección de ofertas.

La decisión debe basarse en las entidades que realmente existen, no en la intención de incorporar el mayor número posible de tipos.

Cómo diseñar una arquitectura de datos estructurados paso a paso

Puedes encontrar mas detalles sobre como implementar los datos estructurados aqui:

1. Identificar las entidades reales del negocio

El primer paso consiste en elaborar un inventario.

Puede incluir:

• Empresa o razón social.
• Marca o marcas comerciales.
• Productos.
• Servicios.
• Profesionales.
• Autores.
• Ubicaciones.
• Certificaciones.
• Áreas geográficas.
• Contenidos.
• Catálogos.
• Datos de contacto.

También debe comprobarse si algunas de estas entidades coinciden o son diferentes.

Por ejemplo, la marca puede compartir nombre con la organización o constituir una identidad comercial independiente.

2. Analizar las plantillas de la web

La arquitectura debe aplicarse de forma sistemática a las plantillas, no únicamente a páginas concretas.

Conviene revisar:

• Home.
• Páginas corporativas.
• Servicios.
• Productos.
• Categorías.
• Artículos.
• Autores.
• Contacto.
• Localizaciones.
• Casos de éxito.

Cada plantilla debe tener una entidad principal y unas relaciones predefinidas.

3. Definir identificadores únicos

Las entidades globales deben mantener el mismo @id en toda la web.

Especialmente:

• Organización.
• Marca.
• Sitio web.
• Ubicaciones.
• Autores.

Los servicios o productos pueden tener un identificador propio asociado a su URL canónica.

4. Crear el mapa de relaciones

Antes de programar el JSON-LD, conviene representar gráficamente:

• Quién presta cada servicio.
• Qué marca lo comercializa.
• Qué organización publica cada contenido.
• Qué autores forman parte del equipo.
• Qué ubicaciones ofrecen cada servicio.
• Qué productos pertenecen a cada marca.

Esta fase permite detectar contradicciones antes de trasladarlas al código.

5. Alinear los datos estructurados con el contenido visible

La información declarada debe ser coherente con lo que puede ver el usuario.

Google indica que no deben marcarse contenidos ocultos, irrelevantes o engañosos. El marcado debe representar el contenido principal de la página y seguir las directrices específicas de cada función.

Por tanto, no deberían incluirse:

• Servicios que no aparecen en la página.
• Precios inexistentes.
• Reseñas falsas.
• Direcciones incorrectas.
• Certificaciones no acreditadas.
• Autores que no participan en el contenido.
• Relaciones corporativas que no existen.

6. Validar la implementación

Una vez generado el código, debe comprobarse con:

• La Prueba de resultados enriquecidos.
• Schema Markup Validator.
• La herramienta de inspección de URLs.
• Los informes de Search Console.
• Un rastreador SEO que permita extraer y revisar JSON-LD.

Google recomienda probar el marcado durante el desarrollo y seguir monitorizando su validez después de publicarlo, ya que pueden aparecer errores relacionados con plantillas o cambios técnicos.

7. Medir el rendimiento

La medición no debe limitarse al número de elementos válidos.

También debe analizarse:

• Evolución de clics e impresiones.
• CTR.
• Posición media.
• Consultas de marca y sin marca.
• Keywords en Top 3, Top 10 y Top 20.
• URLs que comienzan a recibir visibilidad.
• Aparición de resultados enriquecidos.
• Cambios por tipo de plantilla.

Google recomienda comparar el rendimiento antes y después durante un periodo suficientemente amplio y reconoce que los resultados pueden verse afectados por múltiples factores.

La arquitectura correcta es más importante que la cantidad de Schema

Los datos estructurados no deben tratarse como una colección de etiquetas añadidas para intentar conseguir estrellas, imágenes o posiciones más altas.

Su función es representar de manera clara y coherente el contenido y las entidades de una web.

No existe un tipo de Schema con más peso de ranking por naturaleza. Algunos, como Product, tienen un mayor potencial visual porque Google dispone de experiencias específicas para productos. Otros, como Service o Brand, cumplen principalmente una función descriptiva y relacional.

La decisión estratégica no consiste en priorizar un tipo frente a otro, sino en construir una arquitectura que responda correctamente a estas preguntas:

• ¿Quién es la empresa?
• ¿Cuál es su marca?
• ¿Qué servicios o productos ofrece?
• ¿Quién publica sus contenidos?
• ¿Cómo se relacionan todas estas entidades?

Una implementación sólida convierte una web fragmentada en un ecosistema semántico coherente.

Y esa coherencia es lo que permite que Google reciba una representación más clara de la empresa, la marca y su propuesta de valor.

Errores frecuentes al implementar datos estructurados

Utilizar Service en todas las páginas

Una web de servicios no debe marcar automáticamente todas sus URLs como Service.

La home, la página corporativa, el blog, los autores y el contacto tienen funciones diferentes.

Sustituir Organization por Brand

Brand y Organization no son equivalentes.

La primera representa una identidad comercial. La segunda identifica a la empresa o entidad responsable de la actividad.

En muchos casos deben coexistir y estar relacionadas.

Marcar servicios como productos

Utilizar Product para describir un servicio puede generar una representación incorrecta del contenido.

La posibilidad de obtener resultados visuales no justifica utilizar un tipo que no corresponde con la entidad real.

Crear varias versiones de la misma organización

El nombre, URL, logotipo o identificador de la empresa no deberían cambiar entre páginas.

Todas las menciones deben apuntar a la misma entidad.

No relacionar los servicios con su proveedor

Un nodo Service aislado describe el servicio, pero no necesariamente identifica con claridad quién lo presta.

La propiedad provider permite establecer esta relación.

Considerar suficiente la validación

Que un código sea válido no significa que sea estratégicamente correcto.

Los validadores detectan errores de sintaxis y requisitos técnicos, pero no sustituyen el análisis de la arquitectura empresarial.

Añadir todas las propiedades posibles

Google recomienda priorizar propiedades completas y precisas frente a grandes volúmenes de información incompleta o inexacta.

La calidad y la coherencia son más importantes que la cantidad.

Caso de éxito: de una web basada en servicios aislados a una arquitectura centrada en la marca

Situación inicial

En el proyecto analizado, la web estaba configurada principalmente alrededor de entidades Service.

La página de inicio y diferentes URLs interiores utilizaban el marcado de servicio como elemento central. Sin embargo, no existía una representación suficientemente clara y consistente de:

• La empresa responsable de la web.
• La marca comercial.
• La relación entre la marca y la organización.
• El proveedor de cada servicio.
• El sitio web como entidad.
• Los contenidos publicados por la empresa.

El problema no era que Service fuese un tipo incorrecto. Era adecuado para las páginas que describían servicios concretos.

La dificultad estaba en que se había convertido en el centro de toda la arquitectura, dejando a la organización y a la marca en un segundo plano.

Cambio de enfoque

La solución no consistió simplemente en sustituir todos los nodos Service por Brand.

Se rediseñó la arquitectura para que la marca y la organización ocupasen la posición que realmente tenían dentro del negocio.

Los principales cambios fueron:

• Definición de una entidad Organization consistente.
• Creación de una entidad Brand cuando correspondía.
• Incorporación de una entidad WebSite.
• Mantenimiento de Service en las páginas de servicios.
• Conexión de cada servicio con su proveedor.
• Unificación de los identificadores @id.
• Relación de la organización con la marca.
• Conexión de los contenidos con su publisher.
• Revisión de nombres, logotipos, URLs y perfiles oficiales.
• Adaptación del marcado a cada plantilla.

La web dejó de representarse como una suma de servicios independientes y pasó a mostrar una organización que operaba una marca, publicaba contenidos y prestaba diferentes servicios.

Resultados observados

Después de la implantación y de la consolidación de los cambios, los datos del proyecto mostraron:

• Mejora de los rankings orgánicos.
• Mayor número de consultas con visibilidad.
• Crecimiento de las impresiones.
• Incremento del tráfico procedente de buscadores.
• Mayor presencia de URLs interiores.
• Mejor asociación entre la marca y sus servicios.

La conclusión correcta es que la mejora coincidió con una arquitectura semántica más coherente, dentro de una estrategia SEO más amplia. pese a que no podemos relacionar directamente los cambios realizados frente a los resultados obtenidos, pero tiene sentido.

El aprendizaje del proyecto no fue que Brand tenga más peso que Service. Fue que una web debe representar primero a la empresa y a la marca, y después conectar correctamente los servicios que ofrece.

Preguntas frecuentes sobre datos estructurados y Schema

¿Los datos estructurados mejoran directamente el posicionamiento?

Google no documenta un incremento automático de rankings por implementar datos estructurados.

Su función es proporcionar información explícita sobre el contenido y, en determinados casos, habilitar resultados enriquecidos. Una mayor comprensión o una presentación más visible puede generar beneficios indirectos, pero no garantiza mejores posiciones.

¿Qué Schema es mejor: Product, Service o Brand?

No existe un tipo universalmente mejor.

Product debe utilizarse para productos, Service para servicios y Brand para marcas. La empresa debe representarse normalmente mediante Organization o un subtipo más específico.

La elección debe responder a la naturaleza real de la entidad.

¿Brand puede sustituir a Organization?

No de forma automática.

Organization representa a la empresa o entidad responsable. Brand identifica una marca comercial asociada a productos, servicios o una organización.

Pueden coincidir en nombre, pero desempeñan funciones semánticas diferentes.

¿Service genera resultados enriquecidos?

Google no documenta actualmente un rich result general específico para Service.

Aun así, este tipo permite describir un servicio y relacionarlo con su proveedor, marca, área de cobertura, categoría y ofertas.

¿JSON-LD y Schema.org son lo mismo?

No.

Schema.org es el vocabulario que define los tipos y propiedades. JSON-LD es uno de los formatos utilizados para incorporar ese vocabulario al código de la página.

¿Cómo puedo saber si la arquitectura es correcta?

Una arquitectura correcta debe:

• Representar entidades reales.
• Mantener identificadores consistentes.
• Adaptarse a cada plantilla.
• Conectar organización, marca, servicios y contenidos.
• Coincidir con la información visible.
• Cumplir las directrices de Google y Schema.org.

Superar un validador es necesario, pero no suficiente.

¿Google entiende correctamente tu empresa y sus servicios?

Una auditoría de datos estructurados no debería limitarse a comprobar errores de validación. También debe analizar si la arquitectura representa correctamente la organización, la marca, sus servicios, productos, autores, ubicaciones y contenidos.

Si necesitas revisar si tu web tiene los datos estructurados, contacta con nosotros.

Post escrito por: