Qué es el Schema de Localbusiness

Un negocio puede tener su dirección en el pie de página, los horarios en contacto y los servicios repartidos entre varias URLs. El marcado LocalBusiness permite describir esos datos de forma estructurada. Para que resulte útil, hay que identificar bien el negocio y expresar qué relación tiene con cada dato.

Aquí entra el anidamiento de schema: una dirección pertenece a un negocio; un horario corresponde a su apertura; un servicio lo presta una empresa. Colocar toda esa información en un mismo bloque no basta si las relaciones están mal planteadas.

En esta guía veremos qué conviene marcar, cómo organizarlo en JSON-LD y cómo revisar el resultado en WordPress. Hay dos ejemplos explicados: uno con datos anidados y otro que conecta varias entidades mediante @graph y @id.

Qué es Schema LocalBusiness y qué representa

LocalBusiness es un tipo del vocabulario Schema.org para describir un negocio físico concreto o una sucursal. Hereda propiedades de Organization y de Place: puede tener datos de una organización y, a la vez, una ubicación física.

Por ejemplo, un salón de belleza y la página donde explica sus tratamientos son cosas diferentes. El salón puede describirse como BeautySalon, un subtipo de LocalBusiness; la página es una WebPage y el tratamiento puede representarse como un Service. Distinguirlas ayuda a evitar un error frecuente: asignar todos los datos de la web a una única entidad.

Conviene utilizar un subtipo existente que describa con precisión la actividad. BeautySalon es una opción para un salón de belleza. Si ninguno encaja, es preferible mantener un tipo general correcto antes que inventar uno o elegir una actividad que el negocio no realiza.

Schema.org aporta el vocabulario. JSON-LD es una forma de escribir esos datos. Google documenta qué tipos y propiedades utiliza para sus funciones de búsqueda. Esta distinción se explica con más detalle en nuestra guía sobre datos estructurados, marcado schema y resultados enriquecidos.

Qué puedes esperar del marcado en Google

Google utiliza los datos estructurados para interpretar contenido y habilitar determinadas presentaciones en sus resultados. En LocalBusiness, su documentación contempla información del establecimiento como dirección y horarios. Eso no permite prometer una mejora concreta de posiciones, llamadas o ventas por añadir un bloque de código.

El posicionamiento local depende de varios factores. Google señala la relevancia, la distancia y la prominencia entre los principales. Un marcado correcto no convierte una oficina en otra ubicación ni sustituye una página de servicio útil, un perfil de empresa cuidado o una reputación real.

Tampoco hay una garantía de resultados enriquecidos. Google lo aclara incluso para páginas cuyo marcado es técnicamente correcto. La implementación puede hacer que una página reúna determinados requisitos; que se muestre una función depende además de la búsqueda y de los criterios del buscador.

El objetivo práctico es que los datos publicados sean comprensibles, consistentes y mantenibles. Si el horario de la web está desactualizado, describirlo perfectamente en JSON-LD seguirá transmitiendo un horario equivocado.

Qué datos conviene preparar antes de escribir código

Empieza por una ficha de datos contrastados: nombre comercial, URL, dirección pública, horarios, teléfono, imágenes y perfiles oficiales. Comprueba también qué cambia si hay varias sedes. Esa ficha debe coincidir con lo que una persona puede consultar en la web.

La documentación de LocalBusiness de Google identifica name y address como propiedades obligatorias para su implementación documentada. Schema.org, en cambio, no es una lista universal de campos SEO obligatorios: cada consumidor de los datos establece sus propios requisitos.

Campo o propiedad	Qué representa	Criterio de uso
@type	El tipo de entidad.	LocalBusiness o un subtipo que corresponda a la actividad real.
@id	Un identificador de la entidad.	Estable y reutilizable; especialmente útil para conectar otros nodos con el mismo negocio.
name	El nombre del negocio.	El nombre real, sin añadir ciudades o servicios como una lista de palabras clave.
address	La dirección física.	Organizarla como PostalAddress cuando corresponda; no confundirla con la zona atendida.
url	La página que representa al negocio o a esa sede.	Una URL vigente y coherente con la entidad descrita.
telephone	El teléfono de contacto.	El número correcto, con prefijo internacional; +34 en un número español.
openingHoursSpecification	Las franjas de apertura.	Separar tramos y días cuando cambien; mantenerlos actualizados.
geo	Las coordenadas de la ubicación.	El punto real del establecimiento, no el centro de la ciudad a la que se quiere llegar.
image	Una imagen de la entidad.	Imagen pertinente y accesible, con una URL real.
sameAs	Otras URLs que identifican a la misma entidad.	Perfiles oficiales y referencias inequívocas; no una lista de enlaces sobre el sector.

Estas propiedades tienen funciones diferentes. GeoCoordinates describe una posición; sameAs relaciona identidades. Ninguna justifica añadir ubicaciones o perfiles ajenos. Una plantilla con más campos no es necesariamente una implementación mejor.

El vocabulario puede utilizarse en webs españolas. En los ejemplos empleamos ES, una dirección de Córdoba y horarios de 24 horas. Las propiedades conservan sus nombres técnicos en inglés: se escribe addressLocality, no una traducción inventada del campo.

Qué significa anidar schema y cómo hacerlo con sentido

Anidar consiste en colocar un objeto dentro de otro a través de una propiedad. Esa propiedad expresa la relación. Si el negocio contiene address y su valor es un PostalAddress, estamos diciendo que esa es su dirección.

El objeto interior conserva su propia estructura. PostalAddress puede contener calle, localidad, provincia, código postal y país. Esos campos describen la dirección. No deben repartirse arbitrariamente por el objeto principal del negocio.

La misma lógica se aplica a los horarios: openingHoursSpecification conecta el negocio con uno o varios objetos OpeningHoursSpecification. Dentro de cada uno aparecen los días y las horas de apertura y cierre.

La propiedad importa más que la profundidad

No existe una ventaja documentada por añadir más niveles al marcado. Cada nivel debe responder a una pregunta: ¿qué es este dato y a qué pertenece? Una dirección dentro de address tiene sentido; una dirección dentro de openingHoursSpecification mezcla conceptos, aunque el texto pudiera seguir siendo JSON legible.

Tampoco sirve asignar al negocio todos los tipos en un array. "@type": ["LocalBusiness", "PostalAddress"] estaría atribuyendo dos tipos al mismo nodo, no creando un negocio con una dirección. Anidar entidades y asignar varios tipos a una entidad son operaciones distintas.

El contexto y los objetos interiores

En estos ejemplos, @context aparece al principio y establece el vocabulario para el documento. No es necesario repetirlo dentro de cada dirección o franja horaria. Si se publican documentos JSON-LD independientes, cada uno necesita un contexto que permita interpretar correctamente sus términos.

Los detalles formales de identificadores, tipos y objetos están definidos en JSON-LD 1.1, la especificación del W3C. Para una implementación habitual interesa dominar esas relaciones básicas antes de incorporar estructuras más complejas.

Ejemplo 1: negocio con dirección y horarios anidados

Ejemplo didáctico con datos ficticios. El salón, la calle y las URLs siguientes no corresponden a un cliente ni describen a Shopoo. El código muestra una estructura; antes de utilizarla en una web hay que sustituir los datos por información real que figure en esa página.

El supuesto es un salón abierto de lunes a viernes, de 9:00 a 14:00 y de 17:00 a 20:00, y cerrado el fin de semana. Se utiliza BeautySalon, por lo que no hace falta añadir también LocalBusiness para expresar su pertenencia a esa familia.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BeautySalon",
  "@id": "https://example.com/#negocio",
  "name": "Salón de ejemplo",
  "url": "https://example.com/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle de ejemplo, 12",
    "addressLocality": "Córdoba",
    "addressRegion": "Córdoba",
    "postalCode": "14001",
    "addressCountry": "ES"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "09:00",
      "closes": "14:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "17:00",
      "closes": "20:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Saturday",
        "Sunday"
      ],
      "opens": "00:00",
      "closes": "00:00"
    }
  ]
}
</script>

Hay tres decisiones que conviene entender:

• La dirección es un objeto. Córdoba, el código postal y la calle quedan dentro de address, con su tipo PostalAddress.
• El horario partido ocupa dos objetos. Cada franja tiene sus propios valores opens y closes. No se escriben dos propiedades llamadas opens dentro del mismo objeto.
• El cierre del fin de semana se declara expresamente. En el formato que documenta Google, apertura y cierre a 00:00 indican cierre durante todo el día. No debe confundirse con abrir las 24 horas.

Los corchetes de openingHoursSpecification contienen una lista de franjas. También hay listas de días dentro de cada franja. El orden visual del código facilita leerlo, pero la relación la establecen las propiedades y sus valores.

El ejemplo se centra en dirección y horarios. Podrían añadirse un teléfono y una imagen reales, entre otros datos pertinentes. No incluye coordenadas ni valoraciones de relleno para que parezca más completo. Si cambia el horario de verano, habrá que actualizar tanto lo visible como el marcado correspondiente.

Cómo relacionar entidades con @id y @graph

Cuando una web describe un negocio, sus páginas y varios servicios, repetir todos los datos de la empresa dentro de cada objeto resulta difícil de mantener. Se puede asignar un @id al negocio y referenciar ese identificador desde otras entidades.

En nuestro ejemplo, https://example.com/#negocio identifica al salón. https://example.com/#website identifica a la web. Comparten dominio, pero representan entidades diferentes. El fragmento final permite distinguirlas; no requiere crear una página independiente para cada identificador.

@graph permite agrupar varios nodos en un documento. Las relaciones siguen dependiendo de las propiedades y de los identificadores: poner dos objetos junto al otro dentro de un array no explica por sí solo qué relación mantienen.

La guía de Google sobre varios elementos en una página admite tanto elementos anidados como elementos separados y relacionados mediante @id. Por tanto, no hay que convertir una estructura correcta en un grafo solo por considerar que su aspecto es más avanzado.

Qué identificar y cuando no hace falta complicarse

Resulta útil identificar el negocio, la web y las páginas que se relacionan con otras entidades. Una dirección que solo se usa dentro de un negocio puede permanecer anidada sin un @id propio. Asignar identificadores a todos los objetos pequeños puede añadir trabajo sin resolver ningún problema del proyecto.

Mantén el mismo identificador para la misma entidad. No crees #empresa, #negocio y #organizacion en distintos plugins como si fueran tres empresas cuando describen una sola. A la inversa, no reutilices el mismo identificador para dos sucursales diferentes.

Ejemplo 2: conectar negocio, web, página y servicio

Este segundo modelo corresponde a una página que explica el servicio de coloración del salón y muestra sus datos de contacto. Los datos siguen siendo ficticios. El negocio, la web, la página y el servicio se definen por separado y se conectan con referencias.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BeautySalon",
      "@id": "https://example.com/#negocio",
      "name": "Salón de ejemplo",
      "url": "https://example.com/",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Calle de ejemplo, 12",
        "addressLocality": "Córdoba",
        "addressRegion": "Córdoba",
        "postalCode": "14001",
        "addressCountry": "ES"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Salón de ejemplo",
      "publisher": {
        "@id": "https://example.com/#negocio"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/coloracion/#webpage",
      "url": "https://example.com/coloracion/",
      "name": "Coloración en Salón de ejemplo",
      "isPartOf": {
        "@id": "https://example.com/#website"
      },
      "mainEntity": {
        "@id": "https://example.com/coloracion/#servicio"
      }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/coloracion/#servicio",
      "name": "Servicio de coloración",
      "serviceType": "Coloración del cabello",
      "url": "https://example.com/coloracion/",
      "provider": {
        "@id": "https://example.com/#negocio"
      }
    }
  ]
}
</script>

Relación	Cómo leerla
WebSite.publisher → negocio	El salón es la organización que publica esta web.
WebPage.isPartOf → WebSite	La página de coloración pertenece a esa web.
WebPage.mainEntity → Service	El servicio de coloración es el contenido principal de esa página.
Service.provider → negocio	El salón es quien presta el servicio.
negocio.address → PostalAddress	La dirección sigue anidada dentro del negocio.

La propiedad provider permite indicar quién presta un servicio. mainEntity identifica la entidad principal descrita por una página; isPartOf expresa su pertenencia a una obra más amplia, como el sitio web. publisher identifica a su editor. Elegir la propiedad adecuada evita atribuir al servicio una dirección como si el servicio fuera un establecimiento.

Fíjate en que el ejemplo combina ambas formas: hay un grafo de entidades y, dentro del negocio, una dirección anidada. Anidamiento y grafo pueden convivir. Lo que se simplifica con @id es la referencia al mismo negocio desde distintos lugares del documento.

El objeto Service describe el servicio; no constituye por sí mismo una promesa de una presentación especial en Google. Tampoco hay que marcar todos los artículos del blog como servicios. La elección depende de lo que realmente explica cada página.

Para que se vean las relaciones, el segundo ejemplo omite los horarios del primero. Una implementación real debe recoger los datos pertinentes sin perder consistencia. No pegues ambos modelos automáticamente en una página: decide qué existe ya, qué falta y qué entidades necesitas describir allí.

Varias sedes, departamentos y zonas de servicio

Cada sede necesita una identidad propia

Si una empresa tiene un establecimiento en Córdoba y otro en Posadas, cada local debe tener sus datos: dirección, URL, horarios y un identificador distinto. Copiar el mismo @id en ambas sedes mezcla su identidad.

La organización general puede representarse aparte cuando sea una entidad diferenciada. La propiedad parentOrganization permite vincular una organización con la organización superior a la que pertenece. La marca, la sede y la página de esa sede no deben confundirse en una sola ficha.

Una lista de ciudades atendidas tampoco equivale a una lista de sucursales. Si solo hay un establecimiento y se trabaja en varios municipios, el marcado debe reflejar esa realidad.

Un servicio no es automáticamente un departamento

Google documenta department para departamentos del negocio que pueden tener datos propios, como horarios o teléfonos. No es un contenedor genérico donde introducir cualquier cosa relacionada con la empresa.

En un salón, “coloración”, “corte” y “peinado” suelen describir servicios. Convertir cada uno en otro establecimiento con la misma dirección añade confusión. Solo tendría sentido describir una unidad como departamento si realmente lo es y la web aporta la información correspondiente.

Si no publicas una dirección, no la inventes

Un negocio que visita a sus clientes puede tener un Perfil de Empresa configurado por zona de servicio. Google indica que, si no se atiende a clientes en la dirección de la empresa, debe eliminarse esa dirección del perfil. Esa configuración del perfil y el marcado de la web son cuestiones relacionadas, pero no intercambiables.

Si no puedes publicar una dirección real, no uses una oficina ficticia para completar la validación de LocalBusiness. Es posible describir la organización y sus servicios cuando corresponda, pero eso no convierte automáticamente la página en elegible para la implementación de LocalBusiness que exige Google.

Además, el JSON-LD no es un espacio privado. Aunque no se muestre como texto normal, está en el código que se entrega al navegador. No introduzcas una dirección particular que se haya decidido mantener fuera de la web.

Reseñas propias: por qué no copiar un aggregateRating

Muchos ejemplos incluyen aggregateRating con una nota y un número de reseñas. Ese bloque requiere especial cuidado. Que una propiedad exista en Schema.org no significa que un negocio pueda utilizarla para conseguir estrellas de Google en su propia página.

Las directrices de fragmentos de reseñas de Google excluyen de esa función las reseñas sobre una organización o negocio cuando la entidad reseñada controla las opiniones sobre sí misma. También contemplan el caso de una web que incorpora un widget de reseñas de terceros sobre su propio negocio.

Puedes mostrar testimonios reales con el contexto adecuado. Lo que no debes hacer es prometer estrellas en resultados orgánicos por añadir al LocalBusiness la media de tus reseñas de Google. Por ese motivo, los ejemplos de esta guía no contienen review ni aggregateRating.

Cómo llevarlo a WordPress sin duplicar entidades

Antes de instalar otro complemento o pegar código, revisa qué genera ya la web. El tema, el plugin SEO y otros módulos pueden emitir datos estructurados a la vez. La existencia de varios bloques no implica automáticamente un error; el problema aparece cuando describen entidades equivocadas o datos contradictorios.

1. Revisa la salida de la página. Consulta el HTML y busca application/ld+json. Anota tipos, identificadores y datos del negocio. Si hay marcado añadido con JavaScript, revisa también el HTML renderizado mediante las herramientas de prueba.
2. Localiza quién genera cada bloque. Identifica el plugin, tema o integración responsable. Comprueba sus funciones disponibles y la configuración de ese sitio; no todas las instalaciones ofrecen las mismas opciones locales.
3. Elige dónde mantener los datos. Conviene tener una configuración responsable del nombre, dirección y horarios, y conectar el resto de entidades con ella. Así se reduce el riesgo de actualizar un dato en un lugar y olvidarlo en otro.
4. Integra las ampliaciones con lo que ya existe. Si el plugin utiliza un identificador de organización, revisa si corresponde a la misma entidad y cómo ampliar o referenciar ese nodo. Una empresa con una única sede y una marca con varias sucursales pueden necesitar modelos distintos.
5. Asigna el marcado a las páginas pertinentes. Una sede debe quedar representada en la página que la describe; un servicio, en la página de ese servicio. Incluye la información necesaria en la propia página: una referencia a una URL externa no garantiza que Google complete datos ausentes.
6. Comprueba la salida final. Después de guardar y vaciar las cachés que procedan, revisa la URL pública. El código que aparece en la pantalla de configuración del plugin no sustituye esa comprobación.

Por ejemplo, Yoast documenta una API para integrar piezas en su grafo y conectar nodos mediante identificadores. No se trata de copiar sus IDs a ciegas, sino de utilizar el mecanismo previsto por el componente que ya controla el marcado.

Si se implementa a medida, debe hacerse mediante una integración mantenible, con alcance por página y posibilidad de revisar los cambios. No tiene sentido añadir un negocio ficticio a todas las entradas del blog porque el ejemplo se copió desde un artículo.

Cómo validar el código y las relaciones

Una revisión completa necesita comprobar varias cosas. El mensaje de una sola herramienta no responde a todas ellas.

1. Sintaxis del JSON

Comprueba comas, comillas, llaves y corchetes. JSON no admite comentarios ni una coma final después del último elemento. Utiliza comillas rectas y evita claves repetidas dentro de un objeto: algunos analizadores conservarán solo el último valor y el resultado puede no ser el que esperabas.

Esta primera revisión solo acredita que el documento se puede interpretar como JSON. No comprueba que el negocio exista, que las relaciones sean adecuadas o que cumpla requisitos de una función de Google.

2. Vocabulario y referencias

Revisa los tipos y las propiedades con Schema Markup Validator. Después comprueba la identidad de los nodos: ¿el proveedor del servicio apunta al negocio correcto?, ¿la página se vincula a la web adecuada?, ¿hay dos sedes compartiendo identificador?

Una relación técnicamente posible también puede ser falsa. Si el marcado dice que una empresa presta un servicio que solo menciona como ejemplo, el problema está en el modelo y en su correspondencia con el contenido.

3. Requisitos de las funciones de Google

Utiliza la Prueba de resultados enriquecidos para revisar los tipos compatibles con las funciones que Google evalúa. Es una comprobación distinta de la validación general de Schema.org; Google explica la diferencia en su página de herramientas de datos estructurados.

Que un tipo válido de Schema.org no produzca un resultado enriquecido en esa prueba no demuestra que esté mal escrito. A la inversa, superar la prueba no garantiza que Google muestre esa presentación. Revisa también los avisos y su significado, sin rellenar campos con datos inventados para eliminarlos.

4. Página publicada y mantenimiento

Tras la implementación, prueba la URL pública. Con acceso a Search Console, la inspección de URLs permite revisar aspectos de acceso e indexación y, mediante la prueba en directo, contrastar la versión accesible en ese momento. No confundas esa prueba con la información que Google ya tenga en el índice.

Repite la comprobación si se cambia de plugin SEO, tema, dirección, teléfono, horario o estructura de servicios. Deja registrado quién mantiene cada dato. Un marcado que era correcto puede dejar de serlo por un cambio ordinario del negocio.

Qué revisar para dar la implementación por terminada

• El tipo elegido corresponde a la actividad y a la entidad descrita.
• Los datos coinciden con la información que puede consultar una persona en la página.
• Las direcciones, horarios y servicios utilizan propiedades apropiadas para su relación.
• La misma entidad mantiene su identificador; las entidades distintas no lo comparten.
• Los plugins y las integraciones no publican versiones contradictorias del negocio.
• Los ejemplos ficticios se han sustituido y no hay valoraciones, sedes o servicios inventados.
• Se ha comprobado el código de la URL pública, no solo una plantilla aislada.
• Hay un responsable y un criterio para actualizarlo cuando cambie la información.

Para evaluar el negocio, hay que seguir midiendo consultas, contactos válidos y clientes. Si después de modificar el marcado cambian las posiciones, ese movimiento por sí solo no demuestra una relación causal: también pueden haber cambiado contenidos, enlaces, competencia o la propia búsqueda.

El marcado forma parte de una auditoría de SEO local más amplia. En Shopoo revisamos la relación entre información del negocio, páginas, visibilidad y medición para orientar las mejoras hacia consultas y oportunidades reales. Puedes consultar nuestro servicio de SEO local si necesitas revisar esa base en tu web.

Documentación de referencia

Contenido contrastado el 30 de septiembre de 2026. Además de las definiciones enlazadas en el texto, estas son las referencias principales:

• Google Search Central: datos estructurados LocalBusiness.
• Google Search Central: directrices generales y varios elementos en una página.
• Google Search Central: fragmentos de reseñas.
• Schema.org: LocalBusiness y propiedades heredadas.
• W3C: JSON-LD 1.1.
• Google Search Central: herramientas de validación.
• Yoast: integración de datos en su grafo de schema.