During this prolonged period of quarantine, many SaaS companies saw an organic increase in demand.
The main reasons are either being forced to switch from on-premise to cloud software or an increase in TAM as a result of the forced adoption of software by the early and late majority.
I’m constantly pressured to find ways to increase the volume of new prospects and there are not a lot of customer acquisition strategies that will multiply my exposure to my target audience. It’s especially painful if you are rocking a freemium or free trial acquisition model.
Website and product localization seem to be the perfect strategy during this period. A lot of companies in non-English markets, typically more conservative, are forced to accommodate this new WFH and distributed culture.
Maybe it’s time to have a look at expanding your total addressable market into languages where your market share is low but you have good ROI.
I’ve analyzed over 300+ B2B SaaS websites and created a guide for the best course of action that will showcase awesome and disastrous examples found along the way.
For non-English SaaS companies, having an English version is a no-brainer.
Most US-based SaaS companies are in the comfortable position of targeting the language and the country with the highest account value potential.
That can be both a blessing and a curse. Being comfortable can make you lazy and unimaginative to the exponential growth of localization.
There are many ways in which you can think about language and country localization.
When should you start thinking about localization?
How do you begin to assess the ROI of SaaS localization?
Translating your website, marketing assets, and the product is the logical long term strategy for any global company.
You also have to take into consideration the costs of hiring talent for Marketing, Sales, Customer Success and Support.
For me it’s not a question of “Why should I do it ?”. The reason is obvious.
A 2020 research from CSA Research done on non-English speakers from European countries found that a massive 87% of them would not buy from an English-only website.
Most unicorns that reached $100M in valuation have their SaaS website in at least 2-3 languages.
But if your pipeline is over-reliant on English speaking leads, you may not realize you could easily grow your customer base by extending to other markets.
The problem lies in the selection bias principle.
This bias results from the non-random sampling of evidence. For example, let’s say over 80% of your customers are English-speaking people from North America. Accordingly, the data and the funnel will be over-represented by this audience.
The red dots indicate areas of combat damage received by WWII bombers that survived their missions. Since these data came from surviving aircraft only, statistician Abraham Wald recommended reinforcing the areas without damage.
Bombers that were hit in the areas without dots were the ones that were so damaged they could not make it back.
You have to avoid selection bias when deciding whether it’s time to start investing in localizing your SaaS website. If your data is over-represented by English speaking NA customers, you need to collect data from larger data pools.
You should not postpone going international to the point you start hitting diminishing returns on your current target language/location.
If you are lucky to have a big enough sample size of users from other countries/continents, you can analyze that data set to find out their average ACV and engagement. You can even go further and interview them.
Dig deeper into the particularities of their problems and workflows.
Let’s say a company in Germany uses your SaaS. Where does it fit into their workflow? How did they find your solution? Who else uses the product? Is their main office language English? Do they prefer speaking German? How would they describe their problem and your solution in German?
Also, you can look at the languages that SaaS usually gravitates toward besides English, and start your research there.
Here’s a list of the top languages that SaaS websites are targeting in their localization efforts:
- French – 21.85%
- Spanish – 18.49%
- Portuguese – 13.03%
- Japanese – 11.76%
- Italian – 11.34%
Also, keep in mind that companies that have their headquarters in Canada have their website in both English and French. Also, most EU SaaS companies will have an English version besides their native language version.
Important SaaS metrics to calculate localization ROI
This is where we get specific. To evaluate the potential of your localization efforts, you need to look at your SaaS business metrics.
In most cases, when doing a comparison, the metrics for the region you are based on will always look better than the foreign ones.
I’ve also worked with several SaaS companies in Europe that made most of their revenue from US clients. For them, the “local” metric was the US as well.
To make it easy, I’ll make a quick breakdown of SaaS metrics for a classic SaaS company with its HQ in the US that gets around $10M in ARR.
I’m not gonna go into details about how to define or calculate these metrics. You can easily google that shit.
You can make this as granular as you need. Instead of Non-English, you can add DACH, LATAM, APAC, and so on.
But I’m gonna talk about why these are important for assessing your localization potential:
- Net new MRR – It’s not as important as the other metrics but it’s good to look at how the absolute numbers are split. If possible you can also do a YoY comparison to see the evolution of this metric.
- Revenue retention is one important metric in decision making. You will usually have better retention locally, just because of the “home advantage” effect. Regardless, this is your first clue if your localization would be something beneficial.
- LTV:CAC ratio is the strongest metric to take into consideration. It will show you the profitability of your current clients from other regions of the world. You can see from my breakdown that the non-English segment fairs way better than English customers overall. That’s because most of the time there is less competition in non-English markets.
It’s also important to look at the LTV and CAC metrics separately, as these metrics might change in time depending on the timeframe. Competitors might come into play, your sample size at the moment of the analysis might be too small, you are earning customers organically without any effort.
6 main reasons for localizing your SaaS brand
When people think of localization, they think of customer acquisition. And they would probably be right for the most part.
There are four main reasons why you should think about localization:
- Customer Acquisition – obviously, catering to multiple languages increases your total addressable market exponentially. Also, the SEO benefits of translating your website and marketing assets in multiple languages can increase the size of your keyword pool and you can target the same money keyword in multiple languages.
- Increased LTV – Some niches have seen an increase in revenue per customer by localizing your product to cater to the target audience in another region. Priceintelligently stated they saw an increase in willingness to pay by 20-30% in Northern and Western Europe as opposed to their US counterparts.
- Product adoption – As I’ve stated previously, while you might get positive feedback from some product champions that are keen on using the product, you might get pushback from the rest of an organization. Having a product translated into the native language of the users will increase trustworthiness and product adoption.
- Personalized value proposition – You don’t really need to think of other languages to justify having a localized version of your website. You can offer multiple versions of your English website based on the location. That way, you can offer a personalized copy with region-specific social proofing and case studies.
- Less competition – In most cases, one niche is overcrowded only on the English speaking market. You can even do TAM research for organic search and then look at how many of your competitors actually go for more than one language.
- Legal implications – Certain legal ramifications need to be addressed when you cater to an international market. Offering your cookie and privacy policies in localized versions might ease the friction for visitors that don’t master the English language. Also, there are certain countries where SaaS companies are forced to have multilingual websites, like Canada.
- Working with local influencers and partners – Working with local influencers seemed to offer quality ROI at decent ROI in the last few years and this trend tends to grow going forward. Having a local digital footprint helps a lot in working with local influencers and channeling users to your website.
It’s easy to see how many ramifications localization can have. If you take into consideration the first three reasons, the return on investment on localization becomes a no-brainer.
However, I would not recommend looking toward localization to increase the number of leads or sales if you have problems reaching your current quotas. This is not a rainy day strategy as it costs a lot of time and resources.
The localization framework
Localization goes way beyond translating your website and goes deep into a process that requires hiring local experts and offering local support to your international clients.
But as opposed to other industries, localization almost always starts with translation.
Depending on the go-to-market strategy and your customer journey, B2B SaaS companies follow two frameworks. This is an example for Freemium/Free Trial:
The first step is to map out all the touchpoints in your customer journey. A Freemium / Free trial product would look like that:
- Your target audience searches for a relevant keyword on Google or is targeted by a display or social media ad.
- The visitor lands on one of your website’s landing pages and starts browsing through pages for information.
- Visitor clicks on the CTA button and creates a freemium/free trial account and gets onboarded into the platform.
- Users start fiddling with the UI of the product.
- The user starts receiving emails from your email drip campaign.
- The users don’t know what they’re doing and either go to the help section or contact support.
- The sales team reaches out.
- Users watch a webinar/demo highlighting the benefits of a paid subscription for their industry/role.
- User upgrades account to a paid plan.
- The customer success team sends engagement emails.
- Account Managers send the customer renewal emails.
Based on your own SaaS business structure, you can drill down on the type of content your users will encounter. The next step is to map out the types of content they will be encountering in their journey.
And it should look like this:
- Your target audience searches for a relevant keyword on Google or is targeted by a display or social media ad – display ads, social media posts, and search keywords
- The visitor lands on one of your website’s landing pages and starts browsing through pages for information – landing pages, product pages, use cases.
- Visitor clicks on the CTA button and creates a freemium/free trial account and gets onboarded into the platform – sign up steps, onboarding steps
- Users start fiddling with the UI of the product – main UI, modals, invite users, account management
- The user starts receiving emails from your email drip campaign – onboarding emails, use case emails, missed steps emails, newsletters
- The users don’t know what they’re doing and either go to the help section or contact support.
- Sales team reaches out – upsell emails, demo emails
- Users watch a webinar/demo highlighting the benefits of a paid subscription for their industry/role – webinars, pre-recorded videos, demos, walkthroughs.
- User upgrades account to a paid plan – pricing page, checkout page, a confirmation emails
- Customer success team contacts the customers – engagement emails, win-back emails, feedback emails.
- Account Managers send the customer renewal emails – renewal emails, notification emails.
Mapping out as many details as possible will help you out figuring how much time and money you’ll have to spend on localization per language.
For a multi-touch sales approach, the need for localized SDRs and sales collaterals is far more important than having your website and onboarding translated.
SaaS companies that rely primarily on freemium and free-trial strategies for their customer acquisition will follow a more self-served approach that requires your website and onboarding to be localized.
There are certain niches where the need for a localized approach would offer the greatest ROI, as the whole productivity SaaS niche.
This survey from 2011 discovered that more than 80% of the respondents declared that workers were more productive when managers talked with them in their native language.
In my analysis, I found less than 30% of productivity SaaS products had their product translated into other languages than English.
If we look at the G2 grid for visual collaboration software, only 1 SaaS company has its website and product fully translated. Lucidchart has translations for 8 languages besides English.
The two VC funded giants battling for the first position in this billion-dollar niche, Miro and MURAL still rely on the results of British colonialism from the 17th century.
Especially in these times of quarantine, when the market is expanding rapidly through the forced adoption of software from the early and late majority.
Multiplying your lead generation pipeline
If a website is translated and nobody is around to browse it. . .was it really translated?
In all seriousness, translating your website makes sense only if you plan to localize your customer acquisition.
Having another version of your website in a different language offers the opportunity to duplicate all your acquisition channels – SEO, paid campaigns, partnerships, social media.
And there’s no bigger winner than the organic search channel. The problem is it takes time to be crawled, indexed, and properly ranked.
But at the end of this effort, you’ll create another source of qualified traffic that keeps on giving.
If we look at the total number of keywords for international and non-international SaaS websites, you’ll see there’s quite a sizable difference.
The biggest difference between international and non-international websites is for the ones that have a freemium strategy. It’s a difference of 609%!
Freemium based SaaS that get most of their revenue through a self-service funnel prioritize volume over quality. Especially in the productivity niche where there’s a lot of MRR volatility due to high churn.
Sales based SaaS companies have a more target approach to customer acquisition, and also they have shitier website content for some weird coincidence. There’s a difference of 77% between international and non-international websites with a multi-touch sales model.
If we look at the percentage of US keywords, the difference becomes a bit smaller.
It seems that overall, SaaS companies that have an international strategy seem to be performing better in terms of content and SEO.
The ones that managed to also focus on localizing their website are seen as more authoritative locally.
Also, the average number of referring domains linking to international SaaS websites is 182% higher compared to non-international ones. So they perform better across the board.
Some of the international sites that I’ve analyzed are not fully committed to their localization. They kind of dip their toes in international waters.
And some of them straight up made mistakes with their web content localization.
It seems like overall, while the difference in US keyword percentage is not as big, SaaS companies that managed to also focus on localizing their website are more authoritative overall.
Starting with price localization
The easiest step in any localization process ( that could have a serious impact on your business metrics ) would be to offer pricing localization for your customer’s top regions.
A low hanging fruit experiment would be to do an A/B test and try to offer cosmetic price localization and see if it has an impact on your click through rate from pricing to checkout.
Afterward, you can go all out with multi-currency support on the major currencies of your target regions.
From over 300 analyzed SaaS websites only 61.72% of them had their pricing tiers displayed on the website.
Out of all the analyzed websites, 28.68% of them offered localized pricing.
Most of them implemented automatic price conversion based on IP or browser language settings. But some of them also had a currency switcher.
Regardless if you want to automate your language and currency displayed, I would suggest offering visitors and users the ability to switch between the available currencies.
10 rules for a smooth localization of your website
I’m not gonna get into the argument of “translation is not localization”. I feel like it’s just splitting hairs just for the sake of semantics.
Localization doesn’t really mean translating your content word-by-word. Ideally, you want to have a native speaker help you with your translations. Because they know the nuances in linguistic preferences for certain phrases in your niche. Or certain words simply don’t even translate from English to the target language.
People also tend to search differently for problems and solutions. So your target keywords and overall SEO strategy will have to be modified.
It’s usually good to look toward some of your local power users or partners for help as well. They are not only native speakers but also familiar with the terminology in your industry.
They are usually the most knowledgeable people and the most helpful, from my experience.
- Link your localized version of the website on the homepage
It’s not only important for SEO purposes, to have sitewide links to your alternate versions of the pages, but it’s important for the end-user to have easy access to them in case there’s a mixup.
92.00% of the websites that had internationalization, linked their alternate content from the homepage.
- Automatic language and region detection
This one is a hit or miss change because in certain situations can cause confusion. But from my experience, there are fewer CONS than PROS. I’ve lived as an expat in the DACH region for 4 years, and I expect a website to serve me the German version.
There are two solutions to this problem:
a) Detect and serve the localized version automatically with a prompt to change the language if it’s not the correct one.
b) Detect and offer a modal that prompts the visitor to the possibility of accessing the localized version of the page based on their location.
Actually, very few SaaS companies even do automatic detection. Only 27.03%of the websites that have localized homepages automatically redirect the end-user to the appropriate version.
And out of these, less than a handful offer a prompt to change your language.
The pandemic forced an accelerated adoption of the remote work culture. After the pandemic, we’ll see an increase in the number of expats all over the world. This means a lot more digital nomads will be accessing web content from regions where they might not speak the local language.
While automatic detection makes it easier for a native user to have a good experience on your website, it might create a lot of headaches for expats.
3. Multiple English versions for US, Canada, UK and Australia
A less popular use case, but present among SaaS companies.
You may want to have different content on your US website and your Canadian version. Or maybe you want to just modify the offer and the USPs, and leave the rest of the content the same.
Or you don’t want to create a localized selling proposition to your English website for the EU market.
In order to avoid having duplicate content headaches, you can use the same localization method.
You can use en-US, en-CA, en-GB, and en-AU to correctly differentiate your English versions. Of course, these versions can live in peace with other localized versions of your website.
Xero has multiple versions of its English website for different parts of the world.
If you are based in the US, the default version will be the US version. This means that if users from places other than the ones targeted in your localization strategy visit your website, they will be served with the default one.
4. Header or footer placement ?
There’s no wrong answer here. This choice depends on the importance and reliance on your localized version of the website. Of course, header links get more visibility from the visitors.
52.17% of the websites had their localized links at the bottom and 47.83% at the top.
There also doesn’t seem to be a huge impact from an SEO perspective. It may be because, while they are higher on the homepage, these are sitewide header links and less important as page body links.
It’s also worth mentioning that if you opt for an automatic redirect based on location but you don’t want to overcomplicate the experience with popups, it’s a good idea to put your language selector at the top.
5. Side by side or drop down menu ?
I’m going to cover several scenarios because I feel like it highly depends on different situations.
About 10% of the websites have the languages displayed side by side. If you have less than three choices this should be the best option for you. If you have more languages or locations you should go for a dropdown menu.
Beyond that you need to figure out whether the links are text, have easily identifiable icons or flags ( or a combo, why not ).
47.14% of the SaaS websites with localized content use only text in their language menu, while only 15.71% of them had a flag or a flag + text menu.
The problem with flags is that while it’s the most eye-catching option it does not fully represent a language and it may be confusing for some visitors.
I would recommend using text or a simple globe icon if your language menu is at the top. You want to be using icons or flags at the bottom in order to make it visible where the languages are. At the top, you don’t want to clutter the visual field too much and in the footer, you want to make the menu stand out among all the links.
6. If you’re going to localize your website it’s important to have hreflang properly implemented.
Without the hreflang markup, Google has a hard time identifying the proper languages and regions targeted.
You have to remember that by translating your website into another language, you basically create duplicate versions of your webpages. You basically create an intricate web of additional pages that need to be properly crawled, indexed, and ranked by Google.
We’ll go through the technical implementation later on.
It may seem like a no-brainer but actually, only 78% of the analyzed websites have hreflang implemented.
There are pretty popular SaaS websites out there like Notion and Trello that don’t really have hreflang implemented in either HTML or sitemap.xml.
The silver lining here is that Google’s algorithm is quite smart and in time, it will manage to figure shit out. But it’s by no means something that I would recommend if you want to see results this year.
7. Translated text affects the UI
You have to take into consideration the impact translations have on the UI.
For most languages, it is generally safe to prepare for as much as 25%-35% expansion (or contraction if you are translating from another language into English for example).
The expansion percentage of the text may vary depending on the topic, writing style, and sentence complexity. Very short snippets of text like USPs and CTAs may expand as much as 100%-300% in length.
It’s especially important when you’re trying to translate your product UI.
7. Every language should be easily identifiable
Sounds kind of silly, but many SaaS companies forget about the UX of this type of menu.
If the website is in Japanese, the other language options should be in their own representative countries. It helps if they have identifiable flag icons.
If you serve a website in Russian, and the user is Japanese, make sure the dropdown doesn’t display the option in Cyrillic.
You can see Agorapulse made it easy for visitors to identify and switch to their preferred version.
There are situations where flag icons save the day, like in this situation with TripActions. The German version of the website serves you a menu translated in the same language.
But as I’ve mentioned before, the flag of a country does not represent a language.
For example, did you know the Spanish language is the official language of 21 countries?
Make sure that users can easily identify their language if they find themselves in the unfortunate situation of having the wrong version of the content.
8. Legal documents translation
Legal documents like Terms of Service should be left in your default language. It’s not really a requirement to do it and it brings along a whole lot of legal problems if you are not careful.
A plethora of big SaaS companies with an international presence doesn’t translate their TOS. Companies like Trello, Gitlab, Cloudflare, Qualtrics, Hotjar, Webflow, Zapier.
It can come to the interpretation of the various versions of the agreement that can create a big legal headache.
Only 12.14% of the SaaS companies analyzed offered a localized version of their ToS.
And it consists mostly of SaaS companies that have offices around the world or companies where the main language is not English.
With privacy policies, the story is a bit different. In the EU, under GDPR laws, you might find yourself on the wrong side of the law if they find that your version of the PP is ineffective in communicating to a group of users.
9. Help center translation
I know it’s the trickiest part of the website. I know it has a lot of moving parts that get updated as the product evolves.
But if your SaaS metrics show strong, positive growth for non-English customers, this is worth the investment. Imagine the frustration of assembling an Ikea dresser without instructions.
If you don’t have the product UI translated, this step doesn’t make a lot of sense.
But less than half the companies that have an international website even bothered to offer their Help Center in a different language besides English.
This is especially bad for freemium SaaS products, where there’s no human interaction to adjust expectations.
10. If you have the budget, automate the process as much as possible
While working on large scale localization projects, I’ve made good use of localization and translation management software. These can help a lot with management, collaboration, and deployment of localized versions.
You can integrate it with your own CMS and you can just let your translators just make translations in the UI and identify all the areas that still need a translation. You can just review and push the changes to live.
If you have it in the budget, I’d definitely consider choosing such a system. I’m not particularly fond of any product in particular. You can go to a SaaS directory like G2 and do a bit of prospecting.
Most important technical aspects of localization
I can’t stress enough how efficient is localization to increase your SEO channel. But it’s also very easy to fuck up. You might think Google is just smart enough to figure it out, but it might not be the case.
It’s important to put extra emphasis on the fact that this is purely done if you want to see big SEO gains. If you just want to offer your already incoming stream of foreign visitors a localized version of your website, ignore this part.
In this section of the article, I’m gonna go through the proper implementation of your localization for SEO purposes and also display some common mistakes SaaS businesses made.
If you don’t really know how SEO works, here’s the oversimplified version of how anything gets to rank in Google:
- Google bots crawl your website and identify the pages.
- The pages get indexed in Google.
- Google tries to rank them accordingly based on its algorithm.
It’s important to outline these steps because we’ll have to reference them from time to time.
You just have to keep in mind that, by creating a localized version of your website you are duplicating all your pages ( mostly ) and your website will double in size.
Let’s say you plan on rolling out 5 new languages, and your website has around 2000 pages.
Google will have to crawl, index, and rank 12000 pages based on language, region, and topical relevance. That can’t be an easy task.
This increase in the number of pages can negatively affect the website’s crawling budget. Google’s little helpers can’t spend all day looking at your pages. Every website has a finite number of pages that Google accesses every day. Here’s an article where I wrote in more detail about the crawl budgets and the crawling process in more detail.
Most SaaS companies won’t have a problem with this unless they want to translate extensive libraries of content, templates, examples, and so on. Just wanted to mention it for the bigger players out there.
The best URL structure
While we’re on the topic of creating new pages, let’s talk about the URL slug.
You’ll have two options:
- Subdomain – de.example.com
- Sub-directory – example.com/de
It’s recommended to consolidate everything under your domain, so you should go with a sub-directory. The only situation where you want to go with a sub-directory is if your localized versions are way different than the original.
91.6% of the SaaS websites analyzed have a subdirectory as opposed to a subdomain.
Still, there are some highly functioning subdomain localized websites out there like Smartsheet or Sendinblue. But I’m pretty certain they just went by gut feeling and just stuck with it as they grew.
Once you decide on your URL structure, it’s really hard to change it afterward. Especially if you become big and reliant on SEO traffic.
There are also a very select few that chose to go with localized top-level domains, as in the case of Sumologic or Personio. As in the case of sub-domains, if you don’t plan on creating totally different content, it’s better to consolidate everything under one domain.
HTML vs XML Sitemaps
All right, so you got all these fresh new pages that haven’t been touched by any search engine crawler. In order to make it as easy as possible for Google to index and rank them properly, you need to label them with their correct language and region codes.
The best way to do this is either through HTML or XML. There are pros and cons to each option, but the most popular option among SaaS websites is the HTML one.
71.84% of the websites have HREFLANG tags in their HTML.
Surprisingly, very few websites had XML sitemaps with HREFLANG attributes. XML sitemaps are not only less messy but are more scalable in the long run.
But don’t take my word for it, check it out straight from the horse’s mouth.
Hreflang tags are very important in the process of crawling and indexing. They help Google how the different versions of a page are related to each other.
You need to be aware of the fact that as with any tag, this is not a directive. Google might decide to ignore your hreflang meta tags. But it’s still the best way to show the search engine which version of the content should be served for a language.
I’m not gonna go into details about the nitty-gritty details of the hreflang technical implementation, there are enough guides out there.
How to implement HREFLang
Like I previously stated, almost 30% of the websites that implemented localized versions of the website don’t have HREFLang meta tags.
An HREFLANG is an attribute that specifies the language and the region for each URL. And it looks something like this
<link rel=“alternate” hreflang=“x” href=“https://www.example.com/new-page” />
Replace the X with the corresponding two-letter ISO 639-1 code specific to the language you want to target. You can check out all the codes here.
If you have a handful of pages translated, Google will eventually figure out how to rank them. But if you have a handful of pages you probably don’t give a shit about SEO either.
But if you have hundreds or thousands of pages to localize it can be a pain in the ass. Not to mention you have to take into consideration other directives that you’re sending to Google like canonicals and redirects.
Let’s make a template for a SaaS company from the US that plans to release a Spanish and German version. The HREFLang structure would look something like this:
<link rel=“alternate” hreflang=“en” href=“https://example.com” />
<link rel=“alternate” hreflang=“es” href=“https://example.com/es” />
<link rel=“alternate” hreflang=“de” href=“https://example.com/es” />
<xhtml:link rel=”alternate” hreflang=“en” href=“https://example.com” />
<xhtml:link rel=”alternate” hreflang=“es” href=“https://example.com/es” />
<xhtml:link rel=”alternate” hreflang=“de” href=“https://example.com/es” />
Also, if you have downloadable assets that are translated in multiple languages you can also use the HTTP header version:
<https://example.com/downloadable.pdf> rel=”alternate” hreflang=”en”>
<https://example.com/es/downloadable.pdf> rel=”alternate” hreflang=”es”>
<https://example.com/de/downloadable.pdf> rel=”alternate” hreflang=”es”>
Another important part is that each of your URLs has return tags. This means that every page should have the same alternate tags as its counterparts.
Around 76.47% of the SaaS websites that implemented HREFLang contained proper return tags.
You have to make sure to create bi-directional HREFLang entries between all the alternate versions of the URL.
How to view your localised content in Google
To check certain keywords in certain languages or regions, you can modify the search queries in your search URL.
For example, if want to mimic a German user in the Germany:
And you can see how it looks for a German user in Austria:
Or if I want to see what an English user in Germany sees:
As opposed to an English user in United States:
It’s important to do this kind of check-up before you start the localization process, to assess what you’re going up against but also to check if everything was implemented properly.
Top 9 biggest implementation mistakes
These are the biggest mistakes I’ve seen SaaS companies do when implementing localized versions of their website. From small startups ranking for a couple of hundreds of keywords to established brands.
We’ll use the Ikea dresser analogy again – once you’ve assembled everything, you can’t do anything about that extra screw.
You have to make sure to take as many precautions from the get-go.
- 68% of SaaS websites don’t have x-default
There’s still a lot of confusion about the actual use case of x-default. More than half of websites don’t even have it in their HREFLang attributes.
This snippet of code is a directive that instructs Google that it may use a specific page as the default page for all the languages and regions that are not included in the HREFLang set. For a majority of SaaS websites out there, this will be the English version.
While it is not an enforced rule, Google recommends that you include this in your HREFLang attribute set.
- URLs with relative values
HREFLang attributes, as canonicals, can use both relative and absolute values for URLs. The difference is that absolute URLs tend to be a bit more .. errr. . .absolute.
Plus, it makes diagnosis a lot harder when you want to solve problems.
91.24% of SaaS websites have absolute URLs in their HREFLang attributes.
It is important that the URLs are not given as a path but as an absolute value. Here’s an example:
- Absolute: https://www.example.com/de/
- Relative: /de/
- Dynamic translations with JS
While Google stated on numerous occasions that it made efforts to improve the crawling and indexation process for JS reliant content, the reality points to the contrary.
In my research, I’ve seen SaaS websites, like Notion, that serve the localized version dynamically.
If you care about getting the best results from SEO, you should stay away from wrapping content in JS and you should use HTML.
- Creating another URL for the default language of the website
Another mistake I’ve encountered is the creation of an unnecessary version of the default language.
If your website is in English and you don’t plan to create multiple versions for different English markets you should not create another version for your HREFLang set. There’s no need to create example.com/en/ or en.example.com.
Long term, Google will prioritize ranking the default pages for the English market but it creates confusion and complexity.
- Using country codes without targeting specific countries
Albeit a rare manifestation, I thought I’d add it here. I’ve seen SaaS businesses like Aircall use this in their HREFLang set.
It’s obvious from their HREFLang set and the dropdown that they are targeting languages, but they’ve also added specific country codes for each language. And they point to the same URLs.
While I don’t know if this might pose serious issues ( Google is quite smart at figuring stuff out in time ), this is more like a best practices thing.
If you target all English markets with your English website you should not use country-specific codes like en-US.
- Only 67% of businesses translate the URL slug
This is both an SEO and a UX issue. Having an optimized URL slug not only reinforces the SEO signal but it offers a clear navigation to the user.
It’s actually really important in situations where you have many product and use case pages. It can become really messy and confusing in the search results.
Check out this SERP result for Aircall:
This is the German version of their Shared Contacts page. The title and the meta description are on point, but the URL slug is still in English.
By fixing this little mistake, they could not only improve the experience for visitors coming from Google but also optimize their pages for that specific keyword.
- One page is referenced in multiple languages
It’s especially popular when companies are trying to create a localization strategy for different English markets. They sometimes end up using the same page for two regions like en-US and en-CA.
While you might consider it’s ok because the content is similar and you don’t want to create another page, it’s not really best practice.
You need to have different URLs for each language or region targeted in your HREFLang set.
- Canonicalized URLs with HREFLang attributes
Another mistake that you should always be aware of: URLs that refer to another URL via canonicals must not have any hreflang attribution.
Canonical URLs should not have hreflang directives. But here too there are exceptions . Websites that have a mobile version (m.example.com) and AMP versions of pages get an hreflang tag despite the referring canonical .
I’ve talked about the complex relationship between these two directives in my article about user-generated content.
You need to stay away from having too many directives on one page, as it might force Google to dismiss them completely and just decide for itself which page to rank for what.
- Forgetting to set self-referencing links
This is more common than I would have thought.
About 1 in 4 SaaS websites have broken HREFLang sets where they forget to set self-referencing links.
Although all pages are correctly linked to one another using the hreflang tag, the self-referential link to the own page is missing.
You need to remember that HREFLang attributes are bidirectional and self-referencing.
You need to make sure to tie every end. Every version of your website should link back to itself. It’s extremely important when adding new languages as you go.
It’s a complicated process with lots of moving parts but it’s definitely a project that keeps on generating ROI long after you’re finished with implementation.
The biggest mistake I’ve seen on localization is that companies treat it like an afterschool project. They peak the languages based on who they have in their team that might know the language.
Do we have a person who speaks Spanish? Great, we’re gonna translate in Spanish. Our technical team is in São Paulo? We’re making a Portuguese version.
That’s hardly a strategic business decision. To make serious gains you need to make a serious effort. Period.
Depending on where you are on the globe, you might be forced to start this process sooner than later. Typically SaaS companies in the US tend to postpone this process or not even do it at all.
But the ones that do decide to invest in a localized website and product tend to see a lot more success. It’s just correlation or is it causation?
A bit of both, if I’m being honest.
High performing localization goes beyond content. You also need to hire sales people, customer support and so on. So you need to budget that in as well.
But having a TAM assessment to see if it’s the right move for you doesn’t really cost anything.