COLUMN
よく検索されるキーワード
2026/09/28
ホームページ制作の基本構造化データとは？検索結果で情報を正しく伝える基本と注意点
構造化データとは？ 構造化データとは、ホームページに書かれている情報の意味を、検索エンジンへ分かりやすく伝えるためのデータです。 たとえばページ上に、 「株式会社Refu」「2022年設立」「この記事を書いた人：〇〇」 と表示されていても、検索エンジンがそれぞれの情報の意味を完全に判断できるとは限りません。 構造化データを使うことで、 これは会社名ですこれは記事の著者ですこれは公開日です といった情報を明示できます。 Googleも、構造化データを「ページについての情報を提供し、ページ内容を分類するための標準化された形式」と説明しています。 構造化データを設定するメリット 主なメリットは2つです。 検索エンジンがページ内容を理解しやすくなる 会社、記事、商品、パンくずリストなどの情報を明確に伝えられます。 リッチリザルトの対象になる場合がある 構造化データの種類によっては、通常の検索結果より情報量の多いリッチリザルトとして表示される可能性があります。 ただし、 構造化データを設定すれば必ず検索結果の表示が変わるわけではありません。 Googleも、正しく設定されていてもリッチリザルトの表示を保証するものではないとしています。 企業サイトで使われる代表的な構造化データ 企業サイトで特に確認したいものを紹介します。 Organization 会社・組織の情報を伝える構造化データです。 例： 会社名 URL ロゴ 住所 連絡先 Googleは、ホームページにOrganizationを設定することで、組織の情報を理解しやすくなると説明しています。 Article・BlogPosting ブログ・コラムなどの記事に使用します。 例： 記事タイトル 著者 公開日 更新日 画像 Googleが記事のタイトル・画像・日時・著者などを理解する手助けになります。 BreadcrumbList いわゆるパンくずリストです。 たとえば、 ホーム ＞ SEO対策 ＞ 構造化データとは のようなサイト内の階層を検索エンジンへ伝えます。 このほかにも、 Product Event JobPosting Recipe など、サイトの内容に応じた構造化データがあります。 Google検索で利用できる種類は決まっているため、自社サイトに関係するものだけを設定することが基本です。 構造化データを入れると検索順位は上がる？ よくある誤解が、 「構造化データを入れる＝検索順位が上がる」 というものです。 構造化データは、ページ内容を検索エンジンへ正確に伝えるための仕組みであり、設定しただけで上位表示が保証されるものではありません。 また、リッチリザルトの対象になる構造化データを設定しても、実際に検索結果へ表示されるかどうかはGoogleが判断します。 構造化データは、 SEO順位を直接上げる裏技 ではなく、 検索エンジンがサイトを理解するための技術的な整備 と考えると分かりやすいでしょう。 Googleが推奨するJSON-LDとは 構造化データの記述方法には、 JSON-LD Microdata RDFa があります。 Googleは、この中でJSON-LDを推奨しています。 JSON-LDはページ内に専用のコードを記述する方式で、HTML本文と分離して管理しやすいのが特徴です。 WordPressなどのCMSでは、 テーマ SEOプラグイン 独自プログラム によって自動的に構造化データが出力されている場合もあります。 そのため、 「構造化データを追加したいから、とりあえずプラグインを追加する」 のではなく、まず現在どのデータが出力されているか確認しましょう。 設定するときの注意点 構造化データは、多く設定すればよいわけではありません。 特に次の点に注意しましょう。 実際のページ内容と一致させる ページに書いていない内容を、構造化データだけに追加してはいけません。 Googleも、構造化データの内容はページ上の内容を正しく表している必要があるとしています。 関係のない種類を設定しない リッチリザルトを狙うためだけに、ページ内容と関係のないマークアップを入れるのは避けましょう。 古い情報を放置しない 会社情報・記事更新日・商品情報などが変更された場合は、構造化データ側も一致しているか確認します。 CMSによる重複に注意する WordPressでは、 テーマ＋SEOプラグイン＋別プラグイン から同じ構造化データが出力されるケースがあります。 導入前に既存設定を確認することが重要です。 正しく設定できているか確認する方法 Googleでは、構造化データを確認するためのツールを提供しています。 リッチリザルトテスト URLまたはコードを入力して、 対応している構造化データ エラー 警告 などを確認できます。 Search Console 公開後はSearch Consoleから、構造化データに関するエラーが発生していないか確認できます。 Googleも、実装後はリッチリザルトテストやURL検査ツールを利用して確認することを案内しています。 設定して終わりではなく、公開後もエラーを確認する ことが大切です。 まとめ：SEOの裏側を整える基本設定 構造化データとは、 ホームページの内容を検索エンジンへ正しく伝えるための仕組み です。 特に企業サイトでは、 Organization Article・BlogPosting BreadcrumbList などが関係するケースが多くあります。 ポイントは、 ページ内容に合った構造化データを使う 実際の表示内容と一致させる JSON-LDを基本に検討する リッチリザルト表示を保証するものではない リッチリザルトテスト・Search Consoleで確認する ことです。 構造化データは、ユーザーから直接見えるデザインではありません。 しかし、検索エンジンへサイトの情報を適切に伝えるという意味では、ホームページの土台を整える重要なSEO施策の一つです。 構造化データ・内部SEOのご相談ならRefuへ Refuでは、ホームページ制作時のデザインやコンテンツだけでなく、サイト構造・内部SEO・構造化データなど検索エンジンに正しく情報を伝えるための技術設計まで含めて対応しています。 「自社サイトに構造化データが設定されているか分からない」「Search Consoleにエラーが出ている」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら CMS導入のメリット・デメリット｜自社更新の最適解とは？ SEOの前に整える「サイト構造」｜カテゴリ設計・URL・内部リンクの基本 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 404エラーとは？ホームページで起きる原因と正しい対処法 オウンドメディアの始め方｜中小企業が記事公開前に決めるべき7つのこと
2026/09/21
ホームページ制作の基本オウンドメディアの始め方｜中小企業が記事公開前に決めるべき7つのこと
オウンドメディアは「とりあえずブログを書く」と失敗しやすい SEO対策や問い合わせ獲得を目的として、 「自社でもブログを始めよう」 と考える企業は少なくありません。 しかし、オウンドメディア運営でよくあるのが、 とりあえず週1本書く 社員が順番に好きなテーマを書く SEOキーワードを見つけたら記事にする AIで大量の記事を作る アクセス数だけを追いかける というスタートです。 この方法では、記事数は増えても、 「誰に何を伝えるサイトなのか」 が分からなくなりやすく、問い合わせにもつながりません。 Googleも、検索エンジンからのアクセス獲得を主な目的として幅広いテーマの記事を大量に作るのではなく、既存または想定している読者にとって役立ち、サイトに明確な目的やテーマがあるコンテンツを重視する考え方を示しています。 オウンドメディアは、 記事を書くところから始めるのではなく、誰に・何を・何のために届けるかを決めるところから始める ことが重要です。 そもそもオウンドメディアとは？企業ブログとの違い オウンドメディアとは、直訳すると「自社が所有するメディア」です。 広い意味では、 コーポレートサイト ブログ メールマガジン 採用サイト なども含まれます。 ただしWebマーケティングの現場では、一般的に、 自社が継続的に記事や情報を発信し、検索・SNSなどからユーザーとの接点を作るWebメディア という意味で使われることが多くあります。 企業ブログとの違いは名称よりも、運営目的が設計されているかです。 たとえば、 企業ブログ 社内イベント 夏季休業のお知らせ 社員の日記 新商品の紹介 オウンドメディア ユーザーの悩みを解決する記事 商品・サービス選びに必要な知識 専門家としてのノウハウ 比較検討時に必要な情報 という違いがあります。 もちろん、企業ブログ形式でも戦略的に情報発信していれば、オウンドメディアとして活用できます。 大切なのは名称ではなく、 「記事を読んだ人にどのような価値を提供し、その後どのような関係を作るのか」 が設計されていることです。 始める前に決めること｜何のために運営するのか 最初に決めるのが目的です。 目的が曖昧なまま始めると、記事テーマもKPIも決まりません。 代表的な目的には次があります。 問い合わせを増やす 例：Web制作会社なら、 ホームページ制作 SEO リニューアル Web集客 などについて記事を作り、サービスへの相談につなげます。 見込み顧客との接点を増やす まだサービスを探していない潜在層へ情報提供し、将来の相談候補に入ってもらう目的です。 専門性・信頼性を伝える 専門的な情報を継続的に発信することで、 「この分野ならこの会社に相談できそう」 という状態を目指します。 採用につなげる 業界情報・仕事内容・働き方・社員の知識などを発信し、求職者との接点を作る方法もあります。 目的は、 × SEOを強化する だけでは不十分です。 SEOは集客手段だからです。 最終的には、 「SEOで集客して、何につなげたいのか」 まで決めましょう。 例： 自然検索から月3件のホームページ制作問い合わせを獲得する のように設定すると、必要な記事テーマや計測方法を考えやすくなります。 始める前に決めること｜誰に読んでもらうのか 次に決めるのが、読者＝ターゲットです。 「経営者向け」 だけでは広すぎます。 できるだけ、 業種 会社規模 役職 現在の課題 検討段階 知識レベル まで整理します。 たとえば、 従業員10〜50名程度の中小企業で、初めてホームページリニューアルを担当する総務・広報担当者 まで設定すると、どのような記事が必要かが見えてきます。 その人が知りたいのは、 制作費はいくらか 何ヶ月かかるか 制作会社はどう選ぶか 社内で何を準備するか SEOは何をすればいいか かもしれません。 Googleもpeople-firstコンテンツを考える際、「既存または想定しているユーザーが存在し、その人たちが直接サイトへ来ても役立つ内容か」を確認するよう案内しています。 記事テーマを考える前に、 「この記事は誰の、どんな疑問を解決するのか」 を明確にしましょう。 始める前に決めること｜どのテーマまで扱うのか オウンドメディアでは、サイトとして扱うテーマの範囲も重要です。 たとえばWeb制作会社なら、 ホームページ制作 SEO Webマーケティング デザイン ホームページ運用 などは本業との関連性があります。 一方、 「アクセスが取れそうだから」 という理由だけで、 投資 転職 グルメ 芸能ニュース などの記事を作り始めると、サイト全体の方向性が分かりにくくなります。 Googleも、サイトに主要な目的やテーマがあるかをpeople-firstコンテンツの確認項目として挙げています。 まず、 「自社が専門家として価値を提供できる範囲」 を定義しましょう。 おすすめは、 メインカテゴリ → サブカテゴリ → 記事テーマ の3階層で整理する方法です。 例： ホームページ制作 制作会社選び 費用 制作の流れ CMS サーバー SEO キーワード 内部リンク Search Console コンテンツSEO Web集客 SNS 広告 MEO LP このように先に全体設計すると、記事が増えてもテーマが散らかりにくくなります。 始める前に決めること｜検索キーワードと検索意図 オウンドメディアでSEOを狙うなら、記事を書く前に検索意図を考えます。 検索意図とは、 「そのキーワードを検索した人は、何を知りたいのか」 ということです。 たとえば、 「ホームページ制作 費用」 と検索する人なら、 相場を知りたい 料金の内訳を知りたい 高い・安いの基準を知りたい 制作会社へ頼む予算を決めたい と考えている可能性があります。 記事では単に、 「ホームページ制作 費用」 というキーワードを何度も入れるのではなく、これらの疑問へ答える必要があります。 1記事1キーワードではなく「1つの検索意図」 ここも重要です。 たとえば、 ホームページ制作 費用 HP制作 相場 Web制作 料金 は、検索意図が非常に近い可能性があります。 それぞれ別記事を作ると、内容が重複する場合があります。 キーワード単位ではなく、検索意図単位で記事を設計する ことを意識しましょう。 始める前に決めること｜カテゴリと内部リンク設計 記事を公開してからカテゴリを考えると、後から整理が難しくなります。 そのため、開始前にカテゴリ構造を決めておきます。 例： ホームページ制作 費用 制作会社選び 制作の流れ SEO 内部SEO コンテンツSEO 分析 運用 更新 保守 セキュリティ という形です。 そして重要なのが内部リンクです。 たとえば、 「ホームページ制作費用」 の記事を読んでいる人なら、 見積書の見方 制作会社の選び方 制作の流れ 問い合わせ にも興味がある可能性があります。 そこで記事同士をつなぎます。 Googleも、リンクはユーザーや検索エンジンがリンク先の内容を理解する助けになり、関連する情報へ文脈を追加するためにも利用できると説明しています。 オウンドメディアでは、 記事を単体で作るのではなく、記事同士をつなげてサイト全体で疑問を解決する ことを意識しましょう。 始める前に決めること｜誰が記事を作り、誰が確認するのか オウンドメディアが止まる理由として多いのが、 「誰がやるか決まっていない」 ことです。 少なくとも、 テーマを決める人 記事を書く人 専門内容を確認する人 SEOを確認する人 公開する人 公開後に分析する人 を決めましょう。 1人ですべて担当しても構いません。 重要なのは、 役割が明確になっていること です。 また、専門性が必要な記事では、 実務経験者や専門家の知識を記事へ反映する ことも重要です。 Googleはコンテンツ品質を評価する際の自己確認項目として、 誰が作ったのか 実体験や深い知識があるか 信頼できる情報源が示されているか 専門家や詳しい人によって作成・確認されているか といった点を挙げています。 制作会社や外部ライターへ依頼する場合でも、 自社にしかない経験・事例・ノウハウを提供する仕組み を作ることが重要です。 始める前に決めること｜KPIと問い合わせまでの導線 記事を公開してアクセスが増えても、それだけで事業成果につながるとは限りません。 開始前に、 「記事を読んだあと、何をしてほしいのか」 を決めます。 たとえば、 記事↓関連記事↓サービスページ↓実績↓問い合わせ という流れです。 記事の内容によってCTAも変えます。 潜在層向け記事 いきなり、 「今すぐお問い合わせ！」 ではハードルが高い場合があります。 その場合は、 関連記事 チェックリスト 事例 サービス解説 などへつなぎます。 比較検討層向け記事 料金 制作会社比較 サービス比較 選び方 などの記事では、問い合わせや無料相談へ近い導線を設置できます。 KPIも段階的に設定します。 例： 検索表示↓クリック↓記事閲覧↓サービスページ遷移↓問い合わせフォーム到達↓問い合わせ Search Consoleでは、検索クエリ・ページ・国などの単位でクリック数や表示回数などを確認できるため、公開後の検索パフォーマンス分析に利用できます。 PVだけでなく、事業成果に近い指標まで見る ことが重要です。 記事テーマはどうやって決める？実務で使える5つの探し方 営業担当へ「よく聞かれる質問」を聞く 最もおすすめの方法です。 営業担当が毎回説明している内容には、顧客ニーズがあります。 例： 料金はいくら？ 何ヶ月かかる？ 自分たちで更新できる？ SEOも対応できる？ 写真は用意する？ これだけでも記事テーマになります。 問い合わせ内容を確認する 問い合わせフォームやメールに書かれている質問を集めます。 ユーザーが実際に困っている内容なので、記事テーマとの相性が良い情報源です。 Search Consoleを見る すでにサイトを運営している場合は、Search Consoleから、 「どんな検索語句で自社サイトが表示されているか」 を確認できます。 たとえば、表示回数は多いのに該当する記事がないキーワードが見つかれば、新規記事候補になることがあります。 既存顧客へ聞く 「依頼前は何が分からなかったですか？」 と聞いてみましょう。 制作側が想像していなかった疑問が見つかることがあります。 自社の経験・事例から考える 競合サイトのキーワードだけを追いかけるのではなく、 実際にあった失敗 成功した改善 現場でよくある相談 自社独自の進め方 実績から分かったこと などを記事にすると、独自性が生まれます。 Googleも、コンテンツの自己評価項目として独自情報・調査・分析や、検索結果の他ページと比べた実質的な付加価値を挙げています。 最初に何記事用意すればいい？本数より設計を優先する 「オウンドメディアを始めるなら、最初に何記事必要ですか？」 という質問もよくあります。 結論として、 Googleが「最初に○記事必要」と定めている基準はありません。 10記事でも50記事でも、 本数だけでSEO評価が決まるものではありません。 Googleは、特定の文字数を好む仕組みはないと明示しているほか、検索流入を期待してさまざまなトピックのコンテンツを大量に作ることについても注意を促しています。 最初は、 優先ターゲット 主要カテゴリ 問い合わせに近いテーマ 潜在層向けテーマ 内部リンクの関係 を整理したうえで、優先順位の高い記事から公開しましょう。 たとえば、 50記事のテーマだけ先に設計し、まず10記事から制作する という進め方も可能です。 重要なのは、 「何本書いたか」ではなく「必要な検索意図をどこまでカバーできているか」 です。 AIで記事を作っても大丈夫？2026年現在の考え方 AIを活用すれば、 構成案作成 調査 見出し整理 下書き 校正 要約 などを効率化できます。 では、 AIで記事を書くとSEOで不利になるのでしょうか？ 重要なのは、AIを使ったかどうかだけではありません。 Googleの現在のスパムポリシーでは、生成AIなどを使い、ユーザーへの価値を加えず、検索順位操作を主目的として大量のページを生成することを「大量生成されたコンテンツの不正使用」の例として挙げています。 つまり問題なのは、 AI利用＝NG ではなく、 価値のないコンテンツを検索順位目的で大量生成すること です。 AIを使う場合も、 自社独自の知見を追加する 事実確認をする 最新情報を確認する 実例を入れる 専門家が確認する 既存記事との重複を確認する 読者にとって本当に役立つか確認する ことが重要です。 Googleもコンテンツについて、「誰が・どのように・なぜ作ったのか」という観点で評価・説明する考え方を推奨しています。 AIは記事を量産する装置ではなく、 良いコンテンツを効率よく作るための制作支援ツール として活用しましょう。 オウンドメディアでよくある失敗8選 目的が「SEO対策」だけ SEOでアクセスを増やした後、何につなげるかがありません。 → 問い合わせ・採用・認知など、事業目的まで設定する。 記事テーマがバラバラ アクセス数だけを狙い、本業と関係の薄い記事を増やすケースです。 → サイトの主テーマ・ターゲットを明確にする。 キーワードごとに似た記事を大量に作る 少し言葉を変えただけの記事が増え、内容が重複します。 → キーワードではなく検索意図でまとめる。 Googleのスパムポリシーでも、検索順位を狙って類似ページを大量に用意する誘導ページや、価値の乏しい大量生成コンテンツへの注意が示されています。 競合記事をまとめ直しただけ 検索上位の記事を5本読んで、同じ内容をまとめた記事。 これだけでは独自性がありません。 → 自社の経験・事例・数字・専門家コメントを追加する。 記事からサービスにつながらない アクセスは増えているのに問い合わせが来ない典型例です。 → 関連記事・サービス・事例・CTAへの導線を設計する。 記事数だけをKPIにする 「月8記事公開」がゴールになってしまいます。 → 検索表示・クリック・サービス遷移・問い合わせまで計測する。 公開した記事を一度も見直さない 情報が古くなり、検索意図にも合わなくなります。 → Search Consoleなどを使って定期的にリライト対象を確認する。 運営担当が決まっていない 「時間がある人が更新する」では、ほぼ確実に止まります。 → 企画・執筆・確認・公開・分析の担当を明確にする。 公開前チェックリスト 目的 オウンドメディアの最終目的を決めた 問い合わせ・採用・認知などゴールが明確 SEOが目的そのものになっていない ターゲット 誰に読んでもらうか決めた 業種・役職・課題まで整理した 潜在層・比較検討層を区別した テーマ サイトで扱うテーマの範囲を決めた メインカテゴリを決めた サブカテゴリを整理した 本業と関係の薄いテーマを無理に扱っていない SEO キーワードを調査した 検索意図を確認した 似た検索意図の記事を重複させていない title・見出しを設計した 内部リンク先を考えた コンテンツ品質 自社独自の経験・事例を入れられる 誰が書くか決めた 専門内容の確認者を決めた 出典が必要な情報を確認するルールがある AI生成内容をそのまま公開しない 導線 記事からサービスページへ移動できる 関連記事への内部リンクがある 実績・事例へ誘導できる 問い合わせCTAを設置する 記事の検索意図に合ったCTAになっている 運用 記事制作担当を決めた 公開確認担当を決めた 更新頻度を決めた 既存記事の見直しルールを作った Search Console・GA4を確認できる 記事数だけを成果指標にしていない まとめ：記事を書く前の設計でオウンドメディアの成果は変わる オウンドメディアを始めるとき、 最初にやるべきことは記事を書くことではありません。 まず、 何のために運営するか 誰に読んでもらうか どのテーマを扱うか どんな検索意図を狙うか カテゴリと内部リンクをどうするか 誰が制作・確認するか 何を成果として計測するか を決めることが重要です。 Googleも、検索順位獲得を目的として大量のコンテンツを作るのではなく、特定のユーザーにとって有用で、独自性・専門性・信頼性のあるpeople-firstコンテンツを作ることを推奨しています。 さらに2026年現在、AIを利用した大量生成そのものではなく、ユーザーへ価値を加えないコンテンツを検索順位操作目的で大量生成する行為がGoogleのスパムポリシーで明確に問題視されています。 オウンドメディアで重要なのは、 「何記事公開したか」ではなく、「顧客が抱える疑問をどれだけ深く解決し、その先の問い合わせまでつなげられているか」 です。 記事制作を始める前に全体設計を行い、公開後はSearch ConsoleやGA4のデータ、実際の問い合わせ内容をもとに改善を続けていきましょう。 オウンドメディア設計ならRefuへ Refuでは、単なるSEO記事制作ではなく、ターゲット設定・カテゴリ設計・キーワード選定・記事テーマ設計・内部リンク・問い合わせ導線まで含めたオウンドメディア設計をご提案しています。 「何を書けばいいか分からない」「記事を増やしているけれど問い合わせにつながらない」「AIを使って効率化しながらSEOの品質も維持したい」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 原稿が書けないを解決！伝わる文章構成テンプレと作り方 SEOの前に整える「サイト構造」｜カテゴリ設計・URL・内部リンクの基本 ホームページのKPI設計｜アクセス・CV・問い合わせを“数字で改善”する方法 GA4で最低限見るべき指標7つ｜初心者でも分かる分析のはじめ方 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 よくある質問（FAQ）ページの作り方｜問い合わせ前の不安を減らす設計 ホームページはどのくらい更新すべき？更新頻度と運用ルールの決め方
2026/09/10
集客・マーケティング戦略構造化データとは？中小企業サイトで優先したい種類と実装時の注意点
構造化データは「検索順位を上げるコード」ではない SEOについて調べていると、 「構造化データを入れるとSEOに強くなる」「schemaを入れれば検索順位が上がる」 という説明を見ることがあります。 しかし、構造化データを、 「検索順位を直接上げるための裏技」 と考えるのは適切ではありません。 Googleは構造化データを、ページに関する情報を標準化された形式で提供し、ページの内容を分類するための仕組みとして説明しています。 適切な構造化データを設定することで、Googleがページ内容を理解する手掛かりになり、対応するコンテンツでは通常の検索結果より情報量の多い「リッチリザルト」の対象になる可能性があります。 ただし、正しく設定したからといって、必ずリッチリザルトが表示されるわけではありません。Googleも、構造化データがガイドラインに沿って実装されていても、検索結果での表示を保証するものではないと明記しています。 つまり構造化データは、 検索順位を操作する施策ではなく、Googleへページの意味を正確に伝えるための技術施策 と考えるのが基本です。 まず結論：すべて入れるのではなく“ページの役割に合うものだけ”設定する schema.orgには非常に多くの構造化データタイプがあります。 だからといって、 「設定できるものは全部設定しよう」 と考える必要はありません。 例えば一般的な中小企業サイトであれば、優先順位は次のように考えられます。 ほぼすべての企業サイト Organization BreadcrumbList 実店舗・地域サービス LocalBusiness ブログ・オウンドメディア Article／BlogPosting 採用活動を行っている JobPosting 商品販売・EC Product イベント・セミナーを開催している Event 重要なのは、 「どんなリッチリザルトが欲しいか」から考えるのではなく、「このページは何を表しているのか」から選ぶこと です。 Google検索が現在サポートしている構造化データは限定されており、対応する機能も随時変更されます。実装前にはGoogle Search Centralの最新一覧を確認することが重要です。 構造化データとは？初心者向けに簡単に解説 人には分かる情報を検索エンジンにも明確に伝える 例えば、会社概要ページに次の情報があったとします。 株式会社〇〇 神奈川県相模原市 042-000-0000 Web制作会社 人が見れば、 「これは会社名」「これは住所」「これは電話番号」 と分かります。 しかし、検索エンジンに対して、 これは会社名ですこれは所在地ですこれは電話番号です と、より明確な形式で伝えるのが構造化データです。 例えばOrganizationというタイプを使って、 name address telephone url logo などを記述します。 GoogleはOrganizationの構造化データについて、組織の詳細を理解し、検索結果上で他の組織と区別するために利用できると説明しています。 schema.orgとGoogle検索の関係 構造化データでは一般的にschema.orgで定義された語彙が使われます。 ただし、 schema.orgに存在するタイプ＝Google検索で特別表示される という意味ではありません。 Google検索には、Googleがサポートしている構造化データと、それぞれの検索機能があります。 そのため実務では、 schema.orgに存在するか だけではなく、 Google検索が現在その機能をサポートしているか まで確認する必要があります。 構造化データとリッチリザルトの違い この2つは混同されやすいので整理します。 構造化データ→ ページの意味を機械が理解しやすい形式で伝えるデータ リッチリザルト→ 構造化データなどを利用して検索結果が通常より豊かに表示される仕組み 例えば商品ページなら、 価格 在庫状況 レビュー情報 などが検索結果上で追加表示される場合があります。 GoogleはProductマークアップにより、対象となる商品ページが価格・在庫などの追加情報を含む商品スニペットの対象になり得ると説明しています。 ただし、 構造化データを設定する＝リッチリザルト表示確定 ではありません。 あくまで表示対象になるための条件を整える施策です。 中小企業サイトで優先したい構造化データ7種類 Organization｜会社情報をGoogleへ伝える 企業サイトなら、まず検討したいのがOrganizationです。 主に、 会社名 URL ロゴ 所在地 電話番号 企業識別情報 などをGoogleへ伝えられます。 Googleは、Organizationの情報をホームページ、または会社について説明する代表的なページに配置することを推奨しており、全ページへ設定する必要はないと説明しています。 おすすめページ トップページ 会社概要ページ 特に優先したいサイト コーポレートサイト BtoBサイト ブランドサイト EC運営企業 Googleは、会社名やロゴ、実世界での所在地・電話番号など、ユーザーに役立つ情報を中心に設定することを推奨しています。 BreadcrumbList｜サイト内の階層を伝える パンくずリストがあるサイトなら、BreadcrumbListも優先度が高い構造化データです。 例えば、 トップ ＞ SEO対策 ＞ 構造化データとは という階層をGoogleへ伝えます。 パンくずリストは、 サイト階層を理解しやすくする ユーザーが上位階層へ移動しやすくなる Googleへページの位置関係を伝える という役割があります。 Googleも、Breadcrumbの構造化データによってページがサイト階層のどこに位置するかを示せると説明しています。 おすすめページ 基本的にはトップページを除く、 サービス詳細 ブログ記事 事例詳細 商品詳細 採用情報 などです。 LocalBusiness｜店舗・地域ビジネス向け 実店舗や地域密着型サービスならLocalBusinessを検討します。 例えば、 飲食店 美容室 歯科医院 整骨院 不動産会社 工務店 地域密着型サービス会社 などです。 GoogleはLocalBusinessにより、 営業時間 所在地 電話番号 ビジネスの種類 部門情報 などをGoogleへ伝えられると説明しています。 また、できるだけ具体的なサブタイプを利用することも推奨されています。 例えば飲食店なら、 LocalBusiness だけでなく、 Restaurant など、より実態に近いタイプを選びます。 なお、ローカル集客では構造化データだけでなく、Googleビジネスプロフィールの登録・管理も重要です。 Googleも、地域ビジネスの所在地や営業時間などを検索・Googleマップへ反映させる手段としてBusiness Profileの管理を案内しています。 Article・BlogPosting｜ブログ・コラム向け オウンドメディアを運営しているなら、 Article BlogPosting NewsArticle などが候補になります。 GoogleはArticle構造化データによって、 記事タイトル 画像 公開日 更新日 執筆者 などの記事情報をより明確に伝えられると説明しています。 おすすめページ SEO記事 コラム ブログ ニュース記事 解説コンテンツ 特にE-E-A-Tを意識するなら、 誰が書いたのか がページ上でも構造化データ上でも分かるように整理しておくとよいでしょう。 JobPosting｜採用ページ向け 求人情報を自社サイトに掲載している企業なら、JobPostingも重要です。 対象は、 会社の採用トップページ というより、 1つ1つの具体的な求人ページ です。 例えば、 Webデザイナー募集 営業職募集 エンジニア募集 などの求人詳細です。 Googleは、適切なJobPosting構造化データを求人ページへ追加することで、Google検索の求人検索体験の対象になれると説明しています。 求人では特に、 投稿日 職務内容 雇用主 勤務地 など、必須項目を正確に設定する必要があります。 募集終了後も古い求人情報を残し続けないよう、運用面まで含めて設計しましょう。 Product｜商品販売・ECサイト向け 商品を販売しているサイトなら、Productを検討します。 Googleが対応する商品情報には、 商品名 価格 在庫 レビュー情報 Offer情報 などがあります。 適切な商品マークアップによって、対象ページが価格や在庫などを含む商品スニペットの候補になります。 優先したいサイト ECサイト メーカーの商品詳細 通販サイト 自社商品販売サイト 価格や在庫は変更されるため、ページ上に表示している情報と構造化データの内容を常に一致させることが重要です。 Event｜セミナー・イベントページ向け セミナーやリアルイベントを開催している企業ならEventがあります。 例えば、 展示会 セミナー 講演会 音楽イベント 地域イベント などです。 GoogleはEvent構造化データを適切に実装することで、イベントがGoogle検索やGoogleマップなどのイベント体験の対象になり得ると案内しています。 ただし、 「毎週開催しています」だけの一覧ページ ではなく、各イベントの、 日時 会場 イベント名 開催情報 を明確にしたページを作ることが基本です。 FAQ・HowToは優先すべき？現在のGoogle検索での扱い 以前は、 FAQPage HowTo がSEO施策として頻繁に紹介されていました。 しかし、現在は注意が必要です。 Googleは2023年にFAQリッチリザルトの表示を大幅に縮小し、現在はよく知られた信頼性の高い政府サイト・医療サイトを中心に表示するとしています。 一般企業サイトでは、FAQPageを設定しても検索結果上でFAQリッチリザルトが通常表示されるものではありません。 さらにHowToについては、Google検索でのリッチリザルト表示自体が終了しています。 そのため一般的な中小企業サイトでは、 「FAQを構造化データにすること」よりも、「ユーザーが抱える疑問へページ上で分かりやすく回答すること」 を優先しましょう。 FAQコンテンツ自体が不要になったわけではありません。 料金 契約 納期 対応範囲 初めて利用する際の不安 などを解消するFAQは、問い合わせ導線として引き続き重要です。 構造化データを入れるべきページ・入れなくていいページ 構造化データは、ページの内容に合わせて設定します。 例えば、 ページ優先候補トップ・会社概要Organizationサービス一覧・詳細BreadcrumbList店舗ページLocalBusiness＋BreadcrumbListブログ記事Article／BlogPosting＋BreadcrumbList求人詳細JobPosting＋BreadcrumbList商品詳細Product＋BreadcrumbListイベント詳細Event＋BreadcrumbList 重要なのは、存在しない情報を構造化データだけで追加しないことです。 Googleの一般ガイドラインでは、構造化データで示す内容はページの主要コンテンツを正しく表している必要があり、ユーザーから見えない情報や誤解を招く情報をマークアップすることは認められていません。 実装するならJSON-LDがおすすめ Googleがサポートしている主な記述形式は、 JSON-LD Microdata RDFa です。 その中でもGoogleはJSON-LDを推奨しています。 例えばOrganizationなら、イメージは次のようになります。 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Organization", "name": "株式会社〇〇", "url": "https://example.com/", "logo": "https://example.com/logo.png", "telephone": "00-0000-0000" } </script> 実際には、 業種 サイト構成 拠点数 Googleが推奨する最新プロパティ などを確認したうえで設定します。 Web上のコード例をコピーして、そのまま使うのはおすすめできません。 構造化データの仕様やGoogle側のサポート内容は変更されることがあるため、実装時点の公式ドキュメントを確認してください。 WordPressなどCMSで実装するときの注意点 SEOプラグインとテーマの二重出力に注意する WordPressでは、 SEOプラグイン テーマ 構造化データ専用プラグイン 独自実装 など、複数箇所からschemaが出力されることがあります。 例えば、 Organizationが2つBreadcrumbListが複数 など、意図しない重複が起きるケースがあります。 そのため、 「プラグインを入れたから完了」 ではなく、実際に出力されているコードを確認することが重要です。 ページ内容と構造化データを一致させる 例えばページ上では、 料金：100,000円 なのに、構造化データでは、 80,000円 となっていたら情報が一致していません。 Googleは、構造化データで参照する内容がユーザーから見えるページ内容と一致し、誤解を招かないことを求めています。 特に、 商品価格 在庫 営業時間 求人情報 イベント日時 は更新漏れに注意します。 自動生成された情報を放置しない CMSで自動生成すると便利ですが、 著者が存在しない 古い会社情報が残る 募集終了求人が残る ロゴURLが切れている といった問題が起きます。 構造化データもサイトコンテンツと同じく、公開後の保守が必要です。 構造化データ実装の7ステップ サイト内のページ種類を整理する まずコードを書くのではなく、ページを分類します。 例えば、 会社情報 サービス 店舗 記事 商品 求人 イベント です。 Googleが現在サポートしている種類を確認する Google Search Centralの「Google検索がサポートしている構造化データ」を確認します。 2026年6月時点の公式一覧には、Article・Breadcrumb・Event・JobPosting・LocalBusiness・Organization・Productなど多数の対応機能が掲載されています。 過去の記事だけを参考にすると、すでにサポート終了している機能を実装してしまう可能性があります。 必須・推奨プロパティを確認する 構造化データごとに、 必須項目 と 推奨項目 があります。 例えばJobPostingでは、Google検索上で求人機能の対象になるために必須プロパティが設定されています。 一方、Organizationには必須プロパティがなく、該当する推奨項目を追加する形になっています。 タイプによって条件は異なるため、個別ガイドを確認します。 まず数ページで実装する いきなりサイト全体へ反映するより、 代表的な数ページ から導入します。 特にテンプレートを変更する場合は、設定ミスがサイト全体へ広がる可能性があります。 リッチリザルトテストで確認する Googleは構造化データ実装時に、まずリッチリザルトテストで確認することを推奨しています。 確認するのは、 検出されているタイプ エラー 警告 必須項目 リッチリザルト対象 などです。 なお、 テストでエラーがない＝検索結果で必ず表示される ではありません。 URL検査でGoogleからの見え方を確認する 公開後はSearch ConsoleのURL検査で、 Googleがアクセスできているか noindexになっていないか robots.txtでブロックされていないか などを確認します。 Googleも構造化データの実装フローとして、テスト後に数ページへ公開し、URL検査でGoogleからどのように見えているか確認する方法を案内しています。 Search Consoleで継続監視する 公開して終わりではありません。 構造化データに対応するリッチリザルトレポートが利用できる場合は、 有効な項目 無効な項目 新しく発生したエラー を確認します。 Googleも、新規実装後・テンプレート変更後・定期的なトラフィック分析時にSearch Consoleを確認することを推奨しています。 構造化データでよくある7つの失敗 とにかく種類を増やす 構造化データの数が多いほどSEOが強くなるわけではありません。 ページ内容に合うものだけ設定します。 ページ上にない情報をマークアップする 構造化データには、 実際にページ上でユーザーが確認できる情報 を使います。 隠された情報や誤解を招く情報はガイドライン違反になる可能性があります。 古いSEO記事を参考にFAQ・HowToを大量実装する Google検索の仕様は変わります。 FAQリッチリザルトは一般サイトでは通常表示されず、HowToリッチリザルトのサポートも終了しています。 実装前に必ず現在の公式情報を確認します。 プラグインを入れて確認しない WordPressのプラグインは便利ですが、 正しく設定されている保証ではありません。 リッチリザルトテストで確認します。 構造化データだけ更新してページを更新しない 商品価格・求人・営業時間などは、 画面表示と構造化データを同時に更新 します。 リッチリザルトが出ない＝実装失敗だと思う 正しく実装しても、Googleがリッチリザルトを表示するとは限りません。 Googleは検索履歴・場所・デバイスなど複数要素を考慮して検索結果を決定するため、構造化データは表示を保証するものではありません。 構造化データだけでSEOを改善しようとする 構造化データ以前に、 検索意図 コンテンツ品質 内部リンク ページ速度 クロール・インデックス サービス内容 実績・一次情報 などを整える必要があります。 構造化データは、良いページの意味をより明確に伝える補助施策として使います。 このまま使えるチェックリスト｜構造化データ実装前後の確認項目 実装前 ページの種類を分類した Googleが現在サポートしているタイプを確認した ページ内容に合ったschemaを選んだ 必須プロパティを確認した 推奨プロパティを確認した 構造化データに使用する情報がページ上にも存在する 古いGoogle仕様を参考にしていない 企業サイト Organizationを確認した 会社名が正しい URLが正しい ロゴが正しい 所在地・電話番号が最新 必要に応じてLocalBusinessを検討した コンテンツ パンくずにBreadcrumbListを検討した 記事にArticle／BlogPostingを検討した 著者情報が正しい 公開日・更新日が正しい 用途別 求人詳細にはJobPostingを検討した 商品詳細にはProductを検討した イベント詳細にはEventを検討した 一般企業サイトでFAQリッチリザルトを前提にしていない HowToリッチリザルトを目的に実装していない 技術確認 JSON-LDなど適切な形式で実装した CMS・プラグインによる二重出力がない リッチリザルトテストを実施した エラーを修正した URL検査を実施した Googlebotをブロックしていない noindexになっていない 公開後 Search Consoleを確認している テンプレート変更後にも再確認した 料金・在庫・営業時間などの更新と連動している Google公式仕様の変更を定期的に確認している まとめ：構造化データは“検索エンジンへの説明書”として設計する 構造化データは、 「入れれば検索順位が上がるSEOテクニック」 ではありません。 役割は、 ページに書かれている情報が何を意味しているのか、検索エンジンへ明確に伝えること です。 中小企業サイトなら、まず、 Organization↓BreadcrumbList↓LocalBusiness（店舗型なら）↓Article／BlogPosting（記事があるなら）↓JobPosting・Product・Event（必要なサイトのみ） という順番で検討すると整理しやすくなります。 そして重要なのは、 ページ内容に合う種類を選ぶ↓Googleの最新公式仕様を確認する↓ページ上の情報と一致させる↓リッチリザルトテストで検証する↓Search Consoleで公開後も監視する という運用です。 Google検索がサポートする構造化データやリッチリザルトは変更されることがあります。 一度設定して終わりではなく、Webサイトのコンテンツと同じように定期的に点検する技術要素として管理していきましょう。 構造化データ・SEO設定の確認ならRefuへ Refuでは、ホームページ制作時のSEO設計だけでなく、 「どのページにどの構造化データが必要か」「WordPressから正しく出力されているか」「Search Console上で技術的な問題が起きていないか」 まで含めたサイト構造・SEO改善を行っています。 「構造化データを設定できているか分からない」「昔入れたschemaが現在も有効か確認したい」「SEOの技術面をまとめて点検したい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 成果を出す企業が必ずやっているアクセス解析の活用法 コンバージョン率を上げるための改善ポイント5選｜成果が伸びるUX改善と導線設計 Web集客に必要なKPIとは？成果を数値で管理する方法｜中小企業が“改善できるサイト”を作る基礎知識 お問い合わせが増えるCTA設計｜ボタン文言・配置・タイミングの鉄則 GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順 検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法
2026/09/07
ホームページ制作の基本よくある質問（FAQ）ページの作り方｜問い合わせ前の不安を減らす設計
FAQページは「問い合わせを減らすページ」ではない FAQとは、Frequently Asked Questions（よくある質問）の略です。 ホームページでは、 「料金はいくらですか？」「どこまで対応してもらえますか？」「依頼してから完成までどのくらいかかりますか？」 など、お客様からよく寄せられる質問とその回答をまとめるために使われます。 FAQページというと、 「同じ質問への対応を減らすためのページ」 というイメージを持つ方も多いでしょう。 もちろん問い合わせ対応の効率化にも役立ちますが、それ以上に重要なのが、 問い合わせするか迷っているユーザーの不安を、先回りして解消すること です。 ユーザーはサービスに興味を持っていても、 費用が分からない 自分も対象になるか分からない 契約後に追加費用が発生しないか不安 何を準備すればいいか分からない 営業されそうで問い合わせしづらい といった小さな疑問によって問い合わせを止めることがあります。 FAQページは、その「あと一歩」を後押しするためのコンテンツです。 FAQページを設置する4つのメリット 問い合わせ前の不安を解消できる サービスページでは説明しきれない細かな疑問を補足できます。 ユーザーが自分の疑問を見つけ、その場で解決できれば、問い合わせへの心理的なハードルが下がります。 問い合わせ対応の負担を減らせる 毎回同じ質問に回答している場合は、その内容をFAQへ掲載できます。 たとえば、 対応エリア 支払い方法 納期 修正回数 営業時間 などです。 問い合わせ前に確認できるようにすることで、双方のやり取りを効率化できます。 サービス説明を補完できる サービスページにすべての細かな条件を書くと、情報量が増えすぎて読みにくくなることがあります。 主要な内容はサービスページで説明し、細かな疑問をFAQで補うことで、サイト全体を整理できます。 ユーザーが使う言葉でコンテンツを作れる 企業側では、 「サービス提供範囲」 と表現していても、ユーザーは、 「どこまでやってもらえますか？」 と考えているかもしれません。 FAQには、ユーザーが実際に使う自然な疑問文を取り入れやすいという特徴があります。 Googleも、検索でユーザーが利用する言葉を意識し、タイトルや見出しなど分かりやすい場所に使用することをSearch Essentialsで案内しています。 どんな質問を載せる？まず整理したい7つのカテゴリ FAQを作るときに困るのが、 「何を質問として載せればいいのか分からない」 という問題です。 まずは次の7カテゴリから考えてみましょう。 料金・費用 ユーザーが問い合わせ前に最も気にしやすい項目です。 例： 料金はいくらですか？ 見積もりは無料ですか？ 追加料金が発生することはありますか？ 支払い方法を教えてください。 分割払いはできますか？ 料金を公開できない場合でも、 「何によって価格が変わるのか」 を説明するだけで不安を減らせます。 サービス内容・対応範囲 「自分の相談も対応してもらえるのか」という疑問です。 例： 〇〇にも対応していますか？ 他社で制作したホームページでも相談できますか？ 小規模な依頼でも対応できますか？ 県外・遠方からでも依頼できますか？ 特にサービスの幅が広い会社では重要です。 依頼から納品までの流れ 初めて依頼するユーザーほど、 「問い合わせた後に何が起きるのか」 を不安に感じます。 例： 問い合わせ後はどのように進みますか？ 打ち合わせは何回ありますか？ 契約前に相談できますか？ オンラインで打ち合わせできますか？ 問い合わせ後の流れを明確にすることで、相談へのハードルを下げられます。 納期・対応期間 例： 依頼してから完成までどのくらいかかりますか？ 急ぎの依頼にも対応できますか？ 〇月までに完成させることは可能ですか？ 単純に「約2ヶ月です」と書くだけでなく、 ページ数・素材準備・確認速度などによって変動する といった条件も説明すると誤解を防げます。 契約・キャンセル・修正 契約直前になるほど重要になる項目です。 例： 契約後のキャンセルはできますか？ 修正は何回まで対応してもらえますか？ 追加作業が必要になった場合はどうなりますか？ 契約期間はありますか？ 契約内容とFAQの記載に違いが出ないよう注意しましょう。 準備するもの・利用条件 例： 依頼前に何を準備すればいいですか？ 写真や文章がなくても依頼できますか？ 専門知識がなくても大丈夫ですか？ どのような会社が対象ですか？ 「準備が大変そう」という理由で問い合わせを止めているユーザーに有効です。 公開後・アフターサポート サービス提供後の不安も重要です。 例： 納品後のサポートはありますか？ 自分たちで更新できますか？ 不具合が起きたら対応してもらえますか？ 保守契約には何が含まれますか？ 高額サービスほど、 「契約した後も大丈夫か」 という安心感が意思決定に影響します。 FAQの質問を集める5つの方法 FAQを作るために、頭の中だけで質問を考える必要はありません。 むしろ、実際のお客様から出ている質問を集める方が価値の高いFAQになります。 営業担当者へ聞く まず、 「商談で毎回聞かれることは何ですか？」 と確認します。 営業担当者が何度も説明している内容は、優先度の高いFAQ候補です。 お問い合わせメールを確認する 過去の問い合わせを見返して、 料金 対応範囲 納期 利用方法 など、繰り返し聞かれている内容を分類します。 電話で聞かれる質問を記録する 店舗や地域ビジネスでは、電話問い合わせも重要な情報源です。 スタッフへ、 「よく電話で聞かれることを1週間記録してください」 と依頼するだけでも、実際のユーザーが知りたい内容が見えてきます。 商談で断られた理由を整理する FAQで特に価値が高いのは、単なる質問ではなく購入・契約を妨げている不安です。 たとえば、 思ったより高そう 自社の規模でも依頼できるか分からない 公開後のサポートが心配 他社との違いが分からない といった理由です。 これらをFAQで先回りして説明すると、比較検討段階のユーザーに役立ちます。 Search Consoleの検索クエリを見る Search Consoleで、 「〇〇 料金」 「〇〇 納期」 「〇〇 対応エリア」 「〇〇 自分でできる」 など、質問につながる検索語句が見つかることがあります。 ただし、検索数がありそうだからという理由だけでFAQを大量に作るのではなく、実際の顧客にとって必要な質問かを優先してください。 Googleも、検索流入だけを目的に大量のコンテンツを作るのではなく、既存または想定するユーザーに役立つ「people-first」のコンテンツを重視するよう案内しています。 読まれるFAQ回答の書き方｜5つの基本ルール 最初の1文で結論を答える ユーザーは早く答えを知りたいので、 質問 → 結論 → 補足 の順番で書きます。 悪い例： Q. 見積もりは無料ですか？ お問い合わせいただいた内容を確認し、ご要望をお伺いしたうえで…… 良い例： Q. 見積もりは無料ですか？ はい、初回のお見積もりは無料です。 ご相談内容を確認したうえで、必要な作業と費用をご案内します。 最初の1文だけでも答えが分かるようにしましょう。 条件・例外を具体的に書く 「可能です」だけでは、あとから認識違いが起きる可能性があります。 例： Q. 修正はできますか？ はい、制作途中の修正にも対応しています。 ただし、確定後の大幅な構成変更や追加ページについては別途費用が発生する場合があります。その際は作業前にお見積もりをご案内します。 このように、 基本回答＋条件＋追加費用等が発生する場合 まで書くと親切です。 専門用語を使いすぎない 自社では当たり前の言葉でも、ユーザーには伝わらないことがあります。 たとえば、 × CMSを実装します。 ではなく、 ○ 専門知識がなくても、お知らせやブログを自社で更新できる仕組みを導入できます。 のように、ユーザーが理解できる言葉へ置き換えます。 専門用語を使う場合は、簡単な説明を添えましょう。 詳細ページへ内部リンクする FAQだけですべてを説明しようとすると、回答が長くなります。 たとえば、 Q. ホームページ制作にはどのくらい費用がかかりますか？ に対して簡潔に回答し、 ホームページ制作の費用相場について詳しくはこちら と関連ページへ誘導します。 これにより、 FAQ → 詳細情報 → 問い合わせ という自然な導線を作れます。 回答の最後に次の行動を示す FAQを読んでも解決できないケースもあります。 そのため、 詳細ページを見る 見積もりを確認する 相談する 問い合わせる などの次の行動を用意しましょう。 例： 「ご希望の公開時期が決まっている場合は、スケジュールを確認いたしますのでお気軽にお問い合わせください。」 FAQを読んで終わるページにしないことが重要です。 FAQは1ページにまとめる？各サービスページにも置く？ 結論としては、両方を使い分ける方法がおすすめです。 FAQ一覧ページ サイト全体に共通する質問をまとめます。 例： 支払い 契約 営業時間 対応エリア 会社全体のサービス 質問が多い場合は、 料金／サービス／契約／サポート などのカテゴリに分けると探しやすくなります。 サービスページ内のFAQ そのサービスを検討しているユーザーだけが知りたい質問を掲載します。 例： ホームページ制作ページなら、 制作期間 修正回数 原稿準備 WordPress 公開後保守 などです。 重要な質問をFAQ一覧だけに置いてしまうと、サービスページを見ているユーザーがわざわざ探しに行かなければなりません。 そのため、 意思決定に関係する質問はサービスページにも掲載し、FAQ一覧ページにはより幅広く整理する という設計が使いやすいでしょう。 FAQとSEOの関係｜検索流入を意識するときの考え方 FAQはSEOにも活用できますが、 「質問を大量に追加すれば検索順位が上がる」 というものではありません。 Googleは、検索エンジンを主目的にしたコンテンツではなく、ユーザーにとって有用で信頼できるpeople-firstコンテンツを作ることを推奨しています。 FAQでSEOを意識する場合も、考え方は同じです。 ユーザーが実際に疑問に思う質問を書く 検索キーワードを無理に文章へ詰め込むのではなく、 「ユーザーがどう質問するか」 をそのまま見出しにします。 質問に対して明確に答える 検索キーワードを入れることより、 その質問を検索した人が、読んだ後に疑問を解決できること の方が重要です。 詳細情報がある場合は関連ページへつなぐ FAQから、 サービス 料金 事例 ブログ お問い合わせ へ内部リンクすることで、サイト内の情報をつなげます。 同じ質問のページを大量に作らない FAQページとブログ記事でほぼ同じ内容を繰り返すと、情報が分散します。 短く答えられる質問はFAQ、詳しい解説が必要なら個別記事を作り、FAQから内部リンクする方法が整理しやすいです。 2026年現在の注意点｜FAQリッチリザルトは終了 FAQとSEOについて検索すると、 「FAQ構造化データを設定すると、Google検索結果に質問と回答が大きく表示される」 という古い情報が出てくることがあります。 しかし、この点は現在注意が必要です。 Googleは2023年にFAQリッチリザルトの表示対象を大幅に限定した後、2026年5月7日からFAQリッチリザルトをGoogle検索結果に表示しない方針へ変更しました。 さらに2026年6月には、FAQリッチリザルト機能が検索結果で使用されなくなったことを理由に、Google Search CentralからFAQリッチリザルトに関するドキュメントも削除されています。 そのため2026年現在、 「FAQ構造化データを入れれば検索結果で目立てる」 という説明は適切ではありません。 FAQを作る目的は、 ユーザーの疑問を解決する 比較検討を助ける サービス内容を補完する 問い合わせへの不安を減らす 関連情報への導線を作る といったページそのものの価値に置くべきです。 SEOのためだけに質問を量産するのではなく、本当にユーザーが知りたい内容を充実させましょう。 FAQページでよくある失敗7選 企業側が説明したい質問だけ載せている FAQなのに、 「当社の強みは何ですか？」 など、自社がアピールしたい質問ばかり並んでいるケースがあります。 実際にお客様から聞かれる質問を優先しましょう。 回答が「お問い合わせください」だけ 例： Q. 料金はいくらですか？A. お問い合わせください。 これではユーザーの疑問が何も解決していません。 正確な金額が出せなくても、 「〇〇によって変わるため個別見積もりです」 など、判断材料をできるだけ提供しましょう。 質問数が多すぎて探せない 50問・100問と増えると、一覧を眺めるだけでは探せなくなります。 質問が増えた場合は、 料金 サービス ご依頼方法 契約 サポート などに分類し、目次や絞り込みを設けます。 他社FAQをそのまま参考にする 競合企業にある質問でも、自社では条件が違う可能性があります。 回答内容が契約条件と異なるとトラブルにつながるため、自社の実態を基準に作成してください。 FAQとサービスページの説明が食い違っている 例： サービスページ：修正3回までFAQ：修正回数に制限なし このような状態はユーザーを混乱させます。 料金・契約・サービス内容を変更した場合は、FAQもセットで更新しましょう。 FAQだけで詳しく説明しすぎる 1回答が何千文字もあるなら、FAQではなく独立したページや記事として作った方が読みやすい場合があります。 FAQでは要点を回答し、 「詳しくはこちら」 と内部リンクする方法がおすすめです。 SEO目的で似た質問を大量に並べる たとえば、 ホームページ制作の料金はいくら？ HP制作の費用はいくら？ Web制作の値段はいくら？ というように、ほぼ同じ質問を言い換えて並べてもユーザーには役立ちません。 Googleが推奨しているのは、検索エンジン向けに大量生成された内容ではなく、ユーザーが目的を達成できる有用なコンテンツです。 質問を増やすことより、一つひとつの回答の質を優先しましょう。 そのまま使えるFAQ作成テンプレート FAQを作成するときは、次の形式にすると整理しやすくなります。 質問 ユーザーが実際に使いそうな言葉で書く。 Q. ホームページ制作にはどのくらい期間がかかりますか？ 結論 最初の1〜2文で回答。 A. 一般的なコーポレートサイトの場合、約2〜3ヶ月が目安です。 条件・補足 変動条件や例外を説明。 ページ数や機能、原稿・写真の準備状況、お客様側の確認期間によって制作期間は変動します。 次の行動 必要に応じて内部リンク・問い合わせへ。 ご希望の公開時期が決まっている場合は、逆算した制作スケジュールをご案内できますので、お気軽にご相談ください。 FAQ回答の基本型 結論 → 理由・条件 → 具体例 → 詳細ページまたは問い合わせ この順番を統一すると、FAQ全体が読みやすくなります。 公開後の更新方法｜FAQは“顧客の声”で育てる FAQは公開して完成ではありません。 むしろ、サイト運用を続けながら育てていくコンテンツです。 おすすめの運用方法は、 「新しく2〜3回聞かれた質問はFAQ候補にする」 というルールです。 たとえば、 営業・問い合わせ担当が質問を記録 月1回まとめて確認 既存FAQに回答があるか確認 なければ追加 古くなった回答も同時に更新 という流れです。 また、 問い合わせで同じ質問が増えた＝ホームページ内の説明が足りない 可能性もあります。 その場合はFAQを追加するだけではなく、サービスページそのものへ説明を追加することも検討しましょう。 FAQはユーザーの疑問を集めることで、 ホームページ全体の改善ポイントを見つける材料 にもなります。 FAQページ公開前チェックリスト 質問内容 実際のお客様から聞かれる内容を優先している 料金・サービス・流れ・納期・契約・サポートを確認した 似た質問を重複させていない 自社が答えたいことだけになっていない 回答内容 最初の1文で質問に回答している 必要な条件・例外を書いている 専門用語を説明している 回答が長すぎない 「お問い合わせください」だけで終わっていない 契約内容・料金表と食い違っていない 導線 料金ページへリンクしている サービスページへリンクしている 事例ページへ必要に応じてリンクしている 問い合わせへの導線がある サービスページにも重要FAQを配置している 運用 FAQの更新担当者を決めた 問い合わせ内容を蓄積できる仕組みがある 料金・サービス変更時にFAQも確認する 定期的に古い回答を見直す SEO ユーザーが実際に使う自然な質問文になっている SEO目的だけで質問を量産していない FAQリッチリザルト表示を前提にしていない 必要に応じて詳細記事へ内部リンクしている まとめ：FAQはユーザーの「最後の迷い」を解消するページ よくある質問（FAQ）ページは、単に問い合わせ対応を減らすためのページではありません。 本当に重要なのは、 「興味はあるけれど、まだ問い合わせるほどではない」 というユーザーの疑問を解消し、次の行動へ進みやすくすることです。 成果につながるFAQを作るには、 実際のお客様から出た質問を集める 料金・サービス・納期・契約など不安の大きい項目を優先する 最初に結論を回答する 条件や例外まで正確に書く 詳細ページへ内部リンクする 問い合わせ内容をもとに定期的に更新する ことが重要です。 また、2026年現在はGoogle検索におけるFAQリッチリザルトが終了しているため、FAQを作る目的を「検索結果を大きく表示させるため」に置くべきではありません。 Googleが一貫して推奨しているように、検索エンジンではなくユーザーを第一に考えた有用なコンテンツを作ることが基本です。 FAQを、 「ユーザーが問い合わせ前に抱える最後の疑問を解消するページ」 として設計し、サービスページ・料金・実績・お問い合わせまで自然につながるホームページを作りましょう。 FAQ・問い合わせ導線の改善ならRefuへ Refuでは、実際の問い合わせ内容やユーザーの検討プロセスを整理し、サービスページ・FAQ・CTA・問い合わせフォームまで一貫した導線設計を行っています。 「FAQに何を載せればいいか分からない」「アクセスはあるのに問い合わせにつながらない」「同じ質問への対応が多い」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本 原稿が書けないを解決！伝わる文章構成テンプレと作り方 ホームページのKPI設計｜アクセス・CV・問い合わせを“数字で改善”する方法 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 成果が出る「実績・事例」ページの作り方｜信頼を獲得して問い合わせを増やす お客様の声の集め方・見せ方｜信頼性を高める掲載テンプレと注意点 プライバシーポリシーは必要？ホームページに掲載すべき項目と作り方
2026/09/03
集客・マーケティング戦略検索順位は高いのにクリックされない原因｜タイトル・ディスクリプションの改善方法
検索順位が高くてもクリックされなければアクセスは増えない SEOでは検索順位ばかり注目されがちですが、 「上位表示されている＝十分に集客できている」 とは限りません。 例えば、Search Consoleを確認すると、 平均掲載順位は5位前後 表示回数も十分ある しかしクリックされていない というページが見つかることがあります。 このような場合に重要なのが、CTR（クリック率）の改善です。 Google Search Consoleでも、CTRが低いページを確認し、ページ内容をより正確に表すようタイトルや説明を改善したり、表示されている検索クエリに合わせてコンテンツを調整したりする方法が案内されています。 新しい記事を増やす前に、すでに検索結果へ表示されているページのCTRを改善できれば、同じ掲載順位でも検索流入を増やせる可能性があります。 まず結論：CTR改善は「タイトルを目立たせること」ではなく“検索者に選ぶ理由を伝えること” CTRを改善すると聞くと、 【最新版】を付ける 数字を入れる 「必見！」と付ける 強い言葉を使う といったテクニックを考えるかもしれません。 しかし、本質はそこではありません。 Googleはタイトルリンクについて、検索結果の内容と検索クエリとの関連性をユーザーが素早く理解するための重要な情報であり、ユーザーがどの検索結果をクリックするか判断する際の主要な材料になると説明しています。 つまりCTR改善とは、 「このページを読めば、自分が知りたいことが分かりそう」 と検索者に正しく伝える作業です。 目立つタイトルではなく、選ぶ理由が分かるタイトルを作ることが重要です。 順位は高いのにクリックされない7つの原因 タイトルと検索意図がズレている 例えば、検索キーワードが 「ホームページ制作 費用」 なのに、タイトルが 「ホームページ制作について詳しく解説」 では、費用を知りたい人にとってクリックする理由が弱くなります。 改善するなら、 「ホームページ制作の費用相場｜料金の内訳と見積り比較ポイントを解説」 のように、検索者が知りたい内容をタイトル上で明確にします。 タイトルが抽象的で「読むメリット」が分からない 例えば、 「SEO対策について解説」 だけでは、 初心者向けなのか 具体的な方法なのか 費用の話なのか 自社でできるのか が分かりません。 一方、 「中小企業のSEO対策｜まず取り組むべき7つの施策と優先順位」 なら、誰向けで、何が分かるのかを検索結果だけで判断できます。 競合とタイトルが似すぎている 検索結果を確認すると、 SEO対策とは？初心者向けに解説 SEO対策とは？基本を分かりやすく解説 SEO対策とは？初心者向け完全ガイド SEO対策の基本を初心者向けに解説 のように、似たタイトルが並ぶケースがあります。 この中で選ばれるには、 「自社の記事を選ぶ理由」 が必要です。 例えば、 中小企業向け BtoB向け 自社でできる 費用まで解説 チェックリスト付き 実例あり など、そのページ固有の価値をタイトルへ反映します。 ディスクリプションだけで内容を伝えようとしている 検索結果ではタイトルの視認性が高いため、重要な情報をすべてmeta descriptionへ回してしまうのはおすすめできません。 例えば、 タイトル：ホームページ制作会社の選び方 description：料金・実績・契約・担当者・制作体制など、失敗しないために確認したい10項目を紹介します。 なら、 タイトル：ホームページ制作会社の選び方｜失敗しない10のチェック項目 のように、重要な価値はタイトル側にも反映した方が内容を理解しやすくなります。 検索結果に表示されるタイトルが想定と違う CMSで設定したtitleタグと、Google検索結果に表示されるタイトルが違うことがあります。 Googleの検索結果に表示されるタイトルリンクは自動生成されており、 <title>要素 ページ内のメインタイトル H1などの見出し og:title 大きく目立つテキスト 本文 アンカーテキスト 外部サイトからのリンク文言 など、複数の情報を使用して決定されます。 そのため、titleタグだけ修正すれば必ずその文章が表示されるわけではありません。 検索結果そのものが変化している CTRが落ちた理由が、自社タイトルとは限りません。 検索結果には、 AIによる検索機能 地図 動画 画像 商品情報 リッチリザルト 広告 など、通常の検索結果以外の要素が表示されることがあります。 そのため、順位が同じでも、以前と同じCTRになるとは限りません。 Search Console上の数字だけではなく、実際に検索して現在のSERP（検索結果画面）を確認することも重要です。 順位以外のデータを見ずにCTRを判断している 例えば、 先月 表示回数：1,000 クリック：100 CTR：10％ 今月 表示回数：3,000 クリック：180 CTR：6％ なら、CTRは下がっています。 しかしクリック数は、 100 → 180 に増えています。 つまり、新しい検索クエリでも表示されるようになった結果、CTRが下がった可能性があります。 CTRだけで、 「悪化した」 と判断しないことが重要です。 Search Consoleで低CTRページを見つける ページをCTR順に並べる Search Consoleの、 検索結果 → パフォーマンス を開きます。 次に、 CTRを表示 「ページ」を選択 CTRの低い順に並べる ことで、低CTRページを確認できます。 GoogleもSearch Consoleでこの方法を案内しており、CTRが低い場合にはタイトル・説明・コンテンツとクエリの一致を確認することを推奨しています。 表示回数が十分あるページから優先する CTRが0％でも、 表示回数10回 なら優先度は低いかもしれません。 一方、 表示回数10,000回・CTR1％ なら、改善余地が大きい可能性があります。 したがって、 CTRが低い×表示回数が多い×自社サービスに近い ページから優先します。 ページからクエリまで掘り下げる ページ単位でCTRを見るだけでは不十分です。 対象ページをクリックして、「クエリ」を確認します。 例えば、 クエリ平均順位表示回数CTRホームページ制作 費用4.55,0007%ホームページ制作 相場5.24,0003%ホームページ 見積もり6.02,0001% なら、ページ全体ではなく、 「見積もり」系の検索意図にタイトルや内容が十分対応できていない 可能性があります。 Google Search Consoleでは、特定クエリを選択したうえで、その検索で表示されているページを確認できます。 前期間と比較してCTR低下を確認する おすすめは、 直近3か月 vs 前の3か月 です。 さらに季節性がある場合は、前年同期とも比較します。 「CTRが低い」のではなく、「以前より落ちたのか」を見ることが重要です。 「CTRが低い＝悪い」と即判断しない 掲載順位が下がっていないか確認する CTRが下がったときは、平均掲載順位も確認します。 例えば、 平均順位3位 → 8位 になっているなら、CTR低下の主因はタイトルではなく、順位低下の可能性があります。 この場合は、 技術問題 検索意図 コンテンツ Googleアップデート 検索需要 などから原因を分析します。 新しい検索クエリで表示が増えた可能性もある 記事の評価範囲が広がり、新しいクエリで表示されるようになると、 表示回数↑・CTR↓・クリック↑ という状態になることがあります。 これは必ずしも悪化ではありません。 平均CTRだけではなく、どの検索クエリで変化したかまで確認します。 指名検索と一般検索を分けて考える 会社名・ブランド名で検索する人と、一般的なキーワードで初めて会社を知る人では、検索行動が異なります。 Search Consoleでは利用可能なプロパティについて、ブランドクエリと非ブランドクエリを分けて分析できるフィルタも提供されています。 特にオウンドメディアの記事改善では、非指名検索でどれだけ選ばれているかを見ると、新規ユーザー獲得の改善点を見つけやすくなります。 クリックされるタイトルへ改善する7つのポイント Googleは、title要素について、 ページ内容を説明する 簡潔にする 曖昧なタイトルを避ける キーワードを詰め込まない ページごとに固有のタイトルにする といった基本を案内しています。 そのうえで、実務では次の7点を確認します。 検索者が知りたい答えを前半に置く × 初心者でもよく分かる完全解説！ホームページ制作の費用について○ ホームページ制作の費用相場｜料金内訳と見積りの見方 重要テーマを前半へ配置します。 Googleはtitle要素自体の文字数に固定上限を設けていませんが、検索結果のタイトルリンクはデバイス幅などに応じて必要に応じて省略されます。 そのため、重要な意味を後半に詰め込みすぎない方が安全です。 「誰向けか」を具体的にする × Web集客の方法○ 中小企業のWeb集客｜SEO・広告・SNSの選び方 ターゲットが明確なら、「これは自分向けの記事だ」と判断してもらいやすくなります。 得られる情報を具体化する × SEO対策の基本 より、 ○ SEO対策の基本｜初心者が最初にやるべき7つの施策 の方が、ページを読むことで何が得られるのか分かります。 数字は意味がある場合だけ使う 数字は具体性を高められます。 例えば、 7ステップ 10項目 3つの原因 などです。 ただし、 「数字を入れるとCTRが上がるから」 という理由だけで、不自然に項目数を増やす必要はありません。 内容を整理した結果として数字を使用します。 比較・費用・手順・注意点など検索意図を表現する 検索者が、 「何を判断したくて検索しているのか」 をタイトルへ反映します。 例えば、 情報収集SEO対策とは？初心者向けに基本を解説 方法を知りたいSEO対策のやり方｜中小企業が最初に取り組む7ステップ 比較したいSEOとWeb広告はどちらがいい？費用・即効性・資産性を比較 失敗したくないSEO会社の選び方｜契約前に確認したい10項目 同じSEOテーマでも、検索意図によってタイトルは変わります。 ページごとに固有のタイトルを設定する 例えば、 株式会社○○｜サービス紹介 を複数ページで使い回すのではなく、 ホームページ制作 SEO支援 採用サイト制作 Web広告運用 それぞれの内容に合わせてtitleを設定します。 Googleも、繰り返しの定型文ばかりになったtitleや、ページを区別できないtitleを避けるよう案内しています。 キーワードを詰め込みすぎない × ホームページ制作｜HP制作｜Web制作｜ホームページ作成｜Webサイト制作 では、ユーザーが内容を理解しにくくなります。 Googleも、title要素で同じ単語やフレーズを不必要に繰り返すキーワードスタッフィングを避けるよう明示しています。 SEOキーワードを「入れられるだけ入れる」のではなく、検索者に自然に意味が伝わるタイトルにします。 タイトル改善のBefore／After例 検索意図BeforeAfter制作費を知りたいホームページ制作についてホームページ制作の費用相場｜料金内訳と見積りの仕組み会社を選びたい制作会社のご紹介ホームページ制作会社の選び方｜失敗しない10のチェック項目問い合わせを増やしたいCTAについて解説お問い合わせが増えるCTA設計｜文言・配置・タイミングを解説SEO順位低下SEO順位について検索順位が下がった原因は？Search Consoleで調べる7ステップリライトしたい記事更新の方法SEO記事のリライト方法｜優先すべきページの見つけ方 共通しているのは、 「何の記事か」＋「何が分かるか」 を検索結果だけで理解できることです。 meta descriptionを改善する5つのポイント ページ全体を正確に要約する meta descriptionは、「クリックさせるための煽り文句」ではありません。 Googleは、ページの内容を簡潔かつ適切に要約し、ユーザーへ情報を提供して興味を持ってもらえる説明にすることを推奨しています。 タイトルで伝えきれない判断材料を補足する 例えば、 タイトル：ホームページ制作会社の選び方｜失敗しない10のチェック項目 description：制作実績・料金・契約内容・担当者・公開後の運用まで、制作会社を比較するときに確認したい10項目を中小企業向けに解説します。 というように、 タイトル＝テーマdescription＝読むことで得られる具体的情報 として役割分担すると分かりやすくなります。 ページ固有の説明を作る 全記事で、 「株式会社○○ではWebマーケティングに役立つ情報を発信しています」 という同じdescriptionを使い回すのは避けます。 Googleも、可能な限りページごとに固有で、そのページを正確に説明するmeta descriptionを設定することを推奨しています。 キーワードの羅列にしない × SEO対策、SEO会社、SEO費用、SEO方法、SEO記事、検索順位、SEO改善 のようなキーワード一覧では、何が書かれているページなのか分かりません。 文章として検索者へ意味を伝えます。 Googleも、長いキーワードの羅列ではページ内容を明確に伝えられず、スニペットとして採用される可能性が低くなると説明しています。 文字数だけをSEO基準にしない よく、 「meta descriptionは120文字がSEOに最適」 といった情報を見かけますが、Googleはmeta descriptionに固定の文字数制限を設けていません。 検索結果上ではデバイス幅などに応じて必要に応じて省略されます。 そのため、120文字に合わせることそのものが目的ではありません。 Refuの記事制作では運用上120文字前後を目安にしていますが、本来重要なのは、 ページ内容を正確に説明できている 重要情報が前半にある 検索者が読むメリットを理解できる ことです。 Googleにタイトル・ディスクリプションを変更される原因を確認する titleタグだけが検索結果タイトルの情報源ではない Googleは検索結果のタイトルリンクを自動生成しています。 そのため、 設定したtitle＝必ず表示されるタイトル ではありません。 Googleがtitleを変更する代表的なケースとして、 titleの一部が欠けている titleが古い ページ内容を正確に表していない 定型文が多い メインタイトルが不明確 などが挙げられています。 titleとH1・本文を一致させる 例えば、 title：ホームページ制作費用を完全解説 なのに、 H1：Webサイト制作について 本文も費用より会社紹介中心。 この状態では、ページの主題が曖昧になります。 タイトルだけSEO用に作るのではなく、 title H1 導入文 見出し 本文 まで一貫したテーマにします。 meta descriptionは必ず表示されるわけではない meta descriptionを設定しても、その文章が毎回そのまま検索結果へ表示されるわけではありません。 Googleは主にページ本文からスニペットを自動生成し、meta descriptionの方がページを適切に説明できると判断した場合には、その内容を使用することがあります。 また、検索クエリによって異なるスニペットが表示される場合があります。 つまり、 meta descriptionだけを最適化すればよいわけではありません。 本文そのものにも、 明確な回答 分かりやすい説明 検索者が探している情報 を配置します。 検索結果そのものを見て「クリックされない理由」を探す Search Consoleで低CTRページを見つけたら、実際の検索結果も確認します。 競合のタイトル 自社： ホームページ制作の費用について 競合： ホームページ制作の費用相場｜50万・100万・300万円で何が違う？ なら、競合の方が判断材料を具体的に提示しています。 競合が何を訴求しているか 費用 事例 チェックリスト 比較表 初心者向け 専門家監修 などを確認します。 ただし、競合タイトルをそのまま真似するのではありません。 検索者が何を判断材料として求めているかを理解し、自社独自の価値へ変換します。 検索結果の構成 通常のWebページ以外に、 地図 動画 画像 AI機能 商品 広告 などが多く表示されている場合があります。 そのキーワードで記事ページを改善し続けるべきなのかも含めて判断します。 自社ページのタイトルが想定どおり表示されているか 設定したtitleとGoogle上のタイトルが大きく違うなら、 title H1 本文 ページテーマ の整合性を確認します。 変更後のCTRを検証する 改善したら必ず記録します。 【CTR改善管理表】 項目記録内容URL対象ページ変更日2026/○/○対象クエリホームページ制作 費用変更前title○○変更後title○○変更前description○○変更後description○○変更理由CTR低下／検索意図ズレ等変更前CTR○％変更後CTR○％クリック変化○→○CV変化○→○ Googleはタイトルリンクに関わる情報の変更を認識するには再クロール・再処理が必要で、変更の反映には数日から数週間かかる場合があると案内しています。 そのため、 翌日にCTRが上がらないから再変更 という運用は避けます。 一定期間データを取り、 表示回数 CTR クリック数 掲載順位 CV を比較します。 CTRを上げようとしてやってはいけない5つのこと 内容と違う「釣りタイトル」を付ける 「知らないと損！」「絶対に成功する！」 など、ページ内容以上に期待させるタイトルは避けます。 クリックされても期待と内容が一致しなければ、ユーザー体験を損ないます。 「最新」「2026年版」を意味なく付ける 内容を更新していないのに、 【2026年最新版】 と付けても価値は高まりません。 年度表記をするなら、情報を実際に確認・更新します。 キーワードを大量に詰め込む Googleもtitleでの不必要なキーワードの繰り返しを避けるよう案内しています。 検索エンジンではなく、人が読んで意味の分かるタイトルにします。 「No.1」「最安」「絶対」など根拠のない強い表現を使う CTRを上げる目的で、 顧客満足度No.1 地域最安 業界最高品質 必ず成果が出る といった表現を安易に使用するのは注意が必要です。 消費者庁は、商品・サービスについて実際より著しく優れていると誤認させる表示などを景品表示法で禁止しています。また、合理的な根拠がないNo.1表示が不当表示として問題になる可能性もあります。 CTRより信頼性を優先してください。 CTRだけを改善目標にする タイトルを強くして、 CTR4％ → 7％ になっても、 問い合わせ3件 → 0件 なら、事業成果として成功とは言えません。 最終的には、 表示 → クリック → 回遊 → CTA → 問い合わせ まで確認します。 このまま使えるチェックリスト｜低CTRページ改善テンプレ Search Console分析 表示回数が十分ある 現在の掲載順位を確認した CTRを確認した 前期間と比較した 前年同期も必要に応じて確認した ページ単位で確認した クエリ単位まで確認した クリック数そのものも確認した 検索意図 実際のGoogle検索結果を確認した 現在の検索意図と記事内容が一致している 競合タイトルとの差を確認した 検索者が知りたい答えが明確 記事ページで狙うべき検索か確認した title ページ内容を正確に表している 重要テーマが前半にある 誰向けか必要に応じて明確にしている 読むことで得られる情報が分かる ページ固有のタイトルになっている キーワードを詰め込んでいない titleとH1・本文に一貫性がある 根拠のないNo.1・最安・断定表現を使っていない meta description ページ全体を正確に要約している titleで伝えきれない情報を補足している ページ固有の説明になっている キーワードの羅列になっていない 文字数合わせだけを目的にしていない 公開後 変更日を記録した 変更前後のtitleを記録した CTRの変化を確認した クリック数の変化を確認した 掲載順位も確認した GA4でCVへの影響を確認した まとめ：クリック率改善は「煽る」のではなく“選ぶ理由を明確にする” 検索順位が高いのにアクセスが増えない場合、 「もっと順位を上げなければ」 と考える前に、Search ConsoleでCTRを確認してください。 改善手順は、 低CTRページを見つける↓クエリまで分析する↓順位低下ではないか確認する↓現在の検索結果を見る↓title・H1・本文の検索意図を合わせる↓meta descriptionを改善する↓CTR・クリック・CVを再計測する です。 Googleも、CTRが低いページについて、ページ内容をより正確に表すタイトル・説明への更新や、検索クエリに合わせたコンテンツ調整を検討するよう案内しています。 ただし、CTRを上げることだけを目的に、 「絶対」「No.1」「知らないと損」 といった強い表現を増やすのは本質ではありません。 重要なのは、 検索結果を見た人に「自分が探している答えが、このページにありそう」と正確に伝えること。 SEOは上位表示させて終わりではありません。 表示される → 選ばれる → 読まれる → 比較される → 問い合わせにつながる ところまで設計して、初めてWeb集客として成果につながります。 CTR改善から問い合わせ導線まで見直すならRefuへ Refuでは、Search Console・GA4を使い、 「順位はあるのになぜクリックされないのか」「どのタイトルから改善すべきか」「検索流入はあるのになぜ問い合わせにつながらないのか」 を分析し、タイトル・コンテンツ・内部リンク・CTAまで含めたサイト改善を行っています。 「上位表示できているのにアクセスが少ない」「記事数を増やす前に既存ページを改善したい」「Search Consoleを見ても何を直せばいいか分からない」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 成果を出す企業が必ずやっているアクセス解析の活用法 コンバージョン率を上げるための改善ポイント5選｜成果が伸びるUX改善と導線設計 Web集客に必要なKPIとは？成果を数値で管理する方法｜中小企業が“改善できるサイト”を作る基礎知識 お問い合わせが増えるCTA設計｜ボタン文言・配置・タイミングの鉄則 GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順 検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法
2026/08/31
ホームページ制作の基本多言語ホームページの作り方｜翻訳・SEO・運用で失敗しないポイント
多言語ホームページは、単に日本語サイトを翻訳するだけでは十分ではありません。 海外企業との取引、外国人顧客の獲得、インバウンド対応、外国人材の採用などを目的に、多言語ホームページを検討する企業は増えています。 そのときによくあるのが、 「今ある日本語サイトを英語に翻訳すればいい」 という考え方です。 しかし、多言語ホームページで成果につなげるには、文章を別の言語へ置き換えるだけでは不十分です。 考える必要があるのは、 誰に見てもらうのか どの国・地域を対象にするのか どのような言葉で検索されるのか どんな情報が信用につながるのか どうやって問い合わせてもらうのか 公開後に誰が更新するのか といった、サイト全体の設計です。 多言語サイトは、「翻訳作業」ではなく「別のユーザーに向けたホームページ制作」として考えることが重要です。 「多言語サイト」と「多地域サイト」の違い 似た言葉ですが、「多言語」と「多地域」では考え方が異なります。 多言語サイト 複数の言語でコンテンツを提供するサイトです。 例えば、 日本語 英語 中国語 ベトナム語 など、言語ごとにページを用意します。 多地域サイト 複数の国や地域を対象として、ユーザーごとに異なる情報を提供するサイトです。 例えば同じ英語でも、 アメリカ向け イギリス向け オーストラリア向け では、価格・サービス内容・配送条件・表現などが異なる場合があります。 そのため制作前には、 「英語ページを作りたい」 だけでなく、 「英語を使う、どの国・地域の誰に届けたいのか」 まで整理しておくことが重要です。 多言語ホームページ制作前に決めるべき5つのこと 多言語サイトを作り始める前に、最低限次の5項目を整理しましょう。 対象となる国・地域 まず、どこにいるユーザーへ届けたいのかを決めます。 例えば、 アメリカ 東南アジア ベトナム 中国 日本国内に住む外国人 などです。 対象地域によって、必要な言語や情報が変わります。 対応する言語 「海外向けだから英語」とは限りません。 実際の顧客や採用ターゲットを基準に、必要な言語を決めます。 サイトの目的 多言語化の目的も明確にします。 例えば、 海外企業からの問い合わせ獲得 海外への商品販売・輸出 外国人観光客からの予約 外国人材の採用 海外拠点の紹介 などです。 目的によって、必要なページや問い合わせ導線は異なります。 翻訳するページ すべてのページを最初から翻訳する必要はありません。 まずは、 トップページ サービスページ 会社概要 実績・事例 FAQ お問い合わせ など、ユーザーが比較・判断するために必要なページから対応する方法もあります。 公開後に誰が更新するのか 多言語サイトでは、公開後の更新体制が非常に重要です。 公開時には正確に翻訳されていても、 半年後には日本語版だけ更新され、外国語版の料金やサービス内容が古い という状態は避けなければなりません。 制作段階から、 「日本語を更新したら、誰が他言語版を確認・更新するのか」 まで決めておきましょう。 多言語サイトのURL設計｜言語ごとに別URLを用意する 多言語SEOで重要なのがURL設計です。 基本的には、言語ごとに異なるURLを用意し、それぞれのページへ検索エンジンがアクセスできる状態にします。 代表的な方法は次の3つです。 サブディレクトリ 例： 日本語example.com/ja/ 英語example.com/en/ 中国語example.com/zh/ 同じドメイン内で管理できるため、中小企業サイトでも比較的運用しやすい方法です。 サブドメイン 例： ja.example.com en.example.com 言語や地域ごとにサイトを分けて管理しやすい反面、運用環境が複雑になりやすい点には注意が必要です。 国別ドメイン 例： ドイツexample.de フランスexample.fr 対象国が明確になるメリットがありますが、ドメイン・サーバー・サイト管理の負担も増えます。 初めて多言語サイトを制作する中小企業であれば、既存ドメイン内のサブディレクトリ方式は、管理のしやすさという点で検討しやすい選択肢です。 多言語SEOで重要なhreflangとは？ 多言語サイトで覚えておきたい設定の一つが、hreflang（エイチレフラング）です。 言語・地域ごとのページ関係を検索エンジンへ伝える 例えば、 日本語版 英語版 中国語版 に同じ内容のページが存在する場合、 「これらは、それぞれ異なる言語のユーザー向けページです」 と検索エンジンへ伝えるためにhreflangを使用します。 設定方法としては、 HTML HTTPヘッダー XMLサイトマップ などがあります。 複数の方式を無理に併用する必要はなく、サイトの管理方法に合った形で正しく運用することが重要です。 hreflangは相互設定する hreflangで注意したいのが、一方向だけ設定するケースです。 例えば、 日本語ページ → 英語ページ だけ設定し、 英語ページ → 日本語ページ の指定がない状態です。 基本的には、それぞれの言語版から、自分自身を含む対応ページを指定します。 例えば、 日本語ページ→ 日本語・英語・中国語 英語ページ→ 日本語・英語・中国語 中国語ページ→ 日本語・英語・中国語 という形です。 新しい言語ページを追加するときは、翻訳作業だけでなく、既存ページを含めたhreflangの更新まで作業範囲に含めましょう。 x-defaultでデフォルトページを指定する サイトで対応していない言語のユーザーがアクセスする場合もあります。 その際に利用できるのが、 hreflang="x-default" です。 例えば、 「Select your language」 という言語選択ページを、特定の言語に当てはまらないユーザー向けのページとして指定する方法があります。 翻訳で失敗しないための5つのポイント 直訳ではなく「現地で伝わる文章」にする 日本語として自然な表現でも、そのまま翻訳すると海外ユーザーには伝わりにくい場合があります。 例えば、 「地域密着で、お客様に寄り添います」 という表現です。 日本ではよく見られますが、海外ユーザーが知りたいのは、 どの地域まで対応しているのか どれくらい早く対応できるのか 具体的にどこまで支援してくれるのか といった情報かもしれません。 多言語化では、日本語をそのまま別の言語へ置き換えるのではなく、対象ユーザーに必要な情報へ編集することが重要です。 検索キーワードも言語ごとに調査する 日本語SEOで狙っているキーワードを、そのまま英訳すればよいとは限りません。 例えば日本語の、 「ホームページ制作」 に対して、英語圏では目的によって、 web design website development web design agency website company など、異なる表現で検索される可能性があります。 そのため、 日本語キーワードを翻訳する のではなく、 対象言語・地域で実際に使われる検索表現を調べる ことが重要です。 titleや見出し、本文も、その地域の検索意図に合わせて設計しましょう。 料金・単位・日付・住所表記もローカライズする 文章だけ翻訳されていても、 円だけで料金が表示されている 日本独自の単位を使用している 電話番号が国内形式のみ 日付表記が分かりにくい 営業時間のタイムゾーンが不明 という状態では、海外ユーザーにとって使いやすいサイトとは言えません。 必要に応じて、 通貨 単位 電話番号 日付 時刻 住所 配送地域 対応エリア なども調整します。 翻訳だけでなく、実際に利用できる状態まで整えることがローカライズです。 メニュー・フォーム・メールまで言語を統一する 本文が英語でも、 メニューだけ日本語 フォームのエラーだけ日本語 ボタンが「お問い合わせ」 自動返信メールが日本語 では、途中でユーザー体験が途切れてしまいます。 確認したいのは、 ヘッダー フッター メニュー CTA フォーム エラーメッセージ サンクスページ 自動返信メール までです。 問い合わせ完了まで同じ言語で進められるかを確認しましょう。 AI・機械翻訳は人による確認を前提にする 現在はAIや機械翻訳を活用することで、多言語コンテンツを効率よく制作できます。 ただし、 「翻訳できること」と「そのまま公開できること」は別です。 特に、 商品名 専門用語 業界用語 契約条件 料金 法的表現 キャッチコピー などは、誤訳による影響が大きくなります。 AIや機械翻訳を下訳として利用し、その言語や業界に詳しい人が最終確認する運用が安全です。 重要なのは、AIを使ったかどうかではなく、そのページが対象ユーザーにとって正確で役立つ内容になっているかです。 海外ユーザーから問い合わせを増やすページ設計 多言語サイトを作っても、会社概要やサービス名だけを翻訳した状態では、問い合わせにつながりにくい場合があります。 最低限、次の情報を整えましょう。 何を提供している会社なのか ファーストビューで、 「誰に、何を提供している会社なのか」 が分かる状態にします。 海外ユーザーは自社について何も知らない状態で訪れる可能性が高いため、曖昧なキャッチコピーだけで終わらせないことが重要です。 どの地域に対応しているのか 海外対応では、対応エリアを明確にしましょう。 例えば、 日本国内のみ対応 海外発送可能 オンライン対応可能 特定の国・地域のみ対応 などです。 実績・取引事例 海外ユーザーにとって、自社はまだ「知らない企業」です。 そのため、 導入事例 取引実績 対応業界 写真 実績数 など、企業としての信頼を判断できる材料を用意します。 会社情報 最低限、 正式な会社名 所在地 代表者 設立 事業内容 などを分かりやすく掲載します。 問い合わせ方法 海外からでも利用しやすい問い合わせ方法を用意します。 例えば、 問い合わせフォーム メールアドレス オンラインミーティング 対応可能言語 などです。 日本国内向けの電話番号しか掲載されていないと、問い合わせのハードルが高くなる場合があります。 言語は自動切り替えより「ユーザーが選べる設計」にする ブラウザ言語やIPアドレスを利用して、 日本からアクセス→ 日本語 海外からアクセス→ 英語 のように自動で切り替えたくなることがあります。 しかし、自動転送だけに依存すると、ユーザーが希望する言語版を閲覧できなかったり、検索エンジンがすべてのページへアクセスしにくくなったりする可能性があります。 基本は、ユーザー自身が言語を選択できる状態にします。 例えばヘッダーに、 JP｜EN｜中文 といった言語切り替えリンクを設置します。 必要に応じて、 「英語版があります。切り替えますか？」 と案内する方法もあります。 勝手にページを移動させるのではなく、ユーザーへ選択肢を提供する設計が分かりやすいでしょう。 多言語サイトでよくある失敗7選 日本語サイトを丸ごと自動翻訳しただけ 対象ユーザーの文化・検索意図・必要情報まで考慮されていないと、文章は読めても問い合わせにはつながりにくくなります。 改善：対象ユーザーに必要な情報へローカライズする すべて同じURLで言語だけ切り替えている 検索エンジンが言語ごとのページを認識しにくくなります。 改善：言語ごとに個別URLを用意する hreflangを設定していない・設定が間違っている 言語ページ同士の関係が適切に伝わらない可能性があります。 改善：対応する言語ページを相互に設定する 外国語ページなのに一部だけ日本語 本文は英語なのに、フォームやメニュー、自動返信だけ日本語という状態です。 改善：問い合わせ完了まで言語を統一する 日本語のSEOキーワードをそのまま翻訳する 国や言語によって検索表現や検索意図は異なります。 改善：対象地域・言語ごとにキーワードを調査する アクセスすると勝手に言語が変わる ユーザーが希望する言語へ戻れないと使いにくくなります。 改善：分かりやすい言語切り替えリンクを設置する 公開後に日本語版しか更新されない 料金やサービス内容が言語ごとに異なる状態になると、ユーザーの不信感につながります。 改善：日本語更新→翻訳→確認→公開までの運用ルールを決める 公開後の運用｜日本語だけ更新される状態を防ぐ 多言語ホームページは、公開後の更新コストまで考えて設計する必要があります。 例えば日本語サイトでサービス内容を変更した場合、英語・中国語ページも必要に応じて更新しなければなりません。 更新内容を次の3種類に分けておくと運用しやすくなります。 全言語で早めに更新する情報 例えば、 料金 営業時間 サービス内容 会社住所 問い合わせ方法 などです。 内容が古いとユーザーへ直接影響する情報は、各言語で優先して更新します。 順次翻訳して更新する情報 例えば、 実績 お知らせ ブログ 採用情報 などです。 緊急性や重要度を判断しながら、順次更新します。 日本語のみで運用する情報 すべてのコンテンツを全言語へ翻訳する必要はありません。 対象となる海外ユーザーにとって必要性が低い情報であれば、日本語のみで運用する判断もできます。 重要なのは、 「すべて翻訳すること」ではなく「必要な情報を正しい状態で維持すること」 です。 多言語ホームページ制作チェックリスト 企画 対象となる国・地域を決めた 必要な言語を決めた 多言語化の目的を決めた 翻訳するページを決めた 問い合わせ対応できる言語を確認した URL・SEO 言語ごとに異なるURLを用意した URL構造を統一した hreflangを設定した 各言語版から相互に参照できている 必要に応じてx-defaultを設定した 各言語で検索キーワードを調査した title・descriptionも各言語向けに調整した コンテンツ 直訳ではなく対象ユーザー向けに編集した 本文とナビゲーションの言語を統一した 料金・単位・日時を確認した 会社情報を掲載した 実績・事例を掲載した FAQを用意した プライバシーポリシーなど必要ページを確認した 問い合わせ フォームを対象言語に対応させた エラーメッセージも翻訳した サンクスページを翻訳した 自動返信メールを翻訳した 海外から実際に問い合わせできる設計になっている 運用 翻訳担当者を決めた 日本語更新時の翻訳フローを決めた 情報の更新漏れを定期的に確認する Search Consoleなどで各言語ページの流入を確認する まとめ：翻訳ではなく「各言語のユーザー向けサイト」を作る 多言語ホームページを成功させるうえで重要なのは、 「日本語サイトを別の言葉に置き換える」という考え方から離れること です。 必要なのは、 対象となる国・言語を明確にする 言語ごとに適切なURLを用意する hreflangでページ同士の関係を伝える 検索キーワードも言語ごとに考える 対象ユーザーに伝わる内容へローカライズする 問い合わせまで一つの言語で完結させる 公開後の翻訳・更新体制まで決める という設計です。 目指すべきなのは、 「外国語で表示できるサイト」ではなく、「海外ユーザーが理解し、比較し、安心して問い合わせできるサイト」 です。 翻訳だけをゴールにせず、SEO・コンテンツ・問い合わせ導線・公開後の運用まで含めて設計しましょう。 多言語・海外向けホームページ制作のご相談ならRefuへ Refuでは、海外向け・外国人向けホームページについて、サイト構成・言語別URL・SEO設計・コンテンツ設計・問い合わせ導線まで含めてご提案しています。 「英語ページを作りたいけれど、どこまで翻訳すべきか分からない」「すでに多言語化しているが、海外から問い合わせが来ない」「更新のたびに各言語の情報がずれてしまう」 といった段階からでも、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 原稿が書けないを解決！伝わる文章構成テンプレと作り方 SEOの前に整える「サイト構造」｜カテゴリ設計・URL・内部リンクの基本 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 成果が出る「実績・事例」ページの作り方｜信頼を獲得して問い合わせを増やす 会社概要ページの書き方｜信用される情報設計とNG例
2026/08/25
リニューアル・運用ノウハウ構造化データの基本｜検索エンジンにページ内容を正しく伝える実装方法
構造化データとは？ページの意味を検索エンジンに伝える仕組み 構造化データとは、Webページに掲載されている情報を、検索エンジンが理解しやすい形式で記述するためのデータです。 例えば、ホームページに次のような情報が掲載されていたとします。 会社名 所在地 代表者 ロゴ 電話番号 人間がページを見れば、「これは会社情報だ」と理解できます。 一方、検索エンジンに対して、 「これは会社名です」「これは所在地です」「これは会社のロゴです」 と、情報の意味まで明確に伝えるために使われるのが構造化データです。 Googleも、構造化データをページに関する情報を標準化して提供するデータ形式として案内しており、ページの内容をより正確に理解するために利用しています。 つまり構造化データは、簡単にいえば、 検索エンジンに渡す「ページの説明書」 のようなものです。 構造化データを入れるとSEO順位は上がる？ 構造化データについてよくある誤解が、 「構造化データを設定すると検索順位が上がる」 という考え方です。 構造化データは、設定するだけで検索順位を直接上げるための仕組みではありません。 Googleが構造化データを利用する大きな目的の一つは、ページの内容を理解し、対応している場合にはリッチリザルトなどの検索機能へ利用することです。 流れを整理すると、次のようになります。 構造化データを実装する Googleがページの内容を理解しやすくなる 条件を満たせば、検索結果の表示方法が拡張される可能性がある 検索ユーザーにページ内容が伝わりやすくなる 構造化データは、順位を直接上げるための裏技ではなく、検索エンジンとの情報伝達を正確にするSEOの土台として考えましょう。 構造化データとリッチリザルトの関係 構造化データを理解するときに、一緒に覚えておきたいのがリッチリザルトです。 通常の検索結果よりも追加情報を含んだ表示を、Googleではリッチリザルトと呼びます。 構造化データを正しく実装することで、対応する検索機能へ表示される資格を得られる場合があります。 ただし、ここには重要な注意点があります。 構造化データを正しく実装しても、リッチリザルトとして表示される保証はありません。 Googleも、リッチリザルトテストで正しくマークアップされていても、実際の検索結果で拡張表示されることを保証していません。 検索内容や地域、端末など複数の要因によって、通常の検索結果が表示される場合もあります。 そのため、 「構造化データを入れたのに検索結果が変わらない＝失敗」 とは限りません。 企業サイトで検討したい代表的な構造化データ Googleがサポートする構造化データには多くの種類があります。 企業サイトですべてを設定する必要はありません。 重要なのは、そのページに実際に存在する内容に合った構造化データだけを使うことです。 企業サイトでは、Organization、Breadcrumb、Article、LocalBusiness、JobPostingなどが代表的です。 Organization｜会社・組織情報を伝える 企業サイトでまず検討したいのがOrganizationです。 会社や組織に関する情報をGoogleへ伝えるための構造化データです。 例えば、 会社名 URL ロゴ 所在地 電話番号 組織に関する情報 などを、サイトや組織の実態に合わせて記述します。 Googleは、Organization構造化データを追加することで、組織の情報をGoogleが理解しやすくなり、他の組織との識別にも役立つと説明しています。 企業サイトでは、サイト全体の運営主体を正確に伝えるという意味でも検討したい構造化データです。 Breadcrumb｜ページの階層構造を伝える Breadcrumbは、いわゆるパンくずリストを検索エンジンへ伝える構造化データです。 例えば、 トップ ＞ サービス ＞ ホームページ制作 という階層です。 BreadcrumbListを利用することで、そのページがサイト内のどこに位置しているのかをGoogleへ伝えられます。 Googleも、パンくずリストはページのサイト階層上の位置を示し、ユーザーがサイト構造を理解・移動するうえで役立つと説明しています。 ページ数の多い企業サイト、オウンドメディア、サービスサイトなどでは特に相性のよい構造化データです。 Article｜ブログ・コラムの記事情報を伝える オウンドメディアやブログを運用している場合は、Article系の構造化データを検討できます。 例えば、 記事タイトル 公開日 更新日 著者 画像 など、記事に関する情報を検索エンジンへ伝えます。 特に企業のオウンドメディアでは、 誰が書いたのかいつ公開・更新されたのか といった情報をページ上でも明確にし、構造化データの内容と一致させることが重要です。 LocalBusiness｜店舗・地域ビジネスの情報を伝える 飲食店、美容室、クリニック、工務店など、実店舗や地域との結びつきが強い事業では、LocalBusiness系の構造化データを検討できます。 業種やページ内容に応じて、 店舗名 所在地 営業時間 電話番号 業種 などを記述します。 ただし、構造化データを設定するだけでローカルSEOが強くなるわけではありません。 Googleビジネスプロフィール、サイト内の会社・店舗情報、実際の営業時間など、Web上の情報を正確かつ一貫させることが重要です。 JobPosting｜求人情報を伝える 採用サイトや求人ページを運営している企業では、JobPostingを検討できます。 求人内容に応じて、 職種 仕事内容 勤務地 雇用形態 給与 求人掲載日 などを記述します。 重要なのは、構造化データだけに情報を書かないことです。 ユーザーがページ上で確認できる求人情報と、構造化データの内容を一致させる必要があります。 Googleも、ユーザーから見えない情報や、ページの主な内容を正しく表していない情報を構造化データとしてマークアップしないよう案内しています。 構造化データの形式｜Googleが推奨するJSON-LDとは？ 構造化データには、主に次の形式があります。 JSON-LD Microdata RDFa Googleはいずれもサポートしていますが、一般的にはJSON-LDが推奨されています。 HTMLの表示部分と分けて管理しやすく、実装や保守もしやすいことが特徴です。 JSON-LDは、例えばHTML内に次のような形で記述します。 <script type="application/ld+json"> 企業サイトを運用する担当者が、コード自体をすべて覚える必要はありません。 重要なのは、 「どのページに、どの情報を構造化データとして設定しているのか」 を管理できる状態にしておくことです。 構造化データの基本的な実装手順 ページに合った構造化データを選ぶ 最初に、 「SEOに良さそうだから、とりあえずschemaを入れる」 という考え方は避けましょう。 Googleがサポートしている構造化データを確認し、ページの内容に合うものがある場合に実装するのが基本です。 例えば、 トップ・企業情報 → Organization 記事 → Article 求人詳細 → JobPosting サイト階層 → BreadcrumbList といった考え方です。 ページに実際に掲載されている情報をマークアップする 構造化データの内容と、ユーザーが見ているページの内容は一致させます。 例えば、ページ上に「創業30年」と書かれていないにもかかわらず、構造化データだけで30年の実績があるように記述する、といった使い方は避けます。 Googleは、ユーザーから見えないコンテンツや、ページ内容を正しく表していない情報をマークアップしないことを品質ガイドラインで求めています。 構造化データは、 検索エンジンだけに見せる「裏側の広告スペース」ではありません。 必須・推奨プロパティを設定する 構造化データの種類ごとに、 必須プロパティ 推奨プロパティ があります。 対象の検索機能を利用できる状態にするためには、必要なプロパティを正しく設定します。 推奨プロパティについても、実際に確認できる情報であれば追加を検討します。 ただし、 項目数を増やすことより、正確な情報を設定すること の方が重要です。 分からない情報や、実態と異なる情報を無理に設定する必要はありません。 リッチリザルトテストで確認する 実装後は、Googleのリッチリザルトテストで確認します。 主に、 構造化データが認識されているか 重大なエラーがないか 対象となるリッチリザルトの種類 などを確認できます。 実装して終わりではなく、 実装 → テスト → 修正 までを1セットにしましょう。 公開後はSearch Consoleで監視する 公開後はSearch Consoleも確認します。 基本的な流れは、 構造化データを実装する リッチリザルトテストで確認する ページを公開する URL検査ツールでGoogleからの見え方を確認する Search Consoleで継続的に監視する となります。 サイトリニューアルやCMS変更によって、公開前には正常だった構造化データが崩れるケースもあります。 そのため、公開後の確認まで含めて運用することが重要です。 構造化データでやってはいけないこと ページに存在しない情報を記述する ユーザーに見えていない情報を、検索エンジンだけに伝える目的で構造化データへ追加するのは避けましょう。 構造化データは、ページに存在する情報の意味を説明するものです。 偽のレビュー・評価をマークアップする 検索結果で星評価を表示させたいからといって、 実際には存在しないレビュー 架空の評価 ページ内容と関係のない評価 などを設定してはいけません。 ユーザーを誤解させる構造化データは、Googleのガイドラインに抵触する可能性があります。 内容によっては、リッチリザルトの対象外や手動による対策につながる可能性もあるため注意が必要です。 関係のない構造化データを設定する 構造化データは、多ければ多いほどよいわけではありません。 例えば、 一般的な企業コラムをRecipeとしてマークアップする 会社紹介ページを商品ページとしてマークアップする など、実際のページ内容と異なる設定は避けます。 数を増やすより、適切な種類を正確に実装する。 これが基本です。 「入れれば必ずリッチリザルトになる」と考える 構造化データを正しく設定しても、検索結果の表示方法はGoogleが判断します。 そのため、 「星が表示されないから構造化データを増やそう」「検索結果を目立たせるためだけにschemaを追加しよう」 という発想ではなく、 ページ内容を検索エンジンへ正確に説明する ことを目的にしましょう。 WordPressサイトではどう実装する？ WordPressの場合は、主に次のような実装方法があります。 テーマ側で実装する SEO系プラグインで出力する 独自プラグインで実装する テンプレートにJSON-LDを組み込む WordPressなどのCMSでは、管理画面やプラグインから構造化データを出力できる場合もあります。 ただし、注意したいのが複数箇所からの出力です。 例えば、 テーマがOrganizationを出力＋SEOプラグインもOrganizationを出力＋独自実装でもOrganizationを出力 という状態になることがあります。 複数の構造化データが存在すること自体が直ちに問題になるとは限りませんが、内容が矛盾すると管理しづらくなります。 WordPressサイトでは、 「現在、どのテーマ・プラグイン・コードから構造化データが出力されているのか」 を一度確認しておくことをおすすめします。 リニューアル時に構造化データを見直すべき理由 構造化データは、ホームページリニューアルによって崩れやすい項目の一つです。 例えば、 会社情報が変更された URL構造が変わった パンくずの階層が変わった ブログの著者情報が変わった CMSやテーマを変更した 採用ページの構造が変わった といった場合、旧サイトの設定をそのまま流用できない可能性があります。 特にWordPressでは、テーマ変更によって構造化データの出力方法そのものが変わる場合もあります。 リニューアル公開前には、 Organization Breadcrumb Article 求人・商品などサイト固有の構造化データ を確認し、現在のサイト内容と一致しているかチェックしましょう。 構造化データチェックリスト 実装前 ページ内容に合った構造化データを選んでいる Googleが現在サポートしている種類を確認している 構造化データの目的を「順位アップ」と誤解していない ページ上の情報と構造化データの内容が一致している 実装時 JSON-LDなど適切な形式を使用している 必要なプロパティを設定している 推奨プロパティも正確な範囲で設定している 偽のレビューや実績を入れていない ユーザーから見えない情報だけをマークアップしていない 同じ情報が複数箇所から矛盾して出力されていない 公開前 リッチリザルトテストで確認した 重大なエラーを修正した 対象ページがrobots.txtやnoindexによって意図せず制限されていない 構造化データ内のURLが本番URLになっている 公開後 Search Consoleで状況を確認している URL検査ツールでGoogleからの見え方を確認している CMS・テーマ更新後に再確認している 会社情報・営業時間・求人などを変更した際、構造化データも更新している まとめ：構造化データは「検索エンジンへの説明書」として考える 構造化データは、検索順位を簡単に上げるためのSEOテクニックではありません。 本来の役割は、 「このページには何が書かれているのか」 を、検索エンジンへ正確に伝えることです。 企業サイトであれば、 Organization＝会社・組織情報 Breadcrumb＝ページ階層 Article＝記事情報 LocalBusiness＝店舗・地域事業情報 JobPosting＝求人情報 など、ページの目的に合わせて適切な構造化データを検討します。 Googleがサポートする検索機能や実装要件は変更されることもあるため、実装時には最新のGoogle検索セントラルを確認することも重要です。 そして何より、 ユーザーに見えている情報と一致させる正確な情報だけを記述するページに合った種類だけを使う実装後にテスト・監視する ことが重要です。 構造化データは「検索結果を派手にするためのコード」ではなく、自社サイトの情報を検索エンジンへ正しく届けるための情報設計として活用しましょう。 構造化データ・SEO設定の見直しならRefuへ Refuでは、サイトリニューアル時のSEO設計だけでなく、Organization・Breadcrumb・Articleなどの構造化データ、title・description、内部リンク、Search Consoleまで含めた技術面のチェックにも対応しています。 「今のサイトに構造化データが入っているか分からない」「WordPressをリニューアルするのでSEO設定も見直したい」「検索エンジンにサイト情報を正しく伝えられているか確認したい」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら Googleサーチコンソールの基本操作と改善への活かし方 E-E-A-Tを強化するサイト改修ポイント｜信頼を積み上げる情報設計 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴 robots.txtとnoindexの違い｜検索に表示されない原因と正しい使い分け サイトマップ作成の基本｜リニューアルで迷わないページ設計の決め方
2026/08/20
集客・マーケティング戦略検索順位が下がったときの原因分析｜サーチコンソールで切り分ける7ステップ
検索順位が下がったら、すぐリライトするのはNG 「先月まで3位だった記事が8位になった」 「SEOからのアクセスが急に減った」 「Googleのアップデートで順位が落ちた気がする」 こうした状況になると、すぐにタイトルを変更したり、文章を大量に追加したりしたくなります。 しかし、原因を特定せずにリライトするのはおすすめできません。 検索流入が減る原因には、次のようなものがあります。 掲載順位の低下 検索需要そのものの減少 CTRの低下 インデックスの問題 サイトの技術的な問題 Googleのアルゴリズム更新 季節性 検索結果の見え方の変化 つまり、順位低下が見つかったとしても、必ずしも「記事の内容が悪くなった」とは限りません。 大切なのは、「順位が落ちたから直す」のではなく、「なぜ成果が落ちたのかを特定してから直す」ことです。 まず結論：順位低下は「何が減ったか」を分解してから原因を探す 最初に確認したいのは、順位だけではありません。 Google Search Consoleで、次の4つを確認します。 クリック数 表示回数（インプレッション） CTR 平均掲載順位 そして、「どの数字が変化しているのか」を見ます。 例えば、次のように考えます。 表示回数↓＋クリック数↓→ 順位低下・検索需要低下・インデックス問題などを疑う 表示回数はほぼ同じ＋クリック数↓→ CTR低下・タイトル・スニペット・検索結果の変化を疑う 順位↓＋表示回数↓→ 掲載順位低下による影響が大きい可能性がある 特定ページだけ↓→ そのページ固有の問題を疑う サイト全体↓→ 技術的な問題・アルゴリズム更新・サイト全体の品質などを確認する このように、数字の組み合わせから原因候補を絞り込むことが最初のステップです。 STEP1：期間を比較して「本当に下がったのか」を確認する 直近だけで判断せず、長期間の推移を見る まずSearch Consoleの「検索結果」パフォーマンスを開き、長めの期間で推移を確認します。 短期間だけを見ると、一時的な変動や季節性を順位低下と勘違いする可能性があります。 例えば、 「7月から問い合わせが減った」 という場合でも、前年の7月にも同じように検索需要が減っていれば、SEOの問題ではなく季節要因かもしれません。 可能であれば、過去16か月程度の推移まで確認し、通常の変動なのか異常な下落なのかを判断しましょう。 前期間・前年同期と比較する 次に、Search Consoleの期間比較を使います。 おすすめは、次の比較です。 直近3か月 vs その前の3か月 直近3か月 vs 前年同期 前期間との比較だけでは、季節性を判断できないことがあります。 前年同期も確認することで、毎年同じ時期に起きる需要変化なのか、今回だけ発生している問題なのかを切り分けやすくなります。 数日単位の順位変動に反応しすぎない 検索順位は常に変動しています。 特に、 2位 → 4位 程度の小幅な変化であれば、すぐに全面リライトする必要がない場合もあります。 「昨日2位だったのに今日は5位だから記事を全部書き直す」 という対応を繰り返すと、これまで評価されていた内容まで変更してしまう可能性があります。 数日間の変動ではなく、一定期間の傾向を見ることが重要です。 STEP2：クリック・表示回数・CTR・平均掲載順位を切り分ける クリック数と表示回数の両方が減っている場合 両方が減っている場合は、次のような原因が考えられます。 検索順位が落ちた 検索需要が減った ページがインデックスされなくなった 技術的な問題が発生した アルゴリズム更新の影響を受けた この段階では、コンテンツだけが原因だと決めつけないことが重要です。 表示回数は同じでクリックだけ減っている場合 この場合、検索結果には引き続き表示されています。 つまり、問題は「見つからなくなった」ことよりも、 「表示されているのに選ばれなくなった」 可能性があります。 確認したいのは、次の項目です。 titleタグ 検索結果に表示されるスニペット 競合サイトのタイトル リッチリザルト 現在の検索意図とのズレ 例えば競合サイトのタイトルが以前より具体的になり、自社ページの内容が検索結果上で魅力的に見えなくなっている可能性もあります。 平均掲載順位だけを見ると判断を誤ることがある Search Consoleの「平均掲載順位」は便利な指標ですが、絶対的な順位として見すぎないようにしましょう。 例えば平均掲載順位が少し下がっていても、 表示回数が増えている クリック数も増えている 問い合わせも増えている のであれば、慌てて修正する必要はありません。 SEOの目的は順位そのものではありません。 順位は成果につなげるための途中指標として確認することが重要です。 STEP3：「サイト全体」か「一部ページ」かを特定する ページ別にクリック減少幅を確認する Search Consoleの「ページ」を開き、比較期間でどのURLのクリック数が減っているか確認します。 ここで確認したいのは、 サイト全体で下がっているのか 特定カテゴリだけなのか 数ページだけなのか 1つの重要ページだけなのか という点です。 例えば、 サイト全体では−5％だが、1記事だけ−70％ という場合、サイト全体を大きく変更する必要はありません。 まず、その1ページを詳しく分析します。 クエリ別に落ちたキーワードを特定する 対象ページを絞ったら、「クエリ」を確認します。 例えば以前、 ホームページ制作 費用 ホームページ制作 相場 HP制作 料金 など複数の検索から流入していたページで、「相場」に関するクエリだけが大きく減っている場合があります。 この場合、「相場を知りたい」という検索意図に対して競合との差が生まれた可能性があります。 逆に、ほぼすべてのクエリが同時に落ちている場合は、ページ全体の評価や技術面も確認します。 デバイス・国・検索タイプでも切り分ける 必要に応じて、さらに条件を分けます。 PC モバイル 国 ウェブ検索 画像検索 動画検索 例えばスマートフォンだけ大きく流入が落ちているのであれば、スマホ表示やページ体験に問題がないか確認するきっかけになります。 STEP4：技術的な問題・インデックス状況を確認する 順位が大きく落ちた場合、コンテンツをリライトする前に確認したいのが技術面です。 ページのインデックス登録状況を確認する Search Consoleの「ページのインデックス登録」を確認します。 特に注意したいのは、 サーバーエラー robots.txtによるブロック 404エラー noindexの誤設定 リダイレクトエラー などです。 サイトリニューアル後やCMS変更後に急落した場合は、特に優先して確認しましょう。 URL検査で重要ページを確認する 一部ページだけ流入が落ちている場合は、「URL検査」を使います。 主に次を確認します。 Googleにインデックスされているか Googleが認識している正規URLはどれか クロール可能な状態か インデックス登録可能な状態か 検索順位以前に、Googleがページを正しく取得・認識できていなければ、コンテンツを書き直しても改善しません。 noindex・robots.txt・404・サーバー障害を確認する 制作現場で特に起こりやすいのが、次のような事故です。 テスト環境用のnoindexが本番にも残った robots.txtを変更した URL変更後に301リダイレクトを設定していない 重要ページが404になった サーバー障害でGooglebotがアクセスできない 順位が急落した日とサイト変更日が近い場合は、技術面を最優先で確認しましょう。 セキュリティ問題・手動による対策を確認する Search Consoleでは、 セキュリティの問題 手動による対策 も確認できます。 マルウェアやフィッシングなどの問題が発生している場合や、Googleのスパムポリシーに関する手動対策を受けている場合は、検索流入へ大きな影響が出る可能性があります。 大幅な下落が発生した際は、念のため確認しておきましょう。 STEP5：Googleアップデートとの時期を照合する Google Search Status Dashboardを確認する Googleは検索ランキングシステムについて、継続的に変更・更新を行っています。 順位が大きく変化した場合は、 順位低下日とGoogleのアップデート期間が重なっていないか を確認します。 ただし、 「同じ時期だからアップデートが原因」 と決めつけないよう注意しましょう。 サイト変更や検索需要の変化など、別の要因も並行して確認する必要があります。 コアアップデート中に慌てて大幅変更しない コアアップデートの展開中は、順位が大きく変動することがあります。 その段階で、 タイトルを変更する 全面リライトする URLを変更する 記事を削除する といった対応をすると、元々の変動なのか変更の影響なのか判断しにくくなります。 アップデートとの関連を分析する場合は、ロールアウト完了を確認し、その後一定期間のデータを比較して判断しましょう。 小幅下落と大幅下落で対応を変える 小幅な低下 例： 2位 → 4位 この場合は、 大規模な変更を避ける 検索意図の変化を確認する 競合ページとの差を確認する 必要な部分だけ改善する という対応が基本です。 大幅な低下 例： 5位 → 30位 この場合は、 ページ単体だけでなくサイト全体も確認する コンテンツ品質を確認する 信頼性や専門性を確認する ユーザー第一の内容になっているか確認する 技術・内部構造も調査する など、調査範囲を広げます。 STEP6：検索需要・季節性・検索結果の変化を確認する Googleトレンドで市場全体の検索需要を見る 順位がそれほど変わっていないのにクリック数が減っている場合は、検索需要そのものが減っている可能性があります。 特に、 季節商品 採用 引越し 旅行 イベント 補助金 などは、時期による検索需要の変化が大きいテーマです。 Googleトレンドなどを活用し、自社だけの減少なのか、市場全体で検索数が減っているのかを確認しましょう。 検索意図そのものが変わっていないか確認する 同じキーワードでも、検索結果に表示されるページの種類が変化することがあります。 例えば以前、 「○○ おすすめ」 という検索で解説記事が多く表示されていたものが、現在は、 比較サイト 商品一覧 動画 地図 ECサイト 中心になっているケースです。 この場合、Googleが判断する検索意図そのものが変化した可能性があります。 自社ページだけを見るのではなく、実際の検索結果も確認しましょう。 CTR低下ならタイトル・スニペット・検索結果を確認する 順位が大きく変化していないのにクリック数だけ減った場合は、次を確認します。 タイトルが競合より分かりにくくないか 検索意図とタイトルがズレていないか 競合の訴求が強くなっていないか 検索結果の構成が変わっていないか 例えば、 ホームページ制作会社の選び方 より、 ホームページ制作会社の選び方｜失敗を防ぐ10項目と見積り比較ポイント の方が、ページの内容を具体的に想像しやすい場合があります。 ただし、クリック率だけを目的とした煽りタイトルは避け、ページ内容と一致した表現にしましょう。 STEP7：コンテンツと競合を比較して「改善すべき理由」を特定する ここまで確認して、 技術的な問題ではない 検索需要も大きく変わっていない アップデートだけでは説明できない のであれば、コンテンツそのものを分析します。 検索意図への回答が古くなっていないか まず確認したいのは情報の鮮度です。 例えば、 GoogleやSNSの古い仕様 数年前の料金相場 終了した制度 現在推奨されていないSEO手法 古いツール画面 などが残っていると、ユーザーにとっての価値が低下します。 大切なのは更新日そのものではなく、現在のユーザーにとって内容が正確で役立つ状態かです。 競合にあって自社にない情報を確認する 現在の上位ページを確認し、 自社にない論点 比較表 具体例 料金情報 FAQ 事例 独自データ 専門家情報 などを整理します。 ただし、競合サイトの見出しをそのままコピーして追加するだけでは意味がありません。 重要なのは、「その情報がなぜ検索ユーザーに必要なのか」を考えることです。 一次情報・事例・専門性を追加する コンテンツを改善する際、差別化につながりやすいのが自社にしか出せない情報です。 例えば、 実際の相談で多い質問 顧客事例 Before／After 自社独自の判断基準 制作現場で起きた失敗例 独自アンケート 実績データ 担当者・専門家の見解 などです。 競合サイト10記事をまとめた一般論より、自社が実際に経験した具体的な1事例の方が、ユーザーにとって価値の高い情報になる場合があります。 リライト・統合・維持を判断する 分析が終わったら、ページを次の4つに分類します。 維持する 順位変動が小さく、クリック数やCVにも問題がないページです。 無理に変更せず、経過を確認します。 部分リライトする 一部の検索意図や情報だけが弱くなっているページです。 不足部分だけを追加・更新します。 大幅リライトする 順位・流入ともに大きく落ち、現在の検索意図への回答が不足しているページです。 構成から見直すことを検討します。 統合する 似た検索意図の記事が複数存在し、評価やユーザー導線が分散している場合です。 強い1ページへ情報をまとめることを検討します。 「順位が落ちた＝全文を書き直す」ではなく、原因に必要な範囲だけ変更することが重要です。 検索順位が落ちたときにやってはいけない5つのこと 原因分析前に全面リライトする 原因が分からない状態で大きく変更すると、何が良かったのか、何が悪かったのか分からなくなります。 まずSearch Consoleで数字を比較しましょう。 数日間の変動だけで判断する 検索順位は日常的に変動します。 短期間だけで判断せず、一定期間の傾向を確認します。 順位だけを追いかける 順位が下がっても、クリック数やCVが増えているのであれば、必ずしも悪化とは言えません。 最終的にはサイトの成果を確認することが重要です。 競合の文章や見出しをそのまま追加する 競合サイトと同じ情報を追加するだけでは差別化できません。 自社の経験・事例・判断基準など、一次情報を加えましょう。 順位低下ページをすぐ削除する 過去に獲得した検索評価や被リンク、内部リンク上の役割を失う可能性があります。 削除・統合する場合は、 検索流入 被リンク CVへの貢献 検索意図 統合先 まで確認したうえで判断しましょう。 このまま使える順位低下の原因分析チェックリスト STEP1｜期間 過去16か月程度の推移を確認した 前期間と比較した 前年同期とも比較した 数日だけの変動ではないことを確認した STEP2｜指標 クリック数を確認した 表示回数を確認した CTRを確認した 平均掲載順位を確認した どの指標が変化したか整理した STEP3｜影響範囲 サイト全体か一部ページか確認した 最もクリックが減ったページを特定した 減少したクエリを特定した デバイス別に確認した 必要に応じて検索タイプも確認した STEP4｜技術面 ページのインデックス登録状況を確認した URL検査を行った noindexを確認した robots.txtを確認した 404・リダイレクトを確認した サーバー障害の有無を確認した セキュリティ問題を確認した 手動による対策を確認した STEP5｜Googleアップデート Search Status Dashboardを確認した 順位低下日とアップデート期間を比較した ロールアウト中に慌てて変更していない 小幅低下か大幅低下かを分類した STEP6｜外部要因 Googleトレンドで検索需要を確認した 前年同期の季節性を確認した 実際の検索結果を確認した CTR低下の場合はタイトル・スニペットを確認した STEP7｜コンテンツ 情報が古くなっていないか確認した 現在の検索意図と内容が一致している 競合との差を確認した 自社独自の事例・経験が含まれている 不足している一次情報を洗い出した 維持／部分リライト／大幅リライト／統合を判断した まとめ：順位を戻すことではなく「検索ユーザーに選ばれる状態」を取り戻す 検索順位が下がったとき、最初にやるべきことはリライトではありません。 まずは、 期間を比較する↓クリック・表示回数・CTR・順位を分解する↓影響範囲を特定する↓技術・インデックス状況を確認する↓Googleアップデートとの関係を確認する↓検索需要・検索結果の変化を確認する↓必要なコンテンツ改善を行う という順番で原因を絞り込みます。 SEO改善の目的は、「以前の順位へ戻すこと」だけではありません。 検索ユーザーのニーズや競合環境が変わっているのであれば、それに合わせてページも改善する必要があります。 原因を数字で特定し、必要な部分だけを改善し、公開後の変化を再びSearch Consoleで確認する。 このサイクルを継続することが、長期的に検索流入を伸ばしていくための基本です。 検索順位・SEO流入の低下でお悩みならRefuにご相談ください Refuでは、Search Console・GA4を活用して検索順位や流入が下がったページを分析し、「なぜ下がったのか」「どの記事から改善すべきか」「リライト・統合・維持のどれが適切か」まで整理したSEO改善をご提案しています。 「以前は上位だった記事が落ちてきた」「記事数は増えているのにSEO流入が伸びない」「どの記事をリライトすべきか判断できない」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 成果を出す企業が必ずやっているアクセス解析の活用法 成功企業のSEO改善ステップ｜順位UPまでの実例を紹介 中小企業でも再現できる“成果の出るSEO改善プロセス” ホームページの集客が伸びない原因10選｜まず見直すべき優先順位 SEOに強いサイト構造とは？カテゴリ設計と内部リンク最適化の基本 GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順 検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法 E-E-A-Tを高めるコンテンツ設計｜信頼されるホームページの作り方
2026/08/18
リニューアル・運用ノウハウrobots.txtとnoindexの違い｜検索に表示されない原因と正しい使い分け
robots.txtとnoindexの違い｜まず結論から理解しよう robots.txtとnoindexは、どちらも検索エンジンに関係する設定ですが、役割はまったく異なります。 最初に結論を整理すると、 robots.txt→ 検索エンジンのクローラーに「このURLをクロールしないで」と伝える noindex→ 検索エンジンに「このページを検索結果へ掲載しないで」と伝える という違いがあります。 Googleは、robots.txtについてクローラーがどのページやファイルをリクエストできるかを制御する仕組みとして案内しています。一方、noindexはページをGoogleのインデックスから除外し、検索結果に表示されないようにするためのルールです。 この違いを理解しないまま設定すると、 検索から消したかったのに残っている Googleに見てほしいページをブロックしてしまった noindexを設定したのに反映されない といったSEOトラブルにつながります。 そもそも「クロール」と「インデックス」は何が違う？ robots.txtとnoindexを理解するには、まずクロールとインデックスの違いを知っておく必要があります。 簡単に整理すると、 クロール→ Googlebotなどの検索エンジンがページを訪れて内容を取得すること インデックス→ 取得したページの内容をGoogleが解析し、検索結果に表示できる状態として登録すること です。 イメージすると、 Googleがページを見に来る＝クロール↓ページの内容を理解する↓検索データベースへ登録する＝インデックス↓検索結果に表示される可能性が生まれる という流れです。 robots.txtは最初の「クロール」に関係し、noindexは主に「インデックス」に関係します。 この違いが、今回の記事で最も重要なポイントです。 robots.txtとは？検索エンジンのクロールを制御するファイル robots.txtでできること robots.txtは、検索エンジンのクローラーに対して、サイト内のどのURLへアクセスしてよいか、またはアクセスしてほしくないかを伝えるためのテキストファイルです。 通常は、 https://example.com/robots.txt のように、サイトのルート直下へ設置します。 Googleもrobots.txtは対象ホストのルートに配置する必要があり、サブディレクトリ内に置いても有効にならないと案内しています。 例えば、 管理上クロールさせる必要がないURL サイト内検索結果など大量にURLが生成される領域 重要性の低い類似ページ などについて、クロールを制御する用途があります。 Googleはrobots.txtを、クロールトラフィックの管理や、重要性の低いページ・類似ページへのクロールを防ぐ用途として案内しています。 robots.txtでできないこと ここが非常に重要です。 robots.txtは「Google検索に表示しないための設定」ではありません。 Googleは、robots.txtでクロールを禁止したページであっても、他のページからそのURLがリンクされている場合などには、ページ内容をクロールせずURLだけをインデックスする可能性があると説明しています。 つまり、 robots.txtでブロック＝検索結果から必ず消える ではありません。 「検索結果に表示したくない」という目的なら、原則としてnoindexなど別の方法を検討します。 基本的な記述例 例えば、すべてのクローラーに対して/private-directory/以下へのクロールを許可しない場合、考え方としては次のようになります。 User-agent: * Disallow: /private-directory/ 一方、すべてのページをクロール可能にする場合は、特別な制限を設けない構成にします。 robots.txtは書き方を間違えると、サイト全体をクロールできなくしてしまう可能性があります。 そのため、「何となくSEO対策として設定する」ものではありません。 noindexとは？検索結果への掲載を防ぐための設定 noindexとは、検索エンジンに対して、 「このページを検索結果に表示しないでください」 と伝えるためのルールです。 Googlebotがページをクロールし、noindexを確認すると、そのページはGoogle検索結果から除外されます。 Googleは、他サイトからリンクされている場合でも、Googlebotがnoindexを検出すればGoogle検索結果から除外すると説明しています。 HTMLページでnoindexを設定する方法 代表的なのは、HTMLのrobots metaタグを使う方法です。 例えば、 <meta name="robots" content="noindex"> という設定です。 この設定によって、対応する検索エンジンへ「インデックスしない」という指示を出します。 WordPressなどのCMSでは、HTMLを直接編集しなくても、管理画面やSEO関連機能から設定できる場合があります。 PDFなどHTML以外ではX-Robots-Tagを使える PDFなど、HTMLの<head>内へmetaタグを設置できないファイルについては、HTTPレスポンスヘッダーのX-Robots-Tagを使ってnoindexを指定できます。 Googleも、PDF・動画・画像などHTML以外のリソースについてX-Robots-Tagを利用できると案内しています。 例えば、 営業資料PDF 過去資料 検索から見つけてもらう必要のないファイル などで検討するケースがあります。 noindexを設定してもすぐ消えるとは限らない noindexは設定した瞬間にGoogle検索からページを消すスイッチではありません。 Googlebotがそのページを再度クロールし、 「noindexが設定されている」 と認識する必要があります。 Googleは、ページの重要度などによって再クロールまで時間がかかる場合があり、必要に応じてSearch ConsoleのURL検査ツールから再クロールをリクエストできると説明しています。 そのため、 「昨日noindexを入れたのに、今日も検索結果に出ている」 からといって、必ず設定失敗とは限りません。 robots.txtとnoindexの決定的な違いを比較 項目robots.txtnoindex主な目的クロール制御インデックス制御Googlebotのアクセスブロックできるアクセスさせる必要がある検索結果から除外保証されないGooglebotが認識すれば除外主な設定場所ドメイン直下のrobots.txtmetaタグ／HTTPヘッダーページ単位の検索除外不向き適している機密情報の保護不向き不向き 特に覚えておきたいのは、 検索結果に表示させたくない＝noindexクロールそのものを制限したい＝robots.txt という基本です。 絶対に注意したい「robots.txt＋noindex」の組み合わせ 初心者の方が最も間違いやすいのが、この設定です。 「検索に出したくないから、robots.txtでブロックして、さらにnoindexも付けておこう」 一見すると二重に対策できて安全そうですが、逆効果になる可能性があります。 理由は、robots.txtでクロールをブロックすると、Googlebotがページへアクセスできなくなるからです。 Googlebotがページを開けなければ、ページ内にあるnoindexも確認できません。 Googleは明確に、noindexを機能させるにはrobots.txtでページをブロックせず、クローラーがアクセスできる状態にする必要があると案内しています。 つまり、 robots.txt：入るなnoindex：中に入ったら「検索に載せるな」と書いてある という状態になります。 入れないので、中の指示を読めません。 検索結果から除外したいページなら、 クロールを許可する↓Googlebotにnoindexを読ませる という流れが基本です。 目的別｜robots.txtとnoindexの正しい使い分け 検索結果に表示させたくないページ 例えば、 検索結果ページ ユーザーにとって検索流入させる必要のない完了ページ 一部の管理上必要な公開ページ など、公開状態ではあるもののGoogle検索には載せたくない場合は、noindexを検討します。 ただし「そのページを本当に検索から除外すべきか」は慎重に判断しましょう。 SEO上価値がないと思ってnoindexにしたページが、実は検索流入を持っていた、というケースもあります。 Googlebotのクロールを抑えたいページ 大量のURLが生成されるなど、Googlebotに積極的にクロールしてもらう必要がない領域ではrobots.txtを検討します。 Googleも、robots.txtをクロールトラフィックの管理などに利用できるとしています。 ただし、小規模な企業サイトで、 「SEOに良さそうだから、とりあえずrobots.txtで色々ブロックする」 必要はありません。 むしろ重要なCSS・JavaScriptやページを誤ってブロックするリスクに注意が必要です。 会員限定・社内限定・機密情報を守りたいページ これはrobots.txtでもnoindexでもありません。 ログイン認証やパスワード保護など、アクセス自体を制限する仕組みが必要です。 robots.txtは誰でも閲覧できるファイルであり、セキュリティ機能ではありません。 noindexも検索結果への掲載を制御するもので、URLを知っている人からページを守る機能ではありません。 Googleも、検索結果に出したくないページについて、必要に応じてパスワード保護などを利用するよう案内しています。 機密情報を守る目的でrobots.txtやnoindexだけを使うのはNGです。 テスト環境・ステージングサイト リニューアルで特に注意したいのが、制作中のテストサイトです。 テストサイトがGoogleにインデックスされると、 本番サイトとほぼ同じ内容が検索される 制作途中の情報が一般公開される 会社名検索でテストサイトが出る といった問題につながります。 テスト環境では、noindexだけに依存するのではなく、認証をかけて一般ユーザーや検索エンジンからアクセスできない状態にするのが安全です。 そして本番公開時には、認証・noindex・robots.txtなどのテスト用設定が残っていないか必ず確認します。 検索に表示されない時に確認すべきポイント noindexが残っていないか リニューアル後に検索へ出なくなった場合、最優先で確認したいのがnoindexです。 制作中に設定していたnoindexを、本番サイトでもそのまま残してしまう事故があります。 特に、 トップページ サービスページ ブログ・お知らせ 施工事例 採用ページ など重要ページのnoindexは致命的です。 robots.txtで重要ページをブロックしていないか robots.txtの設定ミスによって、重要なページ群をGooglebotがクロールできなくなっている可能性もあります。 例えば、 Disallow: / のような設定は、対象ユーザーエージェントに対してサイト全体へのクロールを禁止する意味になります。 制作環境用の設定を本番へそのまま移さないよう注意しましょう。 WordPressの検索エンジン表示設定を確認する WordPressでは管理画面に、検索エンジンがサイトをインデックスしないよう促すための設定があります。 制作中に有効にしていた場合、公開時の解除忘れに注意が必要です。 リニューアル公開時のチェックリストに、 「検索エンジン関連設定の確認」 を必ず入れておきましょう。 HTTPヘッダーのX-Robots-Tagを確認する HTMLを見てもnoindexが見つからないのに検索へ出ない場合、HTTPレスポンスヘッダーにX-Robots-Tagが設定されている可能性があります。 Googleでは、X-Robots-Tagでもnoindexなどのルールを指定できます。 特に、 PDF サーバー設定 .htaccess NGINX設定 などが関係する場合は、制作会社やエンジニアへ確認しましょう。 そもそもGoogleにクロールされているか noindexもrobots.txtも問題がないのに表示されない場合、 新しく公開したばかり 内部リンクがない XMLサイトマップに含まれていない GoogleがまだURLを発見していない など、別の理由も考えられます。 「検索に出ない＝noindex」と決めつけず、Search Consoleで状況を確認することが大切です。 リニューアル時に起こりやすいrobots.txt・noindex事故 テスト環境のnoindexを本番に残す 最も危険な事故の一つです。 デザインもフォームも正常なのに、検索流入だけが急激に落ちる可能性があります。 robots.txtでサイト全体をブロックしたまま公開する 制作中にクロールを抑える目的で設定し、そのまま本番公開するケースです。 公開前チェックで必ずrobots.txtを確認します。 noindexページをrobots.txtでもブロックする 先ほど説明した通り、Googlebotがnoindexを確認できなくなる可能性があります。 検索から外したいなら、Googlebotがnoindexを読み取れる状態にすることが必要です。 robots.txt内に「Noindex:」と書く robots.txtへnoindexを記述して検索結果から除外しようとする方法は、Googleではサポートされていません。 Googleは、noindexはmetaタグまたはHTTPレスポンスヘッダーで実装するよう案内しています。 インデックスさせたい重要ページまでnoindexにする カテゴリページやサービス詳細などを、「重複しそうだから」という理由だけでnoindexにするのも注意が必要です。 そのページがユーザーの検索意図に応えられるなら、検索流入の入口になる可能性があります。 noindexは、 「SEO評価が低そうだから」ではなく、「検索結果に存在する必要があるか」 で判断しましょう。 設定を確認する方法｜Search Consoleでチェックする robots.txtやnoindexの状態を確認する際は、Google Search Consoleを活用します。 特に便利なのがURL検査ツールです。 対象URLについて、 Googleにインデックスされているか クロールできているか noindexが検出されているか GoogleがどのURLを正規URLとして認識しているか などを確認できます。 Googleも、noindexが正しく実装されているか確認する方法としてURL検査ツールやページのインデックス登録レポートを案内しています。 robots.txtについても、Search Consoleのrobots.txtレポートなどを利用して公開済みファイルの問題を確認できます。 「設定したつもり」で終わらず、Googleから実際にどう見えているかを確認することが重要です。 robots.txt・noindexチェックリスト robots.txt robots.txtがドメインのルート直下にある 重要ページを誤ってDisallowしていない サイト全体を意図せずブロックしていない 制作環境用の設定が本番に残っていない 「検索から消す目的」でrobots.txtを使っていない robots.txtにNoindexルールを書いていない noindex 検索結果に必要なページへnoindexが付いていない noindexページをrobots.txtで同時にブロックしていない WordPress等の検索エンジン設定を確認している HTTPヘッダーのX-Robots-Tagも確認している noindex設定後、Search Consoleで認識状況を確認している リニューアル公開時 トップページをURL検査した 主要サービスページをURL検査した robots.txtを確認した noindexを全ページ横断で確認した XMLサイトマップを確認した 旧URL→新URLの301を確認した 公開後もSearch Consoleでインデックス状況を監視している まとめ：検索に出したくない＝robots.txtではない robots.txtとnoindexは似ているようで、役割が明確に違います。 robots.txt→ クロールを制御する noindex→ 検索結果へのインデックスを制御する そして最も注意したいのが、 robots.txtでクロールを止めると、Googlebotがnoindexを読めなくなる という点です。 Googleも、noindexを有効にするには、そのページをrobots.txtでブロックせずGooglebotがアクセスできる状態にする必要があると明記しています。 また、robots.txtもnoindexもセキュリティ機能ではありません。 社内限定・会員限定・機密情報など、本当に第三者へ見せたくない情報については、認証などアクセス自体を制限する仕組みが必要です。 特にサイトリニューアルでは、制作中の設定が本番へ残り、検索流入が失われる事故があります。 公開前には、 robots.txt noindex X-Robots-Tag Search Console XMLサイトマップ をセットで確認し、検索エンジンが正しくサイトをクロール・インデックスできる状態を整えましょう。 無料相談 Refuでは、リニューアル時のrobots.txt・noindex設定確認から、Search Consoleを使ったインデックス状況の調査、301リダイレクト、XMLサイトマップ、公開後のSEO監視まで一括で対応しています。 「リニューアル後に検索に出なくなった」「noindexが残っていないか確認したい」「Search Consoleにエラーが出ているけれど原因が分からない」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら Googleサーチコンソールの基本操作と改善への活かし方 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 コンテンツ移行で失敗しないために｜旧サイト資産の棚卸しと移行判断基準 ホームページの404エラーとは？SEOへの影響と正しい対処法
