I decided to write this blog post because I get a lot of Magento retailers asking me for help after they’ve migrated to Magento from another platform from an SEO perspective. Lots of retailers lose visibility, traffic and revenue as a result of either a lack of SEO knowledge going into a migration or not understanding technical SEO issues once they’re on the Magento platform. I’ve consulted for Magento retailers of all sizes (migrations from anything from Hybris to Shopify) at various stages of re-platforming projects and have helped them to overcome all kinds of technical issues, over-indexation issues, legacy content issues, redirect issues and plenty more. I’ve also helped to deliver a host of seamless migrations.

Whether you’ve already migrated and have seen a drop in organic visibility or you’re just going into a migration, the following tips will help you to move forward.

Ensure that 301 redirects / rewrite rules have been mapped correctly

This is the biggest focus for any migration project as 301 redirects help to maintain the SEO value of the pages on your website. All pages on the previous version of a website should be redirected to the equivalent pages on the new version of the website. It’s also important that you don’t forget old redirects, as the source URLs still need to be redirected, just to a new destination URL.

This is made a lot easier if you’re able to maintain the same URL structure, however this can often be hard. Also, if you’re manually mapping a lot of URLs, you’re not going to want to add these to the .htaccess file, as it will impact the performance of your website.

The redirect mapping process can be extremely time consuming, especially if you’re moving from a legacy or non-SEO friendly platform to Magento – as the URLs are likely to be dynamic or query-string based, making it hard to create rules. Here’s an example:

Old URL: Website.com/page?cat=374759

New URL: Website.com/brands/nike

If you don’t have a standard URL convention (which you might still have if your old URLs are query string-based) to follow with rewrites, I would recommend trying to map as many as you can manually whilst working with your developer to prevent it from having to much of an impact on load time. Again, if you’re creating a manually mapped spreadsheet, you should look for an alternative solution rather than adding them individually to the .htaccess file. Magento’s rewrite management feature can help with this as well.

If you’ve already re-platformed and know that the redirects weren’t mapped correctly (and you don’t have a backup of the old version of the site you can restore), I would recommend list crawling the majority of your organic landing pages for the past few years and pulling out the 404 errors being reported. You can then map these to the new URLs on the new version of the website. I would also suggest manually redirecting the 404 errors being flagged in your Google Webmaster Tools account (or looking for a convention you can follow for a rewrite rule). Another tip here is to monitor 404 errors in Google Analytics (can be identified via the meta title), as this gives you a real-time solution for discovery and also allows you to prioritise based on traffic.

If you’ve not launched yet and still need to map the URLs, I’d suggest doing the following:

  • Using a crawler (such as Screaming Frog, Deep Crawl or Botify) to generate a list of all of active URLs
  • Taking the product feed and pulling out all URLs
  • Taking 2-3 years of organic landing pages

These should all be added into an Excel spreadsheet and de-duped, giving you a list of source URLs to start using. If you think you have issues with this, you could also use server logs and your XML sitemaps for sourcing URLs.

You can then start planning rewrite rules or looking to redirect the individual pages manually. I’d suggest trying to get ALL of your URLs, so don’t forget about things like dynamic pages, tracking parameters etc – as there’s a good chance a lot of these are going to be indexed. I’d generally review these types of pages early to factor them into the requirements for rules. For example, if I know that I have dynamic ?p= and ?category= filtered versions of a sub-set of pages (as well as the main page), I’d use a regular expression to catch the parameters being appended as well as the main URLs.

Redirects are very, very important and QA is fundamental here. I’ve worked with at least 10 merchants who have migrated and have lost a large amount of visibility due to redirect issues (which they weren’t able to see). The other things I’d recommend is to avoid using any hops, as these can also cause lots of issues (particularly common when moving from http to https as part of a migration).

Try to keep SEO and content changes to a minimum

In order to prevent a dip in traffic, I’d recommend trying to keep as much of your website the same as possible – across all page types and templates. The more search engines realise you’ve made major changes to the website, the more likely it is that you’ll see a dip in organic traffic.

If you’ve already migrated from another platform to Magento and you’ve not moved your old content, meta content etc to the new version of the website – you can still move it over and regain value (depending on how long ago you moved). If you’ve re-written the content, then there’s not much point, however if you’ve just moved and you lack content on category or product pages, you should be using the existing content.

Structural / architectural changes are also very common causes of re-platforming SEO issues – where certain pages / page types are removed or changed. This also impacts the quality of redirect mapping generally, which doesn’t help. As a rule of thumb, I’d avoid making ANY structural changes as part of a migration, as it significantly reduces the likelihood of a serious drop in traffic and revenue.

In Magento – one of the most common issues around structure is thinking that layered navigation pages (created around product attributes) can be used in place of static category pages. It’s important that you keep key pages as static pages and try and prevent any dynamic pages from being indexed.

In addition to text content, you should also be maintaining the same meta content where possible. If you’ve already moved and have re-written meta content, then it’s probably not going to be worth reverting back – but again, it’ll help to prevent search engines from seeing that there have been significant changes to the website.

I see a lot of retailers forget about things like review content, Q&A content etc, which is really important. Even if you’re moving to a new review vendor, make sure you migrate this content as well. Also, make sure that the new system allows the review content to be crawled properly – if you’re moving from a built-in platform to a SaaS option (like BazaarVoice or Yotpo), make sure the content is published in-line on the page.

Another area where lots of people have issues is around structuring the Magento product catalog. Lots of merchants move to Magento and use things like simple products alongside configurable products, leaving lots of room for duplicate content issues (because of the different variants). I’d suggest ensuring that, at least to start with, your product catalogs match. Then, for phase two you should be using canonical URLs to manage issues like this.

Ensure that dynamic pages aren’t indexable

Faceted or layered navigation represents one of the biggest issues for Magento websites and it’s not always an issue for other platforms. If you’ve recently moved over to Magento from another platform, it’s worth checking to see if your filter pages are indexable and how they’re being handled by search engines. Layered navigation pages are the biggest example, however pagination, sort / ordering parameters and search pages are other examples. Parameter-based URLs around tracking etc can also cause issues.

To check, simply use advanced search operators in Google like the following:

Site:websitename.com inurl:?price= (or inurl:?cat=, inurl:?p=, inurl:?manufacturer=)

or if you’re using something like Amasty, check things like inurl:/shopby/

I’d suggest going through the URL parameters being reported in Google Search Console and checking each of them. Really, you should be crawling the site to understand what the behaviour is here – I’d suggest using Screaming Frog and looking at how different dyanamic pages are being crawled and check if canonical URLs and other directives are being used to control how these pages are being crawled / indexed.

These pages shouldn’t be indexed and they can cause a lot of duplicate content issues – as well as leaving you susceptible from the panda update.

To prevent these pages from being indexed, you should really be using the canonical tag, which has a much higher success rate when you use it from the start (this can be quite complex to get right and the OOTB Magento implementation is generally quite ineffective). If you already have lots of these pages indexed, I would recommend looking at another solution. If your site isn’t too big and you’re not using multi-select layered navigation, I’d generally recommend using meta robots rules to assign noindex, follow tags to these pages – you can then start doing manual removal requests or wait for them to drop our of the index. If you have a larger site and are worried about crawl budget, I’d suggest looking at other options to prevent the pages from being crawled as well.

This blog post provides more detail on resolving layered navigation issues for Magento websites and generally setting up Magento for search engines.

Ensure that other valueless pages aren’t indexable

Chances are, if SEO hasn’t been a major consideration for your website migration, you’re going to have lots of other low quality pages in the index, here are some examples:

  • Search pages
  • Account pages
  • Review pages (which usually duplicate review content being displated on product pages)
  • Checkout pages
  • Wishlist pages
  • Tag pages
  • Sort / ordering pages
  • Alternate layout pages (e.g. grid)

There could be plenty more, but these are the most common ones.

To eliminate this issue, you can setup canonical URLs, use the robots.txt file, use meta robots directives, be strategic with linking or use parameter handling in Google Search Console. The right solution will depend on your store and how you’ve implemented Magento.

You can use various modules to help with this – feel free to email me ([email protected]) for advice on modules. I’d almost always recommend using MageWorx, as this gives you a huge amount of control from the Magento back-end. The module allows you to make changes to how canonical URLs work, assign meta robots rules, adjust how your sitemaps are setup, add hreflang tags etc.

Check the number of pages being indexed and compare to your product catalog and category tree

Another really good way of finding out if you’re allowing search engines to access low quality static or dynamic pages is comparing the number of pages indexed by google (by doing a site: search) before and after the migration. You can also see how many pages are being submitted and indexed via your sitemap statistics in Google Webmaster Tools and look at indexed count vs the number of products and categories in your Magento implementation. You’ll want to then allow for CMS pages etc as well.

If you find that there are a lot more pages being indexed, you can start to look for low quality pages included in the site: search and start taking action to control this.

Check that your XML sitemap is configured correctly

The standard Magento sitemap functionality is pretty poor although it will generally include any page featured on the website (all product types, categories, CMS pages etc). You should perform checks to ensure that dynamic and low quality pages aren’t being included within your XML sitemap. This isn’t something that happens with an OOTB Magento implementation, but I’ve seen it before.

If you do find any other unwanted pages in the sitemap, your developer should be able to exclude them for you. There are a number of premium Magento sitemap extensions that can help to give you more control over your XML and html sitemaps – including this one, which I’ve used in the past.

Check performance / load time against previous platform

Magento is notoriously slow and is likely to be a lot slower than your previous platform if you’re moving from a more simple system and you’ve not invested in performance. Magento can be optimised and I’ve seen some implementations where each page type loads in less than one second, but it’s generally been after lots of optimisation work. Although I don’t believe load time has a big impact on organic rankings – it will impact crawlability, which is important.

If you’re experiencing issues around speed, I’d recommend reading this piece on Magento performance optimisation.

Checklist for doing a platform migration

  • Create a good source list of URLs (crawl + analytics + feed at least)
  • Map redirects correctly (should be done on a staging website before-hand and QA’d in a lot of detail)
  • Migrate existing content onto the new version of the website (again check on a staging site)
  • Migrate existing meta content onto the new version
  • Crawl the staging website to ensure that there aren’t any accessibility issues and that redirects are working
  • Cross-reference a sample of key pages to ensure they’re represented on both versions)
  • Review number of internal links to key pages (across both versions)
  • Review overall structure – complete review of any changes
  • Ensure that the new XML sitemap is working (via the staging website)
  • Check for issues with low quality pages (layered navigation, search pages etc) and ensure that they’re dealt with
  • Check that the website is able to be crawled (without any waste)
  • Launch the website (if these issues are working)
  • Crawl the website again repeatedly (to check for issues with redirects)
  • List crawl all of the old pages (or at least key ones) to validate the redirects
  • Check redirects to ensure there aren’t hops
  • Re-submit sitemap via GWT and look for changes in number of pages being submitted and indexed

Pre-launch QA

This is fundamental and is a huge part of a successful migration. Before you go live you should have a QA brief which is focused on all SEO features / requirements and they should all be signed off by different parties involved in the project.

You should also perform manual and automated redirect testing at various stages of the project. This needs to be completed several weeks before launch, with a second QA phase around a week before launch.

Pre and post migration planning

Planning for the migration is fundamental and it’s important that you’re able to define whether there have been issues as a result of the migration and if there have been, where they are. In addition to the above, I’d suggest doing the following before you launch the new website.

  • Ensure you have a back up of the old site available
  • Map the existing site architecture against the new one, to ensure that you’re able to redirect all key pages and that you’re not going to lose any rankings / traffic as a result of losing pages
  • Generate as many keyword reports as possible (ideally daily) from 6-8 weeks prior to launch, which will allow you to see changes once the new site has gone live (you can also look to use tools like Sistrix, SEMrush and SearchMetrics for this)
  • Monitor key organic landing journeys prior to launch (so you can see if they remain the safe after launch
  • Create a list of all of the old pages and put them in a .txt file. You can then crawl the list via Screaming Frog and check to make sure that each one returns a 301 response code.

Then, once you’ve launched the new Magento website, you should continue with the ranking reports and closely monitor organic traffic levels in order to spot any changes early – allowing you make changes to redirects or pages on the website if need be.

If there are any things that you think I’ve missed – please feel free to drop me an email or mention it within the comments below.

This graph also shows the impact of a bad re-platforming project for one of my clients – we managed to recover the traffic fully (and increase visibility considerably afterwards), however they lost ~50% of their organic trade for around 3 months.

Magento Re-platforming Project

—

I’ve worked on lots of enterprise-level Magento re-platforming projects for companies from all over the world – if you have any questions around processes, QA, the Magento platform or modules, please drop me an email on [email protected]. I also provide Magento SEO audits and full Magento platform audits.