design+code
La web de un restaurante tiene una sola función. Alguien tiene hambre, está con el móvil y quiere tres respuestas rápidas: qué servís, si hay mesa y cómo se llega. Todo lo demás viene después. Este es el orden en el que trabajamos en los proyectos de restaurantes, y estas son las cosas por las que hemos dejado de pelear.
Pon la carta en la página como texto HTML, con platos y precios que se puedan seleccionar y copiar. Google puede indexar un PDF, pero un PDF se abre en otro visor, se amplía mal en el móvil y a un buscador o a un asistente de IA le cuesta más citarlo cuando alguien pregunta qué se sirve en un sitio. Además, en texto un precio se cambia en treinta segundos, sin tener que preparar un nuevo archivo maquetado. Si te encanta tu carta impresa, mantenla como descarga, no como la carta.
El botón de reserva va en la cabecera, y otra vez donde se toma la decisión: después de la carta, junto a la dirección. Una sola etiqueta, un solo destino. Si usas una herramienta de reservas, enlázala o intégrala directamente en lugar de mandar a la gente a una página que a su vez la manda a la herramienta. Si solo aceptas reservas por teléfono o por email, dilo con claridad junto al número. Comparamos las principales herramientas en Zenchef, SevenRooms o Tock y analizamos lo que le cuesta cada una a un restaurante francés en TheFork, OpenTable o Zenchef.
Ni en una imagen ni solo en el pie de página. El horario es el dato más consultado en la web de un restaurante. Escríbelo una vez, en un único sitio, para que un cambio de temporada o un día de cierre sea una sola modificación y no pueda contradecirse de una página a otra.
La gente quiere ver dónde se va a sentar y qué va a comer. Las fotos reales de ambas cosas funcionan mejor que las imágenes de banco. Comprímelas, ajústalas al tamaño del móvil y dale a cada una un texto alternativo que describa lo que aparece. Una imagen de cabecera de varios megas es una de las razones más habituales por las que la web de un restaurante va lenta.
Google documenta un tipo de datos estructurados para negocios locales, restaurantes incluidos. Según su documentación, el nombre y la dirección son obligatorios. Recomienda servesCuisine, menu (la URL completa de la carta), openingHoursSpecification, priceRange, telephone, url y geo. Son unas pocas líneas de JSON-LD que dicen lo mismo que tu página ya muestra, en un formato que las máquinas leen sin tener que adivinar. No garantiza ningún resultado concreto en la Búsqueda, así que tómalo como higiene, no como un truco.
Nombre, dirección, horario y teléfono deberían ser idénticos en la web, en tu Perfil de Empresa de Google, en tu herramienta de reservas y en las redes sociales. Cuando no coinciden, un buscador o un asistente tiene que elegir uno, y puede quedarse con el equivocado. Revísalos una vez por trimestre y cada vez que cambies el horario.
Una animación de entrada o un vídeo a pantalla completa retrasan las tres respuestas que el visitante ha venido a buscar. Un blog solo merece la pena si alguien lo va a mantener vivo: un restaurante con el horario correcto y sin sección de noticias gana a uno con un blog abandonado. Una navegación ingeniosa tampoco ayuda. Carta, Reservar, Ubicación y horario, Eventos privados y Contacto suele ser suficiente. Una tipografía a medida solo compensa si la carta sigue siendo legible en el móvil. Y un restaurante con un único local rara vez necesita más de unas pocas páginas.
Estos son los puntos que revisamos en los proyectos de restaurantes y hostelería, entre ellos Maison Mayane en París, Double Dimanche en Hossegor y The Green Clerkenwell en Londres, del grupo The Culpeper Family. En esos tres nos encargamos de la integración en Webflow y del trabajo de SEO y GEO. El diseño es de Studio Avenir.
Si todavía estás eligiendo herramienta de reservas, empieza por nuestra guía de sistemas de reservas. Si ya tienes una y el problema es la web que la rodea, ese es el trabajo que hacemos.