Astroウェブサイトの翻訳方法:i18nルーティングとSEO
i18nルーティング、コンテンツコレクション、ローカライズしたSEOタグ、hreflang対応サイトマップ、MDXの編集ワークフローを活用し、クロール可能なAstroのロケール別URLを公開しましょう。

静的生成を優先するAstroのアーキテクチャは、多言語のマーケティングサイトに適しています。ただし、i18nルーティング、コンテンツコレクション、SEOアノテーションを、開発の主要な作業として扱うことが前提です。Astroの開発者がロケールごとのフォルダーをきれいに整えて公開した後で、hreflangがない、レイアウトの共通UIが英語のまま、ハイブリッド構成のアイランドがクライアント側で未翻訳の文字列を表示するといった問題に気づくケースは少なくありません。
このガイドでは、Astroサイトを翻訳する方法を解説します。クロール可能なロケール別HTML、コンテンツコレクションの整理、レイアウトとSEOタグのローカライズ、hreflang対応のサイトマップ、ハイブリッドレンダリングの注意点、MarkdownとMDXの編集ワークフローまで、すべてGoogleの多言語サイトに関する要件に基づいて説明します。根拠のないランキング要因は取り上げません。
このガイドでわかること
- Astroのi18nルーティングは、クロール可能なロケール別ページをどう実現する?
- 言語ごとのコンテンツコレクションはどう整理する?
- Astroのレイアウト共通UIとSEOタグをローカライズするには?
- Astroの静的出力向けにhreflangを生成するには?
- 多言語Astroサイトでハイブリッドレンダリングが必要になるのはいつ?
- Markdown/MDXコンテンツに翻訳ワークフローを組み込むには?
- Astroの多言語対応でよくあるミスは?
- Astroの開発チームが翻訳プラットフォームを導入すべきタイミングは?
要点:ロケール別の静的HTMLがAstroのSEO上の強み
結論:Astroのi18nルーティングを使い、ナビゲーション、メタデータ、メインコンテンツを含めて完全にローカライズしたHTMLを、ロケールごとに異なるURLで事前レンダリングします。そのうえで、各言語版の間に相互参照するhreflangを追加します。
ロケール別URLごとに事前レンダリングしたHTMLを用意する方法は、言語版ごとに異なるURLを設け、クロール可能にするというGoogleの推奨に沿っています。Astroはビルド時にロケール別の静的ファイルを出力できるため、クライアント側の言語切り替えに依存せず、ユーザーが受け取るものと同じ言語別ドキュメントをクローラーにも提供できます。
Googleは、Cookieやブラウザーの言語だけに頼るのではなく、言語版ごとにクロール可能な別々のURLを用意することを推奨しています。Astroのastro:i18nルーティング(または同等のロケールプレフィックス方式)では、ロケールごとに出力パスを生成することで、この構成を実現できます。
Astroのi18nルーティングとURL設計
Astroでは、対応するロケールとデフォルトのロケールを明示的に設定します。一般的なURLパターンは次のとおりです。
- デフォルトのロケールにもプレフィックスを付ける(
/en/about、/fr/about)— 言語が明確で、アノテーションも設定しやすい方式です。 - デフォルトのロケールを省略する(英語は
/about、フランス語は/fr/about)— 主要市場向けのURLをシンプルにできます。hreflangで対応関係を明示してください。
astro.config.mjsで、対応するロケール構成に合わせてi18n.locales、i18n.defaultLocale、i18n.routingを設定します。テンプレートが正しい言語で表示されるよう、各ルートファイルではAstroのAPIから現在のロケールを取得してください。
Googleは、主に画面に表示されるコンテンツからページの言語を判断します。各言語版では、コンテンツとナビゲーションを基本的に1つの言語に統一してください。ナビゲーションコンポーネントをロケール対応の翻訳辞書と連携させ、ヘッダーやフッターの言語を本文と揃えましょう。
推定した言語や所在地に基づく自動リダイレクトは避けてください。Googleは自動リダイレクトを推奨しておらず、代わりに、別の言語版のURLへリンクする言語セレクターをユーザーに見える形で設置することを勧めています。
言語ターゲティングと国別ターゲティングの戦略上の違いについては、国際SEOと多言語SEOの違いをご覧ください。
ロケール別のコンテンツコレクション
Astroのコンテンツコレクションは、ブログ、ドキュメント、ランディングページのテキストを管理する仕組みです。多言語コンテンツは、方針を明確にして整理しましょう。
- ロケールごとにコレクションのディレクトリを分ける(
src/content/blog/en/、src/content/blog/fr/)。スキーマは共通化します。 - コンテンツ量が少ない場合は、フロントマターのロケールフィールドで、単一のコレクションを絞り込みます。
- シンボリックリンクまたは自動生成によるインデックスを用意し、各ロケールで利用可能な項目だけを一覧にします。中身のないロケール別ページは公開しないでください。
ローカライズした各ドキュメントでは、そのロケールに適したアセットと内部リンクを参照してください。フランス語の記事から英語しかないドキュメントにリンクすると、ユーザーの信頼と言語の一貫性が損なわれます。
あるロケールに同等のコンテンツが存在しない場合は、実態のないhreflangの代替言語ページを設定しないでください。対応するページを翻訳するか、準備が整うまでその参照関係を設定しないようにします。
レイアウト、SEO、Open Graphのローカライズ
レイアウトの共通UIは、ロケールに対応したコンポーネントに集約します。
BaseLayout.astroがAstro.currentLocale(または使用しているi18nヘルパー)を読み取り、JSONまたはTSの辞書から文字列を選択します。<title>とメタディスクリプションは、英語でハードコードせず、ページごとのフロントマターやCMSのフィールドから取得します。- Open GraphタグとTwitterタグには、ローカライズしたタイトルと説明を反映します。
html lang属性を現在のロケールに合わせます(アクセシビリティと明確さのためです。Googleは引き続き、表示されるコンテンツから言語を判定します)。
ローカライズしたSEOタイトルとメタディスクリプションは、ロケール別URLごとに固有のものにしてください。ナビゲーションだけを翻訳し、記事本文は英語のままにするなど、定型部分だけの表面的なローカライズでは、言語版として不十分です。
hreflangとサイトマップの生成
Astroサイトでも、別の言語版が存在する場合は、ロケール別URL間で相互参照するhreflangを出力する必要があります(HTML、ヘッダー、サイトマップのいずれかで設定します)。ビルド時に、コンテンツの対応関係からロケール対応表を生成します。
- 対応する各ページについて、公開済みのすべてのロケール別URLを一覧にします。
- 各静的HTMLファイルの
<head>内に<link rel="alternate" hreflang="..." href="..." />を出力します。または、 - 各URLエントリに
xhtml:linkで代替言語版を指定したXMLサイトマップを生成します。
XMLサイトマップは、各言語版の検出に役立ちます。また、hreflangの実装方法として採用する場合は、xhtml:linkによるhreflangアノテーションを含めることができます。
各言語版のURLには、同じ言語の正規URLを明確に指定してください。Googleの正規URLに関するガイダンスは、動的サイトと同様に静的サイトにも適用されます。
サイトマップの生成をCIに組み込み、コンテンツの変更に合わせてhreflangも更新されるようにします。@astrojs/sitemapとカスタムのシリアライズ用フックを組み合わせると効果的です。
編集チームが開発側の出力と連携してアノテーションを管理する方法については、多言語SEOの基礎をご覧ください。
ハイブリッド構成のアイランドと動的コンテンツの注意点
Astroのアイランドアーキテクチャでは、React、Vue、Svelteのコンポーネントを選択的にハイドレーションできます。多言語対応では、次の点に注意してください。
- クライアント側のみで動作するウィジェットは、JavaScriptが読み込まれるまで英語で表示される可能性があります。言語判定とUXの両方に悪影響を及ぼします。
- 可能な限り、正しいロケールでアイランドの初期HTMLをサーバー側でレンダリングしてください。
- 動的ルート(
output: 'server'またはhybrid)では、SSRで生成されるHTMLがURLプレフィックスと一致するように、ミドルウェア経由でロケールを渡す必要があります。
ハイブリッドレンダリングが必要なのはどのような場合でしょうか。コンテンツがパーソナライズされている場合、閲覧に認証が必要な場合、リクエスト時に取得される場合は、ハイブリッドレンダリングまたはサーバーレンダリングを使用します。ただし、検索上位を目指すマーケティングページでは、クローラーがアクセスできる静的なロケール別シェルも出力してください。マーケティング向けの各ロケールは静的生成を基本とし、動的レンダリングは認証が必要なアプリ領域に限定します。
MDXとCMSコンテンツの編集ワークフロー
多くのチームにとって、MarkdownとMDXは引き続き、Astroで最も保守しやすいコンテンツレイヤーです。
- UIの共通部分には、翻訳ファイル内の原文文字列(
src/i18n/fr.json)を使用します。 - 長文コンテンツには、ロケール別ファイルごとのフロントマターを使用します。
- ロケール別のバッチごとにプルリクエストを作成し、用語集との整合性を確認します。
- 大量のドキュメントはCATツールまたはTMS向けにエクスポートし、
src/contentに再インポートします。
Googleの有用なコンテンツに関するガイダンスでは、ユーザーを第一に考えたページが重視されています。機械翻訳の出力をレビューせずにそのまま掲載すると、各ロケールの体験が内容の乏しいものになります。
公開の判定基準を定めましょう。ロケールの必須項目が欠けている場合、内部リンクが別のロケールへ移動してしまう場合、またはサンプルのhreflangペアで相互参照を確認できない場合は、マージしないようにします。
実装チェックリスト
よくある間違い
- ローカライズ済みのルートでレイアウトのシェルが英語のままになっている。
- 静的パスを手動管理していたためにhreflangが欠落している。
- 代替言語版を明示せずにデフォルトロケールを非表示にしているため、相互参照が成立していない。
- 言語ごとに個別のURLがないまま、言語切り替えをクライアント側でレンダリングしている。
- 翻訳を部分的にマージした結果、MDX内に複数の言語が混在している。
- ダミーテキストや英語のプレースホルダーを残した未完成のロケールを公開している。
- 大規模な静的サイトでサイトマップを省略しているため、ページの発見が遅れる。
- 不用意に別の言語のページをcanonicalの参照先に指定している。
Bingのウェブマスターガイドラインでも、各市場でのインデックス登録に向けて、クロール可能で有用なコンテンツと明確なサイト構造が重視されています。
従来の検索と回答エンジンに共通する基盤
Astroで生成するロケール別の静的HTMLとコンテンツコレクションの共通基盤は、Google、Bing、回答エンジンのいずれにおいても重要です。必要なのは、クロール可能な各言語版、明確なエンティティ、根拠に裏付けられた主張、実態に即した構造化データ、そして英語だけのシェルではない本格的なローカライズです。以下のガイドは、同じ多言語配信の基準をプラットフォームごとの視点で捉えるために活用してください。
プラットフォーム別ガイド:Google Search
Google検索でページが検出されるには、クロール可能なロケール別URL、各言語に適したHTML、正確なタイトルと見出し、代替言語版がある場合は相互に参照するhreflangが必要です。技術的な基盤には、インデックス登録可能なコンテンツ(Cookieだけに依存した言語切り替えでは不十分)、ローカライズされたメタデータ、サイトマップ、適切なcanonicalの運用が含まれます。コンテンツ品質の要となるのは、各言語でユーザーを第一に考えたメインコンテンツです。権威性は、翻訳ツールの宣伝ではなく、組織情報の明確さと裏付けとなる情報源から生まれます。多言語対応では、市場別・言語別の各URLが単独で成り立つ必要があります。Search ConsoleのカバレッジとURL検査を使い、ロケールごとに状況を測定してください。確かな点と不確かな点:Googleは多言語対応とhreflangの動作を文書化していますが、特定のCMSや機械翻訳のポストエディット(MTPE)ワークフローによる検索順位は保証していません。
プラットフォーム別ガイド:Bing
Bingは、GoogleがURLやコンテンツの明確さに求めるものと同様に、構造が明確でクロール可能な多言語ページを検出し、インデックスに登録します。技術的な基盤には、取得可能なロケール別URL、有用なコンテンツ、Bing Webmaster Toolsでの監視が含まれます。UI要素だけを翻訳するのではなく、見出し、主張、FAQのローカライズを優先してください。権威性を示す要素としては、引き続き信頼できる情報源と一貫したエンティティが重要です。多言語対応では、クライアント側だけで動作する切り替え機能の背後に各言語版を隠さないでください。Bing Webmaster Toolsでインデックス登録状況とクロール統計を測定しましょう。確かな点と不確かな点:Bingのガイドラインは、クロール可能で有用なコンテンツを重視しています。翻訳ツールに関して、Bing独自のランキング要因を根拠なく想定しないでください。
プラットフォーム別ガイド:ChatGPT
ChatGPTは、各言語版が明確で、回答に活用しやすい公開ページを引用または要約することがあります。情報の発見は従来のクロールに基づく順位付けとは異なり、可視性は情報源として選ばれたり、回答内で参照されたりする形で現れます。技術的な基盤は、やはりアクセス可能なHTMLのURLです。テキストを隠してしまうウィジェット型のオーバーレイではありません。コンテンツ面では、直接的な回答、FAQ、用語集に基づく一貫した用語が役立ちます。権威性は、根拠と、ロケールをまたいだエンティティの一貫性から生まれます。多言語対応では、各ロケールのページが単独で読んで理解できる必要があります。測定は完全ではないため、引用状況の確認は仮説の検証として扱ってください。確かな点と不確かな点:MTPEや特定のCMS連携によってChatGPTに引用されることを保証する文書化された根拠はありません。
プラットフォーム別ガイド:Gemini
Geminiと関連するGoogleのAIサービスでは、一貫したエンティティ、正確な構造化データ、インデックス登録可能なローカライズ済みページが役立ちます。可視性とは、参照・認識されることであり、Gemini独自のランキング要因を根拠なく想定することではありません。技術的な基盤は、Google検索のクロール可能性やメタデータの品質と共通しています。コンテンツでは、各言語で主張や定義を明確に示す必要があります。権威性は、組織情報の一貫性と裏付けに左右されます。多言語対応では、用語集で製品名を統一することで、ロケール間の混乱を減らせます。従来どおりSearch Consoleで測定しつつ、AIの回答を抽出して定性的にも確認してください。確かな点と不確かな点:Geminiの挙動は、hreflangや各言語版に関するGoogle検索の公式ガイダンスの代わりにはなりません。
プラットフォーム別ガイド:Google AI Overviews
Google AI Overviewsは、回答の裏付けとなるページへのリンクを表示することがあります。掲載対象となるための基本は、引き続きユーザーを第一に考えた、インデックス登録可能なコンテンツです。AI Overviewsは言語切り替え機能ではなく、hreflangの代わりにもなりません。技術的な基盤は、クロール可能なロケール別HTMLと、事実に即した構造化データです。コンテンツ面では、各言語での簡潔な回答と明確な見出しが重要です。権威性の評価も、有用なコンテンツに求められる水準に沿ったものです。多言語対応では、翻訳されたページがAI Overviewsに掲載される保証はありません。Search Consoleで生成AI関連のレポートが利用できる場合はそれを使って測定し、従来のインデックス指標とは分けて管理してください。確かな点と不確かな点:どのような翻訳ワークフローでも、AI Overviewsへの掲載を約束することはできません。
GlotEOが担う役割
Astroを使うチームが翻訳プラットフォームを導入すべきタイミングはいつでしょうか。用語集の徹底、ロケール別のレビュー待ち管理、hreflangマトリクスへの対応が、JSONやMDXの手動プルリクエストでは追いつかなくなったときです。
エンジニアリング側でAstro i18nのルーティングを完璧に実装できても、ローカライズには用語集、レビュー待ち管理、厳格な公開運用が欠かせません。GlotEOのウェブサイトローカライズを詳しく見ることで、制作要件、翻訳ワークフロー、QAの判定基準を静的サイトのコンテンツパイプラインと連携できます。MDXや辞書の更新と、Astroのビルドで出力されるhreflangやSEOメタデータの整合性を保ちましょう。
翻訳量が増え、JSONの手動編集では対応しきれなくなったら、GlotEOの料金とプランを比較してみてください。また、多言語SEOワークフローを支援するツールを活用して、開発者とコンテンツチームの双方がロケールマトリクスと編集要件を把握できるようにしましょう。
実装に先立って言語と対象国の戦略を検討する場合は、このAstroチュートリアルと併せて国際SEOと多言語SEOの違いもお読みください。
参考文献
- この記事で紹介した指針の根拠資料(Bingウェブマスターガイドライン)
- この記事で紹介した指針の根拠資料(rel=canonicalなどの方法で正規URLを指定する方法)
- この記事で紹介した指針の根拠資料(有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成)
- この記事で紹介した指針の根拠資料(ページのローカライズ版をGoogleに知らせる)
- この記事で紹介した指針の根拠資料(多地域・多言語サイトの管理)
- この記事で紹介した指針の根拠となる資料(サイトマップについて学ぶ)