SEO
Technical SEO for Real Estate Websites
Why IDX websites end up crawled but not indexed — duplicate filter URLs, rendering, canonicals, sitemaps and listing status changes — and what to do about each.
Introduction
The most common technical problem on a real estate website is not that pages rank badly. It is that they never enter the running.
You publish community pages, the feed adds thousands of listings, and months later Search Console shows a large number of URLs sitting in Crawled – currently not indexed or Discovered – currently not indexed. Nothing is broken in a way anyone would notice. Traffic just does not arrive.
IDX sites hit this harder than most sites, for structural reasons. This article covers why, and what is actually worth doing about it.
⚡ Quick answer — Why isn't my IDX website being indexed? Usually one of four things: search engines cannot discover the page, crawl budget is being spent on filter and sort URLs instead of pages that matter, the content only appears after JavaScript runs, or the page is a near-duplicate of another URL on your own site. Listing pages are also the least distinctive content you have, so indexation alone does not make them competitive.
The five stages, and where sites stop
A page has to survive a sequence before it can rank at all. Google describes it as crawling, rendering and indexing — and a real estate site can fail at any point.
- 1
Discovery
Google learns the URL exists — from a link or a sitemap
Fails when — Orphan pages. A community page nothing links to may never be found.
- 2
Crawl
Googlebot requests the URL and checks robots.txt first
Fails when — Blocked in robots.txt, or crawl spent on filter URLs instead of real pages.
- 3
Render
Headless Chromium runs the page's JavaScript
Fails when — Content that only appears after a client-side fetch may be missed or delayed.
- 4
Index
The rendered result is stored and made eligible
Fails when — noindex, a canonical pointing elsewhere, or a near-duplicate of another URL.
- 5
Ranking eligibility
The page can now compete for queries
Fails when — Indexed but thin — nothing on it that another site does not also have.
Every failure above produces the same symptom from outside: the page is not in Google. Diagnosis means working out which stage it stopped at.
Working out which stage a page stopped at is most of the diagnosis. Search Console's Page indexing report names the stage; the URL Inspection tool shows what Google actually rendered.
Crawlability
robots.txt. Check it first, and check it after any platform migration. Blocking a directory that contains your community pages is a five-minute mistake that takes months to notice.
Internal links. This is the biggest discovery problem on real estate sites. Pages generated in bulk — one per community, one per building — frequently have nothing linking to them. If a page is reachable only by typing its URL, treat it as invisible.
Sitemaps. A sitemap helps discovery but does not compensate for a page nothing links to. Google treats orphaned pages as low priority regardless of whether they appear in a sitemap.
Parameter URLs. This is where crawl budget goes to die on IDX sites. Filter combinations multiply: five filters with a handful of options each produce thousands of URLs over the same inventory. Google is direct about the risk, warning that the default implementation of faceted navigation generates "infinite URL spaces" that cause overcrawling and slow the discovery of genuinely new content.
The practical read: every request spent on ?sort=price&page=7 is a request not spent on the community page you wrote last week.
Rendering
Two outdated claims need retiring before anything useful can be said here.
"Google can't render JavaScript." It can. Google's documentation is explicit that once resources allow, "a headless Chromium renders the page and executes the JavaScript."
"So rendering doesn't matter." It still does. Rendering is queued, and Google notes a page "may stay on this queue for a few seconds, but it can take longer than that." Google also recommends server-side or pre-rendering anyway, because "it makes your website faster for users and crawlers, and not all bots can run JavaScript" — which matters increasingly as AI crawlers become a real source of referral.
For real estate specifically, the risk concentrates in three places:
- Listing facts fetched client-side after load. If price, beds and address arrive via a subsequent request, they may not be in what gets indexed.
- Search results pages built entirely in the browser. Often fine to leave unindexed anyway, but be deliberate about it.
- Single-page-app routing. Google warns that client-side routing makes meaningful HTTP status codes impractical, which produces soft 404s. Fragment-based URLs are worse: Google "generally doesn't support URL fragments in crawling and indexing."
The test is simple. Open the URL Inspection tool, run a live test, and read the rendered HTML. If your listing facts are not in it, neither is your ranking.
Indexability
noindex. Check for it before theorising about anything else. It survives migrations and staging environments with remarkable persistence.
Status codes. A removed listing should return 404 or 410, or redirect to something genuinely equivalent. What it should not do is return 200 with an empty template — a soft 404, which wastes crawl and can drag on quality signals.
Redirect chains. Common after a platform change. Each hop costs, and long chains sometimes stop being followed.
Thin and near-duplicate pages. The real constraint on IDX sites, and the subject of the next section.
IDX duplicate content, properly understood
The folklore version — MLS listings are duplicate content, so IDX pages can't rank — is too crude to act on, and it leads people to noindex things they should keep.
Two separate problems get conflated.
Problem one: the same listings appear on every participant's site. True, and it is why listing pages rarely rank for anything competitive. But there is no automatic penalty for it. Google's guidance on duplicate URLs is about consolidating signals to a preferred URL, not about punishment. Listing pages still earn their place — they convert, they serve returning visitors, they support saved searches. They are just not your ranking asset.
Problem two: your own site generates many URLs over the same inventory. This is the one you control, and the one that actually wastes crawl.
Four URLs over the same inventory. The question is never “is this a duplicate” — it is whether anyone searches for it.
/homes/torontoIndexLanding page
A page someone would search for, with local content only you can write
/homes/toronto/condosIndexMeaningful filter
Real search demand, enough inventory to be useful, worth its own copy
/homes?city=toronto&sort=priceNot a separate pageSort order
Same inventory reordered — nobody searches for it
/homes?city=toronto&beds=3&baths=2&pool=1Not a separate pageDeep filter combination
One of effectively unlimited combinations; crawl spent here is crawl not spent elsewhere
There is no single correct handling for the bottom two. Google’s own guidance offers several approaches, and which suits depends on how your search URLs are built.
Note what the diagram does not say: canonicalize every filter to the city page. Do that and you delete /homes/toronto/condos — a page with real search demand — along with ?sort=price.
The distinction worth holding is between a filter combination that matches how people search and one that merely reorders or narrows. The first deserves a real URL, a real title and real content. The second does not need to exist as an indexable page.
Canonical URLs, used deliberately
A canonical tells Google which URL you would prefer to represent a piece of content. It consolidates signals — links, in particular — onto one address.
Two things about it that matter in practice.
It is a preference, not a directive. Google decides. If your canonical points somewhere that is not substantially the same page, expect it to be ignored.
It is not required. Google's own wording is that "none of them are required; your site will likely do just fine without specifying a canonical preference." Useful antidote to the idea that every URL needs one.
Where it earns its keep on a real estate site: when the same page is reachable at several addresses — with and without trailing slash, with tracking parameters, with a session ID. Point them all at the clean URL.
Where it does not: as a blanket answer to faceted navigation. Google is explicit that canonicals and nofollow are "generally less effective in the long term" for that than robots.txt or fragment-based filters, though they may reduce crawl volume gradually.
Sitemaps
Split them by logical group rather than shipping one enormous file:
| Group | Why separate |
|---|---|
| Static pages | Small, stable, rarely changes |
| City and community pages | Your ranking layer — worth watching independently |
| Articles | Different update rhythm |
| Listings | Huge and volatile; changes constantly |
The reason is diagnostic. Search Console reports coverage per sitemap, so separating them tells you which group is not being indexed. One combined file tells you only that something is wrong.
For listings, keep the sitemap in step with the feed. A sitemap advertising thousands of URLs that now 404 is a signal you do not want to send. How long a sold listing may remain publicly displayed at all is a separate question, set by your MLS — see MLS & IDX Compliance.
Site architecture and internal links
The architecture that ranks is a hierarchy, not a flat pile:
Homepage → market → city → community → property
Each level should link down to the next and back up, so crawl paths exist without a sitemap and so authority flows to the pages you care about. That structure is covered in Real Estate SEO: The Complete Guide; what matters technically is three things.
No orphans. If a page is not linked from anywhere, it is not part of the site as far as crawling is concerned.
Breadcrumbs. They give every page an explicit position in the hierarchy and a link back up. They also produce clean BreadcrumbList markup for free.
Contextual links over link blocks. A link inside a sentence about the neighbourhood carries context. Thirty links in a footer carry almost none.
The pages this structure exists to support are your area pages — see Neighborhood Pages That Actually Rank.
Structured data
Structured data helps search engines understand what a page is. It does not improve rankings by itself, and adding it does not guarantee rich results — Google's documentation is consistent that rich result eligibility is not the same as entitlement.
Worth implementing on most real estate sites:
OrganizationorRealEstateAgenton the site, identifying who you areBreadcrumbListwherever breadcrumbs appearArticleon editorial contentWebSitefor site-level identity
Be careful with listing markup specifically. Schema.org offers property-related types, but support for real estate rich results is limited and inconsistent across markets, and marking up data your MLS restricts may run into your display agreement. Confirm both before investing in it.
Core Web Vitals, in real estate terms
Performance work on real estate sites is dominated by a short list of the same offenders.
Listing photography. The single biggest one. Twenty-plus images per listing, frequently served far larger than the slot they occupy. Serve responsive sizes, use modern formats, and lazy-load everything below the fold — with the exception of the main image, which is usually the LCP element and should load eagerly.
Map libraries. Heavy, and often loaded on pages where no map is visible. Load on demand.
Third-party scripts. Chat widgets, tracking, remarketing pixels. Each one runs on the main thread. Audit them periodically; most sites accumulate scripts nobody can account for.
Search JavaScript. The bundle powering filters and the map is usually the largest thing a visitor downloads. It rarely needs to be present on a community page that has no search on it.
Fonts. Preload the faces used above the fold; let the rest wait.
Handling this is a real part of what an IDX platform does — clean URLs, rendering, keeping property data current and search fast are platform-level concerns rather than things an agent configures. See RealFoyer IDX websites.
Listing status changes
When a listing goes from active to pending to sold, something has to happen to its URL. There is no universally correct answer, and anyone who tells you otherwise is describing their own market.
Three defensible strategies:
Keep the URL, update the page. Marks it sold, retains any links and history the page accumulated. Only viable where your MLS permits displaying sold data.
Redirect to the parent area page. Sends the visitor somewhere useful rather than a dead end. Sensible when sold display is not permitted.
Return 404 or 410. Honest and clean. Costs whatever the page had accumulated.
Whichever you choose, two things hold: return the status code you actually mean, and clean up internal links so the site is not full of pointers to removed pages.
The constraint that decides this is usually not technical. What may remain publicly displayed after a sale is set by your MLS and data licence.
A diagnostic order
When indexation looks wrong, work in this order rather than guessing:
- Search Console → Page indexing. Which state, and how many URLs?
- URL Inspection, live test. Is your content in the rendered HTML?
- robots.txt and meta robots. Anything blocked that should not be?
- Canonical tags. Do they point where you intend?
- Internal links. Is the page linked from anywhere?
- Crawl stats. What proportion of requests goes to filter URLs?
Most cases resolve in the first three.
FAQ
Does duplicate MLS content mean my listings can't rank? Listing pages rarely rank competitively, because every participant shows the same records. That is a distinctiveness problem, not a penalty. Your ranking comes from area and resource content only you have.
Should I noindex my property search pages? Not automatically. Filter URLs matching real search demand — a city, a property type — are often your best landing pages. Sort orders and deep filter combinations are the ones that do not need to be indexed.
Is JavaScript bad for real estate SEO? No, Google renders JavaScript. But rendering is queued rather than instant, and not every crawler runs it, so server-rendering the content that matters is still the safer choice.
Do I need schema for my listings? Organization, breadcrumb and article markup are straightforward wins. Listing-level markup is more complicated: rich result support is inconsistent, and your MLS may restrict marking up certain fields. Check both first.
How long should indexing take? It varies by site and by how well linked the page is. Rather than watching a calendar, check whether the page is discovered and rendered correctly — that is the part you control.
Should I delete sold listings? Not necessarily, and it may not be your choice. Where your MLS permits keeping the page, retaining a useful URL is often better than removing it. Where it does not, redirect or return a proper 404.
In short
Technical SEO on a real estate site comes down to three questions: can search engines discover your pages, does your content exist in the rendered HTML, and is crawl going to pages that matter rather than to filter permutations of the same inventory.
Fix those and the content work has somewhere to land. Skip them and the best neighbourhood page you ever write will sit in Discovered – currently not indexed.
Explore RealFoyer IDX websites, or book a demo to look at your current site's architecture.
Related reading
- Real Estate SEO: The Complete Guide
- Real Estate SEO: Your First 90 Days
- AEO for Real Estate: How to Get Found in AI Search
- Real Estate IDX Websites: The Complete Guide
- Neighborhood Pages That Actually Rank
- MLS & IDX Compliance: What Your Real Estate Website Must Handle
Research Integrity
Written 16 August 2026 against Google's own documentation. The crawl-render-index sequence, the headless Chromium rendering statement, the rendering queue caveat and the pre-rendering recommendation come from Google's JavaScript SEO basics. Canonical guidance, including that canonicals are not required, comes from Google's duplicate URL consolidation documentation. The "infinite URL spaces" warning and the relative effectiveness of robots.txt versus canonical tags come from Google's faceted navigation guidance. No claim is made that schema improves rankings or guarantees rich results, and no indexation timeline is stated, because neither is supported.