Hreflang for Bilingual BM/English Websites: Doing It Correctly
How hreflang actually works for Bahasa Malaysia and English site pairs, the reciprocity rule that breaks most setups, and why it's a signal, not a directive.
What hreflang actually decides — and what it doesn't
hreflang gets described as "translation markup" often enough that the description sticks, but it isn't quite right. hreflang doesn't create a translation, verify one, or improve one. It does one narrower job: it tells Google which of several URLs is the correct language-and-region match for a given searcher, so that a Bahasa Malaysia page and an English page covering the same content reinforce each other in search results rather than being treated as duplicates competing against one another. That's the framing Google itself uses in its documentation on Localized Versions of your Pages.
Nothing about hreflang touches rankings directly. It doesn't tell Google a page is well-written, trustworthy, or worth showing higher. It answers one specific question: of these near-identical URLs, which one is correct for this language and this country?
Three ways to declare it — use one, consistently
Google documents three implementation methods. A site should commit to one of them across the board, not mix them page by page:
- HTML
<link>tags in the<head>of each page:
<link rel="alternate" hreflang="ms-MY" href="https://example.my/perkhidmatan" />
<link rel="alternate" hreflang="en-MY" href="https://example.my/en/services" />
- HTTP response headers, useful for non-HTML files such as PDFs, where there's no
<head>to put a tag in:
Link: <https://example.my/en/services>; rel="alternate"; hreflang="en-MY"
- An XML sitemap, where each URL entry lists every language and region variant of that page as a child element. This becomes genuinely worthwhile once a site has more than a handful of bilingual pages, since the annotations live in one file instead of scattered across every page's
<head>.
Mixing methods — tags on some pages, sitemap entries covering others — is a common way reciprocity quietly breaks, simply because it's easy to update one location and forget the other exists.
Getting the language and region codes right
Google's format is exact: a language code in ISO 639-1, optionally followed by a region code in ISO 3166-1 Alpha-2, joined by a hyphen, language first. For a Malaysian bilingual site, the two codes worth knowing are:
ms-MY— Bahasa Malaysia, targeted at Malaysiaen-MY— English, targeted at Malaysia
If your Bahasa Malaysia content isn't Malaysia-specific and would suit any Malay-reading searcher, ms on its own works too — the region portion is optional, not compulsory. What isn't optional is getting the order and standard right. Google's own guidance flags region codes used where a language code belongs, and non-standard region strings such as EU or UK (the correct ISO code for the United Kingdom is GB, not UK) as invalid. An invalid code isn't corrected automatically or flagged loudly — the tag is simply ignored, and the page behaves as if it had no hreflang annotation at all.
Reciprocity: the rule that breaks more setups than anything else
This is the failure Google states most bluntly: "If two pages don't both point to each other, the tags will be ignored." If your English services page links to its Bahasa Malaysia counterpart via hreflang, that Bahasa Malaysia page must link back with an hreflang entry of its own, pointing at the English URL. One-directional linking is common — a BM page gets added months after the English original, and nobody goes back to update the English page's tags to reference it — and the result isn't a partial win. Google disregards the entire pair.
This is worth auditing pair by pair, not page by page. A site with forty bilingual pages has forty reciprocal relationships to keep intact, and it only takes one URL change, one page taken offline, or one draft quietly replacing an old page to break that pair without anyone noticing.
Self-referencing: the tag people forget because it looks redundant
Every page in a language set needs hreflang entries for all of its counterparts — and for itself. The English page's hreflang block should include an entry pointing at the English page's own URL, tagged en-MY, alongside the entry pointing at the Bahasa Malaysia version. Skipping the self-reference is a common gap in hand-coded implementations, usually because it looks pointless — why would a page need to point at itself? — but Google's documentation lists it as required across all three implementation methods above, not an optional nicety.
x-default: for everyone else
x-default is a reserved hreflang value that tells Google which URL to serve a searcher whose language doesn't match any declared variant — someone searching in French, say, on a site with only Bahasa Malaysia and English versions. It's optional on a genuinely two-language site, but Google recommends including it wherever a sensible fallback page exists, such as a language-selection page or the version aimed at the widest audience.
Three specific failures worth checking for
Non-reciprocal tags. Already covered above — the fix is checking every pair individually, not assuming a site-wide implementation is symmetrical just because it was built that way once.
hreflang pointing at a noindexed or redirecting URL. If an English page's hreflang tag points to a Bahasa Malaysia URL that carries a noindex directive, sits behind a login wall, or has since been 301-redirected elsewhere, Google has nothing usable to treat as the alternate version — the annotation points at a dead end. This tends to surface after a site restructure, when URLs get consolidated or redirected and nobody circles back to update every hreflang reference that pointed at the old address.
Claiming a translation that doesn't exist. hreflang should only ever point to a genuinely separate, fully translated page — never to the same English content with a ?lang=ms parameter appended that changes nothing on the page, and never to a placeholder that reads "Bahasa Malaysia version coming soon." If the translation isn't finished, the honest approach is to leave the tag out until it is, rather than declaring an alternate that misrepresents what the page actually contains.
hreflang is a signal, not a directive
It's worth being precise about what correct hreflang implementation guarantees, because the honest answer is: nothing on its own. Google's guidance on managing multi-regional and multilingual sites groups hreflang together with several other signals it weighs when deciding which version of a page to show a given searcher — alongside things like a country-code domain and server location. hreflang is a strong, well-documented hint that, correctly implemented, works reliably in practice — but it sits alongside those other signals, not above them. Perfectly reciprocal, correctly coded hreflang does not override a genuine mismatch between a page's declared language and what's actually written on it, and it doesn't force a specific result for every searcher regardless of their own browser and location settings.
That distinction matters for expectations. Implementing hreflang correctly removes a real, common source of confusion for Google. It isn't a control you turn to influence search results directly.
Checking your own site
Google Search Console's URL Inspection tool shows what Google currently sees for one URL at a time, which is useful for spot-checking a specific page. There's no single Search Console report that flags every broken reciprocal pair across a whole site at once — auditing a bilingual site properly still means working through the pairs by hand, or with a crawler that specifically checks hreflang reciprocity.
Where JagaWeb fits
Checking hreflang implementation on a bilingual site — reciprocity, self-referencing tags, and whether the annotated URLs are actually live and indexable — is one of the eight control points in JagaWeb's Essential System Review (RM1,500, currently RM999 until 16 September 2026, for one site up to 25 pages). It's a diagnostic option worth considering, not a promise that fixing hreflang changes where you rank — no one can honestly offer that. Reach us at sales@jagaweb.my, or on WhatsApp through jagaweb.my.
Ready to verify who owns your website?
Replace uncertainty with a decision-ready ownership and access report. The fixed Ownership & Access Review is RM1,500 before SST and includes a 30-day action plan.