Website migration: how to move your site without losing rankings
Search rankings are tied to URLs. When a site moves to a new platform, every old address that stops working loses the search traffic it earned. The good news: if you map every page and redirect it properly, Google treats the new pages as the replacements and moves the old pages' signals across. Expect some movement while it catches up. I recently moved a site of more than 500 pages and 120 articles to a new platform, checked all 874 redirects and launched with zero broken links. Here's the order I do it in.
Website migration checklist in six steps
- List every URL you have.
- Decide what happens to each page.
- Use permanent redirects, one hop each.
- Carry the content over, not just the design.
- Test before launch, then check on the day.
- Watch the first few weeks.
Step 1: Which URLs does your site have?
You can't redirect a page you don't know about. Before anything is built, collect every URL the old site has, from three places, because each one finds pages the others miss:
- A crawl of the live site with a tool such as Screaming Frog.
- The Page indexing report in Google Search Console (Indexing > Pages), which counts every URL Google knows about, including ones nothing links to any more. Its example lists stop at 1,000 rows, so treat it as a source of missing URLs, not a complete list.
- Your analytics, sorted by traffic, so you know which pages matter most. Export it now as your baseline, so after launch you can show nothing dropped (what to export, and why).
Put them in one spreadsheet, remove duplicates, and mark the pages that bring in the most traffic and enquiries. Those get the most care.
Step 2: What should happen to each old page?
Every old URL gets one of three outcomes: it moves to the same address on the new site, it moves to a new address, or it is retired. Pages with a new address need a redirect. Retired pages should redirect to the closest relevant page, not to the home page by default. If there is no close match, let the old URL return a 404 or 410 (a "not found" or "gone" page). Google may treat many old URLs redirected to one unrelated page, like the home page, as a "soft 404". That means it handles them as if they had simply been removed.
| What happens to the old URL | What to do | Status code |
|---|---|---|
| Same address on the new site | Keep the URL | 200 |
| New address | Permanent redirect, one hop | 301 or 308 |
| Retired, with a close match | Redirect to the closest relevant page | 301 or 308 |
| Retired, no close match | Let it return “not found” or “gone” | 404 or 410 |

Step 3: Which redirects should you use?
Use permanent redirects (301, or 308, which Google treats the same way) for pages that have moved for good. Point each old URL straight at its final address: if page A went to B and B now goes to C, update A to go straight to C. Chains slow pages down, and Google's crawlers follow up to 10 redirect hops by default.
Keep the redirects in place for at least a year. Google recommends that, and in practice there is little reason ever to remove them, because old links from other sites keep sending visitors to those addresses.

Step 4: What content has to move?
A new design is fine. Losing the words Google ranked you for is not. For the pages that bring in traffic, keep the page titles, headings and main text close to what they were, at least for the launch. Rewrite them later, one page at a time, so you can see the effect of each change.
- Keep page titles and meta descriptions, or improve them deliberately.
- Carry over structured data, image alt text and internal links.
- Keep image URLs where you can, or redirect the important ones, so image search traffic isn’t lost.
- Update internal links to point at the new URLs directly, instead of relying on redirects.
- Make sure forms still send enquiries to the same inbox or CRM.
Step 5: What should you test before and on launch day?
Before launch, crawl the new site where it is being built and fix what the crawl finds. While it is there, keep it out of Google with a password or a noindex tag (a line telling Google not to list the page). Remove both at launch. A noindex left on after launch is one of the most common ways a migration loses its traffic. Also check that:
- robots.txt (the file that tells search engines what to crawl) on the new site doesn’t block pages you want found.
- Canonical tags (which tell Google the main address of a page) point at the live domain, not the address the site was built on.
- One version of each address wins (https, with or without www, with or without a trailing slash), and the others redirect to it.
Right after the new site goes live, run the full list of old URLs through a crawler and confirm each one returns a single permanent redirect (301 or 308) to the right page, and that page loads normally (a 200 status). Check for 404 errors (pages not found) and redirect chains. On the move I mentioned above, this is how all 874 redirects were verified before anyone called it done.
Then submit the new sitemap in Search Console. If the domain changed, also use Search Console's Change of Address tool. You need to own both sites in Search Console under the same Google account, with a 301 redirect from the old home page to the new one. It isn't for moves from http to https or from www to non-www. Keep the old domain registered for at least a year so its redirects keep working and nobody else can buy it.
Step 6: What should you watch after launch?
Some movement in rankings is normal while Google recrawls the site. Watch the Page indexing report in Search Console for new errors, compare traffic on your most important pages week by week, and fix anything that slipped through. On a medium-sized site it can take a few weeks or more for Google to show the new URLs in place of the old ones, so give it time before you judge the move.
If you're planning a move and want it done carefully, tell me about it or see the sites I've built. If the move comes with a new design, read what to prepare before a redesign. And if you haven't picked the new platform yet, start with how to choose a website platform.
