How To Migrate the Same Website to a New Domain

Migrating your website to a new domain is no trivial matter.

It reflects a significant transition, whether driven by corporate rebranding, strategic redirection, or simply pursuing a more resonant name. 

But don’t let your guard down. 

You’d be surprised if we told you how often our prospects have contacted us with a completely tanked website due to a poorly planned migration process.

This guide will lead you through the essentials of domain migration with precision and foresight. From pre-migration preparation to ensuring search engines recognize and index your new URLs, we’ll cover the steps necessary to make your transition seamless and efficient.

What Do You Need to Get Started?

First, here’s a short checklist of what needs to be done to ensure a successful migration.

1. Set up the staging environment

2. Make a list of all URLs on the production website

3. Map out the 301 redirects accordingly (optional)

4. Set up the 301 redirects on the staging environment

5. Update internal links on the staging environment

6. Set up robots.txt & XML sitemaps

7. Review each aspect of the staging environment (we’ll give you a list of the most important things later)

8. Push the staging website to production

9. Double-check robots.txt & XML sitemaps

10. Double-check canonical tags

11. Double-check all meta tags

12. Double-check all 301 redirects

13. Double-check internal links

14. Submit a Change of Address request via Google Search Console

Now, let’s get to it.

1. Set up the Staging Environment

Why a staging environment?

Firstly, your production website should still be available for clients, visitors, and crawlers. It’s best to leave it and work on the migration in the background.

Secondly, you won’t know how long it’ll take for the migration to be 100% done. Based on our experience, a migration project can take 1-2 months (small local businesses) to a year or more (big corporates), depending on the project’s complexity and the size of the website.

You don’t want service disruption during the process, risking losing clients and rankings/traffic simultaneously. This step is usually easy; you should already have access to developers (either in-house or freelancers), so setting up a staging environment won’t take much time.

The most crucial action you must carry out here is to set the staging environment to noindex,follow.

Why noindex?

Noindex is essential if you don’t want your staging environment with the same content as your production website to be indexed. This can cause a lot of trouble during or even after the website migration.

Why follow?

This step isn’t mandatory, and you can set it to noindex nofollow if that’s more suitable for you. But if you have access to website crawlers (Screaming Frog, Sitebulb, etc.), having the follow tag will make it easier to crawl and review the staging website.

NOTE: Even though it’s not crucial for your site, keeping the same URL structure on your staging environment and new production website would be easier.

For example, don’t add a trailing slash to URLs if your existing production site doesn’t have it, e.g., from domain.com/my-page-here to domain.com/my-page-here/ and vice versa.

This will make planning much easier.

2. Make a List of All URLs on the Production Website

Ideally, if you can access website crawlers, you can run a quick crawl to get all the important information you need to put everything in a sheet. The information you can grab from that crawl includes:

• URLs
• Meta titles
• H1s
• Meta descriptions
• Clicks
• Sessions

With the meta tags you get from the crawl, you can review the staging website to ensure everything is in place (step 6) and double-check them when the staging website is pushed to production (step 10).

“Why do I need Clicks and Sessions data?” you might ask.

You’ll need them to know what URLs to prioritize and double-check when everything is live (step 11).

Also, if your website has three pages bringing in 90% of the traffic, you definitely don’t want to lose sight and must treat them carefully.

If you don’t have access to website crawlers, exporting a list from either Google Search Console or Google Analytics works too. It’s not the most comprehensive way of doing things, but at least you’ll still have a list of the most important URLs and their clicks/sessions.

After this step, you should have a spreadsheet that looks like this.

The meta tags you have here could be a helpful resource for the developer when setting up the staging environment.

3. Map Out the 301 Redirects Accordingly (Optional)

As we’re only changing the domain name, setting up 301 redirects via the htaccess file is the easiest way. 

Here’s a simple guide for your reference: https://www.inmotionhosting.com/support/website/setting-up-a-301-permanent-redirect-via-htaccess/

But, in some cases, some pages are no longer relevant on the new site (old/out-of-stock products, sale landing pages, etc) that you’ll want to delete.

You can map out their new destinations by filling out the New URL column.

Once completed, the final sheet should look something like this.

Note: even if you set up the 301 redirects via htaccess, it’s always better to fill out the New URL column so you have something to cross reference when the new website is live.

4. Set Up the 301 Redirects on the Staging Environment

Now, if you choose the htaccess method, feel free to set it up by following the guide above.

If you opt for the mapping method, this is when you set up the 301 redirects.

Usually, all major CMS such as WordPress, Magento, and Shopify can import 301 redirects using CSV files, either directly or with the help of a plugin/app, so this shouldn’t be too complex.

5. Update Internal Links on the Staging Environment

Because we’re moving the entire website to a new domain, the URLs on the new production website will differ.

For visitors, because 301 redirects are in place (if we set them up correctly), there won’t be any significant changes to how they navigate the site.

However, for crawlers, having 301 redirected URLs accessible can slow down the load time, thus potentially causing crawling issues. If your website is more extensive (ten thousand pages range or above), replacing 301 redirected URLs is essential.

Also, the server can sometimes behave abnormally, resulting in a redirect that takes a few minutes to load fully. If that happens, you’ll wish you cleaned everything up when the site was still in staging.

Enough with the reasoning; let’s get to the execution.

First, we need to differentiate between relative and absolute URLs.

In short, here is the difference between them:

Relative URL: /my-page-here

Absolute URL: https://domain.com/my-page-here

There are a few different scenarios here:

If we change the domain, migrate everything over, and use relative URLs, then it’s highly likely we don’t have to do anything here because when we migrate over, the relative URLs will be the same no matter what the domain is. You only need to be careful of the forward slash at the start of the relative URL.

For example:

If your domain is domain.com and the proper relative URL is “/my-page-here,” but you mistakenly use “my-page-here,” there’ll be a lot of 404 URLs accessible on your site.

If we fall into any of the scenarios below, then we need to carry out this step thoroughly:

• Change the domain and migrate only a portion of the site over, no matter what type of URL is used
• Change the domain, migrate everything, and use absolute URLs

You’ll need a site crawler to review and replace all 3xx (or even 4xx) URLs fully. Our tool of choice is usually Screaming Frog.

This is where the follow tag on the staging site comes in handy. With that, you can easily set up a crawl with the tool of your choice without messing with the settings.

After running a crawl, you can export a list of 3xx/4xx URLs and the source URLs (i.e., where they come from.)

We can easily identify and replace broken links with that information.

6. Set Up robots.txt & XML Sitemaps

These are two of the most crucial components of any website.

For robots.txt, you want to set it up so crawlers don’t waste time with redundant, low-value pages (filtered, parameter, internal search result, etc.) but have access to all the essential stuff (landing pages, collection and product pages, etc.).

Most of the time, robots.txt will be set up by default if you use any major CMS (again, either by the CMS itself or via plugins/apps). But, as some websites are different, knowing what to add and what to modify in robots.txt requires extensive planning.

The principle is the same for XML sitemaps. You want to present only essential pages in XML sitemaps, and anything of low quality will be removed.

You should also add the XML sitemaps to the robots.txt, to make it easier for crawlers to access them.

7. Review Every Aspect of the Staging Environment

What do we mean by every aspect?

We mean everything you could think of.

You don’t want to push an incomplete website for the world to see. Sometimes, a small mistake can undo years of hard work, so it’s crucial to be extra careful. 

Some of the most important things you should check, preferably manually, are:

• Logo
• Favicon
• Placeholder content (lorem ipsum content – this is extremely common during the developing phase)
• Main menu
• Contact information (phone number, address, email, etc.)
• Checkout process (if you’re selling products) or contact process (if you’re selling services)
• Heading structure

Unfortunately, this also means checking everything on the desktop and mobile versions.

Yes, it’s a hassle. But we’d rather spend extra time during this process than worry when the issues are found on the production site at a later stage.

8. Push the Staging Website to Production

It’s D-Day, the day you’ve been waiting for. The day you can show off your hard work for the last few weeks, months, or even years to the public.

You should be proud. You’ve come so far to get to this moment.

But don’t let your guard down. The moment you push the staging environment to production, the 2nd and most significant phase of the migration process begins.

We highly recommend NOT going live on a Friday unless your suppliers (Dev, SEO, etc.) are willing to work over the weekend. 

9. Double-check robots.txt & XML Sitemaps

It’s never wrong to double-check your work. We’re only human, and we make mistakes.

In this step, you’ll want to:

• See whether the robots.txt is blocking any crucial parts of the site
• Check and see if the XML sitemaps contain any redundant URLs

We’ve seen cases where robots.txt blocks the entire website or XML sitemaps only have URLs from the staging website. Neither is ideal, especially in the early stage of the new website.

A simple tool like https://technicalseo.com/tools/robots-txt/ can help you verify how well your robots.txt works.

10. Double-check Canonical Tags

Canonical tags are fundamental but also easily forgotten.

The canonical tags from the staging website can sometimes be pushed over during the push from staging to production. Based on our experience, the potential issues you might encounter here are:

• Canonicalized to the staging website
• Canonicalized to the old production website
• Canonicalized to HTTP version (if your site is using HTTPs – if you’re not, what are we doing here?)
• Canonicalized to incorrect URLs

Below is an example of a page canonicalized to the incorrect one, blurred to protect our client identity.)

If you can’t check all pages, you should prioritize top-performing pages to ensure they’re good to go.

11. Double-check Meta Tags

With the spreadsheet you created in Step 2, you can double-check all pages and see if the meta titles, meta descriptions, and H1s match what they used to have.

If you don’t have the time or resources (i.e., crawler tools), you can prioritize checking the top-performing pages. Having hard-earned rankings drop because of incorrect meta titles is the last thing you want.

12. Double-check All 301 Redirects

With the information you’ve gathered in Step 3, you can use a crawler tool (such as Screaming Frog) or a simple tool like https://httpstatus.io/ to check them in bulk.

This is where you check whether any 301 redirects were established incorrectly.

You should be fine if you migrate everything over and set up 301 redirects via htaccess.

But if you have to map out some URLs manually, this is your fallback plan. Check all 301 redirects, or at least prioritize the redirects for top-performing pages to identify any potential issues.

13. Double-check Internal Links

With the information you gained in Step 5, it’s time to check all internal links on the new production website.

If you use relative URLs, you’ll most likely be good to go. However, many potential issues can occur if you use absolute URLs.

• Absolute URLs from the old website
• Absolute URLs from the staging website
• Absolute URLs from the new website but redirected/not accessible

14. Submit a Change of Address Request via Google Search Console

Because we are moving the website to a new domain, we must submit a Change of Address request via Google Search Console.

You can follow this Google guide to ensure everything is set up properly.

Once you’re done, you should see this message in your new Google Search Console property:

This is evidence that your site has successfully migrated to its new domain and that everything has been established correctly. 

Need Help Migrating Your Website to a New Domain? We Can Help.

Still confused by the migration process? Don’t worry, you’re not alone. 

Migrating your website to a new domain can be a long and complex endeavor. Faults and issues lurk around every corner, but these 14 steps will help ensure a smooth and stress-free transition.

If you want to alleviate the headache and ensure minimum service disruption, the SwishDM team can help with your website migration. We’re experts in site migration and are equipped with the necessary tools for success. 

We’ve seen it all, so get in touch to see how we can help today.