SEO local con LocalBusiness: guía técnica según Google Search Central

El SEO local no acaba en la ficha de Google: en tu sitio web puedes describir el negocio de forma que Google lo interprete con precisión. La documentación oficial de Google Search Central sobre Local Business structured data explica cómo usar Schema.org (habitualmente JSON-LD) para aportar nombre, dirección, horarios, coordenadas y más. No es magia de posicionamiento, pero es la forma “oficial” de alinear lo que publicas con lo que el buscador puede mostrar en contextos locales (por ejemplo un panel de conocimiento o, en algunos casos, formatos enriquecidos relacionados con el tipo de negocio).

Este artículo resume qué dice Google, qué marcar, qué evitar y cómo validarlo. Para la parte de Google Business Profile, categorías y reseñas en la ficha, enlaza con la guía práctica de SEO local y Google Business Profile. Para el contexto general de datos estructurados, con Schema.org y JSON-LD.

Objetivo: implementar LocalBusiness (o un subtipo) de forma compatible con las directrices generales de datos estructurados y las Search Essentials, sin sustituir una buena experiencia de usuario ni una ficha de negocio completa.

Qué aporta Google: contexto, no solo “una etiqueta más”

En la página oficial, Google explica que, cuando alguien busca negocios, los resultados pueden incluir un panel de conocimiento con detalles del que mejor encaja con la consulta, y que en búsquedas por tipo de negocio puede haber carruseles u otros formatos. Con LocalBusiness puedes comunicar horarios, departamentos dentro del mismo establecimiento, y otros datos; además, si quieres acciones como reservas en resultados, Google enlaza la documentación del Maps Booking API como vía aparte del marcado básico.

Traducción para el día a día: el JSON-LD no sustituye a contenido claro en HTML ni a una URL de ubicación que el usuario y el bot puedan rastrear; refuerza la señal y reduce ambigüedad entre “esta página es la de la tienda de X en Y”.

LocalBusiness y subtipos: sé específico

LocalBusiness está definido en schema.org/LocalBusiness. Google recomienda usar el subtipo más específico que encaje: por ejemplo Restaurant, DaySpa, HealthClub, etc., en lugar de quedarse solo en LocalBusiness genérico.

Si tu negocio combina actividades, la documentación permite expresar varios tipos como array en @type (por ejemplo Electrician, Plumber, Locksmith), indicando que additionalType no está soportado para este fin en la guía de Google.

Como LocalBusiness es subtipo de Organization, Google recomienda revisar también los campos útiles de Organization —por ejemplo coherencia de name, url, logo o señales que ayuden a desambiguar la entidad respecto a otras organizaciones homónimas.

Propiedades obligatorias y las que más importan

Según la tabla oficial de propiedades admitidas para LocalBusiness en Search Central:

• Requeridas: name y address (como PostalAddress). Cuanta más granularidad (calle, localidad, región, código postal, país), mejor calidad percibida para el usuario.
• Recomendadas destacadas: geo (latitud y longitud con al menos 5 decimales en la documentación), telephone (con prefijo de país y área), url de la ubicación concreta (enlace que funcione), openingHoursSpecification, priceRange (texto menor de 100 caracteres; si no, Google puede no mostrar rango de precio), department para sucursales o servicios internos con datos distintos, y campos propios de ciertos negocios (p. ej. menu o servesCuisine en restauración donde aplique).

Un ejemplo mínimo conceptual (no copies ciegamente: adapta tipos y datos reales):

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Clínica Ejemplo Centro",
  "url": "https://www.example.com/clinicas/madrid-centro",
  "telephone": "+34-91-000-00-00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Ficticia 12, Bajo A",
    "addressLocality": "Madrid",
    "addressRegion": "MD",
    "postalCode": "28001",
    "addressCountry": "ES"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.41678,
    "longitude": -3.70379
  }
}

La documentación enfatiza que puedes añadir el marcado en cualquier página, pero que tiene más sentido en páginas que describen de verdad ese negocio o esa ubicación.

Horarios: medianoche, 24 h y temporada

Google dedica ejemplos a horarios estándar, franjas que cruzan medianoche (un solo OpeningHoursSpecification), abierto 24 horas (opens 00:00, closes 23:59) y cerrado todo el día (ambos en 00:00). Para cierres estacionales o vacaciones, usa validFrom y validThrough en el bloque de horario.

Además, acepta tanto la notación canónica de dayOfWeek de schema.org (URLs del tipo https://schema.org/Monday) como la forma corta (Monday), y anticipa que la documentación puede actualizarse según evolucione el estándar.

Varios departamentos en el mismo local

Si compartes edificio pero tienes teléfono u horario distintos (farmacia dentro de un hipermercado, mostrador de atención, etc.), Google describe la propiedad department como una lista de elementos LocalBusiness anidados, definiendo en cada uno lo que difiera del establecimiento principal. Hay convenciones de nombre: por ejemplo incluir el nombre del centro y el del departamento (gMart y gMart Pharmacy), salvo que el departamento sea una marca reconocible por sí sola.

Reseñas en el marcado: lee la letra pequeña

Un error habitual es meter aggregateRating o review en la web del propio negocio pensando que “es lo mismo” que las estrellas de Maps. La documentación oficial es explícita: aggregateRating y review en LocalBusiness solo se recomiendan para sitios que publican valoraciones sobre otros negocios locales. Usar el marcado fuera de ese supuesto puede violar las directrices y exponerte a acciones manuales.

Para tu propio negocio, prioriza reseñas reales en Google Business Profile, contenido útil en la web y políticas honestas de solicitud de opinión —en línea con lo que ya comentamos en la guía de perfil.

Carruseles de restaurantes (alcance limitado)

La misma página documenta un carrusel de restaurantes con requisitos adicionales (imágenes en varias proporciones, propiedades de Carousel, etc.) y aclara que hoy está limitado a un conjunto reducido de proveedores y un formulario de interés para quien quiera participar. Útil saberlo para no prometer a un cliente un carrusel que depende de elegibilidad que no controlas desde el marcado solo.

Flujo de trabajo que Google describe (y tú puedes clonar)

La guía propone un orden claro:

1. Añadir las propiedades requeridas y las recomendadas que apliquen; si usas CMS o JS generando JSON-LD, sigue las secciones sobre formato y colocación y generación dinámica.
2. Cumplir Search Essentials, directrices generales de datos estructurados y, si aplica, las de carrusel.
3. Validar con la Rich Results Test y corregir errores críticos.
4. Usar Inspección de URLs en Search Console y comprobar que la página no esté bloqueada por robots.txt, noindex o un login obligatorio.
5. Tras publicar, solicitar rastreo si hace falta y tener paciencia: Google advierte que pueden pasar días hasta que se reindexe; un sitemap actualizado ayuda a mantener el ritmo de descubrimiento.

Esto conecta con buenas prácticas generales de rastreo e indexación: sin acceso limpio al HTML y al JSON-LD, el marcado no sirve.

Troubleshooting sin mitos

La documentación de solución de problemas recuerda varias verdades incómodas pero útiles:

• Google no garantiza que un tipo de resultado enriquecido aparezca siempre, aunque el marcado sea válido.
• Errores de sintaxis se pueden detectar en informes; spam de contenido o de marcado puede no aparecer en la prueba de rich results pero sí disparar penalizaciones.
• Una acción manual sobre datos estructurados puede hacer que Google ignore ese marcado en la página afectada.

Si algo deja de mostrarse, revisa cambios recientes en plantilla, consistencia NAP con la ficha y si el bot sigue viendo el mismo JSON-LD que tú en el navegador (especialmente en SPAs o renders condicionados).

Checklist práctico (SEO local + web)

1. Una URL clara por ubicación (o por negocio único) con datos visibles: dirección, teléfono clickeable, horario humano.
2. @type lo más específico posible; name y address reales y alineados con Google Business Profile y el footer.
3. geo con precisión adecuada, telephone internacional, url de la ubicación operativa.
4. openingHoursSpecification fiel a la realidad; especiales y festivos actualizados en web y ficha.
5. Sin reviews inventadas en JSON-LD; cumplimiento estricto de las guías de Google.
6. Validación (Rich Results + Search Console) y sitemap que incluya esas URLs.

Fuentes oficial

Para profundizar o citar en informes técnicos, usa siempre la documentación viva en Google:

• Local business (LocalBusiness) structured data
• Organization structured data
• Introducción a datos estructurados

Así mantienes el SEO local anclado a lo que Google publica para desarrolladores, no solo a intuiciones de la SERP.