Restaurant vs LocalBusiness: cómo marcar con Schema.org cocinas fantasma y marcas virtuales múltiples

Por qué este problema es distinto al de un restaurante tradicional

Un restaurante con una sola marca, una dirección y un comedor tiene una relación uno a uno entre negocio y local. Las cocinas fantasma y los operadores multi-marca rompen esa relación: una sola cocina física puede producir para tres, cinco o más marcas de delivery, cada una con nombre, menú y presencia en apps distintas, pero comparten el mismo edificio, el mismo horario operativo de cocina y, muchas veces, el mismo número de teléfono de soporte. El marcado estructurado no tiene una regla explícita para este escenario, por lo que la implementación queda a criterio del operador, siempre dentro del vocabulario que Schema.org define para el tipo Restaurant.

Restaurant y LocalBusiness según Schema.org

Según la definición de Schema.org, Restaurant es un tipo de entidad dentro de la jerarquía de LocalBusiness, orientado a negocios que sirven comida. La documentación no condiciona su uso a que exista atención en sala, reservas o un mostrador de recogida: describe la categoría del negocio, no su modelo de servicio. Esto significa que una marca de delivery puro puede marcarse legítimamente como Restaurant si ese tipo describe con precisión lo que el negocio es, sin necesidad de "bajar" a LocalBusiness genérico por considerarlo más prudente.

La guía de Google sobre datos estructurados de LocalBusiness, por su parte, explica qué propiedades pueden ayudar a que un negocio aparezca representado en ciertas experiencias de búsqueda, pero no garantiza que el marcado produzca una función visual específica. Esa distinción es clave para todo lo que sigue: elegir el tipo correcto y las propiedades correctas es una cuestión de precisión descriptiva, no una palanca de visibilidad garantizada.

Marco de decisión: la Verificación de Cuatro Preguntas

Para operadores con múltiples marcas virtuales operando desde una o varias cocinas, proponemos un marco de cuatro preguntas que se recorre por cada marca antes de publicar su marcado:

1. ¿Qué entidad describe este bloque de marcado? Defina si el JSON-LD representa la marca (por ejemplo, "Tacos del Barrio") o el local físico operativo (la cocina compartida). Cada marca virtual normalmente necesita su propio bloque, con su propio name, aunque comparta dirección con otras.
2. ¿Qué tipo describe con precisión esta entidad? Si la marca sirve alimentos, Restaurant es aplicable exista o no atención presencial. Use LocalBusiness genérico solo si el tipo Restaurant no describe con exactitud lo que ese negocio hace (por ejemplo, si es una marca de repostería que no encaja en las subcategorías de servicio de alimentos disponibles).
3. ¿Qué propiedades son ciertas, y cuáles no aplican? Revise campo por campo: acceptsReservations debe omitirse o marcarse como falso si la marca no acepta reservas; menu o hasMenu deben apuntar al menú real de esa marca, no al menú combinado de la cocina; openingHoursSpecification debe reflejar el horario en que esa marca específica recibe pedidos, que puede diferir del horario general de la cocina.
4. ¿La dirección física queda representada una sola vez de forma inequívoca? Si cinco marcas comparten una dirección, decida si se necesita una entidad LocalBusiness separada para el local físico (con sus propias coordenadas y teléfono operativo) a la que cada marca se pueda relacionar, o si basta con que cada marca incluya la misma dirección de forma consistente, dejando claro en el name y la descripción que se trata de un concepto de producción compartida y no de un comedor independiente por marca.

Tabla de referencia rápida por escenario

Cómo evitar duplicar o tergiversar el local físico

El riesgo más frecuente no es elegir el tipo equivocado, sino que campos de dirección idénticos en múltiples entidades de marca generen la impresión de que existen varios locales de atención al público donde solo hay una cocina de producción. Algunas prácticas razonables:

• Use la descripción textual de cada entidad para aclarar el modelo de servicio ("marca de delivery producida en cocina compartida", por ejemplo), en lugar de dejar que el tipo o la dirección hagan esa distinción por sí solos.
• Si el operador mantiene un sitio o perfil que represente el local físico como tal, considere si conviene una entidad separada para ese local, distinta de las entidades de cada marca, en lugar de fusionar ambos roles en un solo bloque de datos.
• Revise que el horario declarado por cada marca corresponda a cuándo esa marca acepta pedidos, no al horario general de funcionamiento de la cocina, que puede ser más amplio.

Limitaciones que hay que tener presentes

Este marco ayuda a estructurar decisiones, pero no resuelve automáticamente la representación en cada plataforma de descubrimiento o entrega, cuyas reglas de agregación de datos son propias de cada servicio y no están definidas por Schema.org. Tampoco existe en la documentación de Schema.org una regla explícita y oficial para el caso específico de múltiples marcas en una sola dirección; lo aquí propuesto es una interpretación razonable del vocabulario existente, no una norma publicada por Schema.org para ghost kitchens. Además, ni Schema.org ni la guía de Google sobre LocalBusiness garantizan que un marcado correctamente implementado se traduzca en una aparición visual específica en buscadores o en enlaces de pedido o reserva.

Cómo medir si el marcado está b

Flujo de implementación paso a paso

Antes de publicar marcado para varias marcas virtuales, conviene seguir un orden de trabajo que evite errores de duplicación una vez que el sitio o los perfiles ya están en producción:

1. Inventariar todas las marcas activas y la o las direcciones físicas desde las que produce cada una.
2. Asignar a cada marca un bloque JSON-LD independiente, incluso si varias comparten plantilla de página.
3. Completar únicamente las propiedades de Schema.org que sean verificables para esa marca (menú propio, horario de aceptación de pedidos propio).
4. Revisar que ninguna propiedad quede copiada por defecto desde otra marca sin verificar si sigue siendo cierta (un horario, un teléfono o un menú).
5. Publicar y, antes de dar por cerrado el trabajo, releer el bloque como lo haría alguien externo a la operación, verificando si sugiere sin querer que existen locales de atención independientes.
6. Repetir la revisión cuando se agregue, pause o retire una marca, ya que el marcado no se actualiza solo cuando cambia la operación real.

Árbol de decisión para casos límite

El marco de cuatro preguntas ya descrito cubre el caso típico de un operador con marcas propias en una cocina propia. Existen configuraciones adicionales, frecuentes en el sector de cocinas fantasma, que requieren una rama de decisión distinta:

• ¿La instalación es de un único operador o es una instalación multi-inquilino?
  • Si un solo operador controla todas las marcas: aplica el marco ya descrito, marca por marca.
  • Si la instalación alquila espacio de cocina a operadores independientes: cada operador debe publicar su propio marcado bajo su propia entidad Restaurant o LocalBusiness. La empresa que administra la instalación no debe representar a esos inquilinos dentro de su propia entidad a menos que sea ella misma quien preste el servicio de alimentos descrito.
• ¿La marca rota entre distintas cocinas físicas a lo largo del tiempo?
  • Si la dirección de producción cambia, el bloque debe actualizarse en ese mismo momento; de lo contrario queda describiendo un local en el que la marca ya no opera.
• ¿La marca es temporal o estacional (pop-up virtual)?
  • Al dar de baja la marca, conviene retirar o marcar como inactivo su bloque, en lugar de dejar publicada una entidad que ya no corresponde a un negocio en funcionamiento.

Qué se puede medir y qué no

La verificación de este tipo de marcado es principalmente un ejercicio de auditoría interna, no de medición de resultados de búsqueda:

Limitaciones adicionales en instalaciones multi-inquilino

Cuando varios operadores independientes comparten una misma instalación, ninguno de los dos controla por completo cómo una plataforma de terceros combina o muestra esa dirección compartida; la guía de Google sobre LocalBusiness explica qué propiedades son relevantes para el negocio descrito, pero no cubre cómo cada agregador de delivery decide agrupar o separar direcciones idénticas.

Nota sobre el alcance de ChefNet

Este artículo describe cómo interpretar el vocabulario de Schema.org y la guía de Google para datos estructurados; no describe funciones específicas de ChefNet. ChefNet se encuentra desarrollando productos de descubrimiento y operación para restaurantes, y los operadores deben verificar directamente con el equipo de ChefNet qué capacidades de marcado o gestión multi-marca están activas en el momento de su implementación, en lugar de asumir soporte automático para escenarios de cocina fantasma.

Fuentes primarias

• Schema.org Restaurant
• Google: LocalBusiness structured data

FAQ

Divulgación editorial: ChefNet publica esta guía y desarrolla productos para el descubrimiento y las operaciones de restaurantes. Las recomendaciones operativas generales se separan de las afirmaciones sobre el producto. Las funciones pueden cambiar durante los programas piloto. Publicado 2026-08-12.