What IDX is, and why almost everyone has it wired in wrong
IDX — Internet Data Exchange — is the mechanism by which an agent's website is allowed to display active MLS listings from their board. It became table stakes more than a decade ago. If a buyer lands on your site and cannot search inventory, they leave inside ten seconds.
The problem is that "having IDX" and "having IDX integrated correctly" are two completely different things. The default path — the one nearly every templated site ships with — is to drop in a third-party IDX widget, point it at the MLS, and call it done. Listings appear, and in that narrow sense it works. It also quietly undermines almost everything else a luxury agent is trying to accomplish online: trust, brand control, organic traffic, and the perception that the agent operates at a different tier than the volume brokerage down the street. For most agents the IDX is the largest chunk of pages on the site by volume, and treating it as a bolted-on accessory is the costliest decision in the typical real estate web stack.
The iframe problem
If you click into a listing on your own website and the URL bar does not change, or it jumps to a long query string on a subdomain that does not match your brand, you are looking at an iframe IDX. The listing detail page is not really part of your site. It is a separate web application from a third-party IDX provider, embedded inside a rectangle on your page. Your header sits above it, your footer below, and everything in between is rendered by someone else.
The visual tell is unmistakable on a luxury build. The agent's site uses a refined serif, generous whitespace, custom photography, considered hover states. Then the visitor clicks a listing card and lands inside a boxed-in widget with system fonts, dense rows of stat icons, a different button style, and a chat bubble in the corner promoting a brand the agent has never heard of. On an eight-figure listing, it reads as cheap.
It is not only aesthetic. Iframes are nearly invisible to search engines — Google does not credit the surrounding page for the content inside the frame, and the listing pages typically live on the IDX vendor's domain, not yours. Every backlink that detail page earns goes to the vendor. Every minute a buyer spends scrolling those photos counts as engagement on someone else's analytics. You are renting space inside your own homepage.
What "native IDX" actually means
Native IDX means the MLS data is pulled into your own database, your own templates render it, and the listing detail pages live on your own domain at a clean URL — something like yourdomain.com/listings/123-ocean-view-drive. The listing page inherits your typography, your color palette, your gallery component, your inquiry form, and your analytics. It is indistinguishable from the rest of the site because, structurally, it is the rest of the site.
The implications compound. Google crawls those URLs and indexes them as your content. Schema.org markup tells search engines exactly what the listing is — address, price, beds, baths, square footage, geo coordinates — and qualifies the page for rich results. Internal links between your neighborhood guides, sold gallery, and active inventory actually pass authority instead of dead-ending at an iframe boundary. This is the same distinction we make in arguing that a templated site cannot carry a luxury brand: the substrate matters. Listings have to be built into the site, not pasted onto it.
The MLS feed itself: RESO Web API vs older RETS
Underneath every IDX is a data feed from the MLS. There are two common standards, and the difference matters for what your site can actually do.
The older standard is RETS — Real Estate Transaction Standard — a SOAP-style protocol that was state of the art around 2005. It works, but it is slow, brittle, and expensive to keep in sync. Newer boards have largely deprecated it. The current standard is the RESO Web API, a modern REST and JSON interface defined by the Real Estate Standards Organization. It is faster, easier to query, and supports incremental updates so a site can pull only what changed in the last few minutes instead of re-syncing nightly.
The other question — the one almost no agent thinks to ask — is what is inside the feed. MLS boards offer different feed tiers. A bare public IDX feed often strips out high-resolution photography, agent remarks, virtual tour links, and certain status fields. To present a luxury listing properly, the site has to be authorized for a fuller feed — VOW (Virtual Office Website) or broker-level access, depending on the board — which includes the original photo resolutions and the rich remarks that make a listing read like a brochure instead of a database row.
Performance on luxury inventory
Luxury listings are heavier than typical listings. Where a tract-home detail page might show twelve photos at modest resolution, a meaningful estate listing carries thirty to fifty high-resolution images, a drone reel, a cinematic walkthrough, and often a floor plan PDF. That payload cannot be served the way a 2010-era listings page served three hundred kilobytes of thumbnails.
A correctly built listing page in 2026 does several things at once. It serves the hero image immediately in a modern format like AVIF or WebP, sized to the viewport. It lazy-loads the rest of the gallery as the visitor scrolls or swipes, and preloads the next likely image based on swipe direction. It serves video via an adaptive stream so a buyer on cellular does not get a six-second buffer before the first frame. And it does all of this behind a CDN so the first byte arrives in under two hundred milliseconds. Conversion drops sharply as load time climbs past two seconds, and luxury buyers — accustomed to retail experiences engineered to a higher standard — are less patient, not more. A slow listing page is a closed tab.
Mobile: the swipe-first experience
More than sixty-five percent of property search traffic is mobile, and on luxury inventory the share is climbing. Buyers do not sit at desks browsing MLS pages. They swipe through listings on a phone the way they swipe through Instagram — between meetings, on a plane, in bed.
That changes what a listing page needs to feel like. The photo gallery should dominate above the fold, full-bleed, tap-to-expand, swipe horizontally, pinch to zoom. Price and key stats should sit in a sticky element. The inquiry form should be a single tap away, not buried below a wall of detail blocks. The map should load when the visitor scrolls to it, not block the rest of the page. Off-the-shelf IDX widgets are still, in 2026, surprisingly bad at this — many were designed for desktop in an earlier era and patched for mobile by squashing the same dense table layout into a narrower column.
SEO: every listing is a landing page
Every active listing on your site is a potential search engine landing page. Buyers — and curious neighbors, journalists, and future sellers comparing comps — search the exact addresses of properties. They search neighborhood plus bedrooms. They search school district plus price band. A listing detail page on your domain, properly marked up, can rank for those queries and pull qualified visitors directly into your funnel. An iframe IDX captures none of this — its pages are either uncrawlable, hosted on the vendor's domain, or so generic in markup that Google cannot tell one agent's instance from another's.
A native IDX, by contrast, accrues. Every listing the agent ever represents becomes a permanent or archived URL on the agent's domain. Sold pages can remain live with sold status, building topical authority for the neighborhood. Five years in, the organic footprint of a properly built site is measured in thousands of indexed pages, earned by simply doing the job over time. None of that compounding happens inside an iframe.
Saved searches, alerts, and the CRM loop
A listing search is also a lead capture surface, and this is where the difference between bolted-on and integrated becomes most expensive. When a visitor saves a search or creates an alert on a third-party widget, that contact often lives in the widget vendor's system, syncing to the agent's CRM through whatever integration the vendor happens to support — if any.
On a native build, the saved search lives in the same database as everything else: the contact, their search criteria, their click history on individual listings, their inquiry submissions, and their email engagement. The CRM has a complete picture, not a partial one stitched together from exports. Automated follow-up can be specific — a new listing matches the saved search, the buyer gets an email rendered in the agent's brand, the click lands them on a page that knows who they are. This is the core argument in our deeper piece on turning a real estate site into a lead engine: the IDX is the largest funnel on the site, and it has to feed the same database every other touchpoint feeds.
Checklist: what to ask a website vendor about their IDX
Before signing anything, ask the vendor these questions. The answers will tell you, in about ten minutes, whether you are getting native integration or an iframe in costume.
- Do listing detail pages live on my own domain, at my own URL structure, or on a subdomain or third-party domain?
- Are the listing pages server-rendered HTML that Google can crawl, or are they injected via an iframe or a client-side script that search engines cannot read?
- Are you pulling the MLS data via the RESO Web API, or an older RETS feed?
- What feed tier am I authorized for — bare public IDX, VOW, or broker-level? What photo resolution and remarks fields are included?
- Does each listing page emit schema.org RealEstateListing markup for rich results?
- What is the median Largest Contentful Paint on a listing page over cellular?
- Where do saved searches, alert signups, and inquiry submissions live — in my CRM, or in a third-party silo?
- When a listing goes off-market, what happens to the URL? Does it 404, 301, or remain as a sold archive page?
- Who owns the SEO equity of the listing pages — me, or the IDX vendor?
If any of those answers feel hedged, they are. A vendor doing this work properly will answer all nine without hesitation. To see what the right answers look like in practice, browse the luxury sites we've built, review the included feature set, read about our approach, or work through the FAQ.
IDX is not the flashy part of a luxury site. It is the substrate the entire buyer experience sits on. Get it right and the rest of the site has somewhere to compound. Get it wrong and every other investment in brand, content, and design is undercut by the largest section of the site behaving like it belongs to someone else.