As SEO professionals, we are no strangers to migrations and the various levels of volatility they can bring.
Migrations are naturally occurring events in the life cycle of digital businesses as both technology and business objectives advance.
Migrations can come in different forms, but the more common ones we encounter include:
The level of risk and variables change dramatically between the different migration types, as well as variables and nuances in the client’s tech stack, meaning it’s almost impossible to provide an “off-the-shelf” scope.
In the industry, we hear about migrations going wrong namely when they start to impact the world outside of SEO.
Losing some traffic and a few rankings isn’t headline news, but businesses closing down stores and laying off staff is.
Examples of this include the Homebase HTTPS migration (as covered in-depth by Omi Sido here), and the more recent Logojoy to Looka rebrand, which when looking through the eyes of third-party tools show a decrease in ranking keywords of 25,000 (150k to 125k).
Scoping an SEO Migration
For me, getting the scoping of a migration correct is essential to the success of the migration process as a whole, and avoid situations like this:
A key part of the scoping and specifications is that it needs to be actionable for both developers and wider stakeholders:
- Reducing the “why.”
- And focusing more on the “how.”
Ambiguity creates risk. The less room for misinterpretation, the better.
Within the scoping document, it’s essential to establish:
- The reasons for the migration taking place (from the client).
- Primary and secondary stakeholders.
- The scope of activities and responsibilities from each stakeholder (maintaining traffic and rankings is not a responsibility, it’s an objective).
- The timeline for activities, plus post-migration resources.
- Agreed (by all parties) objectives of the migration.
- Reporting frequency and depth.
From this, you can begin to create a schedule of activities to reduce as much risk as possible.
For the most part, risk mitigation during any migration is carrying out what is for many, general migration activities.
Each activity, however, is designed to reduce elements of risk and work toward achieving the agreed-upon objectives.
It’s a given that redirects are part of almost all migrations.
However, having performed a number of post-migration traffic drop audits, here are some common errors made when scoping and implementing redirects.
JS, CSS, Parameters & Media Files Not Redirected
More often than not, when migration is carried out people focus on redirecting the URLs, as those are what rank, but you should also be looking at redirecting your JS files, CSS, Parameter URLs, and media files (images, videos) if necessary.
A lot of people question the value in redirecting images, but a URL is a URL and Google will have crawled it. Google has even recommended that you should redirect image URLs.
When migrating to a new platform, redesigning templates, or updating the site structure it’s important to ensure that the new “environment” mirrors the SEO qualities of the previous at a minimum.
- Metadata has been carried over correctly.
- Structured data has been implemented and is validated.
- Canonicals are correct.
- Pagination mark-up is correct (Bing exists, too!).
- Internal linking has been carried over and points 200 URLs.
- XML and HTML sitemaps are present.
- Hreflang is set up correctly (if you’re an international website).
- Redirects have been tested.
- Your 404 page returns a 404 response code.
Some things like site speed will require live site testing unless the staging and pre-production environments are on mirrored stacks (so you can emulate the same performance), but more often than not they’re not on performance-orientated servers.
Understanding Why Migrations Go Wrong
Oftentimes when a migration goes wrong, it can be pinpointed to at least one of seven reasons, these being:
- Incorrect SEO strategy/unclear objectives.
- Poor planning and scoping of resources and timeline.
- Unforeseen UX/design changes that impact content or code.
- Involving the SEO agency too late/after key decisions have already been set in stone.
- Poor or lack of sufficient testing.
- Slow responses and low development priority to post-migration bug fixes.
- Uncontrollable variables (e.g., Google update).
Understanding why the migration is taking place and the desired outcomes is critical in order to set measurable benchmarks for “success.”
For most migrations the objective is to main SEO performance, to then use said stability as a foundation for growth.
However, each migration type has its own set of risks. These need to be communicated to the client and wider stakeholders.
If you’re moving hosting or platform but maintaining URL structures, it should be seamless, but if you’re rebranding and changing the domain name, expect some period of turbulence.
Poor Planning & Scoping
Devising a detailed scope and project plan early on can help avoid delays along the way by setting expectations of how long SEO processes and tasks take.
This also allows you to factor in what is, and isn’t, within the scope of the project so you can schedule and allocate resources adequately.
By setting out a plan, you can also identify potential obstacles, such as public holidays or peak sales periods.
For example, as an online retailer, you wouldn’t launch a website in the days running up to Thanksgiving as major bugs could jeopardize your Black Friday/Cyber Week/Christmas period.
SEO migrations don’t happen overnight.
However, SEO support is oftentimes sought too late down the roadmap with many critical decisions made beforehand that will impact organic search performance.
Sometimes the late involvement can be a saving grace, as long as there is room in the timeline for changes to be made, but that is seldom the case and you can only watch and prepare for the post mortem.
This also means there is a lack of sufficient testing (from an SEO perspective)
Slow Development Response Times
This is more often than not an issue with the business themselves, and not something SEO professionals can control.
I’ve been in situations before where immediately after the migration development resource has been fully rededicated to another part of the business, leaving no time for urgent or ad hoc bug fixes.
More often than not, this isn’t the developer’s fault but more a symptom of poor planning from decision making stakeholders.
I’ve seen websites go live before with a sitewide noindex (as the wrong bucket had been deployed), something we flagged almost immediately – only for it to take 4 days for the resource to be allocated to remove it.
Every now and again, despite the best planning and resource allocation, you’ll get sideswiped by something unforeseen and completely unavoidable – such as a Google update or the CDN/DNS suffering outage.
Screenshot taken by author, November 2019