5 of the biggest website migration mistakes that happen when SEOs aren’t involved soon enough.

I write soon enough but the reality is that sometimes SEOs aren’t involved until after the migration, maybe when it is clear something has gone wrong, sometimes, in my experience, months later when it becomes clear the fall in traffic isn’t just a blip.

Sometimes the lack of inclusion isn’t due to a lack of SEOs, sometimes there is an agency or an SEO in a digital marketing department. Teams may be so siloed though so that no-one knows who does what or that the others exist.

In other cases web developers and those responsible for delivering the migration on time can even actively avoid getting SEOs involved as they will only point out things that are wrong and want to block the new site launching.

So the answer to each of these 5 points is really to get your SEO(s) involved ASAP and to work in time for them to have their input and for their advice to be actioned before the site launches.

1. Using it as a chance to delete old content (and not knowing which pages are providing SEO value)

One thing that often happens is that people with a passing knowledge or awareness of SEO think that if they check that pages aren’t getting much traffic from organic search then they don’t have SEO value and can probably be deleted. In some cases of course no check is done at all, or the focus is too much on revenue and conversions rather than clicks.

Non-SEOs, and some SEOs too, need to stop thinking of SEO as being only on a page level, and that includes on-page SEO. The topical relevance of one page can improve visibility of other pages, especially those linked together in a topical-cluster, so a page getting few clicks itself can still be helping Google understand what the site is relevant too.

So a page answering ‘How Does the flange on a whotsit work?’ may get no traffic as no one is actively searching for that, but it might help a ‘What is a flange?’ page rank higher and might be the article people reading that didn’t realise they needed until they see the link, therefore boosting enagagement, but if you only measure organic landing page traffic you’ll miss that too.

There is a place for reviewing the value of old content, but then there’s more than just the delete option: refresh, archive, or just leave it alone and let it be unless it is doing any actual harm. This is a job to be done seperately to a migration though if you ask me.

Migrations should be done in such a way it is as easy for search engines to reasess the site and understrand what is what as possible. making changes that could be done later just makes it more likely that visibility will be lost and then makes it harder to work out what is/are the cause or causes.

2. Adding in Single Page Applications or JS that make content or navigation uncrawlable by search engines

This one is technical but often missed by a standard crawl in Screaming Frog or similar. The site may still be crawlable and all pages findable, but that doesn’t mean that the content is crawlable and the links you want to be crawled are crawalable.

JS can cause a few crawling issues, including links that can only be crawled once pages are rendered: which delays new pages being found, and content that isn’t visible in the source, but at least is shown in the Intial DOM, in other words the initial coding of the page before it is interacted with which Google indexes.

Let’s focus on links and content that are not crawlable at all though. This could be a seperate article but let’s go through the basics of what happens and what needs to be checked.

Single Page Applications and Web Apps, are basically interactive web pages that have content that updates depending on how a user interacts with it. The DOM or document object model, the code of the page that the browser is interpreting, updates as the user interacts with it. This can include things like interactive games, forms etc. and can be great for User Experience, and great for developers as these are relatively easy to code.

The problem is that Google and other search engines will index the Initial DOM and not keep on indexing content as it changes, unless:

• Firstly there is a URL to index it to, this can be a parameter URL that updates as a user interacts, and
• Secondly the search engine can replicate all the user actions required to update the content. If this isn’t simply clicking a link then there’s a good chance there will be an issue.

Don’t assume that a SPA will be the main content of the page or be something exciting and dazzling like an interactive quiz. It can be things like navigation, for example one that needs a postcode to see links to local stores (this is probably the most common one to cause issues) It could also be a drop down box or series of boxes and tick options to display links: a common culprit here is language and country selectors.

It can be page content too though, another common issue is where selecting a different language updates the content on the page but the URL stays the same meaning there is no way for search engines to index that content against a specific URL.

Content that has no SEO value doesn’t need to be worried about but if it has SEO value and you want it to be indexed you’ll need to spot it and fix it before the new site is launched: this may involve telling a developer that the menu they thought was so clever and well thought out, isn’t.

3. Making a mess of, or missing, international targeting

Getting international targeting right means search engines know which pages to show to which users in each location or based on their chosen browser language. Getting it wrong means search engines guessing, often getting it wrong leading to bemused users landing on pages in the wrong language, currency etc.

Often websites have hreflang that is missing or just badly implemented because they are on an old platform or perhaps they never planned for the site to cover multiple markets and languages and they didn’t future proof.

A website that doesn’t have hreflang mapping baked in to the CMS means a lot of extra work and complication: and for a site that is constantly changing with new and deleted pages, keeping Hreflang really up to date may be nearly impossible.

So a migration is an opportunity to fix these issues. Make sure there is a proper solution for creating hreflang clusters of pages without a lot of work where changes to tags or sitemaps will be automated.

At the very least a migration should ensure there is a setup in terms of the CMS and the URL / domain structure that will allow more markets and/or languages to be added in future.

However all to often this isn’t thought about when migrating and by the time someone realises it could be too late. Some platforms, such as Drupal, are like a dream to work with to setup easy to manage international targeting, or at least have great plugins available, e.g. WordPress. Other platforms however don’t have this included, adding it in may be impossible or require your devs to build a custom module. This is just another reason why having someone who can ask the right questions and input into the site spec at the start with an SEO hat on is vital.

4. Not making the site structure future-proofed

Some companies seem to always have a migration in th works, they do one migration, which goes way over time, and often budget, and then realise it doesn’t meet their needs and so start another one almost as soon as they have launched, sometimes before.

Most often this is due to a lack of forethought and focusing only on existing challenges not thinkign about what future requirements and challenges for the website might be and often what gets missed is thinking about expansion.

This expansion could be just more content, more landing pages, posts etc. A blog section doesn’t neccesarily need categories or sub categories at first with a few dozen posts: but what about with a few hundred or a few thousand.

It can also be expnasion of new offerings, new divisions and very commonly new markets or languages. Hreflang we have mentioned above but also the URL structure needs to be considered. If you put your Canadian site on www.example.com/ca/ what happens when you want to add a French Canadian version as well as an English version. These may seem like little things, often there are workarounds but just planning ahead can make a big difference.

5. Forgetting to check Page Speed and Core Web Vitals

Most web developers, in my experience, want to create beautiful, interactive websites, they want to innovate and add cool stuff that senior stakeholders can get excited about. Nothing wrong with that but all too often this is at the expense of user experience especially when it comes to page speed.

With Core Web Vitals as part of Google’s algorithm, speed (Largest Contentful Paint), visual stability (Cumalative Layout Shift) and responsiveness (Interaction to Next Paint) can impact rankings, and even when they don’t due to lack of sufficent data: these do impact users experience of a site in the real world too.

Often problems are caused by simple mistakes, such as key images or fonts not being prioritised for loading or no width and height being provided for certain elements such as images. Often though a site can be weighed down with the number of scripts to be fetched, parsed, compliated and executed in order to add features and interactivity which few people may use.

These should of course be checked in pre-launch staging checks, often this stage is missed completely. It can be far more effective and efficient however to ensure that meeting CWV scores is in the initial specs of the site, and developers are given any support they might need in designing sites to be compliant. Testing templates before they are fully implemented across the site can also save a lot of wasted effort and allow issues to be flagged sooner.

That’s your five biggest migration mistakes then: there are more, many more, but these are the ones I see most and which can all be avoided by having someone who knows their stuff, and has probably spotted these before.