Fellow State of Digital blogger Briony Gunson recently wrote a great post that detailed the content and SEO side of site migrations, which is when a client redesigns their website and/or changes CMS systems, and you have to consider and plan for the various challenges around such a major change.
Briony mentioned that “many digital marketers will encounter at least one site migration at some point in their careers.” I love the challenge of a good site migration (without sounding too sad!) and I’ve worked on quite a few during my career, with two in just the last few months (and a third in the works, due to launch in a few weeks’ time). I’m sure that many SEOs would’ve seen a spike of interest in 2015 in particular, following Mobilegeddon back in April – a couple of clients of mine used it as an excuse not only to mobile optimise their ageing websites, but to redo them altogether.
If you’re new to site migrations then I recommend reading Briony’s post and the resource links included within it. However if you’re a seasoned veteran of this type of work – or perhaps you have one looming with a client and you want to make sure that you’ve covered all bases – then this post is especially for you. Because as much as you can plan for a site migration, and as much as some universal truths apply to virtually all migrations (e.g. making sure that you implement redirects, etc.), each one that I’ve worked on has been unique and has even thrown up a surprise or two. Here are five surprises that crept up on me – make sure they don’t get you, too…
1) Remembering to carry across old redirects from the previous site
Arguably the most essential part of a successful site migration is remembering to 301 redirect any and all URLs that are changing, whether it’s because the CMS system is changing, you’ve decided to restructure the site architecture, or URLs were SEO-unfriendly and now’s your chance to improve them. I always tell clients to keep redirects to a minimum where possible, although I recently worked on a site with 250+ URLs and every URL (bar the homepage) was changing, so the circumstances may vary.
For one client’s website, with only a dozen pages or so, it was relatively easy – especially as only a few URLs were changing. I confidently implemented the redirects and that was that… so I was surprised when their Google Search Console account suddenly started to report multiple 404 errors post-launch. When I investigated them, I gave my head a slap – I’d overlooked carrying across the redirects that were already on place on the previous version of the website!
When creating a ‘redirect map’ (i.e. a spreadsheet of all the old URLs and where they’ll point to on the new version of the site), it can be easy only to consider what’s currently live on the website – but you must remember to consider what was already in place as well.
Solution: If you were responsible for all the old redirects on the old website (and therefore know what’s in place previously), be sure to include them in the redirect map in addition to all the live pages. If you’re unsure what’s been put in place before, check the website’s .htaccess file… If you don’t have access to that for whatever reason, then tools like Screaming Frog should help you to find some (if not all) of them, while some CMS systems use redirect plugins, so you might be able to find them all that way. For any that you miss, you can always refer to Google Search Console to find the rest – but the more that you’re able to detect and remedy pre-launch, the better.
2) Unexpected sub-domain changes (e.g. dropping the www.)
For a recent site migration, I had the surprise of my life when the website launched and I immediately realised that the web designer had decided to drop the www. part of the domain in the process. I had made the mistake of assuming that the website – previously on www.example.com – would remain on www.example.com, and the web designer made the mistake of assuming that making this change (dropping the www. and moving forward on http://example.com on the new site) would be completely harmless and make no difference whatsoever.
This was for a website where all the URLs (bar the homepage) were changing, so fortunately the SEO consequence of this change didn’t differ too much for the vast majority of the website – I immediately changed the redirects so that they pointed straight to the non-www. version, rather than going to the www. version and then redirecting again to the non-www. (which would’ve resulted in a redirect chain for every URL). Unfortunately the homepage had no choice but to 301 redirect from www.example.com to example.com, resulting in a slight loss of SEO value in the process (see Moz’s Redirection guide for more info on this). Alternatively, I could’ve asked the web designer simply to make sure that he added the www. back in, but we made the judgement call to proceed with the non-www. version (his change) going forward.
Solution: This was just one of those classic cases where I assumed that the domain path wouldn’t change, when in fact it did. As ridiculous as it sounds, it’s worth the quick question (“are we sticking with www. or moving to non-www.?”) simply to avoid the hassle of this come launch time. If it happens to you, you have a quick decision to make: either sticking with what you had before, or making the necessary tweaks to adapt to the change in sub-domain. This should be decided on a case-by-case basis.
3) Allowing enough time to schedule in content creation for new pages
Many clients use a site migration as a good excuse to have an overall content overhaul on the website – a content ‘spring cleaning,’ if you will. It’s a good opportunity to review the old site’s content and to decide what needs to be kept, what needs to be shelved/archived and what needs to be introduced as new pages – and for those that are being kept, whether or not their content needs to be updated.
This can result in a lot of content that needs sorting out and producing – all in addition to having to worry about getting to grips with a new website/CMS and the other SEO considerations related to it. Unfortunately for one recent site migration client of mine, they simply underestimated the scale and volume of content required, delegating it too late and to too few people. As a result, the need to produce new content for some of the pages actually held up the launch of the new site, resulting in a bit of a rush-job before the launch, and – so as not to hold things up further – they launched the site with brief, incomplete pages, somewhat dampening the excitement and impact around the announcement that the new site had gone live.
Solution: This is just an issue of educating the client… Make sure that they consider conducting a content audit really early on (in the above example I suggested this, but it still became a later consideration despite my constant nagging)! If the client doesn’t think that they’ll realistically be able to produce all the new content themselves internally in time then they may have to consider outsourcing to external copywriters – so it’s important that they realise that this might be an option and therefore to budget accordingly.
4) In-post links and images still containing the test site URLs
I imagine that this one might be pretty common – but for me, it was the first (and only) time that I’ve come across it.
Let’s say that the client’s test site was test.example.com, and they planned to move it to www.example.com (taking over the old website) once it was ready to launch. Shortly after the launch, the client’s web designer took test.example.com offline, and I noticed two things: missing images site-wide, as well as a load of internal 404s site-wide…
I discovered that although the site menu/nav had carried across, the image and in-copy links (i.e. links within the text of a page/post) were still bearing the old test.example.com URL. Fortunately it was only a small site (less than 10 pages) and so it wasn’t too big a job to quickly edit each page, finding all the old test.example.com URLs and changing them to www.example.com URLs, restoring the images and internal links in the process. I used Screaming Frog helped to detect them all, which was handy.
Solution: When this became a potential issue a second time, on a site that had hundreds of pages (and therefore I didn’t want to go through every single page manually changing image/in-copy URLs!), I told the web designer and he said: “no problem, we can run a script site-wide that can change every test.example.com URL to www.example.com.” I nearly hugged the guy. So try to avoid it altogether if you can, but if it becomes a problem for you post-launch, ask if your web designer can do the same for you, which will save everyone a ton of time and hassle.
5) Contingency planning: working to a worst case scenario with deadlines
Even with the best of intentions and the best of planning, websites rarely go live on their originally intended launch date. The only one that I can think of that bucked the trend in recent memory was when the web designer launched the site at 11:50pm-ish on 20th April 2015 (the intended launch date), ready for the launch of Mobilegeddon the following day, as he wanted to launch it before Mobilegeddon struck. And even then, it was tight…!
So as much as they may not like the sound of it, ask clients to keep a launch date in mind, but to work to a worst case scenario and also to plan for any contingencies that may arise. It’s one of those things where you don’t think about it until something happens to you (by which point it’s too late), but given a recent experience that I encountered, I’ll now be thinking about for any site migration project going forward…
One client had a date in mind as they had three bits of news that they wanted to announce one week apart following the launch of the new site, and they wanted to do so on the new version of the site, not the old one. Unfortunately the site launch became delayed and they had two choices: announce the news on the old site instead in the meantime, or delay the news – neither of which was welcomed by them, although they realised and admitted that perhaps they’d been a bit too ambitious working to such a set-in-stone deadline.
For the same client, things got more serious when – a few days before the rescheduled launch date – the web designer became hospitalised for a few days. As you can expect, virtually everything was put on hold until he’d recovered (other than a few bits and bobs that the rest of us could get on with in the meantime), delaying the launch yet again by a few days.
Solution: As mentioned above, the only solution here is to make sure that your client understands that bad things can happen (however unlikely and/or extreme) and perhaps not to plan too much news to coincide with a website launch, just in case it becomes delayed. If one part becomes delayed, you don’t want it to have a knock-on effect on other things as well. So be sure to have plans and strategies to account for any unexpected emergencies (and hey – wrapping your web designer in layers of bubble wrap in the days preceding the launch probably wouldn’t be a bad idea, either)… 😉
What site migration issues and challenges have you faced in the past, and what did you do to overcome them? Do you have any as weird as (or perhaps weirder than) some of mine listed above? I’d love to hear them, so please let me know in the comments below or over Twitter.