Paste Booking.com hotel URLs, one per line, and the review section comes back as a table - who wrote it and which country they booked from, what they liked and what they disliked in separate columns, alongside the score, the stay date, the room they had and the kind of trip they were on. Eleven columns, one row per review.
One required field and two controls - plus one thing to set up before the first run.
booking.com/hotel/<cc>/<slug>.html URL per line - or upload a CSV, XLSX, TXT or Parquet file.PROXY_URL first. In the service's own words, Booking blocks free and datacenter IPs, so a paid residential one is needed - and your real IP is never used.The limit is per query, not per run: five hotels with a limit of a hundred is a hundred reviews from each, not a hundred altogether.
The sort opens on Most Relevant, which is Booking's own ordering rather than an unopinionated one. Lowest Scores is the setting that answers the question most people arrive with, and Older First is the rare one - it lets you read the reviews from before a refurbishment or a change of management, which no amount of scrolling the newest ones will show you.
Booking asks guests what they liked and what they disliked as two questions, and the export keeps them as two columns rather than one paragraph you have to read your way through. That is the structural reason to prefer this over a generic review scraper - though read the data dictionary first, because disliked is also the column our own runs never managed to fill.
reviewer_country, room_type and traveler_type are declared alongside the text, and that combination is what a review export is actually for: a complaint from a solo business traveller in the cheapest room is a different signal from the same words written by a family in a suite. Confirm on your own run which of them arrive filled - ours came back with the text and the country, and not the rest.
The names come from the service's own declared list, so the shape of the file is not in question. What each one contained is a much shorter story, and this page tells it rather than describing a schema as though it were a result.
reviewer_country came back blank.The names are the service's own; the behaviour is a much narrower claim, and the gap between them is the whole point of this section. Our measurements come from thirty-six rows covering exactly two hotels - twenty-two distinct reviews once the rows repeated across runs are removed. On that sample, only four of the eleven columns ever carried a value: query, reviewer_name, reviewer_country and liked. The other seven - score, review_title, disliked, date, stay_date, room_type and traveler_type - were empty on every row. They are documented because they are part of the declared schema, not because we have seen them work, and this page therefore states no format for the dates, no scale for the score and no vocabulary for the two segmentation fields. What we can tell you about the four that did work is above, and the practical parts are that liked is a truncated snippet with spaces on both ends, and that a missing reviewer_country means the country ended up inside reviewer_name. Set a paid residential PROXY_URL before your first run - the service says plainly that Booking blocks free and datacenter IPs - then spend a few free rows on a hotel you care about and read the columns yourself.
All of them start from a hotel link you can copy out of the address bar.
One bad review is an anecdote; the same sentence in thirty is a maintenance ticket. Export a property's reviews, sort by Lowest Scores, and read the text end to end - the recurring words are usually about one lift, one breakfast service or one wall.
A competing hotel's review section is the most candid description of it available, and it is public. Point the scraper at their listing and you get the same eleven columns you get for your own, so the two files compare directly.
Older First is the sort you rarely get elsewhere. For an acquisition, a franchise review or a supplier decision, the reviews from two years ago tell you whether a problem was fixed or simply buried under newer ones.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.
For every new account, one time. No credit card. All scrapers unlocked. Given how much of this schema we have never seen populated, this is the part that matters most here: spend a few rows establishing which columns your run actually fills before you plan around them.
Roughly $2 per 1,000 reviews, the same flat rate as every other scraper on the platform. The limit is per query, so ten hotels with a limit of a hundred is a thousand rows - worth the arithmetic before you start, and a good reason to narrow the sort first.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams tracking a portfolio rather than a property. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.A review is one fact about a hotel. These return the others.
The same hotel's room types and rates rather than its reviews, one wide row per property. Run both and you can put a complaint next to what the room it was about actually costs.
Properties from a destination search rather than a list you already have. Run it first when you need the shortlist itself, then bring the URLs here.
The same property judged by a different audience. Booking reviews come from people who booked there; Tripadvisor's come from anyone, and the gap between them is often the finding.
Short answer: yes, when you only collect what is publicly visible on a hotel page - and that is all this service reads.
A hotel's review section is public. Anyone can open the listing without an account and read it, and collecting publicly visible information for market and competitive research is long-settled practice. As long as the data is publicly available and the process does not disrupt the service, there are no federal laws against it.
Reviews are written by people, though, and this export carries more about them than most: a display name, the country they booked from, and - where they arrive - the room they stayed in and the kind of trip they were on. Publicly visible is not the same as free of obligation. If you store it you are handling personal data, and the GDPR and similar regimes apply regardless of where you got it. Reading complaints in aggregate to fix a property is an easy case; assembling a file about identifiable guests is not, and this service is not intended for it.
Booking's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, read only what an ordinary visitor sees, run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
Set a residential proxy, paste one hotel URL, change the sort away from Most Relevant and see what guests actually wrote. Your first 500 rows are free.
Booking reviews are written by people who actually stayed - the platform only accepts them from completed bookings - which makes the review section unusually worth reading and unusually hard to read in bulk, because it is a widget you can only scroll. This service turns it into a table. Paste Booking.com hotel URLs, one per line, and each review comes back as a row: the guest's name and the country they booked from, what they liked and what they disliked as separate columns, the score, the date, the dates they stayed, the room they had and the kind of trip they were on. Eleven columns, one row per review.
Two controls shape the run. The limit is per query rather than per run, so ten hotels at a hundred each is a thousand rows; it defaults to 100 and the field's own hint says to leave it empty for all. The sort has five settings - Most Relevant, Newest First, Older First, Highest Scores and Lowest Scores - and the first is the default. That is worth a moment's thought: Most Relevant is Booking's own ordering, not a neutral one. Lowest Scores is the setting that answers the question most people arrive with, and Older First is the rare one that lets you read what a property was like before it was refurbished.
One thing has to be set up before the first run. In the service's own words, Booking blocks free and datacenter IPs, so a paid residential PROXY_URL is needed - and your real IP is never used. Doing that first saves you an empty run and a wrong conclusion about the service.
The honest limits are stated here rather than buried, because they change what to plan for. The eleven column names are the service's own declared list and are dependable. The behaviour behind them is measured on thirty-six rows covering exactly two hotels - twenty-two distinct reviews once duplicates across runs are removed - and on that sample only four of the eleven columns ever carried a value: query, reviewer_name, reviewer_country and liked. The other seven, disliked among them, were empty on every row, so this page claims no format for the dates, no scale for the score and no vocabulary for the room and traveller fields. Two practical details about the ones that did work: liked is a truncated snippet carrying a leading and trailing space, cut at different lengths in different runs; and where reviewer_country was blank, the country had been folded into reviewer_name. Run the free tier against a property you care about and read your own columns first. Your first 500 rows cost nothing and need no credit card. See pricing for current rates.