One Site, Six Languages: Lessons From Localising a SaaS Blog

A while ago I helped take a SaaS blog from one language to six. We started in English, and over the following year we added five more languages, market by market. It went better than I expected in some ways and considerably worse in others, and almost nothing about it matched the tidy plan I had drawn on a whiteboard at the start. This is an account of what I actually learned, written in the hope that it spares someone else a few of the wrong turns.

I am not going to pretend this is a universal playbook. Every market is different, every product is different, and what worked for one blog may not transfer cleanly to yours. But the lessons below are the ones I would tell a past version of myself, and most of them are less about technical SEO than about expectations, sequencing, and the quiet ways a localisation project goes sideways.

Lesson one: I confused "translated" with "localised" for far too long

The first version of our plan was, embarrassingly, a translation plan. We had a good English blog. The idea was to translate it, well, into five languages, and the new traffic would follow. I genuinely believed this for the first couple of months.

What broke that belief was looking at why our first non-English pages were not ranking despite being, by any reasonable standard, accurate translations. They were accurate. They were also using the wrong words. We had translated our English keywords faithfully into the target language, and the resulting phrases were grammatically correct and not what anyone in that market actually typed into a search engine. Real searchers there used a shorter colloquial term, or a borrowed English word, or a regional variant our translator — who was excellent — had no reason to know was the high-volume search query, because translating accurately and knowing search behaviour are different skills.

The lesson landed hard: translation is a language task, and ranking is a search-behaviour task, and they are not the same task. After that we did keyword research natively in each market before writing anything, and treated translation as the step that came after we knew what the market searched for, not before. Everything improved once that order was fixed.

Lesson two: entering markets one at a time was right, and I almost didn't

There was real pressure, internally, to launch all five new languages at once. It looked decisive. It made a good slide. I came close to agreeing.

What stopped me was a smaller, duller realisation: we did not have the capacity to do five markets properly at the same time, and doing five markets badly is worse than doing one market well. Each market needed native keyword research, native review, market-specific examples, and someone paying attention to its performance. Multiply that by five simultaneous launches and we would have produced five mediocre, half-localised sections and learned nothing clean from any of them.

So we sequenced. One market, then the next, with a gap between. The gap turned out to be the valuable part. By the time we launched the second market we had already learned things from the first — what our localisation process missed, how long native review actually took, which kinds of articles translated well and which needed rewriting — and every subsequent launch was better than the one before. Launching all five at once would have meant making the same five mistakes five times in parallel. Sequencing meant making each mistake once.

Lesson three: the URL structure decision felt boring and was the most important one

Early on we spent what felt like a disproportionate amount of time arguing about URL structure — whether the language versions should live on separate domains, on subdomains, or in subdirectories of the main site. It felt like bikeshedding. It was not.

We chose subdirectories, putting every language in a folder of the one main domain. The reason, which I only fully appreciated later, is that the whole site then shares one pool of domain authority. Every link our English blog had ever earned over years of work was helping the new French and German folders rank from the day they launched. Had we put each language on its own domain, every new market would have started its authority climb from absolute zero, and I am fairly sure two of our smaller markets would simply never have gotten off the ground.

The lesson: the structural decisions you make before publishing are the ones you cannot easily undo, and they quietly determine how hard everything afterward will be. Spend the boring meeting. It is cheaper than the migration.

Lesson four: hreflang humbled me

I will be honest about this one. I thought hreflang — the markup that tells search engines which language version to show which searcher — would be a small technical task. It was not. It was a recurring source of small, infuriating bugs for most of the year.

The problem was never the concept, which is simple. The problem was that hreflang is an interconnected matrix that has to be perfectly consistent, and we were maintaining it by hand. Every page needed to reference every sibling version and itself, every reference had to be mirrored on the other end, and every time we added a language we had to update every existing page. We missed things. A non-reciprocal link here, a wrong region code there, and a page would quietly stop being served to its market for weeks before anyone noticed, because hreflang fails silently.

What finally fixed it was abandoning the idea that careful people could maintain the matrix by hand. We moved to generating the whole hreflang set automatically from one list of page versions, and validating it with a checker before publishing. The bugs stopped. The lesson: hreflang is not a test of diligence. It is a clerical task at a scale humans are bad at, and it should be automated. (I have written more about that specific pain in our piece on hreflang without the headache.)

Lesson five: some articles should have been rewritten, not translated

We translated almost everything by default, and it was the wrong default for a meaningful slice of the blog.

Technical explainers — how a feature works, what a concept means — translated cleanly, because their substance was market-neutral. But our more opinionated, example-heavy articles did not. They were full of references to our home market, framings that assumed a reader from our country, examples that meant nothing elsewhere. Translated literally, they read as faintly foreign and slightly off, and they did not perform. The ones we eventually rewrote — same topic, but reconceived for the target market with local examples and local framing — performed much better.

The lesson is that "translate or rewrite" should be a decision made article by article, not a blanket policy. We learned to ask, for each piece, whether its value was in market-neutral information (translate) or in market-specific framing (rewrite). Getting that question into our process improved the new markets noticeably.

Lesson six: the native reviewer was not optional, and I tried to make it optional

To save time and money, there was a stretch where we published machine-translated content into a market without a native speaker reviewing it first. The translation tool was good. How much could a reviewer really catch?

Quite a lot, it turned out. Not grammar errors — the machine got grammar right. It was register, idiom, and the small tells. Phrasings that were technically correct but that no native speaker would choose. A slightly formal tone where the market expected casual, or the reverse. The cumulative effect was content that subtly read as written by an outsider, and in a market where local competitors sounded native, that was a real disadvantage. We reinstated native review for every market and never skipped it again. It is the cheapest insurance in the whole process.

Lesson seven: I had to measure each market separately to see the truth

For a while we looked at one combined traffic number across all six languages, and it told us almost nothing. It went up, slowly, and we felt fine.

When we finally segmented the data by market, the real picture appeared, and it was not the smooth story the aggregate told. Two markets were growing strongly. Two were doing fine. One was essentially flat, and one was quietly declining. The aggregate had averaged a failing market and a thriving one into a comfortable "steady." Once we could see each market on its own, we could act — pour effort into the markets that were responding, diagnose the flat one, and eventually accept that the declining market was not worth our attention and redirect that effort. The lesson: an international program is several programs, and a number that averages them is a number that hides them.

Lesson eight: choosing the markets was harder than executing them

I had assumed the hard part of the project would be the doing — the keyword research, the writing, the technical setup. It was not. The hard part, in hindsight, was the deciding: which five languages, in which order, for which markets.

We did not choose carefully enough at the start. A couple of our markets were picked because the language was "obvious" or because someone had a contact there, not because we had honestly assessed the search demand for our subject, the competition we would face, and whether our product genuinely fit that market. One of the markets that later turned out flat was a market we had chosen for a soft reason — it felt international, it looked good on the roadmap — rather than because the numbers supported it.

The lesson I took is that market selection is the highest-leverage decision in an international program and deserves the most rigour, yet it usually gets the least, because it happens early when enthusiasm is high and data feels optional. If I did it again I would treat the shortlist as a real analysis: rank candidate markets by demand, by beatable competition, and by product fit, and refuse to add a market that scored poorly on all three no matter how appealing the language sounded. We executed our weak markets perfectly well. They were just the wrong markets, and good execution does not rescue a wrong market.

Lesson nine: local links were the slow part nobody owned

The subdirectory structure gave our new markets a real head start on authority — they inherited the domain's existing strength. For the first few months that head start was enough, and the new folders ranked respectably. Then, in the more competitive markets, they plateaued, and it took me a while to understand why.

The reason was that competing with established local players eventually requires local signals of relevance and trust — links from sites in that market and that language, mentions in the local-language publications and communities our buyers there actually read. Our inherited authority got us onto the field. It did not, by itself, win the more contested markets. And local link earning was the part of the program nobody clearly owned. The technical work had an owner, the content had an owner, but "go earn relevant links in the German-language web" sat in a gap, so it largely did not happen.

The lesson: an international program is not finished when the content is published and hreflang is correct. In competitive markets there is a slower, second phase of building genuine local presence, and it needs an explicit owner and explicit time, or it quietly does not get done and the market plateaus. I would assign that ownership from the start next time, rather than discovering the gap when the growth curve flattened.

What I would do differently

If I started again, I would do native keyword research before translation from day one instead of learning it the painful way. I would automate hreflang from the first market rather than the fourth. I would decide translate-or-rewrite article by article from the start. And I would set up per-market reporting before the second launch, not after the sixth. None of those are dramatic insights. They are just the difference between learning lessons in advance and paying for them in lost months.

The encouraging part is that the project did work. Six languages, one shared domain, real traffic from markets we could not have reached in English alone. It was slower and messier than the whiteboard promised, but it compounded — and a multilingual blog, once it is structured properly, keeps paying back long after the launches are done.

Where an AI agent fits

Looking back, most of what made the project hard was not strategy. It was the sheer multiplied volume of structured, repetitive work — native keyword research in five new languages, intent classification per market, hreflang matrices, translate-or-rewrite calls on hundreds of articles, per-market reporting — all of it done in parallel and forever. That volume is what nearly broke the timeline.

It is also exactly what an SEO AI agent is built to absorb. Orova works natively across multiple languages — it can run keyword research directly in each market's language instead of translating a domestic list, classify intent per market, draft and adapt content for each locale, help keep hreflang consistent as languages are added, and report each market separately so a failing one cannot hide inside an aggregate. It would not have replaced our native reviewers, and it should not replace yours — that judgment stays human. But it would have removed the repetitive volume that turned a one-year project into a frequently overwhelmed one. If you are about to localise a blog, get the structure right and let an agent carry the parts that are work, not judgment.