Cuándo Rehacer el Sitio Web de Tu Restaurante: Un Framework de Decisión

Read this article in English →

El operador con dos cotizaciones para el mismo rebuild — una por $24,000 y otra por $7,000, ninguno de los dos desarrolladores le preguntó qué estaba realmente roto — no está realmente preguntando cuál cotización tomar. Está preguntando si rehacer del todo. Esa es la pregunta más difícil, y casi nadie ayuda a los operadores a responderla.

La respuesta honesta es que la mayoría de los restaurantes independientes rehace su sitio 12–24 meses tarde — para cuando el rebuild cuesta más (porque hay más que migrar), toma más tiempo (porque el embudo de reservas ya empeoró), y el operador toma la decisión bajo presión en lugar de bajo planeación.

Este es el diagnóstico de siete preguntas que recorro antes de recomendar un rebuild — o, igual de seguido, recomendar contra uno y apuntar a tres cambios chicos que compran otro año.

Pregunta 1: ¿Cómo puntúa en Storefront Health?

Corre Storefront Health sobre tu sitio. La calificación compuesta enrolla velocidad, SEO, mobile, schema, GBP, y la Restaurant Audit en un solo número, 0–100. El gráfico de arriba mapea las bandas. El camino barato: una sub-puntuación por debajo del resto suele estar a un arreglo puntual de devolver el compuesto al verde.

Pregunta 2: ¿Tu CMS puede actualizarse sin romper el sitio?

Las instalaciones viejas de CMS acumulan deuda técnica como los ductos acumulan polvo. La prueba: ¿cuándo fue la última vez que alguien intentó actualizar la plataforma? Si la respuesta es “no lo hacemos, porque la última vez se rompió,” eso es señal de rehacer.

Pregunta 3: ¿El menú vive en HTML?

Si tu menú es un PDF, una imagen, o “manejado por el widget de menú de Wix,” eres invisible para las queries a nivel de plato de Google y para la búsqueda con IA. Cambiar a un menú HTML real a veces basta para postergar un rebuild — a veces requiere uno.

Pregunta 4: ¿Cómo puntúa el sitio en Core Web Vitals?

Si LCP está arriba de 4 segundos en mobile, o CLS está arriba de 0.25, te están penalizando en búsqueda Y rebotando visitantes antes de que cargue el menú. A veces un CDN + compresión de imágenes lo arregla; a veces la plataforma es el problema y solo un rebuild lo resuelve.

Corre Speed Test sobre la home y la página interior más visitada. Si la home es rápida pero la página de menú es lenta, la plataforma no es el problema — la página sí. Si ambas son lentas, la plataforma usualmente sí.

Pregunta 5: ¿Puedes enviar un cambio chico en menos de una hora?

Prueba: intenta actualizar el horario de feriado en tu home en los próximos 60 minutos. Si no puedes (sin acceso, CMS complejo, requiere developer), eso es señal de rehacer — no porque la limitación técnica sea fatal, sino porque la carga operativa compone silenciosamente. Cada cambio que postergas es una pequeña fuga.

Pregunta 6: ¿La marca coincide con el salón?

Abre tu home en el teléfono que cargas. Luego entra a tu comedor. ¿Se sienten como el mismo lugar? Si no — si el salón es cálido, considerado, intencional, y el sitio es plantillado, genérico, “elegimos la plantilla más limpia de Squarespace” — eso es señal de rehacer por marca, separado de las técnicas.

Pregunta 7: ¿Qué pasa con las reservas si no haces nada por 18 meses?

Mira tu tendencia mensual de reservas. Si está plana o cayendo y tu sitio ha sido el mismo por 24+ meses, no hacer nada no es realmente neutral — la brecha con tus competidores locales se está abriendo aunque tus números se vean estables. La proyección de “no hacer nada” a 18 meses casi siempre es negativa para un sitio de restaurante estancado.

Tres patrones de caso

Caso 1 — Sitio con buena puntuación, arreglos puntuales: Un bistró francés de seis años puntuando 75 en Storefront Health. La velocidad mobile arrastraba la puntuación. Agregar un CDN, recomprimir cada imagen, arreglar el schema del menú. La puntuación se mueve a 88; el rebuild se posterga dos años más.

Caso 2 — Sitio bajo 60, rehace: Front-end viejo, lento en mobile, schema de menú malformado, embudo de reservas escondido. La plataforma misma es el techo. El rebuild aquí es full custom: menú HTML real, datos estructurados a nivel de plato, embudo de reservas limpio. La puntuación aterriza en 80s altos o 90s. Las reservas vía búsqueda aproximadamente se triplican en 90 días porque el schema faltante empieza a aparecer en queries del local-pack para las que el sitio nunca apareció antes. Las ventanas de payback en rebuilds de este rango son típicamente 9–14 meses — pero el leverage compone conforme el índice de Google se actualiza.

Caso 3 — Sitio en 65–70, rebuild parcial: Plataforma bien, marca cansada. Mantén el CMS, reemplaza el front-end y las fotos a aproximadamente 40% del costo de rebuild completo. La puntuación se mueve a 80s bajos-medios. Las reservas suben — pero no tan pronunciadamente como el Caso 2. El trade-off honesto que vale señalar: un rebuild parcial mantiene tu techo en lo que la plataforma subyacente permita para schema, velocidad e indexación. A veces es la decisión correcta; a veces vale revisitar en 18 meses cuando el techo de la plataforma se vuelve la siguiente restricción.

La mayoría de los operadores no rehace porque no se imagina cómo se ve la cosa rehecha. El framework es una herramienta forzosa. Recorre las preguntas. La respuesta casi siempre ya existe.

Cómo usar este framework

Corre Storefront Health primero. Guarda la puntuación en tu Taller. Recorre las siete preguntas, escribe la respuesta honesta a cada una, y mira el patrón. Si tres o más apuntan a “rehacer,” estás atrasado. Si una o dos lo hacen, estás en territorio de arreglar-las-fugas.

Si quieres un segundo par de ojos sobre cómo aplica el framework a tu sitio, escríbeme por La Ventana. Leo cada uno.

No hacer nada no es neutral. La brecha con tus competidores locales se abre cada trimestre que tu sitio no.