The Multilingual Website Development Guide: URL Structure, Localization, and the Cost of Maintaining It
“We would like to add an English version.” It sounds like a few extra pages. What it actually changes is the structure of the site, the workflow around it, and your staffing for years afterwards.
The real cost of multilingual is not the first translation. It is that every subsequent update has to be done again, in every language. This guide sets out the decisions to make first: which URL structure to choose, how to handle language markup and switching, where translation ends and localization begins, whether your admin system can carry it, and how to estimate the maintenance load.
First: do you actually need a second language?
Before discussing how, confirm whether you should. A common pattern in practice is a site that gains an English version, receives almost no overseas inquiries afterwards, and continues to consume staff time indefinitely.
Three things are worth checking. Are overseas inquiries arriving now? Even a handful means the demand is real. Could you service the business if you won it? Quoting, contracting, delivery, and after-sales all have to happen in that language, with somebody able to do it. And who owns translation and review going forward? If any one of those three questions has no answer, the pragmatic move is to publish a single thorough page in the target language with contact details, watch what comes back, and decide about a full language version afterwards.
Once you have decided to proceed, every choice that follows shapes the maintenance burden for years.
The first decision: where the language versions live
The three approaches differ mainly in management burden and degree of independence.
| Approach | What it looks like | When it fits | Main burden |
|---|---|---|---|
| Subdirectory | One domain, languages separated by path | Most corporate sites, one team maintaining | Structure needs planning once volume grows |
| Subdomain | A separate hostname using a prefix | Each language owned by a different team | Certificates, deployment, and analytics configured separately |
| Separate domains | A distinct domain per market | Genuinely different companies or product lines | Highest management cost, nothing shared |
For most small and mid-sized businesses the sensible default is a subdirectory. Every language shares the foundation the domain already has, deployment, certificates, and analytics are one set of settings, and when something breaks there is only one place to look.
Legitimate reasons to choose a subdomain or a separate domain are usually organizational: each market has its own marketing team, the product lines differ, or regulation requires data and operations to be kept apart. “It looks more international” is not a reason.
One related note: if the language structure changes on an existing site, the URL changes bring redirects and re-indexing with them. Read the Website Redesign SEO Checklist before deciding whether to combine this with a redesign.
Language markup and switching: two things to get right
Language markup (hreflang) is a set of annotations inside the page telling search engines that equivalent versions of this page exist in other languages. Its purpose is to stop different language versions being treated as duplicate content, and to make it more likely that users land on the version suited to them.
Three principles govern the implementation. Pairings must be reciprocal — if A points to B, B has to point back to A. Each set must include itself — the current page belongs in its own group of equivalents. Only mark pages that genuinely exist — pointing at a URL that is missing or redirects invalidates the markup. For syntax and current recommendations, follow the search engine’s own documentation rather than copying older examples found online.
The language switcher is for people. A few approaches that hold up in practice:
- Switching should land on the equivalent page, not bounce back to the homepage every time
- Label each option in its own language (write English on the English option), and avoid flag icons — a flag represents a country, not a language
- Do not force automatic redirection. Switching language based on browser settings or location guesses wrong often, and leaves users unable to find their way back. If you use detection at all, make it a suggestion rather than a redirect
- Remember the choice the user made instead of asking again on every visit
Translation is not localization
Translation handles sentences. Localization handles whether the content makes sense where it lands. The difference shows up in several places:
Terminology and naming. The conventional term for the same industry concept can differ completely between markets. Build a glossary for brand names, product names, and job titles up front, so the same word does not appear three different ways across your pages.
Formats. Dates, numbers, addresses, phone numbers, and units of measurement are written differently from place to place, and these are usually the details that give a translation away.
Whether the content itself should change. Case studies, testimonials, partners, and regulatory notes do not transfer equally between markets. Some content should be swapped, some should be dropped, rather than translated word for word.
Compliance and claims. Rules on advertising claims and disclosure obligations vary by jurisdiction, and the wording used at home cannot simply be reused. For the rules that apply in Taiwan, see the Taiwan Word-of-Mouth Marketing Compliance Guide; for the localization gaps foreign brands hit when entering the Taiwanese market, see How Foreign Brands Build Word of Mouth in Taiwan.
Layouts have to stretch. The same sentence varies considerably in length between languages. Buttons and navigation need to accommodate longer strings, and that should be tested during the design phase.
Can the admin system carry it?
Multilingual support is one of the decisive questions in choosing a CMS. When evaluating, ask the vendor to demonstrate these things on a live system:
- When you create an article, how the language versions are created and linked
- What the public site does when a language has not been translated yet (hide it, fall back to the primary language, or show a blank)
- Whether interface strings such as navigation, button labels, and form error messages can be maintained by an editor
- Whether images and files can vary by language (images containing text usually need a version per language)
- Whether there is a report showing which pages are still untranslated
Different categories of admin system vary widely here; for the full comparison, see How to Choose a CMS. One warning: if interface strings are hard-coded into the program, every additional language means a code change. Settle that point before development begins.
Estimating the maintenance cost
The cost structure of a multilingual site differs from a single-language one, and it helps to split it into three parts.
Build phase: architecture, language switching, markup configuration, and the first batch of translation and review.
Ongoing: translation, review, publishing, and cross-language consistency checks on every content addition or change. This is the part most often left out of the estimate, because it is not a one-time cost.
Functional changes: when a feature is added, the interface text, notification emails, and error messages have to be completed in every language.
Two practical ways to control the cost. Tier the content: split it into “must stay in sync” (main service pages, contact details, terms) and “primary language first” (blog posts, announcements), and stop insisting that everything match. Phase the rollout: publish complete translations of the core pages, confirm that overseas inquiries genuinely arrive, and expand from there rather than translating the entire site at once. For the underlying cost factors, read this alongside How Website Costs Are Calculated.
Four common mistakes
One: publishing machine translation directly. Unreviewed translation produces errors in terminology and tone that damage professional credibility.
Two: translating only half the site. The homepage is in English, the page behind it is not, and the visitor leaves. Better to do fewer pages completely.
Three: using flags for languages. One language can span many regions and one region can hold many languages; sooner or later flags offend somebody.
Four: ignoring everything that is not page content. Notification emails sent by the system, form validation messages, error pages, and the filenames of downloads frequently exist in one language only, and users tend to find them after launch.
The technical groundwork to get right during development — URL structure, titles, indexing settings — is not expanded on here; for the full list, see the Technical SEO Checklist. If the second language is being added as part of a redesign, the process is covered in How a Website Redesign Actually Runs.
Multilingual sites usually succeed or fail on the maintenance process rather than the translation quality. Before committing, confirm who translates, who reviews, and how quickly it has to go live on each update. A project stands up once those three questions have answers.
If you are weighing up an English version or another language, talk to NETVANA about your multilingual requirements. We confirm the real overseas demand and the people available to maintain it before discussing architecture; for what each service includes and delivers, see the software services overview.
Further reading: your CMS choice directly determines how hard multilingual maintenance is, so see How to Choose a CMS; the technical fundamentals are collected in the Technical SEO Checklist; for localization gaps when entering a new market, see How Foreign Brands Build Word of Mouth in Taiwan; for producing content on an ongoing basis, see How to Run a Brand Blog; and for budgeting, see How Website Costs Are Calculated.
