Detrás de
Brasa & Oliva.
Estrategia, decisiones de diseño y estado verificable de la implementación.
1. Estrategia
Brasa & Oliva presenta una cocina contemporánea al fuego para parejas, grupos pequeños y profesionales. El recorrido responde tres preguntas: qué propone, qué se puede comer y cómo solicitar una mesa. Dos CTA principales llevan a una carta legible en HTML y a un formulario breve. No se usan reseñas, premios ni señales de demanda inventadas.
2. Concepto visual
«El fuego nos reúne». Identidad de campo contemporánea: bordó apagado (#653b3c), madera oscura (#3b2c21), arena (#e9dabf) y detalles tostados. Fondos con veta vectorial, paneles cálidos, sello circular y un grabado de llama y rama. Tipografía Barlow Condensed en títulos con peso 700/800 y Manrope para lectura, ambas servidas localmente con sus licencias OFL. Texto principal de 18 px; descripciones de carta de 17–18 px; títulos y controles ampliados. Se conserva la portada en video, el movimiento con pausa y las preferencias de movimiento reducido.
3. Sitemap
Inicio → Carta / Nuestra cocina / Galería / Reservas / Contacto. Soporte: Aviso legal, Privacidad, Créditos, esta documentación y página 404. Recursos técnicos: sitemap.xml y robots.txt.
4. Investigación SEO y matriz por URL
Consulta realizada el 17 de octubre de 2026. Como no se proporcionó ciudad, se utilizó Buenos Aires / Palermo exclusivamente como mercado de referencia. Esa ubicación no se atribuye a Brasa & Oliva. Consultas exploradas: «restaurante Buenos Aires», «cocina a las brasas Buenos Aires», «reservar restaurante Palermo» y cocina de estación. Se revisaron resultados de búsqueda y sitios oficiales. No hay datos de Search Console, Keyword Planner ni herramientas de volumen o dificultad.
| Referencia local | Observación comprobable | Aplicación a la demo |
|---|---|---|
| Fogón | Organiza su propuesta como experiencias al fuego, con reservas y preguntas frecuentes. | Explicar la propuesta y el proceso de solicitud antes de pedir datos. |
| Tomate | Comunica cocina de estación; la carta enlaza a Drive y las reservas a Meitre. | Hipótesis de oportunidad: una carta nativa en HTML evita salir del sitio para leer platos y precios. |
| Casa Cavia | Conecta gastronomía, arquitectura y producto estacional en su relato. | Vincular ambiente y cocina con fotografías y texto específico. |
Estas son referencias que aparecieron en la investigación, no un ranking exhaustivo ni competidores confirmados de un negocio que todavía no existe. La oportunidad de una carta HTML y una solicitud breve es una inferencia de diseño, pendiente de validación con usuarios y métricas.
| URL | Keyword / intención propuesta | CTA |
|---|---|---|
| / | cocina al fuego · descubrimiento. Para un negocio real: restaurante [ciudad confirmada]. | Explorar carta / Reservar mesa |
| /carta/ | carta Brasa & Oliva · menú y precios. Hipótesis: cocina a las brasas [ciudad]. | Elegí tu próximo encuentro |
| /nuestra-cocina/ | cocina de estación · propuesta y diferenciación | Reservar mesa |
| /galeria/ | ambiente Brasa & Oliva · inspección visual de referencia | Ampliar fotografía |
| /reservas/ | reserva Brasa & Oliva · intención transaccional. Hipótesis: reservar restaurante [barrio]. | Simular solicitud de reserva |
| /contacto/ | ubicación y contacto Brasa & Oliva · intención local pendiente | Probar Reservas desde preguntas frecuentes |
| /aviso-legal/, /privacidad/, /creditos/, /proyecto/ | información de soporte · sin objetivo de captación local | Navegación contextual |
Cada página incluye título, descripción y H1 únicos, canonical propio, Open Graph e imagen social. El contenido y los enlaces están en el HTML de origen. La demo incluye noindex,follow para evitar que un restaurante ficticio compita como negocio real; robots permite rastreo y referencia el sitemap. Activar indexación solo al pasar a producción con datos reales. No se publica schema Restaurant/LocalBusiness, AggregateRating, dirección ni horario comercial ficticio.
Google Business Profile: trabajo separado
No se creó ni verificó una ficha. Para una actividad real: confirmar elegibilidad, nombre comercial, categoría, dirección, zona, horarios y teléfono; verificar el negocio; incorporar carta y fotografías autorizadas; mantener consistencia de esos datos y medir visitas con enlaces etiquetados. No se deben generar reseñas ficticias. Validar keywords con datos locales antes de definir la campaña SEO.
5. Implementación
Descargar código y documentación
Stack: HTML estático multipágina, CSS y JavaScript nativos. Generador Python sin dependencias para compartir layout, contenido y metadatos. Es apropiado para una demo editorial sin backend: HTML rastreable, navegación normal, poco JavaScript, fuentes locales y despliegue portable.
Estructura: config.json contiene origen y estado demo; build.py compone las 11 vistas; report-content.html mantiene esta documentación; dist/ es el sitio completo; dist/assets/ contiene CSS, lógica de interacción, fotografías WebP en 640/1200/1800 px, imagen OG y fuentes de las imágenes. check.py y tests/ prueban la integridad y la lógica de reservas. README.md explica ejecución y publicación. No hay secretos ni credenciales en el código.
Reservas: validación de fecha real, rango de 90 días, horario de muestra, turnos pasados en Buenos Aires, cantidad entre 1 y 8, nombre, correo, teléfono opcional, comentarios y reconocimiento de simulación. Errores por campo, resumen accesible y foco en el primer error. Confirmación simulada con resumen, edición y reinicio. Los datos se insertan con textContent; no se transmiten ni persisten.
Medios y rendimiento: fotografías WebP locales con srcset y sizes; prioridad alta solo para imagen principal, lazy loading en las secundarias, cajas de imagen con tamaño estable y sin solicitudes a proveedores de fuentes durante la visita. Core Web Vitals objetivo: LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1 en p75. No hay una medición de campo disponible, por lo que no se afirma cumplimiento.
6. QA y estados
| Elemento | Estado | Alcance |
|---|---|---|
| Rutas, header, footer y página 404 | Implementado | Vistas HTML reales; comprobación automática de archivos y enlaces internos. |
| Carta, categorías y precios | Implementado | 30 platos/bebidas; filtros por categoría; carta completa disponible sin JS. Pedido demo con cantidades, total y resumen para copiar. |
| Video y animaciones | Implementado | Loop local de 10 segundos, sin audio, pausa manual, imagen de respaldo y preferencias de movimiento reducido. 751.433 bytes. |
| Pedido desde la carta | Simulado | Agregar y quitar productos, total en ARS, límite por producto, vaciado y ticket copiable. No envía pedidos ni realiza pagos. |
| Galería ampliable | Implementado | Dialog nativo, cierre y restauración del foco. Fotografías identificadas. |
| Formulario y resumen | Simulado | Valida datos localmente. No consulta disponibilidad ni genera reservas reales. |
| Motor de reservas y notificaciones | Requiere integración | Backend, validación en servidor, disponibilidad, idempotencia y pruebas de envío. |
| WhatsApp y Maps | Requiere integración | Sin enlaces falsos: faltan teléfono y dirección verificados. |
| Accesibilidad y responsive | Implementado · probado en navegador | Breakpoints desde 320 px, etiquetas, foco, enlace de salto, menú móvil, reduced motion y estados de error. Verificados menú móvil, Escape y restauración de foco. Auditoría WCAG 2.2 AA completa pendiente. |
| SEO técnico | Implementado | H1, metadatos únicos, canonical, sitemap, robots, OG y alt. Indexación intencionalmente desactivada para la demo. |
| Privacidad y seguridad | Implementado · alcance demo | Sin scripts de seguimiento ni envíos del formulario. Configuración de cabeceras incluida; efectividad sujeta al hosting. |
| Spam, persistencia y mensajes | Requiere integración | No aplica al formulario local. Antes de conectar backend: límites por IP, honeypot, validación servidor y protección de endpoints. |
| Analítica de conversiones | Requiere integración | No se activó. Eventos propuestos: view_menu, booking_start, booking_error y booking_request, con configuración y consentimiento adecuados. |
Pruebas ejecutadas y límites
V3: nueva paleta y fondos de madera, tipografías locales y aumento de tamaños. Comprobación de recursos locales y contraste sobre los colores base; revisión visual en escritorio y móvil. En 320 px: cuerpo y descripciones de carta 18 px, títulos de platos 34 px y diálogo de pedido 290 px sin desborde. En pantallas compactas se usa menú desplegable con enlaces grandes.
V2: los 28 controles automáticos pasaron. Se verificaron en navegador la reproducción del video, pausa/reanudación, filtros, agregado de platos, modificación de cantidades, totales, resumen, copiado, vaciado y devolución del foco al cerrar. Carta y pedido sin desbordes horizontales a 320 px. Se excluyeron de las entradas animadas los controles de platos para que no se desplacen al pulsarlos.
Controles ejecutados: generación de 11 páginas; 11 títulos, descripciones y H1 únicos; revisión de 249 enlaces internos y de recursos; sintaxis JavaScript; 28 pruebas de validación y resumen aprobadas de reservas en DOM simulado y aritmética pura de pedidos. Cero errores en esos controles.
Probado en el sitio desplegado: portada de escritorio y CTA a Carta; filtro de postres; formulario vacío y foco en el primer error; solicitud completa, edición y reinicio; menú móvil, Escape y devolución de foco; galería con apertura, cierre y restauración de foco. A 320 px se comprobaron Inicio, Carta, Nuestra cocina, Galería, Reservas, Contacto y esta documentación sin desborde horizontal. También se comprobaron Inicio a 390 px y Carta a 768 y 1440 px. Una ruta inexistente mostró la 404 diseñada. Las consultas de consola realizadas no mostraron errores ni advertencias.
La vista previa administrada no arrancó por una restricción de infraestructura; se pudo verificar la versión desplegada con el navegador conectado. No se ejecutó una auditoría completa de lector de pantalla, WCAG 2.2 AA ni Lighthouse; no hay métricas de campo de Core Web Vitals. La efectividad de las cabeceras y el código HTTP de 404 siguen pendientes de una comprobación HTTP autenticada.
7. Para convertirla en un restaurante real
- Confirmar titular, ciudad, domicilio, teléfono, correo y horario de atención.
- Reemplazar el relato y las fotografías de muestra por contenido autorizado del negocio.
- Validar recetas, precios vigentes, alérgenos, medidas de cocina y políticas de atención.
- Conectar una recepción real de pedidos (backend, stock, modalidades y precios) antes de ofrecer envíos o cobros. El ticket actual es únicamente local.
- Conectar motor de reservas con validación servidor, disponibilidad, notificaciones, cancelaciones y prevención de spam. Probar credenciales y endpoints de punta a punta.
- Revisar avisos legales y privacidad con los tratamientos reales; configurar consentimiento y medición cuando corresponda.
- Definir dominio; actualizar origin, canonical, sitemap y OG; verificar cabeceras y 404; habilitar indexación solo después de quitar datos ficticios.
- Realizar QA visual, teclado y lector de pantalla; auditoría automatizada de accesibilidad y mediciones Lighthouse y de campo antes de afirmar cumplimiento.
- Validar keywords locales y configurar por separado Google Business Profile cuando el negocio sea elegible.
8. Ejecución, GitHub y Vercel
El sitio desplegado en Sites es privado inicialmente. No se creó un repositorio en tu cuenta de GitHub ni un despliegue en Vercel. El código queda versionado en el repositorio fuente de este Site; las siguientes instrucciones permiten reutilizarlo.
python3 build.py python3 check.py node --test tests/booking.test.cjs tests/order.test.cjs python3 -m http.server 8080 --directory dist
Abrí http://localhost:8080. El servidor de ejemplo sirve archivos estáticos y no consulta datos externos. Para probar el código de error 404 de producción, usá el hosting final: el servidor Python muestra su propia respuesta para rutas inexistentes.
GitHub
Creá un repositorio privado vacío en tu cuenta. Usá un checkout separado o cambiá el remote con cuidado para no interferir con el repositorio administrado por Sites. No incluyas .openai en el repositorio externo ni compartas credenciales.
git init git add build.py asset-metadata.json config.json report-content.html README.md QA.md \ check.py package.json tests dist .gitignore vercel.json export-source.py git commit -m "Add Brasa & Oliva restaurant demo" git branch -M main git remote add origin <URL_DEL_REPOSITORIO> git push -u origin main
Vercel
Importá ese repositorio. Elegí preset Other, sin comando de instalación ni build, y directorio de salida dist (los archivos ya están generados). Para cambios, ejecutá build.py y subí dist actualizado. Añadí la configuración vercel.json incluida para cabeceras y cleanUrls. Actualizá config.json con el dominio definitivo y regenerá el sitio antes de publicar. Probá una ruta inexistente: debe responder HTTP 404 con la página diseñada. No hay endpoints ni variables secretas necesarias para la demo. El video se sirve como archivo MP4 desde dist/assets y requiere que el hosting admita media-src self.