自動翻訳ウィジェットではインバウンド検索に出ない｜京都の観光・宿泊サイトの多言語SEO設計（hreflang・URL構造・翻訳品質）

この記事のポイント

• 自動翻訳ウィジェットはクライアントサイドJSで動くため検索エンジンには原文しか見えず、海外検索に露出しない
• 京都のインバウンド対応は英語を最優先し、繁体字・韓国語へ段階投資するのが定石
• 国内単一事業者の多言語サイトはサブディレクトリ型URL（例：/en/）が最も評価が集中しやすい
• hreflang実装は海外調査で約75%にエラーがあるとされ、リターンタグ欠落とISOコード誤りが二大要因
• 機械翻訳は人間レビューを経てから公開するのがGoogleの見解に沿った運用ライン

京都の宿泊施設や観光関連事業者のサイトを見ていると、右上に「EN」ボタンやGoogle翻訳のウィジェットが設置されているケースは珍しくありません。ところが、そのサイトを実際にGoogleの英語検索結果で探しても出てこない——という状況に心当たりがある担当者は少なくないはずです。これは設定ミスというより、仕組みそのものが検索エンジンに向いていないために起きる、構造的な問題です。

「京都 多言語サイト SEO」を検討する段階でまず理解しておくべきなのは、翻訳ボタンの設置と、検索エンジンにインデックスされる多言語サイトの構築は、まったく別の作業だという点です。この記事では、なぜ翻訳ウィジェットが検索に出ないのかという構造の話から、URL設計、hreflangの実装ミス対策、機械翻訳の品質基準、そして直予約導線への接続まで、京都の観光・宿泊事業者が制作会社に発注する際の要件定義に使えるレベルまで落とし込んで整理します。

自動翻訳ウィジェットではなぜ海外からの検索に出ないのか

図1: クローラーには翻訳結果が見えない仕組み

結論として、Google翻訳やブラウザ内蔵翻訳のようなクライアントサイド翻訳ウィジェットは、検索エンジンのクローラーには翻訳結果が見えていません。訪問者のブラウザ上でJavaScriptがページ読み込み後に文字列を置き換えているだけで、サーバーが返すHTMLそのものは日本語のままだからです。

翻訳ボタンの翻訳結果はGoogleにインデックスされない仕組み

MultiLipi Blogの記事「The Hidden SEO Costs of Using Google Translate on Your Website」では、Google翻訳ウィジェットはページ表示後に動くクライアントサイドJSであるため、クローラーが取得するのは常に原文HTMLのみで、翻訳版は独立したURLを持たずインデックス対象にもならないという構造的欠陥が整理されています。日本の観光サイトに当てはめても事情は同じで、翻訳ボタンをどれだけ目立たせても、検索エンジン側には「多言語対応済みのサイト」として一切認識されません。

titleタグとmeta descriptionが日本語のままになる問題

クライアントサイド翻訳では、検索結果に表示されるtitleタグとmeta descriptionは書き換わりません。英語圏のユーザーがGoogleで検索したとき、検索結果一覧にはそもそも日本語のタイトルと説明文しか表示されないため、英語話者からするとクリックする理由がない、あるいはそもそも検索順位に乗ってこないという二重の壁があります。

『多言語対応済みなのに海外流入ゼロ』の典型パターン

Search Consoleのレポートを国・地域でフィルタして確認すると、海外からの検索流入がほぼゼロという状態が典型的なパターンです。多言語対応をしたはずなのに数字が動かない場合、まず疑うべきは翻訳ウィジェットへの依存であり、言語別URLが存在するかどうかをまず確認するのが実務上の切り分け方法になります。

京都のインバウンド集客で対応すべき言語の優先順位は？

英語対応から着手する宿のオーナー

京都の観光・宿泊事業者が最初に翻訳投資すべき言語は英語です。理由は検索エンジンとしてのGoogleの利用率が高い言語圏であることに加え、英語圏以外の訪日客にとっても英語ページが「共通言語」として機能するためです。

まず英語、次に繁体字・韓国語という段階投資の考え方

全言語を一斉に用意しようとすると翻訳予算が薄く広く分散し、どの言語も検索に引っかからない中途半端な状態になりがちです。段階投資の考え方としては、まず英語で予約導線と主要な観光コンテンツを固め、そのうえで台湾・香港からの流入データを見ながら繁体字、韓国からの流入があれば韓国語へと広げていくのが現実的な順序です。

簡体字圏は百度・小紅書、韓国はNAVERというGoogle外の検索行動

簡体字圏（中国本土）の旅行者は検索行動そのものがGoogleではなく百度（Baidu）や小紅書（RED）中心であり、韓国のユーザーもNAVER検索の利用比率が高いことが知られています。つまり簡体字・韓国語のページをGoogle向けSEOとして作り込んでも、そもそも狙っている検索エンジンが違うという構造上のミスマッチが起きやすい言語圏です。この論点は簡体字圏・韓国のプラットフォーム対策そのものを掘り下げる価値があり、大衆点評・小紅書・NAVERとGoogleマップの使い分けで詳しく扱っています。

全ページ翻訳ではなく予約導線と周辺観光ページから翻訳する

Bookinglayerの「Hotel SEO: The Guide to Driving Direct Bookings in 2026」では、客室・設備ページの翻訳はスタート地点にすぎず、主要送客国の言語で書かれたデスティネーション（周辺観光）コンテンツこそが国際流入の差を生むと整理されています。京都の宿泊施設は祇園や嵐山といった周辺観光情報について一次情報を持つ立場にあるため、客室紹介だけでなく周辺観光コンテンツへの翻訳投資が差別化につながりやすいと言えます。予約ページ・アクセスページ・周辺観光ページの3つを優先し、館内規約やスタッフ紹介のような検索需要の薄いページは後回しにするのが現実的な割り振りです。

多言語サイトのURL構造はどれを選ぶべきか｜サブディレクトリ推奨の理由

図2: 3方式のドメイン評価の集中度を比較

多言語サイトのURL構造には、ccTLD（国別ドメイン）、サブドメイン、サブディレクトリの3方式があり、京都で単一事業を展開する宿泊・観光事業者にはサブディレクトリ型が基本的に推奨されます。

3方式の比較とドメイン評価の集中

方式	例	特徴
ccTLD	example.us	国別に強いシグナルを持つが、ドメインごとに評価がゼロから積み上がる
サブドメイン	en.example.jp	技術的に切り離しやすいが、Googleがメインドメインと別サイト扱いする場合がある
サブディレクトリ	example.jp/en/	既存ドメインの評価をそのまま引き継ぎやすい

京都の宿泊・観光事業者にサブディレクトリを勧める理由

複数国に法人を持つグローバルチェーンでない限り、被リンクやサイテーションといったドメイン評価はひとつのドメインに集中させたほうが効率的です。京都の単一事業者であれば、日本語サイトがこれまで積み上げてきたドメインの評価をそのまま多言語ページに引き継げるサブディレクトリ構造のほうが、立ち上げ直後から評価を得やすい傾向にあります。

既存日本語サイトに/en/を足すときの注意点

既存サイトに後から/en/を追加する場合、CMSの仕様によっては英語ページのURLが/en/room-a/のようにスラッグまで自動的に英訳・重複生成されてしまうことがあります。スラッグの命名規則、404ページやパンくずリストの多言語対応、サイトマップの言語別出し分けまで含めて事前に仕様を固めておかないと、後から構造を直すコストのほうが大きくなりがちです。

hreflangの設定方法とよくあるミス｜設定したのに効かない原因

図3: リターンタグ欠落が引き起こす片方向の誤り

hreflangとは、同一内容の異なる言語・地域向けページ同士をGoogleに伝える属性のことで、正しく設定すると検索ユーザーの言語・地域に応じて適切な言語版のページが検索結果に表示されやすくなります。

hreflangタグの書き方とx-defaultの使い方

実装方式はHTMLの<link>タグ、HTTPヘッダー、XMLサイトマップの3種類があり、どの言語にも該当しないユーザー向けのフォールバック先を指定する場合はx-defaultを使います。

<link rel="alternate" hreflang="ja" href="https://example.jp/" />
<link rel="alternate" hreflang="en" href="https://example.jp/en/" />
<link rel="alternate" hreflang="x-default" href="https://example.jp/" />

リターンタグ欠落・ISOコード誤り・canonical矛盾の3大ミス

Oncrawlの「Hreflang implementation: Best practices for SEO」によると、hreflang実装の代表的なエラーはリターンタグ（相互参照タグ）の欠落、ISO言語コードの誤り、canonicalタグとの矛盾の3つに集約され、海外調査ではhreflang実装の約75%に何らかのエラーが存在するとされています。さらに、クラスタ内のどれか1ページでもエラーがあると、Googleがそのクラスタ全体のhreflangを無視する場合がある点も指摘されています。日本語ページから英語ページへのhreflangは書いたが、英語ページから日本語ページへの記述（リターンタグ）を書き忘れる、あるいは「JP」のような国コードを言語コードの位置に誤記する、といったミスは実務でも起きやすい典型パターンです。

エラー種別	内容	起きやすい原因
リターンタグ欠落	相互参照が片方向のみ	一方の言語ページのみ更新して他方を反映し忘れる
ISOコード誤り	言語コードと国コードの混同	「en-US」を「en-us」「EN」等と表記揺れさせる
canonical矛盾	hreflangの参照先とcanonicalの指定先が食い違う	CMSが自動生成するcanonicalを見落とす

Search Consoleでの検証手順

Search Consoleには専用の国際ターゲティングレポートは廃止されていますが、URL検査ツールで対象ページを検査し、インデックス登録された言語版が意図通りかを個別に確認する方法が実務的です。加えて、site:example.jp/en/のようなsite検索演算子で英語ページ群がインデックスされているかをざっくり確認し、想定より件数が少ない場合はサイトマップの送信状況やnoindexの誤設定を疑うのが定石です。

機械翻訳をそのまま公開してはいけない理由と翻訳品質の担保ライン

誤訳に気づき赤ペンを止めるスタッフ

機械翻訳の利用自体は禁止されていません。問題は、人間のレビューを経ないまま大量のページを一括公開することです。

人間レビューなしの機械翻訳はインデックスさせたくないというGoogleの見解

Search Engine Roundtableの報道によれば、GoogleのJohn Mueller氏は、人間による確認・修正を経ない機械翻訳コンテンツを「自動生成コンテンツ」として扱い、インデックスさせたくないという見解を示しています。翻訳エンジンにDeepLやWeglotのようなSaaSを使うこと自体は問題ではなく、公開前に人間がチェックする工程があるかどうかが評価の分かれ目になるという整理です。全ページを機械翻訳のまま一括公開するのではなく、優先度の高いページから人間レビューを通す運用が、この見解に沿った現実的な落としどころと言えます。

固有名詞・料理名・体験メニューなど観光サイトで誤訳が致命傷になる箇所

観光サイトでは、寺社名・料理名・体験メニュー名といった固有名詞の誤訳が信頼性に直結します。「湯豆腐」を直訳して意味不明な英語になっていたり、施設名の一部が翻訳エンジンによって勝手に意訳されてしまったりするケースは典型的な失敗パターンです。こうした語句はグロッサリー（訳語集）として事前に統一表記を決めておき、機械翻訳後のレビュー工程で必ず確認する運用にしておくと、担当者ごとの訳ブレを防ぎやすくなります。

直訳ではなく現地の検索語に合わせるローカライズの考え方

ローカライズとは、単なる逐語訳ではなく、現地ユーザーが実際に検索で使う語彙や表現に合わせて文章を作り直すことを指します。例えば「町家」を”machiya”とそのまま表記するか”traditional Kyoto townhouse”と説明的に訳すかは、ターゲット読者の京都に関する知識レベルによって判断が変わります。訪日外国人の検索行動を踏まえると、地名や文化用語は説明を添えたうえでローマ字表記も併記しておくと、検索クエリとの一致率が上がりやすい傾向にあります。

検索流入を予約につなげる設計｜GBP・構造化データ・直予約導線

多言語SEOは、検索結果に載せて終わりではなく、直予約という着地まで設計してはじめて投資対効果が測れます。

Googleビジネスプロフィールの多言語対応と店名誤翻訳の管理

Googleビジネスプロフィール（GBP）はGoogleマップの表示言語に応じて自動翻訳が働くため、店名や説明文が意図しない形に誤訳されてマップ上に表示されてしまうことがあります。この問題への対処法は、Googleマップの店名が勝手に翻訳されるときの修正手順で扱っている通り、GBP側の設定確認とビジネス情報の修正申請というマップ面での個別対応が必要です。サイトのSEO対策とGBP対策は別軸の作業であることを押さえておく必要があります。

宿泊・観光施設の構造化データと多言語ページへの適用

宿泊施設であればHotelやLodgingBusiness、観光施設であればTouristAttractionといったスキーマの構造化データを、日本語ページだけでなく多言語ページにも同様に実装しておくと、検索結果でのリッチリザルト表示や、生成AI検索での情報抽出のされやすさに寄与すると考えられています。多言語ページを作る際は、構造化データの実装を後回しにせず、テンプレート段階で言語ごとに出し分けられる設計にしておくのが効率的です。

多言語LPと広告を併走させる場合の役割分担

SEOで作る多言語ページは中長期の資産として機能する一方、広告用の多言語LPは短期的な訴求に特化させるという役割分担が基本になります。両者を混同して1ページで両方の役割を持たせようとすると、SEO観点では情報量が薄く、広告観点では離脱しやすい中途半端なページになりがちです。この役割分担の設計については、京都のインバウンド広告と多言語LPの実務設計で広告側の予算配分まで含めて整理しています。

多言語サイトSEOの費用感と進め方｜自社対応と外注の線引き

多言語SEOの進め方は、予算規模と社内体制によって翻訳SaaS活用と制作会社外注のどちらを軸にするかが変わります。

翻訳SaaS活用と制作会社外注の使い分け

WOVN.ioやWeglotのような翻訳SaaSは、既存サイトに後付けでスクリプトを組み込み、機械翻訳ベースの多言語ページを比較的短期間で用意できる点が強みです。ただし、URL構造やhreflangの実装がツールの仕様に依存するため、SEO要件を満たせるかどうかは導入前に必ず確認が必要です。一方、制作会社に一から発注する場合は自由度が高い分、初期費用も工数も大きくなります。小規模事業者であればまず翻訳SaaSで英語ページを立ち上げてみて、流入が育ってきた段階で本格的な作り込みに切り替えるという段階導入も現実的な選択肢です。

発注時に仕様書へ入れるべきSEO要件

制作会社やSaaSベンダーに発注する際、口頭で「多言語対応してほしい」と伝えるだけでは、翻訳ウィジェットの後付けで済まされてしまうリスクがあります。仕様書には最低限、以下の項目を明記しておくべきです。

• URL構造をサブディレクトリ型（/en/等）で実装すること
• 各言語ページでtitleタグ・meta description・OGPを個別に生成すること
• hreflangをリターンタグまで含めて実装すること
• 機械翻訳を使う場合は公開前に人間レビュー工程を挟むこと
• 構造化データを多言語ページにも同様に実装すること

公開後にSearch Consoleで見るべき指標

公開後は、Search Consoleの検索パフォーマンスレポートを国・言語別にフィルタし、表示回数とクリック数の推移を追うのが基本です。表示回数自体が伸びない場合はインデックスの問題を疑い、表示回数はあるのにクリック率が低い場合はtitleタグ・meta descriptionの訴求内容を見直す、という切り分けが実務的です。インデックスされているのに順位が伸びないケースと、そもそもクロールはされているがインデックスされていないケースは原因も対処法もまったく異なるため、クロール済み・インデックス未登録の判断基準で判断軸を確認しておくと切り分けがスムーズです。

よくある質問

Q：Google翻訳のウィジェットを設置すれば多言語対応・SEO対策になりますか？ なりません。クライアントサイド翻訳はブラウザ側でのみ表示が切り替わる仕組みで、検索エンジンのクローラーには翻訳結果が見えず、言語別のURLもtitleタグ・meta descriptionも生成されないためです。海外検索からの流入を狙う場合は、言語ごとに独立したURLを持つページを用意する必要があります。

Q：多言語サイトはサブドメインとサブディレクトリのどちらが良いですか？ 国内で単一事業を展開している場合はサブディレクトリ型（例：example.jp/en/）が基本的に推奨されます。既存ドメインの評価をそのまま多言語ページに引き継げるためです。ただし、複数国に現地法人を持ち、国ごとに全く異なる事業運営やサーバー管理体制を敷いている場合は、ccTLDやサブドメインが適するケースもあります。

Q：機械翻訳（DeepL等）で作った英語ページはGoogleにペナルティを受けますか？ 機械翻訳の利用自体がペナルティの対象になるわけではありません。ただし、人間のレビューを経ずに大量公開すると「自動生成コンテンツ」として低品質評価を受けるリスクがあるとGoogleの見解として示されています。公開前に固有名詞や文脈のチェックを人間が行う工程を挟むことが、実務上の安全なラインです。

Q：京都の宿泊施設はまず何語のページから作るべきですか？ まず英語を最優先に整備するのが基本です。そのうえで、実際の予約データや問い合わせデータから台湾・香港からの流入が多ければ繁体字、韓国からの流入が多ければ韓国語へと、客層の実態に応じて段階的に言語を拡張していくのが現実的な判断軸になります。

多言語サイトのSEO設計は、翻訳ボタンを置くだけの対応と比べて初期の手間は増えますが、URL構造とhreflang、翻訳品質の基準さえ最初に決めておけば、後から言語を追加していくのはそれほど難しくありません。真策堂では、こうした多言語SEOの設計方針の整理や、制作会社・翻訳SaaSへの発注要件定義といった観点からのご相談を受けています。自社サイトの多言語対応が検索に反映されているかどうか気になる場合は、まずSearch Consoleの国・言語別レポートを確認するところから始めてみてください。