Last spring TransferWise, an online only fintech scale-up changed its name to Wise. The result was a complex domain migration process that broke many established best practices and SEO rules. Find out why we did it and how come it all turned out well in the end.
27. Custom environments?
Customised staging environments with only the services
we're interested in, and not the "moving people's money"
parts.
Fast & flexible.
Homepage
Money
transfers
AML Magic* Blog CMS
Custom environment
* Not actual technology name
28. Deploying to custom environments
Version 2 deployed on a custom
URL:
https://phase2.ourstagingdomain
.transferwise.com/
Version 1 deployed on a custom
URL:
https://phase1.ourstagingdomain.
transferwise.com/
Compare crawls
@LuciaLecesne @Wise
33. Test redirecting a portion of new
visitors from a single geo (not
search engines)
There wasn’t one
single big bang
migration day
Phase 2
@LuciaLecesne @Wise
34. This COULD get problematic if:
a) You accidentally include search engine
bots
b) You artificially exclude search engine bots
@LuciaLecesne @Wise
35. No major search engine operating
&&
Big part of our user base
@LuciaLecesne @Wise
36. Worth it. We caught a bug.
😌
@LuciaLecesne @Wise
37. All visitors without cookie get
redirected
The “SEO” migration day
There wasn’t one
single big bang
migration day
Phase 3
@LuciaLecesne @Wise
Hi, my name is Lucia and I work as an SEO product lead at Wise, previously called TransferWise. Last spring TransferWise, an online only fintech scaleup changed its name to Wise. And as it goes, with a rebrand came a change of a well established domain.
Let’s back up a little and let me give you some context on why this particular domain migration was special. For starters, our “google-facing” website is fragmented into more than 16 github repositories, using multiple frameworks such React, Thymeleaf or Wordpress.
We move £7 billion every month and have more than 12 million customers - that means that we couldn’t afford any outage or any disruption to our service. Plus, since we take trust of our users very seriously, we wanted them to know about the new brand and the new domain as soon as possible.
And so we tweeted about it along the way. We love to keep things transparent (and interesting)
All that just a few months before entering the London Stock Exchange. This was no longer an SEO exercise, the value of the company was at stakes. We simply had to get this right.
In other words, no big pressure. So what did we do? Did we dust off our migration checklists and ensured all of the best practices that you’ll hear a lot about in the following talks were followed to the T?
Yeah, right. Except that this is a real world and a very real multi-million business in it.
So let me tell you how it all went down. It turns out that we had to do a lot things differently. Things that at a first glance go against best practice. Some of them downright nuts.
As you can see though, i’m still here, so clearly things worked out for us. Let me show you how.
There was no big spreadsheet or htaccess file that would match old and new URLs. To minimise impact we decided to move the website as it was, with freezing any website changes and architecture decisions. This of course meant a lot of pushback from other parts of the company, as rebrands often inspire other changes, such as:
Changing the main navigation on the homepage
Considering splitting the website on subdomains
Or redirecting transferwise.com’s homepage to a subfolder
My personal favourite was a suggestion to use JS redirects to redirect real users from the old homepage to a subfolder, while sending Googlebot to a different location. This of course would be not only against Google’s guidelines, most likely it would not work anyway, since Google follows JS redirects nowadays.
How did we push back? And how come anyone listened to us? We used case studies from unsuccessful migrations (internet is full of them), and plotted the estimated drop on our own organic traffic and conversions attributed to said organic traffic - everyone understands £££ lost due to a bad SEO.
But going back to the things we did differently…
We didn’t fix a single internal link manually. With a large scale website we didn’t have time to upload new logos and update internal links one by one. So we decided to automate it and built a library that worked with Java as well as React to automatically replace any mentions of the old brand name, logo and old host.
Moving on to the probably the most controversial decision…
…To keep both domains live and accessible in parallel. Once the world knew about the new name, we wanted the search engines to know as well. We launched a version of our existing website, with the new logo and brand name on the new domain address. And invited Google to it. How come it was OK?
We allowed search engines to crawl and index the homepage of the new domain, while blocking crawling the rest of it. We put an organisation schema with “sameAs” on both domains, to help Google understand the connection. We decided against using noindex or canonical. Using them would mean that bots would likely spend days or weeks crawling millions of our URLs, only to be told that we don’t want them to show up in their index.
I bet you would like to know how much this backfired or what happened next. I’ll tell you in a minute. But before that, there is more you need to know.
Wise.com wasn’t a brand new domain. In fact it’s been around since 90s and belonged for a while to Symantec and other companies.
So in addition to analysing its backlink profile and checking for any manual actions, we also wanted to makes sure that there weren’t any other indexation issues. We published three random articles on the domain and exposed them outside of VPN restriction …and watched.
And voila, all was good. It looked something like this.
One of the things that is crucial in domain migrations is being able to crawl both the old and new domain in staging. However, there are a couple of downsides to using staging environment for this: 1. We didn’t have one. Or well, we did, but not across all of the applications, so crawling it would be a nightmare. 2. Our website consists of multiple web apps, and everyone of them relies on multiple services and dependencies.
We used what we call “custom environments”, sort of customised staging that allows us to include only the services that we need and not the “moving money” part. This technology was built specifically for TransferWise, but there are similar services from companies such as Netlify or Vercel.
This had the added benefit that I, as an SEO, could directly from Slack spin up multiple custom environments to deploy different versions of github repositories and compare them side by side. We could crawl these different versions and then compare crawls in Screaming Frog to spot any missing links, or other anomalies.
That’s still not it though. There are even more things that were a little unusual
We didn’t pull the trigger on a single big bang migration day. That would be too risky. Remember all of those pounds and dollars that we move every month? We’ll hear about them soon again. Phase 0 simple meant hiding the domain behind a VPN and only exposing few select parts to test indexability.
Then we announced the rebrand. New domain went public, but absolute majority of the website was still closed for crawling. No impact on Google OR users for now.
In phase 2 we wanted to make sure that all was working well behind the log in and so we decided to test. For 1 hour we started redirecting users from a single location.
Of course, we wanted to make sure that no search engine was involved. This was meant to be just a test. We weren’t ready to migrate yet.
We picked UK, as no major search engine crawls from a british IP address and most of our users are based here.
And good thing that we did - we quickly realised that our redirects in fact DID cause an issue, so we could revert our changes and fix them before going live.
So we fixed what was broken and finally started redirecting all new visitors (without existing cookies) - including search engines.
For a short while after that we kept all users who had visited transferwise.com before the migration on the old domain - just in case. But then that was it - transferwise.com was no more.
All in all it was an exciting domain migration and we learned a lot.
It was absolutely crucial that SEOs were part of all important decisions surrounding the whole project. We got the seat at the big table and that meant that although we had to compromise and put user’s experience before SEO migration checklists, we had the opportunity to push back when our future domain health could be affected.
You see, at Wise SEOs have a say.
We have earned that trust, because SEO is not a supporting team. We measure what we do and have a tangible impact on the company’s bottom line. Engineers are part of our team, which means that we can implement, build and learn much faster.
Another useful thing was using project plans built in the Confluence with Github integration. This way we could keep track of pull request across multitude of repositories and make sure that all of the requirements were met when moving from one phase of the migration to another.
Sidenote: it doesn’t really matter what tool you use, as long as it helps the communication across the teams.
Another thing that we learned is that sitemaps can really help. Not only to let search engines know about the new/old domain, but a well structured sitemap index makes it easy to see what ratio of the website has been recrawled and reindex. (Monitoring crawl logs is even better, but takes more time and resources with large websites)
All in all it was an exciting domain migration and we learned a lot.
For example Bing was much less willing to recrawl the new domain’s homepage based on some cached information from a decade ago - as a result, immediately after the domain launch we got accidentally indexed everything apart from the homepage (opposite of what we wanted)
Sooo… what was the result?
Even though we have changed our brand name, both Google and Bing made the connection fast
Within 30 days we started ranking first + got the knowledge panel for the new brand
It went well. We have recovered most of the traffic almost immediately and despite some algo hiccups last summer, wise.com continues growing.
Another chart of the same thing, sorry couldn’t help myself. :-)