Moving Off a Brokerage Website Without Losing Your Visibility

The uncomfortable thing about a brokerage-provided website is that its value accumulates somewhere you do not control. The pages rank on the brokerage’s domain. The links point at the brokerage’s domain. The profile your clients have saved is on the brokerage’s domain. When you leave, none of it moves with you, and the only part of the arrangement that was ever portable was whatever you registered in your own name. This piece covers what you own, what you cannot take, and the migration work that preserves as much as can be preserved.

What you own, honestly

Start with an inventory, because the answer is usually narrower than people expect and it is better to know in advance.

You almost certainly own:

• The photographs you commissioned and hold the rights to, though check the photographer’s license, because many are limited to marketing a specific property rather than general use.
• Copy you wrote yourself.
• Your client list and your own records, although how you can use them is governed by your agreement.
• Any domain registered in your name at a registrar you can log into.
• Reviews you have collected on independent platforms, since those live with the platform and are attached to you.

You almost certainly do not own:

• The website, if it was provided as part of your affiliation. It is typically licensed for the duration of the relationship.
• Anything on the brokerage domain or a subdomain of it. Every URL, and every link pointing at those URLs.
• The IDX feed, which is licensed to the brokerage under the terms of the local board or association.
• The templates and the design.
• Email at the brokerage domain, and every message in it.
• Content in a CRM you cannot export, which in practice means any CRM you have not tested an export from.

The grey area is the content you wrote inside their system. You may hold the copyright to the words and still have no mechanism to get them out. Copy and paste is not beneath you here. A weekend spent saving your own writing into documents is a weekend that pays for itself.

Why rankings do not travel

A search engine’s index is organized by URL. Signals accumulate against URLs and, by extension, against the domain those URLs sit on. That is the whole reason a domain matters.

So when a page at bigbrokerage.com/agents/your-name ranks for a local search, the thing that ranks is that URL on that domain. It carries the domain’s overall standing, the links pointing at it, and its own history. You contributed the content. You did not acquire the address, and the address is what the index holds.

Leaving means that URL either continues to exist without you, gets reassigned to another agent, or returns a not found error. In none of those cases does its standing transfer to a new domain you have just registered, because nothing connects the two. There is no mechanism by which a search engine could know they are related, and no honest way to create one.

This is not a reason to despair. It is a reason to understand what the actual task is: you are not migrating a site, you are starting one, and everything that makes that faster is worth doing early.

The case where signals do transfer

There is one situation where a move genuinely preserves what you built, and it is worth separating clearly: moving your own domain from one site to another.

If you already own youragentname.com and you are replacing the site that sits on it, that is a site move with URL changes, and Google documents the process precisely. The mechanism is permanent redirects: every old URL points at its closest equivalent on the new site, and the signals associated with the old URL consolidate on the new one.

The rules that make it work:

• Map every URL individually. Old area page to new area page. Old listing to new listing. Old article to new article. This is a spreadsheet, and it is the whole job.
• Redirect to the equivalent page, not to the home page. A mass redirect of everything to the root is treated as a soft not found, and it throws away exactly what you were trying to keep.
• Use permanent redirects. A temporary redirect tells a search engine the old URL is still the real one.
• Do not chain them. Old URL to new URL, one hop. A chain of three redirects loses value at every step and is slow for visitors.
• Keep them indefinitely. Google’s site move guidance suggests at least a year, and there is no reason to ever remove one. Links on the web do not expire.
• Move in one pass rather than page by page over months, so the change is legible rather than looking like continuous instability.

If the domain itself is changing as well, Search Console’s change of address tool is the formal notification that the two properties are related. It works alongside the redirects rather than instead of them.

Getting the URL list

You cannot redirect what you have not listed, and the list is usually larger than memory suggests.

Four sources, in order of usefulness:

1. Search Console, if you have access to the old property. The pages report is the authoritative list of what was actually indexed.
2. The old sitemap. It lives at a predictable address and it is the site’s own statement of what exists.
3. A crawl of the old site, using any site crawler, which finds pages the sitemap forgot.
4. Analytics, filtered to landing pages over the last year or two. This catches the pages that still receive visits, which is the set that matters most if you have to prioritise.

Combine, remove duplicates, and sort by whatever traffic data you have. Then map each one. Where there is no equivalent on the new site, redirect to the most closely related page rather than to the home page: an old listing goes to the area page it belonged to, an old article on a topic you no longer cover goes to the nearest thing you do cover.

What to rebuild first

You are effectively launching, so the order from a launch applies, with one difference: you already know which pages earned attention.

First, the pages that were working. Whatever your analytics say brought people in, rebuild those, better. If three area pages produced most of your inquiries, those three are the first three you write.

Second, the areas you actually work. One page each, describing geography, housing stock and amenities in factual terms. This is the structure that makes a new site findable for the searches that matter locally, and it is set out in full in the neighborhood page architecture.

Third, your active listings, each on its own URL, with the structure described in the listing page structure.

Fourth, the pages that establish who you are. About, contact, the legal pages.

Fifth, everything else. The blog, the guides, the calculators. These are additions to a working site, not prerequisites for one.

Resist the urge to recreate the old site page for page. A brokerage template usually carries a number of pages that existed because the template had them, not because anybody needed them, and rebuilding those is work with no return.

Email, and why it is the part that hurts

The website gets the attention and email is the part that actually disrupts a business, because email is where the relationships live.

An address at the brokerage domain stops working on the day the affiliation ends, sometimes without warning. What goes with it is not just future messages: it is the archive, the threads with past clients, the attachments, and every service that uses that address as a login. Password resets for your CRM, your scheduling tool, your accounting software and your social accounts are all sent somewhere you no longer have access to.

The fix is the same as the domain fix, made early:

• Run email on your own domain from the start. Almost every registrar and hosting provider offers this and the cost is small.
• Use it as the login address for every service you rely on. This is the step that turns a difficult transition into an inconvenient one.
• Export your mail archive while you still have access, into a format you can search.
• Set up a forwarder during any notice period, if your agreement allows it, and use the window to tell people the new address directly rather than relying on the forwarder to do it forever.

An agent who does this once never thinks about it again. An agent who does not, does it in a hurry, at the worst possible moment, while trying to close deals.

The things outside your website

A migration is only half a website job. The other half is every place your old address is published, and this is where moves quietly leak.

• Google Business Profile. Update the website field to your new domain. This link is often the first click from a local search.
• Portal profiles. Every listing portal you have a profile on carries a website field.
• Your board or association directory.
• Social profiles. Every bio, on every platform.
• Your email signature, which is the one you will forget and the one you use twenty times a day.
• Local directories and chamber listings.
• Print material. Signs, cards, flyers. A domain you cannot change is a good argument for choosing a domain you will keep.
• Anyone who links to you. If a local publication, a partner or a supplier links to your old page, ask them to update it. A direct link is worth more than a redirect, and people generally say yes.

Keep this as a checklist and work through it in the week after the move rather than as you think of things over six months.

A migration timeline that works

Compressed into four weeks, which is realistic for a single agent with a small site.

Week one: secure the assets. Register or confirm the domain in your own name. Set up email on it. Export everything exportable: the mail archive, the CRM records, the photographs, your written copy. Pull the URL list from Search Console, the sitemap, a crawl and analytics, and build the mapping spreadsheet. Nothing visible happens this week and it is the week that decides how the rest goes.

Week two: build the pages that were working. Whatever the analytics said brought people in, plus the areas you genuinely work and your active listings. Write them properly rather than porting them. This is the only chance you will get to improve them with no cost to anything, because nothing is live yet.

Week three: build the rest and wire it up. About, contact, the legal pages. Load the redirect map. Generate the sitemap. Test every form on a phone. Check the robots file allows crawling, which is the single most common reason a new site stays invisible.

Week four: go live and tell everyone. Point the domain. Confirm the certificate. Verify the property in Search Console and submit the sitemap. Then work the external checklist above in one sitting: profile, portals, directory, social bios, email signature. Send a short note to your active clients with the new address. Ask anyone who links to you to update the link.

Then stop, and let it settle for a quarter.

The temptation in week four is to keep building, because the site feels unfinished next to what you left. It is unfinished, and that is correct. A site that launches with the pages that matter and grows steadily reads as a business that is working. A site that launches complete usually launched late.

What to expect afterwards

Expect a dip, expect it to recover, and do not respond to it.

Even a clean move produces a period where things are unsettled: a search engine has to recrawl, follow the redirects, and reassociate signals with the new addresses. Traffic moves around during that period, and individual pages can rank oddly for a while before settling.

The mistake is to react inside the window. Changing URLs again, adding redirects on top of redirects, rewriting pages in a panic: each of these extends the period rather than shortening it. The site needs to be stable for long enough to be recrawled and understood.

What to actually do:

• Watch Search Console for crawl errors and for pages reported as not found. Fix the mapping mistakes, which are real problems.
• Check the redirects work, in bulk, with a crawler. Every old URL should reach a live page in one hop.
• Submit the new sitemap.
• Leave the pages alone otherwise.
• Give it a quarter before drawing conclusions.

If you are starting a new domain rather than moving an old one, there is no dip to recover from, because there is nothing to dip. There is a build, and the site accumulates from zero. That is slower in the first months and it is the honest baseline, which is better to plan around than to be surprised by.

The lesson to carry forward

Everything in this piece reduces to one decision made early or made late: whose name is the domain in.

An agent who registers their own domain at the start of their career, points it at whatever site they have at the time, and keeps it through every affiliation change, never has to read a piece like this. Their address is constant, their links accumulate against it for a decade, and changing brokerages is a change of employer rather than a change of identity.

An agent who uses whatever the brokerage provides has a website that is genuinely free, works perfectly well, and belongs to somebody else. That is a reasonable trade to make knowingly. It is a bad one to discover.

If you are somewhere in the middle, which is most people, the useful move is the small one: register the domain today, put something on it, and start pointing at it. The migration you might do in two years gets easier every month you do that.

For what a site of your own carries once it is yours, the features list sets it out, and the launch checklist covers the order to build it in.