Schema Service y LocalBusiness: qué debe incluir realmente tu marcado de datos estructurados

En resumen

Los schemas Service y LocalBusiness suelen confundirse, aunque cumplen funciones distintas. Schema.org define Service como una prestación ofrecida por una organización, por ejemplo, un servicio de reparto o de impresión, con campos clave como provider, serviceType, areaServed y hasOfferCatalog. Por su parte, Schema.org define LocalBusiness como un negocio físico concreto o una sucursal, como un restaurante, una oficina bancaria o una consulta médica. En una página de servicios vinculada a un único establecimiento físico, lo habitual es combinar ambos: LocalBusiness para la ubicación y Service para explicar qué ofreces allí.

Puntos clave

• LocalBusiness requiere, como mínimo, nombre y dirección: Google solo admite marcado con estos campos para los resultados enriquecidos de negocios locales.
• Cada establecimiento necesita su propio marcado: si cuentas con varias ubicaciones, debes definir cada establecimiento físico por separado como un tipo LocalBusiness, según Google.
• Service describe la oferta, no el lugar: utiliza serviceType y areaServed para indicar qué prestas y en qué zona, independientemente de la dirección de tu negocio.
• Las reseñas no son obligatorias: aggregateRating dentro de LocalBusiness solo se recomienda para sitios que recopilan reseñas sobre otros negocios locales, no para cualquier empresa que tenga opiniones de sus propios clientes (Google).
• Los resultados enriquecidos nunca están garantizados: Google confirma expresamente que unos datos estructurados correctos no garantizan una presentación visual concreta en los resultados de búsqueda.

¿Por qué Google no identifica mi página de servicios como un negocio local?

Una empresa de reparaciones publica una página con su dirección, horario y una lista de servicios, pero en los resultados de búsqueda no aparece ninguna ficha de negocio, ninguna valoración con estrellas ni información destacada. El texto está ahí, pero los sistemas no lo interpretan como datos empresariales. Esa es la diferencia entre contenido pensado para personas y datos estructurados pensados para máquinas (páginas de servicio que responden a tus clientes).

El problema rara vez está en el contenido de la página. Suele estar en la ausencia de marcado schema o en una implementación incorrecta. Sin marcado en JSON-LD o microdatos, Google solo ve texto plano: debe deducir si «Calle Mayor 12, Madrid» es una dirección, una nota al pie o una frase dentro de un párrafo. Con datos estructurados, no hay que dejar nada a la interpretación, porque indicas de forma explícita qué representa cada dato.

La diferencia entre una tarjeta de visita y una carta de servicios

Piensa en LocalBusiness como la tarjeta de visita de tu negocio: nombre, dirección, teléfono y horario. Service sería la carta de servicios: qué ofreces, para quién y en qué área trabajas. Una página que solo incorpora marcado LocalBusiness indica a los buscadores dónde estás, pero no necesariamente qué haces. Una página con solo Service explica lo que ofreces, pero no dónde puede encontrarte el cliente. Para la mayoría de empresas de servicios con sede física, hacen falta ambos.

¿Qué ocurre si eliges el tipo equivocado?

Si utilizas LocalBusiness para un servicio que prestas exclusivamente online o a distancia, das a entender que existe una ubicación física a la que los clientes pueden acudir, aunque no sea así. En cambio, si solo usas Service para una tienda o consulta con establecimiento fijo, pierdes la oportunidad de mostrar una ficha de negocio con mapa, horario e indicaciones. En ambos casos, renuncias a visibilidad que podrías conseguir con el marcado adecuado.

¿Qué schema encaja con tu tipo de servicio?

La elección entre Service, LocalBusiness o una combinación de ambos depende de cómo recibe el cliente tu servicio.

Solo LocalBusiness es adecuado para negocios en los que la ubicación forma parte esencial de la experiencia: un restaurante, un gimnasio o una tienda. El cliente acude a tu establecimiento y el servicio se presta allí.

Solo Service es la mejor opción para profesionales sin una ubicación de atención al público o para servicios que se prestan en cualquier lugar: un redactor autónomo, una empresa de limpieza que trabaja en todo el país o un consultor informático remoto. En estos casos, areaServed tiene más relevancia que una dirección física.

Service dentro de LocalBusiness es la opción más habitual para pymes de servicios: una empresa de instalaciones con oficina y zona de cobertura, una notaría o una clínica de fisioterapia que también ofrece atención a domicilio. Defines el establecimiento como LocalBusiness y añades, mediante la propiedad makesOffer o hasOfferCatalog, los servicios concretos como objetos Service.

Ejemplo práctico de los campos necesarios

Para una empresa de fontanería con una sede y cobertura en tres municipios, un conjunto mínimo y correcto incluiría:

• @type: LocalBusiness o un subtipo más específico, como Plumber
• name, address, telephone, openingHours
• areaServed con los municipios en los que presta servicio
• hasOfferCatalog con uno o varios objetos Service, cada uno con su propio serviceType

Esta estructura ofrece a los buscadores y a los asistentes de AI una visión completa y sin ambigüedades: quién eres, dónde estás y qué haces exactamente.

Así puedes implementarlo:

• Determina primero si tu servicio está ligado a una ubicación física o si puedes prestarlo en cualquier lugar.
• Elige LocalBusiness, o un subtipo más específico, si la ubicación es relevante para el cliente.
• Añade objetos Service mediante hasOfferCatalog para cada servicio concreto.
• Incluye siempre el nombre y la dirección, ya que es el requisito imprescindible de Google para los resultados enriquecidos.
• Comprueba el marcado con la prueba de resultados enriquecidos antes de publicarlo.

¿Cómo debe ser el marcado de una empresa con varios establecimientos?

Imagina una clínica de fisioterapia regional con tres centros en distintas ciudades. Cada ubicación tiene su propio horario, equipo y una oferta de servicios que coincide en parte, pero no por completo.

Ejemplo práctico: una pyme de servicios hipotética con varias ubicaciones

Supongamos que esta clínica utiliza un único marcado genérico LocalBusiness para sus tres centros e indica la dirección de la sede principal. Los buscadores reciben una señal confusa: ¿qué centro corresponde a la búsqueda de un cliente cercano? Al separar la información en tres objetos LocalBusiness distintos, cada uno con su dirección, teléfono, horario y objetos Service propios para la oferta local, empresas similares han observado una mejora apreciable en la frecuencia con que se muestra el centro adecuado en búsquedas locales. Las cifras concretas varían según el sector y la situación, pero el principio que establece Google, definir cada establecimiento por separado, explica estructuralmente esa diferencia.

La lección no es solo técnica, sino organizativa: tratar los datos estructurados como una configuración única para toda la empresa hace que se pierda justamente la ventaja que deberían aportar.

¿Qué beneficios aporta un marcado Service y LocalBusiness correcto?

Un marcado bien implementado aporta valor en dos niveles. El primero son los resultados enriquecidos clásicos: fichas de negocio, horarios e indicaciones directamente en los resultados de búsqueda. Google es claro al respecto: los datos estructurados son un requisito, no una garantía. Incluso con un marcado impecable, puede que no aparezca un resultado enriquecido, sencillamente porque Google decide qué mostrar.

El segundo nivel, y hoy tiene al menos la misma importancia, es la facilidad con que los asistentes de AI pueden interpretar tu información. Cuando alguien pregunta a ChatGPT o Perplexity «qué fontanero en Madrid hace reparaciones urgentes», es más fácil que una respuesta se base en datos estructurados que en frases sueltas dentro de un párrafo. Un objeto Service con serviceType y areaServed bien definidos resulta tan útil para un modelo de lenguaje como para un buscador y, a menudo, es más fácil de procesar que el texto libre.

La creciente relevancia de este enfoque también se aprecia en la rapidez con la que las empresas adoptan la AI en marketing y ventas. Según CBS, en 2025 una de cada seis empresas neerlandesas utilizaba AI, el doble que dos años antes, y marketing y ventas eran las aplicaciones más mencionadas. Las empresas que ya hacen legibles sus páginas de servicios para las máquinas se preparan para un entorno de búsqueda en el que no solo Google, sino también los asistentes de AI, basan sus recomendaciones en información estructurada y correctamente etiquetada.

¿Qué errores son más frecuentes en el marcado actual?

Hay tres patrones que se repiten una y otra vez al auditar datos estructurados ya implementados.

Añadir reseñas sin contar con un sistema propio de recopilación

Muchas empresas añaden aggregateRating a su marcado LocalBusiness aunque no dispongan de un sistema propio de reseñas. Google es explícito: esta propiedad solo se recomienda para sitios que realmente recopilan reseñas sobre otros negocios locales, no como valoración genérica de tu propia empresa sin un sistema que la respalde.

Usar una única dirección genérica para varios establecimientos

Como en el ejemplo anterior, usar un objeto LocalBusiness compartido para varias ubicaciones es un error habitual. El resultado es que ningún establecimiento se posiciona de forma óptima en las búsquedas locales, porque las señales quedan mezcladas.

Incluir la información de servicios solo como texto, no en el marcado

La página enumera correctamente los servicios para el lector, pero esa información no aparece como objeto Service en el código. Para una persona es evidente, pero un buscador o un asistente de AI no puede interpretarla como información estructurada.

Resolver estos tres puntos suele dejar cubierta la mayor parte de la base técnica. El resto consiste en mantener el marcado actualizado cuando cambien el horario, la dirección o la oferta de servicios.

Preguntas frecuentes

¿Cuál es la diferencia entre el schema Service y el schema LocalBusiness?

LocalBusiness describe un establecimiento físico con dirección y horario, mientras que Service explica lo que ofrece una organización, como un servicio o tratamiento. Un negocio de servicios con una ubicación fija suele combinar ambos: LocalBusiness para el establecimiento y Service dentro de hasOfferCatalog para la oferta.

¿Todas las páginas de mi web necesitan marcado LocalBusiness?

No. Solo las páginas que describen un establecimiento físico concreto necesitan marcado LocalBusiness. Para servicios sin una ubicación de atención al público, es preferible utilizar únicamente un objeto Service con areaServed.

¿Es obligatoria la dirección en el marcado LocalBusiness?

Sí. Según Google, el nombre y la dirección son los requisitos mínimos para optar a resultados enriquecidos de negocios locales. Sin estos campos, el marcado no se considera válido para esa funcionalidad.

¿Un marcado correcto garantiza un resultado enriquecido en Google?

No. Google indica expresamente que no garantiza que las funciones de datos estructurados aparezcan en los resultados de búsqueda, incluso cuando la implementación sea técnicamente correcta. El marcado mejora las posibilidades, pero no asegura el resultado.

¿Cómo ayuda Launchmind a implementar el marcado Service y LocalBusiness?

Alex, el compañero de AI de Launchmind, mejora las páginas de servicios con una respuesta directa, una orientación de precios, el proceso de trabajo, pruebas y preguntas extraídas de tus conversaciones reales con clientes, además de los datos estructurados que leen Google y los asistentes de AI. Tras tu aprobación, Alex publica la página en tu sitio con un solo clic, incluido el marcado Service y LocalBusiness adecuado para tu caso.

Conclusión

Los schemas Service y LocalBusiness no son un detalle técnico menor. Determinan si Google y los asistentes de AI pueden interpretar correctamente tu página de servicios como un establecimiento, una oferta o ambas cosas. La regla es sencilla: LocalBusiness para indicar dónde estás, Service para explicar qué haces y, si tienes varias ubicaciones, cada una debe definirse por separado. Ignorarlo significa dejar escapar resultados enriquecidos y visibilidad en AI que están al alcance con ajustes relativamente pequeños.

Puedes leer más sobre el contenido que debe incluir una página de este tipo en qué debe incluir una página de servicios que convierta. ¿Prefieres no entrar en el código, pero quieres asegurarte de que tus páginas de servicios estén bien resueltas tanto a nivel técnico como de contenido? Reserva una consulta gratuita y descubre cómo Alex crea y publica páginas de servicios con los datos estructurados adecuados.

Sobre la empresa

Launchmind es el compañero de AI que escribe, revisa y publica contenido SEO cada día en tu propio blog, en 8 idiomas, y se ajusta continuamente con datos reales de Search Console. Alex también mejora páginas de servicios con respuestas directas, orientación de precios, procesos de trabajo, pruebas y los datos estructurados que leen Google y los asistentes de AI, para responsables de marketing, emprendedores y directores de marketing de pymes y empresas en crecimiento.