Building a Swedish-English Website the Right Way

Choosing the URL structure

There are three honest options. Language folders on one domain keep all authority in one place and are the easiest to maintain. Separate domains, such as a .se and a .com, make sense only if the markets are run as separate businesses. Subdomains sit awkwardly between the two and are rarely worth it. For a company site the folder model wins almost every time. Whatever you choose, translate the URL slugs too: /sv/tjanster/ and /en/services/ read as native pages, while /en/tjanster/ does not.

hreflang and language switching

hreflang is a tag in the page head that lists every language version of that page. It is how Google learns that /sv/priser/ and /en/pricing/ are the same content for different audiences, so that a Swedish searcher gets the Swedish page instead of the English one. It is fiddly, and most bilingual sites get at least one detail wrong.

• Every page links to itself and to every sibling, in both directions. A one-way tag is ignored.
• Include an x-default entry pointing at the language you want shown when no match exists, usually English.
• Use language codes consistently: sv and en, or sv-SE and en-GB, but not a mix.
• The language switcher must go to the equivalent page, not to the other language's home page. Nothing loses a visitor faster than being dumped on the start page.

Never redirect automatically based on browser language or IP address. A Swede on a business trip and a foreigner living in Sweden both need to choose. Detect, suggest with a small banner if you like, but let the visitor decide and remember the choice.

Translating vs rewriting for each market

A Swedish reader and an English-speaking reader arrive with different assumptions. The Swedish page can assume the reader knows what ROT, F-skatt or a BRF is. The English page cannot, and a literal translation leaves the foreign reader either confused or condescended to. Decide page by page which of three treatments each one gets.

Machine translation: where it fails

Machine translation is good enough for a first draft and dangerous as a final one. Its errors are not typos; they are fluent sentences that say something slightly different from what you meant, and a reader who spots one stops trusting the rest of the page. Typical damage: legal terms rendered with a plausible but wrong equivalent, formal and informal address mixed in one paragraph, product names translated, idioms carried across literally, and decimal commas or currency changed in prices.

The workable routine is machine draft, then a native-speaking editor who knows your business, then a final read by someone who owns the page. That costs a fraction of translation from scratch and produces text that survives a customer's scrutiny. Publishing the raw draft with an automatic translation widget is the one option we advise against on a company site: it tells the visitor you did not think they were worth the effort.

Keeping both languages in sync

Sites do not go bilingual and then stay that way by accident. The Swedish page gets a new price, a new opening hour or a new service, and the English page keeps the old one until a customer complains. The fix is a small process, not more technology.

1. One owner for language parity, named in the content routine.
2. A content change is not done until both versions are updated or the English version is deliberately marked as not applicable.
3. A quarterly diff: list every page in each language and check the pairs still match in substance.
4. Prices, hours and contact details come from one source and are rendered into both languages, never typed twice.

When you do not need this: if fewer than a handful of your customers each year read English, a single well-written Swedish site with an English contact page is more honest than a half-maintained bilingual one. When the international share is real, the structure above is what we build into a company website launch, and a free call is the fastest way to find out which pages actually need both languages. Package prices are on the pricing page.

Frequently asked questions