A hotel price is not one number. The same room on the same dates can be shown at several different prices depending on the guest's country, whether they are signed in, and whether they are on the app, and a scraper that reads only the headline rate is reading one of those prices and missing the rest. This guide is the complete, practical version of how to scrape hotel prices properly: why the rate depends on who is looking, the layers you have to read, the residential proxy setup that reads each market, and how to size and run it. We run a proxy network and this is one of the oldest jobs our residential IPs do, so this is written from what actually works.
The business-side buyer's guide is proxies for hotel rate monitoring; the flight companion is how to scrape flight prices; and the individual sites have their own pages, from Booking.com and the chains like Marriott to the metasearch like Trivago.
Why the hotel price depends on who is looking
The core fact of hotel scraping is that the price follows the guest, and it does so in four layers.
Currency follows the IP country. The booking sites choose the display currency from where the connection sits, so a request from the wrong country shows a price in the wrong currency before anything else.
Some discounts are hidden by country. Booking.com sells hotels a product called Country Rates: targeted discounts that its own partner documentation says are only visible to guests browsing from an IP address in the country the hotel targets. A scraper reading from outside that country never sees the discount a local guest is shown.
Member rates need a login. The chains (Marriott, Hilton, IHG, Accor) and the OTAs show an exclusive member rate only to signed-in loyalty members, part of their push to move bookings direct. That price does not exist for a logged-out visitor.
Mobile rates need the app. Some rates are shown only on the mobile app or mobile site, so reading them means a mobile exit and a mobile user agent.
Base rate
the public number
Currency by IP country
where you appear to be
Country Rate
hidden unless in-country
Member and mobile rates
login and device
Because the price depends on the guest, reading it accurately means becoming the right kind of guest: an in-market residential exit for the country layer, a logged-in session for the member layer, a mobile exit for the app layer.
The residential proxy setup that reads each market
The layers above resolve into a clear proxy setup.
Rotating residential, pinned per market, for public rates. A residential IP reads as an ordinary guest, which clears the bot management that turns datacenter away, and pinning it to the guest's country reads the currency and the Country Rate that country is shown. Reading several source markets means a pool across those countries. Our residential proxies cover 100+ countries for this, and the background is in what is a residential proxy.
Static residential (ISP), held sticky, for member rates. A member rate needs a logged-in loyalty session, and a session that hops addresses gets dropped, so hold one ISP exit for the whole logged-in read, on an account enrolled in that market's program. The rotation split is in rotating vs static residential proxies.
Mobile, for app-only rates. Where a site shows a mobile rate, a mobile exit with a mobile user agent reads it the way the app does.
Datacenter, only for parser testing. Cheap and fast, and the first thing hotel bot management challenges, so keep it for developing against saved pages.
The layers you have to record
Reading the price is half the job; recording it correctly is the other half, because most bad hotel-pricing decisions come from comparing prices that are not comparable.
- Same room, same terms. Lowest available public rate, same room category, occupancy, cancellation policy and inclusions. A refundable king with breakfast against a non-refundable double is not a price difference.
- Total price, taxes in. Guests decide on the total, and Google grades hotel listings on it, so read the price the guest sees at the last step.
- Each layer as its own line. Public rate, member rate, mobile rate, Country Rate per market. Averaging them hides the discount a competitor is actually offering.
- The market and currency on every rate. A rate without its market is meaningless when the whole point is that markets differ.
- The brand and tier for a chain. An Accor rate is noise until you know whether it is an ibis or a Raffles.
Rate shopping and parity, the business case
The reason most people scrape hotel prices is to compare: a hotel checking its rate against competitors and against its own price on every channel, an analyst studying a market, a deal site tracking drops. That comparison is rate shopping, and the parity question underneath it (is our direct rate at or below every channel) is exactly what the chains' price-match guarantees assert and invite you to check. The full business framing is in proxies for hotel rate monitoring, and the key point for a scraper is that the comparison only means something when both sides are read as guests in the same market, on the same room and terms.
Which sites to read
Hotel prices live in three kinds of source, and a full picture reads across them.
- OTAs (Booking.com, Expedia, Agoda, Hotels.com): the reference prices most guests see, with Country Rates, member rates and per-market localization. Start here.
- The chains directly (Marriott, Hilton, IHG, Accor): the direct rate and the member rate, the other side of the parity comparison.
- Metasearch (Trivago, Google Hotels, Kayak): several channels' prices for one hotel on one page, the most efficient parity read per request.
Sizing (rotating residential, one refresh cycle):
public pages = hotels x dates x markets
= 8 hotels x 90 dates x 3 markets = 2,160 pages
member reads = hotels x markets, each on a sticky ISP session
per address = a few public pages, then rotate
Trim the pages to the HTML you parse; hotel pages are heavy.
Read near-term dates more often than far ones. The pool spreads it.
Staying unblocked
- Home address in the guest's market. Accuracy and reputation in one rule, and the single change that fixes most hotel setups.
- Rotate public reads, hold member sessions. Mixing the two on one pool logs you out on the second page.
- Carry cookies through a session, drop them with the IP. A fresh visitor every request is a bot tell.
- Render where the page needs it, and trim it. Some sites (Agoda) build listings client-side; wait for the cards, then read. Guides for Playwright and Puppeteer cover the wiring.
- Count success by content, not status. A 200 with an empty shell is a failed read; check for the room cards.
- Pace like a guest. The full checklist is in avoiding IP bans while scraping.
Free versus paid
A free proxy is a shared datacenter address, the profile hotel bot management challenges first, and it cannot hold a member session or represent an in-market guest. It is fine for learning and for testing a parser, which is what our free proxy list and proxy checker are for. When the rates have to come back reliably, from the right market, and the member layer has to be read, paid residential is the floor.
Why residential proxies fit hotel pricing specifically
Hotel pricing needs exactly what residential proxies provide, and the fit is even tighter than for flights because more of the price is geographic. Country Rates are literally invisible except from an in-country IP; the currency is set by the connection; the member rate needs a stable logged-in session. A residential pool reads each market's price as a local guest is shown it, holds a member session on a static IP, and spreads a comp-set shop across enough addresses that no booking site sees a monitor. Datacenter proxies fail the Country Rate test and the reputation check; a VPN gives you one market at a time. Only a residential pool does the real job, which is why every serious rate-shopping product runs on one.
Our residential proxies are $0.44/GB pay-as-you-go, no KYC and no expiring balance, so a 40-room hotel checking three competitors pays the same per read as a chain checking hundreds, and a comp-set shop bills as the bandwidth it uses. Start with the free proxy list to learn the job, move to residential when the rates have to be real, and read the business framing in proxies for hotel rate monitoring.
The limits worth knowing
Proxies read the price a guest in each market is actually shown and spread a shop so the sites see guests. They do not give you a member rate without a member account, they do not stand in for an API you qualify for, and they do not change any site's terms of service, which scraping runs against regardless of tooling. What good residential proxies buy you is the market as your guests see it, from every country that matters, which is the hard part of hotel pricing and the part they are built for.
Sources
- HProxy, proxies for Booking.com, on Country Rates, currency-by-IP and the member and mobile layers.
- HProxy, proxies for hotel rate monitoring, on rate shopping, parity and the business case.
- HProxy, proxies for Marriott and proxies for Hilton, on member rates and price-match guarantees.