A visible price and an available booking are different facts. Finding the first does not prove that the second can be observed, reused or purchased under the same conditions.
An August 2026 exploratory probe looked for prices and long-stay availability on small-business websites. The original note compared percentages across those searches and described the difference as deliberate withholding by operators.
We have withdrawn those comparative percentages. The published account did not preserve clear matched denominators: a sample of businesses, the businesses that could be reached and the pages with a relevant rate are different populations. A percentage cannot travel between them without its denominator.
What the observation can still help test
Before building a service around both price and availability, define each field and check whether the same sampled providers expose both. Record inaccessible sites separately instead of treating them as proof that no data exists. Preserve the date, the page or endpoint, the unit being booked and the length of stay.
A published monthly rate may be a general offer. A quote for specific dates may depend on availability, minimum stays, fees or eligibility. Matching one returned price to a rate card does not validate every date, every property or every interpretation of a booking response.
Availability and permission are separate
A website or booking platform can expose information while limiting reuse through its terms. Public reachability alone does not establish permission to aggregate or redistribute it. Check the current terms and obtain an appropriate agreement where needed; do not infer a permanent right from one historical request.
The earlier note quoted a platform’s terms without enough context to establish a current general conclusion. We do not repeat that interpretation as legal advice or as proof that an entire market cannot be served.
Avoid inferring motives from missing fields
A contact form can reflect business preferences, implementation limits, an old website or several other causes. An absent calendar does not establish that an operator deliberately hides inventory. Those explanations need separate evidence.
The useful design test is practical: can a reader complete the task with the data actually available and permitted for use? If the answer is unknown, preserve that uncertainty rather than replacing it with a market-wide percentage.
Our sampling-frame note explains the denominator problem, and the two-endpoint note describes another way incomplete observations can mislead a project decision.
Correction, 19 October 2026: unsupported comparative percentages, claims of operator intent and universal uncollectability have been withdrawn. Evidence grade: C: a historical exploratory observation and a method lesson, not a current market measurement.
Start with the decision, not the easiest field to collect
A reader comparing monthly places to stay needs to know whether a suitable place can be booked for the intended dates at an acceptable total cost. A researcher who collects only the advertised monthly rate has answered part of that question. The missing part may determine whether the offer is useful at all.
Write the intended decision in one sentence before designing the dataset. For example: identify providers that appear to offer a specified service for a specified period, then confirm price and availability with the provider. That is a more bounded task than promising a complete live marketplace from public pages.
The distinction changes the required fields. You need the service or unit type, geography, relevant dates, length of stay, price basis and observation time. You also need a status showing what was actually checked. A general rate page is different evidence from a returned date-specific quote, and both differ from a confirmed booking.
A collection project can still be useful when confirmation remains manual. Its value is reducing the search work without hiding the remaining work. The product should say which steps it completed and which require the user's action.
Use a matched denominator for a price-versus-availability comparison
Consider a chosen measurement exercise involving 100 sampled businesses. These are demonstration counts, not a new observation about a market. Suppose 80 websites are reachable, 60 have a relevant price and 20 return a relevant availability response.
Price coverage is 60% of sampled businesses or 75% of reachable websites. Availability-response coverage is 20% of sampled businesses or 25% of reachable websites. Those are different percentages describing the same exercise. Label the denominator rather than choosing whichever number makes the contrast larger.
There is another missing relationship: do the 20 availability responses belong to businesses with relevant prices? If all 20 overlap, 20 sampled businesses expose both fields. If only ten overlap, only ten expose both. Separate totals cannot establish the joint coverage needed for a product that requires both fields.
Record an individual outcome for each sampled business. That lets a reviewer count price only, availability only, both and neither without reconstructing the relationship from a paragraph. Keep unreachable websites distinct from reachable websites that do not expose a field. Neither category should silently disappear from the report.
The useful published result might be that the proposed workflow could be completed for a certain share of this sample under stated conditions. That is narrower than claiming businesses deliberately withhold information, and much closer to what a buyer of the research needs to know.
A booking response needs a careful status label
A response showing no matching dates is not always evidence that every unit is occupied. The request may violate a minimum stay, use an unsupported arrival day, select an unsuitable unit type or omit information the provider needs. A technical error is another possibility.
Likewise, a returned offer is not necessarily a guaranteed reservation. The offer may expire, require eligibility checks or change before checkout. Preserve the response wording and the conditions instead of translating every positive response into a permanent available flag.
A useful status vocabulary can distinguish a general published offer, a date-specific returned offer, an explicit no-match response, a request requiring contact and a technical failure. Include an unknown state for cases the collector cannot interpret reliably. Those categories are not interchangeable numerical values.
This discipline matters for an interface as much as for a CSV. A green badge saying available should have a definition that a reader can inspect. If it means only that a page contained the words book now, the badge promises more than the underlying observation supports.
Product stock has the same distinction in a different form
For a shop, a product page can advertise a price while stock is unavailable, reserved or expected later. The number physically at a location is also different from the number currently available for sale. Shopify's inventory-state documentation makes that distinction explicit: on-hand inventory includes available, committed and unavailable units.
That is a definition for Shopify's system, not a rule that every booking platform uses the same fields. Its relevance here is the need to define the operational state before interpreting a number. Twenty items in a building do not necessarily mean twenty items a customer can buy now.
A comparison tool should therefore preserve the source's unit and state. Do not relabel on-hand units as available units because both look like stock counts. Do not combine a price for one product variant with availability for another. Identity matching is part of the measurement, not an optional cleanup step.
The same care applies to a service with several locations. A price from one branch and a calendar from another do not form a valid offer merely because the brand name matches. Keep location, service and time conditions together.
Structured data helps describe an offer; it does not confirm fulfilment
The Schema.org Offer vocabulary separates price-related information from availability and other offer conditions. This is useful for organizing fields, but finding structured data on a page does not independently verify that its contents are up to date or that a transaction can be completed.
Read the visible page alongside its markup. If the markup says in stock while the page says unavailable, preserve the conflict. A parser that prefers whichever representation is easier to extract can produce a confident answer from inconsistent evidence.
Google's merchant-listing documentation also treats price and availability as distinct product information. That documentation concerns eligibility and presentation in Search. It does not turn a public page into a complete booking or inventory API.
For someone publishing their own offers, the practical action is to keep the representations aligned and explain material conditions. For someone analyzing another business, the action is to report what each representation says and avoid claiming a checkout test that was never performed.
Prices need units, fees and comparable conditions
Two offers can have the same headline price and different total costs. A monthly offer may exclude a deposit, usage charges, service fees or taxes. A nightly offer may not apply to an extended stay. A quoted starting price may apply only to a smaller unit or a limited set of dates.
Do not solve these differences by adding a guessed fee allowance. Keep the known components separate, mark missing components and label whether a total is complete. A partial known cost can be useful if it is clearly presented as partial.
In a chosen comparison, provider A lists $900 per month and provider B returns a $950 date-specific quote. If A's required fees are unknown, the dataset cannot establish that A is cheaper overall. The right next question is which additional components apply, rather than a ranking that treats unknown costs as zero.
Currency and timing matter too. Preserve the quoted currency and the capture date. If a report converts currencies, show the conversion source and date separately from the provider's original figure. A converted comparison is an analytical result, not a price the provider necessarily offered.
Design collection around permission and low impact
Public data research still needs a collection policy. Read the relevant terms, respect appropriate access controls and use an authorized interface or agreement when the task requires it. Do not bypass a login, challenge or other restriction merely because the desired field is valuable.
Limit requests to what is needed for the defined question. Avoid repeatedly testing every possible date combination against a small provider's booking system. A restrained sample can expose whether the idea is workable without behaving like an unrestricted load test.
Never create a booking or hold scarce capacity just to check whether a website works unless the provider has agreed to that test. A research request should not prevent a real customer from booking. Stop before actions that create obligations or change inventory.
Separate personal information from public offer details. A returned response may contain details that do not belong in a public dataset. Publish only what is appropriate for the research purpose, and avoid collecting sensitive data that the task does not need.
Test the collector with known cases before trusting its output
Create a small set of cases whose expected interpretation you can inspect manually. Include a clear general price, a date-specific quote, an unavailable response, a contact-only page and a failed request. Then check whether the collector preserves those differences.
Include format changes. A currency symbol, a decimal separator, a price range and a per-person rate can all confuse a parser designed for one simple price. A missing field should remain missing rather than inheriting the previous page's value.
Test entity matching as well. Similar business names are not enough to establish that two pages concern the same location or unit. Save the source address and the identity fields used to join records. Review a sample of the joined results, especially the unusually cheap or unusually available ones that a ranking would promote.
Only after those checks should a larger collection run become evidence for a coverage statement. More rows can repeat the same interpretation error at scale. A smaller inspected sample is a better starting point than a large table whose labels nobody has validated.
Build an honest useful result from incomplete information
The most helpful output may be a shortlist with specific questions to ask, rather than a supposedly live booking engine. Show the offer observed, the conditions checked, the capture time and the remaining confirmation step. Let the reader understand why an entry appears.
Do not describe every unobserved field as a market opportunity. Some gaps reflect a genuine workflow need; others reflect information that cannot responsibly be supplied without cooperation. Test whether the missing information matters enough to the user and whether a provider relationship can supply it reliably.
For a business owner, the equivalent audit is straightforward: can a customer find the relevant price, understand its basis and take the next step without guessing? A clear contact or quote workflow can be appropriate even without a public calendar. The design should explain what happens next rather than imply instant confirmation where none exists.
That is the distinction this historical probe can support. A price page is evidence of a published offer. Operational availability is a separate fact with its own conditions and observation method. A good research product connects the two carefully, labels what it cannot establish and leaves the reader with a concrete next action.
When reviewing a download, check the observation status before sorting by price. Filter to the conditions that actually match your task, then inspect the source for shortlisted entries. A low price for an unsuitable period or an unconfirmed unit is not a saving you can rely on.