Cómo hacer la web de un restaurante sin código, paso a paso
Para hacer la web de un restaurante sin código, describe la carta, el horario, la ubicación y cómo se reserva mesa. Zugo genera el sitio a partir de ese texto y lo publica con una dirección propia. Una sola página bien resuelta sale en torno a un minuto y cubre casi todas las consultas.
Aquí conviene resistirse a la ambición. La web de un restaurante compite con una búsqueda en el móvil a las nueve de la noche, y gana la que responde en cinco segundos, no la que tiene vídeo de fondo.
¿Qué busca alguien que abre la web de un restaurante?
Casi siempre está de pie, con poca batería y decidiendo entre dos sitios. Estas son las preguntas reales, por orden de frecuencia, y dónde deben estar resueltas.
| Pregunta | Dónde debe estar | Qué pasa si falta |
|---|---|---|
| ¿Estáis abiertos ahora? | Primera pantalla, con horario por días | Llama por teléfono o va al de al lado |
| ¿Qué tenéis y a qué precio? | Carta legible, sin descargar nada | Abandona antes de encontrar el PDF |
| ¿Dónde estáis exactamente? | Dirección con enlace que abre el navegador | Copia la dirección a mano o desiste |
| ¿Puedo reservar? | Botón visible en todas las secciones | Reserva en otro sitio que sí lo tiene |
| ¿Hay opciones para mí? | Marcas de vegetariano, sin gluten, alérgenos | Escribe para preguntar, o no viene |
| ¿Cómo es el local? | Cuatro fotos reales de sala y platos | Duda del sitio y elige uno que sí las tiene |
Las dos primeras filas resuelven más de la mitad de las visitas. Si tu web solo hiciera eso bien, ya sería mejor que la mayoría.
Un detalle que se pasa por alto: escribe el horario por días, incluido el día de cierre. La frase "abierto todos los días excepto lunes" evita más llamadas que cualquier otra línea del sitio.
¿Carta en la web o carta en PDF?
En la web, sin discusión. Un PDF obliga a descargar, se abre mal en el móvil, hay que hacer zoom para leer los precios y no lo entiende bien un buscador. La carta escrita como texto se lee de golpe y se puede actualizar en un minuto.
Estructura por secciones cortas: entrantes, principales, postres, bebidas. Cada plato con nombre, una línea de descripción cuando el nombre no basta y el precio a la derecha. Los alérgenos, marcados de forma simple y consistente.
Si tienes menú del día, ponlo arriba y con la fecha visible. Es lo que más se busca entre semana y lo que más rápido envejece: un menú del martes pasado hace dudar de todo lo demás que hay en la página.
Mantener la carta al día se hace con una edición por chat, 3 créditos, y una frase del tipo "sustituye la sección de postres por estos cinco". Si cambias de carta cada semana, conviene que la carta viva en una base de datos y actualizarla sea añadir filas, sin coste por cambio.
¿Qué prompt genera la web a la primera?
El generador acierta cuando nombras secciones, orden y acción principal. Escribe tu carta real dentro del prompt: los platos inventados hay que corregirlos uno por uno.
Crea la web del restaurante [nombre] en [ciudad],
cocina [tipo], en español.
Secciones en este orden:
1. Portada: nombre, una frase de qué cocina hacemos,
horario de hoy, botón "Reservar mesa" y teléfono.
2. Carta: secciones [entrantes, principales, postres,
bebidas] con nombre, descripción corta, precio y
marcas de alérgenos.
3. Menú del día: precio, qué incluye, días y horario.
4. Fotos: 6 imágenes de sala y platos.
5. Reservas: formulario con fecha, hora, número de
personas, nombre, teléfono y observaciones.
6. Dónde estamos: dirección, mapa, transporte,
horario completo por días y teléfono.
Tono cálido y sencillo, fotos grandes, pensado
primero para móvil.
La línea final no es un adorno. La mayoría del tráfico de un restaurante llega desde el teléfono, y pedir explícitamente que se diseñe primero para móvil evita la web preciosa en portátil donde el botón de reservar queda debajo de tres pantallas de scroll.
¿Cómo se gestionan las reservas?
Hay dos niveles y el sencillo funciona mejor de lo que la gente espera. Un formulario de solicitud que llega por correo, con Resend conectado, resuelve el caso de un restaurante que confirma por teléfono.
El nivel avanzado es una agenda con disponibilidad real por turnos y mesas, que necesita base de datos para impedir que dos personas cojan el mismo hueco. Esa lógica, incluido el problema de las reservas simultáneas, está desarrollada en la guía de sitios con reservas.
Elige según el volumen. Si recibes cinco reservas al día, el formulario más una llamada de confirmación cuesta menos esfuerzo y da más control sobre la sala. Si recibes cincuenta, la agenda deja de ser un lujo.
Sea cual sea el nivel, comprueba el circuito antes de publicar: envía una reserva de prueba y verifica que el aviso llega a la cuenta de correo que se abre en el turno, no a una dirección que nadie mira. Una reserva perdida es una mesa vacía y una reseña mala.
¿Cuánto cuesta la web y qué plan hace falta?
El plan gratuito da 5 créditos, suficientes para ver la primera versión publicada antes de gastar nada. Pro cuesta $25 al mes con 200 créditos e incluye conectar tu dominio. Business son $99 al mes.
Las acciones tienen precio fijo: generar cuesta 6 créditos, editar cuesta 3 y un sitio de varias páginas se cobra como plataforma, 12 créditos por las tres primeras páginas y 3 por cada página adicional.
Un restaurante se resuelve muy bien con una sola página larga: 6 créditos y todo a un scroll de distancia. Si prefieres carta, reservas y contacto separados, son 12 créditos por las tres primeras páginas. Cambiar la carta de temporada, 3 créditos.
El modo Hi-Fi duplica ambas cifras, 12 la generación y 6 la edición. En hostelería conviene gastarlo en la portada y en las fotos, que es donde se decide la mesa. La comparación de coste con otras vías está en cuánto cuesta una web hecha con IA.
El sitio queda publicado en una dirección del tipo turestaurante.zugo.run, que puedes poner hoy mismo en el perfil de Instagram, y el dominio propio se conecta después sin rehacer nada.
¿Qué hay que comprobar antes de publicar?
Cinco comprobaciones, todas desde el teléfono y con datos móviles, no con el wifi del local.
El horario de hoy se ve sin desplazarse. Es la consulta número uno y tiene que estar en la primera pantalla.
El teléfono se marca con un toque. Si hay que copiarlo a mano, la mitad de las llamadas no se hacen.
La dirección abre el navegador. Un mapa que no se abre en la aplicación de mapas es un mapa decorativo.
Los precios de la carta no se cortan. El error más común en móvil, y se ve en tres segundos.
El formulario de reserva llega de verdad. Envíate una reserva y espera el correo. Zugo arranca cada proyecto en un entorno aislado antes de entregarlo, así que una compilación rota no llega a tus manos, pero que el correo aterrice donde tú quieres solo lo confirmas tú.
¿Dónde se queda corto un generador de IA aquí?
Cuatro límites honestos.
El reparto con zonas y repartidores es otro producto. Mapa de cobertura, franjas de entrega y seguimiento del pedido forman un sistema completo, no una sección más.
No se conecta con tu TPV ni con el stock. Una carta que sabe que se acabó el pulpo requiere conexión con la caja o el almacén, y eso es integración a medida.
Los pedidos para llevar con cobro se construyen, pero por partes. Stripe cubre el pago; el flujo de horarios de recogida, límites por franja y avisos a cocina se afina con ediciones sucesivas.
Los textos de alérgenos son responsabilidad tuya. Las obligaciones varían por país y un generador escribe redacciones verosímiles, no verificadas. Revísalos con quien lleve la seguridad alimentaria.
Para el caso normal, un local que necesita carta legible, horario claro, mapa y reservas que llegan, la web se resuelve en una tarde. Si vendes sobre todo café y bollería con otro ritmo de visita, la estructura cambia y está en la guía de cafetería. Puedes empezar con los créditos gratuitos en zugo.dev.