The symptom that brings people to this topic is almost always the same: the company has a Japanese section, it is indexed, and yet searchers in Japan keep landing on the English page. Sometimes the English page even outranks the Japanese one for a Japanese-language query.

Hreflang is usually part of that story. It is not always the whole of it — a Japanese page that nobody searches for will not rank however it is annotated — but it is the part you can fix deterministically, and it is worth fixing before you conclude anything else.

What hreflang actually does

Hreflang does not make a page rank. It tells Google that several URLs are alternate language or regional versions of the same content, so that when one of them qualifies for a result, Google can substitute the version matching the user’s language and location.

Two consequences follow from that definition, and most hreflang mistakes come from missing one of them.

First, it is a swap mechanism, not a boost. If your Japanese page has no visibility of its own and the English page has none either, correct hreflang changes nothing.

Second, it operates on clusters of URLs, not on sites. Every page has its own cluster. /services/technical-seo/ and /ja/services/technical-seo/ form one cluster; the two home pages form another. A single site-wide annotation block that points at the home pages of each language, repeated on every page, is one of the most common ways to have hreflang and get no benefit from it.

ja or ja-JP?

The language subtag is ja. Not jp. jp is a country code — it is what appears in .co.jp and in ja-JP — and it is not a valid language value on its own. hreflang="jp" is invalid and is ignored outright. This is the single most frequent hreflang error we see on Japanese sections, and because invalid annotations fail silently, it can sit there for years.

Between ja and ja-JP, the honest answer is that ja is right for most sites.

  • ja means “this page is for Japanese speakers”, anywhere in the world.
  • ja-JP means “this page is for Japanese speakers in Japan”, and it excludes Japanese speakers browsing from elsewhere.

Use the region subtag only when you actually have more than one Japanese-language version differentiated by country — say a ja-JP page with Japanese pricing and a ja-SG page for the Singapore entity. If you have exactly one Japanese page, ja covers everyone who should see it, including Japanese speakers travelling or living abroad. Narrowing to ja-JP for no reason simply removes an audience.

If you do use a region subtag, it must be an ISO 3166-1 alpha-2 country code, and the conventional casing is ja-JP (the value is not case-sensitive, but consistency makes auditing easier).

Reciprocity is the rule everything fails on

Every URL in a cluster must list every URL in that cluster, including itself. If page A claims page B as its Japanese alternate but page B does not claim page A back, Google may disregard the annotation entirely.

The self-reference is genuinely required and genuinely often missing. The Japanese page must include an hreflang="ja" line pointing at itself, not only the line pointing at English.

For a site with an English original and a Japanese version, the identical block appears on both pages:

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

The most reliable way to get reciprocity right is to stop maintaining it by hand. Generate the cluster from one source of truth — a page registry that knows which languages each page exists in — so that every page in the cluster emits the same list by construction. Hand-maintained hreflang decays the first time someone adds a page.

x-default

x-default marks the page to show when no other version matches the user. It is optional, and it is frequently misunderstood.

Point it at whichever page is the sensible fallback for “someone we have no better match for”. That is usually the global English version, or a genuine language-selector page if you have one. Do not point x-default at the Japanese page — it will be served to users you did not intend it for.

x-default also participates in reciprocity: the same annotation belongs on every page in the cluster, including the page it points at.

One nuance worth knowing: x-default only earns its keep once there is more than one version to choose between. On a page that exists in a single language, the whole annotation block is noise.

Where to put it

Three delivery methods, all equally valid to Google:

  • <link> elements in <head> — simplest, and the right default for most sites. They must be in the raw HTML <head>, not injected by JavaScript into <body>.
  • HTTP Link headers — the only option for non-HTML files such as PDFs.
  • XML sitemap annotations — often the most maintainable choice for a large site, because the whole cluster map lives in one generated file rather than being distributed across thousands of templates.

Pick one. Two methods that disagree is worse than either alone, and it is a surprisingly common outcome when a plugin and a hand-written template are both active.

Canonical and hreflang must agree

This is where a lot of otherwise-correct setups break.

Every language version must be self-canonical. The Japanese page canonicalises to itself. If the Japanese page carries <link rel="canonical"> pointing at the English URL — which happens more often than you would think, usually as a leftover from a duplicate-content worry — you have told Google the Japanese page should not be indexed at all, and the hreflang annotation pointing at it is meaningless.

Related rules that follow from the same principle:

  • hreflang must point at the canonical, indexable URL — not a redirect, not a parameterised variant, not a noindex page.
  • Use absolute URLs, with the protocol. Relative hreflang URLs are not supported.
  • Match your trailing-slash, www and https conventions exactly. https://example.com/ja/pricing and https://example.com/ja/pricing/ are different URLs, and a mismatch breaks reciprocity even though a browser lands in the same place.

Subdirectory, subdomain or .co.jp

Hreflang works identically across all three. example.com/ja/, ja.example.com and example.co.jp can all be annotated as alternates of one another, and Google handles cross-domain hreflang clusters fine.

So the URL structure decision is not an hreflang decision — it is an authority, operations and credibility decision, which we work through separately in Do You Need a .co.jp Domain to Rank in Japan?. The only hreflang-relevant point: a cross-domain cluster is harder to keep reciprocal, because the two sides are usually maintained by different teams on different release cycles. That is an operational risk, not a ranking one, but it is a real one.

The failure modes worth checking for first

In roughly the order we find them:

  1. hreflang="jp" instead of hreflang="ja".
  2. No self-referencing annotation on one or both sides.
  3. Non-reciprocal clusters — usually because the Japanese section was built later, by a different team, from a different template.
  4. Site-wide annotation pointing every page at the two home pages.
  5. hreflang targets that redirect, 404, or carry noindex.
  6. The Japanese page canonicalising to the English page.
  7. Protocol, www or trailing-slash mismatches between the annotation and the real URL.
  8. Annotations injected by client-side JavaScript.
  9. Automatic IP-based redirects that send Googlebot — which crawls largely from US IP addresses — away from the Japanese pages entirely.

That last one deserves emphasis because it defeats everything else. If visitors from Japanese IPs are force-redirected to /ja/ and everyone else is force-redirected away from it, your annotations are describing a site Google cannot crawl. Suggest a language switch with a dismissible banner; do not enforce it.

How to validate

Google retired the dedicated International Targeting report in Search Console, so there is no first-party hreflang validator to lean on any more. Validation is now your own job, and it is not difficult:

  • Crawl both language sections with a crawler that extracts hreflang, and check reciprocity across the whole set rather than spot-checking one page. Reciprocity errors are systematic; if one page has one, hundreds probably do.
  • Verify every target URL returns 200, is self-canonical, and is indexable.
  • Check the raw HTML, not the rendered DOM in your browser’s inspector — they can differ.
  • Use the URL Inspection tool on a representative Japanese page to confirm Google sees the canonical you intended.
  • Watch Search Console Performance filtered to Japan, and look at which URL receives the impressions for Japanese-language queries. If it is still the English URL weeks after the fix, either the annotation is not being honoured or the Japanese page is not a credible result for that query.

That last distinction is the one to hold on to. Hreflang decides which of your pages is shown. It does not decide whether any of them deserves to be. If the Japanese page is a direct translation of an English page, built around English search demand, correct annotations will surface a page nobody was looking for — which is the argument made at length in Why Translating Your Website Is Not Japanese SEO.

Fix the technical layer first, because it is knowable and it stays fixed. Then go and do the harder half.

If you want the setup checked properly, that is part of our international SEO for Japan and technical SEO work — send us the URLs and we will tell you what we find.