Glass globe connected to floating browser panels, illustrating multilingual website architecture

A multilingual website needs more than translated menus. A practical structure gives each language a stable address, connects equivalent pages, and names the people responsible for keeping content accurate. This guide is for teams planning an English, Japanese, Korean or Spanish company website and a clear route from search to enquiry.

1. Map the customer journey before choosing URLs

Start with a short inventory: home, services, projects, articles, company information and contact. For each page, record its purpose, primary language, target audience and next action. Do not assume every article needs every language on day one. Translate the pages that help a customer understand the service and make a useful enquiry first.

For example, a Japanese service page may need a locally reviewed explanation of project communication, while an English technical article may remain English until a reviewer is available. Keep untranslated content out of completed-translation groups.

2. Choose a consistent language URL structure

For one company managing one domain, language directories such as /en/ and /ja/ are a practical starting point. Google recommends distinct URLs for different language versions and cautions against automatically redirecting visitors based on a presumed language. Provide a visible language selector instead. Subdirectories also let a team maintain one host. See Google’s multilingual site guidance.

Use a routing sheet before development. An illustrative pair might be https://example.com/en/services/web-development/ and https://example.com/ja/services/web-development/. These are examples, not live project addresses. Record the final URL, page owner and any old address that needs a redirect. Avoid changing published slugs just to add another keyword.

3. Connect genuine translations with hreflang

Hreflang identifies equivalent language or regional versions. Google asks for fully qualified URLs, a reference to the current version, and reciprocal links between alternatives. HTML, HTTP headers and XML sitemaps are supported approaches; choose the one your team can maintain reliably. Do not link an English article to an unrelated Japanese homepage as its translation. Google’s localized-version documentation explains the implementation rules.

If the two example service pages are complete translations, both pages can include this same set in their HTML head:

<link rel="alternate" hreflang="en" href="https://example.com/en/services/web-development/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/web-development/" />

Do not paste this example into production unchanged. Replace the URLs with your published equivalents and inspect the rendered head. Hreflang describes relationships; it does not guarantee indexing or a search position.

4. Assign content ownership, not just translation work

A small ownership register prevents a common failure: the source page changes while other languages retain an old promise or broken contact route. For every page group, assign these responsibilities:

  • Business owner: approves service scope, supported markets and the enquiry process.
  • Language reviewer: checks terminology, tone, examples and whether the answer makes sense to that audience.
  • Web editor: maintains the title, summary, links, image description and publication status.
  • Developer: verifies routing, language associations, redirects and form behavior.

One person can hold multiple roles. The important detail is a named owner and a review trigger. A change to service scope, an address, a form or a required integration should reopen the relevant language versions for review. Machine translation can assist drafting, but publication should follow a review of the actual page and its customer journey.

5. Use this launch acceptance checklist

  1. Open every final URL without an admin session. Confirm the intended page loads, with one clear main heading and no draft-only content.
  2. Review the full language experience. Check headings, navigation, validation messages, image descriptions and contact instructions.
  3. Inspect metadata. Confirm the title and description match the page, its canonical points to the intended address, and no staging noindex remains.
  4. Test translation pairs. Follow the selector in both directions and compare the actual content. Check hreflang targets for missing pages.
  5. Check discovery routes. Link the page from its relevant service or article and confirm the published URL appears in the intended sitemap.
  6. Test mobile enquiry flow. Check readable text, usable fields, consent and file-upload instructions. Verify delivery separately from a button click.
  7. Record outcomes. Track Search Console impressions and clicks separately from contact interactions and enquiries actually received.

Frequently asked questions

Should we launch four languages at once?

Only if the team can review and maintain all four. A smaller set of complete service and contact pages is easier to operate than a large set with unfinished translations. Define the first release around customer needs and available reviewers.

Do all language versions need identical wording?

No. Reviewers can adapt examples and terminology while preserving the page’s purpose and factual service scope. Keep unrelated articles in separate groups rather than forcing them into a translation relationship.

Can one contact form serve several languages?

Yes, if the interface is localized and the enquiry carries enough context for follow-up. Include the selected service and preferred communication language. Tell visitors what happens after submission and avoid collecting information the team does not need.

How do we know the new structure is working?

First verify accessibility and correct routing. Then monitor search discovery and the enquiries received. Publishing, sitemap discovery, indexing, search clicks and qualified enquiries are different stages; record them separately before judging a business outcome.

Plan your multilingual website

If you are changing an existing site, read our website redesign or new-build decision guide before choosing the scope. For implementation, explore our website development service.

Send your current website, required languages, priority pages and who will review each language to info.alldaigou@gmail.com. pulainaiwork can discuss the structure, development and enquiry flow with your team.