Multilingual websites for agencies: the practical guide
Practical guide to multilingual website architecture for small agencies - URL strategy, content modeling, hreflang, and the tooling that makes multi-language editable.
This is our agency’s practical guide to handling multilingual websites sustainably.
TL;DR. A sustainable multilingual SMB stack rests on four decisions: subdirectory URLs (example.com/en/, example.com/de/), localised slugs per page key, an explicit default-and-fallback policy, and a translation workflow that fits a small team. Add field-level localisation flags and automatic hreflang in head and sitemap, and the CMS handles the multilingual work the editor would otherwise repeat by hand for every change.
TL;DR (skim view)
- Subdirectory URL structures (e.g.,
/en/) are usually the most sustainable choice for SMBs. - Hreflang tags are critical for SEO and should be automated by the CMS.
- Field-level localization saves time by preventing full-page re-translations for minor edits.
In Germany, Austria, Switzerland, and most of the EU, “do you support multiple languages” is not a feature ask - it is a baseline expectation. A hotel website without an English version loses guests. A clinic without a Turkish or Arabic page leaves patients out. A small-agency portfolio that does not handle multilingual cleanly is operating under capacity. This is one reason why a multi-tenant CMS is a strong fit for agencies serving these markets.
The four upfront decisions
Successful multilingual sites require upfront choices on URL routing, slug localization, fallback behavior, and translation workflows.
URL strategy. Three options. Subdirectory (example.com/de/, example.com/en/) is recommended for nearly every case. One domain, one SSL certificate, one analytics property, easy hreflang. Subdomain (de.example.com) is acceptable but more setup overhead. ccTLD (example.de, example.fr) is only useful if you target country-specific markets distinctly. For multilingual SMB sites, default to subdirectories.
Localized slugs. example.com/de/funktionen/ reads native to a German visitor. example.com/de/features/ reads borrowed. Localized slugs are better for native UX, better for native-language SEO, and signal to search engines that each locale is independently authored. Implementation cost is a slug map per page key per locale - minor work, significant UX win.
Default language and fallback. Pick a default language - usually the agency’s home market, or English for an EU-targeting product. Then decide what happens when a localized version of a page does not exist. Hard 404 is right when every page should be authored per language. Fallback to default is acceptable when you start a new locale and it is not yet complete - ship a banner. Redirect is cleanest for SEO but can feel rude.
Translation workflow. For SMB sites with a small agency, three patterns work. Translate up front, edit per language afterwards (most common). Default-language editing only with machine translation at render time (cheap, quality uneven). Per-language editorial team (rare for SMB managed websites).
hreflang in practice
The hreflang attribute is the standard mechanism (documented by Google Search Central) to tell search engines which language version of a page to serve to which users.
Search engines need to know which page in which language is the canonical version of the same content. The mechanism is the hreflang attribute, set in the page head as link rel=“alternate” hreflang for each language version, plus hreflang=“x-default” pointing to the fallback. Also in the sitemap with xhtml:link rel=“alternate” hreflang per URL entry. A modern multilingual CMS handles both automatically.
Localization granularity
Not every field needs to be translated. A typed content model lets the agency decide per-field. Always localized: headlines, body text, FAQ entries, image alt text, SEO meta titles and descriptions. Sometimes localized: product names, team member titles. Never localized: layout choices, alignment, dates rendered locale-aware at view time, block structure, image references.
A CMS that lets the agency mark each field localized or not is doing a lot of the multilingual work for free. Field-level locale flags are the difference between “translate the website” and “translate the content.”
German-specific patterns
A few patterns matter for German-market sites. Formal Sie throughout B2B German content, always capitalised - the phrasing is different from informal du, not just a pronoun swap. German allows long compound nouns - make sure layout accommodates 30-character single-words without overflow. Date format expects 9. Mai 2026, not May 9, 2026. Number format: 1.000,50 (period thousands, comma decimal). Impressum, Datenschutz, and Cookie-Richtlinie are mandatory disclosures - per-locale legal pages, not a translated copy of one.
What to avoid
One CMS install per language - past pattern, maintenance treadmill. Auto-translation at view time only - fine for low-stakes content, painful for SEO. Free-form HTML body translated whole - any content edit re-triggers translation review for the whole body.
The tooling baseline
A small agency multilingual stack typically wants a CMS that handles localized fields at the schema level, localized URL slugs without manual reconciliation, automatic hreflang in head and sitemap, locale-aware preview, per-locale draft and publish status, and built-in AI-assisted translation for field-level content. In our experience, Kernset ships all of these effectively. See the full feature list for details.
For a typical SMB site, launching in a second language means roughly doubling the initial content-load work. Steady-state edits are slightly more expensive per change because the client edits in two places. The benefit is a site that genuinely speaks to its audience in their language - which, in most European markets, is what closes the deal.
Frequently asked questions
Should I use subdomains or subdirectories for a multilingual site?
For the vast majority of SMB client websites, subdirectories (like example.com/en/) are the better choice. They consolidate domain authority, require only one SSL certificate, and simplify analytics tracking compared to subdomains.
See it against your portfolio
If your portfolio mixes hotels, clinics, or service businesses that need to read native in two or three languages, the fastest way to know whether Kernset fits is to look at it against your messiest current multilingual site. Get early access - a real person reads every message.