Offer schema carries the transactional data Google reads on a listing page. Missing fields kill rich-result eligibility.
- ✓ price, priceCurrency, availability, and businessFunction are the load-bearing fields for rich-result eligibility.
- ✓ businessFunction is what distinguishes a sale listing from a rental listing in the schema graph.
- ✓ The data should flow from the RESO Web API rather than from CMS fields or the page-publish layer.
The Offer schema at the field layer, the transaction-type layer, and the data-sourcing layer and how each layer feeds rich-result eligibility.
Schema.org's Offer type nests inside the RealEstateListing node via the offers property. The Offer carries the transactional data Google reads on a listing page: the asking price (or monthly rent for rentals), the currency, the availability status, and the businessFunction that distinguishes a sale listing from a rental listing. Missing or malformed Offer fields suppress the listing's eligibility for the rich-result surfaces Google evaluates against the structured-data graph, regardless of how the listing copy reads. The data should source from the RESO Web API feed through the brokerage's IDX integration rather than from CMS fields or the page-publish layer, because the MLS is the canonical timestamp Google trusts under the NAR Clear Cooperation Policy. SEO for real estate brokerages at the schema layer routes Offer-field generation against the RESO Property Resource so the schema validates and the rich-result eligibility holds across the listing inventory.
The four required Offer fields for a real estate listing.
price (numeric, no currency symbol). priceCurrency (ISO 4217 code, typically USD for U.S. listings). availability (https://schema.org/InStock for active listings, OutOfStock for sold or off-market). businessFunction (https://schema.org/Sell for sale listings, https://schema.org/LeaseOut for rentals). The Offer node nests inside the offers property of the RealEstateListing node. Without these four fields populated correctly, the listing is ineligible for the listing-specific rich-result surfaces Google evaluates. Optional but recommended fields: validFrom and validThrough for time-bound offers, seller as the listing brokerage entity, areaServed for the listing's geographic relevance.
Sale-listing versus rental-listing schema differences.
The businessFunction property carries the distinction. For sale listings, businessFunction sits at https://schema.org/Sell and the price field carries the asking price. For rental listings, businessFunction sits at https://schema.org/LeaseOut and the price field carries the monthly rent (or the rent over the lease period if quoted differently). Rental listings additionally use the leaseLength property on the listing (Duration in ISO 8601 format, e.g. P12M for a twelve-month lease). The transaction-type distinction is load-bearing for Google's structured-data parser because the listing pattern in either direction (price displayed without explicit businessFunction) produces ambiguous rich-result eligibility and broken SERP features.
Where the Offer data should come from on a real listing.
The RESO Web API feed via the brokerage's IDX integration. Property Resource fields map almost 1:1 into Offer slots: ListPrice into price, StandardStatus or MlsStatus into availability, ListingContractDate into validFrom, ExpirationDate into validThrough. Currency code is constant USD for U.S. MLSs. The brokerage's RealEstateAgency node populates seller. Pulling Offer schema fields from the page-publish date or from manually-entered CMS fields breaks the freshness signal Google trusts under the Clear Cooperation Policy datePosted carriage, and creates schema-validation drift when the MLS-side data updates and the CMS-side does not.
Rich-result eligibility and the validation pattern that holds it.
Google evaluates rich-result eligibility against the structured-data graph at crawl time. Listings that ship the four required Offer fields plus the recommended fields and clear Schema.org validation against Google's Rich Results Test are eligible for the listing-specific rich-result surfaces. Listings that miss fields, malform fields (price as a string with currency symbol, businessFunction omitted), or that fail Schema.org validation lose eligibility for the surface even when the listing copy and the IDX integration are otherwise solid. The operating pattern routes Offer generation through a single tested generator that validates every output against the Rich Results Test before the listing ships.
What operators ask about Offer schema on listings when they audit rich-result eligibility.
[ 01 ] Which Offer fields are required for a real estate listing to ship rich-result-eligible schema? +
[ 02 ] How does the schema differ between a rental and a sale listing? +
[ 03 ] Where should the Offer schema data come from on a real listing? +
If Offer fields are missing, malformed, or pulled from the wrong source, rich-result eligibility is dead regardless of how the listing copy reads. Book a diagnostic.
We audit the Offer schema on every listing template, the RESO Web API to Offer field mapping, the sale-versus-rental businessFunction carriage, and the Rich Results Test validation status. Output is the per-template fix ledger plus the schema-generator rebuild path.