Handling SEO when moving websites and applications

One of the main priorities we encounter with clients when discussing any application upgrade, update or re-write is the maintenance of existing SEO performance and positions. This is a perfectly understandable concern as changes to content or configuration can have a significant impact on search rankings and as a consequence adversly affect sales leads / ad revenue / income.

What is SEO and why does it matter?

SEO, or Search Engine Optimisation is a set of techniques to employ to allow your website to rank as high in search engine results as possible. We started in this industry back in 1999 building traffic generating websites to drive bookings on hotel websites, so we've been involved with SEO since its very beginnings. Whilst the search world was easier to understand and work with then the basic principles of driving results are still very similar now.

Search engines are essentially algorithms, they take a huge range of input values and compute a ranking for a page. In the early days search was easier to manipulate as changes would be computed and reflected in a regular update cycle, you'd have feedback on your changes quite quickly and could make adjustments to respond. As the algorithms have evolved this feedback loop has been deliberately obfuscated to protect the ranking algorithm from being manipulated.

As a result search engine optimisation is a difficult process to get right and as any search engine marketer will understand the work required to get your site in the top results for competitive keywords is significant and negative changes to this can be hard to recover from.

So with that in mind, when a new client wants a website or application to be rewritten or moved onto a framework there are lots of things to bear in mind when managing the transition. The following list highlights the major areas that need to be considered when making changes to a site with a good presence in search, get these wrong and the website could drop rankings, or drop out altogether.

1. Domain name changes 

This isn't something that happens regularly but when you do need to change your domain as part of the re-build or restructuring it's advisable to make this change first. Leave the existing site architecture in place whilst the domain change is picked up by search engines and ensure that the old version is successfully transferred to the new domain before changing the url structures and site architecture.

Changing the domain along with the url structure and content all at the same time is a recipe for traffic loss and ranking disruptions. Search engines are smart but if you throw too much at them in one go they're likely to not understand what's happening. It's a bit like changing your name and moving house at the same time and expecting everyone to work out what's happened on their own.

We'd generally recommend not changing domains if your business is highly dependent on your current search rankings. If you do make the change then a permanent redirect should be considered to catch users clicking on existing links to your domain.

2. Urls and redirects

This is really the primary issue with site rebuilds and redesigns and it's very easy to get it wrong when dealing with large numbers of urls and web pages. The usual scenario is when urls are being changed to make them more user friendly, for example pages that have urls such as:

example.com/events.php?event=49

that need to be changed to

example.com/events/cricket-match. 

Whilst Google and other search engines will happily index the url it's not great for users who might try to access the page again from their history, it's also a missed opportunity for seo.

Urls like this can either be remapped at the server or application level. When redirecting at the server level you'd need to have a list of remapped urls for it to use (unless the new urls can be worked out programmatically) - this will involve creating a mapping of old to new urls. We've done this a few times with smaller websites and it's our preferred way of dealing with smaller sites. For larger sites with hundreds of thousands of urls it's generally easier to handle this at the application level. The essential thing here is to make sure that the server response code is correct, search engines will handle the url according to this. Some CMSs might allow you to create a redirect but this might actually happen in Javascript or not actually send the correct response code, you need to ensure that you're sending 301s to search engines to force them to update their reference to the url.

The best way to handle anything like this is to break it down into smaller steps if possible, redirect one part of the site at a time so that you can check to see that the new urls are being indexed correctly. You can start with lower traffic areas of the site and go from there. If this isn't possible then you need to test the redirects as much as possible, you can do this with application testing tools or just manually test how it responds to the urls you're expecting it to redirect. You should be looking out for potential issues with text matching and how the new application will handle a badly formed redirect, you don't want 404s and 500s everywhere for pages that were previously fine.

A good way to manage this with Google is to use the search console and submit sitemaps with the new urls. You can then monitor Google's progress in picking up the new urls and see if it's having any problems. Again, if you start with a small part of the website this can alert you to any problems before you move on. 

3. Content and on page changes

This is the other major area of consideration when making big changes to a site or application. The impact of on page factors is definitely a smaller part of the SEO mix now but you still don't want to make drastic changes to pages that are performing well. For example, if you're moving to a new content management system (CMS) with a completely different design template then you'll need to consider how that CMS handles the page meta information, how it deals with any rich snippet mark up, how the HTML tags compare in the old vs new design etc.

What we try to do is to look at a page without any styling and see how it compares, ideally you'll want emphasis on different titles, subtitles etc to be consistent between the two designs. Search engines will use the hierarchy of page elements to try to understand the page better. Whilst it probably doesn't have a huge impact in rankings a correctly marked up page is likely to be a positive marker in the search engine's opinion, especially when you consider how that page will present to impaired users.

You should also pay close attention to the load times and performance of new templates and designs. We've seen examples of CMS built websites that take over 5 seconds for the home page to load, this is due to complex heavy javascript blocking the page load until it has everything it needs. There's really no excuse for this and templates like this should be avoided, search engines will almost certainly have load times like this marked as a negative against your site.

In summary

Whilst it can seem a bit scary embarking on radical changes to your website there's really no reason why it should go wrong if you use a plan and stick to it. The ideal process is to make small changes and test the impact, then move on to the next change.

Most web development companies should be skilled in this area, if you're being told that "it'll be fine just to switch, Google will work it out" then you should probably get a second opinion.

We've moved sites with hundreds of thousands of urls and we've moved sites with 5 urls. They each present different potential issues when migrating to new systems but none of it should stop you from getting your site or application just how you want it.