Why the second language must not become a second website project
The trigger is almost always the same: your SaaS is growing beyond the DACH region. The first trials come from the Netherlands, a partner asks for the English product page, the advisory board asks about the international roadmap. And immediately the worry appears: do we now have to maintain every page, every article, every price change twice?
The short answer: no. Duplicate maintenance is not a law of nature but an architecture mistake. Whether your multilingual website becomes a growth lever or a maintenance grave is decided in three places: the URL structure, the hreflang annotation, and the question of how your CMS manages the language versions.
That the step can pay off is well documented: according to the CSA study “Can't Read, Won't Buy” (2020, 8,709 respondents in 29 countries), 76 percent of online buyers prefer product information in their native language; 40 percent will not buy from foreign-language websites at all. If you offer only one language, you measurably forgo demand.
This article is part of our guide on the anatomy of a B2B SaaS website. I walk through the decisions in the order they come up: is the second language worth it at all? Which architecture carries it? And how does the content stay in sync without you copying it?
When the second language pays off and when it is just maintenance overhead
First, an uncomfortable truth: the translation itself is the smallest item. What gets expensive is the upkeep — every new feature, every blog article, every price adjustment now raises the question “and in English?”. So the decision does not hang on a wish for another language but on your business. Three signals speak for it:
- Trials from abroad: registrations show up in your analytics from markets you never advertised in. The market pulls before you push.
- English-speaking buying centers: even DACH corporations increasingly evaluate software in English-speaking teams. Without English product and security pages, you drop out at the shortlist stage.
- Product and support are already there: your app interface and support already work in English. Then the website is the last missing piece, not the first.
For most SaaS companies from the DACH region, the second language simply means English: 49.5 percent of all websites are in English (W3Techs, as of September 22, 2026), and English carries you through the Benelux countries, Scandinavia, and Eastern Europe before you invest in further local languages.
The reverse also holds: if your product is tied to the German market, say through a DATEV integration or German tax law, nobody will believe your international website. And if nobody on your team can answer English support tickets, you create demand you have to disappoint. Then the second language is pure maintenance overhead.
The most honest test question: who on your team answers an English support ticket next Tuesday, and who edits the English version of the new feature next month? If you have two names, the language pays off. If you have none, it is decoration.
A language version nobody maintains is not market access. It is a shop window full of dust.
Subdirectory, subdomain, or separate domain: the architecture decision
Now for the technical part: Google's documentation for multilingual websites describes four URL structures. Google explicitly advises against URL parameters like ?lang=en. That leaves three candidates, which compare like this:
| Structure | Example | Strength | Weakness |
|---|---|---|---|
| Subdirectory | example.com/en/ | one domain, one infrastructure, pooled authority | country focus barely visible in the URL |
| Subdomain | en.example.com | separate systems per language possible | authority and maintenance get split |
| Country domain (ccTLD) | example.co.uk | clearest signal for a country market | expensive, own infrastructure, one country per domain |
For SaaS websites, the subdirectory is almost always the right choice: one codebase, one domain, and every backlink benefits all languages. A new language is then a folder, not a project. Country domains only pay off once you build a separate organization with its own marketing per market — which comes much later.
hreflang: tell search engines which versions belong together
hreflang is the annotation that tells Google which language versions of a page correspond to each other. Without it, your German pricing page might rank in London. The hreflang documentation from Google Search Central names three methods: link tags in the HTML head, HTTP headers, or entries in the sitemap.
The rules are strict, and most implementations fail on them: every language version must list all other versions and itself. If page X points to Y, Y must point back to X, otherwise Google ignores the annotation. The codes follow ISO 639-1 for the language, optionally extended with ISO 3166-1 Alpha 2 for the region, for example de-CH.
On top of that comes x-default as the catch-all version for every language you do not serve. A classic from the error list: region codes without a language (“UK” or “EU” on their own) are invalid. hreflang is diligent work by clear rules — which is exactly why your framework should generate the tags, not your editors.
Concretely, the head of our homepage carries three entries for this: one for de, one for en, one for x-default, each with a fully qualified URL including https. With hundreds of pages, that list is better placed in the sitemap, otherwise every page drags unnecessary kilobytes around in its head.
What to translate and what to leave alone
Not every page deserves a second language. My rule of thumb: translate what sells, and skip what merely keeps you busy.
- Always translate: homepage, product and feature pages, pricing, trust center, onboarding emails. Everything that sits in the buying process.
- Translate selectively: blog and resources. Translate the five articles that demonstrably bring trials, not the archive.
- Usually English only: technical documentation, API reference, changelog. Developers expect English; in my experience, nobody keeps a German API doc up to date. How docs and website come from one source is covered in the sibling article docs and website from one CMS.
- Review per market instead of translating: legal notice, terms, privacy policy, price information. This is not about language but about law; more on that below.
Content maintenance without drift: connect instead of copy
Now for the core of the use case: how do you maintain two languages without doing everything twice? The most common mistake is quickly described: the English site starts life as a copy of the German one. Six months later, nobody knows which version missed which change. I call this silent divergence drift.
The antidote is a pattern from the headless world: one document per language, connected by a translation reference. The German and the English pricing page are two independent documents, but the CMS knows they belong together. That gives you three things:
- Visible gaps: you can query which German documents still lack an English counterpart. “Something is missing somewhere” turns into a work list.
- Independent content: the English version may be shorter, cite different references, or drop a section. You translate the message, not the syllables.
- Generated hreflang: the frontend builds the hreflang tags from the connection automatically. Nobody maintains lists of language URLs by hand.
We do exactly this on happycoding.agency, with Sanity as the CMS and Next.js as the frontend: German and English live as the subdirectories /de/ and /en/ on one domain, each piece of content exists as one document per language, and a connecting document holds the pairs together. The hreflang tags are generated from this connection. Nobody here has ever written an hreflang tag by hand.
This is what it looks like day to day: you change the pricing section in the German document. The connection shows you the English counterpart, you carry the change over in a quarter of an hour, and both versions match again. Without the connection, the search begins instead: which pages existed in English again?
What matters is the question of leadership: for us, German is the leading language, every change starts there and then travels to English. Set this direction explicitly. Two equally ranked sources are guaranteed to drift.
Machine translation, human editing: the 2026 workflow
On the translation itself: in 2026, you no longer need to commission anyone for the raw text. Machine translation, whether DeepL or a language model, delivers marketing copy at a quality that was agency level just a few years ago. The bottleneck has moved: from translation to editing. Our workflow has three steps:
- Glossary first: define which terms stay untranslated (product name, feature names) and how core terms are translated. Without a glossary, the same feature means three different things on three pages.
- Machine first draft: the machine translates the entire document, including meta title, meta description, and image alt texts. That costs minutes, not weeks.
- Human editing: a person who knows the market reviews positioning, tone, claims, and everything with legal relevance. In our project experience, that is closer to half an hour than half a day per marketing page — an estimate, not an industry figure.
Take the editing step seriously for SEO reasons too: Google's spam policies list automated translation among the techniques used to mass-produce pages without added value. An edited translation with market context is far from that; a thousand unreviewed AI pages are exactly that.
One more thing: translation is not a project but a process. Build the editing step firmly into your publishing routine: a new blog article only counts as done once it is decided whether it gets translated — and a deliberate no is a perfectly legitimate outcome.
For your budget, this means: in my estimate, the second language adds roughly 20 to 30 percent on top of your ongoing content maintenance — a figure from our own projects, not a surveyed industry number. With copied instead of connected pages, you sit permanently well above that.
Five mistakes I keep seeing
To close, the error list from audits and project takeovers. Check your website against every item:
- The half-translated site: homepage in English, blog in German, cookie banner mixed. That does not look international, it looks unfinished. Better to translate ten pages completely than forty halfway.
- Forgotten meta texts: meta title, meta description, Open Graph texts, 404 page, form error messages, confirmation emails. The texts no editor sees in daily work are exactly the ones a prospect sees first.
- Forced redirect by IP: visitors from Zurich land on the German version automatically, even as English speakers. Google advises against automatic language redirects and recommends visible links between the versions; the same documentation calls IP-based location generally unreliable.
- hreflang without return links: the new English page points to the German one, but the German page lacks the link back. Result: Google ignores both annotations.
- Prices and legal texts carried over unchecked: net or gross, currency, legal notice requirements, applicable law. What is correct for Germany is wrong in the UK or the US. These pages do not need a translation, they need a review per market.
Next steps
If the second language is coming up for you, start with the architecture, not with the translation: subdirectory structure, one connected document per language, generated hreflang. That costs a few days at the start and saves you years of duplicate maintenance.
As a website agency for B2B companies, we build multilingual websites with Next.js and Sanity — following the same pattern our own site runs on in German and English. If you want to know what the path looks like for your website, book a free intro call: we look at your setup and sketch the steps to the second language.
