Schema de negocio local: guía de implementación

Un negocio local existe en dos versiones para quien lo busca en internet: la que un visitante lee en la página —un párrafo de "sobre nosotros", un horario en el pie de página, un teléfono en la cabecera— y la que un motor de búsqueda puede leer sin tener que interpretarla. El schema de negocio local, la marcación LocalBusiness del vocabulario de schema.org, existe para cerrar esa distancia: en vez de que un rastreador infiera la dirección a partir de una frase suelta o adivine el horario leyendo un texto libre, el markup declara esos datos en un formato que una máquina procesa de forma directa y sin ambigüedad.

Eso es, literalmente, todo lo que hace: declarar hechos verificables sobre el negocio en un formato estructurado. No es un truco de posicionamiento ni un atajo para aparecer en el mapa de resultados locales. Es información, y su valor depende de que sea correcta, de que sea lo bastante específica y —el punto que sostiene el resto de este artículo— de que sea coherente con lo que ya se dice del negocio en cualquier otro lugar donde aparece.

Qué declara realmente el markup y dónde vive

El schema de negocio local se implementa casi siempre como un bloque de datos en formato JSON-LD insertado en el código de la página. Es un objeto separado del texto visible: el visitante nunca lo ve, pero cualquier sistema que procese la página puede leerlo sin interpretar lenguaje natural. Dentro de schema.org, LocalBusiness combina dos herencias: toma de Organization los atributos propios de una entidad comercial —nombre, sitio web, identidad— y de Place los atributos propios de una ubicación física —dirección, coordenadas. Esa doble herencia es lo que lo distingue de un schema de Organization genérico, pensado para negocios sin una sede física relevante para quien busca.

Conviene tratarlo como una ficha de hechos, no como una pieza de contenido: no lleva narrativa ni argumentos de venta. Lleva un nombre, una dirección, un horario y un puñado de propiedades más, cada una con un formato esperado. Cuanto más se parezca a una hoja de datos y menos a un texto persuasivo, mejor cumple su función.

Las propiedades que realmente importan

No todas las propiedades de LocalBusiness pesan igual. Hay un núcleo pequeño que vale la pena completar con cuidado; el resto es opcional o específico de un tipo de negocio concreto.

Un campo vacío no es grave: es una pregunta sin responder. Un campo con un valor incorrecto sí lo es, porque deja de ser ausencia de información y pasa a ser información falsa.

• name: el nombre exacto del negocio, tal como aparece en la fachada y en el resto de tus perfiles, sin variaciones de marketing.
• address: la dirección postal completa como campos separados —calle, localidad, código postal, región, país—, no como una sola cadena de texto.
• telephone: el número que realmente se usa para llamar, idealmente con el prefijo de país.
• geo: latitud y longitud del local físico, útiles cuando la dirección textual deja margen de duda.
• openingHoursSpecification: el horario real de atención, día por día, no uno aproximado ni el que tenía el negocio hace dos años.
• priceRange: una indicación del nivel de precio, no un dato inventado para parecer más accesible o más premium de lo que es.
• url: la dirección de la página propia a la que corresponde ese schema, no la portada de un directorio ni la de otra sucursal.
• sameAs: enlaces a los perfiles del mismo negocio en otras plataformas —su ficha de Google Business Profile, sus redes— que confirman que se trata de la misma entidad vista desde varios lugares.

Elige el tipo más específico que exista, no el genérico

LocalBusiness no es un tipo único: es el techo de una familia de decenas de subtipos más concretos. Un restaurante puede marcarse como Restaurant, una cafetería como CafeOrCoffeeShop, una clínica dental como Dentist, un taller mecánico como AutoRepair, una inmobiliaria como RealEstateAgent. Cada subtipo hereda todo lo de LocalBusiness y añade propiedades propias de su categoría: un restaurante puede declarar el tipo de cocina que sirve; una clínica, la especialidad que atiende.

Usar el subtipo correcto en vez del genérico no cambia el formato básico, pero sí cuánta información precisa se transmite. Declarar una peluquería como LocalBusiness a secas cuando existe HairSalon es quedarse corto sin necesidad. Cuando ningún subtipo describe bien el negocio, la salida correcta es LocalBusiness genérico y, si hace falta, additionalType para acercarse a la categoría real. Forzar el subtipo equivocado solo porque suena más específico reintroduce el problema central de este artículo: una discrepancia entre lo que el schema afirma y lo que el negocio realmente es.

La coherencia es lo que sostiene todo el schema

Aquí está el punto que importa más que cualquier lista de propiedades: el markup tiene que decir exactamente lo mismo que la página donde vive, lo mismo que tu perfil de negocio en Google y lo mismo que cualquier otro listado donde aparezcas. No parecido. Lo mismo.

Piensa en el caso más común: el schema declara que el negocio cierra a las 22:00, el pie de página de la propia web dice 20:00, y el perfil de negocio dice 21:00. Ningún sistema tiene forma de saber cuál de los tres es real, y la conclusión razonable no es "confían en el más reciente": es que el negocio, como fuente sobre sí mismo, no es confiable. Lo mismo pasa con un teléfono distinto en el schema y en el encabezado, o con un código postal en el markup que no coincide con el del texto visible. Cada discrepancia, sola, parece un detalle menor. El problema es que rara vez aparecen solas: cuando un dato se desactualiza en un sitio y no en otro suele ser porque nadie tiene la tarea de mantenerlos sincronizados, y el patrón se repite en cada dato que cambia con el tiempo.

Esto es lo que hace que datos contradictorios sean peores que datos ausentes. Un campo vacío es una pregunta sin responder; un campo que contradice a otro es una respuesta que no se puede usar, y que además pone en duda las demás. Un motor de búsqueda no tiene por qué resolver ese conflicto a tu favor: la consistencia entre tu sitio, tu perfil de negocio y tus listados externos —lo que suele llamarse coherencia de nombre, dirección y teléfono— es la base sobre la que se sostiene la utilidad de todo lo demás que hayas marcado.

La forma práctica de sostener esto es tratar el schema como parte del mismo cambio que actualiza la página, no como una tarea aparte para después. Si el horario cambia en el mostrador, cambia también en el markup, en el pie de página y en el perfil de negocio, en el mismo momento.

Negocios con varias sucursales: una página por ubicación

Cuando el negocio tiene más de un local, el error habitual es crear una sola página de "nuestras sucursales" marcada con los datos de todas a la vez, o apilar varios bloques de LocalBusiness en una misma URL, cada uno con su propia dirección. El resultado es una página sin respuesta clara a "¿de qué lugar físico habla esta URL?", porque habla de varios a la vez.

La estructura que funciona es la contraria: cada sucursal tiene su propia página, con su propia dirección, teléfono, horario y coordenadas marcadas ahí y solo ahí. Una página general de sucursales puede seguir existiendo como índice, enlazando a cada una, pero no necesita cargar ella misma el markup de ninguna ubicación particular; su función es de directorio, no de representar un lugar físico.

Esto no es solo cuestión de orden: una página por ubicación permite que cada sucursal acumule su propia identidad como entidad local, y facilita justo lo que exige la sección anterior —es más simple mantener coherentes el horario, el teléfono y la dirección de una sucursal con su propio espacio dedicado que con doce datasets apretados en la misma página.

Horarios especiales: el punto donde casi todos fallan

El horario regular, día por día con su hora de apertura y cierre, es la parte fácil. Donde casi todos se equivocan es en los dos casos que no encajan en ese patrón.

El primero son los festivos: Navidad, Año Nuevo, fechas locales con horario reducido o cierre total. Necesitan su propio bloque de horario para esa fecha concreta, distinto del horario semanal, porque de lo contrario el schema sigue diciendo que el negocio abre un 25 de diciembre a la hora de siempre, cuando en realidad está cerrado.

El segundo son los horarios partidos: un negocio que cierra al mediodía y reabre por la tarde no puede representarse con un único bloque de apertura y cierre para ese día, porque ese formato no puede expresar una interrupción en medio. Necesita dos especificaciones distintas para el mismo día, una por tramo.

El patrón detrás de ambos fallos es el mismo: el schema se configuró una vez, cuando reflejaba la realidad del negocio, y nadie volvió a tocarlo cuando esa realidad cambió por temporada o festivo. La corrección no es técnica, es de responsabilidad: quien decide el horario de un festivo en el mostrador tiene que ser también quien actualiza el markup.

Qué logra este markup y qué no

El schema de negocio local ayuda a que la información se entienda de forma directa, sin depender de que un sistema interprete correctamente un texto libre, y puede ser condición para que ciertas presentaciones enriquecidas de esa información sean posibles. Eso es real y vale la pena hacerlo bien.

Lo que no hace, y conviene decirlo con claridad porque circula la idea contraria, es producir por sí mismo una posición en el paquete de resultados del mapa local. Esa posición depende de señales de proximidad respecto a quien busca, de relevancia para la consulta y de prominencia del negocio, ninguna de las cuales cambia porque se añada un bloque de JSON-LD a la página. Cualquier artículo que prometa que instalar este markup mejora por sí solo el posicionamiento en el mapa describe una relación que no existe. El schema es un requisito de claridad, no una palanca de ranking.

Validar el markup y mantenerlo vivo

Validar el schema antes de darlo por terminado es un paso simple que se salta con frecuencia: existen herramientas gratuitas —como el test de resultados enriquecidos y el validador de schema markup— que comprueban que el código tiene el formato correcto y que las propiedades obligatorias están presentes. Vale la pena correrlas cada vez que se toca el markup, no solo la primera vez.

Pero hay que ser realista sobre lo que valida una herramienta así: confirma que el JSON está bien formado, no que los datos dentro sean ciertos. Un bloque válido con un teléfono que ya no existe pasa la validación sin ningún aviso, porque la herramienta no sabe que el negocio se mudó el mes pasado.

Por eso validación técnica y revisión de contenido son tareas distintas y hacen falta las dos. La validación se corre después de cada cambio. La revisión de que los datos siguen siendo ciertos conviene hacerla en un calendario aparte —por ejemplo cada trimestre— para detectar el desajuste que se acumula en silencio cuando el horario cambió, el negocio se mudó o cambió de teléfono y el schema se quedó como el día que se escribió.