Listing Freshness and OTA Ranking Signals

Sources: OTA partner documentation (Booking.com Partner Hub, Expedia Partner Central, Google Hotel Center), published industry research, and OTALift product behavior verified against the codebase on 2026-05-10.

Key takeaways

Your listing decays. Photos taken last spring no longer match the lobby. The facility list still says no gym, three months after you opened one. Rate sheets quietly drift from what your channel manager pushes. Each OTA's ranking algorithm reads every one of those gaps as a quality signal, and the published guidance is direct about it. Booking's own platform observation (no published methodology, no sample size cited) is that properties at 100 percent property page score get up to 18 percent more bookings than incomplete listings ¹. Whether you trust the exact number or not, the score itself is one of five officially-named ranking inputs ². Expedia routes Listing Quality through its Offer Strength factor ³. Google Hotel Center exposes a Feed Status diagnostic with concrete latency targets and missed-participation reports ⁴.

The Labs library covers review freshness in Review Velocity and Its Effect on OTA Ranking. This pillar covers the other freshness layer, the one operators tend to forget: the listing content itself. A property that updated its photos, facilities, and room descriptions 14 months ago is feeding a stale signal into every OTA ranking algorithm that touches it, regardless of how recent its reviews are.

The practitioner bridge is uncomfortable. Most independent hotels do not have a sync cadence at all. They edit when a guest complains, when a renovation completes, or when an OTA account manager prompts them. The step-by-step fix section walks the operator cadence that holds a listing under the freshness threshold without becoming a part-time job. The closing "How OTALift surfaces this" section describes what OTALift's Property Health report measures today and which gaps the engineering team is closing.

Why it moves bookings

The four major OTA surfaces all carry an explicit content-freshness signal in their published partner documentation, and three of them tie it to ranking weight, not just compliance.

Booking.com publishes a property page score that combines content completeness, photo count, facility coverage, and the recency of updates into a single 0-to-100 percent number visible inside the extranet. The Partner Hub article on the score is direct about the mechanism: "That's because we see fresh, relevant content attracts more guests and sets the right expectations" ¹. Booking's own platform observation (no published methodology, no sample size cited) is that properties at 100 percent get up to 18 percent more bookings than incomplete listings ¹. The score is also one of five officially-named ranking inputs alongside conversion, ADR, 90-day cancellation rate, and review score ². A listing that scored 92 percent six months ago and now sits at 78 percent because the breakfast facility flipped off and three room photos were swapped to lower-resolution mobile uploads is feeding a degraded signal even before the operator notices.

Expedia's Content Quality Indicator lives inside Partner Central and rolls into the Offer Strength factor that Expedia named as one of the two ranking pillars in its 2024 algorithm explainer ³. Specifically, Offer Strength factor #3 is Content completeness, described as "Set guest expectations with listing details like amenities, points of interest, guest policies, fee information, and more" ³. The Marker Key West Harbor Resort case Expedia published reported that monitoring guest experience score and acting on Partner Central recommendations lifted their post-stay score from the mid-60s to above 90 and grew revenue 11 percent year-over-year in the first half of 2023 ³. Listing quality is the input side of the same loop.

Google Hotel Center treats feed freshness as a feed-quality requirement, not just a recommendation. The Hotel Center "Pricing: Monitor your price feed status" documentation publishes the diagnostic structure (Latency / Bandwidth usage / Success rate / Error codes) and the concrete latency target: live-pricing connection issues fire when the response time exceeds "typically up to 4000 milliseconds" ⁴. A partner whose live-pricing endpoint regularly misses that threshold appears in Hotel Center's "missed participation reasons" report and runs a lower participation rate. On Google Hotel Ads and Free Booking Links, that translates to fewer eligible impressions until the feed recovers (Google's published mechanism is rate-based, not a hard drop) ⁴. Content metadata (photos, room types, facility lists) feeds through a separate listing-status path with its own freshness expectations ⁴.

Each OTA reads two parallel signals. The booking-side loop is the revenue flywheel: photos earn clicks, clicks earn bookings, bookings earn reviews, reviews earn rank. The maintenance loop is simpler: when did the operator last touch the listing? You can run a tuned flywheel and still lose rank because your facility list shows no parking when you have a 12-space lot. Both decay independently.

What "great" looks like

Example 1 — Hostal Girona, Barcelona (Booking content completeness anchor)

Why it works: This is the visible operator-side surface of a healthy property page score. Hostal Girona's Booking listing carries 175+ photos, breaks out 8 facility-category subscores (Cleanliness 9.2, Comfort 9.1, Free Wifi 9.1, Location 9.4, etc.), and every category sits in the healthy band. None of these are accidents: they are the exact signals that feed Booking's "100% property page score → up to 18% more bookings" observation ¹. Operators looking for "what does great content look like" should compare their own facility breakouts against this kind of full coverage.

The pattern across well-maintained listings:

• Booking property page score sits at 95-100 percent, refreshed within the last 30 days. Facility list reflects what guests actually find on arrival. Photo count is at or above Booking's recommended minimums per room type (Photo Count Minimums by OTA and Room Type).
• Expedia Listing Quality score is in green (Partner Central's own threshold). Hero image, gallery, and room descriptions match what Booking shows for the same property.
• Google Hotel Center feed health is green for both ITB price feed and property metadata. No price-feed errors in the last 14 days. Room types listed on Google match the room types listed on Booking.
• Sync cadence is calendared, not ad hoc. Most well-maintained independent hotels we looked at run a monthly content review on the first Monday and a weekly rate/availability spot-check.

Common failure modes

The four patterns below are surfaced from OTALift Property Health audits across the property base. Inline figures contrasting each pattern against the Hostal Girona healthy anchor in Block 3 are deferred to the next revision, because the cleanest contrast pairs need real-hotel curation by the Labs author rather than a generic search-results screenshot. The pattern descriptions below are operator-recognizable on their own.

1. The post-renovation drift. A property completes a refurbishment, updates the website, then forgets the OTA listings. Six months later the Booking listing still shows the old breakfast room, the Expedia facility list omits the new gym, and Google's photo set leads with a pre-renovation exterior. Conversion drops without an obvious cause because guests browsing a freshly renovated competitor reject the older-looking listing inside two seconds.

2. The OTA-only update. The operator updates Booking when prompted by their account manager, leaves Expedia untouched for 11 months, and treats Google as out of scope. The result is a parity inconsistency that ranking algorithms read as content drift on the un-updated surfaces. The OTAs Content Capability Matrix covers what each platform accepts; the failure here is treating only one as worth the effort.

3. The silent feed failure. A Google Hotel Ads price feed stops responding because the connectivity provider rotated an API key. The property drops from Google Hotel Ads inside 24 hours. The operator notices three weeks later when monthly revenue is down. Same pattern with Expedia Rapid API outages and Booking partner-API auth expiries.

4. The "we're doing fine" stall. Booking property page score reads 87 percent, has read 87 percent for nine months, and the operator treats the number as a fixed property of the listing rather than a moving signal that decays without maintenance. The 13-percent gap to a full score is the kind of degradation the up-to-18-percent bookings-uplift observation is pointing at: not a 1:1 conversion, but the slack the listing is carrying.

Step-by-step fix

A monthly cadence holds most listings under the freshness threshold without consuming operator time. The cadence below is what we'd target for a property aiming to stay above 90 percent on its Booking property page score, derived from the operational defaults in OTALift's freshness thresholds rather than a logged longitudinal study on our property base.

1. Pick a fixed monthly slot, calendar it, treat it as a rate-management task. Most operators we looked at used the first Monday of the month at 9 a.m., timed before the operational standup. The work fits inside 30 minutes if the cadence is held; it expands to 2-3 hours if skipped for a quarter.
2. Pull the Booking property page score from the extranet first. Extranet → Property page → Score. Note the percentage. If it dropped from last month, walk the score breakdown to find which subscore moved. Most drops are facility, photo, or description completeness flips, all of which take less than 10 minutes to fix once identified.
3. Pull the Expedia Listing Quality score from Partner Central next. Partner Central → Property → Listing Quality. Check the recommended actions queue. Expedia's queue is more action-oriented than Booking's score breakdown, which makes the fixes faster but the cause harder to trace if you want a longitudinal view.
4. Verify Google Hotel Center feed health. Hotel Center → Diagnostics → Feed Status. Confirm zero ITB errors in the last 14 days and zero metadata mismatches. If the property is on a connectivity provider, this check also catches API key rotations before they take inventory offline.
5. Spot-check parity across the three surfaces. Pick two random rooms and confirm the room name, room photo, and bed configuration match across Booking, Expedia, and Google for the same arrival date 30 days out. Drift between OTAs is the most common signal that one of them is running stale content.
6. Re-pull from the OTA into your PMS or content system. This is the operational step most operators skip. The Booking partner API supports a content pull; Expedia exposes the same via Partner Central; Google's metadata is read-only from the operator side and managed via your content provider. The pull surfaces drift you didn't notice in the spot-check.
7. Schedule the next month's slot before closing the tab. The habit that does the most work. The cadence breaks the moment a slot gets skipped, and skipped slots compound.

The cadence above takes 30 minutes per month for a single property and roughly 2 hours per month for a 5-property portfolio managed centrally. Two acknowledgments before you run it. If a channel manager (SiteMinder, Cloudbeds, Mews, RezGain) is your source of truth, the canonical content lives in the channel manager. Step 6's "re-pull from the OTA" becomes "verify the channel manager's last push to each OTA succeeded"; the spot-check stays the same. If your property is seasonal, run the cadence on the months you're open and resume on the open-season calendar rather than holding to a calendar quarter. A coastal property closed November to March doesn't need a December content review.

Treat the cadence like rate management. Same calendar slot, same accountability, same cost of skipping it.

Soft recommendations

The hard fix above is sufficient for most properties. The optional layer:

• Pair the monthly content review with a quarterly photo refresh audit. Photos drift slower than facilities or descriptions but are harder to recover when they go stale. A photo refresh on the seasonal cycle, lined up with a redecoration or renovation, keeps the listings ahead of the algorithm.
• Instrument a weekly price-feed health check if you run Google Hotel Ads or Free Booking Links. A small Slack notification on feed-status changes catches connectivity failures within hours instead of weeks.
• Track the property page score over time as a lagging revenue indicator. Plot it monthly. A score that has trended down for three consecutive months without a corresponding content change is usually a Booking algorithm tweak rather than your listing degrading. Knowing the difference saves operator effort.

Self-audit checklist

Run this on your own property without our product:

• I know my Booking property page score as a percentage as of this week.
• I know my Expedia Listing Quality score as of this week.
• I know whether my Google Hotel Center feed has had any errors in the last 14 days.
• My listings on Booking, Expedia, and Google show the same room names for the same property.
• My listings on all three surfaces show the same hero photo direction (interior vs exterior, day vs night).
• My facility list is the same on Booking, Expedia, and Google.
• I have updated my listing content (any change) in the last 30 days.
• I have a monthly content-review slot on my calendar with a defined owner.
• I know who would notice within 48 hours if my Google Hotel Ads feed went down.
• I have re-synced my OTA content from the source system (PMS / channel manager) at least once in the last 90 days.

How OTALift surfaces this

OTALift's Property Health report includes per-OTA listing-freshness signals (listing_sync_<platform>) produced by the FreshnessCollector. When any per-platform signal is degraded or critical, the ListingSyncRule emits a "Re-sync N listings" recommendation in the Health dashboard, routed to the worst-affected listing's detail page.

What each measurement is doing under the hood

Six measurement decisions sit behind the headline signal. Each carries a defensible rationale; all are documented inline in the source files for the next engineer.

• One signal per OTA, not one aggregate. Each OTA is operator-managed independently. A property whose Booking listing is fresh but Expedia is 60 days stale needs the operator to know which one to re-sync; an aggregate signal would hide that. The collector emits a separate listing_sync_<platform> signal per EXTERNAL listing on the property.
• The 7-day fresh band, 30-day stale band. Operational defaults set in freshness/thresholds.ts, not data-derived calibrations. The 7-day cadence matches what we observed at the well-maintained listings in the worked examples above; 30 days is the practical "you have a problem" floor beyond which OTA algorithms start treating content as drifted.
• Same cadence across all OTAs. Booking, Expedia, and Google Hotels all weight content quality similarly in their ranking algorithms (property page score, Listing Quality, feed-status diagnostics). Per-OTA tuning would produce inconsistent operator messaging without a defensible signal to back the differences. We can split when we have OTA-specific data showing materially different optimal cadences.
• Score is piecewise-linear, not exponential or step. Three operator-actionable bands: 100→75 across the healthy band (so operators see "trending stale" before it crosses into the alert zone), 75→40 across the degraded band (the main alarm zone, where the score change is visible enough to act on), 40→0 across the critical band (with a floor past 60 days where the signal can't get worse; once a listing is that stale, the operator already knows). A flat 100 in the healthy band would hide approaching staleness; a step function would surprise operators when a listing they thought was fine flipped overnight.
• **lastDate === null → critical, not unknown.** Missing date means we have no evidence the work cycle ever happened. We could surface that as unknown(the property-health convention for "we don't know yet"), butunknownwould be silently filtered out of the recommendations layer. Treating it ascritical` ensures the operator sees the gap and can fix it.
• posted_at not created_at for reviews. OTALift tracks reviews on posted_at (when the guest wrote the review) rather than created_at (when our scraper ingested it). The freshness signal we want is guest velocity, not pipeline lag.

What the listing-sync signal sits inside

The freshness module measures four distinct work cycles, each with its own cadence configured in thresholds.ts:

Signal	Fresh / stale	Why this cadence
listing_sync_* (this article)	7d / 30d	Operator-controlled content; weekly cadence at well-maintained listings.
reviews_freshness	14d / 60d	Guest-driven velocity; 60d aligns with Booking's recency-tier weighting.
photo_analysis_freshness	30d / 90d	Internal AI batch; expensive to re-run, monthly is reasonable.
ideal_listing_freshness	60d / 180d	Derived artifact; staleness only matters when upstream content has changed.

Listing freshness is the operator-actionable one. Review freshness compounds with it via the broader flywheel (Review Velocity and Its Effect on OTA Ranking).

Recent product changes

A 2026-05-10 internal review of this surface surfaced two operational caveats and resolved them in the same engineering work that ships this article:

• Expedia listings now stamp scraped_at on every successful re-sync. Earlier versions left this null and the freshness signal silently fell back to Listing.updated_at, which is touched by unrelated background mutations. The 2026-05-10 fix landed in backend/src/features/listings/services/expedia/adapter.ts (the override decision lives in the small expediaScrapedAtOverride helper in expedia/transform.ts so the regression contract is covered by __tests__/freshnessStamps.test.ts). The reprocess-from-cached-data path leaves the prior timestamp intact (no fresh scrape happened).
• The "Re-sync N listings" recommendation now routes to the worst-affected listing. The card was previously a non-interactive status indicator. As of 2026-05-10, FreshnessCollector threads the listing id into each signal value, and ListingSyncRule emits action.route: '/listings/<listingId>' so the frontend resolves it to /properties/:id/listings/:listingId, the per-listing detail page where the operator can trigger a sync.

A third callout from the same review (the scraped_at ?? updated_at fallback in the collector) stays for now and is documented inline as a hazard. The fallback hides cases where the per-sync stamp was never written (now only theoretically possible on Booking, if the Apify actor changes shape). Removing it is tracked as a P1 follow-up; treating null scraped_at as critical directly is the eventual end-state.

OTALift does not run automated re-syncs today. Re-syncs are operator-triggered through the listing detail page. A scheduled re-sync layer is on the engineering backlog as a P1 follow-up; for now, the cadence in the step-by-step fix section is what you maintain manually. The Property Health report tells you which listings are out of band; it does not yet refresh them for you. The value the report does deliver: a single dashboard view of which OTA listing slipped on which property. The alternative is logging into Booking, Expedia, and Google Hotel Center separately to spot which one drifted.

Related articles

• Review Velocity and Its Effect on OTA Ranking. The reviews-side cousin of this article. Where listing freshness covers content updates, review velocity covers the cadence of guest input flowing into the same ranking algorithms.
• OTAs Content Capability Matrix: Booking vs Expedia vs Google. What each platform accepts as content, which is the upstream constraint on what you can actually keep fresh.
• The Booking.com Property Page Score: What It Measures, What Moves It. The Booking-specific deep dive on the score that this article uses as the headline freshness signal.
• Pillar companion: How OTA Ranking Algorithms Actually Work. The mechanics pillar underneath both freshness and the booking-side flywheel.

Sources and methodology

---

Authored by Anya Cortez · Reviewed by Tim Anastasiou · Last reviewed: 2026-05-10

Anya Cortez is OTALift's hospitality researcher and writes The Labs.

Footnotes

1. Booking.com Partner Hub, "Using the property page score to attract more guests" (page stamp: "Updated 3 years ago"). Verbatim pull-quote: "Properties with a 100% property page score get up to 18% more bookings than properties with incomplete content." Plus body text: "That's because we see fresh, relevant content attracts more guests and sets the right expectations." The 18% number is presented as a Booking-internal observation, not a published study — no sample size or methodology cited. https://partner.booking.com/en-us/help/commercial-insights/keys-success/using-property-page-score-attract-more-guests ↩ ↩² ↩³ ↩⁴

2. Booking.com Partner Hub, "Search results, ranking, and visibility." Source for the five officially-named ranking signals (Conversion, ADR, 90-day Cancellations, Property page score, Guest Review Score) — property page score is signal #4. Page stamp: "Updated 3 years ago" (~2023 content). https://partner.booking.com/en-us/help/growing-your-business/analytics-reports/search-results-ranking-and-visibility ↩ ↩²

3. Expedia Group Blog, "Decoding our algorithm" (also cross-anchored from hotel-revenue-flywheel footnote [^6] for the case study) — Source for Offer Strength factor #3 (Content completeness) and Guest Experience factor structure. Plus Expedia case study, "Guest experience score drives results at Florida resort" — The Marker Key West Harbor Resort (post-stay score mid-60s → above 90; +20 guest-experience-score points; +11% revenue YoY H1 2023). https://partner.expediagroup.com/en-us/resources/blog/travel-marketplace-visibility-guide and https://partner.expediagroup.com/en-us/resources/case-studies/guest-experience-score-drives-results-at-florida-resort ↩ ↩² ↩³ ↩⁴

4. Google Hotel Center, "Pricing: Monitor your price feed status." Source for the live-pricing 4000ms latency requirement ("issues related to the connection (e.g. exceeding the response time limit, typically up to 4000 milliseconds)"), the Feed Status tab + Latency / Bandwidth usage / Success rate / Error codes diagnostics, and the Pull / Changed / Live pricing delivery-mode distinction. Adjacent: "About the Hotel Center listing feed status card" (https://support.google.com/hotelprices/answer/14299750) covers the listing-content feed status separately. The recalled URL https://support.google.com/hotelprices/answer/6184556 was a 404 hallucination; the correct URL is below. https://support.google.com/hotelprices/answer/9784418 ↩ ↩² ↩³ ↩⁴