Real Estate Schema: What to Mark Up and What Google Supports

Real estate schema becomes confusing when three different questions are collapsed into one:

Is the type or property valid in Schema.org?
Does Google currently support a search feature for it?
Are the values true, visible, and maintained on this page?

A page can pass one test and fail the other two. RealEstateListing is a real Schema.org type. Google currently documents no generic property-listing rich result for it. Perfectly valid JSON-LD can also contain a false price, invented affiliation, or stale availability.

Start with Google’s structured-data gallery when the goal is a Google search feature. Google’s own feature documentation controls eligibility; the larger Schema.org vocabulary does not create features by itself. Google also states that correct markup does not guarantee display. See the structured-data introduction and general policies.

The practical use of schema is narrower and still worthwhile: restate visible facts in a consistent machine-readable model, qualify for a documented feature where one fits, and make entity relationships explicit without asking the markup to manufacture authority.

Use different types for the brand, office, person, and listing

The names are misleading enough to deserve a decision table.

Thing on the page	Useful type	Important boundary
Brokerage brand	`Organization`	The brand is not automatically a physical local business location
Staffed brokerage office	`RealEstateAgent`	Despite its singular name, Schema.org defines this as a `LocalBusiness`, `Organization`, and `Place`, rather than a person
Individual agent or broker	`Person`	Use `worksFor` for a true relationship with the brokerage organization
Page about one individual agent	`ProfilePage` with a `Person` as `mainEntity`	Google supports ProfilePage markup when one affiliated person or organization is the page’s primary focus
Property-listing page	`RealEstateListing` with a property entity and `Offer`	Schema.org-valid; no current generic Google property-listing rich result

RealEstateAgency is not a current Schema.org type. The valid type is RealEstateAgent, whose definition describes a real-estate agency as a local business. Using RealEstateAgent for an individual person because the English label sounds right creates the wrong entity model.

Agent profile example

This example gives the brokerage a stable organization identity and models Jane Doe as a person on a page primarily about Jane. Replace every value with a visible, verified fact.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#brokerage",
      "name": "Example Realty",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "ProfilePage",
      "@id": "https://example.com/agents/jane-doe/#profile",
      "url": "https://example.com/agents/jane-doe/",
      "mainEntity": {
        "@type": "Person",
        "@id": "https://example.com/agents/jane-doe/#person",
        "name": "Jane Doe",
        "jobTitle": "Real estate salesperson",
        "worksFor": {
          "@id": "https://example.com/#brokerage"
        }
      }
    }
  ]
}

worksFor describes an actual person-to-organization relationship. parentOrganization describes one organization as a suborganization of another organization. It is therefore a possible relationship for a branch or subsidiary, rather than a required agent-affiliation field.

Neither property transfers “entity authority.” Schema.org defines the relationship; Google does not document a ranking inheritance mechanism behind it.

Google’s ProfilePage documentation controls its Search feature requirements. The visible page still needs to focus on that person and display the marked facts. A sitewide author byline does not make every article a ProfilePage about the author.

Brokerage office example

Use RealEstateAgent for an actual staffed real-estate office. Do not publish a hidden home address merely to complete a markup example or pursue LocalBusiness eligibility.

{
  "@context": "https://schema.org",
  "@type": "RealEstateAgent",
  "@id": "https://example.com/offices/austin/#office",
  "name": "Example Realty Austin",
  "url": "https://example.com/offices/austin/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Main Street",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "telephone": "+1-512-555-0100",
  "parentOrganization": {
    "@type": "Organization",
    "@id": "https://example.com/#brokerage",
    "name": "Example Realty",
    "url": "https://example.com/"
  }
}

Google’s LocalBusiness documentation requires a name and physical address for the supported feature. The page and markup should represent the same location. An areaServed property cannot replace that address requirement.

What `areaServed` actually says

areaServed describes the geography where a service or offer is provided. It can be useful when the page visibly states the same coverage. It does not create extra offices, verify a service area, replace Google Business Profile configuration, or carry a documented local-ranking benefit.

Use the simplest accurate value. Named cities or counties are easier to maintain than a decorative polygon nobody updates. If the business serves several states, list only the places the visible page and actual operation support. The local SEO guide for real estate agents covers the profile and page decision separately.

Rental-listing example

This is a Schema.org model. It is not a promise of a Google property rich result.

{
  "@context": "https://schema.org",
  "@type": "RealEstateListing",
  "@id": "https://example.com/listings/123-main-st/#listing",
  "url": "https://example.com/listings/123-main-st/",
  "name": "123 Main Street for rent",
  "datePosted": "2026-08-12",
  "mainEntity": {
    "@type": "SingleFamilyResidence",
    "@id": "https://example.com/listings/123-main-st/#property",
    "name": "123 Main Street",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "123 Main Street",
      "addressLocality": "Austin",
      "addressRegion": "TX",
      "postalCode": "78701",
      "addressCountry": "US"
    },
    "numberOfBedrooms": 3,
    "numberOfBathroomsTotal": 2,
    "floorSize": {
      "@type": "QuantitativeValue",
      "value": 1800,
      "unitCode": "FTK"
    }
  },
  "offers": {
    "@type": "Offer",
    "@id": "https://example.com/listings/123-main-st/#offer",
    "url": "https://example.com/listings/123-main-st/",
    "price": 2800,
    "priceCurrency": "USD",
    "businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
    "leaseLength": "P12M"
  }
}

RealEstateListing, businessFunction, and leaseLength are valid Schema.org vocabulary. LeaseOut makes the rental transaction explicit. Sell is already the default business function in Schema.org.

Every value in the example should also appear on the page and stay synchronized with the listing. Price, currency, availability, address, property facts, and lease term can all become false after one feed or template failure.

Use the webpage publication date for `datePosted`

Schema.org defines datePosted as the publication date of an online listing. That is not automatically the MLS contract date or the first timestamp at which MLS participants could see the record.

The RESO Data Dictionary defines ListingContractDate as the date of the listing agreement and OriginalEntryTimestamp around original entry into the MLS system. Either can differ from the first publication on this particular public website.

Use the real first-publication date for the page when it is known and visible. Omit the field when the system cannot establish it. Recycling the CMS modified date on every update turns the field into a freshness costume.

Visible disclosure and JSON-LD do different jobs

Structured data is invisible to ordinary readers. It cannot satisfy a requirement for a fact to be visibly and readily disclosed.

For example, the 2026 NAR Standard of Practice 12-9 requires covered REALTOR® firm websites to visibly show the firm’s name and relevant states of licensure. A parentOrganization edge in JSON-LD does not fulfill that visible disclosure. The rule also does not make parentOrganization a universal schema requirement. See the current NAR Code of Ethics.

Apply the actual rule on the visible surface, in its real jurisdiction and scope. Then make the structured data agree with the visible facts.

Validate the right layer

Use this order when implementing or debugging real estate schema:

Check the page first. It should return the intended status, use the intended canonical, and be indexable when search visibility is the goal.
Name the Google feature. Find it in the current Search gallery. If no feature exists, label the work as Schema.org modeling.
Compare markup with visible facts. Check names, URLs, affiliations, address, price, status, dates, and image rights against their authoritative source.
Parse the JSON. A deploy guard should reject malformed JSON-LD before production.
Run Schema Markup Validator. Fix vocabulary, type, and property-range errors.
Run Rich Results Test only for a documented Google feature. “No supported item” is an expected result for an ordinary RealEstateListing; it does not mean the JSON is malformed.
Inspect the deployed URL. Use Search Console URL Inspection to verify rendered markup, selected canonical, and index state.
Test listing lifecycle states. Check active, pending, sold, withdrawn, expired, and relisted pages as the local data and publication rights permit.
Monitor the applicable Search Console reports. Enhancement reports, Unparsable Structured Data, and Manual Actions can reveal different classes of failure.

A validator can prove syntax and vocabulary conformance. It cannot prove that a brokerage relationship is true, an address should be public, the page qualifies to rank, or the markup caused a ranking change.

Structured data belongs inside the website’s wider templates and lifecycle. The IDX and MLS guide explains the data and permissions behind listing pages, while IDX SEO implementation covers the resulting website behavior.