Trees Consulting Japan AI Search Optimization & SEO · Direct English Communication Contact Us

JAPAN SEARCH BRIEF Japan SEO · AI Search Optimization· Japanese Search · Market Entry

Hreflang for Japan: How to Set Up Japanese and English Pages Correctly

Hreflang setup connecting equivalent English and Japanese website pages with bidirectional language and region mapping

Last reviewed: September 2026

If your international website has English and Japanese versions, hreflang helps Google understand which URL is the language or regional alternative for a user.

It does not make a page rank higher simply because you added a tag. It does not replace Japanese keyword research, useful localized content, technical quality, or trust. Its job is narrower and important: to describe the relationship between equivalent URLs so Google can choose a more appropriate version when possible.

For Japan, the difficult question is often not how to copy a tag. It is how to define the audience correctly:

Is the page Japanese for Japanese speakers generally (ja)?
Is it Japanese specifically for users in Japan (ja-JP)?
Is the English page global (en) or specifically for Japan (en-JP)?
Does Japan have different prices, products, support, shipping, or legal information?
Are the pages genuinely equivalent, or are they separate pages with different search intent?

This guide shows how to make that decision and implement the mapping safely. For the broader crawlability, indexing, canonical, sitemap, rendering, and international-site checks around this work, see the Technical SEO for Japan guide.

What hreflang does for a Japan website

Suppose the same product page exists in English and Japanese. Without an explicit relationship, Google has to infer how the URLs relate. Hreflang provides a declared mapping such as:

English global page → English page
Japanese Japan page → Japanese Japan page
English page → Japanese counterpart
Japanese page → English counterpart
Unmatched users → a selector or fallback through x-default

The relationship is usually most useful when multiple pages contain substantially the same information but are localized for different languages or regions.

Hreflang is not a ranking factor in the sense of “add it and rankings rise.” A page still needs to be crawlable, indexable, relevant, useful, and competitive. Hreflang helps with language or regional URL selection; it does not repair weak Japanese content or create demand.

`ja` or `ja-JP`? Start with the audience

The right value depends on the page’s intended audience, not simply on the fact that the page is written in Japanese.

Code	Meaning for implementation	Use when	Do not infer
`ja`	Japanese-language content without a regional restriction in the hreflang label	The page is intended for Japanese speakers generally, or the business does not need to distinguish Japan from other Japanese-speaking audiences	It does not automatically mean “Japan only”
`ja-JP`	Japanese-language content targeted to users in Japan	The page contains Japan-specific products, pricing, shipping, legal terms, support, availability, or other Japan-only conditions	It does not mean the page will rank merely because `JP` is present
`en`	English-language content without a specific region	A global English page or an English page intended for English speakers generally	It does not automatically mean English-speaking users in Japan
`en-US`	English content targeted to the United States	US-specific pricing, legal terms, inventory, or service conditions exist	It is not a generic English fallback
`en-GB`	English content targeted to the United Kingdom	UK-specific pricing, legal terms, inventory, or service conditions exist	`UK` by itself is not the valid region code in this syntax
`x-default`	Fallback for unmatched language/region settings	A country selector, language selector, or genuinely global fallback URL exists	It is not a replacement for a language code

Use ja when the URL is Japanese-language content without a Japan-only regional distinction. This can make sense when one Japanese page is intended for Japanese speakers generally and the business is not separating Japan from other Japanese-speaking audiences.

Use ja-JP when the URL is Japanese content specifically targeted to users in Japan. This is more appropriate when the page reflects Japan-only prices, products, shipping, tax, legal conditions, support, availability, local offices, or other Japan-specific information.

Neither code is a guaranteed ranking instruction. ja does not mean “never show this in Japan,” and ja-JP does not create a Japan ranking advantage. They describe the intended language and optional region of the URL.

The same logic applies to English:

en = English without a specific regional restriction
en-US = English for the United States
en-GB = English for the United Kingdom
en-JP = English specifically for Japan, if the site genuinely maintains such a page and the audience distinction is meaningful

Do not add both ja and ja-JP to the same URL as a hedge. Decide what the page is for. If you maintain separate Japanese pages for different regions, map those real regional variants separately.

The annotation decision should follow the actual language, audience, offer, and search experience. For the broader localization context, see Japanese SEO: What Changes When Search Moves Into Japanese.

The core rules every implementation must follow

Google’s localized-page documentation supports HTML, HTTP headers, and XML sitemaps. Whichever method you use, keep these rules intact:

Use fully qualified absolute URLs.
Include the current page in its own alternate set.
Put the same complete set on every page in the set.
Make the relationship reciprocal: if English points to Japanese, Japanese points back to English.
Use valid ISO 639-1 language codes and optional ISO 3166-1 Alpha 2 region codes.
Never use a region code by itself, such as JP.
Use x-default for an unmatched-language fallback or language/country selector.
Point only to final, accessible, equivalent URLs.

The most common operational mistake is generating tags from each page independently. That often creates asymmetric sets: the English page knows about the Japanese page, while the Japanese page points to an old URL, omits the English page, or uses a different code. Generate or manage the set as one unit.

HTML implementation in the `<head>`

For an English global page and a Japanese Japan page, the following set could appear in the <head> of both pages:

<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/product/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

On the English page, the en line is the self-reference. On the Japanese page, the ja-JP line is the self-reference. The entire set remains identical on both pages.

The tags must be in a valid <head>. Do not paste them into the article body, a visible country-selector component, or a JavaScript-only element that is not reliably present in the rendered HTML.

Adding regional English pages

If your site genuinely has separate US and UK versions, the set might be:

<link rel="alternate" hreflang="en" href="https://example.com/en/guide/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/guide/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/guide/" />
<link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/guide/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/choose-region/" />

Do not create en-US and en-GB merely because the site has visitors in those countries. Use regional codes when the URLs are actually designed for those regional audiences.

HTTP headers for PDFs and other non-HTML files

For a PDF or another resource where HTML <head> markup is not available, Google supports an HTTP Link response header:

Link: <https://example.com/en/whitepaper.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/ja/whitepaper.pdf>; rel="alternate"; hreflang="ja-JP",
      <https://example.com/choose-region/whitepaper.pdf>; rel="alternate"; hreflang="x-default"

Return the same complete set for each version. Keep the angle brackets around every URL, and verify the actual response with an HTTP header inspection rather than relying on server configuration alone.

XML sitemap annotations

XML sitemaps can carry hreflang annotations using the XHTML namespace:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/product/</loc>
    <xhtml:link rel="alternate" hreflang="en"
                href="https://example.com/en/product/" />
    <xhtml:link rel="alternate" hreflang="ja-JP"
                href="https://example.com/ja/product/" />
    <xhtml:link rel="alternate" hreflang="x-default"
                href="https://example.com/" />
  </url>
  <url>
    <loc>https://example.com/ja/product/</loc>
    <xhtml:link rel="alternate" hreflang="en"
                href="https://example.com/en/product/" />
    <xhtml:link rel="alternate" hreflang="ja-JP"
                href="https://example.com/ja/product/" />
    <xhtml:link rel="alternate" hreflang="x-default"
                href="https://example.com/" />
  </url>
</urlset>

The <xhtml:link> entries should list every variant, including the URL in the <loc> element itself. For a large site, generate the alternate sets programmatically from a single source of truth and validate the output before submission.

Hreflang and canonical are not interchangeable

Canonical answers: “Which URL represents this page’s content?” Hreflang answers: “Which equivalent language or regional URL should be considered for this audience?”

Mechanism	Main question	Typical localized-page setup
Canonical	Which URL represents this page’s content for indexing purposes?	English page self-canonicalizes to the English URL; Japanese page self-canonicalizes to the Japanese URL when both are intended indexable localized versions.
Hreflang	Which equivalent language/region URL should be shown to a user?	English and Japanese pages list each other, themselves, and any genuine fallback or regional variants.

When English and Japanese pages are intended to be independently indexable localized equivalents, a common pattern is:

<!-- English page -->
<link rel="canonical" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/product/" />

<!-- Japanese page -->
<link rel="canonical" href="https://example.com/ja/product/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="ja-JP" href="https://example.com/ja/product/" />

Do not canonicalize every Japanese page to the English source by default. If the Japanese page is a real localized page that should be indexed, a self-canonical is usually the clearer setup. At the same time, do not label unrelated pages as hreflang alternatives simply because they discuss the same company or product.

Hreflang does not force Google to index a page or guarantee that Google will use the declared URL. The target still needs to be accessible, indexable, and sufficiently equivalent.

Japan-specific implementation cases

`.com/jp/`

A /jp/ folder usually communicates a Japan market section. If its pages are Japanese and Japan-specific, ja-JP may be appropriate. If it also contains an English Japan page, use en-JP only when that page is deliberately for Japan rather than global English. The folder name itself is not the hreflang signal.

`.com/ja/`

A /ja/ folder usually communicates a language section. Use ja when the page is Japanese without a regional distinction, or ja-JP when the page is specifically for Japan. The decision should follow the content, offer, and governance model.

`.co.jp`

A .co.jp page can participate in the same alternate set as .com pages. The domain extension does not replace hreflang and does not eliminate the need for valid return links, self-reference, and correct canonicalization.

Japan-only pricing or products

If Japan has different pricing, tax, shipping, products, warranties, or support, treat the pages as regional variants only when they represent the same page role and underlying offer. Map the correct Japan-specific English and Japanese pages; do not point a global page at a Japan page that presents materially different commercial conditions.

Country selector and `x-default`

Use x-default for a stable language/country selector or a genuine fallback page. Make sure users and crawlers can reach each localized URL without being trapped in an automatic IP redirect.

International SaaS

Map product, feature, pricing, documentation, and support pages by equivalent page role. A Japanese pricing page with JPY, Japanese tax information, and Japan-specific billing may be a regional counterpart to an English global pricing page, but it should not be mapped to an unrelated Japanese help article.

B2B corporate sites

Check office locations, certifications, support contacts, case studies, procurement terms, and legal information. A Japanese corporate page may need different evidence and a different CTA. Map it to an equivalent corporate or service page only when the relationship is real.

How to diagnose a broken hreflang implementation

Start with one representative cluster: one English URL, one Japanese URL, and one fallback or regional URL if present. Build a matrix with one row per URL and one column per expected hreflang value.

Then check:

Does every URL return the final HTTP 200 response?
Does every page list itself?
Does every page list the same set?
Do all links have return links?
Are the language and region codes valid?
Do canonical tags point to the intended page identity?
Are the pages genuinely equivalent localized versions?
Is the implementation present in the rendered HTML, response header, or submitted sitemap?

If one of these checks fails, fix the mapping before adding more localized pages. A larger number of inconsistent tags makes the problem harder to diagnose.

Common hreflang errors

Error	Why it is wrong or risky	Corrective action
`hreflang="JP"`	A region code by itself is not a valid language-region tag.	Use `ja-JP` when Japanese for Japan is intended.
`hreflang="uk"` for the United Kingdom	`uk` is a language code, not the valid region code for the UK in this context.	Use `en-GB` for English targeting the United Kingdom.
Using `ja-JP` on every Japanese page	It may falsely imply Japan-only targeting.	Use `ja` for broad Japanese-language targeting when appropriate; use `ja-JP` for Japan-specific pages.
Tags appear only on the English page	The alternate set is not reciprocal.	Put the identical set on every page in the cluster.
The current page is missing from its own set	Self-reference is incomplete.	Add the current URL with its own language/region code.
Alternate URL redirects	The target is not the final equivalent URL.	Link directly to the final 200 URL.
Alternate URL is `noindex` or blocked	Google may not be able to use it as an eligible alternate.	Make the intended target crawlable and indexable, or remove it from the set.
Japanese page canonicalizes to English page by default	It can suppress the Japanese URL’s independent indexing purpose.	Self-canonicalize each intended indexable localized page.
Different pages share one canonical but are called alternates	Canonical and alternate relationships are being used inconsistently.	Decide whether the pages are duplicates, localized equivalents, or separate intents.
Missing return tag	Google may ignore or fail to interpret the relationship.	Check every directed edge in both directions.
Relative URLs	They are less reliable for cross-domain or multi-site mapping.	Use complete absolute HTTPS URLs.
HTML tags placed in `<body>`	Google’s documented HTML method requires them in `<head>`.	Move them into a well-formed `<head>`.
Unrelated attributes combined with hreflang	The annotation no longer follows the documented syntax.	Keep hreflang link elements dedicated to alternate language/region URLs.
Sitemap lists only one side of the relationship	The set is incomplete.	Add identical `<xhtml:link>` children for every variant under every `<url>`.
`x-default` points to a dead selector	Unmatched users and Google receive a broken fallback.	Use a live, stable selector or genuine fallback page.
Global English and English Japan pages are both labeled `en` without a reason	The intended regional audiences are not distinguished.	Use `en` for global English and `en-JP` only for a genuinely Japan-targeted English page.
Hreflang is treated as a ranking hack	It confuses URL selection with ranking quality.	Use it as a localization signal; improve content, relevance, authority, and technical quality separately.

Final implementation checklist

☐ The audience of each page is documented.
☐ ja versus ja-JP is chosen from the site’s language/region design.
☐ en, en-US, and en-GB are used only for real audience distinctions.
☐ x-default points to a real fallback or selector.
☐ Every page self-references.
☐ Every page contains the same complete alternate set.
☐ Return links are present.
☐ All URLs are absolute, HTTPS, final, and accessible.
☐ No region-only or invalid codes are used.
☐ HTML tags are in <head>, or HTTP/sitemap syntax is correctly implemented.
☐ Each localized page has an appropriate canonical.
☐ Hreflang is not being presented as a ranking boost.
☐ The production output has been checked after release.

Need help with a Japan website hreflang setup?

If you need a broader technical review, start with the Technical SEO for Japan guide.

For the wider market-entry and page-planning framework, read the Japan SEO guide for overseas companies.

If the implementation needs to be planned alongside Japanese search, page structure, and conversion work, review Japanese SEO: What Changes When Search Moves Into Japanese.

For hands-on support with the Japanese search strategy and implementation priorities, see Japan SEO services for global companies.

FAQ

Does hreflang improve rankings in Japan?

Not directly. Hreflang helps Google understand language and regional URL alternatives. It does not replace relevance, useful Japanese content, technical quality, authority, or a credible conversion path, and it does not guarantee rankings.

Should a Japanese page use `ja` or `ja-JP`?

Use ja when the page is Japanese-language content without a regional restriction. Use ja-JP when the page is specifically intended for users in Japan and reflects Japan-specific products, prices, legal terms, support, shipping, or availability. Choose from the actual site design; neither code is automatically correct for every Japanese page.

Is `JP` a valid hreflang value?

No. A region code cannot be used by itself. Use a language code with an optional region, such as ja-JP or en-JP, when that language-region target is genuinely intended.

Do I need hreflang if my site uses `/jp/` or `.co.jp`?

The folder or domain does not replace hreflang. If you maintain equivalent language or regional versions, map them explicitly and still implement self-reference, return links, valid codes, canonical tags, and indexability checks.

Should every page point to `x-default`?

Use x-default when a real fallback or language/country selector exists for unmatched users. Do not add it as an unconsidered extra tag, and do not point it to a dead or inappropriate page.

Do hreflang tags need to appear on both the English and Japanese pages?

Yes. Every page in the alternate set should contain the same complete set, including itself. If one page points to another without a return link, Google may ignore or fail to interpret the relationship correctly.

Can I canonicalize the Japanese page to the English page?

Do not do this by default when the Japanese page is an independently indexable localized version. A self-referencing canonical on each intended localized URL is usually clearer. Canonical and hreflang have different jobs and should be designed together.

Which implementation method should I use: HTML, HTTP header, or sitemap?

Use HTML head tags for ordinary HTML pages when your CMS can maintain them reliably. Use HTTP headers for non-HTML resources such as PDFs. Use XML sitemaps when managing the annotations in the sitemap is more reliable at scale. The most important requirement is a complete, consistent, reciprocal set—not the method alone.

Does a translated Japanese page automatically qualify as an hreflang alternate?

No. The pages should be genuine localized equivalents with substantially the same page role and information. If the Japanese page targets a different product, audience, or search intent, it may need its own page relationship rather than being forced into an alternate set.