Migrating a brokerage website without losing your listing URLs

A brokerage website migration keeps its search visibility when the complete inventory of existing URLs is exported before anything is designed, every one of those URLs is mapped to exactly one new URL, the mapping is served as a permanent redirect with no chain in the middle, and the result is verified in the first 48 hours rather than assumed. Everything else in a migration is a project management problem. This part is the part that loses rankings, and it loses them quietly, over weeks, in a way that is expensive to diagnose after the fact.

Start with the inventory, before anything is designed

The first deliverable of a migration is a spreadsheet of every URL the current site serves, and it is produced before a single new page is designed. The reason is simple: the old site is the specification for what the new site has to be able to answer for. If you design first and inventory later, you find out at the end that the new structure has no home for two hundred sold listing pages, and the decision gets made under launch pressure.

What to export

A brokerage site carries more URL types than most businesses. Collect all of them:

• Active listing pages, including every URL variant your current system produces for the same listing.
• Sold, expired and withdrawn listing pages, which are often the largest single group and the most frequently forgotten.
• Agent profile pages, plus any per-agent microsites or subdomains the old vendor set up.
• Office and location pages.
• Market, city and neighborhood pages.
• Blog posts and market reports, including author and category archive pages.
• Search result pages that happen to be indexed, such as saved filters with their own URLs.
• Landing pages built for past campaigns, which nobody remembers and which are often still receiving paid or email traffic.
• PDFs and downloads, brochures, floor plans, buyer guides.
• Images, where an image URL has accumulated links or appears in image search.
• Legal and policy pages, which are boring and which regulators and compliance reviews care about.

Where the list comes from

No single source is complete, so build the inventory from four and merge them:

1. A full crawl of the live site, which finds everything reachable by following links.
2. Your existing sitemap files, which often include pages the crawl missed.
3. Search Console and analytics, which surface URLs that receive traffic but are no longer linked internally. This is how orphaned pages get found.
4. Server access logs, which show what crawlers and real visitors are actually requesting, including URLs that exist in nobody’s list but are still being hit from outside.

Merge, deduplicate, and record for every URL: the page type, its current title, whether it is indexed, its traffic over the last twelve months, and whether it has external links pointing at it. That last column is what tells you which pages cannot be allowed to break.

Why this happens before design

Because the inventory changes the design brief. A brokerage that discovers it has eleven hundred sold listing pages carrying steady long-tail traffic will make different structural choices than one that discovers it has forty. Google’s own guidance on site moves with URL changes treats the mapping of old URLs to new ones as a planning step of the move, not a cleanup task at the end, and that ordering is the whole point.

Building the redirect map

The redirect map is a two-column list: one old URL, one new URL, no blanks. It is the single most important artifact of the migration, and it should be reviewable by a person who has never seen the new site.

One to one, not one to many

Each old URL points at exactly one destination. If two old URLs held the same listing, both point at the one new listing page, which is also how you resolve the duplicate problem you inherited. Google’s guidance on consolidating duplicate URLs describes the underlying principle: search engines want one clear canonical URL for a given piece of content, and leaving several equally valid versions in play means the signal gets split instead of consolidated.

Build the map by page type rather than by hand, wherever a rule exists:

• Listing pages usually map by a listing identifier that appears in both the old and new URL, which can be generated as a rule and then spot-checked.
• Agent profiles map by agent identifier or by a name slug you can derive.
• Market pages map by place name.
• Blog posts map by slug, with a manual pass for anything renamed.
• Everything that has no rule gets mapped by hand, and that set is usually smaller than it feels.

Pages with no equivalent

Some pages genuinely have no destination on the new site. Handle them deliberately, in this order of preference:

1. Redirect to the closest genuine equivalent. A retired market page goes to the parent market hub. A discontinued service page goes to the service that replaced it.
2. Redirect to the category above it. A sold listing in a town you still cover goes to that town’s market page, which is a reasonable next step for a visitor who arrived looking for that property.
3. Rebuild the page on the new site. If a page has real external links or steady traffic, the cheapest answer is often to keep it rather than to redirect it.
4. Let it return a not-found response. This is a legitimate outcome for a page with no traffic, no links and no relevance, and it is better than a misleading redirect.

What not to do is redirect everything with no obvious home to the homepage. It reads as a fix and behaves like a broken link: the visitor lands somewhere unrelated to what they clicked, and search engines generally treat an irrelevant redirect as equivalent to a missing page rather than as a move.

Why 301, and never a chain

Use a 301 permanent redirect, because that is the response that says the content has moved for good, and Google’s redirect documentation names permanent redirects as the strongest signal that the target URL should now be the one shown in search results. A 302 says the move is temporary, which tells search engines to keep the old URL in play, which is the opposite of what a migration wants.

The chain rule matters just as much:

• One hop, always. Old URL to final new URL. Not old URL to interim URL to new URL.
• Chains form by accident. The classic is a site that already redirected non-secure to secure, and without-prefix to with-prefix, before the migration added a third hop on top. Three hops for every request is slower for visitors and more fragile for crawlers.
• Flatten the map before launch. Take every entry whose destination is itself a source in another entry, and repoint it at the final destination.
• Watch the trailing slash and the case. Both create silent extra hops when the new server normalises differently from the old one.
• Never redirect into a redirect you do not control, such as the old vendor’s shortener or a third-party listing host.

Test the flattened map mechanically. Every old URL should return a single 301 and then a 200, and a script that walks the whole map and reports anything else is an afternoon of work that pays for itself on launch day.

Launch day: the order of operations

Run the launch in a fixed order, and do not let anyone reorder it because the design review ran late. The sequence:

1. Freeze content on the old site. No new posts, no page edits. New listings still flow from the feed, which is fine because the feed is moving too.
2. Re-crawl the old site one final time and reconcile against the map, since a few URLs will have appeared since the inventory was taken.
3. Deploy the new site on a staging address that is not publicly indexable, and verify templates, forms and feed data there.
4. Load the redirect map into the new site and test it against the staging address.
5. Verify enquiry routing end to end. Submit a real test enquiry from a listing page, an agent profile and the contact page, and confirm delivery to the actual inbox or CRM, not to a developer’s test address.
6. Cut the domain over to the new site.
7. Confirm redirects are live on the real domain within minutes, using a handful of the highest-value old URLs from your list.
8. Submit the new sitemap. Google’s sitemaps documentation describes a sitemap as an aid to discovery, which is exactly what a few hundred newly created listing and market URLs need.
9. Keep the old sitemap available for a while where your setup allows it, so the old URLs stay discoverable long enough to be recrawled and redirected.
10. Announce internally. Agents will notice something changed and will report things. Give them one place to report to.

DNS, domain and email cutover

Treat the website cutover and the email cutover as two separate projects that happen to share a domain, because that is exactly what they are and because mixing them is how a brokerage loses a day of enquiries.

• Lower the DNS time-to-live in advance, a day or two before the move, so the change propagates quickly instead of being cached at the old value.
• Never touch the mail records while moving the site. The records that route mail are separate from the records that route web traffic. Change only what has to change.
• Confirm who holds the registrar login before launch week. On older brokerage sites this is frequently a former vendor or a former employee, and finding out on launch day is a genuine outage risk.
• Check certificates on every hostname the site answers on, including the version with and without the prefix, on the real domain rather than on staging.
• Reissue or re-verify anything tied to the domain: mail authentication records, any third-party tool that verifies by DNS, and your Search Console property.
• Send test mail in both directions after the move, from an outside address to a brokerage address and back, for at least one address per office.

If the migration also changes the domain itself, that is a larger move than a platform change, and Google’s site move documentation is worth reading in full before planning it, since it covers the additional steps a domain change requires.

What to check in the first 48 hours, and the first 30 days

Verification is a schedule, not a feeling. Two windows matter, and they check different things.

The first 48 hours

This window is about mechanical failures, which are fixable in minutes if you find them:

• Walk the redirect map with a script. Every old URL returns one 301 to a 200. Anything returning 404, 500 or a chain goes on a fix list immediately.
• Read the server logs, not just analytics. Logs show crawler activity and error responses that analytics never records, because a page that fails to load usually fails to fire a tracking script.
• Submit a live enquiry from three different page types and confirm a human received it. Forms that silently stop delivering are the most damaging and least visible migration failure.
• Spot-check the highest-value pages by hand: your top ten landing pages from the last year, opened in a browser, on a phone.
• Confirm the old site is no longer serving its own content on any hostname, including any staging address that was public during the build.
• Check that the new sitemap is being fetched and that it lists what you expect.
• Verify the listing feed ran and that new listings, status changes and removals are flowing.

The first 30 days

This window is about patterns, and the useful posture is comparison rather than alarm:

• Watch the coverage and indexing reports for the new URLs being discovered and processed, and for a matching decline in the old ones. Both curves moving is the sign the move is being understood.
• Compare top landing pages against the same period last year, not against last week, because seasonality in real estate traffic will otherwise read as a migration failure.
• Track enquiry volume by source, which is the number the broker-owner actually cares about and the one that settles arguments.
• Recheck page speed on the new templates. The guidance on Largest Contentful Paint sets the threshold for a good result at 2.5 seconds or less, measured at the 75th percentile of page loads, and a new template loaded with fresh photography is exactly where that slips.
• Keep a running fix list rather than doing one big review at day 30. Most migration issues are small and individually cheap.

Expect fluctuation. Google’s site move documentation states plainly that ranking and traffic changes during a move are normal while the new URLs are crawled and processed, so the question to ask at day 10 is whether the trend is recovering, not whether any single day is down.

The real estate traps

Five things go wrong on brokerage migrations that do not go wrong on other websites. All five are predictable.

Sold listing archives

Sold and expired listing pages are usually the largest group in the inventory and the one most likely to be dropped, because nobody thinks of them as pages that matter. They often carry steady long-tail traffic from address searches and they are frequently linked from outside. Decide their fate before design: keep them as reduced pages, or redirect them to the market page for their town. What you cannot do is discover them the week of launch.

Display compliance on the new site

Your IDX or MLS display obligations do not migrate themselves. The required broker attribution, the data source disclosure, the last-updated stamp and the rules about how long a listing may be displayed after a status change all have to be rebuilt into the new templates and verified against your current agreement, not against what the old site happened to do. Standardised field definitions help here: the RESO Data Dictionary gives the common vocabulary for listing and member fields, which makes it much easier to confirm that the new templates are reading the same fields the old ones did.

Agent profile URLs

Agent profiles are high-value URLs printed on signs, cards and email signatures, and they are usually restructured during a migration because the old vendor’s format was awkward. Map every one, including agents who have since left, and make sure the enquiry routing on each new profile points at a live inbox. A profile that loads correctly but delivers enquiries to a disabled address is worse than a broken link, because nobody notices.

Feed reconnection

The feed is a separate go-live with its own failure modes. Confirm before the domain moves that the new site is authorised to pull the feed, that the pull runs on the schedule you expect, that status changes and removals are honoured rather than only additions, and that images are being fetched rather than hot-linked. A feed that only adds listings looks perfect on day one and is badly wrong by week three.

Duplicate listing URLs from the old vendor

Old brokerage platforms commonly produce several URLs for the same listing: one with a listing identifier, one with an address slug, one inside a search path, sometimes one per agent who shared it. All of them belong in the map, all pointing at the single new listing URL. This is the cleanest opportunity you will ever get to consolidate them, and it is the reason the inventory step insists on exporting every variant rather than one representative per listing.

A plain rollback plan

A rollback plan is one page, written before launch, that says what has to be true to reverse the move and who decides. It is not a sign of low confidence. It is the thing that lets the team launch on a Tuesday morning instead of arguing for another month.

1. Keep the old site running, intact, on its original hosting, reachable at a private address, for at least 30 days after launch. Do not cancel that account on launch day.
2. Write down the trigger conditions in advance. Enquiry forms not delivering and unfixable within a stated number of hours. Listing pages returning errors at scale. Feed not running. Anything else is a fix-forward situation, not a rollback.
3. Name one decision maker. One person calls it, and that person is available on launch day.
4. Document the reversal steps as a numbered list: repoint DNS to the old host, confirm the old site is serving, confirm mail is unaffected, notify the offices.
5. State what happens to content created after launch, so anything published on the new site during the window is not lost when you roll back.
6. Set an expiry date on the plan. After the 30 day window, rolling back stops being viable, the old hosting can be decommissioned, and the redirect map becomes permanent infrastructure rather than a migration artifact.

Most migrations never use the plan. The ones that need it and do not have it are the ones people still talk about years later.

Planning a move off an old brokerage platform? Book a demo and we walk through the inventory and the redirect map against your current site, or read the real estate website redesign page for how the rebuild itself is scoped. If the underlying problem is that listings never had real URLs in the first place, the IDX website development page covers what replaces the widget.