hreflang Basics — How Search Engines Recognize a JP/EN Article Pair

If you run a site in both Japanese and English, a few questions come up quickly. Will a search engine treat the two versions of the same article as unrelated pages? Will someone searching in Japanese be shown the English page? The hreflang annotation, placed in the HTML <head>, exists to address exactly this. This post covers what hreflang says, how it needs to be written, and how it works in practice on this blog (wpmm.jp/blog and en.wpmm.jp/blog).

Note: hreflang tells search engines that a page has counterparts in other languages or regions. It does not translate anything. It only declares which URLs are language variants of the same content.

What Problem hreflang Addresses

When several language versions of a page exist, a search engine has to work out:

• which page to show to a searcher in which language
• whether two pages are separate articles or language variants of one
• whether they should be treated as duplicates

hreflang lets the site owner state these relationships explicitly. Search engines can guess a page’s language from its text, but a declared relationship gives them clearer grounds than a guess.

The Basic Syntax

On each article page, place link tags like these in the <head>:

<link rel="alternate" hreflang="ja"        href="https://wpmm.jp/blog/sample-article/" />
<link rel="alternate" hreflang="en"        href="https://en.wpmm.jp/blog/sample-article/" />
<link rel="alternate" hreflang="x-default" href="https://wpmm.jp/blog/sample-article/" />

x-default is a special value for the fallback page shown to people whose language matches none of the listed ones. A language-selector page or the primary-language page is the usual choice.

The Key Rule: Both Sides Must Point to Each Other

The most commonly missed point is that hreflang must be reciprocal. If the Japanese page points to the English page but the English page does not point back, the relationship may be treated as not established.

So both the Japanese and the English page carry the same set of lines, including the line that points to themselves. A few other points worth keeping in mind:

• Keep the URLs consistent with the canonical URL. If canonical and hreflang disagree, it is unclear which to trust.
• Use two-letter ISO 639-1 language codes such as ja and en.
• Point only to pages that exist and render normally, not to 404s or redirects.

A Real Example: Pairing by Identical Slugs

wpmm.jp/blog (Japanese) and en.wpmm.jp/blog (English) run as separate WordPress sites. On top of that, each article uses the same slug in both languages. If the Japanese article lives at https://wpmm.jp/blog/example/, the English one lives at https://en.wpmm.jp/blog/example/.

This keeps the theme code simple. It takes the part of the current URL after /blog/, then attaches it to each language’s base URL.

// Simplified pseudo-code for illustration
$jp_base = 'https://wpmm.jp/blog/';
$en_base = 'https://en.wpmm.jp/blog/';

// $rel = the part of the current URL after "/blog/"
$jp_url = $jp_base . $rel;
$en_url = $en_base . $rel;

echo '<link rel="alternate" hreflang="ja" href="' . esc_url($jp_url) . '" />';
echo '<link rel="alternate" hreflang="en" href="' . esc_url($en_url) . '" />';

There is no per-article lookup table of “which English post matches this Japanese post”; matching slugs decide the pair mechanically. The esc_url() call on output, covered in the previous post, is used here as well.

The method has two prerequisites: the slugs must match exactly across languages, and they must not change after publication. If only one side changes, the constructed URL points to a page that doesn’t exist and the pairing breaks. That is one reason slugs are chosen carefully before publishing and left alone afterward.

The same rule applies beyond articles. Category and other listing pages are paired in the same way, so the whole site follows one consistent convention: the same relative path in both languages.

Verifying the Output

hreflang changes nothing visible, so a missing tag is easy to overlook. Some ways to check after publishing:

• View the page source in a browser, search for hreflang, and confirm ja, en and x-default are all present with correct URLs.
• Check both the Japanese and English pages and confirm they emit the same set.
• Fetch the HTML with curl and extract the lines containing hreflang.

On this blog, an SEO check script lists the hreflang output after each publish and warns if any of ja, en or x-default is missing. Catching omissions mechanically is more reliable than relying on a human glance.

Common Pitfalls

• One-way declarations: writing them only on the Japanese side. Reciprocity is required.
• Mismatch with canonical: hreflang and canonical point to different URLs.
• Relative URLs: the href should normally be absolute.
• Pointing to nonexistent pages: continuing to emit a counterpart URL when that language’s article is unpublished or deleted. If no counterpart exists, it can be better not to declare the pair.
• Wrong language codes: writing jp instead of ja.

The last one is easy to fall into for Japanese: jp is the country code, while hreflang expects the language code ja.

Summary

hreflang states the relationship between language variants of a page, in a form search engines can read. The essentials are rel="alternate" plus a language code and an absolute URL, and placing the same set on both language versions. Operationally, keeping slugs identical across languages makes counterpart URLs mechanical to build, so no mapping table needs maintaining as the article count grows. After publishing, check the output on both language versions.

Upcoming posts will cover other information that lives in the same <head>, such as structured data and OGP.