Airbnb and Vrbo Occupancy Rates by City and ZIP Code

City and ZIP-code occupancy figures look precise, but they are estimates rather than booking records. I use them to compare broad market patterns, not to predict what one rental will earn. The useful work begins when I hold the source, period, property type, rate, supply, and season constant.

This distinction matters whether I am comparing Airbnb markets, Vrbo markets, or both. A percentage inferred from unavailable calendar nights cannot reveal whether every unavailable night was booked, blocked for maintenance, reserved for personal use, or unavailable for another reason. For the wider research process, I start with how to find occupancy rates and use the framework below to decide how much confidence to place in each result.

What are Vrbo occupancy rates by ZIP code?

Vrbo occupancy rates by ZIP code are third-party estimates based on calendar unavailability, not official Vrbo booking data. A market-data provider observes or models unavailable nights within a postal area and converts those nights into an estimated fill rate. The percentage can be useful for comparison, but it is not a direct count of confirmed reservations.

Here is my illustrative calculation: 180 unavailable nights among 10 listings over 30 days equals a 60% estimated fill rate. The denominator is 10 listings multiplied by 30 nights, or 300 listing-nights. Dividing 180 unavailable nights by 300 possible listing-nights gives 0.60, or 60%. The arithmetic is exact; the interpretation is not. Calendar observation cannot distinguish blocked nights from bookings.

That limitation affects the meaning of the result. Suppose my illustrative sample contains two owner-used vacation homes. Each owner blocks 15 nights for personal stays. Those two calendars contribute 30 unavailable nights even if no guest booked them. Removing those blocks would reduce the observed total from 180 to 150. The estimated fill rate would then be 150 divided by 300, or 50%, rather than 60%. Nothing about the original calendar display tells the researcher which interpretation is correct.

I also inspect the denominator before trusting a ZIP result. My illustrative sample of 10 listings gives each listing 10% of the sample weight. If one calendar is blocked for all 30 observed nights, that single rental contributes 30 unavailable nights out of 300 possible nights. A personal-use calendar can therefore move the reported result materially without producing any rental revenue.

Property mix creates another problem. A ZIP code containing small urban rentals, large homes, and seasonal second homes does not describe one competitive market. I would not compare a compact rental intended for short stays with a large home attracting a different guest group merely because both addresses share a postal code. I narrow the comparison by rental type, bedroom category, practical location, and amenities before using the average.

The best use of a ZIP estimate is screening. It can help me identify areas that deserve closer inspection, especially when the difference is large and comes from one source over one period. It should not determine an acquisition, lease, or revenue forecast by itself. The same warning applies when reviewing city and ZIP-code occupancy data or a list of markets with high occupancy estimates: the percentage is a starting point, not a property-level conclusion.

How can I measure Airbnb demand by city?

Airbnb demand by city cannot be represented by occupancy alone. I compare estimated occupancy, average daily rate, active listing growth, and seasonality from the same source and period. If regulation materially limits when or where rentals may operate, I record that separately rather than assuming the occupancy estimate already reflects it correctly.

Consider my illustrative market report showing 70% occupancy alongside 25% active-supply growth. The occupancy figure sounds strong in isolation, but the supply increase may indicate weakening demand per listing if guest demand did not expand at the same pace. I would not call the market stronger merely because the first percentage is high.

Using the same source is essential. If one provider defines occupancy against available nights while another uses all calendar nights, their percentages answer different questions. Combining one provider’s occupancy with another provider’s supply estimate can create a polished spreadsheet built from incompatible definitions.

I also keep the period identical. An annual occupancy estimate should not be paired with a recent monthly rate or a supply count from a different season. In my illustrative example, comparing a 12-month occupancy figure with a peak-month daily rate would exaggerate expected annual revenue because the strongest rate is being applied to a broader period. Instead, I compare monthly figures with monthly figures or trailing-period figures with the same trailing period.

Demand analysis should also account for how guests find listings. Airbnb publishes that quality, popularity, price, location, availability, and personalization from the guest’s history influence search results. It also says its ranking algorithms evolve over time. I therefore avoid treating city demand as something distributed evenly among all hosts. Two comparable rentals can capture different shares of the same demand because their presentation, price, availability, location, and popularity differ.

For property research, I combine the market view in choosing a short-term rental market with property-level arithmetic from rental profitability calculations. If I already operate the rental and need to improve its result, ways to increase occupancy separates practical listing changes from broad market conditions.

The central question is not simply, “Is occupancy high?” I ask whether rates support the result, whether supply is expanding, whether the pattern survives weak seasons, and whether the particular rental can compete. Occupancy becomes informative only after those pieces are placed beside it.

Can I get an Airbnb occupancy rate by ZIP code?

Yes, market-data tools publish ZIP-code estimates, but smaller samples make them less reliable than city estimates. A single operator with 12 units can materially shift the reported average in a small ZIP code. The narrower label looks more precise, yet the underlying sample can be less stable.

Here is my illustrative example. Suppose a ZIP-code sample contains 24 active units and one operator controls 12 of them. That operator represents 50% of the sample. If those 12 calendars average 75% observed unavailability while the remaining 12 average 45%, the combined estimate is 60%. The reported ZIP figure is therefore heavily shaped by one operating strategy rather than by a broad population of independent rentals.

The city figure may be more stable because it draws from a larger pool, but it can hide neighborhood differences. The ZIP figure may reflect a more relevant area, but it can be dominated by a handful of operators or unusual calendars. I do not assume either geography is automatically superior. I inspect sample size and listing composition first.

I treat the ZIP result as a hypothesis and then build a manual comparable set. I choose rentals that resemble the proposed unit in capacity, property type, quality, location, and major amenities. I record their future calendar unavailability on the same day and repeat the process consistently. That does not transform blocked dates into verified bookings, but it prevents an unrelated part of the ZIP code from setting the benchmark.

My illustrative quality-control rule is simple: if I identify 20 apparent comparables but discover that 8 are a different property type, I do not average all 20. I work with the 12 relevant rentals and disclose the smaller sample. A narrower honest sample is more useful than a larger mixed one presented as if every listing competes for the same guest.

I also test concentration. If the same operator appears to control a large share of the sample, I calculate the result both with and without that group. In the illustrative 24-unit example, I would report the 60% combined estimate, the 75% operator-group estimate, and the 45% remainder. That makes the concentration visible instead of hiding it inside one average.

ZIP estimates are particularly weak when the proposed property sits near a boundary. The guest may compare rentals on both sides, while the report stops at the postal line. In that case, a distance-based comparable set can be more relevant than the ZIP average. Postal geography is a sorting tool; it does not define every traveler’s search area.

For a fuller research process, I use the comparison of rental analytics tools alongside the occupancy calculation framework. If the objective is improving an existing listing rather than selecting a ZIP code, listing changes that affect bookings is the more direct next step.

Where can I find Airbnb rental statistics by city?

I distinguish three sources: Airbnb provides exact data only for the host’s own listings, third-party tools model citywide performance from public calendars, and municipal registers can provide exact legal-listing counts but not occupancy. These sources answer different questions and should not be merged into one supposedly authoritative city statistic.

The host’s own records are the strongest source for that host’s actual operation. They can show what happened to the listing, but they do not reveal the results of every competing rental. A personal dashboard occupancy figure and a modeled city estimate are therefore not equivalent, even when both are labeled “occupancy.”

Third-party tools offer wider coverage by estimating market performance. Their advantage is comparison across areas. Their limitation is that public calendar unavailability does not disclose why a night is unavailable. A modeled city result can be useful when I keep the method consistent and treat it as an estimate.

Municipal registers answer another question: how many rentals are legally registered under the register’s rules. They may provide an exact count of entries in that register, but that count does not reveal booking nights or occupancy. I use the register to examine legal supply, not to manufacture a demand metric the register does not publish.

Here is my illustrative source check. Suppose my own rental sold 21 of 30 available nights, giving it 70% occupancy under my calculation. A market tool reports 62% modeled city occupancy for the same month, while a municipal register lists 800 legal rentals. The figures cannot be averaged. The 70% describes my rental, the 62% describes a modeled market sample, and the 800 describes registered supply.

I record the source beside every figure in a research sheet. I also record the geographic boundary, observation period, property category, and metric definition. Without those fields, a number becomes detached from the question it answered.

For example, a city can mean the municipal boundary, a larger metropolitan area, or a provider-defined market. If my illustrative city report contains 2,000 sampled units while another report contains 3,500, the difference may come from geography or inclusion rules rather than an error. I check definitions before comparing results.

I apply the same discipline to active-listing counts. A register may count licensed units, while a model may count calendars it identifies as active. Those totals can differ because the categories are different. Neither should be relabeled to make the comparison look cleaner.

When paid market data is unnecessary, a manual sample can still answer a narrow question. I choose relevant rentals, count their calendar unavailability for one consistent window, and repeat the observation later. This produces a local comparison rather than official occupancy. Its value comes from relevance and consistency, not from pretending unavailable nights are confirmed reservations.

The research path depends on the decision. Someone considering a purchase can start with market-selection criteria and then test a specific property. Someone considering a lease should also review how rental arbitrage works and the permissions required for rental arbitrage. An existing host may get more value from examining operational performance than from buying another city report.

Which Airbnb statistics should I compare by city?

I compare occupancy, average daily rate, revenue per available night, active supply, seasonality, and regulatory limits using one source and one time period. No individual metric is enough. Occupancy explains calendar use, rate explains price, revenue per available night combines the two, supply shows competitive pressure, seasonality reveals timing, and regulation establishes whether the operating assumptions are viable.

The core calculation is straightforward. In my illustrative example, a $200 average daily rate at 60% occupancy equals $120 revenue per available night. I multiply $200 by 0.60 to get $120. This is a comparison metric before operating expenses, platform fees, taxes, financing, cleaning, maintenance, or other property costs.

The combined metric prevents a high-occupancy market from winning automatically. In my illustrative table, one city reaches 80% occupancy at a $120 average daily rate, producing $96 per available night. Another reaches 60% occupancy at a $180 rate, producing $108. The second city has lower occupancy but the higher simplified revenue measure.

I then examine active supply. If Market B’s modeled revenue measure is stable but active supply is growing quickly, future performance may be more competitive. If Market C has slightly lower modeled revenue but steadier supply and a more balanced seasonal pattern, it may deserve closer inspection. These are research signals, not guarantees.

Seasonality changes the operating burden and cash-flow pattern. An annual average can make two cities look similar even if one earns most of its revenue during a narrow peak. In my illustrative comparison, both markets average 60% occupancy for the year. One stays between 50% and 70% across observed months, while the other moves between 20% and 90%. Their annual averages match, but their staffing, pricing, and reserve requirements may not.

Regulation belongs in the comparison because revenue arithmetic cannot establish permission to operate. I verify the rules that apply to the address and operating model rather than assuming a high modeled occupancy rate implies legal availability. A market can appear financially attractive while the target property fails a licensing, lease, zoning, or building requirement.

I also separate market statistics from listing execution. Airbnb publishes that search placement is influenced by factors including quality, popularity, price, location, availability, and personalization. A city-level statistic cannot tell me how effectively one proposed listing will compete on those factors. Market demand and listing performance are connected, but they are not interchangeable.

Once a rental is operating, I compare its result with a carefully selected comp set rather than treating the city average as a target. If the property trails relevant competitors, I examine presentation, availability, pricing, guest communication, reviews, and avoidable calendar gaps. The search-ranking factors that are publicly documented, the economics of gap nights, and the comparison of pricing tools address different parts of that work.

BnBGenius is not a pricing tool, channel manager, calendar-sync product, direct-booking system, or owner-accounting system. We answer guest messages on Airbnb and Vrbo around the clock, request guest reviews and publish host reviews, create cleaning and repair tasks after checkout, answer guest calls through a voice AI agent, and sell empty nights, early check-in, and late checkout. The product is controlled through Telegram and installs as a Chrome extension in about 5 minutes without API keys or password sharing.

Pro costs $10 per month per unit. One unit means one rentable accommodation, including when the same accommodation appears on both supported platforms. The free tier includes the first 500 messages, all features, and requires no card. Voice Concierge costs an additional $7 per month per unit, includes 20 resolved calls per month, and then costs $0.35 per call. Current product details are on BnBGenius pricing, while Airbnb automation explains the operational category.

I would not use automation software as a substitute for market research, legal checks, or property-level underwriting. I would use city statistics to create a shortlist, ZIP estimates to narrow the search cautiously, comparable listings to test the address, and actual operating data to judge the rental after launch. If calendar distribution is the missing capability, channel managers for Airbnb and Vrbo covers that separate job; BnBGenius does not provide channel management or calendar synchronization.

The final comparison sheet should preserve uncertainty instead of hiding it. I label occupancy as estimated when it comes from public calendar modeling, keep platform records separate from city models, and treat municipal counts as supply data rather than occupancy. That produces a less dramatic answer than a single city ranking, but it is far more useful for deciding what an address can realistically support.