Disponibilidad en Booking.com: calendario por fecha

Recolectar la disponibilidad de Booking.com no es un problema de extracción de documentos, porque una página de disponibilidad no es un documento. Es una proyección de una consulta: las fechas, la ocupación, la habitación y la tarifa que se piden deciden qué celdas del calendario existen siquiera en la página. BotBrowser documenta salida alineada geográficamente y valores de configuración regional respaldados por perfil, de modo que una comparación de punto de venta puede declarar la región y el idioma que representa. No proporciona datos de disponibilidad, no mantiene inventario, no reserva una habitación y no garantiza que una consulta devuelva el mismo calendario dos veces. Prefiera un feed oficial de socio o afiliado cuando exista.

Resumen

• Una página de disponibilidad es una proyección de su consulta. Registre la consulta o la página no podrá interpretarse después.
• Clave el calendario por fecha, no por página. Una estancia de tres noches son tres filas de fecha, y la fecha de salida es exclusiva.
• Habitación y tarifa son dimensiones de una fila, no calendarios separados. Dos tarifas en la misma fecha son dos celdas, no dos observaciones de una celda.
• Use cinco estados por celda: disponible observado, cerrado observado, fuera de la ventana, ausente en la respuesta y no aceptado. Una celda ausente no es una habitación cerrada.
• Prefiera un feed oficial de socio o afiliado cuando exista, y mantenga los términos de la plataforma como autoridad sobre lo que puede recolectarse.

Contenido

• La disponibilidad como calendario
• La clave y las dimensiones
• Qué proyecta la página desde una consulta
• Cinco estados por celda
• Registrar la consulta con la observación
• El límite de los términos
• Conclusión práctica

La disponibilidad como calendario

Una búsqueda de alojamiento responde a una pregunta sobre un rango de fechas. El rango es la unidad que la fuente pone precio, y la noche individual es la unidad sobre la que un calendario puede poner clave. Equivocar esa relación es el error de modelado más común en el trabajo de disponibilidad, porque una página que muestra «desde 412» para tres noches parece un solo valor cuando es un resumen de tres filas que pueden tener disponibilidad distinta.

La fecha de salida es exclusiva. Una estancia del 2026-12-10 al 2026-12-13 ocupa las noches del 10, 11 y 12, y el huésped sale el 13. Tratar la fecha de salida como una cuarta noche produce un calendario desplazado uno en cada estancia, y el error es invisible hasta que alguien compara una reserva de dos noches y otra de tres de la misma habitación.

La disponibilidad tampoco es una propiedad del establecimiento en conjunto. Un hotel puede tener habitaciones libres mientras un tipo concreto está agotado, y puede tener un tipo libre mientras la tarifa con desayuno no lo está. Por eso el calendario necesita al menos dos dimensiones antes de que una celda signifique algo.

La clave y las dimensiones

La clave es la fecha más lo que se observa. Las dimensiones describen cómo se cualificó esa observación. Mantenerlas separadas es lo que permite comparar dos capturas sin mezclar en silencio un tipo de habitación, un plan tarifario o un punto de venta.

Parte	Contenido	Por qué no puede plegarse en un valor de página
date_key	Fecha ISO de la noche, en la zona del hotel	Dos noches son dos observaciones, no una
room_code	Tipo de habitación o unidad como lo nombra la fuente	Una suite agotada no cierra el hotel
rate_code	Plan tarifario como lo nombra la fuente	Una tarifa cerrada no cierra la habitación
occupancy	Adultos y niños solicitados	La ocupación cambia el inventario ofrecido

Una clave de (date, room, rate, occupancy) basta para comparar dos observaciones de lo mismo. Una clave de solo (date) fusiona una suite y una habitación estándar en una celda, y la serie resultante mostrará una habitación «reabriéndose» cada vez que cambie la categoría más barata. Una clave de (page) fusiona tres noches en un valor y pierde la capacidad de decir qué noche cambió.

La zona horaria del establecimiento pertenece a la clave también, pero como propiedad declarada del calendario y no como dimensión aparte. Una noche es un concepto local, y una captura tomada cruzando un cambio de horario de verano sin registrar la zona producirá dos filas que parecen una noche duplicada.

La ocupación merece una nota propia porque cambia qué inventario existe, no solo cómo se pone precio. Una consulta para dos adultos puede devolver un tipo que una consulta para cuatro no puede ver, y la misma habitación física puede aparecer como dos ofertas distintas con códigos tarifarios diferentes. Registrar la ocupación junto a la habitación y la tarifa permite que una comparación posterior sepa si el cambio vino del inventario o de la pregunta planteada.

Las reglas de estancia mínima son la dimensión más silenciosa de todas. Un establecimiento puede exigir dos noches un fin de semana, así que una consulta de una noche no devuelve nada mientras la habitación está realmente libre para dos noches. Un calendario que registra la consulta de una noche como observed_closed ha registrado un resultado de política como un hecho de disponibilidad. Cuando la página declare una estancia mínima, regístrela como dimensión o como nota; cuando no lo haga, trate un resultado vacío de una noche como una observación con su consulta declarada y no como un cierre.

Moneda y punto de venta se sientan junto a las cuatro entradas de tarifa y no dentro de la clave del calendario. Un código tarifario puede existir en varias monedas y bajo varias reglas de punto de venta, y el importe diferirá mientras la disponibilidad no cambia. Mantenga moneda y punto de venta en el registro para que una comparación de precios no se confunda con una de disponibilidad, y para que un cambio de moneda no parezca una habitación reabriéndose.

Qué proyecta la página desde una consulta

La documentación de la API URL de MDN describe URL como la interfaz que analiza y expone los componentes de una dirección, incluidos sus parámetros de búsqueda. Esa es la parte de la superficie del navegador que este problema realmente necesita: una página de disponibilidad renderizada se selecciona por los parámetros de su dirección, así que la dirección es evidencia sobre la página y no decoración a su alrededor.

Una misma estancia admite varias codificaciones de consulta. Un rango de fechas puede escribirse como dos parámetros, como un único parámetro de rango o como un segmento de ruta, y una consulta puede añadir parámetros de seguimiento que no cambian el resultado. Normalizar la consulta es por tanto el primer paso para hacer comparables dos capturas, y debe ocurrir antes de pedir la página y no después.

// Constructed fixture: the same stay written two ways, then a changed check-in.
const raw = [
  'https://example.test/hotel/alpha?checkin=2026-12-10&checkout=2026-12-13&adults=2&tracking=abc',
  'https://example.test/hotel/alpha?stay=2026-12-10_2026-12-13&adults=2',
  'https://example.test/hotel/alpha?checkin=2026-12-11&checkout=2026-12-14&adults=2',
];
const KEEP = ['checkin', 'checkout', 'adults', 'children', 'room', 'rate'];

const lines = raw.map(input => {
  const url = new URL(input);
  const stay = url.searchParams.get('stay');
  const params = new Map();
  if (stay) {
    const [checkin, checkout] = stay.split('_');
    params.set('checkin', checkin);
    params.set('checkout', checkout);
  }
  for (const key of KEEP) {
    const value = url.searchParams.get(key);
    if (value) params.set(key, value);
  }
  const canonical = [...params.entries()]
    .sort(([a], [b]) => a.localeCompare(b))
    .map(([k, v]) => `${k}=${v}`)
    .join('&');
  return `canonical=${canonical} key=${params.get('checkin')}..${params.get('checkout')}`;
});
console.log(lines.join('\n'));

La salida construida muestra que las dos primeras direcciones se reducen a una sola consulta canónica, y que la tercera se mantiene distinta porque sus fechas difieren.

canonical=adults=2&checkin=2026-12-10&checkout=2026-12-13 key=2026-12-10..2026-12-13
canonical=adults=2&checkin=2026-12-10&checkout=2026-12-13 key=2026-12-10..2026-12-13
canonical=adults=2&checkin=2026-12-11&checkout=2026-12-14 key=2026-12-11..2026-12-14

El parámetro de seguimiento desaparece en las dos primeras líneas, y eso es el punto: dos capturas que solo difieren por una etiqueta de campaña describen la misma estancia y deben compararse como una. La tercera línea conserva su propia clave, porque una entrada desplazada es otra pregunta aunque el número de noches coincida.

Tres reglas de normalización hacen fiable ese comportamiento. Ordene los parámetros conservados por nombre para que la forma canónica no dependa del orden que usó el sitio. Elimine los parámetros cuyo valor no afecta al resultado y mantenga una lista explícita de los que sí, para que un nuevo parámetro de seguimiento no cree en silencio una nueva serie. Represente el rango de fechas de una sola manera, convirtiendo un parámetro de rango en dos fechas explícitas, para que la elección de codificación del sitio nunca se filtre a la clave.

También hay una frontera que el normalizador no puede cruzar. Dos direcciones que parecen distintas pueden describir la misma estancia mediante una redirección, y dos direcciones que parecen idénticas pueden resolverse de forma diferente por una cookie o un estado de cuenta. La consulta canónica es por tanto una afirmación sobre lo solicitado, no una garantía sobre lo renderizado. Registre la consulta canónica y la dirección final tras cualquier redirección, y trate una divergencia entre ambas como un hallazgo y no como ruido.

Cinco estados por celda

El trabajo de disponibilidad falla más a menudo en la frontera entre «no disponible» y «no observado». Un modelo binario disponible/cerrado fuerza toda celda ausente hacia una de esas dos respuestas, y ambas elecciones son erróneas para una celda que la consulta nunca preguntó.

Estado	Qué se observó	Qué sostiene
observed_available	La consulta devolvió una oferta para esta fecha, habitación y tarifa	La celda estaba disponible en esa consulta en ese momento
observed_closed	La consulta devolvió una señal explícita de agotado o cerrado	La celda estaba cerrada en esa consulta en ese momento
not_in_window	La ventana de la consulta no incluía esta fecha	Nada sobre la celda; la ventana estaba acotada
absent_in_window	La ventana cubría la fecha, pero la respuesta no listó celda	Nada sobre la celda; la respuesta la omitió
unaccepted	Sin respuesta utilizable: desafío, error, tiempo agotado, fallo de análisis	Nada sobre la celda; la observación falló

Los dos estados ausentes salvan una serie de inventar cierres y describen fallos distintos. Si la captura solo pidió tres noches, la cuarta noche es not_in_window: fuera de la ventana acotada, y no cerrada. Si la ventana cubría la fecha pero la respuesta no listó celda, es absent_in_window: dentro de la ventana, no listada, y tampoco cerrada. Registrar cualquiera como cerrada hace que el establecimiento parezca haber perdido disponibilidad de la que nunca informó.

El estado unaccepted protege del error opuesto. Una página de desafío, un 500 y un fallo de análisis producen cero celdas, y tratarlos como disponibilidad vacía convierte un problema de infraestructura en una observación de oferta. Manténgalos en su propio estado para que un lector posterior vea cuánto del calendario se observó realmente.

La documentación de la API Performance de MDN describe interfaces del navegador para medir tiempos y carga de recursos. Eso importa aquí solo para la frontera entre una página aceptada y una lenta: una captura que se rindió antes de que el calendario se renderizara debe registrarse como unaccepted, no como un establecimiento sin habitaciones. Registrar el tiempo que tardó la página en asentarse junto al estado hace auditable esa distinción.

Hay una condición aparte, fuera de los cinco estados que no debe plegarse en ellos: el calendario se observó, pero la observación pertenece a un alcance distinto del que la serie declara. Una captura tomada con un código tarifario corporativo, un inicio de sesión de miembro o una campaña promocional puede mostrar disponibilidad que la serie pública no puede, y mezclar ambas produce filas que parecen comparables y no lo son. Registre el alcance junto a la consulta y empiece una nueva serie cuando el alcance cambie.

Los cinco estados también necesitan una regla de revisión. Una celda observada como disponible el lunes y cerrada el martes es una transición, no una contradicción, y el registro debe conservar ambas filas con sus horas de observación en lugar de sobrescribir la primera. Sobrescribir pierde la transición e impide distinguir un cambio real de una corrección, que es exactamente la distinción que un revisor posterior necesita cuando se cuestiona una serie.

Por último, mantenga honesta la granularidad de la observación. Una página puede renderizar una vista mensual donde solo algunas fechas llevan celdas, y una captura que registra el mes entero como observado ha reclamado de más. Registre qué fechas estaban realmente presentes en la respuesta, incluso cuando la respuesta sea «la respuesta listó tres de las treinta y una fechas», y registre esas fechas como absent_in_window en lugar de como cerradas.

Registrar la consulta con la observación

Un registro de captura de disponibilidad tiene que llevar la consulta, porque la página no puede interpretarse sin ella. Los campos siguientes son el mínimo que hace comparables dos capturas.

Campo	Contenido	Por qué está en el registro
canonical_query	Consulta normalizada del paso anterior	Define qué calendario se pidió
property_ref	Identificador del establecimiento acotado a la fuente	Separa dos establecimientos con nombres parecidos
date_key	Fecha ISO de la noche	Clave una fila por noche
room_code	Tipo de habitación como lo nombra la fuente	Separa una suite de una habitación estándar
rate_code	Plan tarifario como lo nombra la fuente	Separa una tarifa flexible de una prepagada
state	Uno de los cinco estados	Evita que la ausencia se lea como cierre
observed_at	Hora de captura en UTC	Ordena observaciones y acota la ejecución
settle_ms	Tiempo que tardó la página en asentarse, si se midió	Distingue una página lenta de una ausente

Dos campos merecen una nota. property_ref debería ser un identificador acotado a la fuente y no un nombre, porque dos establecimientos de la misma ciudad pueden compartir nombre y una cadena puede renombrar uno. settle_ms es opcional pero útil: una captura que registró un estado tras 40 milisegundos probablemente leyó un esqueleto y no un calendario, y conviene saberlo antes de confiar en la fila.

El modelo de captura de tarifas aplica la misma disciplina a una sola tarifa en lugar de a un calendario: las cuatro entradas se registran por captura porque una comparación sin ellas mide el entorno. La disponibilidad necesita eso más la clave de fecha, porque una estancia abarca varias filas que pueden cambiar de forma independiente.

El límite de los términos

Una página de reservas está detrás de una plataforma cuyos términos deciden qué puede recolectarse. Eso no es una restricción técnica que una mejor configuración del navegador elimine; es la condición bajo la cual los datos pueden usarse. Donde exista un feed oficial de socio, una interfaz de afiliado o un canal de distribución con licencia, ofrece la misma disponibilidad con un esquema definido y un derecho de uso declarado.

RFC 9110 define la semántica HTTP, incluido el almacenamiento en caché y la cabecera Vary, que indica a una caché qué campos de la solicitud influyeron en la representación. Ese es el mecanismo con el que una página dice que su contenido depende de más que su ruta, y es un recordatorio útil de que una respuesta de disponibilidad se negocia y no es fija. No dice nada sobre si un sitio concreto permite la recolección, y ninguna cabecera hace desaparecer una cuestión de términos.

El modelo de anuncios inmobiliarios traza la misma línea para datos de propiedades: una ocurrencia de anuncio, la propiedad física y una oferta son distintas, y una tarjeta ausente no es una venta. La disponibilidad tiene la misma forma, con un rango de fechas en lugar de una propiedad, y la misma regla: una observación no es una conclusión.

De ahí se siguen dos límites prácticos. Primero, observar no es reservar: cargar un calendario y registrar lo que mostró es un acto distinto de bloquear una habitación, y el segundo queda completamente fuera de alcance. Segundo, una diferencia entre dos capturas es una observación, no evidencia de una violación de política por parte de la plataforma. Esas conclusiones pertenecen a quien tiene el inventario y el acuerdo.

Preguntas frecuentes

¿Una estancia de tres noches es un solo valor de disponibilidad?

No. Son tres filas de fecha, y cada una puede llevar un estado distinto. Una página que resume la estancia muestra una proyección, así que el resumen debe descomponerse antes de compararse noche a noche.

¿Una celda ausente significa que la habitación no está disponible?

No. O la ventana no cubría la fecha (not_in_window), o la cubría y la respuesta no listó celda (absent_in_window), o la respuesta no se aceptó (unaccepted). Mantenga los tres separados de observed_closed para que ninguno se lea como cierre.

¿El tipo de habitación y la tarifa pertenecen a la clave?

Pertenecen a la clave junto con la fecha, porque una suite agotada no cierra el hotel y una tarifa cerrada no cierra la habitación. Plegarlos en un valor a nivel de página fusiona observaciones que deben seguir separadas.

¿BotBrowser proporciona datos de disponibilidad o reserva habitaciones?

No. Proporciona entradas de navegador documentadas, incluidas salida alineada geográficamente y valores de configuración regional respaldados por perfil, para que una comparación declare su región. No suministra disponibilidad, no mantiene inventario, no reserva una habitación y no garantiza un resultado.

Fuentes

• API URL de MDN
• API Performance de MDN
• RFC 9110 semántica HTTP
• Base de datos GeoIP de BotBrowser
• Configuración de perfiles de BotBrowser

Conclusión práctica

Modele la disponibilidad como un calendario con clave por fecha, con habitación, tarifa y ocupación como dimensiones, y trate la fecha de salida como exclusiva. Normalice la consulta antes de pedir la página y regístrela en cada captura, porque la página es una proyección de esa consulta y no un documento autónomo. Mantenga cinco estados por celda para que la ausencia y la observación fallida nunca se conviertan en cierres. Donde exista un feed oficial de socio o afiliado, úselo, y deje que los términos de la plataforma decidan qué puede recolectar la ejecución de navegador.