2021年のこと、7つの国をターゲットにしたWordPressのeコマースサイトを持つクライアントが私のところに来ました。翻訳代理店を雇い、すべてをWPMLにプラグインして、完了だと思っていたのです。そのうち5つの市場でのオーガニックトラフィックはほぼゼロでした。低いではなく、ゼロです。ドイツ語ページが英語ページを蝕んでいました。アラビア語ページにはdir="rtl"属性がどこにもありませんでした。hreflangタグはどうかといえば、完全に異なるページに301リダイレクトしているURLを指していました。dir="rtl" attribute anywhere. And the hreflang tags? Pointing at URLs that 301-redirected to completely different pages.
それは3ヶ月の復旧作業でした。適正に請求しましたが、その後もずっと考え続けています。あのサイトのすべての問題は、ローンチ前にまともなチェックリストを実行すれば防げたものだからです。
だからここに私のものがあります。実際に私が進める正確な順序、実際に開くツール、そして経験豊富な開発者でもまだ引っかかる事項です。
---
URL構造から始める（他のことに手をつける前に）
この判断は永遠のものです。もしくは、永遠に近いものなので、そう扱うべきです。ライブの多言語サイトでURL構造を変更し、6ヶ月分のリンク評価が蒸発するのを見てきた代理店があります。
あなたの選択肢は3つです。サブディレクトリ（/fr/）、サブドメイン（fr.）、またはccTLD（site.fr）です。国際的なターゲティングに関するGoogleの公式ドキュメントは、この3つすべてが機能することをかなり明確に述べていますが、トレードオフは実在しています。/fr/), subdomains ( fr.), or ccTLDs ( site.fr). Google's own documentation on international targeting is pretty clear that all three work, but the trade-offs are real.
ほとんどのクライアントでは、私はサブディレクトリを使います。1つのドメイン、1つのオーソリティのプール、1つのクロールバジェットで管理できます。サブドメインは、本当に独立したチームが独立した運用を行っている場合に意味があります（Seahawkは一度、USとEUの製品が実際に異なる規制の製品だったSaaS クライアントを持っていて、そこではサブドメインが正解でした）。ccTLDは、真摯なローカルブランドプレゼンスと、各々のドメインオーソリティを構築するための予算を持つエンタープライズ向けです。
1つ選んでください。ドキュメント化してください。誰かが1行のテンプレートコードを書く前に、承認を得てください。
私が繰り返し見かけるサブフォルダの失敗
デフォルト言語を/en/の下にネストして、ルートから適切なリダイレクトを設定していない人が多いです。ですからsite.com/はhreflangなしで200を返し、site.com/en/はすべてのコンテンツを持ち、Googleは両方を別々の薄いページとしてインデックスします。ルートをAccept-Languageに基づいて適切なロケールにリダイレクトするか、またはルートがデフォルトロケールを直接配信するようにしてください。ぶら下がったままにしないでください。/en/ without setting up a proper redirect from the root. So site.com/ returns a 200 with no hreflang, site.com/en/ has all the content, and Google indexes both as separate thin pages. Set your root to redirect to the appropriate locale based on Accept-Language, or just make the root serve the default locale directly. Don't leave it dangling.
---
Hreflang: 正しくやるか、やらないか
Hreflangはほとんどの開発者を神経質にさせる部分です。当然のことながら。気難しいものです。
Googleからのhreflang仕様は、言語-地域コード（en-GB、fr-FR）を使用し、タグを自己参照的にし（すべてのページが自分自身を参照）、関係を双方向にすることを指示しています（/fr/が/en/を指す場合、/en/は必ず/fr/を指し返さなければなりません）。これらのいずれかを見落とすと、全体が無音で破たんします。Googleは手動アクションを投げません。タグを無視して推測するだけです。hreflang spec from Google tells you to use language-region codes (en-GB , fr-FR ), make the tags self-referential (every page references itself), and make the relationship bidirectional (if /fr/ points to /en/, then /en/ must point back to /fr/). Miss any of those and the whole thing breaks silently. Google won't throw a manual action. It just ignores your tags and guesses.
実際のワークフローは以下の通りです:
- スプレッドシートで最初に完全な URL マトリックスを構築します。すべてのロケール、すべての対応ページ URL です。
- 可能な限りサイトマップではなく <head> 経由で実装します。サイトマップは機能しますが、<head> 実装の方がソースを表示するだけで監査しやすいです。
<head>rather than sitemaps wherever possible. Sitemaps work, but<head>implementation is easier to audit by just viewing source. - hreflang 監査を有効にした状態で Screaming Frog をステージングサイト上で実行します。問題レポートをエクスポートします。Screaming Frog over the staging site with hreflang auditing enabled. Export the issues report.
- Ahrefs のサイト監査とクロスチェックして、orphaned locale ページ (1 つの言語で存在するが、他の言語の対応ページを指す hreflang がないページ) がないか確認します。
- 10～15 ページを手動でスポットチェックします。ソースを表示するだけです。パターンを探します。
人々が絶えず間違えることの 1 つ: x-default です。「英語版」ではありません。言語がロケールタグのいずれにも一致しないユーザーのフォールバックです。en-GB と en-US を具体的にターゲットにしている場合、カナダ英語話者が着地できる場所が必要です。それが x-default です。最も関連性の高いキャッチオールページ (通常はルートまたは言語セレクターページ) を指してください。x-default . It's not "the English version". It's the fallback for users whose language doesn't match any of your locale tags. If you're targeting en-GB and en-US specifically, a Canadian English speaker needs somewhere to land. That's x-default. Point it at your most relevant catch-all page, usually the root or a language-selector page.
---
クロール予算とインデックス登録
小規模サイトではそこまで重要ではありません。8 言語で 50,000 ページのサイトでは、絶対に重要です。
数学は単純です。英語のサイトに6,000ページあり、7言語を追加すると、クローリングとインデックスが必要な48,000ページになる可能性があります。ほとんどのサイトは、それを効率的にサポートするだけの権威性や内部リンク構造を持っていません。
私がやること：
- 実際に翻訳する価値のあるページを監査する。すべてのページが対象ではありません。月に3アクセスしかない2017年のブログ記事にはフランス語版は必要ありません。
- ロケール固有の個別サイトマップ（sitemap-fr.xml、sitemap-de.xml）を使用し、sitemap-index.xmlからすべてを参照します。Google Search Consoleを使うと各言語版を個別に送信・監視でき、デバッグがはるかに簡単になります。
sitemap-fr.xml,sitemap-de.xml) and reference them all fromsitemap-index.xml. Google Search Console lets you submit and monitor each separately, which is far easier to debug. - サブドメインまたはccTLDを使用している場合、Search Consoleでプロパティごとにクローリング統計を確認してください。1つのドメイン内のサブディレクトリの場合、URLパスでフィルタリングしたカバレッジレポートを使用します。
- まだレビューしていない質の低いページや機械翻訳されたページにはNoindexを付けてください。本気です。Googleがスパム品質のコンテンツとしてインデックスしたページは、ドメイン全体に悪影響を与えます。
2019年、旅行セクターのクライアントは12言語版を本番環境にプッシュしました。すべてDeepLで機械翻訳され、人間によるレビューはありませんでした。英語ではアクセスは好調でしたが、他のすべての言語では8週間以内に壊滅しました。DeepLは優れたツール（最初のドラフトとしてまだ使用しています）ですが、レビューされていない大規模出力は信頼シグナルの悪夢です。
---
翻訳とトランスクリエーション
この違いはほとんどのテクニカルSEOが認めるより重要です。
翻訳は言葉を変換することです。トランスクリエーションは意図、トーン、文化的文脈を変換することです。ランディングページ、商品説明、そして検索ランキングのためにお金をかけるコンテンツには、トランスクリエーションが必要です。
実際のチェックリスト項目はこうです。各ターゲット市場について、トラフィック見込みが高い上位20ページを少なくとも母語話者に確認してもらってください。文法だけでなく、そのコピーがその言語の実在する人間らしく聞こえるか、それとも説明書から言語を学んだ機械のように聞こえるかをチェックしてください。
キーワード調査はロケール別に別々に行います。私はこれにAhrefsを使っています。ドイツ語のキーワードは、英語のキーワードのドイツ語版ではありません。検索行動が異なるのです。市場によっては、ユーザーはより形式的に検索します。他の市場では、直訳には決して出現しない略語やスラングを使います。ロケール固有のキーワードマップを構築してください。時間がかかります。その価値があります。
適切なトランスクリエーションに十分な予算がない市場への対応方法
自分に正直になってください。今、ドイツ語を適切にできないなら、ドイツ語を立ち上げないでください。中途半端な多言語対応は、多言語対応がないよりも悪いです。Googlebotは努力に対してクレジットをくれません。
---
ロケール別の技術的なページ内チェック
これは地味な部分です。しかし、成果が出るのはここです。
- `<html>`要素の`lang`属性。ページのロケールと一致する必要があります。`<html lang="fr-FR">`。ホームページだけでなく、すべてのテンプレートを確認してください。 Should match the locale of the page.
<html lang="fr-FR">. Check every template, not just the homepage. - RTL言語の`dir`属性。アラビア語、ヘブライ語、ウルドゥー語、ペルシア語。`<html dir="rtl">`。そしてHTMLセットだけでなく、CSSが実際にそれをサポートしているか確認してください。 Arabic, Hebrew, Urdu, Persian:
<html dir="rtl">. And check that your CSS actually supports it, not just the HTML attribute. - カノニカルタグ。各言語版のページは自身にカノニカライズすべきです。フランス語版ページは英語版ではなく自身にカノニカライズします。これを間違えているのを数え切れないほど見てきました。 Each localised page should self-canonicalise. The French page canonicalises to itself, not to the English equivalent. I've seen this wrong more times than I can count.
- メタタイトルとメタディスクリプション。各言語に翻訳・適応させます。英語のままにしません。[ページ名] | [サイト名]というテンプレートに機械翻訳されたタグラインを入れただけのものにしません。 Translated and adapted per locale. Not left in English. Not auto-generated from a template with
[Page Name] | [Site Name]and a machine-translated tagline. - 構造化データ。Schema.orgマークアップを使用している場合、inLanguageプロパティはそのページの言語を反映する必要があります。eコマースの場合、priceCurrencyが対象地域の通貨と一致していることを確認します。 If you're using Schema.org markup, the
inLanguageproperty should reflect the page's language. For e-commerce, check thatpriceCurrencymatches the locale's expected currency. - 画像のalt属性。翻訳します。目に見えないため見落とされることが多いです。常にチェックします。 Translated. Often overlooked because it's not visible. Always checked.
これらすべてを列ヘッダーとしたシンプルなGoogleシートを使用しています。言語ごとに1行。検証済みでチェックを入れます。クライアントと共有して、何をチェックしたのかを理解してもらいます。
---
ローカル検索とGoogle ビジネスプロフィール
複数の市場に物理的な場所を持つクライアントの場合、多言語SEOはウェブサイトで終わりません。
Google ビジネスプロフィールは、ビジネスの説明とサービス一覧の複数言語に対応しています。各拠点の主言語を正しく設定します。パリにオフィスがある場合、その拠点のGBPはフランス語で、英語本社のプロフィールから逐語的にコピーしたものではなく、フランス語の説明が必要です。
NAP一貫性（ビジネス名、住所、電話番号）は市場ごとのローカルサイテーション ディレクトリ全体にわたって重要です。ドイツではDas ÖrtlicheとGelbe Seitenで一覧が正しいことを確認する必要があります。Googleだけではなく。フランスではPagesJaunesです。各市場にはそれぞれのサイテーション エコシステムがあります。対象国ごとの上位10のサイテーション ソースをマッピングするために午後を費やすのは十分な価値があります。
---
ローンチ後のモニタリング
ローンチはゴールではない。見落とした部分を発見する始まりだ。
多言語サイトにおける私のローンチ後モニタリング体制：
- Google Search Consoleをロケール別に（サブドメインまたはccTLD）、または URL プレフィックスプロパティをサブディレクトリパス別に設定する。
- Search Consoleの「Legacy tools」(レガシーツール)の下にある「International Targeting」(国際ターゲティング)レポートを確認する。ローンチから数週間以内にhreflangエラーが表示される。
- Ahrefs内でロケール別にランク追跡を設定し、正しい国と言語のターゲティングを使用する。「English, US」で追跡されたキーワードと、同じキーワードを「German, Germany」で追跡した場合では、異なる順位が表示される。
- 最初の6ヶ月間は毎月クロール範囲をモニタリングする。新しいロケールページが「Discovered, not indexed」(発見されたがインデックスされていない)の状態で数週間止まることがある。通常はクロールバジェットまたは内部リンクの問題だ。
- 四半期ごとにカニバライゼーション(重複)をチェックする。同じ国の同じクエリに対して2つのロケールページが競合しているのは、URLまたはhreflang設定で何か間違ったことが起きた兆候だ。
フィンテック系クライアントの痛い経験の後に追加した項目がひとつある：IP ベースのリダイレクトが hreflang をオーバーライドしていないことを確認することだ。CDNまたはサーバーがIPジオロケーションに基づいてユーザーをリダイレクトしている場合、通常US IPからクロールするGooglebot が非英語ページを見つけられない可能性がある。そのフィンテック系クライアントはCloudFrontルールで非US IPを積極的にリダイレクトしていた。ヨーロッパのページがゼロインデックスになった理由を診断するのに2週間かかった。check that IP-based redirects aren't overriding hreflang. If your CDN or server is redirecting users based on IP geolocation, Googlebot (which usually crawls from US IPs) might never see your non-English pages. That fintech client had CloudFront rules aggressively redirecting non-US IPs. Took us two weeks to diagnose why the European pages had zero indexation.
FAQ
FAQ
言語ごとに Google Search Console のプロパティを別々に作成する必要がありますか?
必ずしもそうではありません。1つのドメイン上でサブディレクトリを使用している場合（site.com/fr/ など）、サブディレクトリごとに URL プレフィックスプロパティを使用するか、ルートドメインプロパティを使用して URL パスでフィルタリングすることができます。サブドメインまたは別々の ccTLD を使用している場合は、市場ごとのクリーンなデータが得られるため、管理上のオーバーヘッドに見合う価値があります。site.com/fr/), you can use a URL-prefix property per subdirectory, or just use the root domain property and filter by URL path. If you're on subdomains or separate ccTLDs, separate properties are worth the admin overhead because you get cleaner data per market.
2024年の SEO では機械翻訳で十分ですか?
最初のドラフトについては、はい。人間によるレビューなしに公開するなら、いいえ。DeepL と Google Translate は本当に良くなりましたが、文法的には正しく、トーン的には平坦なコンテンツを生成します。検索エンジンは、言語として自然に読める コンテンツと翻訳されたコンテンツを区別するのがますます上手くなっています。機械翻訳を使ってスピードを上げ、インデックス前に価値の高いページをネイティブスピーカーにレビューしてもらいましょう。
翻訳カバレッジが部分的しかない市場にはどう対応しますか?
翻訳されていない、または部分的に翻訳されたページが完成するまで noindex を設定してください。完成していないロケールページを公開するためだけに公開しないでください。言語でのシンコンテンツによる信頼シグナルへのダメージは、公開の遅延よりも逆転させるのが難しいです。
hreflang の最も一般的な間違いは何ですか?
自己参照タグの欠落です。すべてのページには、すべての同等ページを指すのに加えて、自分自身を指す hreflang タグが必要です。開発者は多くの場合、相互参照を正しく実装しながら自己参照を忘れます。Screaming Frog を実行すれば約30秒で検出されるため、すべてのローンチ前に実行してください。
URLsを翻訳すべきですか、それとも英語のまま保持すべきですか？
翻訳してください。/fr/chaussures/は/fr/shoes/よりもフランス語の検索で好成績を上げます。スラッグが関連性シグナルに貢献するからです。フランス語ユーザーにとってもより信頼感があります。実装の手間（ロケール固有のルーティングとCMSのスラッグ翻訳が必要）をかけても、真剣に狙うマーケットであれば価値があります。/fr/chaussures/ outperforms /fr/shoes/ in French search because the slug contributes to relevance signals. It also looks more trustworthy to French-speaking users. The extra implementation effort (you need locale-specific routing and slug translation in your CMS) is worth it for any market you're seriously targeting.
---
多言語SEOはチェックボックスに一度チェックを入れて終わりではありません。これは一つの規律です。上記のチェックリストは、予想外のローンチ後対応から私を救ってくれた回数は数え切れません。そしてまだ進化し続けています。新しいビルドのたびに私は何かを学んでいます。最近の気づき：非デフォルトロケールリクエストに対してCDNが何をしているかを確認してからサイトの準備ができたと宣言してください。必ずです。