Respuesta directa: marcar tu menú con Schema.org no garantiza un resultado enriquecido en buscadores. Lo que sí puedes controlar es que cada propiedad relevante —menu, hasMenuItem, offers, price, priceCurrency, suitableForDiet— esté presente, bien formada y coherente con lo que un cliente ve en tu sitio. Esta auditoría propone un proceso de cuatro pasos para revisar tu marcación antes de pedir una reindexación, en lugar de reindexar a ciegas y esperar resultados.
Por qué auditar antes de reindexar
Cuando un resultado enriquecido de menú no aparece —o desaparece— es tentador solicitar de inmediato la reindexación de la página. Pero reindexar una página con marcación incompleta simplemente le pide al buscador que vuelva a leer el mismo error. Antes de ese paso, conviene verificar de forma sistemática qué propiedades de Restaurant definidas en schema.org/Restaurant están realmente presentes en tu HTML y si sus valores son válidos según ese vocabulario.
Es importante distinguir esto de otros temas relacionados: esta auditoría no trata sobre qué tan legible es tu menú para respuestas generadas por IA, ni sobre el cumplimiento de campos de LocalBusiness como horarios o dirección. Se enfoca exclusivamente en las propiedades de menú dentro del tipo Restaurant y su relación con la elegibilidad para resultados enriquecidos tradicionales de búsqueda.
El marco: Checklist de Auditoría de Menú en Cuatro Pasos
Este es el marco práctico que proponemos —la Checklist de Auditoría de Datos Estructurados de Menú para Resultados Enriquecidos— organizado en cuatro pasos secuenciales.
- Paso 1 — Verificar la estructura raíz. Confirma que el tipo principal declarado sea
Restauranty que incluya la propiedadmenu, apuntando a un objetoMenuo a una URL de menú válida. - Paso 2 — Revisar hasMenuItem. Dentro del objeto
Menu, verifica quehasMenuItemliste correctamente cadaMenuSectionoMenuItem, sin secciones vacías ni referencias rotas. - Paso 3 — Validar precios y moneda. Cada
MenuItemcon precio debe tener un bloqueoffersconpriceypriceCurrencyconsistentes con lo que se muestra visualmente al cliente. - Paso 4 — Confirmar el uso opcional de suitableForDiet. Solo donde exista información dietética verificada, revisa que se use la enumeración
RestrictedDietcorrectamente, sin generalizar platillos.
Tabla de propiedades a revisar
| Propiedad | Ubicación esperada | Qué verificar |
|---|---|---|
| menu | Restaurant | Apunta a un Menu válido o a una URL de menú accesible |
| hasMenuItem | Menu / MenuSection | Lista MenuSection o MenuItem sin entradas huérfanas |
| name | MenuItem | Coincide con el nombre visible del platillo |
| offers / price | MenuItem | Valor numérico coherente con el precio mostrado |
| priceCurrency | offers | Código de moneda válido (por ejemplo, MXN, USD) |
| suitableForDiet | MenuItem | Uso opcional, solo con información verificada |
Errores frecuentes que impiden la elegibilidad
No existe una única causa universal de fallo en la elegibilidad de resultados enriquecidos de menú; cada sitio tiene su propia combinación de errores según su plataforma, plantilla y proceso de actualización de contenido. Dicho esto, al auditar la estructura conviene prestar atención a patrones técnicos comunes:
- El menú vive solo como imagen o PDF, sin ningún marcado en HTML ni en JSON-LD.
- La propiedad
hasMenuItemapunta a secciones que ya no existen en la página visible. - Los precios en
offersno se actualizan al mismo ritmo que los precios reales del menú impreso o digital. - Se usa
suitableForDietde forma genérica en todo el menú sin verificación por platillo.
Limitaciones de esta auditoría
Es necesario ser claros sobre lo que este proceso puede y no puede lograr. Corregir la marcación de menú resuelve un requisito técnico de elegibilidad, pero no controla si un producto de búsqueda decide mostrar un resultado enriquecido, ni con qué frecuencia, ni en qué posición. Tampoco garantiza que aparezcan enlaces de reserva dentro de un resultado de búsqueda: los datos estructurados expresan hechos verificables sobre tu menú, pero no obligan por sí solos a ningún producto de búsqueda a mostrar esos enlaces. Además, las propiedades descritas en schema.org/Restaurant son vocabulario disponible, no una lista obligatoria; un restaurante puede tener una marcación técnicamente válida usando solo un subconjunto de estas propiedades. Esta auditoría tampoco evalúa señales de calidad de contenido para respuestas generadas por IA ni aspectos legales del etiquetado dietético, que exceden el alcance de la corrección técnica de marcación.
Cómo medir el resultado de la auditoría
Para dar seguimiento objetivo a esta auditoría, sin prometer resultados de tráfico o posicionamiento, es útil llevar un registro simple antes y después de cada corrección:
- Documenta, propiedad por propiedad, cuáles estaban ausentes o mal formadas antes de la corrección.
- Registra la fecha en que se corrigió cada propiedad en el código fuente.
- Verifica con una herramienta de validación de datos estructurados que el objeto
Restauranty suMenupasen sin errores de sintaxis. - Anota si, tras la corrección, solicitaste reindexación y en qué fecha, sin asumir un resultado específico ni un plazo garantizado.
Este registro sirve como evidencia interna de qué se cambió y cuándo, útil para diagnósticos futuros, sin convertirse en una promesa de aparición en resultados enriquecidos.
Dónde encaja ChefNet en este proceso
ChefNet está desarrollando productos de descubrimiento y operación de restaurantes, y este tipo de auditoría de propiedades de menú es el tipo de trabajo técnico que un operador puede necesitar como parte de su presencia en buscadores. Si tu equipo utiliza o evalúa herramientas de ChefNet para gestionar tu menú o tu ficha de restaurante, verifica directamente con el equipo de producto qué capacidades de marcación estructurada están disponibles actualmente y cuáles se encuentran en desarrollo, en lugar de asumir que una función específica ya existe.
Flujo de implementación cuando el menú vive en múltiples plantillas
Muchos restaurantes no tienen una sola página de menú, sino varias plantillas (menú de comida, menú de bebidas, menú de temporada, página por sucursal). Aplicar la checklist a una sola página y asumir que el resto está igual es un error común. El flujo recomendado es el siguiente:
- Haz un inventario de todas las plantillas o URLs que contienen algún
Menumarcado, no solo la página principal de "Menú". - Aplica los cuatro pasos de la checklist a una muestra representativa de cada plantilla, no solo a la primera que encuentres.
- Si el sitio usa un sistema de gestión de contenido, verifica si la marcación se genera desde una plantilla central o si cada página la define manualmente; esto determina si una corrección se propaga automáticamente o debe repetirse página por página.
- Registra en qué plantilla se corrigió cada propiedad, para poder auditar de nuevo si el CMS cambia de versión o plantilla en el futuro.
Casos límite que la checklist básica no resuelve por sí sola
Además de los cuatro pasos generales, existen situaciones específicas donde la aplicación directa del vocabulario de Restaurant no es obvia. Documentarlas evita decisiones improvisadas al momento de marcar el menú.
| Caso | Problema típico | Tratamiento recomendado |
|---|---|---|
| Platillo sin precio fijo ("precio según mercado") | El campo price queda vacío o con un valor inventado | Omitir offers/price para ese ítem antes que inventar una cifra; documentar la ausencia como decisión intencional |
| Combos o promociones temporales | El MenuItem del combo no refleja los componentes individuales | Marcar el combo como un MenuItem propio, sin duplicar precios de los platillos que lo componen por separado |
| Menú de temporada que se retira periódicamente | hasMenuItem sigue listando secciones ya eliminadas del sitio | Incluir la actualización o eliminación de secciones estacionales como parte del calendario de mantenimiento de la marcación |
| Restaurantes con varias sucursales y un menú compartido | Todas las sucursales heredan el mismo Menu aunque los precios varíen por ubicación | Verificar si cada sucursal necesita su propio bloque offers con precios locales en lugar de un único precio genérico |
| Menú multilingüe | El name del MenuItem no coincide entre la versión visible en cada idioma y la marcación | Auditar cada versión de idioma por separado; no asumir que corregir una versión corrige las demás |
Métricas técnicas adicionales para dar seguimiento a la auditoría
Más allá del registro simple de fechas de corrección descrito antes, conviene llevar métricas técnicas que no dependen de si aparece o no un resultado enriquecido:
- Número de errores de sintaxis reportados por una herramienta de validación de datos estructurados, comparado entre la auditoría inicial y la posterior a las correcciones.
- Proporción de
MenuItemconoffers/pricecompleto frente al total de ítems listados enhasMenuItem. - Número de discrepancias encontradas entre el precio visible al cliente y el valor declarado en
price, por plantilla.
Límite de las herramientas de validación
Una herramienta de validación de datos estructurados puede confirmar que la sintaxis del Restaurant y su Menu es correcta, pero no puede confirmar que los precios o la información dietética declarada sean veraces, ni que un producto de búsqueda vaya a mostrar un resultado enriquecido con esa marcación. Pasar la validación sin errores es una condición necesaria dentro de este proceso de auditoría, no una confirmación de elegibilidad ni de aparición en resultados de búsqueda.
Fuentes primarias
FAQ
¿Agregar marcación de menú con Schema.org garantiza que aparezca un resultado enriquecido?
No. Los datos estructurados expresan hechos sobre tu menú en un vocabulario legible por máquinas, pero que un producto de búsqueda muestre un resultado enriquecido depende de las reglas de elegibilidad propias de ese producto, algo que el operador no controla. Una marcación correcta elimina una barrera técnica, no obliga a ninguna plataforma a renderizar una función específica.
¿Qué propiedad de Schema.org debe listar los platillos individuales?
La propiedad menu del tipo Restaurant puede apuntar a un Menu, que a su vez usa hasMenuItem para listar entradas de tipo MenuSection o MenuItem. Cada MenuItem debería incluir su propio name y, cuando corresponda, un bloque offers con price y priceCurrency, según el vocabulario disponible en schema.org/Restaurant.
¿Es obligatorio usar suitableForDiet en cada platillo?
No es obligatorio. suitableForDiet es vocabulario opcional para describir restricciones dietéticas como vegetariano o sin gluten mediante la enumeración RestrictedDiet. Los operadores deberían aplicarlo solo cuando exista información precisa y verificada, ya que las afirmaciones dietéticas pueden implicar responsabilidades legales y de seguridad que van más allá de la corrección técnica de la marcación.
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-02.