How To Merge and Migrate Multiple Websites to One Existing Domain

Merging and migrating multiple websites into one existing domain is a meticulous task that requires careful planning and attention to detail.

Whether you aim to consolidate resources, improve user experience, or boost SEO performance, this process involves numerous steps to ensure a seamless transition.

Our comprehensive guide will walk you through each phase, providing clear and precise instructions to help you preserve your search rankings and maintain consistent traffic.

By following our step-by-step approach, you can minimise disruptions, avoid common pitfalls, and achieve a successful merger and migration.

Let’s get started on unifying your web presence under one domain.

1. Set Up the Staging Environment

Like any other website migration project, this step is essential because it gives us the ability to work on the website while all other websites remain online.

Even though the production website is ‘technically’ already live in this scenario, it’s still a good practice to carry out pre-migration work on a staging site to ensure everything is working as intended.

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

Because we’re going to merge multiple websites into one, having a complete list of all URLs on all existing websites (including the production website in its current state) is the key to ensuring that:

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

To do so, 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

If you want to be extra thorough, you can also add the top-ranking keyword and its ranking position for each of the URLs, this may help you in deciding which website content will be live on the final destination website. 

Like any other website migration, you’ll need the Clicks and Sessions data to determine which page to prioritise 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 clients can review the sheet and leave comments on specific pages, helping us save time during the planning phase by reducing back-and-forth communication.

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

3. Determine the URL Structure on the New Production Website

Determining the URL structure is the first complex decision you must make.

Usually, to avoid major traffic loss after the launch, you’ll choose the biggest website (or the best-performing website) as the final production site and merge the remaining sites with it.

Although in some company mergers you may not have this luxury, in which case you will still follow the steps as described here, but may have to migrate more content than if you were to merge inferior sites into an authority. 

Because not all websites are created equal (they can cover different topics, have different landing pages, target different audiences, etc.), you should take the time to decide on the new URL structure here.

Depending on the complexity of the migration and the number of websites to merge, you’ll either fall into one of the two following scenarios:

1. You can (and should) keep the URL structure as is if the final production website already has a clean URL structure. It should fit the newly-migrated pages (from other websites)

2. You should come up with a new URL structure when the final production website doesn’t have a clean URL structure that fits the newly migrated pages (from other websites)

I know, I know. Lower your pitchforks, and let me explain.

It might sound a bit too obvious, but the complexity doesn’t come from the criteria; it comes from the question: What is considered a ‘clean URL structure that fits the newly migrated pages’?

Let’s say ‘websiteB.com’ & ‘websiteC.com’ are what we want to merge with ‘websiteA.com’. Below are their current URL structure:

For websiteB.com:

• Landing page: websiteB.com/what-we-offer/service-name 
• Blog: websiteB.com/articles/blog-title

For websiteC.com

• Landing page: websiteC.com/available-services/service-name
• Blog: websiteC.com/guide/blog-title

Now, let’s talk about websiteA.com. This is where we’ll need to make our decision.

Scenario 1:

If websiteA.com has the following URL structure:

• Landing page: websiteA.com/services/service-name
• Blog: websiteA.com/blogs/blog-title 

As you can see, websiteA’s structure allows us to migrate all important pages from websiteB and websiteC to websiteA without changing anything on website A. This is because the structure fits nicely with websiteB and website C.

In cases like this, you should keep the URL structure on websiteA as is, and it’ll make your life easier.

Scenario 2:

If websiteA.com has the following URL structure:

• Landing page: websiteA.com/industries/service-name
• Blog: websiteA.com/blog-title

This time, the landing page URL structure on websiteA no longer fits with what websiteB & websiteC currently have, so simply moving them over might not work.

Also, even though you can easily migrate the blogs on websiteB & websiteC to websiteA, the blog URL structure on websiteA isn’t necessarily ideal (for better management and analysis in the future). That said, you should consider changing the blog URL structure too on website A during the migration project.

In cases like this, you should take your time to decide whether to change the URL structure and, if so, what the new URL structure will look like.

As an agency, we usually review all websites thoroughly and then advise our clients on the pros and cons of changing the URL structure based on their data and circumstances. Finally, after everything is decided, we’ll develop a detailed step-by-step plan for what needs to be done (similar to what you’re reading here).

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

Once you’ve finalised the URL structure on the new production website using the information from the previous step, it’s time to manually review all the pages you gathered in step two.

AI could be used here to group all pages by topical relevance. But, if you want to do it right, we’re afraid there’s no shortcut here and manually grouping them in your spreadsheet is the best approach.

By reviewing everything manually, you’ll have a clearer vision of the new site’s structure 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 by events (eg. goal completions such as form submits)

Mapping them carefully and correctly and 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 usually be either admin pages, which are generally easier to handle, or low-traffic pages that are less 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 production 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

A streamlined communication channel is essential here. As an agency, we’ll have a dedicated column called “Client Notes” where our clients can leave comments where applicable. This is a huge time-saver for all parties involved because it helps everyone move the project forward without waiting for verbal confirmation.

If you’re working with your internal team, meetings are a great way to ensure everyone is on the same page and discuss all possible solutions.

Once you’ve reached your decision, 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 destination website.

Since you’re already working on the sheet with the available crawl data, this is when your mind is at its sharpest. It’s a good opportunity to save time by completing the necessary planning to benefit the future of the campaign.

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

Once the mapping sheet is ready, you should have a list of all the new pages for the website. Now, it’s time to create a dedicated spreadsheet for the staging site containing all the pages that need to be created.

Why is this necessary?

You don’t want to send the entire mapping sheet to the development team, as it can lead to miscommunication and wasted time.

Instead, create a clean sheet of all the pages that must be created on the destination site. This will allow the development team to see what needs to be done easily, and you can double-check their work later.

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
• Page to pull the content from on the origin website

Following our second tip in step four, 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 from steps two and three, you can plan the meta titles, H1s, meta descriptions, and URLs of the pages on the new websites.

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

6. 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 where your new spreadsheet from step four works its magic.

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. It can save you a lot 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.

7. 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 merge multiple pages into one, you can either use the content from the page with the most traffic or combine content from other pages into the main page,
• If it’s an admin page (about us, contact us, privacy policy, etc.), you must update the content to reflect the changes.

This approach ensures that ranking pages with valuable content are correctly 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. 

8. Create a 301 Redirects Sheet

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

Using the mapping sheet you created in step four, 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 they go live. Also, if you have a straightforward sheet like this, it’s easier to have someone else set the redirects up.

Tip 1: 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 fourteen), 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 fifteen.

Tip 2: If you keep the URL structure on the production website as is, then it’s highly likely that you’ll only need to map out 301 redirects for a handful of URLs (that were either merged or deleted). However, if you change the URL structure altogether, make sure 301 redirects of all important pages of the current production site are on this sheet.

9. 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.

10. Update Internal Links on the Staging Environment

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

With 301 redirects correctly set up, visitors’ experience will stay the same.

However, for crawlers, having broken URLs (3xx, 4xx, or even 5xx) can slow load times, potentially causing crawling issues. It 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). It allows you to identify and replace broken links effectively.

11. 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 essential to make them easier for crawlers to access. It ensures that search engines can efficiently find and index your most important pages.

Tip: If you don’t keep the URL structure on your production website as is, remember to double-check robots.txt to make sure nothing is blocked unintentionally. Also, the XML sitemaps need to be updated as well (if your SEO apps/plugins don’t do that automatically)

12. 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 it launches.

13. 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. 

14. Deploy Site-Wide Redirects on All Existing Websites (Other Than the Production Site)

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

Because we already set up 301 redirects (step nine) based on our mapping (step eight), everything will fall into place after we handle the site-wide redirects (including the redirects on the production site if you change the URL structure)

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

15. 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 eight, 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 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 crawl data, you can do a quick VLOOKUP on your current 301 mapping sheet and put the actual destinations under another column.

Then, with the same template as shown below, using a simple IF formula =IF(‘Data in Redirect to column’=’Data in Actual redirect to column’,”Yes”,”No”) is enough to check your 301 redirect setup.

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

16. 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.

17. Double-Check Canonical Tags

Canonical tags are essential yet often overlooked.

The canonical tags from the staging site can sometimes be inadvertently transferred 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.

18. Double-Check Meta Tags

With the planning sheet in step five, 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).

19. Double-Check Internal Links

Even though you should have already replaced all broken links in step ten, 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.

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

Since we’re moving multiple websites to an existing website, you must submit a Change of Address request via Google Search Console for each of the origin domains.

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: Google’s guidelines 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-performance websites 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, the final production website is already the highest-traffic site so this is when you migrate the 2nd highest-traffic site.

In the rare case where you don’t keep the highest-traffic site, there’ll usually be one (or, at the maximum, two) websites that 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 (migrate one, two, three or all sites 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. 

Are you still trying to figure out the migration process? Don’t worry, you’re not alone.

Even the most straightforward migration projects can be complex, and merging multiple websites into one existing and running site can be incredibly challenging. Issues can arise at every turn, but with this guide, we aim to help you achieve a smooth and stress-free transition.

If you want to alleviate the headache and minimise service disruption, the SwishDM team is here to help. We’re experts in site migration and have extensive experience with projects of all sizes.
We’ve seen it all through years of experience. Get in touch to see how we can help simplify your site migration today.