弊社ホームページを日本語、英語の言語切り替えに対応しました

こんにちは。代表の高橋です。弊社が開発中の詩を気軽に投稿してシェアできるサイトPoetryBirdのサービスを日本語、英語の言語切り替えに対応させたこともあり、弊社ホームページも日本語と英語を切り替えできるようにしました。

言語切り替えの際に弊社ホームページにおいてはja（日本語）とen（英語）でURLを分けて

で表示分けするようにしました。

Next.jsでの多言語化対応は多言語化のためのライブラリであるi18nextライブラリで対応できるのですが、多言語化する際に、言語ごとにURLを分ける方法（例：/ja/page、/en/page）を採用するのか、それとも単一のURLのまま言語切り替えできるようにするのかは、結構悩むところでした。

結果として、ユーザーが日本語圏、英語圏の人も同じ投稿された詩を元言語のまま見るようにするため、PoetryBirdのサービスでは単一URL方式を用いることにして、お知らせ等については言語判定で切り替えを行う形にしました。一方、弊社ホームページでは検索エンジンのインデックス向けとして言語ごとにURLを分ける方針としました。これからは検索エンジン最適化（SEO）ではなく、AIによる直接的な回答生成を目的としたアンサーエンジン最適化(AEO)に移行していくとは思われますが、一旦はSEOも含めて検討しての上記となっています。なお、そうった区分けで実装した後に、それで良いのかどうかは、今後の動向や状況を見ながら、検証していこうと思います。

1. 言語ごとにURLを分ける方法（例：/ja/page、/en/page）

メリット SEOに強い（推奨される方法）:

Googleなどの検索エンジンが言語・地域ターゲティングを正確に認識しやすくなる。言語ごとにインデックスされ、検索結果に表示されやすくなります。

ユーザー体験（UX）: URLを見るだけで現在の言語が明確にわかる。特定の言語のページを共有する際に、意図した言語のページを共有可能。

2. 同じページのURLのまま言語を切り替える方法（例：/page?lang=ja、またはCookie/Accept-Languageヘッダーに依存）メリット URL構造のシンプルさ: 言語コードがURLパスに含まれないため、URL構造がシンプルになります。パスの管理が容易。

実装の柔軟性: クエリパラメータやCookie/ヘッダーを使用するため、アプリケーションレベルで言語切り替えのロジックをより自由に制御できる。

デメリット SEOが弱い（非推奨）: 検索エンジンが言語を認識しづらい: URLが同じであるため、検索エンジンがコンテンツの言語を特定し、適切にインデックスするのが難しくなる。言語ごとのトラッキングが困難: 特定の言語でのパフォーマンスを正確にトラッキングするのが難しくなる。

ユーザー体験（UX）: URLを共有しても、受け取った側の設定（Cookieなど）によっては意図しない言語で表示される可能性があり（セッションやCookie、ブラウザの言語設定に依存する場合）。クエリパラメータに依存する場合ではURLが長くなることがあります。

特徴	言語ごとにURLを分ける (例: /en/pageと/ja/page)	同じURLで言語を切り替える (例: /page?lang=enやブラウザ言語設定に基づく切り替え）)
SEO	非常に強い（推奨）	弱い（非推奨）
UX	共有やブックマークで言語が維持される	共有時に言語設定が失われる可能性がある（ブラウザの言語設定で表示切り替えなどしている場合）
URL構造	言語コードが入るためやや複雑	シンプルなまま

なお、News & Blogの部分については、基本的に日本国内向けの記事となるため、日本語のみの記事としています。ここについてもContentfulのCMSでコンテンツ管理しているので、複数言語で記事を書くことは可能ですが、現時点では対応は検討していないところです。