It is widely accepted within the SEO industry that you cannot relaunch a website without some degree of traffic loss.
In fact, when polled, 80% of SEOs made it clear that they felt traffic loss was unavoidable.
Good morning SEO Twitter. When you are managing a website migration, do you automatically assume there will be some traffic loss? Why / why not?
— Natalie Slater (@njmott) March 15, 2022
A quick Google search returns over 20,000,000 results for “traffic loss after a site migration”, with the top 10 results comprising guides and blog posts exploring the different reasons for traffic loss and strategies for recovering it.
However, few provide a methodology for launching without experiencing traffic loss. None that we could find looked to explain how a site migration might actually be used to improve traffic.
In this post, we reveal our method for how to relaunch a website to maximise its chances of gaining traffic.
What is a site migration?
The most common reason for a website migration is to keep up with design trends. But in recent years, it has become far more common to see sites relaunched when technological improvements are need to be made to keep the site SEO friendly.
Other common reasons include:
- Revamping site structure
- Making changes following user testing or conversion rate optimisation
- Transitioning to a new framework or content management system (CMS)
- Incorporating new usability features
- Switching from HTTP to HTTPS
- Changing servers
- Changing domain name
Why do sites lose traffic after a migration?
Traffic loss after a site migration is normally due to URL changes, where new redirects dilute link equity that previously sustained rankings. This, combined with poorly managed crawl budgets, DNS caching issues and often an overall increase in number of pages, add layers of complications.
How can traffic loss be avoided?
Site migrations can be conducted in such a way that, not only is the risk of traffic loss mitigated, the changes pave the way for maximised growth following a relaunch.
Our consultants have worked with hundreds of sites over the last decade to perform optimised site migrations, and we have condensed their work into this handy checklist.
It has been broken down into pre-launch, day of launch and post-launch steps, and it is designed to mitigate risk, work around common pitfalls and provide a workflow for businesses looking to position their migrations as opportunities for growth – not an inevitable period of traffic loss.
Skittle Digital’s site migration checklist
Pre-launch
- Plan launch schedule
- Block search engines from staging site
- Agree on freeze dates
- Crawl current site
- Extract historic URLs
- Conduct a content audit
- Concentrate the new site structure
- Break redirect chains
- Set up new redirect map
- Create XML sitemaps
- Crawl staging site
- Add Analytics code
- Back up all data
Launch day
- Pause paid ads
- Reduce TTL time
- Monitor rollout in real-time
- Remove blocks e.g. robots.txt, meta robots
- Crawl old URLs, compare with redirect map
- Check analytics tracking, forms & transactions
- Submit new sitemap(s) and crawl request
Post-launch monitoring
Pre-launch
Plan launch schedule
Carefully planning your timeline for your migration projects will be essential.
With a migration, timing is everything. If you’re responsible for the SEO element of the project, you’ll need plenty of time in advance of launch-day to collate all your data, make the right recommendations, and check the implementation in staging.
It is also important to make sure that you’re not repeating the same workflows again and again whilst the staging site evolves. Meet all the stakeholders and make sure that you have the time you need built into the project. Make friends with Design & Development and check they also have the time they need to implement your suggested changes. Most importantly, always have a roll-back plan in place just in case things don’t go well on launch day
Block search engines from staging site
The accidental leaking of a staging site into search engine indexes may not only negatively affect your current live site, but could also be the reason why your new site launch starts going wrong. Issues such as duplicate content, erroneous links between live & staging, and more, can all spell disaster for your site migration.
Blocking access via robots.txt or using IP whitelisting to carefully control access to your staging site is vital. Adding the noindex tag to your meta robots on a page-by-page basis can also be a good tactic, but is less robust. The most important thing to note is that no matter which approach you take at this stage, you must not launch with it still in place – make sure blocks are lifted just prior to launch.
Agree on freeze dates
Some live sites change incredibly quickly. This means that any crawl data you’re basing your recommendations on can quickly become outdated.
To make sure you aren’t constantly having to redo your work, stakeholders need to agree on a freeze date whereby no new content or major changes are made to the live site – at least not without you knowing about them. These freeze dates should be added to your project timeline.
There also needs to be freeze dates agreed for the staging site, with your SEO workflows fitting around them, else you risk repeating your work every time something changes.
Crawl current site
The size and complexity of the site, along with personal preference, will largely determine which crawler(s) you will use to crawl your current site. You need to make sure you capture a complete picture of the existing site so that you can properly carry out the next few tasks. This crawl must also be conducted after the agreed live site freeze date.
Pull in Search Console & Analytics data, as well as any link data you can (via API) for every URL as you crawl. This will get a lot of the data you’ll need all in one place.
Capture all historic URLs
This is done using a backlink report and filtering it by target URL – you can then crawl all these and quickly identify any old versions of URLs. Some might have amassed some link equity, whilst others haven’t, many might not ever have been redirected. Add all these to your redirect map to reclaim lost link juice and give your new site a boost once it launches.
Conduct a content audit
Now is the ideal time to audit, organise and curate your content. Use the data from your fresh crawl to address anything that might currently be holding your site existing site back, and make sure these aren’t carried over to the new (staging) site.
Content to retire
Anything non-essential that generates no traffic and adds nothing of value to the end user doesn’t need to be included in the new site. Add these URLs to your redirect map and choose other pages to benefit from any innate SEO value.
In the same way, thin content – identified most easily in your crawl data by low word count – is often another offender.
If certain thin content pages can’t be retired, identify other pages which house content that can be lifted and merged with the page. Alternatively, simply make a note to add more page copy later on.
Content to move
You might have a new sitemap provided to you by other stakeholders, or you might have the chance to help influence the site’s restructuring. Either way, you’ll have the chance here to move content to new URLs, adding the old ones to your redirect map and aiming for short, logical, URL structures that reflect your various content hierarchies.
Content to merge
Content that has been indexed by Google for the same or similar terms are highly likely to be damaging each other’s rankings – we call this keyword cannibalisation. Look for duplicate or similar page titles as an indicator in your crawl data, or use Search Console to review priority keywords and check which pages are indexed against those.
Plan to merge similar pages into the single strongest URL from each set for the new site. Make a note that “merged” URLs already out there in Google’s index will need to be added to your redirect map.
Streamline the new site structure
This is the culmination of our previous steps so far. Our aim is to take the innate and residual value of many URLs and focus that value in a structure that is far more concentrated, squashing the link juice you’ve amassed into as small a structure as possible.
This means that any link juice lost through new redirects is more than made up for. Review your URL hierarchies and make sure everything makes sense from a semantic / data classification perspective.
Keep URLs short and descriptive. If you’re building folder structures greater than 4 or 5 levels deep, or building URLs over 115 characters, then Google won’t be able to use the words included within them as a ranking factor.
Break down redirect chains
With your fresh crawl, historic URLs and a good sense of how the new site is going to be structured, you’ll be able to spot the redirects which have been chained together.
Chained redirects massively reduce the spread of link equity; they also put added strain on your crawl budgets. Taking each step in the chain in isolation, and ensuring it points to the final destination – bypassing the other steps in between – in your new redirect map puts you in good stead with the new site.
Set up your new redirect map
You’ll need to set up your redirect map to incorporate all your findings from above. Don’t forget to break down those redirect chains and add new redirects for live URLs, based on the final site structure.
To test your map, you can conduct list crawls of current URLs on the staging site by replacing the top level domain (TLD) to match staging site.
Just remember not to carry this version of the redirect map over on launch day.
Create XML sitemap(s)
XML sitemaps show Search Engines the layout of our new site, aiding in URL discovery and reducing the search engine’s reliance on site structure and internal linking for crawling.
Generate sitemaps in XML format. One of the easiest ways is to use an intermediate staging site crawl as a basis, just find and replace the TLD so your URLs don’t include the staging site.
Remember to set crawl priorities, lastmod and changefreq within your sitemaps to help search engines decide where to allocate crawl budget when you launch.
You will also need to monitor indexation of groups of similar pages so as to easily spot errors preventing proper indexation during migrations.
You can do this by creating multiple sitemaps that you submit in Search Console, each dealing with a specific section of your site. This will allow for individual reports in Search Console that show the pages in each sitemap which have and have not been indexed.
Crawl staging site
Conduct a final crawl of the staging site so you know what to expect when the site launches. Compare the crawl results to your XML sitemap(s) to make sure everything that should be crawled and indexed is appearing.
Add analytics code
Place your analytics & tracking codes on the site ahead of launch to ensure no loss of data when you launch. You can implement this using tag manager for an easy transition between your current and new sites at the time of launch.
Back up all data
Create and securely store a backup of the existing site. This should include database, content, assets etc and an agreed roll back plan with other stakeholders just in case something unforeseen happens.
Then, do the same with the staging site too, otherwise weeks, or even months of hard work could be lost in one go.
Launch day
Pause paid ads
Before anything is transitioned on launch day, pause any paid ads from PPC or social advertising campaigns.
You’ll need to update target URLs across your ads, and adjust any display URLs. In addition, you’ll need to make sure that ad copy and collateral reflects any changes to branding or brand identity.
Only unpause your ads once the new site is up and running to ensure you’re not sending visitors to dead pages, or into conversion funnels that don’t yet work or aren’t trackable.
Un-pause once everything else has been checked thoroughly, and all stakeholders are happy.
Reduce Time To Live (TTL)
If you’re changing domain names or hosting, then change your DNS Time To Live (TTL) to help search engines take note of the move and update the index much faster. Put it back later once the change is reflected in the index.
Monitor rollout in real time
Make sure the other stakeholders know you will be available on launch day. Ensure you are present during the rollout so that you can offer any additional ad hoc support as well as run tests to verify the process has gone smoothly.
Remove blocks e.g. robots.txt, meta robots
Check the live site’s robots.txt and meta robots and make sure the site is accessible from public IP addresses. Use a VPN to test from various locations, and from different devices. Use mobile-data to check too.
Crawl all URLs, compare with redirect map
Crawl the new live site and cross-reference the data with your final crawl from the pre-launch checks. Any discrepancies (missing pages etc) should be dealt with swiftly.
At this point, you should also list-crawl to check all your historic URLs (from the previous version of the site AND all those you discovered in your link report earlier). Check they are all redirecting to where you are expecting, using the right redirect status code (normally 301).
Take note of any unexpected SEO issues; for instance, we commonly see canonical errors or internal links that still contain references to staging site URLs.
Check analytics tracking, forms and transactions
Test your analytics tracking in real time, and debug any tracking issues.
Search Console
It is quite common for SEO’s to lose Search Console verification during a site launch. The verification methods for Search Console include on-page tags, a file upload and a record added to the DNS, any of which could change during a migration.
Once launched, make sure you’ve still got Search Console verified. Re-verifying can cause unnecessary work at a time when all hands are occupied with other tasks relating to the migration.
Inside Search Console, submit your new sitemap(s) – but don’t delete the old ones yet. You can monitor the transitions in the index between sitemaps to see how quickly your new URLs are picked up and the old ones are dropped.
Before you leave Search Console, ensure you submit a crawl/indexation request on your site’s homepage to prompt a visit from Google.
Roll back if necessary
Sometimes, things won’t go to plan. With so many moving parts, site migrations are full of potential pitfalls.
If things haven’t gone well, and can’t be fixed on the fly, then reference your roll back plan and action accordingly. Review what went wrong and set a new date to try again.
Post launch monitoring
In the days, weeks and months following launch, carefully monitor progress using all the tools at your disposal. Impressions, clicks, rankings, traffic, conversions and core web vitals will all give you an indication of the new site’s performance.
Search Console
- Check performance report and ensure that priority keywords/pages are ranking as expected.
- Use the sitemaps reports to check indexation by page type.
- Check your crawl rates for an indication of how many pages Google is able to crawl at a time.
Ensure you’re reviewing log files regularly as these will reveal issues that Search Console and Analytics are not always able to pick up on.
Log files
Your log files will help you uncover crawl issues that might not be reported in Search Console or Analytics. Log files will show you which pages are being requested by search engines, and demonstrate where crawl budget is being assigned.
Need help with a site migration?
Feel like you’re not getting anywhere with your site migration? Get in touch to see how we can help.
Alternatively, why not give your whole digital marketing strategy a much-needed boost with one of our Free Acquisitions Workshops? Book in today for a free 30-minute chat with one our marketing experts where you will gain invaluable insights into all aspects of your strategy, as well as advice and tools to make sure your approach stays fresh going forward.
