チュートリアル//12 読了時間

i18n SEO：Hreflangタグ、ロケールURL、多言語検索ランキングの完全ガイド

Eray Gündoğmuş
共有
目次

i18n SEO：Hreflangタグ、ロケールURL、多言語検索ランキングの完全ガイド

多言語SEOは単なる「別の言語に翻訳したSEO」ではありません。異なる問題があり、異なる失敗パターンがあります。そして、ほとんどのi18nガイドではそれに触れることさえありません。完璧に翻訳されたコンテンツ、美しいローカライズされたUI、それでもフランス語のページがドイツのユーザーに表示されることがあります。Googleが重視する技術的な詳細をいくつか飛ばしてしまったからです。

このガイドでは、国際SEOのフルスタックをカバーします：URL構造、hreflangの実装、ロケール固有のメタデータ、サイトマップ、構造化データ、そして実際にランキングを動かすコンテンツローカライゼーションの意思決定。Next.js、SvelteKit、Vueのコード例があります。実装の詳細が重要だからです。

URL構造の戦略

hreflangタグを1つ書く前に、URLの構造を決める必要があります。この決定は永続的です。後から変更するにはマイグレーション作業と一時的なランキング低下が伴います。最初に正しく決めてください。

3つの選択肢があります：

戦略例メリットデメリット
ccTLDexample.de、example.frGoogleへの最強の地域シグナル；ローカルユーザーの信頼を築く費用がかかる；個別のドメイン管理が必要；ドメイン権威の共有が難しい
サブドメインde.example.com、fr.example.com個別ホストが容易；明確な分離Googleはサブドメインを半独立的に扱う；共有リンクエクイティが一貫しない
サブディレクトリexample.com/de/、example.com/fr/ドメイン権威を共有；実装が最も容易；ほとんどのチームに最適ccTLDよりわずかに地域シグナルが弱い

ほとんどのチームへの推奨：サブディレクトリ。

ccTLD（例：ローカルドメイン信頼が重要な大企業が市場参入する場合）やサブドメイン（例：リージョンごとに別のホストインフラが必要な場合）を使用する強い理由がない限り、サブディレクトリが現実的な選択です。ルートドメインの権威を引き継ぎ、正しく実装するのが最も簡単で、適切なhreflang設定と組み合わせることでGoogleが適切に処理します。

もう一点：URLには常に小文字のハイフン区切りのロケールコードを使用してください。/en-us/は問題ありませんが、/en_US/はNGです。一貫性が重要です。

Hreflangの実装

Hreflangは、どのバージョンのページをどのユーザーに提供するかをGoogleに伝える仕組みです。間違えると、Googleがそれを無視するか、間違ったロケールを間違ったユーザーに提供します。これはランキングとバウンス率の両方に悪影響を与えます。

基本的な構文

<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

各ロケールページは、自分自身を含むすべてのロケールバリアントを参照する必要があります。英語ページに自己参照のhreflangタグがない場合、Googleはセット全体を無視する可能性があります。

x-defaultタグ

x-defaultは、他のロケールが一致しない場合にどのページを表示するかをGoogleに伝えます。キャッチオールページ（通常はルートURLや言語セレクターページ）に使用します。これは省略可能ではありません。x-defaultの欠落は最も一般的なhreflangの間違いの1つです。

ロケールコード：言語 vs 地域

Googleは言語のみのコード（en、de、fr）と言語・地域コード（en-US、en-GB、de-AT）の両方を受け入れます。実際にサポートしている最も具体的なコードを使用してください：

  • 全英語話者向けに1つの英語バージョンがある場合：en
  • 米国版とUK版が別々にある場合：en-USとen-GB
  • オーストリアをターゲットにしたドイツ語コンテンツがある場合：de-AT

同じhreflangセット内でenとen-USを混在させることは、Googleのシグナルを混乱させる一般的な間違いです。1つの規則を選び、サイト全体で一貫して使用してください。

Hreflangの3つの実装方法

1. <head>内のHTML <link>タグ（ほとんどのセットアップに推奨）

サーバーレンダリングまたは静的生成サイトに最適。高速で、明示的で、検証が容易。

2. HTTPヘッダー

HTMLコンテンツ以外（PDFs等）やHTMLヘッドを変更できない場合に最適。

Link: <https://example.com/en/>; rel="alternate"; hreflang="en",
      <https://example.com/de/>; rel="alternate"; hreflang="de"

3. XMLサイトマップアノテーション

すべてのページのHTMLにhreflangを追加するのが非実用的な大規模サイトに最適。

<url>
  <loc>https://example.com/en/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/"/>
</url>

同じサイトでメソッドを混在させないでください。 1つを選び、一貫して使用してください。

ランキングを下げる一般的なHreflangの間違い

  • 非相互タグ：ページAがページBを参照しているが、ページBがページAを参照していない。Googleはセット全体を無視します。
  • 間違ったロケールコード：en-ukの代わりにen-GB、またはzh-Hansを意図してzhを使用。BCP 47コードを使用してください。
  • 自己参照の欠落：すべてのページが自分自身のhreflangセットに自分自身を含める必要があります。
  • 壊れたURL：200以外を返すhreflang URLはタグを無効にします。
  • 実装メソッドの混在：一部のページにHTMLタグ、他のページにサイトマップ、さらに別のページにHTTPヘッダー。Googleが混乱します。

ロケール固有のメタデータ

翻訳されたページコンテンツだけでは不十分です。すべてのロケールには、タイトルタグ、メタディスクリプション、Open Graphタグ、正規URLなど、完全に翻訳されたメタデータが必要です。

ロケールごとに必要なセット

<!-- ロケール固有のタイトルとディスクリプション -->
<title>Vollständiger Leitfaden zur i18n-SEO | Better i18n</title>
<meta name="description" content="Alles, was Sie über mehrsprachige SEO wissen müssen..." />

<!-- このロケールの正規URL -->
<link rel="canonical" href="https://example.com/de/blog/i18n-seo-guide/" />

<!-- ロケール付きOpen Graph -->
<meta property="og:locale" content="de_DE" />
<meta property="og:locale:alternate" content="en_US" />
<meta property="og:title" content="Vollständiger Leitfaden zur i18n-SEO" />
<meta property="og:url" content="https://example.com/de/blog/i18n-seo-guide/" />

<!-- Hreflangセット -->
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/i18n-seo-guide/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/i18n-seo-guide/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/i18n-seo-guide/" />

Open GraphはアンダースコアアレードのロケールコードDを使用していることに注意してください（de_DE、en_US）、一方hreflangはハイフン区切りのBCP 47コードを使用します（de-DE、en-US）。この不一致は既知の問題点であり、頻繁なバグの原因です。

Next.jsの実装

Next.js 13+のgenerateMetadata()でロケール対応のメタデータが簡単に実装できます：

// app/[locale]/blog/[slug]/page.tsx
import { Metadata } from 'next'

const locales = ['en', 'de', 'fr', 'es']

export async function generateMetadata({
  params,
}: {
  params: { locale: string; slug: string }
}): Promise<Metadata> {
  const { locale, slug } = params
  const post = await getPost(slug, locale)

  const alternates = locales.reduce(
    (acc, l) => ({
      ...acc,
      [l]: `https://example.com/${l}/blog/${slug}/`,
    }),
    {} as Record<string, string>
  )

  return {
    title: post.title,
    description: post.excerpt,
    alternates: {
      canonical: `https://example.com/${locale}/blog/${slug}/`,
      languages: {
        ...alternates,
        'x-default': `https://example.com/en/blog/${slug}/`,
      },
    },
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://example.com/${locale}/blog/${slug}/`,
      locale: locale.replace('-', '_'),
      alternateLocale: locales
        .filter((l) => l !== locale)
        .map((l) => l.replace('-', '_')),
    },
  }
}

Next.jsはalternates.languagesオブジェクトを自動的に<link rel="alternate" hreflang>タグとしてレンダリングします。App RouterとServer ComponentsでのNext.js i18nパターンの完全な解説は、Next.js App Router i18n: Server Components and RSC Patterns for 2026を参照してください。

SvelteKitの実装

<!-- src/routes/[locale]/blog/[slug]/+page.svelte -->
<script lang="ts">
  export let data: PageData

  const { post, locale, slug, locales } = data
  const baseUrl = 'https://example.com'
</script>

<svelte:head>
  <title>{post.title}</title>
  <meta name="description" content={post.excerpt} />
  <link rel="canonical" href="{baseUrl}/{locale}/blog/{slug}/" />

  {#each locales as l}
    <link
      rel="alternate"
      hreflang={l}
      href="{baseUrl}/{l}/blog/{slug}/"
    />
  {/each}
  <link
    rel="alternate"
    hreflang="x-default"
    href="{baseUrl}/en/blog/{slug}/"
  />

  <meta property="og:locale" content={locale.replace('-', '_')} />
  <meta property="og:url" content="{baseUrl}/{locale}/blog/{slug}/" />
</svelte:head>

タイプセーフな翻訳を使った多言語SvelteKitアプリの構築に関する完全ガイドは、SvelteKit i18n: Building Type-Safe Multilingual Apps with Svelte 5を参照してください。

Vue（@vueuse/headを使用）

// composables/useSeoMeta.ts
import { useHead } from '@vueuse/head'

export function useLocalizedMeta(
  post: Post,
  locale: string,
  slug: string,
  locales: string[]
) {
  const baseUrl = 'https://example.com'

  useHead({
    title: post.title,
    meta: [
      { name: 'description', content: post.excerpt },
      { property: 'og:title', content: post.title },
      { property: 'og:locale', content: locale.replace('-', '_') },
      { property: 'og:url', content: `${baseUrl}/${locale}/blog/${slug}/` },
    ],
    link: [
      { rel: 'canonical', href: `${baseUrl}/${locale}/blog/${slug}/` },
      ...locales.map((l) => ({
        rel: 'alternate' as const,
        hreflang: l,
        href: `${baseUrl}/${l}/blog/${slug}/`,
      })),
      {
        rel: 'alternate',
        hreflang: 'x-default',
        href: `${baseUrl}/en/blog/${slug}/`,
      },
    ],
  })
}

多言語サイトのサイトマップ

適切に構造化されたサイトマップは、すべてのロケールバリアントの明示的なマップをGoogleに提供するため、多言語サイトにとって特に重要です。

Hreflangアノテーション付きXMLサイトマップ

<?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/blog/i18n-seo-guide/</loc>
    <lastmod>2026-03-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/i18n-seo-guide/"/>
  </url>

  <url>
    <loc>https://example.com/de/blog/i18n-seo-guide/</loc>
    <lastmod>2026-03-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/i18n-seo-guide/"/>
  </url>
</urlset>

ページのすべてのロケールバリアントは独自の<url>エントリとして表示される必要があり、各エントリはすべてのバリアントのhreflangアノテーションを含める必要があります。これは設計上の冗長性です。

大規模サイトのサイトマップインデックス

ロケールが多くページが多い場合、フラットなサイトマップは扱いにくくなります。ロケール別サイトマップを持つサイトマップインデックスを使用してください：

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-en.xml</loc>
    <lastmod>2026-03-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-de.xml</loc>
    <lastmod>2026-03-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-fr.xml</loc>
    <lastmod>2026-03-01</lastmod>
  </sitemap>
</sitemapindex>

Google Search Consoleには個別のサイトマップではなく、サイトマップインデックスのURLを送信してください。GSCが自動的にすべての子サイトマップをクロールします。

コンテンツローカライゼーション vs 直訳

ここで多言語SEOは多言語UXから最も大きく乖離します。ユーザビリティのためには、有能な翻訳で十分かもしれません。SEOのためには、通常それでは不十分です。

機械翻訳がパフォーマンスを下げる理由

機械翻訳されたコンテンツはいくつかの理由で失敗する傾向があります：

  1. キーワードの不一致：異なる市場のユーザーは異なる検索をします。「プロジェクト管理ソフトウェア」のドイツ語表現は文字通り「Projektmanagementsoftware」かもしれませんが、ドイツ語話者のユーザーは実際には「Aufgabenverwaltung」や「Team-Kollaborationstool」で検索するかもしれません。英語キーワードの直訳はこれらの実際の検索パターンを見逃します。

  2. 薄いコンテンツシグナル：Googleの品質システムは、コンテンツが薄いか不自然であることを検出できます。自動翻訳されたページはネイティブ言語のページが持つ深さと具体性を欠くことが多いです。

  3. ローカルコンテキストの欠如：米国市場向けの「請求書ソフトウェア」に関するページはIRSコンプライアンスを強調するかもしれません。ドイツ向けの同じページはDATEV統合とGoBDコンプライアンスを強調する必要があります。そのコンテキストは翻訳からは得られません。

代わりに何をすべきか

  • ロケールごとのキーワードリサーチ：Google Keyword PlannerまたはAhrefsをターゲットのロケールと言語を明示的に設定して使用してください。英語キーワードが翻訳されると思わないでください。
  • 市場によって検索インテントが異なる：同じ製品クエリでも、ある市場では商業的インテント、別の市場では情報的インテントを持つ場合があります。それに応じてコンテンツを調整してください。
  • 翻訳だけでなくローカライズ：日付、通貨、単位、文化的参照、法的要件、ローカルの競合他社はすべて翻訳ではなく適応が必要です。

言語を超えたキーワードリサーチと完全な多言語SEO戦略の詳細については、Multilingual SEO: The Complete Guide to Ranking in Every Languageを参照してください。

ここはBetter i18nのようなプラットフォームが役立つ場所でもあります。翻訳管理だけでなく、ローカライズされた用語がすべての市場で一貫して意図的に保たれるようにする用語集の維持にも役立ちます。

技術的実装チェックリスト

多言語サポートをリリースする前に確認してください：

URL構造：

  • すべてのページで一貫したロケールプレフィックス形式（/en/、/de/等）
  • 小文字のハイフン区切りのロケールコード
  • すべてのロケールURLが200を返す（リダイレクトではない）

Hreflang：

  • すべてのロケールページが他のすべてのロケールのhreflangタグを含む
  • すべてのページが自己参照のhreflangタグを含む
  • x-defaultがすべてのページに設定されている
  • すべてのhreflang URLが絶対URL（相対URLではない）
  • Hreflangが1つのメソッドのみで実装されている（HTMLタグまたはサイトマップまたはHTTPヘッダー）
  • すべてのhreflangタグが相互参照されている

メタデータ：

  • タイトルタグがロケールごとに翻訳されている
  • メタディスクリプションがロケールごとに翻訳されている
  • 正規URLが正しいロケールURLを指している
  • Open Graphのog:localeがロケールごとに設定されている
  • Open Graphのog:locale:alternateが他のロケールをリストアップしている

サイトマップ：

  • すべてのロケールバリアントがサイトマップに含まれている
  • サイトマップ内のhreflangアノテーションがHTMLヘッドタグと一致している
  • サイトマップがGoogle Search Consoleに送信されている

国際SEOのためのGoogle Search Console

Google Search ConsoleはインターナショナルSEOの主要な診断ツールです。積極的に使用してください。

インターナショナルターゲティングレポート

GSCでレガシーツールとレポート > インターナショナルターゲティングに移動します。ここでは以下ができます：

  • サイト全体の地理的ターゲットを設定（ccTLDとサブドメインに有用）
  • hreflang実装のエラーを検出するためのhreflangタブを確認

hreflangレポートは最も一般的な実装の間違いを表示します：リターンタグの欠落、無効なロケールコード、200以外を返すURL。

ロケール別カバレッジレポート

GSCでURLプレフィックスプロパティタイプを使用して、ロケールごとに個別のプロパティを設定します（例：https://example.com/de/）。これにより、各ロケールのクロールカバレッジ、インデックスステータス、検索パフォーマンスを個別に監視できます。

パフォーマンスレポートのフィルタリング

パフォーマンスレポートで国別にフィルタリングして、各ロケールがターゲット市場でどのようにランキングされているかを確認します。ロケール設定と照合して、正しいページが正しい国でランキングされているか確認してください。

よくある間違い

1. ロケール間の重複コンテンツ

適切な正規またはhreflang設定なしに複数のURL（example.com/en/とexample.com/の両方が同一の英語コンテンツを返す）で同じコンテンツを提供すると、ランキング権威を希薄化する重複コンテンツシグナルが生まれます。常に明示的な正規URLを設定し、ルートURLがリダイレクトするか特定のロケールと明確な関係を持つようにしてください。

2. 間違ったロケールコード

最も頻繁なエラー：

  • en-GBの代わりにen-uk（地域コードは大文字）
  • 簡体字/繁体字中国語にzh-Hansやzh-Hantの代わりにzh
  • 異なるポルトガル語バリアントを提供する場合にpt-BRやpt-PTの代わりにpt
  • IETFランゲージタグを一貫性なく使用する（en-USとen_USを混在させる）

疑問がある場合はIANA Language Subtag RegistryまたはBCP 47を参照してください。

3. Hreflangメソッドの混在

一部のページがHTML <link>タグを使用し、他のページがサイトマップアノテーションを使用している場合、Googleは一貫しない処理を適用する可能性があります。サイト全体で1つのメソッドを選択してください。

4. 孤立したロケールページ

他のページからリンクされておらず、サイトマップにも含まれていないロケールページは、事実上不可視です。すべてのページのすべてのロケールが内部リンクとサイトマップカバレッジを通じて発見可能であることを確認してください。

5. メタデータの翻訳なし

ボディコンテンツを翻訳してタイトルタグとメタディスクリプションを英語のままにしておくことは一般的なショートカットです。これにより、英語以外のSERPに英語の検索スニペットが表示され、ランキングが良くてもクリックスルー率が下がります。

多言語サイトの構造化データ

構造化データ（JSON-LD）はHTMLコンテンツと一緒にローカライズする必要があります。

言語バリアント付き組織スキーマ

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Corp",
  "url": "https://example.com/de/",
  "inLanguage": "de-DE",
  "sameAs": [
    "https://example.com/en/",
    "https://example.com/fr/"
  ]
}

ローカライズされた記事スキーマ

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Vollständiger Leitfaden zur i18n-SEO",
  "inLanguage": "de-DE",
  "url": "https://example.com/de/blog/i18n-seo-guide/",
  "datePublished": "2026-03-01",
  "author": {
    "@type": "Organization",
    "name": "Acme Corp"
  }
}

多言語FAQスキーマ

ローカライズされたFAQコンテンツがある場合、各ロケールのFAQスキーマはそのロケールの質問と回答を使用する必要があります（英語版ではなく）：

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "de-DE",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was ist hreflang?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Hreflang ist ein HTML-Attribut, das Google mitteilt, welche Sprachversion einer Seite für welche Nutzer gedacht ist."
      }
    }
  ]
}

inLanguageプロパティが重要な追加点です。これがないと、Googleが構造化データを間違ったロケールコンテキストに適用する可能性があります。

まとめ

多言語SEOは本当に複雑です。重要な部分を隠さずに簡略化する方法はありません。hreflang仕様は冗長で容赦ありません。URL構造の決定は覆すのが難しいです。コンテンツローカライゼーションは、翻訳だけでは提供できない市場固有の専門知識が必要です。

良いニュースもあります：競合他社のほとんどがこれを間違えています。正しいhreflang実装、ロケール固有のメタデータ、実際にローカライズされたコンテンツ（翻訳されただけでなく）は、国際市場での競争優位性です。

完全なチェックリストをまとめます：

  1. URL構造を早期に選択する — ほとんどのチームにはサブディレクトリ
  2. hreflangを1つのメソッドで実装する — ほとんどのセットアップにはHTMLタグが最も簡単
  3. 4つの要素をすべて含める：自己参照タグ、すべてのロケールバリアント、x-default、相互参照タグ
  4. すべてのメタデータを翻訳する — タイトル、ディスクリプション、Open Graph、構造化データ
  5. 適切なサイトマップを構築する — すべてのページのすべてのロケールのhreflangアノテーション付き
  6. ロケール固有のキーワードリサーチを行う — 検索用語が直訳されると思わないでください
  7. GSCで監視する — hreflangレポートはランキングに影響を与える前に実装エラーを検出します

複数のロケールを大規模に管理する開発チームにとって、翻訳管理レイヤーは技術的実装と同じくらい重要です。Better i18n for developersとNext.jsとの統合方法をご確認ください。再デプロイなしのCDN配信による翻訳更新と、ローカライズされた用語を市場全体で一貫して保つ用語集強制付きAI翻訳を含みます。

i18nを始めたばかりの場合は、SEOレイヤーに入る前にwhat is i18nの入門ガイドが良い基礎になります。

Better i18nはモダンなフロントエンドチーム向けに構築された開発者ファーストのローカライゼーションプラットフォームです。タイプセーフSDK、Gitベースのワークフロー、CDN配信、用語集強制付きAI翻訳 — リポジトリにロケールファイルなし。

better-i18nでアプリをグローバルに展開しよう

better-i18nはAI駆動の翻訳、Gitネイティブなワークフロー、グローバルCDN配信を1つの開発者ファーストプラットフォームに統合します。スプレッドシートの管理をやめて、すべての言語でリリースを始めましょう。

無料で始める → · 機能を探す · ドキュメントを読む

Comments

Loading comments...

関連記事

チュートリアル15m

How to Localize Better Auth: Error Messages, UI, and Emails (Complete Guide)

Ali Osman Delismen
チュートリアル12m

How to Add i18n to Shopify Hydrogen (Complete Guide)

Ali Osman Delismen
チュートリアル14m

How AI Chatbots Are Changing Software Localization

Eray Gündoğmuş
チュートリアル13m

Django i18n と AI翻訳：完全セットアップガイド

Eray Gündoğmuş

もっと見る

開発者向け

Git-firstのローカリゼーションツールとSDK連携

翻訳者向け

コンテキストと用語集を活用したAI翻訳

プロダクトチーム向け

エンジニアリング不要でローカライズ製品をより速く出荷

全機能

Better I18Nの機能を網羅的に紹介