Vietnamese Hreflang Guide for Multilingual Websites

Last reviewed: 4 October 2026

Short answer

Use hreflang to describe equivalent pages for different languages or regions. Choose vi for Vietnamese without a regional restriction, or vi-VN when the content specifically targets Vietnam. Build page pairs from the content inventory, keep canonical preferences coherent, and test the deployed annotations. A language annotation does not translate the page, redirect visitors or guarantee a search ranking.

Key takeaways

Pair equivalent content, not whichever translated page is available.
Separate language, region, currency and customer location.
Generate annotations from one maintained page inventory.
Treat canonical preferences as a separate decision.
Inspect output and destinations after publication.
Keep a manual language switch available for visitors.

Should Vietnamese pages use vi or vi-VN?

Choose the tag according to the audience and content, not the company's address. vi identifies Vietnamese; adding VN narrows the language tag to the Vietnam region. W3C's language-tag guidance recommends using only the subtags needed for the distinction being made.[1]

A Vietnamese-language technical guide can help readers in several countries. A Vietnamese offer with delivery areas and conditions specific to Vietnam may justify regional targeting. Write the audience decision down before choosing the code. Do not infer that every Vietnamese-speaking visitor wants the same currency, delivery address or commercial terms.

Review the content as well as the metadata. If two regional pages have different policies, ensure those policies are visible and maintained. If the content is genuinely the same, creating more regional URLs adds review work without automatically adding reader value. This is a content-governance decision before it is a tag-generation task.

What makes two pages valid counterparts?

Counterparts should answer substantially the same task for their intended audiences. Wording, examples and approved regional details may differ. Maintain a topic identifier that links the versions without relying only on a matching URL suffix.

For example, a software-localization service page should pair with the equivalent service page. It should not pair with the other language's homepage or contact form. A guide about quotation inputs should pair with a guide about the same inputs, even when the localized headline uses different words.

Use the following original inventory rubric before implementation. It is a planning tool, not a report of faults found on a client's site.

Inventory item	Required decision	Review evidence
Topic identity	Do the pages answer the same task?	Content outline for both versions
Language	What language is the main content?	Reviewed body text
Region	Are terms limited to a particular region?	Approved audience and policy brief
Preferred URL	Which stable URL should be used?	Route and canonical inventory
Availability	Is the counterpart published and accessible?	Destination response and page check
Ownership	Who updates both versions?	Named publishing responsibility

Do not manufacture a counterpart for a page that has not been translated. Record the gap and plan the work. A smaller accurate inventory is easier to maintain than a larger set of misleading matches.

How should reciprocal annotations be generated?

Google's guidance calls for each version to include itself and the other versions, with fully qualified URLs and return links.[2] For a small bilingual site, generating the same alternate set from a shared inventory is a practical way to avoid one-sided changes.

Consider this illustrative HTML fragment for a Vietnamese service page. Place it in a well-formed document head; the canonical is specific to that page. The example describes a proposed pattern and is not a claim that every page currently uses this exact fragment.

<link rel="canonical" href="https://localizezone.com/vi/services/website-localization/">
<link rel="alternate" hreflang="en" href="https://localizezone.com/services/website-localization/">
<link rel="alternate" hreflang="vi" href="https://localizezone.com/vi/services/website-localization/">

The English counterpart would retain the same two alternates but use its own preferred English canonical URL. Maintain the pair together when a slug changes. Do not update only the new page and leave the other version naming the retired route.

A route table can drive the page templates and the language switcher. Reviewers should still compare the actual content, because a perfectly symmetrical table can pair two unrelated pages. Syntax and semantic correctness are separate checks.

When does x-default make sense?

Use x-default for a deliberate fallback when no listed language or region matches. Google's introduction identifies it for international landing pages, including language selectors.[3] Choose a destination that remains useful to someone whose preferred language is not represented.

If the product intentionally uses English as the fallback for a particular topic, the English counterpart can be the fallback destination. If there is a neutral language-selection page, it may be appropriate instead. Do not add a fallback just to increase the number of tags.

Test the experience manually. Does the fallback explain where the visitor is and offer a usable language choice? Does it unexpectedly send an article reader to an unrelated homepage? Does it force a location assumption that the visitor cannot change? These are usability questions the tag itself cannot answer.

How does canonicalization differ from hreflang?

Canonicalization states a preferred representative URL among duplicate or very similar pages; language annotations describe localized counterparts. Google's canonical guidance recommends a canonical in the same language when using hreflang.[4] Do not automatically point every Vietnamese page's canonical at the English version.

For the illustrative pair above, each published translation has its own preferred URL. Track any duplicate query-string, preview or legacy routes separately. The canonical decision for those duplicates should not erase the intended relationship between the English and Vietnamese content.

Review signals together. Navigation, the sitemap and generated metadata should not each name a different preferred route. Check production output rather than trusting a CMS field: a template, cache or deployment transform can change the values that actually reach the visitor.

If a page is removed, decide what should happen to that page and its pair. A redirect can help a visitor reach a replacement, but an unrelated replacement may no longer be an equivalent language version. Update the inventory after the content decision, not before.

Which implementation method should the team choose?

Google documents HTML annotations, HTTP response headers and XML sitemaps as equivalent methods.[2] Select a method the publishing system can generate and the team can verify. Maintaining multiple methods requires an explicit plan to keep them consistent.

Method	Practical use	Main review task
HTML head	Page templates controlled by the site build	Inspect generated head and destination pairs
HTTP Link header	Responses including non-HTML documents	Inspect actual response headers
XML sitemap	Central inventory generated by publishing	Parse entries and compare with routes

An HTTP header for the same bilingual pair could look like this:

Link: <https://localizezone.com/services/website-localization/>; rel="alternate"; hreflang="en", <https://localizezone.com/vi/services/website-localization/>; rel="alternate"; hreflang="vi"

This is an example of response metadata, not text to place inside the visible page. Check the response for both counterparts if this is the chosen method. Be careful when infrastructure adds its own Link headers; do not overwrite other necessary response metadata by blindly replacing the whole header.

For a sitemap approach, the following small example lists both routes and the same language set. Namespace values are XML identifiers, not outbound reader links.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://localizezone.com/services/website-localization/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://localizezone.com/services/website-localization/" />
    <xhtml:link rel="alternate" hreflang="vi" href="https://localizezone.com/vi/services/website-localization/" />
  </url>
  <url>
    <loc>https://localizezone.com/vi/services/website-localization/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://localizezone.com/services/website-localization/" />
    <xhtml:link rel="alternate" hreflang="vi" href="https://localizezone.com/vi/services/website-localization/" />
  </url>
</urlset>

What mistakes should reviewers look for?

Look for mismatched content, stale routes and conflicting generation sources before focusing on tag counts. The most useful defect report includes the affected URL, the observed value, the intended counterpart and a reproducible check.

Common review scenarios include an article mapped to a homepage, a missing return annotation, a tag pointing at an unpublished draft, a stale URL after renaming, or two unrelated pages assigned the same topic identifier. These are hypothetical failure patterns for testing, not statistics about how frequently they occur.

Check regional intent as well. A Vietnam-specific offer labeled as generic Vietnamese might omit a needed explanation of its limits; a general Vietnamese guide marked region-specific may reflect an undocumented audience assumption. Resolve the editorial intent with the owner rather than changing tags solely to make a validator quiet.

Also inspect language switching. The switch should preserve the task where a counterpart exists. The technical annotations can be correct while the visitor-facing switch still drops the reader onto a homepage. Review both systems from the same inventory.

What is a practical testing sequence?

Test the inventory, generated output and deployed destinations as separate layers. Each layer catches a different kind of problem. Save the reviewed release identifier so later changes can be compared with a known state.

Use this eight-step sequence: confirm topic pairs; review audience codes; parse generated metadata; compare return sets; inspect canonical preferences; request each destination; test the language switch; repeat checks after publishing. Include a changed slug and a removed translation in the test fixture, not just the happy-path pair.

For automation, assert that each topic has the expected published versions and no duplicate language assignment. Then compare normalized sets of alternate URLs for every pair. Store the canonical separately so a shared alternate set does not accidentally copy the same canonical into both pages.

Document what the check proves. Parsing XML proves that the document is well formed; it does not prove search-engine acceptance. A successful response does not prove equivalent content. A correct annotation does not guarantee indexing, ranking or a particular search-result language.

How should LocalizeZone projects maintain these mappings?

Include the language inventory in the website localization scope before translating large batches. LocalizeZone recommends a stable topic identifier, explicit counterpart URLs and responsibility for reviewing later edits. Share route changes with both content and engineering owners.

At release time, review one representative service, article and form journey in both languages. For larger sites, expand the automated comparison to the full inventory. If a counterpart is delayed, record its status and revisit the pair when it is genuinely published.

Keep screenshots and route evidence with the release notes. This makes later defects easier to reproduce and keeps the conversation focused on the affected reader journey. The handoff should explain which checks were performed and which still need the production environment.

FAQ

Does vi mean only visitors located in Vietnam?

No. It denotes Vietnamese without a regional subtag.[1] Decide region-specific content separately, and let visitors change language when the suggested version is unsuitable.

Must every page have x-default?

No. Add a fallback deliberately when it serves the intended experience.[3] An irrelevant destination is not improved by labeling it as a default.

Can the English homepage replace a missing article translation?

It should not be treated as the article's equivalent. Record the missing version and provide a clear navigation choice while the relevant translation is prepared.

Should the Vietnamese canonical point to English?

Do not apply that as a blanket rule. Review the preferred URL in the same language and manage genuine duplicates separately.[4]

Does a sitemap parse prove hreflang works in search?

No. It checks document structure only. Review counterpart content, response behavior, deployed output and relevant search diagnostics before making a broader claim.

What information helps scope this work?

Send the route inventory, existing languages, publishing system and known counterpart gaps through the quotation page. Include redirects and non-HTML resources if they are part of the project.

Sources and methodology

Official Google and W3C guidance was checked on 4 October 2026. The inventory rubric, LocalizeZone-domain snippets and eight-step testing sequence are original examples. XML well-formedness and the example pair relationships can be checked locally; these examples are not a live search-engine experiment, a crawl of a customer site or a guarantee of indexing.

References

[1] W3C Internationalization. Choosing a language tag.

[2] Google Search Central. Tell Google about localized versions of your page.

[3] Google Search Central Blog. Introducing x-default hreflang for international landing pages.

[4] Google Search Central. How to specify a canonical URL with rel="canonical" and other methods.