We hold ninety rows from three successful runs over one city, and the finding that matters most is not about hotels. Three of the sixteen columns appeared or vanished depending on the presentation the site served that day - the currency, the distance unit, the tax line and the star field all moved together. Read this before you diff two exports.
This is the finding to plan around. Two of our runs came back with prices in one currency and distances in miles; the third came back in another currency with distances in kilometres. That much is cosmetic. What is not cosmetic is that three columns moved with them: the run in the second currency carried a tax line on every single row and a star field on nearly all of them, and carried no was-price at all. The two runs in the first currency were the exact mirror - a was-price on some rows, and no tax line or star field anywhere. Same site, same city.
Across ninety rows the field took six values and no others: empty on more than half, and otherwise 4, 8, 12, 16 or 20 - always a multiple of four, never a 1, 2, 3 or 5. The two properties carrying the top value are the two luxury hotels in the set; the ones carrying the lowest are budget hotels. So the column is consistent with four times a one-to-five rating. We are not going to state that as fact, because we could not check it against the live listing - see the note on access below.
Every row carries a price and none carries a date. The check-in and check-out the price applies to live inside the link, in its querystring, and in our runs they landed about a fortnight after the run itself. So a price column compared across two exports is comparing two different nights unless you pull the dates out of the URL first. The occupancy column is no help either: it read the same on all ninety rows, because it is the search's default rather than anything about the hotel.
We ran the identical query four days apart and the two result sets shared no hotel pages at all. A third run shared four. That is what you would expect from a page ranking availability for a specific night rather than listing a city's hotels - but it means this export is a snapshot, not a register. Do not build a stable hotel list from it; build a time series and key it on the hotel page address with the tracking parameters stripped.
Two of our five runs returned nothing at all - an empty file, no rows, no explanation. Every catalogue service we run writes a per-row flag that records a block or a rejected input; this one has no such column, so when a run comes back empty there is nowhere for a reason to live. Plan for it: check the row count yourself, and treat zero as something to retry rather than as an answer.
Most columns use an empty string when there is nothing to report. Two - the tax line and the deal label - use a JSON null instead, and never an empty string. A loader that tests only for one of the two will silently mis-handle the other, and these are exactly the fields you would filter on to find discounted rooms. It is a small thing that costs an afternoon if you meet it late.
Read from a real export, in sheet order, with fill counts measured across all ninety rows we hold. Where a column is described as sometimes absent, the note says what it depends on - because on this service that is usually the run rather than the hotel.
rating: the lowest score in our data sits on three reviews.taxes, an absent value is a JSON null rather than an empty string.Sixteen columns per row · CSV, JSON or Excel
Two structural facts sit above every column note here. The first is that this export has no status column. Every other service we run writes a per-row flag recording whether the fetch succeeded, was refused or was given the wrong kind of input - and that is how two of our five runs would have explained themselves. They returned zero rows and nothing else, so the file cannot tell you whether the search was empty, the page did not load, or something in between. Check the row count in your own pipeline and treat a zero as a retry. The second is that three columns depend on the presentation rather than the property. The run served in the second currency carried a tax line on every row and a star value on nearly every row, and carried no was-price at all; the two runs served in the first currency were the exact mirror. The distance unit switched with them. That means a naive diff of two exports will report that hotels gained and lost attributes when nothing about them changed - so record which currency a run came back in and compare like with like. Everything else is ordinary: nine columns arrived on all ninety rows, the score and its review count on all but one, and the remaining fields are genuinely optional in the way you would expect.
Run the same destination on a schedule, pull the check-in date out of the link, and you have a rate series per night rather than per run. Key it on the property page with the tracking parameters stripped, and record the currency alongside - that pair is what makes two runs comparable.
The was-price and the deal label together tell you which listings are cutting rates and which are running a named campaign. Both are optional, and one of our rows was discounted without carrying a label - so compute the gap from the two price columns rather than trusting the label alone.
Ninety rows over one city gave us scores from the low ones to the mid nines and review counts from a single review to several thousand. That is enough to describe a market's shape - as long as you remember you are describing the listings available for one night, not the city's hotel stock.
Each row names the specific room the price is for, so a comparison between two properties is really a comparison between two room types. Normalise that column first - some values carry a stray bed label - and the resulting table is far more honest than a bare price-per-hotel list.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned. One search URL produced forty-odd rows on two of our runs and none on two others, so the cost of a job follows what comes back rather than how many searches you queued.
Credits do not expire on a monthly cycle, so a schedule that runs weekly and occasionally comes back empty does not quietly drain anything.
LIVESCRAPER10 at checkout.The same question asked of a different marketplace - accommodation search results as a dataset, with its own set of caveats about what a search page can and cannot tell you.
Where the search export gives you a score and a count, this one gives you the reviews behind them - the natural second step once a shortlist exists.
A second opinion on the same properties from a different audience - useful when a listing's score on one platform and its reputation on another disagree.
A dated image of the results page beside the rows, which matters more here than usual - the same search returns different hotels from one week to the next.
Rates, scores and room names on a public results page are ordinary commercial facts. What deserves care here is the layer in front of the site, and the fact that we could not get past it ourselves.
A nightly rate, a property name and a room type are facts about accommodation offered for sale, read from a page served to any visitor. Nothing in the sixteen columns describes a guest: no name, no email address, no phone number, no booking reference. The review counts and scores are aggregates the site publishes on the listing itself, not individual reviews attached to individual people - so the data-protection questions that shape our people-facing services stay out of this one. What the export does carry is a link decorated with an affiliate identifier and a session token, which is worth stripping before you store rows anywhere shared.
The site's stated preference is permissive on the paths this service uses. Its robots.txt answered a plain request with HTTP 200 on 12 August 2026, and read with a proper group matcher the general group carries seventy-one rules and no blanket exclusion; both the search-results path and the property pages our rows link to are allowed. The bare exclusions in that file belong to a handful of specifically named crawlers, not to general ones. The runtime is a different matter, and we would rather be plain about it than imply we walked in: an ordinary request from us for a property page and for the search path both came back with a challenge page rather than content, so we could not corroborate a single row against the live listing. Everything on this page therefore comes from the export itself. Our own catalogue records that this service needs a paid residential proxy, and names a different protection vendor than the one our probe encountered. We report both and pick neither.
Our own terms are the same as on every other service here. Publicly available pages only, nothing behind a login, no third-party trackers on the data layer, and exports auto-delete after 30 days. Your first 500 rows are free and need no credit card.
Hotel, score, review count, location, room type, price and a link - one row per search result. Read the note on how the columns shift with the presentation before you diff two exports. Your first 500 rows are free, then $0.002 each.
Booking.com is one of the largest accommodation marketplaces in the world, and this service turns one of its search-results pages into a table: one row per listing, sixteen columns, covering the property name, its guest score and review count, the neighbourhood, the distance from the centre, the specific room the quote is for, the nightly rate, any struck-through was-price, any tax line, any promotional label, a link and a thumbnail. We hold five runs over a single city, three of which returned rows - five, forty-three and forty-two of them - and two of which returned nothing at all. Ninety rows is a reasonable basis for describing what the export looks like, and it is what every figure on this page is measured from.
The most useful thing we found is not about hotels. Two of our runs came back with rates in one currency and distances in miles; the third came back in a different currency with distances in kilometres. That much is cosmetic. What is not cosmetic is that three columns moved with the presentation: the run in the second currency carried a tax line on every single row and a star value on nearly all of them, and carried no was-price anywhere, while the two runs in the first currency were the exact mirror - a was-price on some rows and no tax or star field at all. Nothing about the properties changed between those runs. If you diff two exports without recording which presentation each came back in, the diff will tell you that hotels gained and lost attributes, and it will be wrong.
Two more structural points are worth knowing before you write a loader. The first is the star column, which does not hold a number of stars: across all ninety rows it took only the values four, eight, twelve, sixteen and twenty, or nothing at all - never a one, a two, a three or a five. The properties carrying the highest value are the luxury hotels in the set and those carrying the lowest are budget ones, so the field is consistent with four times a conventional one-to-five rating. We stop short of stating that as fact, for a reason given below. The second is that the price has no date attached to it. Every row carries a rate and none carries a night; the check-in and check-out the rate applies to sit inside the link's querystring and nowhere else, and the occupancy column is identical on all ninety rows because it reflects the search's default rather than the listing. Two prices compared without first extracting those dates are two different nights.
There is also a limit on this page that we would rather state than paper over. On 12 August 2026 the site's robots.txt answered a plain request and is permissive on the paths this service uses - seventy-one rules in the general group, no blanket exclusion, and both the search path and the property pages allowed. But an ordinary request for actual content, on a property page and on the search path alike, came back as a challenge rather than a page. So unlike most of our catalogue pages, no row here has been corroborated against the live listing; everything is measured from the export. Our own service catalogue records that this scraper needs a paid residential proxy and names one protection vendor for the site, while our own probe met a different one - two names for the same layer, and we report both and pick neither. Finally, treat each export as a snapshot rather than a register: we ran the identical query four days apart and the two result sets shared no property pages at all, which is what a page ranking availability for one night will do. Publicly available pages only, no third-party trackers on the data layer, exports auto-delete after 30 days, and your first 500 rows are free with no credit card.