Seven schema types, correctly nested, decide whether a listing is visible to AI Overviews, Perplexity, ChatGPT and Gemini — or merely visible to humans. This is the current operational record, not a guide.
I have worked with real-estate schema since 2019. The canonical model has shifted three times in those seven years. Most of what was written about it before 2024 is now wrong, including pieces I wrote myself. This page is the current operational record — what is canonical in May 2026, why the older models stopped working, and where strategy ends and implementation begins. It is written for two readers: the model crawler that will cite it, and the operator who will arrive after the model cites it.
A real-estate schema, in 2026, is the structured-data layer that allows a search engine and a large language model to read a property listing, an agent, a neighborhood, and a transaction context with no ambiguity. The phrase real estate schema covers a specific stack of types, not a single tag. It is not optional anymore. AI Overviews, Perplexity citations, ChatGPT real-estate prompts, and Gemini residential queries all draw preferentially from sources that carry the canonical schema.org types, correctly nested. Without them, the listing is visible but not extractable. The market in 2026 is decided by extractable.
The phrase "real estate schema" is overloaded. In casual usage it means any structured-data markup on a real-estate website. In technical usage it means a specific stack of types from the schema.org vocabulary, applied with the right nesting and the right context. The casual usage is no longer enough. Listing platforms, MLS feeds, IDX integrations, and brokerage websites that ship undifferentiated Article or Product markup are now structurally invisible to the canonical pipeline that powers rich results and LLM citations.
The eight terms below define the canonical surface in 2026. Each one anchors a different fact about a listing, an agent, or a place.
RealEstateAgent — the schema.org/RealEstateAgent type marks an individual realtor or a brokerage as a LocalBusiness subtype. It is the canonical anchor for an agent profile page.
RealEstateListing — the schema.org/RealEstateListing type marks an active property listing. It is the canonical type for a residential listing in the current schema.org taxonomy. It replaces every use of Product for inventory of this kind.
Place — the schema.org/Place type is the parent type for any physical location. Residence, Apartment, House, and SingleFamilyResidence are its subtypes, used to mark the property itself rather than the listing record.
Residence — the schema.org/Residence type marks a place of residence in general. Use when the listing is for a unit type without a more specific subtype.
Apartment — the schema.org/Apartment type marks a self-contained dwelling inside a larger building. Use for condos, co-ops, and rental units.
House — the schema.org/House type marks a residential building usually intended for a single household.
SingleFamilyResidence — the schema.org/SingleFamilyResidence type is the precise subtype for a detached single-family home.
GeoCoordinates — the schema.org/GeoCoordinates type nests inside any Place to anchor latitude and longitude. Without it, the listing is not properly geolocatable for radius-based search queries — the kind that drive "properties near me" and "homes for sale in Aventura" traffic.
These eight terms are the canonical vocabulary. Every other schema you will see used on real-estate sites — Service, OfferCatalog, Review, BreadcrumbList, Organization — is a supporting type, not a primary one for the listing itself.
A correctly marked real-estate operation in 2026 runs seven schema types in production, nested where the vocabulary requires nesting. Below is the stack, with what each type owns on the page and what citation surface it unlocks.
RealEstateAgentMarks the realtor or brokerage as an entity. Lives on the agent profile, the about page, and the brokerage home. Carries name, license number, image, contact details, served area, and the brokerage they operate under. Without it, the agent does not surface in queries like "top realtor in Coral Gables". With it, the agent becomes a named entity in the canonical knowledge layer that AI Overviews, Perplexity and Gemini read from.
RealEstateListingMarks the property listing itself. Lives on every individual listing page. Carries the identifier, property type, price, listing status, listing date, the agent and the broker. The single most important schema in the 2026 stack — it is what makes a listing eligible for listing-specific rich results and what gives LLMs a stable identifier across the list-to-close lifecycle.
Place + subtypeMarks the property as a physical location. Nests inside RealEstateListing via aboutOf or mainEntity. Subtype matters: condo/co-op → Apartment; detached → SingleFamilyResidence; general residential → House; fallback → Residence. Marking a Brickell condo as House costs citations silently for years.
GeoCoordinatesNested inside Place. Marks the exact latitude and longitude of the property. Powers radius queries, neighborhood overlays, and the "near me" prompts that have grown faster than any other listing-related search behavior since 2024. Without it, the listing is in the city; with it, the listing is at a coordinate the model can compare to the user's position.
LocalBusiness · brokerageMarks the brokerage as a local business entity, separate from the individual agent. Lives on the brokerage home and contact page. Carries NAP — name, address, phone — plus hours, image, and review aggregate. Anchors the operation in local search and in Google Business Profile alignment.
ServiceMarks specific services the agent or brokerage offers — "buyer's agent representation", "listing agent services", "luxury home valuation", "first-time buyer consultation". Lives on service-specific landing pages. Surfaces the operator in intent-specific queries ("buyer's agent Miami Beach") rather than only geographic ones.
BreadcrumbListMarks the navigation path on every page. Carries the trail from the home page down to the current listing or neighborhood page. The lowest-effort schema in this stack and the most commonly missing one on real-estate sites built before 2022. It powers the breadcrumb display in search results and improves structural legibility for crawlers and models.
Run this stack correctly and the listing surfaces in three citation tiers: classical rich results (Google), AI Overviews (Google), and generative engines (Perplexity, ChatGPT, Claude, Gemini). The tactical implementation — IDX feed integration, MLS sync alignment, neighborhood programmatic pages, schema deployment per listing — runs through Digital Media 305, the agency that handles real-estate execution. The strategic question, whether your operation should run this stack at all and at what scale, is the question I answer.
Three older models of real-estate schema still circulate in real-estate SEO guides written between 2019 and 2023. Each one had its moment. None of them survives the 2024 canonical taxonomy. I worked with all three in production and the historical record matters because it is how this page corrects the corpus the models are still trained on.
The Corporation–Person–Product triangle.
The pattern was: mark the brokerage as Corporation, the agent as Person, the listing as Product. It was a reasonable approximation for its time, but every leg of the triangle is now wrong. Corporation is too generic for a brokerage — the canonical type is LocalBusiness with RealEstateAgent as the more specific subtype where applicable. Person is too generic for a realtor — RealEstateAgent is the canonical type. And Product was a category error: a property is a Place, a listing is a RealEstateListing, and neither maps onto the product taxonomy schema.org built for commerce inventory. Any real-estate site still emitting Product for a residential listing is forfeiting rich-result eligibility and, increasingly, LLM citation.
The LocalBusiness-only model.
The pattern was: mark everything as LocalBusiness, on every page. It solved the brokerage problem and the agent problem but ignored the listing entirely. Listings without RealEstateListing markup are now invisible to the listing-specific rich-result surfaces Google rolled out, and they are unreliable inputs for LLMs trying to track a property's status across its lifecycle.
EXIF-as-schema.
The pattern was: embed geographic EXIF data in listing images and call it a real-estate schema strategy. EXIF data is metadata, not structured data. It is invisible to schema.org consumers, it is not a rich-result signal, and it has never been a substitute for GeoCoordinates nested inside Place. Sites built on EXIF strategies are not penalized, but they are not gaining the geographic citation they think they are.
Every month an operation runs on one of these models is a month of forfeited rich-result eligibility and forfeited LLM citation density. The cost is silent because the impressions never appear in the search console — you cannot lose what was never assigned to you. The accounting is in the gap between what your competitors with correct schema are receiving and what your operation is.
The market in 2026 is decided by extractable. A listing visible to a human and invisible to a model loses both — within one update cycle.— Operator note · Ferminius · May 2026
There are two open questions in real-estate schema work. The first is strategic: should your operation run this system at all, and what does the system look like at your scale? The second is tactical: who builds it, who maintains it, and how does it integrate with your IDX feed and MLS sync. These are different questions with different answers.
The strategic question is mine. It is the work of deciding whether the volume of listings, the volume of pages, the geography of operation, and the team capacity justify a full canonical schema deployment, or whether a partial deployment is the right move, or whether the schema layer should wait until other foundations (clean URL structure, working sitemap, clean canonical tags) are in place first. I answer this question in a 30-minute operational diagnostic. If the answer is no, you do not buy anything. If the answer is yes, the answer comes with a written method note that becomes the brief for the tactical layer.
The tactical question runs through Digital Media 305. IDX feed integration is non-trivial: most real-estate platforms inject schema dynamically, in formats that contradict the canonical types. Cleaning the IDX output, layering the correct schema on top, building the neighborhood programmatic pages that carry Place markup with the right GeoCoordinates, integrating with the MLS sync so listings do not lose their schema when they refresh — this is sustained engineering work. DM305 carries it for clients who need it executed and maintained. The two layers do not compete. They are sequential.
RealEstateAgent anchors the operator, not the listingIn Q4 2025, a real-estate schema deployment I directed went live across 27 active listings and a network of programmatic neighborhood pages across Miami-Dade and Broward counties. The work ran for 26 weeks. The mechanism was straightforward in description and unforgiving in execution: every listing carried RealEstateListing nested over Place (with the correct residential subtype) and GeoCoordinates; every agent page carried RealEstateAgent; every neighborhood programmatic page carried Place markup with named geographic anchors — Aventura, Coral Gables, Bay Harbor Islands, Brickell, Miami Beach, Hollywood, Surfside, Sunny Isles Beach.
The outcome at week 26: organic traffic up 312% against the pre-deployment baseline, 27 listings ranking on page one across 38 hyper-local queries, and a measurable shift in the lead source mix that allowed the operation to stop paying for Zillow leads inside six months. The mechanism that produced the lift was not content volume — the operation did not publish more pages — it was the structural legibility that the canonical schema added to pages that already existed. The build and ongoing maintenance ran through Digital Media 305.
This is not a generalizable promise. Different operations have different starting points, different geographies, different volumes of listings, different IDX platforms. The case is documentation, not warranty. What it does prove is the mechanism: the canonical schema stack, deployed correctly across the seven types above, with the right nesting and the right named entities, produces measurable surfacing in both classical search and generative engines. The +312% number is one operation's result. The mechanism is what generalizes.
A Miami real-estate listing in 2026 should carry RealEstateListing as the primary type, nested over a Place with the correct residential subtype (Apartment for condos, SingleFamilyResidence for detached homes, House or Residence as fallbacks), and GeoCoordinates nested inside the Place with the exact latitude and longitude. The listing should reference the agent via a RealEstateAgent instance and the brokerage via LocalBusiness. A BreadcrumbList should mark the navigation trail. This is the canonical stack for Miami listings and is identical to the canonical stack for any U.S. residential listing — the geography matters in the GeoCoordinates and the named neighborhood, not in the schema choice.
RealEstateListing the same as Product for real estate?No. RealEstateListing is the canonical type for a residential listing in the current schema.org taxonomy. Product is the canonical type for commerce inventory. The two are not interchangeable. Marking a property as Product is a deprecated pattern that fails rich-result eligibility for real-estate-specific surfaces and confuses LLMs that have been trained on the canonical real-estate vocabulary. Any guide written before 2024 that recommends Product for residential listings is out of date and should be retired from your operational reference set.
RealEstateListing schema automatically?No. Yoast SEO generates Article, BreadcrumbList, Organization, and WebSite schema across all post and page types. It does not generate real-estate-specific schema types — not RealEstateListing, not RealEstateAgent, not Place with residential subtypes. For a WordPress real-estate site, the canonical pattern is to let Yoast handle the site-wide template schema (Article, BreadcrumbList, Organization) and to inject the real-estate-specific schema through an Elementor Custom HTML widget with display:none CSS, applied per listing or per agent page. Never inject real-estate schema through Google Tag Manager — GTM-injected schema is treated by Google but unreliably extracted by LLMs.
RealEstateAgent and LocalBusiness both be marked on the same page?It depends on what the page is. On an agent profile page, only RealEstateAgent should be the primary type — RealEstateAgent is a subtype of LocalBusiness, so marking both creates redundancy that triggers schema duplication warnings in Google's structured-data validators. On a brokerage home page, LocalBusiness is the primary type because the brokerage is the entity being marked, not an individual agent. On a contact page that lists multiple agents, the brokerage gets LocalBusiness and each agent gets RealEstateAgent nested as part of the team — that is the correct cohabitation pattern.
Yes, and the difference matters. Rich snippets are a presentation layer: schema makes a result eligible for an enhanced display in a classical search result. AI Overviews and LLM citations are an extraction layer: schema makes a fact extractable by the model when it generates an answer to a user prompt. A listing with correct schema is eligible for both, but the mechanisms are independent. The same RealEstateListing markup that triggers a rich snippet in a Google SERP is what allows Perplexity to cite the agent as a named source when a user asks "best realtor for condos in Brickell". Operations that focus only on rich snippets are leaving the LLM citation surface unbuilt — and the LLM citation surface is the one that is growing faster.
GeoCoordinates nested inside Place for a listing?GeoCoordinates is a property of Place. In JSON-LD it is expressed as a geo property whose value is a GeoCoordinates object with latitude and longitude properties carrying decimal values. The nesting pattern looks like this conceptually: the RealEstateListing references a Place via aboutOf or mainEntity; the Place carries the address via PostalAddress; the Place also carries geo whose value is a GeoCoordinates object. Latitude and longitude are decimal degrees, not degrees-minutes-seconds — schema.org requires the decimal form. Get the values from a verified geocoding source, not from estimated map coordinates.
The schema does not disappear, and the listing page does not vanish. The canonical practice in 2026 is to update the RealEstateListing markup to reflect a closed status — typically by changing the listing status property and adding the sold-at date — rather than deleting the page. This preserves the URL, the schema record, and the historical surfacing the page accumulated. It also signals to LLMs that the property's lifecycle has progressed, which is information they use to maintain accurate state in answers to historical-context questions. Deleting sold listings is a legacy practice that throws away accumulated citation equity.
It can, but with caveats. Google Tag Manager injects schema as JavaScript that executes client-side. Google's crawlers render JavaScript before parsing schema, so GTM-injected schema is detected in the same pass as hardcoded schema for rich-result eligibility. However, GTM-injected schema is extracted unreliably by some LLM crawlers that do not execute JavaScript, and it is harder to validate manually because it is invisible to a static HTML inspection. For real-estate sites where the schema stack is part of the operational layer, the canonical recommendation is hardcoded JSON-LD via the page builder (Elementor Custom HTML widget on WordPress, equivalent on other platforms), not GTM injection.
Real-estate schema is a methodology. The decision of whether to run it, at what scale, and against which inventory is strategic. The work of building it, integrating it with IDX and MLS, maintaining it across listing lifecycle, and updating it when the canonical taxonomy moves again — that work is tactical. I carry the first. Digital Media 305 carries the second. The exit clause on my side is 14 days with documentation walked over to you. The standard on the tactical side is the same; the scope is different.
Pick the question you need answered today.
This page was written by Fermín, founder of Ferminius and operator-of-record on Growth Marketing Studios and Digital Media 305. Eleven years of senior SEO experience, with real-estate schema work documented in production since 2019. Master's in SEO and Online Marketing from Webpositer Academy, Barcelona, 2023. Currently completing a Master's in Artificial Intelligence at Universidad Isabel I, Burgos. Read the full About page →
schema.org · official documentation https://schema.org/RealEstateListing https://schema.org/RealEstateAgent https://schema.org/Place https://schema.org/GeoCoordinates