Diseño web para hoteles: reservas directas frente a las OTAs
- Guías prácticas
Tabla de contenidos
Existe la idea de que a Booking no se le puede ganar. Que tiene más presupuesto, más dominio y más gente, y que lo único sensato es aceptar la comisión como un coste fijo del negocio y seguir.
En parte es verdad. Ningún hotel independiente va a competir con una OTA por la búsqueda genérica de «hoteles en Valencia», y perseguir eso es tirar el dinero.
Pero esa no es la pelea.
La pelea está en el cliente que ya sabe cómo se llama tu hotel, que lo ha buscado por su nombre, que ha entrado en tu web y que aun así ha terminado reservando en el portal. Ese cliente lo pierdes tú, no te lo quita nadie.
Pagar comisión por alguien que ya venía a tu casa es como pagarle al vecino por abrirte tu propia puerta.
Un diseño web para hoteles que funciona no intenta sustituir a la OTA. Intenta que el huésped que ya te ha encontrado no tenga ni un motivo para salir de tu web.
Lo que de verdad estás comprando cuando pagas comisión
Conviene separar dos cosas que se confunden siempre.
La OTA te trae clientes nuevos, gente que no te conocía y que te descubre en una lista. Eso es captación y tiene un precio razonable.
La OTA también cobra por clientes que ya eran tuyos: el que repite, el que viene recomendado, el que vio tu cartel y el que buscó tu nombre. Eso no es captación. Es un peaje que pagas porque tu web no cerró la reserva.
La proporción entre esos dos grupos es lo que decide si tu web está trabajando o está haciendo de folleto caro. Y esa proporción se puede mover.
Base Aparthotels: qué cambió y qué se midió
En el rediseño de Base Aparthotels el planteamiento fue exactamente ese: no competir por la búsqueda genérica, sino dejar de perder al que ya había llegado.
Las cifras están publicadas en la ficha del proyecto. Un 48% más de reservas directas. Un 35% menos de abandonos dentro del proceso. Un 62% más de interacción en las landings. Y la web cargando en 1,4 segundos en móvil.
Ninguno de esos números viene de una campaña. Vienen de quitar fricción donde el huésped ya estaba.
Los seis errores que mantienen tu web por debajo del portal
Casi todo lo que falla en diseño web hoteles cabe en esta lista. La misma en un tres estrellas que en un apartamento turístico.
1. El motor de reservas vive en otro dominio
Es el más grave y el más común. El huésped elige fechas en tu web, pulsa «Reservar» y aterriza en una dirección que no se parece a la tuya, con otro diseño, otro tipo de letra y a veces otro idioma.
Ahí se pierde gente. Unos porque desconfían, otros porque el salto tarda, y otros porque en ese cambio de página aprovechan para comprobar el precio en el portal.
Lo que hay que exigirle al proveedor del motor: que se integre dentro de tu dominio, que herede tu diseño y que la disponibilidad y el precio se vean antes de dar el salto. Si el contrato no lo permite, al menos que el subdominio use tu identidad completa y no la plantilla de fábrica.
2. No hay ninguna ventaja por reservar directo
Si el precio es el mismo, las condiciones son las mismas y el proceso es más incómodo, reservar en tu web es la peor opción disponible. El huésped no es tonto.
La reserva directa necesita un motivo explícito y visible en la propia página de la habitación. Cancelación más flexible, desayuno incluido, salida tardía sujeta a disponibilidad, mejor habitación de la categoría contratada, un descuento en el restaurante. Lo que encaje con tu operativa.
Y tiene que estar escrito donde se decide, no en una página llamada «Ventajas» a la que no entra nadie.
3. El precio no se puede comparar
Durante años los contratos con los grandes portales incluían cláusulas de paridad que impedían al hotel anunciar un precio mejor en su propia web. Ese marco ha cambiado en el Espacio Económico Europeo tras la designación de Booking como guardián de acceso bajo el Reglamento de Mercados Digitales.
Traducido: hoy tienes más margen del que tenías para diferenciar tu oferta directa, y conviene que revises tu contrato en lugar de asumir que sigue atado.
Si ese margen existe, la comparación explícita en la ficha de habitación es el argumento más eficaz que hay. Si no existe, el argumento pasa a ser la condición y no el precio.
4. La web se traduce a medias
Un hotel vende fuera. Es la diferencia de fondo con casi cualquier otro negocio local.
Lo que suele pasar: se traduce la portada y las habitaciones, y se dejan en español el blog, los avisos legales, el proceso de reserva y los correos de confirmación. O peor, se instala un traductor automático que genera versiones que ningún buscador va a indexar bien y que producen frases que espantan.
Un multiidioma que se sostiene necesita tres cosas. Una URL propia por idioma. Traducción humana al menos en habitaciones, tarifas y proceso de reserva. Y las etiquetas que le dicen al buscador qué versión corresponde a cada país.
Cuando esas etiquetas están mal puestas, Google enseña la versión en alemán a quien busca en inglés. Se detecta revisando qué está viendo el buscador y qué está ignorando.
5. La web tarda justo cuando más importa
El motor de reservas suele ser la pieza más pesada del sitio, y casi siempre se carga en todas las páginas aunque solo se use en una.
El huésped consulta desde el móvil, muchas veces desde el aeropuerto o desde la calle. Cada segundo que tarda el calendario en dibujarse es una oportunidad para abrir la aplicación del portal, que está optimizada hasta el último detalle.
La regla es sencilla: el motor se carga cuando alguien lo toca, no antes. Los umbrales concretos y cómo saber cuál de ellos estás incumpliendo están en las tres métricas que Google mide y cómo corregir cada una.
6. Nadie sabe dónde se cae la reserva
Si el motor está en otro dominio y la analítica no cruza los dos, tu web no mide nada. Sabes cuántos entran y cuántos terminan, y no sabes en qué paso se va la gente.
Sin ese dato, cualquier mejora es una apuesta. Con él, la conversación cambia: se ve si el abandono está en las fechas, en la selección de habitación, en el formulario de datos o en la pasarela de pago, y se arregla lo que toca.
Es el mismo problema que tiene un comercio electrónico cuando deja de vender sin que nadie sepa por qué, aplicado a un carrito de una sola noche.

El contenido que una OTA no puede publicar
Aquí está la parte que casi ningún hotel trabaja y la que más barata sale.
Un portal describe la habitación, los metros, la cama y los servicios. Tiene que hacerlo igual para los cuatrocientos hoteles de la ciudad, porque su ficha es una plantilla.
Lo que no puede contar, y tú sí:
- Cómo se llega de verdad desde el aeropuerto o la estación, con el tiempo real, el coste aproximado y qué línea conviene a según qué hora.
- Qué hay abierto en temporada baja, que es justo lo que pregunta quien viaja en noviembre y no encuentra en ningún sitio.
- Dónde aparcar, con la respuesta concreta para tu calle, no un enlace genérico.
- Qué se ve desde cada tipo de habitación y cuál conviene según lo que vengas a hacer.
- Guías del barrio escritas por alguien que vive ahí, con los sitios que recomiendas de verdad.
Ese contenido trae búsquedas que la OTA no persigue. Llega al huésped mientras todavía está decidiendo ciudad, o sea, antes de que nadie compare precios.
Y sostiene la estructura del sitio, porque cada guía tiene su propia consulta detrás. Es el criterio de cómo se reparten las páginas para que ninguna estorbe a otra.
Cero páginas escritas para rellenar el menú.
Si tu web viene heredada
Muchos hoteles arrastran una web montada por la cadena anterior, por el proveedor del PMS o por una agencia que ya no responde. Antes de rehacer nada, conviene saber qué hay.
Dos preguntas ordenan la decisión: ¿el motor actual se puede integrar o el contrato lo impide?, y ¿el contenido que tienes vale algo o hay que escribirlo entero?
Con esas dos respuestas se sabe si esto es un arreglo o una obra, y es exactamente el mismo dilema que planteo en reparar frente a rehacer para otro tipo de proyecto. El diagnóstico previo está descrito en qué cubre una revisión completa del sitio.
Lo que hago yo en un proyecto de hotel
No empiezo por el diseño. Empiezo pidiendo el contrato del motor de reservas y el del portal, porque ahí está escrito qué puedo y qué no puedo hacer.
He visto propuestas preciosas que chocaban con una cláusula de la página cuatro.
Después mido dónde se cae la reserva actual, antes de tocar nada. Sin esa foto, dentro de seis meses no hay forma honesta de decir si el trabajo funcionó.
Y no doy por bueno un proceso de reserva hasta completarlo yo mismo desde un móvil, con datos y en la calle, en los idiomas en los que vendes. Si en esa prueba algo cuesta, se cambia, aunque ya estuviera aprobado.
Ese orden es el que sigo en todo lo que planteo antes de escribir una línea de código, y en hoteles es donde más se nota.
¿Hablamos de tu proyecto?
Alejandro Schintu – Developer y frontend especializado en WordPress
Diseñador web en WordPress que convierte ideas en experiencias potentes, rápidas y con carácter.
Más artículos
Conoce mas ideas y
opiniones incómodas.

Diseños que convierten y hacen que tu competencia sude un poco.
Conoce más
sobre mi .








Sigue scrolleando
para más.
