Why Your IDX Listings Don't Rank (and How to Get the Credit Back)
Your Site Has 400 Listings and Google Has Indexed Zero of Them
You're in Search Console. You've clicked into Performance, switched to the Pages tab, and started scrolling through the URLs Google has actually crawled on your domain. Your IDX widget is live right now. Four hundred properties. Full addresses, days on market, listing photos, price history, square footage. A buyer landing on any one of them could pick up the phone and call you this afternoon.
But the URLs in Search Console don't match. There's no /listing/, no /property/, nothing that looks like a detail page for any specific home. Your IDX listings don't rank because, as far as Google is concerned, those pages don't belong to your domain.
That blank report isn't a misconfiguration in your theme or a permalink setting you missed. It's structural, and it starts with how the widget delivers content to visitors and search engines at the same time.
Where Google Actually Thinks Those Listings Live
Most rented IDX widgets deliver content inside an HTML <iframe>. The iframe element sits on your page, but the content inside it is fetched from the provider's server, at the provider's domain.
Google indexes content against the domain that serves it, not the domain embedding it. Google Search Central documents this for embedded frames: content inside an iframe is crawled and attributed to the source URL, not the page holding the frame. So every listing description, every bedroom count, every neighbourhood name inside that widget is building search equity for the provider's domain, not yours.
Your site earns credit for the page that holds the iframe. That's one page. The provider earns credit for four hundred listing detail pages. You can verify this right now by running site:yourprovider.com in a search and checking whether your market's listings appear there.
This isn't an oversight in how the widget was built. The iframe model means the provider's domain accumulates search authority across every client's listings. Every agent on the same platform contributes to the same domain's ranking power. Your listings do the same.
The gap in your Search Console makes sense once you see it. There are no listing URLs on your domain to index. The listings live on the provider's domain, and any ranking they earn goes to the provider's portal.
Iframe content is attributed to the domain serving it. Your site holds the frame. The provider holds the search credit.
The Second Problem the Iframe Creates
The indexing gap is the most expensive part of this, but the iframe creates a set of related problems that compound quietly over time.
Listing URLs can't be bookmarked, shared, or linked back to your site. When a visitor clicks into a property inside the widget, the address bar on your site typically doesn't change. There's no /property/123-oak-street/ to copy, send in an email, or paste into a blog post. If a visitor wants to share a listing with their partner, the URL they copy usually points to the provider's own search portal. The lead, and the traffic, goes with it.
Neighbourhood guides and local content on your site can't link directly to listings either. A well-written "Best Streets in Midtown" guide could link to specific active listings on those streets. With an iframe widget, there are no listing URLs to link to. Your content floats separately from your inventory.
Styles don't follow your theme. The widget has its own CSS, its own font choices, its own button colours. You can adjust a few visual settings through the provider's dashboard, but the widget is sealed. It won't inherit your typography or adapt to your mobile layout the way a native page would.
Navigation breaks in both directions. Visitors who click deeper into listings can drift into the provider's full search portal, losing your menu and your contact forms. If a listing ever surfaces in search, the visitor may land on the provider's portal rather than your site.
None of this is hidden. It's what an iframe is supposed to do. The question is what it costs you in leads, links, and search authority over a full year of listings.
Does your board allow hosted listing pages, and if it does, who owns the search credit those pages build? The free FW Real Estate plugin is what changes the answer: it writes each property into WordPress as its own post at a URL your domain holds. That means address-level searches return pages on your site rather than the provider's portal, filtered archive pages get permanent URLs a buyer can bookmark and share, and every listing your neighbourhood guides link to adds equity to your domain rather than the frame's owner. The plugin is free to install and test before the MLS/IDX add-on is ever part of the conversation, and the diagnosis and the plan you end up with are yours to build with whoever you choose. Run a property on your own domain and see what Google indexes →
What 'Your Own Listing Pages' Actually Means
The alternative is listing pages written into your site's own WordPress database rather than loaded from an external server each time someone visits.
The practical difference is this: instead of a frame pulling in content from the provider's domain, you have real pages on your own domain. Each listing gets its own permanent URL. A three-bedroom townhouse in Phoenix becomes yourdomain.com/properties/456-camelback-rd/ on your site. That URL is a page of your site in exactly the same way a blog post is. It has its own title tag, its own meta description, its own indexable content. Google crawls it during a standard crawl of your domain.
That listing can rank for "3 bed townhouse Phoenix Camelback" on its own. When someone bookmarks it, the bookmark points to your site. When a buyer sends the link to their agent, that agent arrives at your site. When a local blog links to a specific listing, the link equity stays on your domain.
That permanence also changes how you can build around your listings. You can write a neighbourhood guide and link directly to active listings in that area. You can share a listing in your email newsletter and have the link go to a page your site owns. You can build internal links between properties and area pages, the kind of site structure that signals to search engines that your domain covers a market with depth.
The mechanism that makes this work is a data feed pull. An add-on connects to your MLS board's data feed, pulls listing records on a scheduled basis, and writes each record into WordPress as a custom post type. Price changes, status updates, and withdrawn listings are handled by the same sync. The pages stay current, and they stay yours.
This is what separates an iframe embed from a hosted integration. The embed gives you a window into the provider's data. A hosted integration makes that data part of your site.
How FW Real Estate's MLS/IDX Add-On Writes Listings Into WordPress
The FW Real Estate plugin stores properties as WordPress custom post types. Each property, whether added by hand, imported by CSV, or pulled from a feed, gets its own URL on your domain. Google crawls it the way it crawls any post or page on your site.
The MLS/IDX add-on is the paid step that connects the free plugin to a live MLS data feed. Each listing pulled through the add-on becomes a WordPress post at a URL your domain owns. The add-on manages the sync schedule, maps incoming MLS fields to the plugin's property fields, and updates records when listings change status or go off-market. In the WordPress admin, these imported listings look like any other posts in your property archive: editable, searchable, filterable, linkable from any other page on your site.
The outcome for search is what the earlier sections describe: four hundred listings become four hundred crawlable URLs on your domain. Search Console starts showing impressions for individual property detail pages. Listings can rank for searches that include specific addresses, bedroom counts, and neighbourhood keywords.
The free plugin doesn't include a live feed connection. That's the add-on. You can see exactly what ships in the free version and what requires the add-on on the FW Real Estate product page.
When a Rented Widget Is Still the Right Call
Here's the honest part of this post: MLS board rules vary by market, and some boards impose real limits on how listing data can be stored or displayed.
If your board's IDX participant rules prohibit storing listing data on a non-syndicated domain, no software choice changes that. An iframe widget may not be optional in your market. It may be required under the terms you agreed to when you joined the board.
Before you change your setup, read your board's participant rules. The Real Estate Standards Organization (RESO) publishes the data standards that underpin most US MLS systems, and your board's own IDX rules document specifies the display and storage terms that apply in your market. Those two sources are the ones that matter.
In most US residential markets, IDX rules permit licensed participants to locally display and store listing data, which is why hosted listing pages have become common. But "most markets" and "your market" are two different things. Your board's participant rules are the document to check.
If your board allows hosted listing pages, every search impression those pages earn goes to whoever holds them. Right now, with a rented widget, that's your provider. The question is whether changing that is worth the move in your specific situation.
The free FW Real Estate plugin runs on any WordPress site, creating a crawlable post at your own URL for every property you add by hand, import by CSV, or pull from a live MLS feed through the MLS/IDX add-on.
The free download includes custom property fields and dictionaries, list and grid layouts with filtering and paging, a search widget that cascades country to region to city, detail pages with a photo gallery, specification tables, print view and quick view, rentals and sales with their own lease terms and pricing, video and 3D panorama tours, shortcodes and native blocks for any theme, and every library and both typefaces served from the plugin itself so a fresh install contacts nothing outside your server.
MLS feed connectivity is the MLS/IDX add-on, a paid extension. It covers RESO Web API providers, CREA DDF for Canadian boards, and the UK and European portal feeds. Your board and provider feed fees are billed to you directly by your board, not through Fastw3b, so your data contract stays your own. Pricing is on the product page. You can see both the free plugin and the full add-on range running at realestatewordpress.fastw3b.com, though that demo shows more than the free plugin installs on its own.
