← Back to Case Studies
Case Study

Probing Booking-Bot Detection with a Playwright Server

How well do real-world booking sites detect an automated browser? I stood up a Playwright server, scripted a normal reservation flow, and pointed it at 22 hotel booking portals across five major chains. Every portal in this set detected the bot and stopped it. The interesting part is how differently each one did it, and where in the funnel the wall went up.

Probed: May 25, 2026 Tool: Playwright, headless Chromium Scope: 22 booking portals, 5 chains Output: 32 captures, 6 block mechanisms

What This Tested

Bot-detection software is sold on a promise: it can tell an automated browser from a human and stop it before it touches the booking engine. That promise is testable. A Playwright server driving a headless Chromium browser is a faithful stand-in for the kind of automation a scraper or a booking bot would use, so running it against live portals and recording exactly what comes back is a direct measurement of each site's detection posture.

The harness opened each portal, set dates and occupancy the way a guest would, advanced toward checkout, and saved a screenshot at every step. No detection was evaded and no CAPTCHA was solved. The goal was to observe the defenses, not defeat them.

22
Portals captured
6
Block mechanisms
20
Stopped at landing
2
Stopped at checkout

On the numbers. This page documents the portals where detection fired and the bot was stopped. Portals that served booking content to the automated browser are deliberately excluded from this write-up. Treat the figures here as a catalog of detection behavior observed, not a survey-wide block rate.

The Six Detection Mechanisms

Across the set, the defenses fell into six distinct patterns. Three of the big chains each ran a recognizably different stack, and the timing told its own story: one Akamai-protected property sat for nearly fifty seconds before returning Access Denied, a fingerprint-analysis delay rather than an instant block.

MechanismSeen onSignature
Akamai HTTP 403Marriott (7)Immediate 403, page title "Access Denied". One property delayed 49.5s before blocking.
Cloudflare challengeHilton (9)Challenge interstitial, page title "Hilton Page Reference Code". Headless fingerprint flagged.
Access DeniedChoice (2)Bot protection returns Access Denied at the landing page. No room data served.
Silent JavaScript blockHyatt (1)Page renders blank, no error and no page title, no network error returned.
CAPTCHAIndependent (1)Human-verification challenge before any booking content is reachable.
Mid-funnel navigation blockIHG (2)Landing and rates load, then navigation to checkout is refused.

Stopped at the Door

Most portals never served a single rate. The bot hit the landing or availability URL and met a 403, a Cloudflare challenge, a blank page, or a CAPTCHA. Each capture below is the exact frame the harness saved at the block. Click any image to open it full size.

Stopped at Checkout

Two IHG properties were more permissive up front. The bot loaded the landing page, dismissed dialogs, waited out the calendar modal, and saw rates render, then navigation to the checkout step was refused. Detection that lets the funnel start but blocks the transaction is a different design choice, and worth seeing as a sequence.

Why This Is Worth Keeping

A Playwright harness like this is a practical, repeatable way to test bot-detection software, your own or a vendor's. It answers concrete questions: Does the detection fire at all? At which step? What does it return, and how fast? Does it leak booking data before it decides? The same rig that produced these 32 captures can be re-pointed at any portal and re-run on a schedule, turning "our bot protection works" from a claim into a measurement.