あるクライアントが 2021 年に私のところに来ました。SaaS 製品が 2 年間 5 つの言語でライブになっていました。ドイツからのトラフィック: 1 ヶ月あたり 38 セッション。フランスから: 22 セッション。英語ページはランク付けされていましたが、すべてのローカライズされたバージョンは基本的に見えないようなものでした。彼らはコンテンツを翻訳するために代理店に料金を支払い、誰かが WPML をインストールしてから、みんなが仕事は完了したと思い込んでいました。
まったく完了していませんでした。
ローカライゼーション SEO は、仕事の 60% を正しく行うことが 0% 行うこととほぼ同じ領域の 1 つです。hreflang を見落とす。間違った URL 構造を選ぶ。ローカルシグナルをスキップする。結果: Google は翻訳ページを完全に無視するか、さらに悪いことに、重複コンテンツとして扱ってフィルターで除外します。私は Seahawk での過去 9 年間に数百のサイトでこの問題を修正してきましたが、失敗パターンはほぼ常に同じです。
では、実際に機能するものを見ていきましょう。
---
翻訳とローカライゼーションは異なる
これはすべてのクライアントに最初に伝えることです。翻訳とは、ある言語から別の言語へ単語を変換することです。ローカライゼーションとは、特定の市場向けにページの意図を再構築することです。
2022年後半に対応していたイギリスの電子商取引クライアントを例に挙げます。彼らは高級キッチンナイフを販売していました。ドイツ語ページは英語コピーを逐語訳したもので、「Sunday roasts（日曜日のローストビーフ）に最適」というようなフレーズも含まれていました。ドイツ人は日曜日のローストビーフをしません。そのコピーは文法的には正しいが、まったく間違っていたのです。
文化的な要素を超えて、SEOの影響は実際のものです。キーワード検索ボリュームは翻訳できません。英語の検索クエリ「best chef knife」は月間約8,100回の検索がイギリスであります。ドイツ語の同等表現「bestes Kochmesser」ははるかに少ないですが、「Kochmesser Test」（大まかに「シェフナイフのテスト/レビュー」）は膨大です。翻訳されたページが英語キーワードの直訳をターゲットにしている場合、間違ったものに最適化していることになります。
ローカライズされたコンテンツを1語も書く前に、Google Keyword Plannerで国を正しく設定して、またはAhrefsで国フィルターを適用して、対象言語の対象ロケールでキーワード調査を実施してください。これらは英語調査を実行することと同じではありません。キーワードの観点から、各市場を新しいサイトとして扱ってください。in the target language, in the target locale using Google Keyword Planner with the country set correctly, or Ahrefs with the country filter applied. These are not the same as running English research. Treat each market as a new site from a keyword perspective.
実際にはローカライゼーションとは何を意味するのか
- 現地通貨での価格設定、現地の支払い方法への言及
- 日付、住所、単位をその国の形式で表示する（DD/MM対MM/DDは重要です）
- 現地で響く例、慣用句、参考資料
- 国固有の信頼シグナル（ドイツの購入者は現地認定を信頼する；フランスの購入者はブラジル人とは異なるソーシャルプルーフに反応する）
URLstructure: これを間違えるとほかに何をやっても無駄
URLstructure: これを間違えるとほかに何をやっても無駄
このやり取りで多くのプロジェクトが脱線するのを見てきた。ccTLDかサブドメインかサブディレクトリか。みんなそれぞれの立場で譲らない。
何百もの国際サイトを構築・移行してきた率直な意見を言うと：ほとんどのビジネスにはサブディレクトリが通常は正解だ。yoursite.com/de/みたいな構造で、de.yoursite.comやyoursite.deじゃなく。実用的な理由がある：ドメインオーソリティがすべて統合される、ひとつの場所で管理するのが簡単、hreflangが正しく設定されていればGoogleの扱いも良い。subdirectories are usually the right call for most businesses. Something like yoursite.com/de/ rather than de.yoursite.com or yoursite.de. The reasons are practical: all your domain authority consolidates, it's easier to manage in one place, and Google handles it well when hreflang is set up correctly.
ccTLD（yoursite.deやyoursite.fr）は確かに強いローカルシグナルを出す。特定のマーケットで真摯に取り組んでいて、本質的に別々のサイトを運営することにコミットできるなら、価値がある。Seahawkのフィンテッククライアントが2020年に6カ国の別々のccTLDにこだわった。確かにそれらのマーケットでよく機能した。だが開発オーバーヘッドは3倍になった。クライアント向けに構築するほとんどのエージェンシーにとって、それは現実的じゃない。yoursite.de , yoursite.fr) do send a strong local signal. If you're a serious player in a specific market and you can commit to running essentially separate sites, they're worth it. Seahawk had a fintech client that insisted on separate ccTLDs for six countries in 2020, and yes, it performed well in those markets. But their dev overhead tripled. For most agencies building for clients, that's not realistic.
サブドメイン（de.yoursite.com）はほとんどの場合、いいとこどり状態だ。サブディレクトリより保守が難しく、ccTLDより弱いオーソリティシグナル。CMSアーキテクチャが本当にそれを強制する場合を除き、避けるべき。de.yoursite.com) are the worst of both worlds in most cases. Harder to maintain than subdirectories, weaker authority signal than ccTLDs. I'd avoid them unless your CMS architecture genuinely forces the issue.
何を選ぶにせよ：一貫性を保て。構造を混ぜるな。/fr/ページとfr.サブドメインが同時に実行されてる、両方インデックスされてるサイトを引き継いだことがある。悪夢だ。be consistent. Don't mix structures. I've inherited sites with /fr/ pages and a fr. subdomain running simultaneously, both indexed. It's a nightmare.
---
Hreflang: 国際SEOで最も一般的に壊れる部分
このポストからひとつ持って帰るなら、これを。
hreflanは、Googleにどのページのどのバージョンを、どのユーザーに、どの言語と国で表示するかを指示します。設定を誤ると、米国英語ページがドイツで表示されたり、ドイツ語ページがまったくランク付けされなかったり、あるいは私が特に気に入っている災害として、x-defaultが別の場所へリダイレクトするページを指している、といった事態が起こります。 tells Google which version of a page to show to which user in which language and country. Get it wrong and you'll have your US English pages showing up in Germany, your German pages not ranking at all, or, my personal favourite disaster, your x-default pointing to a page that redirects somewhere else entirely.
タグフォーマットは<head>内で以下のようになります:<head>:
`` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> `` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> ``
よく人々がつまずくポイントが何点かあります:
- すべてのページは、自分自身を含む、すべての代替ページを参照する必要があります。ドイツ語ページが英語ページへのリンクを含まず、英語ページがドイツ語へのリンクを含まない場合、実装は壊れています。 If your German page doesn't link back to the English page, and the English page doesn't link back to German, the implementation is broken.
- 言語コードと言語-地域コード。hreflang="en"は「英語、任意の地域」を意味します。hreflang="en-GB"は「英語、具体的には英国」を意味します。英国と米国を別々にターゲットしようとしている場合は、地域コードが必要です。
hreflang="en"means "English, any region."hreflang="en-GB"means "English, United Kingdom specifically." If you're trying to target UK vs US separately, you need the region code. - 返却タグ。ドイツ語ページは英語ページを指すタグを含む必要があります。英語ページはドイツ語へ戻すタグを含む必要があります。両方とも。常に。 The German page must contain a tag pointing to the English page. The English page must contain a tag pointing back to German. Both. Always.
- canonical タグとの一貫性。hreflang 代替URLとそのページの canonical URL は完全に一致する必要があります。末尾のスラッシュを含めて、正確に。 Your hreflang alternate URL and your canonical URL for that page must match. Exactly. Including trailing slashes.
手動でこれらを設定するときは、Aleyda SolisのhreflangタグジェネレーターとScreaming Frogで監査します。常に。Aleyda Solis's hreflang tag generator when I'm setting these up manually. And I always audit with Screaming Frog after. Always.
---
ローカルシグナル：ローンチ後に誰もが見落とすポイント
正しいhreflangとよくローカライズされたページがあれば、おそらく50%まで到達できます。残りの50%はシグナル、つまりGoogleがあなたを本当にそのマーケットの正規な事業体だと考える理由があるかどうかです。
ほとんどのサイトでは、以下を意味します：
- ローカルバックリンク。ドイツの.deドメインからあなたの/de/ページへのリンクは意味のある重みを持ちます。フランスのメディアからあなたのフランス語ページへのリンク、同じことです。USのブログからあなたのドイツ語コンテンツへのリンクは、人々が想定するほどには役に立ちません。 A link from a German .de domain to your
/de/pages carries meaningful weight. Links from French media to your French pages, same thing. Getting a link from a US blog to your German content doesn't help nearly as much as people assume. - Google Business Profile。物理的な拠点があれば、登録住所さえあれば、その場所のGBPを設定してください。きちんと記入してください。これはローカルパック表示のための必須条件です。 If there's any physical presence, even a registered address, set up a GBP for that location. Fill it out properly. This is table stakes for local pack visibility.
- ローカルスキーマ。正しい国、住所形式、電話番号形式でLocalBusinessスキーマを追加してください。英語のスキーマを単にコピーして説明を翻訳するだけではいけません。構造化データはロケール固有の仕様に合わせる必要があります。 Add
LocalBusinessschema with the correct country, address format, and phone number format. Don't just copy your English schema and translate the description. The structured data needs to match the locale specifics. - ホスティング位置。CDNの登場により以前ほど重要ではありませんが、CDNを使用している場合（そして使用すべき）、エッジノードがヨーロッパのユーザーをヨーロッパのサーバーから提供していることを確認してください。Cloudflareの無料プランでこれに対応します。大きなランキング要因ではありませんが、その地域のTTFBに貢献し、それが重要です。 Less important than it used to be given CDNs, but if you're using a CDN (and you should be), confirm your edge nodes are serving European users from European servers. Cloudflare's free plan handles this. It's not a huge ranking factor but it contributes to TTFB in that region, which matters.
2019年、私はスペインでランク付けしようとしていたヘルスサプリメント分野のクライアントがいました。彼らのローカライズは適切でした。彼らのhreflangは正しかったです。しかし彼らはスペイン語のバックリンクがゼロ、マドリードアドレスのGBPは申請されていない、スキーマにはまだ英国の電話番号が記載されていました。これら3つを約4ヶ月かけて修正することで、彼らは目標キーワード3つについて4ページ目から1ページ目に上昇しました。
---
コンテンツの深さはマーケットによって異なる
これはキーワードリサーチだけでは完全には明らかにならない事柄です。情報を求める市場もあれば、シンプルな商品ページで成約する市場もあります。
ドイツはこのことで有名です。ドイツの検索ユーザーは、何かを購入する前に、詳細な比較コンテンツ、スペック表、明確な返品ポリシーを求める傾向があります。イギリスで成約する300文字の商品ページは、ドイツで成果を上げるには900文字のFAQセクション付きが必要な場合があります。
日本も同様です。日本の商業的なクエリの検索結果には、非常に詳細で長編のコンテンツが頻繁に表示されます。SERPは異なり、ユーザー行動は異なり、コンテンツへの期待もそれを反映しています。
私が言いたいのは、できるからといってすべての市場向けに2,000文字を書けということではありません。言いたいのは、その国、その言語で、あなたのターゲットクエリで実際にランキングしているものを見てください。シークレットウィンドウを開き、Googleの国を手動で設定して、上位3つの結果を見てください。それらの長さはどのくらいですか？動画はありますか？表はありますか？ユーザーレビューが埋め込まれていますか？それがあなたのベンチマークです。英語で機能するものではなく。look at what's actually ranking in that country, in that language, for your target query. Open an incognito window, set your Google country manually, and look at the top three results. What length are they? Do they have video? Do they have tables? Do they have user reviews embedded? That's your benchmark, not what works in English.
---
ライブ前のテクニカル監査チェックリスト
Seahawk からインターナショナルサイトがライブになる前に、私たちはこれを順に実行します。
- URL構造がすべてのロケールで一貫していることを確認
- Screaming Frog を使用してすべてのページタイプ（ホーム、カテゴリ、商品、ブログ）の hreflang タグを検証
- canonical タグが hreflang alternate URL と正確に一致していることを確認
- x-defaultが設定されており、ライブでリダイレクトなしのページを指しているか確認してください
- Google Search Consoleのジオターゲティング設定をテストします（国際的なターゲティングレポート、レガシーツールの下）Google Search Console (International Targeting report, under Legacy Tools)
- XMLサイトマップにすべてのローカライズされたURLが含まれており、別々のプロパティを使用している場合はロケールごとに送信されていることを確認してください
- WebPageTestを使用してターゲット地域からページ速度をチェックします（ヨーロッパまたはアジアのノードを使用）
- GoogleのリッチリザルトテストでLocalBusinessスキーマを検証します（ロケールごとに少なくとも1つの代表的なページ）
これがすべてのチェック項目ではありません。しかし、これら8つがクリアであれば、土台は構築を始めるのに十分なほど堅牢です。
---
忍耐のゲーム：タイムラインと期待値
国際SEOについて当社にご相談いただくすべてのクライアントのために、看板に貼ることができたらと思うことがあります。これは英語のSEOよりも時間がかかります。実は、かなり時間がかかることもあります。this takes longer than English SEO. A lot longer, sometimes.
新しいローカライズセクションを立ち上げると、本質的には、Googleの視点からそのマーケットで新しいサイトを立ち上げることになります。ローカルなバックリンク履歴がありません。ローカルなエンゲージメントシグナルがありません。クエリ履歴がありません。Googleは慎重です。
現実的なタイムライン：動きが見え始めるまで3ヶ月、結論を形成し始めるまで6ヶ月、ローカライゼーション戦略が機能しているかを実際に評価するまで12ヶ月。これが誰もが聞きたくない答えだとわかっています。しかし、この期待値を持って進めるクライアントは、4ヶ月目で1ページ目に到達していないからといってプラグを抜く可能性がはるかに低いのです。
最初に言及したSaaSクライアント？2022年のQ1に彼らの国際的なセットアップ全体を再構築しました。2022年のQ4までに、ドイツのトラフィックは月38セッションから約1,400に増加していました。フランスは800でした。9ヶ月間の一貫した作業が必要でした。近道なし。正しいアーキテクチャ、本当のローカライズされたコンテンツ、そして各市場での忍耐強いリンク構築だけです。
---
FAQ
言語ごとに別のGoogle Search Consoleプロパティが必要ですか？
サブディレクトリを使用している場合は必要ありません。1つのGSCプロパティがドメイン全体をカバーし、URLプレフィックスでフィルタリングしてロケール別のデータを表示できます。ccTLDを使用している場合は、各ドメインが独自のプロパティを必要とします。サブドメインは別々にセットアップすることも、ドメインプロパティでカバーすることもできます。より清潔なデータのために私は別々を好みます。
ローカライズされたコンテンツに機械翻訳を使用できますか？
短い答え：いいえ、最終的な出力としては使用できません。Googleは機械翻訳されたコンテンツを検出でき、それは自動生成コンテンツとしてスパムポリシーに含まれます。DeepLまたは同様のツールを使用して下書きを取得し、その後ネイティブスピーカーに適切に編集してもらいます。編集パスはローカライゼーションが実際に起こる場所です。Spam Policies as auto-generated content. Use DeepL or similar to get a first draft, then have a native speaker edit it properly. The editing pass is where localisation actually happens anyway.
複数の国で話されている言語を処理するにはどうすればよいですか？スペイン対メキシコのスペイン語のように？
別々のhreflangtags を使用します：スペインの場合はes-ES、メキシコの場合はes-MX。そして理想的には、各ローカルクエリを対象とした異なるメタデータを最低でも持つ、本当に異なるコンテンツを各々について持っています。両方のhreflangtags を同じページにポイントしないでください。Googleはあなたが何をしているのかを理解します。es-ES for Spain and es-MX for Mexico. And ideally you have genuinely different content for each, or at minimum different metadata targeting local queries. Don't just point both hreflang codes to the same page. Google will figure out what you're doing.
CMSが標準でhreflangをサポートしていない場合はどうすればいいですか?
ほとんどのCMSはプラグインで対応できます。WPMLとPolylangはどちらもWordPressでhreflangをうまく扱えます。カスタムビルドの場合は、<head>ではなくXMLサイトマップ経由でタグを出力する方法もあります。Googleはこのサイトマップ方式を受け入れます。この方法は実際には大規模運用でメンテナンスが楽です。バリデーションがきちんと通っていることだけ確認してください。<head>, which Google accepts. The sitemap method is actually easier to maintain at scale. Just make sure it's validating cleanly.
---
ローカライゼーションSEOは時間がかかり、手作業が多く、リソース不足になりやすいです。私が監査したサイトのほとんどは翻訳コンテンツはあるものの、技術レイヤーが欠落しているか壊れています。まずアーキテクチャを修正してください。その後でローカルシグナルを構築します。コンテンツは正直なところ簡単な部分です。退屈な部分こそが差をつけるんです。