How to Handle Multiple MLS Regions on One Real Estate Website

Introduction

Yes. One website can display listings pulled from more than one MLS.

The hard part is not connecting the second feed. It is reconciling two sets of rules, two vocabularies and two update schedules into something a visitor reads as one coherent site.

Brokerages working along a regional border hit this constantly. An office between two market areas, or a team covering a city board and a neighbouring county board, ends up with two feeds pointed at the same homepage. What changes is almost never the plumbing. This article covers what actually does: which fields stop matching, where your duplicates come from, what disappears when a listing is pulled, and what to ask a vendor before you commit.

What a second MLS actually adds

Each MLS is its own contract. A second board means a second licence agreement, a second feed, and a second set of display rules, not a toggle switched on inside your existing setup.

The feed itself is a technical detail. The agreement behind it is the real work: what you may show, how listings must be attributed, which data points you cannot publish at all. Two boards rarely answer those the same way.

Compliance compounds rather than averages out. You inherit both rulebooks. Where they appear to conflict, the safe working assumption is the stricter reading, and the board is the only place that can confirm it. The IDX and MLS compliance rules that apply to a single board do not disappear when a second one joins; they sit alongside a second set you now also owe.

Where the fields stop lining up

Status values that do not exist on both boards. One board might use a status like "Pending - Taking Backups." A neighbouring board may have no equivalent at all. Just "Pending", with no further detail. A filter built for one feed then either drops the distinction or invents a mapping the second board never agreed to.

The same field, recorded differently. Square footage is the common flashpoint. One board records gross living area. Another includes finished basement space by default. Say a buyer filters for a minimum size: the number means something different depending on which feed the listing arrived through, and nothing on the page tells them so.

Property types that do not map one to one. "Condo" on one board might fold in what another splits into condo, loft and co-op. Vocabularies rarely translate cleanly between boards. A shared dropdown has to decide, in advance, how to collapse or split those categories.

None of this is a bug in either feed. Each board built its schema for its own market and its own members.

A search box spanning two feeds has to make a deliberate call: what happens when a value from one board has no counterpart in the other? Leave it undecided and the call still gets made. By accident, usually by whichever developer touched the filter logic last.

What RESO standardises, and what it does not

RESO Web API gives every board that adopts it a common transport and a shared core vocabulary. That solves querying the feed. It does not solve two boards meaning different things by the same field.

The platform supports RESO Web API feeds. That tells you how the connection works, not what the two sets of listings will look like once they arrive. Local fields, custom enumerations and each board's own display policy stay exactly as local as they were before the standard existed.

The comparison between RESO and the older RETS standard, and what each one actually guarantees, is covered in full in RETS vs. RESO Web API. Worth reading before you assume a shared standard means shared data.

Duplicate listings and overlapping boards

Adjacent boards often cover overlapping territory. A listing near the boundary can be entered on both, syndicated into both feeds, or surface under two different listing keys for what is, on the ground, one house.

There is no neutral default here. You pick one of a small number of approaches, and each one costs you something:

• Show both entries. Simple to build, confusing to a buyer who sees the same kitchen photographed twice at two different prices.
• Designate a primary feed. Clean, but it means deciding in writing which board wins when both carry the listing.
• Match and merge. Catches most duplicates, and occasionally merges two different units in the same building by mistake.

If you merge, the match has to run on something. In rough order of reliability:

1. Parcel or assessor number. The strongest signal when both boards carry it, because it comes from the municipality rather than from either board. Often missing.
2. Normalised street address plus unit. Works well once you have collapsed "123 Main St Apt 4", "123 Main Street #4" and "123 Main St. Unit 4" into one string. Unit numbers are where this quietly fails.
3. Coordinates within a short radius. Useful as a secondary check. On its own it will happily merge two townhouses that share a driveway.
4. A fingerprint of price, beds, baths and living area. Cheap to compute, and wrong whenever one board records living area differently. Treat it as a tie-breaker, never as the primary key.

Then decide what happens to the record that loses. The two defensible answers are to keep one page and point the other address at it, or to stop publishing the loser entirely. What is not defensible is leaving both live and letting whichever imported last overwrite the other. That is how a price ends up flickering between two numbers on consecutive page loads.

When a listing leaves one feed

A listing pulled from one board has to come off the site even when a second feed still carries a stale copy of it. Listing data is imported from MLS feeds on a schedule, including media, geocoding and open houses, with removed listings reconciled. That reconciliation step is what keeps a sold or withdrawn property from lingering on the site after it should have disappeared.

With one feed, a missed reconciliation shows up as a single stale listing. With two, it can look like the property is still genuinely active, because the surviving copy from the other board quietly backs it up.

Then someone calls about a house that sold three weeks ago. That is not a minor annoyance. It makes a brokerage look like it does not know its own inventory.

This is exactly the territory the MLS integration guide covers for a single feed. Running two boards does not change the mechanics. It raises the cost of getting reconciliation wrong.

One URL per property, not one per feed

Two feeds should not end up producing two web addresses for one home. When they do, you have split whatever signal the listing was building and shown a visitor two versions of a single property.

The rule worth writing down before the second feed connects is that one property should get one address, and the thing you build that address from decides how long it survives. This is harder than it looks, and relisting is why. On many boards a property taken off market and listed again comes back with a new listing number, so an address built on the listing key alone turns one home into two pages over a couple of seasons. An address built from the price, the status or the agent is worse again, because all three move while the property does not.

There is no key here that is right everywhere. What there is instead is a question to settle before the second feed connects: which identifier does each of your boards keep stable across a relist, and what does the site do when that identifier changes? Ask it of both boards, because the answers differ, and the one that treats relists differently is the one that will generate the duplicates.

Say a listing is syndicated from a neighbouring board into your main feed as well as pulled in directly. Without a rule to collapse the two into one page, the site publishes both, each with its own address, its own save count, its own history.

This is a decision about structure, not a lesson in search mechanics generally. For the crawling and indexing side of that problem, Technical SEO for real estate websites covers it in full.

Who sees what once there are two markets

Two MLS regions usually mean two offices, or at least two groups of agents who have no reason to be staring at each other's pipeline. Teams can add staff members with roles and permissions. How finely those permissions can be drawn around a market or an office is worth establishing before the second region goes live, because it decides whether separation is something you configure or something you ask people to respect.

A broker running both markets still needs somewhere to check whether either is working. The dashboard reports on leads, listings, activity and marketing. Ask how it treats a second region specifically: whether the figures arrive combined, split by market, or filterable, because that determines what you can actually see in a weekly review.

Routing a lead to the right market

A lead from the second region should never land with an agent who does not work that area. Manual triage is the first thing to break once a second market is live. It does not scale.

Lead routing supports round-robin distribution, configurable rules, automatic assignment and reassignment, with manual override and a visible assignment history. That history matters here specifically: when a lead crosses from one market's listing into another agent's territory, you can see exactly how it got there and move it if the rule got it wrong.

The mechanics of setting up rules by market, team or source are covered fully in Real estate lead routing.

What to watch in the first month

Two feeds fail quietly. A single feed that breaks is obvious because listings stop appearing; a second feed that breaks often leaves the site looking populated. These are the numbers worth checking weekly, and none of them needs vendor cooperation to read:

• Listing count per board against the board's own count. A gap that grows week over week means imports are partially failing, not that the market moved.
• Age of the oldest active listing from each feed. A board whose oldest listing keeps getting older is a board whose removals are not coming through.
• Count of listings with a status or property type your filters do not recognise. This number should be near zero. If it climbs, a board changed a value and nobody mapped it.
• Duplicate rate near the boundary. Spot-check a handful of addresses within a few streets of where the two territories meet.
• Time since the last successful import for each feed, held separately. One combined timestamp hides a feed that stopped three days ago.

Put a date in the calendar for the first month rather than waiting for an agent to report a sold house still sitting on the site. By then a buyer has usually already seen it.

Questions to ask before adding a region

Put these to a vendor in writing before adding a second board. A vague answer to any of these is itself the answer.

• Which boards does the feed connect to today, by name, not by category?
• What happens to a listing on the site the moment it is removed from the source board?
• How are duplicates between the two boards handled: shown separately, merged, or deferred to a primary feed?
• Is field mapping configurable, or fixed by the vendor?
• Who is responsible for display-rule compliance when the two boards' rules conflict?
• What does a search filter do with a value one board has and the other does not?
• Does each listing get one permanent URL regardless of which feed it arrived through?
• Can staff permissions be scoped so one office does not see the other's leads?

One caution before any of this becomes a plan. Board coverage is specific, not general. No platform connects to every board, and a vendor's answer about one of your two markets tells you nothing about the other. Check both against the MLS board coverage page and treat an unlisted board as unsupported until someone confirms otherwise in writing. For the delivery mechanics behind any of this, the MLS integration guide is the place to start.

Common questions

Can one website connect to two MLSs at once?

Yes, technically. The work is in reconciling the two feeds afterward, not in the connection itself.

Does a second feed slow the site down?

That depends on the feed, the board, and how the two are merged on the back end. Ask the vendor how imports are scheduled, not just whether a second board is possible.

Do you need a separate licence for each board?

Usually, yes. Each board tends to be its own agreement on its own terms, and displaying two feeds on one website does not merge them. Confirm the specifics with each board rather than assuming one licence stretches.

Can one search box cover both regions?

It can, but only once someone has decided how to treat the fields that do not match between the two boards. A shared search built without that decision will misreport results for one side or the other.

Who decides what RealFoyer can show from a given board?

The board does. Scope, refresh cadence and display rules vary by market and by the licence a given office signed, and that is true whether you are running one feed or three.