A multilingual website structure is the way you publish the same organisation’s content in more than one language, usually with a separate URL per language, a switcher, and metadata in that language. For Malaysian companies the common pair is English and Bahasa Malaysia. Some also add Chinese.
Machine-translated pages with no editor are still published pages. If you are not ready to maintain them, do not advertise the language.
URLs
Give each language a stable home. Typical patterns:
- A path prefix:
/ms/contactbeside/contact - A subdomain:
ms.example.com - A separate domain, when the brand truly operates that way
Pick one pattern and keep it. Mixing ?lang=ms on some pages and /ms/ on others makes links and analytics messy. The default language should have a clear URL too, not only a cookie that hides the choice.
Do not auto-redirect solely on browser language if that traps a person who deliberately opened the English URL. Offer a switch. Remember their choice if you can do it without blocking the other language.
The information architecture should match across languages: the same services, not a thinner menu in Bahasa Malaysia unless that gap is intentional and labelled.
What must be translated
- Visible navigation and body content
- The title and meta description
- Image alt text when the image is informative
- Form labels, errors, and the success message
- PDF names or the link text pointing at them, if you offer downloads
A Bahasa Malaysia page with an English title tag looks unfinished and is easy to file under the wrong language. Editors need a workflow so one language is not updated months later by accident. Publishing roles are covered in website content publishing workflow.
hreflang
hreflang annotations tell search engines which URL is the English, Malay, or Chinese version of a page, plus an x-default if you have a language chooser. Rules that matter:
- Annotate only pages that exist. A tag pointing at a 404 is worse than no tag.
- Use reciprocal links: the English page lists the Malay URL, and the Malay page lists the English URL.
- Use language codes correctly (
en,ms,zh-Hanswhen you mean simplified Chinese). - Keep the canonical URL of each page pointing at itself, not at the other language.
Adding hreflang does not create a translation. A site that only translates the homepage should only annotate the homepage cluster. Inventing alternates for every English URL will advertise pages you do not have.
Adding a second language without doubling the mess
- Choose one URL pattern and the default language
- Translate navigation, page, and metadata together
- Add a switch that stays on the equivalent page
- Annotate hreflang only for real pairs
- Assign an owner for each language’s updates
A practical example
A company publishes English at /services/networking and Bahasa Malaysia at /ms/services/rangkaian. The switcher on each page links to the other, not back to the homepage. Titles and form errors exist in both languages. There is no Chinese service page, so no Chinese hreflang is emitted for that URL. When the English page gains a new section, the Bahasa Malaysia page stays unpublished for that section until an editor translates it, rather than showing mixed paragraphs.
Key takeaways
- One URL pattern per language, with a visible switch.
- Translate the interface and the metadata, not only the article body.
- Use hreflang for pages that actually exist, in both directions.
- Give each language an editor so the versions do not drift in silence.
FAQ
Is a translate widget enough?
A widget can help a reader in a pinch. It is not a second website. You do not control the wording, the URL, or the metadata.
Should Bahasa Malaysia be the default?
Use the language your primary audience expects to read on arrival, and make the other easy to reach. The choice is editorial, not a technical default hidden in the server.
What if a page exists in only one language?
Link the switcher to that language’s homepage or hide the switch for the missing page. Do not point hreflang at a copied English page with a Malay URL.