How To Merge and Migrate Multiple Websites to One Completely New Domain

Merging and migrating multiple websites to a completely new domain is a complex process that requires extreme attention to detail. 

Whether driven by rebranding or streamlining user experience, it requires careful planning and execution to avoid disruptions and maintain your hard-earned SEO results. 

Our comprehensive guide will walk you through the essential steps to ensure a smooth transition, preserving your rankings and traffic while minimising downtime and potential issues.

Let’s dive into the detailed steps required for a successful website merger and migration.

1. Set Up the Staging Environment

Like any other website migration project, this step is essential because the staging site will be developed while other production websites are online.

Most of the time, the new website won’t go live until everything is set up and ready. In some cases where the production website is already up and running (for example, in a brand merger), it’s still a good practice to carry out pre-migration work on a staging site.

Also, it’s crucial to set the staging environment to noindex, follow to prevent search engines from indexing it while still allowing you to set up a crawl to review the site in the initial stages.

2. Make a List of All URLs on All Existing Websites

This is the beginning of the most important process of the whole migration project — so pay attention!

Because we’re going to merge multiple websites into one, having a full list of all URLs on all existing websites is the key to ensuring that:

• No duplicate or nearly identical pages will go live separately on the new website
• All important landing pages and informational content (blogs, news, press releases, etc) will be migrated over

To do that, you must use either a website crawler (Screaming Frog, Sitebulb, etc) and/or Google Analytics/Google Search Console.

The information you’ll need to grab from the crawl/export includes:

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

Like any other website migration, you’ll need the Clicks and Sessions data to determine which page to prioritize and double-check when the new website goes live.

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

Ideally, you’ll need a dedicated tab for each website, and the column layout needs to be identical. That way, you’ll have the information in separate places while still being able to glance at each tab and know what needs to be reviewed.

Tip: because we’re an agency, having a “Client Notes” column is essential for early communication. The client can review the sheet and leave us comments on what to remember for a specific page before we suggest anything else. This helps us save a lot of time going back and forth during the planning phase.

If you’re working internally on this project, having a similar column for other involved departments could still have the same positive impact.

3. Review & Determine What Pages Need To Be Kept on the New Site

With the information from the previous step, it’s time to do the tedious work of manually reviewing each page.

There might be a way to use AI to group these pages by topical relevance automatically, but we’re afraid there’s no shortcut here if you want to do it right.

By reviewing everything manually, you’ll better understand the existing sites’ strengths and weaknesses, how they’re structured, and get a clearer vision of how the new site will look by the end of this step.

There are many ways to get started with this step. But, to minimise potential SEO issues with the new site, i.e. significant traffic drop after the launch, you should prioritise the following:

• Top traffic pages
• Key landing pages

Mapping them carefully and correctly, ensuring they’re set up properly on the new site is already 80% of the work because they’re your bread and butter for generating traffic and new customers.

The remaining pages will either be admin pages, which should be easier to do and/or low-traffic pages which aren’t as high risk. 

After you go down the list of top traffic & critical landing pages, you should have a better idea of what the replacement pages should look like and where they should be on the new site. Once you figure it out, add the new site’s URLs under the “New Destination” column.

For the remaining pages with low traffic, the easiest way to tackle them is:

• Using meta title & H1 data to group them by topical relevance
• Review the content on pages with similar content to make sure they’re indeed related and make adjustments if needed
• Decide whether you need to migrate the content as is, merge all content, or not migrate them to the new site

This is where a streamlined communication channel is essential. During this step, as an agency, we’ll have multiple meetings and emails, plus the notes under the “Client Notes” column, to discuss and develop a suitable decision for each page. If you’re working with your internal team, having meetings is a great way to keep everyone on the same page and discuss all possible solutions too.

Again, once you’re done, you should fill out the “New Destination” column accordingly. This is important to ensure a smooth transition with the development team.

After you’ve done all the hard work, the final sheet should look like this.

Tip #1: Ultimately, we’re human, and humans make mistakes. It’s never a bad idea to have someone cross-check your work to ensure the actionable items make sense and everything looks good.

Tip #2: During this step, if possible, you should plan out the meta titles, H1s, and meta descriptions (optional—you can work on them later) of the new pages on the new website.

Because you’re already working on the sheet with the available information from the crawls, this is the time when your mind is at its sharpest. And while you’re at it, it’s better to save some time and finish planning the necessary stuff that will be beneficial in the future.

4. Make a List of New Pages on the Staging Website

Once the mapping sheet is ready, you should have a list of all the essential new pages on the new website. It’s time to make a dedicated spreadsheet for the staging website containing all the pages that need to be created.

Why, you ask?

You don’t want to send the entire mapping sheet to the development team. We’ve seen many cases of miscommunication that resulted in precious lost time, and it’s never a good experience.

Instead, you should create a clean sheet of all pages that must be created on the new site. That way, the dev can easily see the work that needs to be done, and you can double-check their work later, too.

Now, in this spreadsheet, ideally, you’ll want to have at least the following information:

• URL (of the page on the new website)
• Meta title
• Meta description
• H1

If you follow our second tip in step three, you should have everything ready at this point, making it a simple copy-and-paste job.

If you haven’t worked on it yet, then this step will require you to do some additional work.

Using the information you have in steps two and three, you can plan out the meta titles, H1s and meta descriptions of the pages on the new websites.

Once everything is complete, you should keep this spreadsheet handy because it is extremely important for this migration project.

5. Create New Pages on the Staging Website

With the information you’ve gathered so far, you can either create the pages yourself or forward them to the appropriate department so they can help you deploy them accordingly.

This is the first place your new spreadsheet in step four comes in clutch.

If you have dev resources, you can forward the sheet to them, and they can help you deploy the new URLs, meta titles, meta descriptions, and H1s accordingly. This can help you save a ton of time during the development phase.

Even if you don’t have dev resources, the sheet will keep you accountable, and you can see your progress when you work through the sheet yourself.

After all pages are created, you can easily use the sheet to double-check either the devs’ or your work. That way, you can ensure that nothing important slips through the cracks.

6. Migrate the Content

With the new pages going live on the staging site, it’s time to plan out & deploy the actual content on the new pages, too.

There are a few scenarios that need different approaches here:

• If you migrate the old page as is, you can keep the same content,
• If you migrate & merge multiple pages into one, you can either use the content on the page that gets the most traffic or merge different parts of other pages to the main pages (if the content is valuable),
• If it’s an admin page (about us, contact us, privacy policy, etc.), you must update the content to reflect the changes.

That way, you can ensure that the ranking pages with the ranking content are moved to the new site.

Tip #1: You must also migrate the heading structure over to ensure everything stays consistent (unless the existing heading structure is a mess).

Tip #2: Remember to check for lorem ipsum content, as it’s usually added as a placeholder in the development phase.

Tip #3: Always make sure that all old brand mentions are updated to the correct brand name of the new production domain. 

7. Create a 301 Redirects Sheet

This should be another simple copy-and-paste job, but the benefits it’ll bring are enormous.

Using the mapping sheet you created in step three, you can make a mapping sheet with all URLs on the existing websites and the new destinations on the new website.

The final sheet should look something like this.

With this sheet, you can quickly double-check the redirects on the staging site and even the new production site when it goes live. Also, if you have a straightforward sheet like this, it’s easier to have someone else set the redirects up.

Tip: We recommend using our template above which contains the Existing website URL, Relative URL & Redirect to columns.

The two columns we will use to set up 301 redirects on the staging site are Relative URL & Redirect to. 

Because you’ll set up site-wide redirect rules via htaccess (step 13), the redirect from domainA.com/old-page to domainB.com/old-page will be handled automatically. Then, on domainB, you only need to set up a 301 redirect from domainB.com/old-page to domainB.com/new-page, and everything should work fine.

Also, you don’t need homepage redirects on this sheet either because the redirect rules in htaccess will handle that.

But why don’t you use relative URLs under the Redirect to column?

Because setting up redirects to relative URLs (i.e., redirecting to incorrect pages because of similar URL structure) carries some risk. We want to ensure that all the 301 redirects, at least in the initial phase, are intended and point to absolute URLs.

And for the Existing website URL, it’ll come in handy in step fourteen.

8. Set Up the 301 Redirects on the Staging Environment

With the sheet you put together above, you can send everything to the development team so they can help you deploy the redirects. Or, you can bulk import the redirects yourself. 

Luckily, most major CMSes have redirect importing features (either through built-in features or an app/plugin), so you should be good.

9. Update Internal Links on the Staging Environment

Because we’re merging multiple websites into a new one and, in most cases, you’ll reuse the old content on the existing websites, the final URLs on the latest production website will be different, thus making updating internal links a must-do job.

With 301 redirects correctly set up, visitors’ experience will not significantly change.

However, for crawlers, having broken URLs (3xx, 4xx, or even 5xx) can slow load times, potentially causing crawling issues. This becomes especially critical for larger websites with ten thousand pages or more, making it essential to replace broken URLs.

Additionally, it’s better to solve these minor issues early on after the new production site goes live in case the servers behave unpredictably.

You’ll need a site crawler to review and replace all broken URLs. Our tool of choice is usually Screaming Frog.

This is where the follow tag on the staging site comes in handy. You can easily set up a crawl with your preferred tool without adjusting the settings.

After running a crawl, you can export a list of broken URLs and their source URLs (i.e., where they originate). This allows you to identify and replace broken links effectively.

10. Set Up robots.txt & XML Sitemaps

Robots.txt & XML sitemaps will ensure that crawlers can easily crawl the most important parts of your site.

For robots.txt: You want to configure it so crawlers don’t waste time on redundant, low-value pages (like filtered, parameter, internal search results, etc.) but have access to all the essential content (landing pages, collection pages, product pages, etc.).

Most of the time, robots.txt will be set up by default if you use any major CMS (either by the CMS itself or via plugins/apps). However, since websites can vary significantly, knowing what to add and modify in robots.txt requires careful planning.

For XML sitemaps: You want to include only essential pages in your XML sitemaps, removing any low-quality content.

Additionally, adding the XML sitemaps to the robots.txt file is important to make them easier for crawlers to access. This ensures that search engines can efficiently find and index your most important pages.

11. Review Every Aspect of the Staging Site

Even though we plan and build the staging site from the ground up, it’s always a good idea to double-check everything to ensure we don’t forget anything during the planning phase.

Sometimes, a missing H1, messy heading structure, or incorrect redirect can plummet the traffic of your new production site after launch.

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

And yes, you need to check both the desktop and mobile versions. You don’t want to focus too much on one while neglecting the other.

Yes, it’s a lot of work. But, in our eyes, it’s time well spent. We’d rather be extra careful here than frantically fixing the site after launching it.

12. Push the Staging Website to Production

Yes, the day is finally here!

After putting hours and hours into this project, this is your chance to show off your hard work to the public.

But, migrating one website is already risky, let alone multiple websites. That’s why the moment you push the staging website to production, you must stay focused and continue working on other steps in this project.

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

13. Deploy Site-Wide Redirects on all Existing Websites

With the new production website up and running, you need to immediately set up site-wide redirects on all old websites.

Because we already set up 301 redirects (step eight) based on our mapping (step seven), everything will fall into place after we handle the site-wide redirects.

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

14. Double-Check All 301 Redirects

After the site-wide redirects are in place, double-check all 301 redirects.

With the 301 mapping sheet you created in step seven, you can now use the Existing website URL & Redirect to columns to quickly review your setup.

You can put the whole list under the Existing website URL into your crawler of choice.

For Screaming Frog, you can go to Configuration → Crawl Config → Advanced → select Always Follow Redirects, and it’ll show up the final destinations of those URLs (in case of multiple redirects instead of one)

Once the crawl is complete, you can export the full list by going to Reports -> Redirects -> All Redirects.

With your brand-new information, you can do a quick VLOOKUP on your current 301 mapping sheet and put the actual destinations under another column. Then, using a simple IF formula to compare the planned destinations and the actual destinations, you should be able to see if 301 redirects are set up correctly.

If you see everything is correct, congratulations! Let’s move on to the next step.

15. Double-Check robots.txt & XML Sitemaps

In this step, you’ll want to:

• Ensure that the robots.txt file isn’t blocking any crucial parts of the site
• Verify that the XML sitemaps do not contain any redundant URLs

We’ve encountered scenarios where robots.txt blocks the entire website or XML sitemaps only list URLs from the staging website. Neither situation is ideal, especially during the new website’s initial launch.

A simple tool like https://technicalseo.com/tools/robots-txt/ can help verify if your robots.txt is set up correctly.

16. Double-Check Canonical Tags

Canonical tags are really important yet often overlooked.

The canonical tags from the staging site can sometimes be inadvertently transferred during the transition from staging to production. Based on our experience, the potential issues you might face include:

• Canonicalised to the staging website
• Canonicalised to the old production website
• Canonicalised to the HTTP version (if your site uses HTTPS – and if not, why?)
• Canonicalised to incorrect URLs

Here’s an example of a page canonicalised to the wrong URL (client details blurred for confidentiality).

If you can’t check all pages, you should prioritise top-performing pages to ensure they’re ready.

17. Double-Check Meta Tags

With the planning sheet in step four, you can double-check all pages to ensure the meta titles, meta descriptions, and H1 tags match your plans.

If you don’t have access to crawler tools, you should at least prioritise checking the top-performing pages (based on the old sites’ performance)

18. Double-Check Internal Links

Even though you should have already replaced all broken links in step nine, it’s a good idea to recheck them.

We’ve seen incorrect staging versions pushed without the correct links before, so this should be on your to-do list.

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

Since we’re moving to a new domain and multiple websites, you must submit a Change of Address request via Google Search Console.

You should follow the guidelines provided by Google to ensure everything is set up correctly.

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

This message means your site has successfully migrated to its new domain and has been properly established.

Note: According to Google’s guidelines, they don’t recommend combining multiple moves to a single location as this can cause confusion and traffic loss. They claim, “you might want to move sites one at a time to the new, combined location and wait till traffic stabilises before moving the next site.”

Based on our experience, we haven’t seen a traffic loss when merging multiple sites simultaneously. But, if you want to stay on the safe side of things, you can:

• Merge low to medium sites first: they’re low-risk properties with little traffic, meaning the new production website can stabilise much more quickly.
• Then, move to high-traffic sites: usually, one (or, at the maximum, two) websites fall into this category. If there are two, you can merge one with the new production website at a time.

Remember, it doesn’t matter how you approach it (merge one, two, three or all websites simultaneously); you must follow all the above steps to ensure a smooth migration process.

Need Help Migrating Multiple Sites Onto One Domain? We Can Help. 

Do you still need clarification on the migration process? Don’t worry, you’re not alone.  

Even the simplest migration is complicated, let alone merging multiple websites into one domain. Faults and issues lurk around every corner, but with this article as a guide, we hope you encounter 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 know what we’re doing on projects big and small. 

We’ve seen it all. Get in touch to see how we can help.