Lamer el Plato
Marketing Gastronómico

Qué debe tener la web de un restaurante para que funcione de verdad

Javier Calabria
AutorJavier Calabria
8 de mayo de 2026
Qué debe tener la web de un restaurante para que funcione de verdad

La mayoría de webs de restaurantes tienen el mismo problema: están diseñadas para existir, no para convertir.

Hay una foto bonita en la cabecera. Hay un menú en PDF. Hay un "reserva aquí" que lleva a un formulario que tarda tres días en responderse. El cliente llega desde el móvil, no encuentra lo que necesita en diez segundos, y cierra. Se va a TripAdvisor. Reserva en otro sitio.

Una web de restaurante que funciona no es la más cara ni la más elaborada. Es la que resuelve las tres preguntas que el cliente tiene cuando llega: ¿qué hay para comer?, ¿cómo reservo?, ¿dónde estáis? Todo lo demás es decoración.


El menú en PDF es un error

Es el error más extendido y el más costoso. Un PDF subido a la web parece una solución cómoda —actualizas el archivo y listo. El problema es doble.

Primero, Google no lo indexa. Un PDF es un documento opaco para el algoritmo. Las palabras que hay dentro —los nombres de los platos, los ingredientes, las especialidades— no contribuyen al posicionamiento de tu web. Si tu carta dice "arroz de bogavante con producto de la lonja de Santa Pola" y está en PDF, para Google esa frase no existe.

Segundo, en mobile es una experiencia pésima. El PDF se abre en un visor externo, hay que hacer zoom para leer, el texto se desborda, el cliente pincha sin querer en el plato equivocado. El ochenta por ciento del tráfico de un restaurante llega desde el móvil. Darle un PDF a ese usuario es decirle que la web no está pensada para él.

La solución es la carta en HTML: cada sección como un bloque de texto, cada plato con su nombre y descripción visibles, todo indexable por Google y legible en cualquier pantalla. No hace falta que sea elaborada —hace falta que sea texto real, no un documento adjunto.


La velocidad en mobile

Una web lenta en mobile no es un problema estético. Es clientes que se van antes de ver nada.

Google establece que si una página tarda más de tres segundos en cargar en mobile, más de la mitad de los usuarios la abandona. Y el tiempo de carga es también un factor de posicionamiento: webs lentas aparecen más abajo en los resultados.

Los culpables habituales en webs de restaurantes son las imágenes sin comprimir —una foto de plato de ocho megabytes que el diseñador subió directamente desde la cámara— y los sliders de la portada, que cargan varios archivos pesados de golpe sin que el usuario haya pedido verlos.

Para medir dónde estás: PageSpeed Insights de Google analiza tu web en mobile y desktop y señala exactamente qué está frenando la carga. Es gratuito y tarda treinta segundos. Si el resultado en mobile está por debajo de sesenta sobre cien, hay trabajo que hacer antes de cualquier otra optimización.


La llamada a la acción que nadie ve

El botón de reserva enterrado en el cuarto elemento del menú de navegación. El teléfono escrito como texto plano que no se puede pulsar desde el móvil. El formulario de contacto que pide nombre, apellidos, email, teléfono, número de comensales, fecha, hora y motivo de la visita antes de enviar nada.

Cada uno de estos elementos tiene el mismo efecto: el cliente que quería reservar abandona el intento.

Lo que funciona es visible, inmediato y sin fricción. El botón de reserva —o el número de teléfono clicable— debe estar en el primer scroll de la web, sin que el usuario tenga que buscar. En mobile, el número de teléfono debe ser un enlace tel: que abra directamente la marcación. El formulario de contacto, si existe, no debería pedir más de tres campos.

Un detalle que marca diferencia: el botón de reserva fijo en la parte inferior de la pantalla en mobile. El usuario scrollea, lee la carta, mira las fotos, y el botón de reservar siempre está ahí, accesible en cualquier punto sin tener que volver arriba. Es el equivalente digital del camarero que aparece justo cuando lo necesitas.


El contenido que Google necesita leer

Google aprende de lo que hay escrito en tu web. No del diseño, no de las fotos. De las palabras.

La home debe responder tres preguntas con texto real —no solo con imágenes o con titulares sin desarrollo: qué tipo de cocina ofreces, dónde estás y qué te diferencia. Una frase como "Especialistas en arroces de la Vega Baja. Producto de temporada, cocina a leña. En el centro de Alicante desde 2008" hace más por tu posicionamiento local que un slider de diez fotos sin texto.

La página de carta es donde más posicionamiento se gana o se pierde. Cada plato con su nombre y una descripción breve es una oportunidad de aparecer en búsquedas específicas. "Fideuà de bogavante con alioli de ajo negro" posiciona para búsquedas que "ver carta" en PDF nunca alcanzará.

La página de contacto debe incluir la dirección completa en texto —no solo en un mapa incrustado— el teléfono, el email y el horario. Texto real que Google puede leer y cruzar con tu ficha de Google Business Profile para verificar coherencia.


Schema LocalBusiness y FAQPage

El marcado estructurado cierra el círculo entre tu web y tu presencia en Google Maps. Ya lo vimos en la guía de posicionamiento local, pero hay un complemento que merece atención específica para webs de restaurantes: el schema FAQPage.

Si incluyes en tu web una sección de preguntas frecuentes con marcado estructurado, Google puede usar esas respuestas directamente cuando alguien pregunta por tu restaurante. "¿Admiten reservas?", "¿Tienen menú para celíacos?", "¿Dónde aparcan los clientes?" —preguntas con respuesta en schema son preguntas que las IAs y los buscadores pueden responder con tu propia voz.

El código va en el <head> de la página donde tengas las FAQs:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "¿Admitís reservas?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sí, recomendamos reservar con antelación, especialmente en fin de semana. Puedes hacerlo por teléfono en el XXX XXX XXX o por email en [email protected]"
      }
    },
    {
      "@type": "Question",
      "name": "¿Tenéis menú para celíacos o alérgenos?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Adaptamos la carta a intolerancias y alergias. Consúltanos al reservar y lo preparamos sin problema."
      }
    },
    {
      "@type": "Question",
      "name": "¿Dónde está el restaurante y hay parking cerca?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Estamos en Calle X, número Y, en el centro de Alicante. Hay parking público a dos minutos a pie en la Plaza Z."
      }
    }
  ]
}
</script>

Para verificar que está correctamente implementado: Google Rich Results Test.


Lo que sí convierte

En resumen, una web de restaurante que funciona tiene esto:

Reserva visible desde el primer scroll. Botón o teléfono clicable, sin búsqueda, sin fricción. En mobile, fijo en la parte inferior de la pantalla.

Carta en HTML. Texto real, indexable, legible en cualquier dispositivo. Sin PDFs, sin imágenes de la carta escaneada, sin "próximamente".

Imágenes optimizadas. Comprimidas para web, con nombres de archivo descriptivos y texto alternativo que explica qué hay en la foto. Una imagen llamada arroz-bogavante-alicante.jpg con alt "arroz de bogavante con alioli de ajo negro" posiciona. Una llamada IMG_4832.jpg sin alt, no.

Dirección y teléfono en texto real. No solo en un mapa. Texto que Google puede leer, cruzar y verificar.

Una descripción que explica por qué merece la pena. No "bienvenidos a nuestro restaurante, donde la calidad y el sabor se unen". Algo concreto: qué cocinas, con qué producto, desde cuándo, para quién.

Nada de esto es caro. Todo requiere criterio.


Si prefieres que lo hagamos nosotros

Auditar una web de restaurante y corregir lo que frena el posicionamiento y las reservas es uno de los primeros pasos que damos con cualquier cliente nuevo. A veces los cambios son mínimos y el impacto es inmediato. A veces la web necesita rehacerse desde la estructura.

En Lamer el Plato revisamos tu web, identificamos exactamente qué está frenando tu visibilidad y tus conversiones, y te damos un plan concreto —o lo ejecutamos nosotros.

Escríbenos a [email protected] si quieres saber dónde estás.

Preguntas frecuentes

¿Por qué no debo tener el menú de mi restaurante en PDF?
Por dos razones: Google no indexa bien el contenido de un PDF, así que los nombres de tus platos no contribuyen al posicionamiento; y en móvil la experiencia es pésima, con zoom y desbordes. La carta debe estar en HTML, plato a plato, legible e indexable.
¿Cuánto importa la velocidad de carga de la web de un restaurante?
Mucho. Si una página tarda más de tres segundos en cargar en móvil, más de la mitad de los usuarios la abandona, y la velocidad es además un factor de posicionamiento. Las imágenes sin comprimir y los sliders pesados son los culpables habituales.
¿Qué es lo más importante que debe tener la web de un restaurante?
Que resuelva en diez segundos las tres preguntas del cliente: qué hay para comer, cómo reservar y dónde estáis. En la práctica: carta en HTML, reserva o teléfono clicable visible desde el primer scroll, y dirección en texto real. Todo lo demás es secundario.
¿Qué es el schema FAQPage y para qué sirve en la web de un restaurante?
Es un marcado estructurado que permite a Google y a las IAs usar tus preguntas frecuentes para responder directamente cuando alguien pregunta por tu restaurante. Preguntas como si admites reservas o si tienes opciones para celíacos, respondidas con schema, aumentan tu visibilidad.
#web restaurante#seo local#marketing gastronomico#diseño web#posicionamiento
Mesa para todos

Suscríbete a

Gato por liebre

Recibe reflexiones, trucos de marketing gastronómico y las verdades del sector directamente en tu bandeja de entrada.