Según datos de Semrush de 2025, el 67% de los sitios con schema LocalBusiness lo tienen con errores de validación o propiedades incompletas. Eso incluye negocios que creen que tienen el markup bien configurado porque pasaron un validador hace dos años. El schema no es una tarea de una sola vez: los horarios cambian, el teléfono puede actualizarse, y cada vez que el GBP se edita hay que verificar que el JSON-LD sigue siendo coherente.
Schema LocalBusiness es un vocabulario estandarizado que le dice a los motores de búsqueda exactamente qué eres, dónde estás, cuándo abres y a qué te dedicas, en un formato que una máquina procesa sin ambigüedad. Cuando Google rastrea tu página y encuentra ese bloque de JSON-LD, no tiene que inferir si tu número es el de la sede o de la sucursal, ni si el horario del sábado difiere del resto de la semana. Los datos están ahí, estructurados, verificables.
Las páginas con schema LocalBusiness completo tienen un 30% más de probabilidad de aparecer en el Knowledge Panel de Google, según BrightLocal 2025. Los negocios que combinan un schema robusto con un GBP bien optimizado no solo compiten mejor en el Local Pack: también mejoran su visibilidad ante los motores de IA generativa que usan datos estructurados como señal de confianza al construir respuestas.
Esta guía explica por qué cada propiedad existe, qué ocurre cuando la omites y cómo verificar que tu implementación funciona. Si ya tienes schema LocalBusiness, probablemente encontrarás aquí cosas que estás haciendo de forma subóptima. Si aún no lo tienes, tendrás una hoja de ruta clara.
Qué es el schema LocalBusiness y por qué importa ahora
Schema.org es un vocabulario colaborativo creado en 2011 por Google, Microsoft, Yahoo y Yandex con un propósito muy concreto: proporcionar un lenguaje común para describir entidades en la web de forma procesable por máquinas. Dentro de ese vocabulario, LocalBusiness es el tipo diseñado para describir negocios con presencia física: una peluquería en Gijón, un despacho de abogados en Madrid, un restaurante en Barcelona.
Lo que distingue a LocalBusiness de otros tipos de schema es su énfasis en los datos geoespaciales y horarios. Mientras que un Article schema se preocupa por la autoría y la fecha de publicación, LocalBusiness necesita saber exactamente dónde está el negocio (hasta latitud y longitud), cuándo atiende al público y cómo contactar con él. Esa especificidad geográfica es lo que lo convierte en la pieza técnica central del SEO local.
El timing de esta implementación importa más de lo que parece. En el ecosistema actual de búsqueda, Google no actúa solo. Los motores de IA generativa como ChatGPT Search, Perplexity y Google Gemini responden cada vez más consultas locales: “mejor dentista en el barrio de Eixample”, “talleres mecánicos abiertos los domingos en Sevilla”. Estos modelos extraen información de múltiples fuentes, y los datos estructurados son, literalmente, los que más fácil procesan. Un negocio con schema LocalBusiness bien construido ya está hablando el idioma que estos motores entienden.
El proceso técnico funciona así: cuando Googlebot rastrea tu página y encuentra un bloque JSON-LD de tipo LocalBusiness, lo extrae, lo valida contra las especificaciones de schema.org y lo agrega a su grafo de conocimiento. Ese grafo de conocimiento es la fuente que alimenta el Knowledge Panel, el Local Pack y, cada vez más, las respuestas de AI Overviews. La coherencia entre tu schema, tu Google Business Profile y el contenido visible de tu web refuerza todas estas señales simultáneamente.
Un dato que suele sorprender a los profesionales SEO que conocen el tema de pasada: Google extrae automáticamente datos del schema LocalBusiness para completar y verificar la información del Google Business Profile. Eso significa que si tu horario en el GBP difiere del schema, Google tiene que decidir cuál creer. Si coinciden, la señal de confianza se amplifica.
Formato JSON-LD: la única opción que tiene sentido
Schema.org puede implementarse en tres formatos: JSON-LD, Microdata y RDFa. En teoría, los tres son equivalentes en cuanto a capacidad de expresión. En la práctica, JSON-LD ha ganado la batalla hace tiempo, y Google ha dejado de ser ambiguo al respecto: su documentación oficial recomienda explícitamente JSON-LD como el formato preferido.
¿Por qué JSON-LD frente a Microdata? Porque JSON-LD es un bloque de código independiente que vive en el <head> de la página, completamente separado del HTML visible. Puedes actualizar los datos estructurados sin tocar el diseño. Puedes añadir propiedades complejas con objetos anidados sin que el marcado HTML se convierta en un laberinto. Y puedes validarlo de forma aislada con herramientas automáticas.
La estructura básica de un JSON-LD LocalBusiness tiene siempre tres elementos indispensables:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Nombre del Negocio"
}Eso es lo mínimo técnicamente válido. También es lo mínimo inútil. Un schema con solo esos tres campos no le dice nada a Google que no pudiera inferir del título de la página. El valor real empieza cuando añades las propiedades que los motores de búsqueda no pueden deducir por sí solos.
El nesting complejo es una de las capacidades de JSON-LD que Microdata gestiona con torpeza. Por ejemplo, para especificar horarios diferentes cada día de la semana con openingHoursSpecification, necesitas un array de objetos con @type: OpeningHoursSpecification. En Microdata, eso requiere marcado HTML anidado que entorpece el mantenimiento. En JSON-LD, es un array limpio en el script, invisible para el usuario, completamente estructurado para la máquina.
(Un aparte técnico que vale la pena mencionar: muchos desarrolladores confunden JSON-LD LocalBusiness con el atributo itemscope de Microdata porque ambos aparecen en páginas de negocios locales. Son cosas distintas. Si encuentras itemtype="https://schema.org/LocalBusiness" en el HTML de tu página de forma heredada, no es incorrecto, pero migrar a JSON-LD te dará mejor compatibilidad con las herramientas de validación actuales y más facilidad de mantenimiento.)
Propiedades obligatorias vs. recomendadas: dónde está el valor real
Google clasifica las propiedades del schema LocalBusiness en dos categorías según su documentación oficial: requeridas y recomendadas. La distinción importa porque las propiedades requeridas son necesarias para que el schema sea elegible para resultados enriquecidos, mientras que las recomendadas son las que marcan la diferencia entre un schema funcional y uno que realmente impulsa tu visibilidad.
Las propiedades requeridas por Google para LocalBusiness son tres: @type, name y address. Sin estas, el validador te devolverá errores críticos. La dirección, a su vez, debe seguir el tipo PostalAddress con los subcampos adecuados.
Pero donde está el verdadero potencial es en las propiedades recomendadas. Aquí no hay que elegir: implementa todas las que apliquen a tu negocio.
telephone — Siempre en formato internacional con prefijo de país. Para España, +34 91 234 56 78, nunca 91-234-56-78 ni 91 234 56 78. Los motores de búsqueda y los sistemas de marcado automático de teléfonos necesitan el formato E.164.
openingHoursSpecification — Es una de las propiedades más frecuentemente mal implementadas. La propiedad openingHours (singular) acepta strings simplificados como "Mo-Fr 09:00-18:00", pero openingHoursSpecification permite definir horarios especiales para festivos o días concretos con objetos anidados. Si tu negocio tiene un horario de verano, cierra los festivos regionales catalanes o tiene horario reducido los sábados, la especificación detallada te da control total que la versión simplificada no puede expresar.
geo — Latitud y longitud del negocio. Esto parece redundante si ya tienes la dirección, pero no lo es. La dirección es un texto que Google tiene que geocodificar (convertir a coordenadas). Las coordenadas directas eliminan ese paso intermedio y reducen la posibilidad de errores de geocodificación, especialmente en negocios en polígonos industriales, centros comerciales o edificios con múltiples entradas. Usa las coordenadas del mismo punto que tienes en Google Maps, no las del centro del edificio calculadas automáticamente.
priceRange — Una a cuatro $ para indicar el rango de precios. Simple pero efectivo para respuestas a consultas con filtro de precio (“restaurantes baratos en Valencia”).
url — URL absoluta de la página principal del negocio. No el dominio: la URL completa con https://.
image — URL de una imagen representativa. Usa una imagen de calidad que muestre el negocio, el equipo o el producto principal.
aggregateRating — Si tienes sistema de valoraciones propio en tu web, puedes incluir la valoración media y el número de valoraciones. No confundas esto con las valoraciones de Google Maps (que Google gestiona directamente) ni intentes falsificar datos aquí: Google verifica la coherencia.
Los más de 100 subtipos de LocalBusiness: elige el correcto
Una de las capacidades más infrautilizadas del schema LocalBusiness es su jerarquía de subtipos. Schema.org no define un solo tipo genérico para todos los negocios: define más de 100 especializaciones que van desde Restaurant hasta DentalClinic, pasando por AutoRepair, LegalService, Hotel, Pharmacy, RealEstateAgent y decenas más.
Esta distinción no es cosmética. Cuando Google sabe que tu negocio es de tipo Dentist (subtipo de MedicalBusiness, que a su vez es subtipo de LocalBusiness), puede asociarlo con consultas específicas del sector dental, aplicar los criterios de evaluación propios del sector sanitario (incluyendo E-E-A-T reforzado para YMYL) y potencialmente mostrarlo en fragmentos enriquecidos específicos para profesionales médicos.
Usar LocalBusiness genérico cuando deberías usar Restaurant es como registrar una empresa en el epígrafe fiscal incorrecto: técnicamente válido, pero con consecuencias en cómo te categoriza el sistema.
La jerarquía funciona así: puedes usar varios @type simultáneamente para capturar múltiples clasificaciones. Un restaurante japonés en Barcelona podría definir:
{
"@context": "https://schema.org",
"@type": ["Restaurant", "FoodEstablishment"],
"servesCuisine": "Japanese",
"name": "Nombre del Restaurante"
}Los subtipos relevantes para los sectores más comunes en España:
- Hostelería y restauración:
Restaurant,Bar,Bakery,CafeOrCoffeeShop,Hotel,BedAndBreakfast - Salud:
Dentist,Optician,Pharmacy,Physiotherapist,VeterinaryCare - Servicios profesionales:
LegalService,AccountingService,FinancialService,InsuranceAgency - Automoción:
AutoRepair,AutoDealer,CarWash - Comercio:
ClothingStore,ElectronicsStore,HomeGoodsStore,BookStore - Belleza y cuidado personal:
BeautySalon,HairSalon,SpaOrHealthClub,NailSalon
Consulta la jerarquía completa en schema.org/LocalBusiness para encontrar el tipo más específico que describe tu negocio. Cuanto más preciso sea el tipo, más relevante resulta el schema para consultas específicas de tu sector.
Implementación paso a paso: el JSON-LD completo
Teoría aparte, veamos cómo se traduce todo esto en código concreto. El siguiente ejemplo corresponde a un despacho de abogados en Madrid, un caso que ilustra bien las propiedades más complejas:
{
"@context": "https://schema.org",
"@type": "LegalService",
"name": "Bufete García & Asociados",
"url": "https://www.bufetegarcia.es/",
"telephone": "+34 91 555 12 34",
"email": "[email protected]",
"image": "https://www.bufetegarcia.es/images/oficina-bufete.jpg",
"description": "Despacho de abogados especializado en derecho mercantil y laboral en Madrid, con más de 20 años de experiencia y 500 clientes empresariales.",
"priceRange": "€€€",
"address": {
"@type": "PostalAddress",
"streetAddress": "Calle Serrano 45, 3º izquierda",
"addressLocality": "Madrid",
"addressRegion": "Madrid",
"postalCode": "28001",
"addressCountry": "ES"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 40.4238,
"longitude": -3.6886
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
"opens": "09:00",
"closes": "19:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Friday",
"opens": "09:00",
"closes": "15:00"
}
],
"areaServed": {
"@type": "City",
"name": "Madrid"
},
"sameAs": [
"https://www.linkedin.com/company/bufete-garcia-asociados",
"https://goo.gl/maps/example"
],
"hasMap": "https://goo.gl/maps/example",
"currenciesAccepted": "EUR",
"paymentAccepted": "Cash, Credit Card, Bank Transfer"
}Algunas notas sobre este ejemplo. La propiedad areaServed es especialmente valiosa para negocios de servicios que atienden a clientes más allá de su ubicación física (un abogado no atiende solo a clientes que entran por la puerta). La propiedad sameAs vincula el schema con perfiles verificables en otras plataformas, reforzando las señales de autoridad. Y hasMap conecta directamente con la ficha de Google Maps, facilitando la correlación de datos.
Para negocios con múltiples ubicaciones, cada página de sucursal debe tener su propio bloque JSON-LD independiente. No uses el mismo schema con @id duplicado en todas las páginas: es uno de los errores que Google detecta y que erosiona la confianza en el conjunto del schema de tu dominio.
Errores comunes que anulan el schema
El espacio entre implementar schema y implementarlo bien es donde se pierde la mayor parte del valor. Estos son los errores más frecuentes que encuentro al auditar sitios web de negocios locales:
- Horarios en formato incorrecto:
openingHours: "L-V 9:00-18:00"no es válido. Google requiere los días en inglés y el formato de 24 horas:"Mo-Fr 09:00-18:00". Parece un detalle menor, pero el validador lo marca como error y el dato queda descartado. - Teléfono sin prefijo internacional:
"91 234 56 78"provoca ambigüedad en el procesamiento automatizado. Usa siempre"+34 91 234 56 78". - Coordenadas del centro del municipio en lugar del negocio: Muchos generadores automáticos de schema insertan las coordenadas del centro de la ciudad si no encuentran las del negocio específico. Si tu
geoapunta al centro de Barcelona pero tu negocio está en Sarrià, la señal geoespacial es incorrecta. - Schema que no refleja los datos del GBP: Si el horario en tu schema dice que abres los domingos pero tu Google Business Profile indica que estás cerrado, Google debe decidir qué creer. Esta incoherencia reduce la confianza en ambas fuentes. El schema y el GBP deben ser siempre idénticos en los datos de contacto y horarios.
- URL relativa en lugar de absoluta:
"url": "/contacto"no es válido. Siempre"url": "https://www.tudominio.es/contacto/". - Tipo genérico cuando existe uno específico: Usar
"@type": "LocalBusiness"para una clínica dental cuando"Dentist"existe y aporta más contexto semántico. - No actualizar el schema tras cambios: Un negocio que cambia su horario en verano pero no actualiza el JSON-LD estará enviando datos incorrectos durante meses. Integra la revisión del schema en cualquier proceso de cambio de datos del negocio.
Herramientas de validación y comprobación
Antes de dar por buena una implementación, necesitas validarla con herramientas que no se equivocan. Google ofrece dos: el Rich Results Test y el Schema Markup Validator. Son complementarias, no intercambiables.
El Rich Results Test (search.google.com/test/rich-results) evalúa si tu schema es elegible para tipos específicos de resultados enriquecidos en Google Search. Para LocalBusiness, te dice si el schema está correctamente implementado para potenciar el Knowledge Panel y los resultados locales. Muestra errores críticos (que impiden la elegibilidad) y advertencias (que reducen el potencial pero no lo anulan).
El Schema Markup Validator (validator.schema.org) valida la sintaxis JSON-LD contra las especificaciones formales de schema.org, independientemente de si Google lo usa para resultados enriquecidos. Es útil para detectar errores de tipado, propiedades desconocidas o estructuras de anidamiento incorrectas.
La herramienta de Merkle (technicalseo.com/tools/schema-markup-generator/) es útil para generar el JSON-LD inicial si estás empezando desde cero. Te guía por un formulario y produce el código, aunque deberás revisar el output porque los generadores automáticos cometen errores con frecuencia en propiedades complejas como openingHoursSpecification.
Para validación masiva en sitios con múltiples páginas de ubicación, herramientas como Screaming Frog pueden rastrear el sitio y extraer todos los bloques de datos estructurados para análisis en conjunto.
Una verificación adicional que suele pasarse por alto: después de publicar el schema, accede a Google Search Console y revisa el informe de “Mejoras” en la sección de “Experiencia en la página”. Google tarda entre unas horas y varios días en procesar el schema nuevo, pero el informe te mostrará si hay errores o advertencias activos en páginas indexadas.
Schema LocalBusiness y los motores de IA generativa
El impacto del schema LocalBusiness no se limita ya al ecosistema de búsqueda tradicional de Google. Los motores de IA generativa que responden consultas sobre negocios locales utilizan datos estructurados como señal de confianza al construir respuestas.
Cuando ChatGPT Search o Perplexity rastrean una página web en busca de información sobre un negocio local, el procesamiento de JSON-LD es más eficiente que el análisis de texto plano. Un bloque de schema LocalBusiness con nombre, dirección, teléfono, horarios y coordenadas le dice al modelo exactamente lo que necesita saber sin ambigüedad. El texto de la página puede ser ambiguo (“abrimos de lunes a viernes” sin especificar horas); el schema no lo es.
Según datos de BrightLocal de 2025, los negocios con schema LocalBusiness completo reciben un 20% más de clics en resultados orgánicos locales, y ese efecto se amplifica en el contexto de las respuestas de IA, donde la fuente con datos más estructurados y verificables tiene ventaja competitiva al ser seleccionada para la respuesta.
Hay una propiedad de schema LocalBusiness que cobra especial relevancia para los motores de IA: areaServed. Esta propiedad permite definir el área geográfica a la que sirve el negocio, ya sea como ciudad, región, país o un radio geográfico con GeoCircle. Para los LLMs que responden consultas como “servicios de fontanería en toda la provincia de Málaga”, un negocio con areaServed correctamente definido tiene una señal explícita que los modelos pueden procesar directamente.
La propiedad makesOffer y hasOfferCatalog permiten estructurar los servicios o productos del negocio en formato procesable por máquinas. Un restaurante que define sus platos con Offer y MenuItem le está dando a los motores de IA los ingredientes para responder consultas muy específicas sobre su oferta. Un estudio de Semrush de 2025 identificó que los negocios con schema de servicios detallado tenían un 35% más de menciones en respuestas de AI Overviews para consultas de nicho comparados con negocios con schema básico.
Para una perspectiva más amplia sobre cómo los datos estructurados funcionan como puente entre el SEO clásico y la optimización para motores generativos, te recomendamos la guía sobre schema.org y SEO/GEO, que explora los tipos de schema más relevantes para la visibilidad en IA.
Mantenimiento y ciclo de vida del schema
Una implementación de schema LocalBusiness no es un trabajo de una sola vez. Es una capa de datos viva que debe mantenerse sincronizada con la realidad del negocio.
Los eventos que requieren actualización inmediata del schema incluyen: cambio de horario (incluido horario de verano o festivos), cambio de dirección o número de teléfono, apertura o cierre de sucursales, cambio de nombre comercial y modificación de la gama de servicios. Cada vez que actualizas la ficha de Google Business Profile, comprueba si el schema correspondiente necesita la misma actualización.
Una práctica recomendada para equipos de marketing o agencias que gestionan múltiples clientes: crear una hoja de control con todos los campos del schema LocalBusiness, los valores actuales y la fecha de última verificación. Revisar esta hoja trimestralmente toma menos de 30 minutos por cliente y evita que se acumulen incoherencias que erosionen la confianza de los motores de búsqueda.
Para webs construidas con CMS como WordPress, los plugins de SEO como Yoast o RankMath gestionan el schema LocalBusiness desde el panel de administración. La ventaja es la facilidad de actualización; el riesgo es que estos plugins generan un schema genérico que puede no incluir todas las propiedades que necesitas. Verifica siempre el output con el Rich Results Test, independientemente del plugin que uses.
Para proyectos más técnicos, como sitios construidos con Astro u otros frameworks modernos, crear un componente dedicado que genere el JSON-LD dinámicamente desde una única fuente de datos (un archivo de configuración o las variables de entorno) es la aproximación más robusta. Cambias los datos en un solo lugar y el schema se actualiza automáticamente en todas las páginas relevantes.
El schema LocalBusiness tiene retorno medible, pero solo cuando la implementación está completa y se mantiene actualizada. Un schema parcial o desactualizado no es neutral: genera inconsistencias que Google y los motores de IA interpretan como señales de poca fiabilidad. La revisión trimestral que cuesta 30 minutos por cliente es la que evita que los rich results desaparezcan en silencio tras una actualización de plataforma.
Para el contexto estratégico completo, la guía de SEO local explica cómo este schema encaja con el resto de factores de ranking y qué priorizar primero.