If you run a website that serves audiences in more than one language or country, you need to understand what is hreflang and how it works. Not in a vague, theoretical way. In a “this is exactly how you implement it without breaking your site” way.
I’m Jim Ng, and at Best SEO Singapore, we’ve fixed hreflang implementations for e-commerce brands, SaaS companies, and regional businesses across Southeast Asia. The mistakes we see are almost always the same. And they’re almost always avoidable.
This guide will walk you through hreflang from the ground up. We’ll cover what the tag actually does, how to construct it properly, where to place it, the common errors that tank your international rankings, and how to audit your implementation. Whether you’re a business owner trying to understand what your developer built, or a marketer implementing this yourself, you’ll walk away with something you can actually use.
What Hreflang Actually Does (And What It Doesn’t)
Hreflang is an HTML attribute that tells Google which language and regional version of a page to show to which users. That’s it. It’s a signal, not a directive. Google uses it as a strong hint, but it’s not a guarantee.
Here’s the scenario where it matters most. You have an English page for Singapore (with SGD pricing and local shipping info) and another English page for Australia (with AUD pricing and different shipping). Without hreflang, Google sees two very similar pages in the same language and has to guess which one to show. It often guesses wrong.
Hreflang solves this by explicitly telling Google: “These two pages are alternate versions of each other. Show this one to users in Singapore, and that one to users in Australia.”
What Hreflang Does Not Do
Let me clear up a few misconceptions I encounter regularly during SEO audits.
Hreflang does not automatically redirect users. If a Singaporean user lands on your Australian page through a direct link, hreflang won’t redirect them. It only affects which version appears in search results.
Hreflang does not translate your content. You still need to create the actual translated or localised pages. The tag just connects them.
Hreflang does not work on Bing. Bing uses the “content-language” meta tag and language settings in Bing Webmaster Tools instead. If Bing traffic matters to your business, you need a separate approach.
Hreflang does not replace canonical tags. These serve different purposes and often work together. More on this later, because getting this relationship wrong is one of the most common technical mistakes we see.
Why Hreflang Matters for Singapore-Based Businesses
Singapore is a multilingual market by default. You’ve got English, Mandarin, Malay, and Tamil as official languages. Many Singapore businesses also serve Malaysia, Indonesia, Hong Kong, and Australia. This creates a perfect storm for hreflang requirements.
Consider a typical Singapore e-commerce site. You might have:
- An English page for Singapore with GST-inclusive pricing in SGD
- An English page for Malaysia with MYR pricing and different shipping options
- A Mandarin page for Singapore targeting Chinese-speaking locals
- A Mandarin page for Hong Kong with HKD pricing
Without hreflang, Google might show your Malaysia page to Singapore users searching in English. Or your Hong Kong Mandarin page to Mandarin-speaking users in Singapore. Either way, the user sees wrong pricing, wrong shipping info, and bounces. Your bounce rate climbs, your conversion rate drops, and Google takes note.
We worked with a Singapore-based fashion retailer that had separate storefronts for SG, MY, and AU. Before implementing hreflang, 38% of their organic traffic from Singapore was landing on the Malaysian version of their pages. After correct hreflang implementation, that cross-contamination dropped to under 4% within six weeks, and their Singapore organic revenue increased by 23%.
The Duplicate Content Problem
This is the other big reason hreflang matters. When you have pages in the same language targeting different countries, Google can interpret them as duplicates. It then picks one version to index and suppresses the others.
For a Singapore business with an en-SG and en-MY version of the same product page, Google might decide the MY version is the “canonical” one and stop showing the SG version entirely. You lose visibility in your home market.
Hreflang tells Google these aren’t duplicates. They’re intentional regional variations. This preserves the indexing and ranking potential of every version.
How to Construct a Hreflang Tag Correctly
Let’s get into the actual syntax. A hreflang tag looks like this:
<link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/product-page" />
Every part of this tag matters, and getting any part wrong can invalidate the entire implementation.
Breaking Down Each Component
rel=”alternate” tells the browser and search engine that the linked URL is an alternative version of the current page. This is standard HTML for defining document relationships.
hreflang=”en-SG” is the core attribute. It contains two parts separated by a hyphen:
The language code comes first. This must be a valid ISO 639-1 two-letter code. Common ones you’ll use: en (English), zh (Chinese), ms (Malay), ta (Tamil), ja (Japanese), ko (Korean), id (Indonesian).
The region code is optional and comes second. This must be a valid ISO 3166-1 Alpha-2 country code. Examples: SG (Singapore), MY (Malaysia), AU (Australia), US (United States), GB (Great Britain), HK (Hong Kong).
href=”…” must be the fully qualified, absolute URL of the alternate page. Not a relative path. Not a URL without the protocol. The full thing, including https://.
When to Use Language Only vs. Language Plus Region
Use language-only codes (hreflang="en") when your content serves all speakers of that language regardless of location. If you have one English page that works for everyone globally, en is sufficient.
Use language-plus-region codes (hreflang="en-SG") when you have country-specific variations. Different pricing, different legal disclaimers (like MAS regulations for financial products in Singapore), different product availability, or different spelling conventions all warrant region-specific tags.
Here’s a rule that trips people up: you cannot specify a region without a language. hreflang="SG" is invalid. It must be hreflang="en-SG" or hreflang="zh-SG" or whatever the language is.
The x-default Tag
There’s one special value you need to know about: x-default. This tells Google which page to show when no other hreflang tag matches the user’s language or region.
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/product-page" />
Think of x-default as your fallback. If a user in Brazil searches and you don’t have a Portuguese version, the x-default page is what Google will consider showing. Typically, you’d set this to your main English page or a language-selection landing page.
Every hreflang implementation should include an x-default. Skipping it is like building a hawker stall with no signboard. People who don’t already know what you serve will just walk past.
Three Ways to Implement Hreflang Tags
You have three options for where to place your hreflang declarations. Each has trade-offs, and the right choice depends on your site’s size and technical setup.
Option 1: HTML Head Tags
Place <link> elements in the <head> section of each page. This is the most common method for small to medium sites.
<head>
<link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/page" />
<link rel="alternate" hreflang="en-MY" href="https://www.example.com/my/page" />
<link rel="alternate" hreflang="zh-SG" href="https://www.example.com/sg/zh/page" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/page" />
</head>Pros: Easy to understand, easy to audit by viewing page source, works well for sites under 1,000 pages.
Cons: Adds to your HTML page size. If you have 15 language/region versions, that’s 15 extra link tags on every page. For large sites with thousands of pages, this bloats your HTML significantly and slows down page load times.
Option 2: XML Sitemap
Declare hreflang annotations within your XML sitemap using the xhtml:link element. This is the preferred method for large sites.
<url>
<loc>https://www.example.com/sg/page</loc>
<xhtml:link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/page" />
<xhtml:link rel="alternate" hreflang="en-MY" href="https://www.example.com/my/page" />
<xhtml:link rel="alternate" hreflang="zh-SG" href="https://www.example.com/sg/zh/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/en/page" />
</url>Pros: Doesn’t add weight to your HTML. Easier to manage programmatically. Google specifically recommends this for large sites.
Cons: Harder to audit manually. You’re relying on Google to crawl and process your sitemap regularly. If your sitemap has errors or isn’t submitted properly in Google Search Console, the annotations won’t work.
Option 3: HTTP Headers
Send hreflang information via HTTP response headers. This is the only option for non-HTML files like PDFs.
Link: <https://www.example.com/sg/page>; rel="alternate"; hreflang="en-SG", <https://www.example.com/my/page>; rel="alternate"; hreflang="en-MY"
Pros: Works for PDFs and other non-HTML documents. Doesn’t require modifying page content.
Cons: Harder to implement and maintain. Requires server-level configuration. Most development teams are less familiar with this method, which increases the risk of errors.
Which Method Should You Choose?
For most Singapore businesses with under 5,000 pages, HTML head tags work fine. If you’re running a large e-commerce site with tens of thousands of product pages across multiple regions, go with the XML sitemap method. Only use HTTP headers if you need to annotate non-HTML resources.
Pick one method and stick with it. Do not mix methods for the same set of pages. Google can get confused when it finds hreflang declarations in both the HTML head and the sitemap for the same URL, especially if they contain even slight differences.
The Reciprocal Rule: The Most Violated Requirement
This is where most hreflang implementations fall apart. Every hreflang annotation must be reciprocal. If Page A says “Page B is my en-MY alternate,” then Page B must also say “Page A is my en-SG alternate.”
If the confirmation is missing from either side, Google ignores the entire annotation for that pair. It’s like a handshake. Both parties need to participate.
A Practical Example
Let’s say you have three pages:
https://www.example.com/sg/shoes(English, Singapore)https://www.example.com/my/shoes(English, Malaysia)https://www.example.com/sg/zh/shoes(Chinese, Singapore)
Each of these three pages must contain hreflang tags pointing to all three pages, including itself. Yes, every page must include a self-referencing hreflang tag. This is another requirement that gets missed constantly.
Here’s what the complete set looks like on the Singapore English page:
<link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/shoes" />
<link rel="alternate" hreflang="en-MY" href="https://www.example.com/my/shoes" />
<link rel="alternate" hreflang="zh-SG" href="https://www.example.com/sg/zh/shoes" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/sg/shoes" />The Malaysia English page and the Singapore Chinese page must each contain the exact same set of four tags. If any one of the three pages is missing a tag, or has a different URL in one of the tags, the whole cluster can break.
Why This Gets Messy at Scale
If you have 10 language/region versions, every page needs 10 hreflang tags (plus x-default, so 11). If you have 5,000 pages, that’s 55,000 individual hreflang annotations that all need to be perfectly reciprocal. One broken link, one typo, one page that got deleted without updating the others, and you’ve got orphaned annotations that Google ignores.
This is why we strongly recommend automating hreflang generation for any site with more than a handful of regional versions. Manual management breaks down fast.
Hreflang and Canonical Tags: How They Work Together
This is one of the most misunderstood relationships in technical SEO, and getting it wrong can completely undermine your hreflang implementation.
The Golden Rule
Every page referenced in a hreflang tag must have a canonical tag that points to itself. If your en-SG page has a canonical tag pointing to your en-US page, Google will ignore the hreflang annotation for en-SG entirely.
Here’s why this makes sense. The canonical tag tells Google “this is the definitive version of this content.” If your en-SG page says “actually, the en-US page is the real version of me,” then Google has no reason to keep the en-SG page in its index. And if it’s not in the index, hreflang can’t serve it to Singapore users.
The Correct Setup
On your en-SG page:
<link rel="canonical" href="https://www.example.com/sg/page" />
<link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/page" />
<link rel="alternate" hreflang="en-MY" href="https://www.example.com/my/page" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/page" />On your en-MY page:
<link rel="canonical" href="https://www.example.com/my/page" />
<link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/page" />
<link rel="alternate" hreflang="en-MY" href="https://www.example.com/my/page" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/page" />Each page canonicalises to itself. Each page references all alternates. Clean and reciprocal.
A Common Mistake We See in Singapore
Many CMS platforms and e-commerce solutions default to setting canonical tags that point all regional pages back to a single “master” version. Shopify, for example, has historically handled this poorly for multi-region stores. If your platform does this, you need to override it before your hreflang tags will have any effect.
Common Hreflang Mistakes (And How to Fix Them)
After auditing hundreds of international sites, here are the errors we encounter most frequently. Check your own implementation against this list.
Mistake 1: Missing Self-Referencing Tags
Every page must include a hreflang tag that points to itself. If your en-SG page only references en-MY and zh-SG but doesn’t include a tag for en-SG, Google may not process any of the annotations correctly.
Fix: Add a self-referencing hreflang tag to every page in the cluster.
Mistake 2: Non-Reciprocal Annotations
Page A references Page B, but Page B doesn’t reference Page A. This is the single most common hreflang error in the wild. It often happens when one regional team updates their pages without coordinating with other teams.
Fix: Audit all hreflang clusters to ensure every page in the group references every other page. Use a crawling tool like Screaming Frog or Sitebulb to automate this check.
Mistake 3: Using Wrong ISO Codes
We’ve seen hreflang="uk" (which is the code for Ukrainian, not United Kingdom), hreflang="en-UK" (should be en-GB), and hreflang="zh-CN" when the content was actually Traditional Chinese for Taiwan (should be zh-TW).
Fix: Double-check every language code against the ISO 639-1 list and every country code against the ISO 3166-1 Alpha-2 list. Don’t guess. Look them up.
Mistake 4: Using Relative URLs
The href value must be an absolute URL starting with https://. Using /sg/page instead of https://www.example.com/sg/page will cause Google to ignore the tag.
Fix: Always use fully qualified URLs. Include the protocol and domain.
Mistake 5: Pointing to Non-200 Pages
If a hreflang tag points to a URL that returns a 404, 301, or any status other than 200, Google ignores it. This happens frequently when pages are deleted or URLs are restructured without updating the hreflang annotations.
Fix: Regularly crawl your hreflang URLs and verify they all return 200 status codes. Set up monitoring to catch new issues quickly.
Mistake 6: Conflicting Canonical and Hreflang Signals
As discussed above, if a page’s canonical tag points to a different URL than its own, the hreflang annotation for that page becomes useless.
Fix: Ensure every page in a hreflang cluster has a self-referencing canonical tag.
Mistake 7: Mixing Implementation Methods
Some sites declare hreflang in both the HTML head and the XML sitemap. If there are any discrepancies between the two, Google may get confused and ignore both.
Fix: Choose one method and use it consistently across your entire site.
How to Audit Your Hreflang Implementation
You’ve set up your hreflang tags. How do you know they’re actually working? Here’s the audit process we use at Best SEO Singapore.
Step 1: Crawl Your Site
Use Screaming Frog SEO Spider (the paid version handles hreflang analysis well) or Sitebulb. Configure the crawler to extract hreflang tags from the HTML head, XML sitemaps, or HTTP headers, depending on your implementation method.
Export the full list of hreflang annotations. You should see every URL paired with every alternate URL it references, along with the language/region codes.
Step 2: Check for Reciprocity
For every pair of URLs connected by hreflang, verify the relationship goes both ways. Screaming Frog has a built-in hreflang audit that flags non-reciprocal annotations. If you’re doing this manually in a spreadsheet, create a matrix where rows and columns are your URLs, and fill in the hreflang codes. Every cell should have a matching cell in the transposed position.
Step 3: Validate ISO Codes
Export all unique hreflang values from your crawl. Check each one against the ISO 639-1 (language) and ISO 3166-1 Alpha-2 (country) standards. Flag any that don’t match a valid code.
Step 4: Cross-Reference with Canonical Tags
For every URL that appears in a hreflang annotation, check that its canonical tag points to itself. If you find pages where the canonical points elsewhere, those hreflang annotations are effectively dead.
Step 5: Check HTTP Status Codes
Every URL referenced in a hreflang tag should return a 200 status code. Run a bulk status check on all hreflang URLs. Flag any 3xx redirects, 4xx errors, or 5xx server errors.
Step 6: Verify in Google Search Console
Go to Google Search Console and check the International Targeting report (under Legacy tools and reports) and the Page Indexing report. Look for hreflang-related errors. Google will tell you about missing return tags, unknown language codes, and other issues it’s detected.
Run this audit quarterly at minimum. For sites that update content frequently or add new regional versions, monthly audits are better. Hreflang implementations degrade over time as pages are added, removed, and restructured.
Hreflang for Specific Singapore Scenarios
Let me walk through some real-world scenarios that are particularly relevant if you’re operating from Singapore.
Scenario 1: Bilingual Singapore Site (English + Chinese)
You have a corporate site with English and Mandarin versions, both targeting Singapore. Your URL structure might be:
https://www.example.com.sg/about(English)https://www.example.com.sg/zh/about(Chinese)
Hreflang tags on the English page:
<link rel="alternate" hreflang="en-SG" href="https://www.example.com.sg/about" />
<link rel="alternate" hreflang="zh-SG" href="https://www.example.com.sg/zh/about" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com.sg/about" />The same set appears on the Chinese page. This ensures that when someone in Singapore searches in Chinese, Google knows to show the /zh/about version.
Scenario 2: Singapore Business Expanding to Malaysia and Indonesia
This is extremely common. You’re a Singapore company that now serves MY and ID markets. Your site might have:
https://www.example.com/sg/(English, Singapore)https://www.example.com/my/(English, Malaysia)https://www.example.com/id/(Bahasa Indonesia, Indonesia)
Note that English in Singapore and English in Malaysia are the same language but different regions. The Indonesia version is a different language entirely. Your hreflang tags need to reflect both distinctions.
On the SG page:
<link rel="alternate" hreflang="en-SG" href="https://www.example.com/sg/" />
<link rel="alternate" hreflang="en-MY" href="https://www.example.com/my/" />
<link rel="alternate" hreflang="id-ID" href="https://www.example.com/id/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/sg/" />The same set goes on the MY and ID pages. Reciprocal, self-referencing, complete.
Scenario 3: Financial Services with MAS Compliance Considerations
If you’re in financial services, you likely have Singapore-specific pages with MAS regulatory disclaimers that differ from what you show users in other countries. Your Singapore page might include specific risk warnings required by the Monetary Authority of Singapore, while your Hong Kong page has SFC-mandated disclosures.
These pages absolutely need hreflang tags, because showing the wrong regulatory content to the wrong audience isn’t just a UX problem. It’s a compliance risk. Hreflang helps ensure that Singapore users see Singapore-compliant content in search results.
Scenario 4: Using ccTLDs vs. Subdirectories
Some Singapore businesses use country-code top-level domains: example.com.sg, example.com.my, example.co.id. Others use subdirectories on a single domain: example.com/sg/, example.com/my/.
Hreflang works with both structures. The implementation is identical. The only difference is the URLs you put in the href attributes. However, there’s an important SEO consideration: with ccTLDs, each domain builds its own authority independently. With subdirectories, all regional versions benefit from the single domain’s overall authority.
For most Singapore SMEs, we recommend the subdirectory approach. It’s simpler to manage, consolidates your backlink equity, and makes hreflang implementation more straightforward since everything lives on one domain.
Advanced Hreflang Considerations
Handling Simplified vs. Traditional Chinese
This comes up constantly in the Singapore and Southeast Asian context. Simplified Chinese (used in mainland China and Singapore) and Traditional Chinese (used in Taiwan and Hong Kong) are different enough that users strongly prefer the correct variant.
There’s no separate ISO 639-1 code for Simplified vs. Traditional Chinese. Both use zh. You differentiate them using the region code:
zh-SGorzh-CNfor Simplified Chinesezh-TWorzh-HKfor Traditional Chinese
If you have a generic Simplified Chinese version not tied to a specific country, you can use the script subtag: zh-Hans for Simplified, zh-Hant for Traditional. Google supports these BCP 47 language tags, though the language-region format is more commonly used and better tested.
Pages That Don’t Have Equivalents in Every Language
Not every page on your site will have a version in every language. Maybe your blog is only in English, but your product pages exist in English and Chinese. That’s fine. You only add hreflang tags to pages that actually have alternate versions.
Don’t create hreflang annotations pointing to your homepage as a fallback for pages that don’t exist in other languages. That sends confusing signals to Google. If a page only exists in one language, it simply doesn’t need hreflang tags.
Hreflang for Paginated Content
If you have paginated category pages (page 1, page 2, page 3), each paginated page should have hreflang tags pointing to the corresponding paginated page in other languages. Page 2 of your English category should point to Page 2 of your Chinese category, not Page 1.
This is a detail that gets overlooked frequently. The result is that Google sees mismatched content across your hreflang annotations, which weakens the signal.
Hreflang and JavaScript-Rendered Content
If your site renders hreflang tags via JavaScript (common with React, Vue, or Angular frameworks), be aware that Google needs to render the JavaScript to discover the tags. This adds a delay. Google’s rendering queue can take days or even weeks to process JavaScript-rendered content.
For hreflang tags specifically, we recommend server-side rendering or implementing them via XML sitemap instead. You want Google to discover these signals immediately, not after a rendering delay.
Tools for Managing Hreflang
Here are the tools we use and recommend for hreflang implementation and monitoring.
For Implementation
Aleyda Solis’ Hreflang Tag Generator (free): Excellent for generating correct hreflang tag sets for small numbers of pages. You input your URLs and language/region codes, and it outputs the complete tag sets with proper reciprocal references.
WordPress plugins: If you’re on WordPress, WPML and Polylang both handle hreflang generation automatically when you link translated pages. Rank Math and Yoast SEO also have hreflang features, though they’re less robust for complex multi-region setups.
Custom scripts: For large sites, we typically build custom scripts that generate hreflang annotations from a database of URL mappings. This is fed into the XML sitemap generator.