Like any quickly forgotten New Years resolution, an SEO migration activity can be well-intentioned but regularly ignored as part of a website launch that tends to fall by the wayside as deadlines encroach and technical issues sneak in.
It would be easy to think that we could become a curmudgeon after my years working in digital has seen the worst and the best (but mostly the worst) of what site launches can offer, but rest assured my pain is your reward.
While we can certainly learn a lot from the worst managed site launches, there are a number of basic items we should be aware of to make sure an SEO migration is managed with as little pain as humanly possible.
A set-and-forget mentality with an SEO migration as with anything is great if you want to live a happy, oblivious life in the short term, but if you want to make sure future-you isn’t cleaning up the mess that past-you has made, it’s best to put in some forethought into what the goals of the project actually are.
The best way to do this is to have a thorough process and stick to it. There are a number of different checklists online (if you look at Google Ads keyword planner, most of the search around migration relates to checklists), so in the instance that you’re handling this kind of project without the help of an agency partner, make sure that it covers the basics:
A thorough benchmarking process that takes a snapshot of traffic and rankings from various sources prior to migration. Don’t just stick to a small selection of keywords that you might track month-on-month, there are likely a large number of terms that you’re getting impressions and clicks on that aren’t being tracked by your agency month-on-month.
Google Search Console data is a good place to start as you can see exactly what terms have been generating clicks over the past 16 months. At a bare-minimum, make sure you know which pages are generating the majority of your rankings and traffic and ensure that these are migrated on a 1:1 level.
A crawl of all URLs returning a 200 OK status prior to site launch. This will be used to test the staging site and live site at launch to ensure that the right redirects are used. You can use tools like Screaming Frog to crawl your entire site that can be used for pre and post migration testing.
Check that analytics tags such as Google Analytics or Google Tag Manager have been maintained on the new site. Seems obvious, yes, but this is regularly forgotten.
There’s nothing worse than checking analytics software in the days following a migration to be greeted with zero sessions in the days since launch, so if you don’t want to be inundated with angry emails from your directors, this is a good place to start.
Have a public mapping document that shows exactly where all 200 live URLs are going to be migrated to. Ensure that content is mapped on a one-to-one basis so rankings and traffic are passed on to the new URLs.
Also make sure that meta data such as title tags are migrated on a one-to-one level so that ranking signals are maintained over the launch, particularly on current high-performing pages.
Ensure 301 redirects are in place on staging for testing and approval before they go live. This should be a multi-round process to ensure that redirect hops or incorrect redirects don’t sneak in prior to migration. While there’s evidence to say that Google will treat blanket 302 redirects the same as a 301, don’t risk it and go straight to the permanent redirects.
6. Noindex tags
Ensure that during the site launch that noindex tags are removed when the staging site is pushed live. Get this tattooed to the back of your hand if you need to. Noindex tags get left on during site launches like clockwork and are a quick way to deindex your site on Google.
Is this recoverable? Absolutely, but dependent on how long this takes to identify can take weeks to recover.
Submit the new sitemap to the Google Search Console and make sure it’s referenced in the Robots.txt file. Google does a pretty good job of figuring out that URLs have changed, but making sure these things are done will at least flag that some changes have been made.