If you’re looking to undertake a domain migration or a replatforming migration or even both, then this post might be of some use to you. I’m going to put some thoughts to paper on some of the migration work I have collaborated on in recent months… I’m not going to name business names or identifiers out of respect for their privacy. I will list some of the problems I have faced and how you can overcome them. For the interest of clarity, this post is aimed at the complications and ramifications in organic search for e-commerce brands.
First up is a domain migration, simple straightforward exercise? or a time and resource drain? The answer can be both. The pitfall is it could take several weeks to reindex all the URLs for the new domain. The best-case scenario is that reindexing (or reindexation) can be done in less than a week.
How long does it take for reindexed on a new domain?
Let’s jump into a few variables here the first one being time. How long does it take for all URLs to be picked up and reindexed under the new domain? Let’s go on the assumption that best practice techniques have been followed, eg; 301 URL remapping to like for like URLs and minimized redirect chains. Submitted an XML sitemap for parsing in Google Search Console.
Guess what? There is no conclusive answer, why? Well, no two domains are the same. A small hobby site domain could house a handful of URLs, whilst an opposite large ecommerce site can hold literally millions of URLs.
Here’s why! Googlebot crawls URLs on a domain at different rates. Popular URLs with inbound links pointing at them will be crawled more frequently as will top-level hierarchal URLs, as will URLs with a higher count of internal linking. Googlebot will see the 301 redirect status for those URLs. As you get deeper within a site’s hierarchy, for example: sub-cats and sub-folders, those pages will likely be crawled far less frequently than you would possibly expect.
Which URLs can you expect to be reindexed first?
Do a little experimentation to check pages within your site get crawled less frequently. You can use a site: search operator, fast forward around 5-10 page deep in the search results. Start checking through some of the page cached date. If you see index cache dates going back weeks or even months. You can start to build up a bigger picture that will give you additional insights on how the migration will go. Which pages you can expect to see reindexed first vs those URLs that might take a little more time, honestly you could be waiting weeks before all the old domain URLs have dropped out of the index.
Log File Analysis
If you’re comfortable with log file analysis, go through the last 90 days Googlebot visits. You will learn valuable insights on how your website URLs are crawled and the frequency. You can also visit the crawl stats in Google Search Console (old version of GSC). I use Screaming Frog Log Analyser.
Other variables that could slow down reindexing?
The above was covering a best-case scenario using best practice techniques. The more domain migrations I collaborate on, the confidence grows for the next project. However, I have been involved in domain migrations at various stages. Some later in the project milestones than I would have liked. Basically, jumping into a recovery exercise.
Other variables can slow down reindexing are incorrect URL mapping, redirect chains and content pruning but most commonly I find it is usually lack of experience. Which, to be fair at the developer level, they don’t deal with migrations all that often whereas tech SEO’s such as myself handle migrations frequently.
Incorrectly URL mapping
Firstly, the redirects should always be a 301 redirect. Never ever use a 302 redirect as the equity flow is treated slightly differently than a 301 redirect. Don’t rely on auto like-for-like redirects, they can have unexpected results. My recommendation is you conduct a manual remapping exercise for all key URLs on your website. If you have the time and resource manually remap the lot. Why? If you do encounter unexpected migration issues, you can rule out redirect mapping being one of them. Simple things such as a forced trailing forward-slash could slow down a successful domain migration and can canonicals.
Redirect chains can also cause an unexpected impact on the domain migration. 2 or more hops can eat away at the equity that passes between pages. 3 or more redirect hops will certainly start to dilute passing link equity. Equity dilution on some of the domain migrations I have collaborated was caused because of the existing redirects where an afterthought by the teams responsible. Wherever possible, the existing redirects should be factored in the main URL remapping exercise. Minimise the chains by pointing the original (existing) redirect to the URL on the new domain. There are caveats such as the domain URL was not used in the existing redirection list, I wouldn’t leave to chance or guesswork though. Do the diligence work first.
Some businesses like to conduct a content cleaning or pruning exercise during a domain migration. The reasons for content pruning vary from site to site. Whether it’s a beneficial exercise or not depends on who you speak too and their reasoning. Old content such as old blog posts that no-one reads can seem like a no brainer. I’m not going to advocate the benefits or pitfalls of content pruning, simply outline the considerations.
And again, as with most approaches, there’s caveats and other variables to consider such as internal linking, the amount of content to be pruned and my favourite the expectantly on the equity passed via the redirects. You know I could probably churn out another 1000 words on content pruning pros and cons but I think I will leave it with. I strongly recommend you conduct content pruning after the domain migration, only when the majority of the URLs have been reindexed. Why? If unexpected wild fluctuations in organic search visibility occur during the migration you can rule out fluctuations that could have been caused content pruning variables.
Lack of experience in migrations and expectations
This section is in no way to sound condescending to the developers or in-house marketing teams working on migrations. Simply that there are many cause and effect variables in migrations, whether they be a domain migration or a replatforming migration.
Domain migrations have fewer variables although they can take some time to see near the previous level of organic visibility. Especially to a new domain with no history or equity. Consider giving the new domain time to establish a foothold in organic search, throw up a splash page confirm it in Search Console, throw a few inbound links at and leave it for a month or two.
Some industry SEO’s still believe there is a sandbox, myself I’m on the fence on that. A sandbox is just another variable to me. Another consideration often overlooked is an aged domains history.
Paying over the odds on a memorable domain may have a history in Google. Take a look on the Way Back Machine to establish if the domain has any history. Additionally, look at any inbound links using AHREFS and Majestic. If there are links and site history, evaluate the impact this could have on your migration. I would probably consider disavowing the links well in advance of the migration.
Domain migration pro tips
- Show diligence on the domain you’re planning to migrate to, check out its content history and links history using Way Back Machine, AHREFs and Majestic (or other leading link analysis tools). New domains may not require this diligence check
- Use log file analysis tools to gain insights into the less frequently crawled URLs, the data may assist in working out a full reindexation timeline
- Allow the new domain 1 – 2 months bed in time. Throw us a splash page with a brand message. Submit and verify to Google Search Console
- If resource time allows manually remap the URLs to the new domain rather than auto remapping rules in NGINX or HTACCESS
- Factor in existing redirects into the URL mapping task, the goal is to minimise redirect chains that could dilute link equity
- Be patient – it can take a number of weeks for all old URLs to drop out of the index, especially for larger sites
- Create a plan with key milestones, double and triple-check sign-off points before flipping that switch. Factor in snagging time for unexpected complications down the line
- Keep an eye on Google updates, an algorithmic shift may happen during migration. This is mainly for reporting and snagging
Replatforming to another technology provider can be a long drawn out process but believe me, if you can ill afford a dip in organic visibility or conversions a well thought out replatforming plan of action will be worth its weight in gold.
There are additional variables to consider when replatforming, in fact, there’s a whole bunch of them. Let’s group them into the following: site hierarchy and UX, redirect mapping, speed and performance, and content and imagery.
Google evaluates pages on numerous weighting factors, each factor has its place within the Google ranking algorithm. Undertaking a platform migration will have touch points on many of those ranking factors, which will result in organic visibility fluctuations during and possibly long after the migration.
Ensuring that your new website performs at its peak from day one is crucial to maintaining organic visibility on non-brand search terms (and on occasions brand traffic) in the SERPs. So where do we start?
Firstly, if your team has an opportunity to make the site better for user experience (UX) take it. Think about how visitors interact with your existing website and how can you make it better (thanks to Focus Web Solutions for their input on that last point). Back on point ensuring the new site has a clear well thought out structure. All the key pages/categories are easily discoverable and can navigate throughout the website without hindrance on any web-enabled device.
One of the pitfalls I have seen more than once on platform migrations, especially on larger sites is the lack of diligence shown on content migration and content placement on the new site. On larger sites, content migration is usually done in a few stages.
I’m going to give an example of a Magento migration. At the product level, the import/export feature is largely intuitive and should handle content migration. However, at the category-level out of the box import features are almost non-existent. Websites with very large complex category trees increase the chance of human error. In most cases, it’s usually not copying the category descriptions across.
One of the techniques I have become accustomed to is using XPath with Screaming Frog and Excel. Locate the div class that houses the category content such as descriptions, copy the XPath location. In Screaming Frog set up custom extraction for XPath to locate the text. Do this for both versions of the site, legacy and new, then compare the versions in excel. I generally use H1 as the identifier, just you can also use other identifiers such as category name, using a VLOOKUP will speed that process up. What you are looking for is anomalies, anything that doesn’t match up against the legacy version, then you can investigate why.
Another consideration for you to think about is content placement. Where and how is it going to sit on the new site? There seems to be a popular approach to move category descriptions below the product feed to give prominence to the products table. I can see why designers and marketers would take that approach. But here’s the thing, the cause and effect variables come into play. You’ve moved meaningful content that was above the fold to below the fold, it’s going to cause an additional weighting fluctuation. I recently saw a discussion on this subject on social media, where the consensus was to have an integrated approach. Leave a partial chunk of the content above the fold with the remainder below the product feed. That is entirely discretionary on your part, although content placement should be a discussion on scoping out content on the new site.
Should you require any support with conducting a migration, visit this page: https://sitebee.co.uk/technical-seo/