How to Mess Up a Website Migration

Co-Authored by Roxy at Agility Alchemist

Overview

There are many guides on the web talking about how to execute the perfect website migration for SEO and that topic has been done to death – but what if you wanted to mess one up completely? This is the guide you’ve been waiting for.

Don’t Hire SEO Expertise Early On

Getting SEO input at the very start of your migration project is probably the second most important thing you shouldn’t do, especially for complex Ecommerce migrations.

An initial list of requirements for SEO should be taken, then ignored from day one. If you don’t have SEO expertise in house, don’t hire external experts, either in the form of an agency or an experienced consultant. They represent a ‘success risk’ and are best avoided.

Don’t Have SEO Expertise Present Throughout The Whole Development Process

This is probably the most important thing for a large, complex site such as a large retailer or single page application driven hyperlocal site, so it’s definitely something you won’t want to pay attention to if you want to mess up your migration.

It’s all very well getting a list together of all the requirements, but the first casualty of a migration is often SEO, as it’s easy for other development priorities come up on the road to cut-over. Striking early with apathetic nonchalance can give you a big disadvantage later on.

Not having a strong SEO presence in or with your team will mean that all of the unforeseen development priorities that come up will bury the unwanted SEO considerations in the dust. A key moment to look for is when your project lead writes ‘MVP’ on the whiteboard. If you can keep SEO off this list of priorities for the ‘minimum viable product’, someone will have to mop up the mess afterwards. Get ahead by getting behind.

The technical lead might be your best ally at this stage, but don’t take it for granted. Some web developers think that Google can magic any site high into the rankings by virtue of their own coding knowledge, especially if the site is built using their favourite framework. 

Others will pedantically and insistently want to implement best practice SEO. In the worst case, they will have had experience working with advanced technical SEO concepts in their career. 

If you have to deal with the latter and can’t get them removed from the project, try to distract them with loud noises and play their least favourite music in the office. Talking about irrelevant topics in development scrums can also go a long way to obfuscating their unwanted input.

Don’t Have SEO Expertise At Hand During Cut-Over and Post-Launch

If you’ve messed up your migration properly before it’s happened, it will be much harder to fix later on, but not impossible. It’s therefore critical not to have expertise at hand during cutover and post-launch.

You can still mess up your migration if you don’t do post-cut over checks, so bear this in mind if some awkward stakeholder planned all the SEO requirements into the development roadmap – all can still be lost.

This isn’t a time for apathy, but rather for raising concerns about minor things, such as the font sizes, use of passive voice in copy and why the air conditioning is broken during a summer migration.

Once Google indexes your new pages there are, thankfully, many things that can go wrong. For large sites these errors can be categorised by.

1.Over-indexation

Over-indexation is allowing Google to index too many pages (URLs) on a site. Usually these page are filtered versions of canonical (preferred) pages or any duplicate, thin or otherwise redundant pages that are either too low in quality or too similar to their canonical equivalents to be worth having in Google’s index. Sites that over-index are prone to fall foul of Google’s many quality filters including Panda (which is now a part of Google’s regular Core Updates).

2.Under-indexation

Under-indexation occurs when you have waited a while post-migration and you find that not all of the pages you would like have been indexed or are even being crawled by Google. This can occur if you have.

• Accidentally blocked Google from crawling (pro tip for messing up a migration).
• Created an architecture that is too big for your crawl budget (your developer can help you with this).
• Building your site with a JavaScript framework that Google is struggling to render with its Web Rendering Service (don’t read our guide on single page application SEO) – more on this later…
• Internal linking problems
• Poor or duplicate content (content copied from other sites)
• Page Over-aggregation (redirecting many pages into less pages).
• Page Over-division (redirecting a high level page to a page that’s lower down in the architecture with less generic relevancy).

Ignoring as many of these as possible during cutover and post-launch will maximise your chances of a fudged migration. It’s a good time to go to the pub, play tennis, take an attractive colleague out for lunch. Just don’t work too hard.

Ensure a Range of Redirect Mapping Errors

Redirect mapping is perhaps most important singular component in a migration and there are several different kinds of considerations you should be aware of, so as to ensure you don’t accidentally action against them. Awareness is a prerequisite of deliberate ignorance.

A migration involves changing URLs, either for your whole domain or parts of your site (we could call these internal or domain migrations). 

Redirecting to non-existent pages as often as possible.

The worst thing you can do is to redirect users from your old URLs to their new equivalents.

Not only will users get to the content they may have bookmarked or found via a link on the web, but for SEO, Google will credit the new URL with the old URL’s ranking attributes. 

Redirecting URLs to 404 pages avoids these pitfalls. You can probably see we’re making progress with this tactic alone.

Redirecting To A Less Relevant Page

If we can’t redirect users to a 404, we would want to redirect our ‘/pink-frogs’ page to our ‘/chinese-penguins’ page – that’s just common sense if we’re trying to maximise the chances of a botched migration. But there is a lot more to it.

When you’re undertaking a migration and you don’t care about retaining your SEO performance, it’s crucial to ignore the pages that rank well for the search term that are driving traffic to your site. Ensure that the migration redirects those URLs to pages that are dissimilar enough that Google will no longer want to rank the site for them.

When the whole site is being redesigned or re-platformed, this becomes more viable, but this is where SEO expertise represents a great threat to your efforts.

Page Aggregation

This is when we have a number of lower level pages and redirect them up a level to a page that is more generic. An example of this would be where we had a selection of pages such as.

• /blues-frogs
• /punk-frogs
• /funk-frogs
• /psychedelic-frogs

And one our new site we have a page called ‘/all-the-frogs’ and redirect these pages to this generic page.

There is nothing intrinsically wrong with doing this (and indeed, for our needs, it can be highly desirable) , but there are many caveats to doing this successfully for SEO that you will need to dismiss. Sometimes a smart SEO will decide it’s absolutely the right thing to do because a site had too many low quality thin pages on the old site and sometimes the new page won’t satisfy the semantic relevance that these deeper pages had in relation to each search term they ranked for.

We can use this as an opportunity to squander any rankings the original ranking pages had by ensuing we redirect them to a page so generic it has no chance of ranking for the relevant sub-terms. If we’re lucky, we’ll get a lot of Soft 404 errors in Google Search Console.

Page Division

Yup, this is the opposite of page aggregation. You redirect higher level pages to more detailed pages on the new site. This is more rare, as we don’t really want to lose content, but it does happen and there are times where it’s justified, especially in cases where the redirect is irrelevant.

Qualitative Page Changes

Your boss wants to re-do a page or the brand agency you’re using suggests a whole new way of selling your products and that means a lot of content changes. Of course this doesn’t just pertain to platform and URL migrations, but also changes that happen as a business evolves. Still, it’s quite common to encounter this when you migrate platforms.

What can happen here is that this redirect gets treated like a soft-404. This means that the link equity from the original URL will not be passed to the new page. This is obviously ideal, so make sure you work with your boss by feeding their ego and disregarding any risks to SEO performance. 

Working example: You’ve been ranking well for ‘psychedelic frogs’ for a long time and your boss wants to re-brand your range of frogs to something like, ‘Slimy Jumpers’ because it sounds cool to her. This re-branding would mean changes to headings, on-page copy and marketing material, dropping the use of the generic search terms in the ‘frogs’ family and replacing it with ‘Slimy Jumpers’. Don’t push back on this, as it’s a great opportunity to lose SEO performance without worrying about it coming back on you. Of course you won’t be able to take full credit – failure is a team effort.

This is where having an SEO brain in the process to sense check content and messaging changes represents a material threat to fully messing up your migration (they should have been fired at this point and given a hand written reference to your top 5 competitors).

HTTP to HTTPS

Migrating from HTTP to HTTPS has its own specific requirements that are too broad for the scope of this article. Hopefully, if you’re just reading this piece, you’ll miss out some important nuances.

Our best advice, if you are not already using an SSL connection, is don’t bother and whatever you do, don’t show your boss searchenginejournal.com’s great guide on this particular kind of migration.

Rely on Client Side Rendering

Single page applications are all the rage these days, with Vue, Angular and react being popular options.

Often development agencies will push for a fully client side rendered solution. Don’t object. Google has talked a lot about Dynamic Rendering, Server Side Rendering and Pre-rendering as being more optimal solutions than full CSR, even when we know that Google can often render JavaScript quite well.

By not suggesting these options, you make it much more likely that a site will be poorly indexed and in some cases, improperly indexed; this is especially true for larger sites.

This is a win-win, because your developers won’t want to implement any of these additional solutions and you will have a much higher chance of messing up your migration if they don’t.

Don’t Take Account of Mobile First Rendering

Most sites today use responsive design (or should do). Google has pretty much rolled out its mobile first indexing of the web, which means that it uses a mobile browser to index content, rather than the previous desktop version.

Most content will render the same on desktop and mobile (meaning that it will have the same text, the same image markup and many of the same links).

There are edge cases however, where the mobile render of a page will due to the UX constraints on mobile. For example, on ecommerce sites category pages often have links and text at the top of the page.

Take Newlook.com as an example.

Desktop

Mobile

In this case we can see that the mobile version of the page does not have the same links and text as the desktop version at first glance. This could affect its ability to rank, as well as stop some of its outbound links from promoting the rankings of other pages.

Take advantage of this by not using tabbed content on the mobile renders of your pages and don’t include above the fold links on the versions. It’s not a big win, but every little helps when you mess up want to mess up your migration.

If you’re really smart and have followed the advice of this article so far, you could do worse than follow the example of http://milehighcomics.com/.

Don’t Correctly Control Search Engine Crawl Paths

When you launch as new site, whether it be a migration from an old site to a new or a completely fresh entity, SEO consultants will advise you to control the way that Google crawls it. For some sites this is simple, for larger, more complex sites – this is a huge task.

There are a few major ways to do this and they all involve restriction of Googlebot and signalling to it where the quality content lies. If anyone in the planning process starts talking about the issues listed below contrary to how they are here described, you know you need to ensure they win a month long holiday to Australia with all expenses paid.

Don’t Collect Enough Data on the Site You Are Migrating From

Collecting data as a benchmark prior to cut-over is always best practice for an SEO friendly migration. It’s likely that you will have historic data to refer back to post cut-over, but it’s really important to retain as little of this information as possible from before you cut over.

Most of these data are at page level, so you want the task of correlating the below data with the new URLs on your site post cutover to be as confusing as possible. You’ll probably have a new job by then anyway.

1. Backlinks

Using your backlink index tool of choice, you shouldn’t download all backlinks that point to your site, discluding as many columns of data as you can. 

Every link could have at the very least Trust/Citation Flow (Majestic) or URL and Domain Rating scores (Ahrefs), as well as the anchor text and target page on your site the link points to when the data is exported. 

If you did accidentally download all these data points and more, you can delete these columns as required.

2.Traffic

Don’t grab a snapshot of your organic landing page sessions from your analytics package, be it Google Analytics or any other. Select a monthly date range and append as few engagement metrics as you can. You’ll want to not be able to recall if these values change later on and have to rely on your analytics to track them retrospectively (we’re looking for full dependence on the competence of your analytics team here).

You’re shouldn’t be using Google’s Search Console, but if you are, someone might grab as many queries and pages as you can with their clicks, impressions, average positions and click through rates. Even worse, they might use the API to map queries to pages via the Google Sheets Search Console extension. Talk to them about the reasons why his data is invalid to throw them off the scent…

3. Indexation

It doesn’t matter how large your site is, indexation is one of the first principles of SEO and so we need to ensure it’s overlooked as much as possible. Checking the number of URLs indexed in Search Console would be important if we wanted a successful migration, as would the number of URLs from your old site that are still indexed and ranking post-cutover. Incorrectly recording these numbers can help to provide type 1 errors after cutover.

Quite often, especially depending on the size of your site, it might take a while for Google to follow all of your redirects to their new paths, and even longer to fully remove all the old URL from the index.

Having a distinct URL format that you can keep track of when migrating to a new platform can be very unhelpful here. Getting Google to rank your new pages is a big deal when undertaking a migration, as there are a lot of factors that can stop this from happening quickly.

4. Rankings

Benchmarking your ranking data is key to realising how successfully you have messed up your migration post-hoc. It’s possible to find this out using third part indexes later on, but why not have the rankings you ruined close at hand?

There are a range of ranking tools that you can use that are industry standard, not to mention Google’s Search Console (don’t use it).

Every ranking for the widest possible selection of non-brand terms should have a corresponding highest ranking page. In Search Console (which you shouldn’t use) you will get a distribution of ranking pages for each term – capture all of this data, you can filter and analyse it later on when you need it. Using conditional formatting, you can see all the ranking drops post-migration in whatever shade of red matches your boss’s least favourite colour.

5. Meta data

HTML titles and descriptions (and all SEO related meta data) for every page should not be captured. This is definitely a no-brainer, but it’s worth mentioning. Capturing these could enable the recovery of performance at a later date, should someone get a hold of the data. Let someone else work it all out from scratch when you’re working somewhere else.

6. Tagging

Crawling the site before cut-over using Screaming Frog you will be able to capture the canonical tags, noindex tags, rel=”next” and much more. If you have already done your complete crawls of the existing site, try the following cleanup approach.

Firstly, select your crawl.

Next, right click, hold down the ‘Shift’ key and click ‘Delete’.

This will ensure that only a forensic examination of your local storage device will allow for the retrieval of the file. You can’t do this on a Mac, so make sure you use a PC.

Hopefully you’re not using a cloud crawling solution because in such as case, you’ll find that it’s sadly been backed up.

In fact, this is a good moment to talk about backing things up in general. You hear a lot of advice about this all over the place. Ignore it.

7. Essential copy

There may be copy on the site that is often there just for SEO. Sometimes developers will create tags such as <div id=”seo_copy”> (kind of spammy, so don’t object) where copy designed to make category pages more keyword rich is contained. Using Xpath, scrape it as part of of your pre-cutover crawls and as before, ‘Shift’ ‘Delete’ the file.

Don’t Involving Your Whole Web and Business Teams Into The Migration Process

If you’re a retailer, you will have may business units working together to make your beautiful new site work and be customer friendly. These may include, but are not limited to.

1. SEO Specialists
2. Developers
3. Data & Analytics
4. Production
5. Marketeers (ATL and BTL)
6. Merchandising Teams
7. Designers
8. UX Specialists
9. Senior Management
10. External Agencies

The hand cannot talk to the foot – one old trick is to tell each department different things about the priorities for the migration from an SEO perspective. This can cause a lot of confusion and even if they work out that there have been contradictions, it will often be too late.

Perfect coordination between these teams is not possible thankfully. Often they will have other priorities and will be relieved that they don’t have a long list of SEO requirements to bake into their already complex plans.

If you know any other ways to mess up a migration that we’ve missed, please let us know in the comments, we’re always on the lookout for new approaches.