How to perform the perfect SEO friendly website migration

This one's best for you if: You are redesigning a website, moving to a new CMS or transitioning to a new JavaScript framework.

SEO risks to watch out for: Rebuilding a website should be an exciting prospect, but a technical mistake or the use of a fancy new JavaScript framework that doesn't play ball with SEO can easily put all your organic traffic at serious risk.

Steps to follow to minimise these risks: Creating a well-formed strategy is the key to success. For your website to be a success for both your users and SEO, you need to cover all bases and give every stakeholder the chance to get their voice heard. For example, your technical SEO team will need to work closely alongside your development team to ensure that your new CMS and any JavaScript frameworks are SEO friendly, and your content marketing team will need to work closely with the technical SEO and UX teams to ensure that content can be easily be found by users and search engines.

This one's best for you if: You are changing from a local TLD (such as .co.uk) to a global TLD (such as .com) so that you can target international audiences. Or you are moving to a domain name that better suits your business – for example, when Moz moved from Seomoz.com to Moz.com back in 2013.

SEO risks to watch out for: A change of domain with no other site changes is one of the most straightforward types of migration. But without the correct redirects, and without notifying your customers or search engines of the change, your organic visibility and conversions can easily be hit.

Steps to follow to minimise these risks: To minimise risk it is vital to make sure you have a strategy in place for managing your redirects (so that they point to the correct locations and use the correct HTTP Status code), managing your customers' awareness (with the use of emails and blogs to let them know), and managing how Google interprets the changes (by updating your Google Search Console and Google My Business configurations).

This one's best for you if: You have just acquired a business and need to merge its website into yours, or you have multiple websites (and potentially legacy sites) that need to be consolidated into one website for easier maintenance and management.

SEO risks to watch out for: Combining multiple websites is one of the most complicated types of migration, and can take months or in some cases years to complete. It can involve working with multiple stakeholders and teams from all over the world. And on top of that, it comes with the most risks – just one small mistake or missed requirement, can damage traffic, conversions and the brand experience of the entire business.

Steps to follow to minimise these risks: Due to its complexity and risks, a fully-formed strategy is a fundamental requirement. This will involve multiple workshops and sessions with multiple teams to cover all aspects of the new site, from fundamental SEO and UX needs through to curating content and rebranding the business.

This one's best for you if: You don't have a secure (HTTPS) website. With browser vendors constantly pushing for a more secure web, and with your customer's data being so valuable, we have always championed the provision of secure websites, and recommend to all our clients that they move to HTTPS as soon as possible.

SEO risks to watch out for: Rushed HTTPS migrations can see your organic positions dramatically fall, by creating redirect issues like redirect loops and by making your website entirely inaccessible due to misconfigured certificates – all while still allowing bad actors the potential to steal or modify your customer's data.

Steps to follow to minimise these risks: Moving to HTTPS is never as simple as just adding an S into every URL. It will involve researching the preferred Certificate Authority (CA) for your business, any additional necessary security measures (such as HSTS) and the correct use of sitewide HTTP to HTTPS redirects.

It's possible that your needs are more unique than the examples above. Perhaps you are merging multiple websites, moving to HTTPS and changing the domain name all at once. This can quickly make a complex project even moreso, but with the right planning and strategy, this can be just as manageable as any other form of migration.

Now we've looked at the types of website migration and their inherent SEO risks, how do you create a strategy to ensure you can avoid them and the whole project goes smoothly? This section takes you through defining your objectives and planning the execution, before listing common challenges and solutions.

Before beginning to plan out a strategy, it is important to understand your objectives and the challenges your migration or new website needs to solve. These challenges, and their solutions, need to be clearly outlined at the beginning so that everyone involved knows the purpose and objectives. Doing this will not only ensure everyone is on the same page, it will make it easier to define which data to benchmark such as page speed and organic search positions.

Here are some reasons we commonly come across for migrating a website:

• An archaic CMS that doesn't meet a growing business' needs
• Rebranding
• Merging of multiple businesses or sites
• Creating a mobile-friendly site
• Securing a website
• Increasing website speed
• Fresh new look and feel

Define your migration

Work out which type of migration you need to perform and make sure everyone involved knows the details. For example, if you are merging multiple websites, ensure that everyone involved knows which websites will be moving into which, which content will be moved where and which content will be removed.

Get stakeholder buy-in and involvement

It is critical to ensure that stakeholders from every team are engaged from the beginning. This needs to, at the minimum, include marketing, SEO, CRO, paid search, design and UX, and development.

Without including stakeholders from key teams, it will be very easy for a key requirement of theirs to get missed in the scoping of the migration, resulting in one or more teams being limited by the new site, or the risk of scope creep where the project to-do list keeps growing after you've started.

Define the tech stack early

It is critical to research and document the new tech stack as early as possible, for example:

• What CMS will be used, and will it be SEO friendly?
• What JavaScript frameworks will be used, and will they be SEO friendly?
• Will a CDN be used, and does it have a good track record?
• Who will host the site, and does the provider have a good track record?

Identify any expected issues

Predictable issues that can be accounted for your strategy may include:

• Can all the content be migrated at the same time?
• Can all the meta content be migrated?
• Can all pages and images be 301 (Moved Permanently) redirected?
• Will the internal links break?
• Will the new tech stack be slow?
• Will new content be easy to add?
• Will the site allow for the business' growth ambitions?
• Will there be a roll-back strategy in place in case things go critical?

Identify any opportunities

Are there additional things you can look to improve with your new website, such as:

• Can the content be improved upon?
• Are there content gaps that can be filled?
• Can the navigation be improved?
• Can the page speed be improved?
• Can the user journey be improved?

Once you have outlined your objectives, the next step is building a clear strategy. Overlooking the importance of this, or not having the right people involved, could spell disaster for your new website. Develop a detailed project plan with details of who is responsible for each task and what needs to happen at each stage, and get your pre-launch preparation in place.

Create a task list

Ask everyone to write down their requirements on separate cards. Shuffle them up, and go through each one together, discussing their importance, impact and blockers. Each card should then be placed on a board in one of two categories – 'must-have' and 'nice to have'. This task list will create the basis for the migration, and once completed, should be moved across to a digital environment such as Trello, Jira, or Basecamp. In doing this, you'll have the opportunity to create an even stronger website, by moving key cards across from 'nice to have' to 'must-have'.

Set up benchmarks

Base these on your current performance, conversions and traffic, using tools like your analytics software, Google Search Console and Fresh Egg's proprietary tool Digital Edge.

For organic visibility, a good set of benchmarks include:

• Page speed: This can be monitored synthetically with tools such as GTMetrix and Google PageSpeed Insights, and can be monitored agains real user data with a mix of tools such as Google Analytics, New Relic, CrUX, and mPulse.
• Clicks and impressions within Google: These are monitored within Google Search Console and can be a great way to benchmark the visibility for key pages and sections, of your website.
• Organic positions within Google: Monitoring organic positions for specific keywords, and keyword groups, is an important and quick way to identify if organic visibility is being affected by the migration, rebuild or redesign. The most accurate way of doing this is with Google Search Console - taking data directly from the search giant. Rank tracking tools, such as STAT and Advanced Web Ranking, can be also be a great way to keep track of what the SERPs and your search results look like and how your competitors are ranking in comparison to your new website.

It is important to note that in the weeks following your migration or the launch of your new website there are likely to be fluctuations in your organic visibility. Any red flags in your benchmarks should be investigated immediately but bear in mind that they could just be a symptom of Google getting to grips with the migration.

Scope out your site structure and navigation

It is important to determine your site structure and navigation as soon as possible as it will impact both user journeys and organic visibility. The easiest way to get started with this is to review your current site and identify any existing issues with the Information Architecture (IA). Once you have identified issues with the current site, you can address them with the new site.

• Is the current main navigation weak? A good way to identify this is with tree testing, it will identify issues with the current navigation, and allow you to fix these with the new navigation

Tree testing is a great way to evaluate a website's current navigation or a proposed solution. Participants are set the task of finding information, allowing us to identify the different ways people interact with the IA. It tests a menu structure in its most basic form allowing us to test a navigational structure away from design distractions. This means we can ensure that the menu structure, and labelling, matches user expectations.

Luke Hay, conversion services director

• Are there organically important pages that are not well linked to? If a page is important for SEO, it needs to be well linked to, and accessible with as few clicks as possible from the homepage. A simple way to check this is to create a crawl visualisation with a tool such as Screaming Frog SEO Spider – it will allow you to visualise the click paths of the site so you can easily identify any pages that are worryingly deep.
• Is your internal anchor text well optimised? It is important to ensure that pages that are of organic importance are linked to with appropriate anchor text. For example, if you are linking to a page about black t-shirts, your anchor text should be 'black t-shirts', and not something like 'click here'. The best way to review this is by taking crawl data and pivoting it in Excel, allowing you to quickly analyse internal anchor text – this pivot will be even more useful if you include Google Search Console clicks in it as well.

Common challenges:

• Your e-commerce faceted navigation is not SEO-friendly: For large e-commerce sites we often see that the faceted navigation is causing organic challenges, be it allowing search engines to crawl thousands of duplicate pages or not allowing them to crawl any of it. To identify any issues with the new site's faceted navigation, you will need to work closely with your SEO team to ensure that they are on the development team's radar.
• Internal links are nofollowed: Using the nofollow attribute on internal links will stop search engines being able to follow the links around a site, stopping them from understanding the site structure and the relationship between different pages and content, and in turn hindering organic visibility. It is important to ensure that only in rare and specific cases should any internal link use the nofollow attribute.

Use SEO friendly JavaScript

JavaScript has become a fundamental part of how the web works, but at the same time it has always been a concern for SEOs as search engines have traditionally struggled with crawling and indexing JavaScript. In recent years this has changed with Google getting much better at crawling JavaScript, but Google openly admits it still isn't perfect. And with Google not being the only search engine around, and with social networks like Facebook and Twitter using non-JS content for scraping their snippets, it is still important to carefully review your use of JavaScript.

Using JavaScript for basic interactions: When using JavaScript for basic interactions (such as pop-ups and dropdowns), it is important to ensure that the content of these widgets is still accessible within the source code. This ensures that if a search engine does struggle to crawl any JavaScript, they will still be able to find the links and any content they point to.

Building the entire site with JavaScript: If your entire site is being built in JavaScript as a Single Page Application (SPA), then it is critical to ensure that search engines are given a static (non-JavaScript) version of the site to crawl, as per Google's recommendation. This is known as Server-Side Rendering (SSR) and is a critical component of building an SPA as it means search engines can still correctly crawl and index your site. Pushing an SPA live without SSR in place can spell disaster for your SEO, resulting in broken pages and fragments of pages appearing in the search results, and your search traffic taking a nosedive.

Here are some common JavaScript SPA frameworks that support SSR and links to their SSR best practices:

• Vue.js (https://vuejs.org/v2/guide/ssr.html)
• React (https://reactjs.org/docs/react-dom-server.html)
• Angular Universal (https://angular.io/guide/universal)

To minimise the risks JavaScript can pose to your organic visibility, it is critical to get your technical SEO team and your development team working closely together from as early as possible, working together to choose the right frameworks and ensuring that any JavaScript is SEO friendly.

Common challenges include:

• The use of the AJAX crawling scheme: The AJAX crawling scheme was a proposed solution by Google to allow it to crawl SPAs, however, it is since been deprecated by the search giant – do not use the AJAX crawling scheme.
• Using a framework that doesn't support SSR: If the site has been built as a full SPA, and SSR hasn't been considered until too late in the build, it can easily push out the scope and deadlines of the build. It is important to get your technical SEO team involved in any framework decisions as early as possible.
• Pagination is only accessible with JavaScript: It is common for blogs to use JavaScript for implementing infinite scroll and 'load more' buttons in favour of classic pagination. And while it can be argued that this provides a stronger user-experience, if classic pagination isn't provided underneath the JavaScript, it will block search engines from being able to crawl older blog posts. To solve this, classic pagination needs to rendered server-side, and at which point it can then be hidden and replaced with client-side JavaScript such as infinite scroll or a 'load more' button. This can be seen in action on the Fresh Egg blog.

Review your content

Migrating your content from your old site(s) to your new site is critical for ensuring that your site continues to maintain its visibility. And, if your current taxonomy is quite weak, this could be the perfect opportunity to improve how your content is categorised throughout the site, improving user journeys and in turn improving organic visibility.

If you're regularly adding content to your site, its taxonomy can quickly become convoluted, with near-duplicate folders and semantically linked content being added to completely different areas of the site. A migration is a great opportunity to pause, look at your audience and user research, and define a structure that better suits them.

Callum Grantham, senior content and social media manager

Prepare a roll-back strategy

During the process, unexpected challenges and blockers will pop up. And while it is unpleasant to think about, it is important to consider putting a plan in place to roll back if needed. This way, the teams know exactly where the event horizon is and will be able to make quick decisions if critical issues arise.

Prepare your analytics

When changing URLs, even it's just moving from HTTP to HTTPS, it is critical to ensure your analytics suites and tools are ready for the changes so that your tracking works and the data is reliable. For example, if your URL structure is changing and you are using URL Content Grouping within Google Analytics, these rules will need to be updated.

A good way to work out what needs changing is to run through all your tools, from Monetate to Adobe Analytics, making a list of all the ones that will need tweaking once the website has gone live.

Data quality is often overlooked when coming up to a site migration but if you don't have trustworthy data it's not possible to demonstrate the impact of the project. The sooner you fix any tracking issues you have, the more likely it is you'll be able to do valid analysis of performance before and after migration.

Graham Marsh, senior web analyst

There are a handful of commonly seen challenges when it comes to site migrations and rebuilds, but luckily if you know how to solve these issues the process should be plain sailing. Here are a few examples of issues you might face, together with the steps you should take:

We can't migrate all our content at once – how should we handle this?

If your website has a lot of content that needs to be migrated, and there are blockers in doing it all at once, it is important to plan for this ahead of time:

• How do we retain our SEO for content that can't yet be migrated? If your legacy content cannot yet all be migrated, there are two scenarios that can pop-up. Either, your content continues to exist on the old site until it is ready to be migrated: in this case these URLs should not yet be redirected, and the pages left live on the old site until they are migrated across, and at which point they can be 301 (Moved Permanently) redirected. Or, your content is going to be offline until it is migrated: in this case 302 (Found) redirects should be used and pointed to the most relevant pages until the content is migrated, at which point these redirects should be updated to the correct locations and the redirect types switched to 301s.

We have lots of legacy sites that we need to clean-up – what should we do?

If your business has a lot of legacy sites or old subdomains that need cleaning up, these are the key requirements to be on top of:

• How do we identify what needs cleaning-up? It is important to identify what each of these legacy websites and subdomains are, and to crawl them all to get a list of every URL on each site. To find old legacy subdomains and sites, a good place to start is within Google itself. For example, if your website is hosted on a www. subdomain, a quick way to find any indexed subdomains is to use the following query in Google: "site:yourdomain.com -www."
• Do we need to map each page? Just having a list of URLs isn't enough. Each URL needs to be mapped against a relevant location on the current site. For example, any old contact pages need to be redirected to the new contact pages. And while this is often a manual and painstaking task, there are tools out there to help speed up the process – we have even built our own propriety tool for this.
• Do we need to redirect every URL? It is important to note that not every legacy URL needs to be redirected. If it has traffic going into it, or has backlinks pointing towards it, it needs to be redirected. However, if a page no longer exists on the new site, has no traffic, and no backlinks, it may make more sense to just let it become a 404 (Not Found) or even a 410 (Gone).

We've merged with another company and need to merge all our content together – what do we do?

If your business is merging with another and you need to merge everything into one single site, here is what you need to consider:

• What content needs merging? You'll need to review the content across both websites, ensuring that any content that is useful for a user is moved across to the new site, and that any content that will no longer be useful to a user is removed.
• Can content be improved? For example, if you are merging blog posts together because they are useful for users, you need to ask yourself if it would be better to expand some of these into evergreen pieces of content.
• What will the new site structure be? It is important to work out exactly where all this merged content will sit on the new site. To do this a card sorting exercise may be needed to work out where each piece of content would sit best placed.
• How will users know that the websites have been merged? A few good ways to handle this are by emailing users about the changes beforehand and putting a message on the old websites (before they are redirected) and the new website explaining that the businesses have merged.

"Card sorting at an early stage in your project helps you to design or evaluate the information architecture of a website. Participants who are representative of your users are asked to sort cards containing your main website topics into categories and to label them."

Stephen Carpenter, head of development and design

We are rebranding – what should we do?

If your business is rebranding and moving to a new domain name, ask yourselves the following:

• How will users know the business is rebranding? A few good ways to handle this are by emailing users about the change beforehand, putting a message on the old website (before it is redirected) and explaining on the new website that the business has rebranded.
• How will users find the new website? To make sure users end up on your new website, the old URLs need to be redirected to their new locations. As part of this it is key to ensure that the redirects are 301 (Moved Permanently). This will ensure Google updates the old URLs in its search results to the URLs of the new site.
• How will Google be alerted of the change? It is important to let Google know that your business has rebranded – the best ways to do this are to set up a new Google Search Console account and update your Google My Business listing.

How to execute your website migration

From your building and testing to your ongoing monitoring and benchmarking, this section sets out our SEO best practises to ensure your execution goes smoothly and that your organic traffic stays safe.

1. Building and testing
2. Pushing the migration live
3. Identifying and fixing issues
4. Checking your benchmarks

When you come to rebuilding your website, it is critical to ensure that your build is fully tested before being pushed live. Failing to do proper testing can result in some serious firefighting on launch and can quickly result in your organic traffic and conversions taking a hit.

Here's a checklist of the most important tasks and requirements to include in your building and testing:

Block search engines from indexing staging

It is easy to forget to block search engines from accessing and indexing your website while it's being rebuilt. This can pose a problem from a search perspective as users may begin accessing the staging site from the search results, resulting in them accessing a site that is incomplete and broken. There are some simple steps that can be put in place to stop search engines from indexing the site:

• Block the staging site from being accessed by IP addresses that haven't been whitelisted: This is our recommended approach as it stops both search engines and users from being able to access the site.
• Block all crawlers within the staging site's robots.txt file: This option is inferior to blocking by IP as robots.txt blocks can be ignored by search engines.
• Add a noindex or nofollow meta robots tag into the <head> of every page: This option is also inferior to blocking by IP as noindex and nofollow tags can be ignored by search engines.

Common challenge:

• The noindex tag or robots.txt block gets pulled across to live: You'd be surprised to learn how often this happens, and if not immediately fixed, it can result in organic traffic dropping fast. This is one of the reasons for only recommending noindex tags and robots.txt blocks as a back-up option when IP blocking isn't viable.

Prepare Google Search Console

Google Search Console is a critical part of migrating a site. It tells Google about the migration, encourages Google to crawl the new website and flags errors so that they can be fixed as soon as possible. And while you won't use it until the new site has gone live, it is important to make sure that your development team are able to quickly add the required mark-up to the website when it's live to allow the suite to be verified. This can be in several different ways, from updating the DNS records to adding a meta tag to the site's homepage.

It is important to also prepare Bing Webmaster Tools – it generally highlights more crawl errors and therefore becomes very useful for identifying issues post-migration.

Common challenge:

• Google Search Console verification is missed from the scope: It is easy to forget about preparing for Google Search Console in the planning phase. However, it is important to ensure the developent team know what they are going to need to do once the site goes live as verifying and configuring this tool is critical to ensuring that the website is correctly indexed.

Prepare and test your redirects

It is critical to ensure that you redirect all your legacy URLs to their new locations. To do this you will need to:

• Create a list of all legacy URLs: This should come from a mix of crawl, analytic, and backlink data.
• Create a list of new URLs: This is created with a crawl of the staging site.
• Map the list of legacy URLs against the new URLs: For small sites this can be done manually, however with large sites this will involve a mix of algorithmic and manual mapping.
• Prepare the redirect: Ensure that every URL that needs redirecting across uses a HTTP 301 (Moved Permanently) server-side redirect.
• Test the redirects: Ensure that that redirects are tested to ensure that they all 301, and that they all point to their correct locations.

Common challenges:

• The wrong redirects are used: When adding a redirect to a server, it will generally default to a using a 302 (Found) redirect. But this will not result in Google updating its search results. To address this it is important to ensure your developers know to instead use a HTTP 301 (Moved Permanently) redirect.
• Not all content can be migrated at once: If you have a lot of content that needs to be migrated after the new website has gone live, the use of HTTP 302 redirects can become very useful. In temporarily redirecting those pages that will temporarily not exist to, say, the blog's homepage, search engines will keep the old URLs in its index (for a time), meaning traffic and positions will remain stable. And then, once a piece of migrated content has gone live, the specific redirect needs to be updated to point to the content's new location, and the type of redirect needs to be updated from a 302 to a 301.

Update your XML sitemaps

Following a migration, search engines will use the XML sitemap to quickly identify all the new pages. Therefore, it is important to ensure that the XML sitemap is as clean and accurate as possible. To be clean, all URLs should give a 200 (OK) response code, and any optional tags (such as <lastmod> and <priority> are correct.

Common challenges:

• The URLs in the XML sitemap are erroring: All URLs in an XML sitemap should give a HTTP 200 (OK) response, however, it is common to see them also include a mix of redirects and 4xx and 5xx errors. As search engines will be using this file to crawl and index the new site, these errors will slow down the indexing and could even encourage the wrong URLs to be indexed. Therefore, it is important to crawl the new XML sitemap with a tool such as Screaming Frog SEO Spider to identify any URL errors.
• The optional tags are wrong: If custom optional tags are being used such as <lastmod> and <priority>, it is important to ensure that they are correctly configured. This is because search engines will be using this data to work out what it should and shouldn't crawl, and could result in the migration taking longer to index. If these errors cannot be fixed, it is simply best to remove the tags, and just stick with the basic <url> tag.

Migrate meta content

It is critical to ensure that, for any pages that are migrated, the meta content will also be pulled across to the new site. This includes both page titles and meta descriptions. If this is missed it can spell disaster for your SEO, with traffic dropping off dramatically. To ensure meta content gets migrated across, it is important that it is on your development team's radar.

On top of migrating meta content, you may also end up creating several new pages. It is important to also ensure that these are updated to include optimised page titles and meta descriptions.

Check for errors

As a migration forces search engines to re-evaluate your while website, it is important to ensure site errors are kept to a minimum. To find these errors the staging site needs to be fully crawled, and the following types of errors need to be addressed:

• 4xx: These are errors that appear when internal links point to content that doesn't exist. Either the content is missing and needs to be added, or the link needs to be updated or the link needs to be removed.
• 5xx: These are errors that appear when the server doesn't know how to handle the request. These need to be flagged with your development team and addressed.
• Canonical errors: Canonical tags are used for handling duplicate content, but misconfiguration of these tags can cause serious issues. In essence, when using canonical tags, ensure that they follow these guidelines from Google.
• Pagination errors: Pagination is often used on blogs to ensure users can access its older content. However, misconfigurations can cause search engines to crawl hundreds or even thousands of broken pages, while older content can easily become orphaned from the site. Therefore, it is important to ensure that any pagination is correctly configured.
• Hreflang: Hreflang is only needed when managing websites that are in different languages or target different countries. However, hreflang can get very complex, and misconfigurations can cause search engines to surface pages that are the wrong locale, or even language, to users within the search results. Is it critical to ensure that when hreflang is being used, it is perfectly configured.

Common challenges:

• The canonical tags are pointing to the wrong domains: When migrating content across from your legacy site to you new site, it is possible that your old canonical tags may also be pulled across. This results in search engines being pushed to the legacy, now non-existent site. To address this the staging site needs to be crawled, and all canonical tags need to be checked.
• Pagination creates an unlimited amount of pages: Depending on how your pagination has been set up, it is possible to create an unlimited amount of pages due to the pagination never ending. This will create an infinite number of pages for search engines to crawl, and will slow down the indexing of the new site.

Stop Google from indexing your site when it goes down

If the site needs to go down during the migration or redesign process, a holding page needs to be created to inform users about what is happening. This holding page also needs to give a 503 (Service Unavailable) status code to tell any search engines that may try to crawl the website when it is down that the site is under maintenance, essentially saying, "We're busy doing something, please come back later".

When pushing the site live it is important to ensure that if there is any downtime, the site responds with a 503 response. Once the site is then live, it is critical to perform the following checks:

• Check crawlability: Once live, check that the website is not blocked to search engines.
• Check for errors: Crawl the website and check for 4xx and 5xx errors, canonical and hreflang issues, and crawler traps with tools such as Screaming Frog SEO Spider, Botify and DeepCrawl.
• Check redirects: Make sure all redirects from the legacy URLs to the new URLs point to their correct locations, and all use 301 (Permanent) redirects.
• Check sitemaps: Crawl the XML sitemaps to ensure that they only include 200 (OK) URLs.
• Check analytics: It is important to check that your analytics tools are correctly tracking on your new site.
• Update your ads: If the landing pages of any PPC or display ads have been changed, these landing page URLs need to be updated.
• Individual team checks: Ensure that everyone involved checks their individual requirements against the migrated website. For example, your UX team might need to check that their A/B testing software is still working as it should.

Once all the above steps have been actioned, and everyone is happy, it is time to ask the search engines to crawl the site. There is almost no turning back once this step has been actioned:

• Update Google Search Console: Set up and verify a property for the new website, add the XML sitemaps, and request a few key pages (such as the homepage) for indexing. And while it likely doesn't bring you a lot of traffic, is it still worth doing this for Bing Webmaster Tools as well.

Once the website has gone live and has started indexing, it is time to thoroughly test the website for any further errors that may pop up. These errors can be identified with a mix of crawl data and errors that will be flagged within both Google Search Console and Bing Webmaster Tools. Common errors include:

• Rogue 500 errors randomly popping up
• Soft 404s being flagged in Google Search Console
• XML sitemap errors
• Canonical errors
• Redirect loops

As the new site is about to come under Google's scrutiny as it crawls and indexes it, addressing these errors as soon as they are found should be a priority in the weeks following a migration or new website launch. A good way to keep track of these errors is to use a task management tool such as Trello, Jira or Basecamp, highlighting issues as they are found and getting the relevant teams to address them as a matter of urgency. To ensure your teams have enough time for these fixes, contingency time needs to be booked in ready for key teams such as SEO, development and Analytics.

It is important to note that this isn't a one-off task, and regular health checks of the site should continue as part of your 'business as usual'.

Following your migration, it is important to carefully review the benchmarks you set in the planning phase. Again, you should also remember to book in contingency time ready for the deployment of any urgently needed fixes.

To keep on top of monitoring your benchmarks, it is important to follow these steps:

1. Check your analytics and data frequently
2. Jump on any signs that something looks wrong, such as a drop in organic traffic to a certain section of the site or a decline in paid conversions
3. Investigate these concerns immediately
4. Address any issues you discover as soon as possible

The simplest way to monitor your data is with tools that can quickly and automatically highlight any declines on your benchmarks. Google Analytics and Adobe Analytics can be configured to send alerts via email when your organic traffic fluctuates, and with certain tools, such as GA Insights and this webhook hack for AA, you can push these types of alerts into Slack.

Again, checking your benchmarking isn't a one-off task. A migration can take about three months to settle down, so keeping a close eye on the data throughout that period and beyond is a must.

As we've seen, migrations and redesigns are complex. They can involve collaboration between people based on opposite sides of the world, and they can throw up all sorts of curveballs and pitfalls. By building the right strategy and involving the right people from the start, you stand the best chance of managing a project that runs smoothly.

It's a wonderful opportunity to grow your business, keep your customers converting and make your senior stakeholders happy. And once the project has been successfully completed, you can congratulate yourself and your teams, take them out to celebrate and finally relax a little.

We are here to help clients build and execute their website migrations. From the humble HTTPS migration to a complex merging of multiple multilingual sites, we have seen and handled it all.

If you need a hand or some reassuring guidance, check out our website and domain migration services or get in touch to find out what we can do for you.

Keep learning with Fresh Egg

Join our email list like thousands of other marketing professionals to get updates on key industry changes, early access to free resources and exclusive invitations to Fresh Egg events in your inbox.