How to move a website without losing your rankings

What actually breaks when a site moves

Nothing dramatic happens on launch day. The new site looks better, everyone is pleased, and a week later the old addresses turn into error pages.

Say your old site had a page at yourbusiness.ca/services/emergency-callout. Google has it indexed and a local supplier linked to it four years ago. If the rebuild moves that content to /emergency/ and nothing connects the two, both land on an error page. Google eventually drops the old address, and the supplier’s link stops counting.

Two more things fail later and silently: your contact details quietly change wording, and the file listing your pages for search engines is never sent again. You just get fewer calls, with nothing obvious to blame.

Step 1: keep the domain, and check who holds it first

Changing the domain is the largest single cause of losing everything in a move. Years of links, listings and print point at one name; a new one starts from zero. If you must change it, the redirect work below becomes the whole job.

Most rebuilds need no new domain. They need confirmation that it is genuinely yours before anybody starts. Take five minutes with who actually owns your domain name first. If the answer is a departed contractor, the recovery order is in the rescue guide for when your web designer disappears.

Step 2: write the URL map before anything is built

A URL map is a two-column list. Left: every address on the old site. Right: where that content will live on the new one. Done early, it shows which pages have to survive.

To make the left column without technical help:

• Open your old sitemap if you have one, usually at yourbusiness.ca/sitemap.xml.
• In Google, search site:yourbusiness.ca to see the pages Google holds for you.
• In Google Search Console, the Pages report lists what is indexed, and the Performance report shows which addresses bring in visits.
• Click through your own navigation and add anything the first three missed, including PDFs and old landing pages.

Then fill in the right column. A page you are merging or dropping still needs a destination: the closest surviving page, not the home page. Sending everything home throws away most of the benefit, because someone who wanted your emergency callout page gets a general welcome and leaves.

Keep the map. It is your checklist after launch, and it makes the next move easier.

Step 3: put a permanent redirect on every old address

A redirect tells your web server to send anyone asking for the old address to the new one. There are two kinds:

• A permanent redirect (your developer will call it a 301) tells search engines the page has moved for good, so the new address inherits the old one’s standing.
• A temporary redirect (302) says the move is short term, so search engines keep the old address on file and wait.

For a rebuild you want permanent, on every row of the map. Ask for it in writing, because a temporary redirect looks identical to a visitor and behaves completely differently to a search engine.

Also: redirect in one hop, not a chain of three, and make sure the plain and www versions of your site land in the same place, so each page has one working address.

Step 4: keep your name, phone and address identical everywhere

Your business name, street address and phone number are how a search engine matches your website to your Google listing, your directory entries and mentions of you elsewhere. Rebuilds rewrite them without anyone deciding to. Suite 4 becomes Unit 4. The phone number gets different brackets. The legal name in the old footer becomes a shorter trading name.

Nobody catches that by reading, and it makes your listings harder to match. Write the three details out once, exactly as on your Google Business Profile, and have the new site copy that version. Check the footer, the contact page and the structured data a developer adds for machines to read.

A person should not have to remember this. On a Droom client build, the name, address and phone number on every page are generated from one declared facts file, and the release gate regenerates them and refuses to ship if they have drifted. The same file produces the sitemap and the plain-text summary AI assistants read, so changing a number updates all of it at once instead of in eleven places.

Step 5: resubmit the sitemap and tell Search Console

Your sitemap is a file listing the addresses on your site. Search engines use it as a hint about what changed, which matters most in the week everything changes.

On launch day, check the new site has a sitemap listing the new addresses, not the old ones (which is what happens when the file is copied across instead of regenerated). Then in Google Search Console, go to Sitemaps and submit the new file’s address. Do the same in Bing Webmaster Tools.

If the domain stayed the same, that is all. If it changed, Search Console’s Change of Address tool wants both the old and new sites verified in the same account first, so set that up before launch.

Step 6: watch for a few weeks, and know what you are looking at

Rankings wobble after even a clean move. Give it three or four weeks, and check these:

• Not found (404) errors in the Search Console Pages report. Each is an old address you missed. Add it to the map, add the redirect, done.
• Total clicks and impressions in the Performance report, against the same weeks before the move. A dip in the first fortnight is common; one still deepening after a month is a signal to go looking.
• Which addresses lost the most. Sort the Performance report by page. One page falling off usually means one bad redirect, a ten minute fix.
• Your own spot checks. Paste twenty old addresses from the URL map into a browser and confirm each lands on the right new page. Repeat a month later.

Leave the redirects in place for good. They cost nothing, and old links keep arriving for years.

What to ask the person doing the rebuild

You need not do any of this yourself. You do need straight answers to five questions, ideally in an email:

• Will the domain stay in my name, at my registrar account, throughout?
• Can I see the URL map before the build starts?
• Are the redirects permanent, and does every old address have one?
• Who submits the new sitemap, and when?
• Who is checking Search Console a month from now, and what do I get to see?

Watch for vagueness on the third and fifth. Both are ordinary, inexpensive work; they need somebody willing to own them by name.

Ours: the URL map is written before design starts, the redirects go live with the site, and the finished repository is handed over with both in it. Same principle as the files themselves: anything you would need to leave should already be in your hands. Fixed rebuild prices are on the pricing page, and what a build includes is on the website service page.