COLUMN
よく検索されるキーワード
2026/10/05
ホームページ制作の基本Webアクセシビリティとは？誰にでも使いやすいホームページの基本
Webアクセシビリティとは？ Webアクセシビリティとは、障害の有無などにかかわらず、Webサイトの情報や機能を利用できるようにする考え方です。 たとえば、 画面を見づらい人 マウスを操作できない人 音声を聞くことが難しい人 文字の理解に時間がかかる人 など、それぞれ異なる方法でWebサイトを利用しています。 W3Cでは、Webアクセシビリティを、障害のある人がWebを知覚・理解・操作し、情報やサービスを利用できる状態と説明しています。 また、アクセシビリティへの配慮は障害のある人だけでなく、 高齢者 一時的にケガをしている人 日差しが強い場所でスマートフォンを見る人 音を出せない環境で動画を見る人 などにも役立ちます。 つまり、Webアクセシビリティは一部の人だけのためではなく、できるだけ多くの人が使いやすいホームページを作るための基本設計です。 なぜ企業サイトでも重要なのか 企業サイトでは、 商品・サービスを調べる 問い合わせる 予約する 求人へ応募する 資料を請求する など、さまざまな行動が行われます。 もし、 「文字が読めない」「ボタンを操作できない」「フォームの入力方法が分からない」 という状態になっていれば、ユーザーはサービスを利用できません。 アクセシビリティを改善することは、 より多くのユーザーへ情報やサービスを届けること につながります。 日本では2024年4月1日から改正障害者差別解消法が施行され、民間事業者にも障害のある人への合理的配慮の提供が義務化されています。 ただし、これは「すべての企業サイトが特定のWebアクセシビリティ規格へ完全準拠しなければ違法」という意味ではありません。 Webサイトも含め、利用上の障壁を減らす取り組みを継続的に考えていくことが重要です。 知っておきたいWCAGとJIS Webアクセシビリティには、代表的なガイドラインがあります。 WCAG WCAG（Web Content Accessibility Guidelines）は、W3Cが策定する国際的なWebアクセシビリティのガイドラインです。 2026年現在、WCAG 2.2がW3C Recommendationとして公開されています。 WCAGでは、大きく4つの原則に分けて考えます。 知覚可能：情報を認識できる 操作可能：サイトを操作できる 理解可能：内容や操作方法を理解できる 堅牢：さまざまな環境・支援技術で利用できる 適合レベルはA・AA・AAAの3段階に分けられています。 JIS X 8341-3 日本では、Webアクセシビリティに関する規格としてJIS X 8341-3:2016が広く参照されています。 デジタル庁の最新ガイドブックでも、現在参照されることの多い規格として紹介されています。 企業サイトで初めて取り組む場合、最初からすべてを完璧に対応しようとするより、影響の大きい部分から改善していくことが現実的です。 企業サイトで確認したい7つのポイント 文字と背景のコントラスト 薄いグレーの文字を白背景に配置すると、視力によっては読みづらくなります。 デザイン性だけでなく、十分に文字を認識できる色の差を確保しましょう。 画像に代替テキストを設定する 重要な画像には、内容を説明するalt（代替テキスト）を設定します。 たとえば商品写真なら、画像を見ることができないユーザーにも何の画像なのか伝わるようにします。 W3Cも、画像への適切な代替テキストをWebアクセシビリティの基本例として示しています。 見出しを正しい順番で使う ページタイトルや項目を、 H1 H2 H3 などの見出しタグで適切に構造化します。 単に文字を大きくするのではなく、内容の階層が分かるHTML構造にすることが重要です。 キーボードでも操作できるようにする すべてのユーザーがマウスを利用できるとは限りません。 メニュー ボタン フォーム モーダルウィンドウ などを、キーボードでも操作できるか確認します。 W3Cも、マウスだけに依存せずキーボードから機能を利用できることを基本的なアクセシビリティ例として紹介しています。 ボタンやリンクを分かりやすくする 「こちら」だけでは、リンク先が分かりにくくなります。 たとえば、 × こちら ではなく、 ○ 料金プランを見る○ お問い合わせフォームへ のように、押した後に何が起こるのか分かる文言にします。 フォームの入力方法を分かりやすくする 問い合わせフォームでは、 何を入力する項目なのか 必須なのか任意なのか 入力エラーの理由 どこを修正すればいいのか が分かる設計にします。 色だけでエラーを伝えるのではなく、 「メールアドレスを入力してください」 など文章でも伝えることが重要です。 動画には字幕・テキスト情報を用意する 音声だけで重要な内容を説明すると、音声を聞けないユーザーには情報が伝わりません。 必要に応じて、 字幕 テキスト説明 文字起こし などを用意します。 これは、電車内など音を出せない環境で動画を見るユーザーにも役立ちます。 よくあるアクセシビリティのNG例 企業サイトでは、次のような状態に注意しましょう。 文字が小さすぎる デザインを優先して本文まで極端に小さくすると、読みづらくなります。 薄い文字色を多用する おしゃれに見えても、背景とのコントラストが不足している場合があります。 画像内に重要な文章をすべて入れる 画像が表示されない環境やスクリーンリーダーでは、情報が伝わらない可能性があります。 色だけで情報を区別する たとえば、 「赤色が必須、緑色が任意」 だけでは、色を区別しづらいユーザーに伝わりません。 文字や記号も併用しましょう。 自動再生・激しい動きを多用する 動画やアニメーションを自動再生し続けると、利用しづらくなる場合があります。 停止・一時停止できる設計を検討します。 公開後もアクセシビリティを維持する アクセシビリティは、制作会社だけが対応すれば終わりではありません。 公開後に、 ブログを追加する バナーを作る PDFを掲載する 動画を追加する 新しいフォームを作る ことで、アクセシビリティが損なわれることがあります。 デジタル庁も2026年6月に、サイト公開後に追加されるコンテンツのアクセシビリティを扱う「ウェブアクセシビリティ広報向けガイドブック」を公開しています。 そのため、社内でも最低限、 画像には代替テキストを付ける 見出し構造を守る 読みやすい文字色を使う リンク先が分かる文章にする 動画には必要に応じて字幕を付ける といった更新ルールを決めておくことが大切です。 また、アクセシビリティチェックツールだけですべてを判定できるわけではありません。 W3Cも、ツールによる自動評価だけでは完全な判断はできず、人による確認も必要と説明しています。 まとめ：特別対応ではなく“使いやすいサイト”の基本 Webアクセシビリティという言葉を聞くと、 「特別な対応が必要なのでは？」 と難しく感じるかもしれません。 しかし基本は、 文字を読みやすくする 画像の内容を伝えられるようにする マウス以外でも操作できるようにする フォームのエラーを分かりやすくする 音声以外でも情報を伝える サイト構造を正しく作る といった、ホームページを使いやすくするための設計です。 WCAG 2.2などの基準を参考にしながら、自社サイトで影響の大きい部分から改善していきましょう。 アクセシビリティは一度対応して終わりではなく、ホームページを運用し続ける中で維持・改善するものです。 多くの人が迷わず情報を確認し、問い合わせ・予約・応募まで進めるホームページを目指しましょう。 無料相談 Refuでは、デザインの見た目だけではなく、文字の読みやすさ・情報構造・フォーム・スマートフォン操作など、実際のユーザーが使いやすいホームページ設計を重視しています。 「今のホームページが使いづらくないか確認したい」「リニューアルを機にアクセシビリティも見直したい」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら スマホ対応は必須！レスポンシブデザインの基本 お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本 原稿が書けないを解決！伝わる文章構成テンプレと作り方 ホームページの写真で反応が変わる｜撮影のコツと“使える写真”チェックリスト ホームページはどのくらい更新すべき？更新頻度と運用ルールの決め方
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/14
ホームページ制作の基本ホームページはどのくらい更新すべき？更新頻度と運用ルールの決め方
ホームページはどのくらいの頻度で更新すべき？ ホームページを公開した後、 「どのくらいの頻度で更新すればいいですか？」「毎週ブログを書かないとSEOに弱くなりますか？」「更新しないと検索順位が下がりますか？」 といった疑問を持つ企業は少なくありません。 結論から言えば、 すべてのホームページに共通する「正しい更新頻度」はありません。 毎日更新する必要があるサイトもあれば、重要情報を数ヶ月ごとに確認するだけで十分なサイトもあります。 大切なのは、 「更新回数を増やすこと」ではなく、「ユーザーに必要な情報を正確で役立つ状態に保つこと」 です。 Googleも、検索順位を上げる目的だけで大量の新しいコンテンツを追加したり、古いコンテンツを削除したりしてサイト全体を“新鮮に見せる”ことには効果がないと明確に案内しています。 つまり、 「毎週更新しているサイトだからSEOに強い」 という単純な仕組みではありません。 結論：「毎週更新」より“必要な情報を必要なときに更新”が重要 ホームページの更新は、大きく2種類に分けて考えると分かりやすくなります。 情報を正確に保つための更新 例： 料金変更 営業時間変更 サービス追加 住所変更 スタッフ変更 募集要項変更 これは必要になった時点ですぐ更新するべき情報です。 サイトの価値を高めるための更新 例： 実績追加 FAQ追加 ブログ記事追加 古い記事のリライト 写真の更新 導線改善 こちらは毎日行う必要はありません。 アクセスデータや問い合わせ内容を確認しながら、必要なタイミングで改善していきます。 ホームページ運用では、 更新頻度をKPIにするのではなく、「正しい情報になっているか」「ユーザーの疑問を解決できているか」を基準にする ことが重要です。 ホームページを定期的に更新する4つのメリット 情報の信頼性を保てる ユーザーがホームページを見たとき、 料金が昔のまま 退職したスタッフが掲載されている 終了したサービスが残っている 営業時間が違う といった状態だと、会社への信頼を損ねます。 ホームページは最新の会社情報を確認する場所として使われるため、情報の正確性が重要です。 問い合わせ前の疑問を減らせる 営業やお問い合わせで何度も聞かれる質問があれば、サイトへ追加できます。 たとえば、 「この地域にも対応していますか？」 という問い合わせが増えているなら、サービスページやFAQへ対応エリアを追記します。 こうした更新を繰り返すことで、 営業担当者が毎回説明している内容をホームページが代わりに説明してくれる状態 を作れます。 検索ユーザーにより役立つ情報を提供できる 検索ニーズや業界情報は変化します。 古い記事に、 現在では使われていないサービス 古い制度 過去の料金 廃止された機能 などが残っていれば、ユーザーの役に立ちません。 Googleは、検索向けに量産するコンテンツではなく、ユーザーが目的を達成できる有用で信頼できるpeople-firstコンテンツを重視すると説明しています。 古い情報を正しく更新することは、この考え方にも合っています。 サイト改善を継続できる 公開時点で完璧なホームページを作ることは難しいものです。 公開後に、 どのページが読まれているか どこから問い合わせが来ているか どこで離脱しているか を確認しながら改善することで、ホームページの成果を高められます。 つまり更新とは、 記事を追加するだけではなく、既存ページを改善することも含む と考えましょう。 ページ別｜おすすめの確認・更新タイミング ホームページ全体を同じ頻度で更新する必要はありません。 ページごとに優先順位を変えます。 会社概要・営業時間・連絡先 更新タイミング：変更が決まったらすぐ 対象： 会社名 所在地 電話番号 代表者 営業時間 定休日 アクセス 拠点情報 これらはSEO以前に、企業情報として正確である必要があります。 移転や営業時間変更が決まった場合は、ホームページだけでなく、 Googleビジネスプロフィール SNS 求人媒体 ポータルサイト などの情報も合わせて見直しましょう。 サービス・料金ページ 確認目安：最低でも半年〜1年に1回＋変更時は即時 サービスページは問い合わせに直結する重要ページです。 確認する項目： サービス内容 対応範囲 料金 納期 対象顧客 オプション 契約条件 特に価格改定やサービス変更を行った場合は、すぐに更新します。 料金ページとFAQ、ブログ記事などで金額が食い違っていないかも確認しましょう。 実績・事例 更新目安：掲載できる実績ができたタイミング 実績は定期更新と相性が良いコンテンツです。 たとえば、 月1件 四半期に3件 大きな案件が終わるたび など、自社に合ったルールを作ります。 すべての案件を掲載する必要はありません。 ターゲットに近い業種・課題・規模の実績 を優先して掲載すると、問い合わせへの説得力が高まります。 よくある質問（FAQ） 確認目安：月1回〜四半期に1回 お問い合わせや商談で新しい質問が増えたら追加します。 おすすめなのが、 「同じ質問を2〜3回受けたらFAQ候補にする」 というルールです。 料金やサービス内容を変更したときは、FAQの回答も必ず確認しましょう。 ブログ・コラム 更新目安：無理なく継続できる頻度 ブログについては、 「週1回でなければSEOに弱い」 といった決まりはありません。 月2本でも、月4本でも構いません。 重要なのは、 自社の顧客が知りたいテーマか 既存記事と重複していないか 独自情報があるか 問い合わせにつながるテーマか です。 Googleも、「検索流入を期待して多数のテーマを大量に作っていないか」という観点を、検索エンジン向けコンテンツを見直す質問として挙げています。 本数を増やすための記事作成よりも、ユーザーに必要な記事を優先しましょう。 採用情報 更新タイミング：募集条件が変わったら即時 採用ページでは、 給与 勤務時間 勤務地 休日 募集職種 選考方法 などが古いままだと応募者とのトラブルにつながります。 募集を終了した求人を長期間残さないことも重要です。 採用強化期間だけではなく、募集内容が現在の条件と一致しているか定期的に確認しましょう。 SEO目的だけで更新日を変えるのはNG SEO対策としてよく見かけるのが、 記事内容はそのままなのに、更新日だけ新しくする 方法です。 これはおすすめできません。 Googleは、コンテンツを大幅に変更していないにもかかわらず、新しく見せるためだけにページの日付を変更していないかを、検索エンジン向けコンテンツを判断する注意項目として明示しています。 また、Googleはページの日付について、実際に公開または大幅に更新した日時を示すことを推奨しています。 したがって、 × 誤字を1文字修正して更新日を変更する× 日付だけ毎年変更する× SEO目的で公開日を現在日に変更する といった運用は避けましょう。 一方、 制度変更に合わせて内容を全面更新した 料金表を更新した 新しい事例・データを追加した 古い情報を大幅に入れ替えた のであれば、最終更新日を変更するのは自然です。 古い記事は削除？リライト？残す？判断基準 古いコンテンツが見つかったとき、 全部削除する必要はありません。 次の3つに分けて判断します。 内容は有用だが情報が古い → リライト 例： 「2023年版ホームページSEO対策」 という記事で、基本的な内容は使える場合。 最新情報を追加し、古い部分を更新します。 古くても歴史的価値がある → 残す 例： 過去のイベントレポート 過去の施工事例 過去のお知らせ などです。 現在の情報と誤解されないよう、 「2023年当時の情報です」 などを明記して残す方法があります。 現在は価値がなく代替ページもない → 削除を検討 たとえば、 完全に終了したキャンペーン 内容が薄く誰にも読まれていない記事 重複しているページ などです。 ただし、 「古いページを削除すればサイト全体が新しく見えてSEOに良い」 という理由だけで大量削除することはおすすめできません。 Googleも、検索順位向上を期待して古いコンテンツを大量削除することでサイトを“新鮮”に見せようとすることに効果はないと説明しています。 更新すべきページを見つける5つの方法 Search Consoleで順位が落ちているページを見る 以前アクセスがあったのに、 表示回数が減った クリックが減った 順位が落ちた ページを確認します。 競合ページと比べ、 情報が古くなっていないか を確認しましょう。 GA4でアクセス数の多いページを見る アクセスが多いページほど、情報が古い場合の影響も大きくなります。 特に、 サービス 料金 採用 事例 人気ブログ記事 から優先して確認します。 問い合わせ内容を見る ホームページに書いてあるにもかかわらず、同じ内容を頻繁に質問されている場合は、 情報が見つけにくい 説明が分かりにくい 情報量が足りない 可能性があります。 ページを更新するサインです。 営業担当者に聞く 営業担当者から、 「サイトにこれを書いておいてほしい」 と言われる内容は重要です。 たとえば、 よく説明している強み 他社との違い よくある誤解 料金の仕組み 対応範囲 などです。 競合サイトと比較する 競合サイトに、 新サービス 詳しい事例 FAQ 料金 動画 比較コンテンツ などが追加されている場合、自社サイトに不足している情報が見つかることがあります。 ただし、そのまま真似するのではなく、 自社の顧客にも本当に必要な情報か を判断してください。 ホームページ運用を止めない社内ルールの作り方 ホームページが更新されなくなる一番の原因は、 担当者が決まっていないこと です。 最低限、次の4つを決めておきましょう。 更新担当者 誰が更新するのか。 例： 広報担当 営業担当 総務 制作会社 確認担当者 更新内容を誰が承認するか。 特に、 料金 契約条件 採用条件 は担当者の判断だけで変更しないようにします。 更新頻度 例： 毎月 お問い合わせ内容確認 実績追加候補確認 四半期 サービスページ FAQ 人気記事 年1回 会社概要 採用ページ プライバシーポリシー サイト全体のリンクチェック といった形です。 更新依頼の方法 たとえば、 Slackの専用チャンネルへ投稿Googleスプレッドシートで管理 など、依頼方法を統一します。 誰かが覚えている状態ではなく、仕組みとして残すことが重要です。 更新時に確認したいSEO・技術面のポイント コンテンツを大きく更新した場合は、文章だけでなく技術面も確認します。 title・description 内容が大きく変わった場合は、検索結果に表示するタイトル・説明文も見直します。 内部リンク 新しい関連記事ができたら、過去記事からもリンクします。 更新日 大幅に内容を変更した場合は、ユーザーに分かる形で最終更新日を表示すると整理しやすくなります。 Googleは、ページの日付について、ユーザーに見える日付と構造化データの日時を一致させることなどを推奨しています。 XMLサイトマップのlastmod XMLサイトマップにlastmodを設定している場合は、実際の重要な更新日時と一致させます。 Googleは、lastmodについてメインコンテンツ・構造化データ・リンクなどの重要な変更を反映すべきとしており、著作権年の変更などは重要な更新とはみなしていません。 一方、XMLサイトマップのchangefreqやpriorityはGoogleでは利用されません。 つまり、 「毎日更新とサイトマップに書けば頻繁にGoogleが来てくれる」 という考え方ではありません。 よくあるホームページ更新の失敗 毎週ブログを書くことが目的になる 最初はSEO目的だったのに、いつの間にか、 「今週も1本公開しなければ」 が目的になってしまうケースです。 → 本数より検索意図・独自性・問い合わせへの関連性を優先しましょう。 新規記事だけ作り、既存ページを放置する 100記事あるのに、昔の記事は一度も確認していない。 これでは古い情報が蓄積します。 → 新規作成と既存記事のリライトを両方行いましょう。 更新日だけ変える 内容を変更せず、検索順位を上げる目的で日付だけ変更する方法です。 → Googleも実質的な変更のない日付変更を注意すべき行為として挙げています。 重要ページよりブログを優先する サービス料金が古いのに、ブログだけ毎週更新しているケースです。 → 優先順位は、 会社情報・料金・サービス → 実績・FAQ → ブログ と考える方が安全です。 更新した結果を見ない ページを変更した後、 検索流入 CTAクリック 問い合わせ数 を確認していないケースです。 → 更新したらGA4・Search Consoleで変化を確認しましょう。 すぐ使える更新管理チェックリスト 毎月確認 新しい実績・事例はないか よく聞かれる質問が増えていないか 問い合わせフォームは正常に届いているか 主要ページのアクセス・問い合わせ数に変化がないか 更新すべきブログ記事はないか 3〜6ヶ月ごとに確認 サービス内容は現在と一致しているか 料金・プランは正しいか 古い写真が残っていないか FAQの回答は現在の条件と一致しているか 主要記事の検索順位が大きく落ちていないか 内部リンクを追加できるページはないか 年1回確認 会社概要 代表・スタッフ情報 採用条件 プライバシーポリシー サイト全体のリンク切れ WordPress・CMSの運用体制 アクセス解析・計測設定 公開済み記事全体の棚卸し 変更時に即確認 住所変更 電話番号変更 営業時間変更 価格改定 サービス終了・追加 採用条件変更 法律・制度の変更に影響されるページ すべてのページを毎月更新するのではなく、 「即時更新」「定期確認」「必要に応じて改善」 の3種類に分けて管理すると運用しやすくなります。 まとめ：更新頻度ではなく「情報の鮮度と価値」を管理する ホームページの更新には、 「月何回更新すれば正解」 という共通の答えはありません。 重要なのは、 変更された情報はすぐ反映する サービス・料金など重要ページを定期的に確認する 実績・FAQを継続的に追加する 検索データを見て古い記事をリライトする 検索順位のためだけに更新日を変更しない 新規記事の本数より既存コンテンツの価値も重視する ことです。 Googleも、サイトを新しく見せるためだけにコンテンツを追加・削除したり、実質的な変更なしに日付を変更したりすることを推奨していません。 ホームページ運用で考えるべきなのは、 「最後にいつ更新したか」ではなく、「今サイトを訪れたユーザーにとって、この情報は正しく役に立つか」 です。 毎週無理に記事を書くより、 重要情報を正しく維持し、実際の問い合わせやアクセスデータをもとに改善を続ける。 この運用が、長期的に成果を生み出すホームページにつながります。 ホームページの運用・改善ならRefuへ Refuでは、ホームページ制作後も、GA4・Search Consoleなどのデータや実際のお問い合わせ内容をもとに、「どのページを、どの順番で更新すべきか」まで整理した運用・改善をご提案しています。 「ホームページを何年も更新できていない」「ブログは更新しているけれど成果につながっているか分からない」 という方も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック ホームページの保守・更新費用の相場｜何が含まれて何が別料金？ ホームページのKPI設計｜アクセス・CV・問い合わせを“数字で改善”する方法 GA4で最低限見るべき指標7つ｜初心者でも分かる分析のはじめ方 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 成果が出る「実績・事例」ページの作り方｜信頼を獲得して問い合わせを増やす お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本
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/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/24
ホームページ制作の基本プライバシーポリシーは必要？ホームページに掲載すべき項目と作り方
プライバシーポリシーとは？ホームページで必要な理由 企業のホームページでは、 お問い合わせフォーム 資料請求 採用応募 メールマガジン登録 会員登録 商品購入 予約 などを通じて、ユーザーの氏名・メールアドレス・電話番号などを取得することがあります。 こうした情報について、 「何のために取得するのか」「どのように管理するのか」「第三者へ提供することがあるのか」 などをユーザーへ分かりやすく示すために設けられるのが、一般にプライバシーポリシー（個人情報保護方針）と呼ばれるページです。 個人情報保護委員会も、事業者と本人との信頼関係を構築する観点から、「プライバシーポリシー」「プライバシーステートメント」などを策定し、ホームページ等で分かりやすく公表することが重要としています。 ホームページ上のプライバシーポリシーは、単なる法律対策のためのページではありません。 「この会社は個人情報をどのように扱うのか」をユーザーへ説明する、企業としての信頼設計の一部と考えることが大切です。 結論：すべてのサイトに「プライバシーポリシー」という名称のページが必須とは限らない 「ホームページを作ったら、法律上必ずプライバシーポリシーという名前のページを設置しなければならない」 と理解されることがありますが、厳密には少し異なります。 個人情報保護法では、個人情報を取り扱う事業者に対して、主に次のような対応が求められています。 利用目的をできる限り具体的に特定すること 一定の場合に利用目的を通知・公表・明示すること 保有個人データについて一定事項を本人が知り得る状態に置くこと 必要かつ適切な安全管理措置を講じること そのため重要なのは、 「プライバシーポリシーというページを置いたか」 ではなく、 「自社の個人情報の取扱いについて、必要な内容を適切に説明できているか」 です。 ただし、企業サイトでは必要事項を一か所へまとめたプライバシーポリシーページを設置する方法が、ユーザーにも分かりやすく実務的です。 特に、お問い合わせ・採用応募・予約などで個人情報を取得するサイトでは、基本ページの一つとして用意しておくとよいでしょう。 お問い合わせフォームがあるサイトは特に注意 企業サイトで特に重要なのが、お問い合わせフォームから個人情報を取得する場合です。 個人情報保護法では、本人から入力フォームなどを通じて直接個人情報を取得する場合、原則として取得前に利用目的を本人へ明示することが求められます。 個人情報保護委員会のガイドラインでも、ホームページの入力画面へ本人が情報を入力する場合が対象として示され、送信ボタンを押す前などに利用目的が目に留まるよう配置することが望ましいとされています。 そのため、 フッターの一番下にプライバシーポリシーへのリンクを置くだけ ではなく、お問い合わせフォームの近くにも確認できる導線を設けることが重要です。 例えば、フォームの送信ボタン付近に、 「個人情報の取扱いについてはプライバシーポリシーをご確認ください。」 という文言とリンクを設置します。 自社の運用や法的要件に応じて、 「プライバシーポリシーに同意する」 というチェック欄を設ける方法もあります。 ただし、チェック欄を設置すれば個人情報保護法への対応が完了するわけではありません。 まずは、自社が何を取得し、何に利用しているのかを整理することが重要です。 プライバシーポリシーに掲載したい基本項目10選 中小企業の一般的なコーポレートサイトを想定した場合、主に次の項目を確認します。 事業者の名称・住所・代表者 まずは、 会社名・事業者名 住所 代表者氏名 など、誰が個人情報を管理しているのかを明確にします。 保有個人データについて、個人情報保護法では事業者の氏名または名称、住所、法人の場合は代表者氏名などを本人が知り得る状態に置くことが求められています。 会社概要ページと表記が異ならないよう確認しましょう。 取得する個人情報 自社がどのような情報を取得する可能性があるのかを整理します。 例えば、 氏名 会社名 部署・役職 メールアドレス 電話番号 住所 お問い合わせ内容 採用応募情報 サービス利用情報 などです。 ただし、実際には取得していない情報までテンプレートのまま列挙する必要はありません。 現在使用しているフォームやサービスを確認し、実際に取得している情報を基準に整理しましょう。 個人情報の利用目的 プライバシーポリシーの中でも特に重要な項目です。 個人情報保護法では、個人情報を取り扱う際、その利用目的をできる限り具体的に特定することが求められています。 例えば、 × 当社事業のため だけでは、ユーザーは何に利用されるのか判断できません。 自社の実態に合わせて、 お問い合わせへの回答のため サービスの提供・契約手続きのため 資料請求への対応のため 採用応募者への連絡・選考のため サービス改善のため 必要に応じたご案内のため など、具体的に記載します。 特に注意したいのが、問い合わせで取得した情報を営業メールや広告配信など、別の目的にも利用する場合です。 最初に示した利用目的と、実際の利用方法にズレがないか確認しましょう。 第三者提供について 個人データを他社などの第三者へ提供する可能性がある場合は、その取扱いを整理します。 一般的には、 「法令に基づく場合などを除き、本人の同意なく第三者へ提供しません」 といった内容が考えられます。 ただし、自社が実際に行っているデータの取扱いに合わせて記載する必要があります。 個人情報保護法では、第三者提供について原則として本人の同意が必要となるルールが定められています。 テンプレートをそのまま掲載するのではなく、実際にどの情報が、どこへ送られているのかを確認することが重要です。 個人情報の取扱いを委託する場合 ホームページ運用では、外部サービスを利用するケースがあります。 例えば、 Web制作・保守会社 メール配信サービス CRM・顧客管理システム クラウドサービス 採用管理システム フォームサービス などです。 プライバシーポリシーを作成するときは、 「自社以外のサービスに、どの情報が送られているか」 も整理しましょう。 個人情報保護委員会も、個人情報の取扱いについて、委託の有無や委託する事務内容を明らかにするなど、透明性を高めることが重要としています。 安全管理措置 個人情報取扱事業者には、個人データの漏えい・滅失・毀損などを防ぐために、必要かつ適切な安全管理措置を講じることが求められています。 ホームページでは、セキュリティ上問題のない範囲で、 アクセス権限の管理 従業者への教育 不正アクセス対策 SSLによる通信の暗号化 個人データを扱う端末の管理 など、自社が実際に実施している対策を整理します。 ここで重要なのは、実施していない対策を「実施しています」と記載しないことです。 プライバシーポリシーの記載と実際の運用を一致させましょう。 開示・訂正・利用停止等の手続き 本人から、 自分の情報を確認したい 内容を訂正したい 利用を停止してほしい 削除について相談したい といった申し出があった場合の手続きを記載します。 例えば、 「開示等をご希望の場合は、下記お問い合わせ窓口までご連絡ください。」 という形で案内します。 窓口だけでなく、必要に応じて受付方法や本人確認方法なども整理しておきましょう。 お問い合わせ・苦情窓口 個人情報の取扱いについて質問や苦情がある場合に、どこへ連絡すればよいのかを示します。 例えば、 会社名 担当部署 メールアドレス 電話番号 問い合わせフォーム などです。 通常のお問い合わせ窓口と同じ場合でも、ユーザーが迷わないよう明確に記載しましょう。 Cookie・アクセス解析ツールについて 多くの企業サイトでは、 アクセス解析 広告計測 SNS連携 動画埋め込み 地図 チャット 広告配信 などのためにCookieや類似技術を利用しています。 Cookieなどの端末識別子を通じて収集されるWeb閲覧履歴は、状況によって「個人関連情報」に該当する場合があります。 また、ほかの情報と組み合わせて特定の個人を識別できる場合などは、個人情報として扱われる可能性もあります。 そのため、 「Cookieは個人情報ではないから何も記載しなくてよい」 と一律に判断するのは避けましょう。 利用している外部サービスを洗い出し、 どのサービスを使っているか 何のために利用しているか どのような情報が扱われる可能性があるか を確認することが重要です。 プライバシーポリシーの変更・制定日 最後に、 制定日：20XX年XX月XX日最終改定日：20XX年XX月XX日 などを記載しておくと、現在の方針がいつ策定・更新されたものなのか分かりやすくなります。 法改正やサービス変更、外部ツールの追加などに伴って内容を更新する可能性があることも記載しておくと、運用しやすくなります。 問い合わせフォームには何を表示すればいい？ プライバシーポリシーを作成したら、お問い合わせフォームとのつながりも確認しましょう。 氏名やメールアドレスなどを直接取得する場合は、ユーザーが送信する前に利用目的を確認できる状態にしておくことが重要です。 例えば、フォーム下部に次のような導線を設置します。 個人情報の取扱いについては「プライバシーポリシー」をご確認ください。 必要に応じて、 □ プライバシーポリシーに同意する というチェックボックスを設置する方法もあります。 ここで重要なのは、 ユーザーが個人情報を送信する前に確認できること です。 フッターにリンクを置くだけでなく、フォーム周辺から簡単にアクセスできる設計にしましょう。 Cookie・Google Analyticsなどを使っている場合の考え方 現在の企業サイトでは、問い合わせフォームだけを確認していても十分とは限りません。 例えば、 Google Analyticsなどのアクセス解析 広告のコンバージョン計測 YouTube動画 Googleマップ SNS埋め込み チャットツール Bot対策ツール など、さまざまな外部サービスを利用しているケースがあります。 こうしたサービスによって、Cookieや閲覧履歴、端末情報などが外部へ送信される場合があります。 そのため、プライバシーポリシーを見直す際は、制作会社や担当者に、 「このホームページから外部サービスへ送られている情報はありますか？」 と確認することをおすすめします。 特にリニューアル時は、 以前のサイトでは使用していなかった解析・広告・チャットツールを新たに導入する ケースもあります。 デザインや機能だけでなく、ユーザーのデータがどこへ流れているのかも公開前に整理しておきましょう。 そのまま参考にできるプライバシーポリシーの基本構成 一般的な企業サイトであれば、例えば次のような構成で整理できます。 基本構成例 個人情報保護についての基本方針 取得する個人情報 個人情報の利用目的 個人情報の第三者提供 個人情報の取扱いの委託 安全管理措置 Cookie・アクセス解析等について 保有個人データの開示・訂正・利用停止等 お問い合わせ・苦情窓口 プライバシーポリシーの変更 制定日・最終改定日 事業者名・住所・代表者 ただし、これはあくまで一般的な構成例です。 ECサイト、求人サイト、会員サービス、医療・福祉サービスなどでは、取得する情報や関連する法令・ガイドラインが異なる場合があります。 「このテンプレートを貼れば完成」ではなく、自社の事業内容と実際の運用に合わせて調整することが前提です。 よくあるNG例｜他社サイトのコピペは危険 他社のプライバシーポリシーをそのままコピーする 最も避けたい方法です。 会社によって、 取得する情報 使用するツール 利用目的 委託先 第三者提供 問い合わせ方法 は異なります。 他社の文章をコピーすると、自社の実態と異なる内容を公表することになりかねません。 また、文章の内容によっては著作権上の問題につながる可能性もあるため、他社サイトの文章をそのまま転用するのは避けましょう。 「個人情報を適切に扱います」だけで終わる 抽象的な宣言だけでは、ユーザーは自分の情報が何に利用されるのか判断できません。 特に利用目的は、 問い合わせへの回答 採用選考 資料送付 サービス提供 など、実際の用途が分かる表現にしましょう。 実際に使っていないサービス名が残っている テンプレートを利用した結果、 「Google Analyticsを利用しています」 と記載しているものの実際には利用していない、または逆に使用しているにもかかわらず記載の検討がされていないケースがあります。 現在のサイトで利用しているツールを確認してから記載しましょう。 フォームからプライバシーポリシーへ移動できない プライバシーポリシーが存在していても、 ユーザーが個人情報を入力するタイミングで確認できない のでは、分かりやすい設計とはいえません。 フォーム送信前に確認できる位置へリンクを設置しましょう。 何年も更新していない ホームページの運用環境は変化します。 例えば、 新しいフォームを追加した 採用応募を開始した アクセス解析ツールを変更した 広告を開始した CRMを導入した 外部サービスを変更した にもかかわらず、プライバシーポリシーだけ昔のままになっているケースがあります。 サイトの機能変更とセットで内容を確認する運用にしましょう。 公開後も必要｜プライバシーポリシーを見直すタイミング プライバシーポリシーは、一度作成したら終わりではありません。 ホームページをリニューアルしたとき フォーム・CMS・アクセス解析・外部サービスなどが変わっていないか確認します。 新しい外部ツールを導入したとき 広告、アクセス解析、チャット、予約システムなどを追加した場合は、データの取扱いを確認します。 取得する情報が増えたとき 例えばフォームへ、 予算 住所 生年月日 などの項目を追加した場合です。 取得する情報と利用目的にズレがないか確認します。 個人情報の利用目的が変わったとき 問い合わせへの回答だけに使っていた情報を、新しくメール配信や別のマーケティング目的にも利用する場合は、法的な取扱いも含めて確認が必要です。 法令やガイドラインが変更されたとき 個人情報保護に関する制度やガイドラインは変更されることがあります。 少なくとも定期的に、 「現在のサイト・運用とプライバシーポリシーの記載内容が一致しているか」 を確認する仕組みを作っておくと安心です。 プライバシーポリシー公開前チェックリスト 事業者情報 事業者名・住所・代表者が現在の情報になっている 会社概要ページとの表記が一致している 取得・利用する情報 実際に取得している個人情報を把握している 利用目的を具体的に記載している フォーム送信前に利用目的を確認できる 利用目的と実際の運用が一致している データの取扱い 第三者提供の実態を確認している 外部委託サービスを把握している 使用している外部ツールを洗い出している Cookieやアクセス解析等の利用状況を確認している 管理・問い合わせ 安全管理措置の内容が実態と一致している 開示・訂正・利用停止等の窓口がある 苦情・問い合わせ先が分かる 実施していない対策を書いていない Webサイト上の導線 フッターからプライバシーポリシーへアクセスできる お問い合わせフォームからも確認できる 制定日・最終改定日を確認した 他社の文章をそのままコピーしていない 特に重要なのは、「書いてある内容」と「実際の運用」が一致しているかです。 文章だけ整っていても、実際の個人情報の取扱いと異なっていれば適切とはいえません。 まとめ：自社が実際に行っている個人情報の取扱いを書く プライバシーポリシーを作るときに最も重要なのは、他社のテンプレートを探すことではありません。 まずは、 何の情報を取得しているのか 何のために使っているのか どのシステムに保存しているのか 誰が扱うのか 外部サービスへ送っている情報はあるのか 本人からの問い合わせにどう対応するのか を整理します。 そのうえで、自社の実態に合わせたプライバシーポリシーを作成します。 個人情報保護法では、利用目的の特定・通知等、安全管理措置、保有個人データに関する事項の周知など、複数のルールが設けられています。 ホームページ制作でも、 「とりあえずテンプレートを置いておく」 ではなく、 「どんな情報を取得し、どのように扱っているホームページなのか」 まで設計することが重要です。 プライバシーポリシーは法律対策だけではなく、ユーザーに安心して問い合わせてもらうための信頼コンテンツとして整えていきましょう。 プライバシーポリシー・個人情報の取扱いでお悩みならRefuへ Refuでは、ホームページ制作時にお問い合わせフォーム・アクセス解析・外部サービスなど、サイト上でどのような情報を取得・利用するのかを整理したうえで、必要なプライバシーポリシーへの導線まで含めて設計しています。 「プライバシーポリシーを長年変更していない」「リニューアルで新しいツールを導入するが、何を見直せばよいか分からない」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本 写真・文章の著作権は大丈夫？ホームページ制作で起きがちな権利トラブル 会社概要ページの書き方｜信用される情報設計とNG例 問い合わせフォームに迷惑メールが届く原因｜スパム対策と安全な運用方法 SSL（https）って何？ホームページの信頼性とSEOに必須な理由 ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック
2026/08/17
ホームページ制作の基本問い合わせフォームに迷惑メールが届く原因｜スパム対策と安全な運用方法
問い合わせフォームに迷惑メールが届くのはなぜ？ ホームページを運用していると、突然、 英語や外国語のメッセージ 意味のない文字列 大量のURLが記載された投稿 仮想通貨・SEO・営業サービスなどの宣伝 同じ内容が短時間に何十件も送られてくる といった迷惑メールが届くことがあります。 「メールアドレスが漏えいしたのでは？」 と心配になるかもしれませんが、問い合わせフォーム経由の迷惑メールの場合、必ずしもメールアドレスが流出しているとは限りません。 多くの場合は、Bot（自動プログラム）がWeb上のお問い合わせフォームを発見し、自動的に情報を送信していることが原因です。 現在のWebサービスでは、不正な自動アクセスを完全に一つの仕組みだけで防ぐのは難しく、OWASPもBot対策について、WAF・レート制限・行動判定・Honeypot・CAPTCHAなどを組み合わせた多層的な対策を推奨しています。 そのため、 「迷惑メールが来た＝サイトが乗っ取られた」 と判断するのではなく、まずはどこから送信されているのかを切り分けることが重要です。 まず確認｜「フォームスパム」と普通の迷惑メールは別物 迷惑メール対策を始める前に、まず確認したいのが、 「ホームページのフォーム経由なのか」 という点です。 フォームスパム ホームページの入力フォームをBotなどが自動送信し、その内容が管理者宛ての通知メールとして届いている状態です。 この場合は、 CAPTCHA・Bot対策 Honeypot 送信回数制限 WAF 入力チェック など、ホームページ側の対策が有効です。自動化された不正利用については、一つの防御だけではなく複数レイヤーを組み合わせることがOWASPでも推奨されています。 メールアドレスに直接届く迷惑メール 一方、 info@example.jp など、公開しているメールアドレスへ直接迷惑メールが送られている場合は、問い合わせフォームとは別問題です。 このケースではフォームにCAPTCHAを追加しても解決しません。 メールサーバー側の迷惑メールフィルターや、メールアドレスの公開方法などを確認する必要があります。 まずは、 「フォームから送信されたものなのか、メールアドレスへ直接届いているのか」 を確認しましょう。 問い合わせフォームが狙われる主な原因 問い合わせフォームへのスパムが増える理由には、いくつかあります。 誰でも送信できる公開フォームだから お問い合わせフォームは、基本的にログインせず誰でも利用できます。 正規ユーザーにとって便利である一方、Botから見てもアクセスしやすい場所です。 Bot対策が設定されていない フォームを設置しただけで、 CAPTCHA Honeypot レート制限 WAF などが設定されていない場合、自動送信を繰り返されやすくなります。 同じフォームへ短時間に何度でも送信できる 送信回数に制限がなければ、Botが同じフォームへ大量のリクエストを送ることができます。 OWASPはBot対策においてレート制限を基礎的な防御策の一つと位置付けています。 CMS・プラグインの管理が不十分 WordPressなどのCMSでは、お問い合わせフォームをプラグインで実装することが多くあります。 フォームや関連機能を長期間放置している場合は、スパム対策だけでなく、サイト全体の保守状況も確認した方が安全です。 迷惑メール対策で効果的な7つの方法 迷惑メールを減らすには、一つの対策に頼るのではなく、複数の方法を組み合わせることが重要です。 reCAPTCHA・TurnstileなどのBot対策を導入する 代表的なのが、 Google reCAPTCHA Cloudflare Turnstile などのBot判定サービスです。 GoogleのreCAPTCHA v3では、ユーザーに毎回画像認証をさせるのではなく、操作をスコアで評価し、リスクに応じた処理を行うことができます。 また、Cloudflare Turnstileは、通常のCAPTCHAのような画像選択を常に求めることなく、ユーザーやブラウザの状態からBot判定を行う仕組みを提供しています。 問い合わせフォームでは、 「Botを防ぎたいけれど、本物のお客様にはできるだけ手間をかけさせたくない」 というバランスが重要です。 そのため、サイトの利用者やフォームの重要度に合わせて適切な方式を選びましょう。 Honeypot（ハニーポット）を設置する Honeypotとは、通常のユーザーには見えない入力欄などを用意し、Botだけが入力した場合に送信を拒否する方法です。 人間には追加操作を求めないため、フォームの使いやすさを維持しやすいメリットがあります。 ただしHoneypotだけですべてのBotを防げるわけではありません。 OWASPも、HoneypotやCAPTCHA、レート制限などをアプリケーション層で組み合わせる方法を示しています。 Honeypot＋Bot判定＋送信制限 のように組み合わせる方が効果的です。 短時間の大量送信を制限する 同じ送信元から、 数秒間に何十件も問い合わせが届く のであれば、通常のユーザー行動とは考えにくいでしょう。 そこで有効なのがレート制限（Rate Limiting）です。 たとえば、 同一IPから一定時間内に送信できる回数を制限する フォームへの連続アクセスを制限する 異常な送信パターンを検知して一時的にブロックする といった対策があります。 OWASPもレート制限をBot対策の基礎的なコントロールとして挙げています。ただしIPだけに依存すると回避される可能性もあるため、複数のシグナルを組み合わせる考え方が重要です。 入力内容をサーバー側で検証する お問い合わせフォームでは、 メールアドレス 電話番号 郵便番号 選択項目 お問い合わせ内容 などに適切な入力ルールを設定します。 たとえば電話番号欄に大量のURLや異常に長い文字列が入力されている場合、通常の問い合わせとは考えにくいでしょう。 OWASPは入力値について、形式や長さなどを検証し、セキュリティ上のチェックはブラウザ側だけでなくサーバー側でも実施することを推奨しています。JavaScriptなどクライアント側だけのチェックは回避できるためです。 ポイントは、 「画面上で入力できないようにしたから安心」ではない ということです。 フォームの送信先へ直接リクエストされる可能性も考慮し、サーバー側で確認する必要があります。 WAF・Bot対策を活用する 大量の不正アクセスが続く場合には、フォームだけでなくサイト全体で対策する方法もあります。 代表的なのがWAF（Web Application Firewall）です。 WAFやCDNなどのエッジ側で、 不審なアクセス 異常な送信回数 Botらしい通信 特定条件に一致するリクエスト などを検知・制御します。 OWASPでも、CDN・WAF・Bot対策と、アプリケーション側のレート制限やCAPTCHA等を組み合わせる多層防御が示されています。 問い合わせフォームへのスパムが非常に多いサイトでは、フォーム単体ではなく、サイト全体のアクセス対策まで確認するとよいでしょう。 CMS・プラグインを最新状態に保つ WordPressなどを利用している場合は、 WordPress本体 フォームプラグイン テーマ その他のプラグイン を適切に管理します。 ただし、 「最新にすれば迷惑メールがゼロになる」 わけではありません。 アップデートはサイトを安全に運用するための基本であり、スパム対策とは分けて考えながら、両方を継続することが重要です。 更新前にはバックアップを取得し、更新後はフォーム送信まで正常に動くか確認しましょう。 特定ワードやURLによるフィルタリングは補助的に使う スパムに共通する、 特定の単語 特定ドメイン 大量のURL 不自然な文字列 などを検知して拒否する方法もあります。 ただし、 「この文字が入っていたら全部拒否」 という単純な設定は、正規のお客様までブロックする可能性があります。 OWASPも、禁止ワードだけを並べるようなDenylistだけに依存する方法は回避されやすく、補助的な対策として使うべきとしています。 キーワードフィルターは主役ではなく、CAPTCHA・レート制限などを補う目的で使いましょう。 「CAPTCHAを入れれば安心」ではない理由 問い合わせフォームにスパムが増えたとき、 「とりあえずCAPTCHAを付けよう」 となりがちですが、それだけでは十分とは限りません。 OWASPは、自動化対策について一つのコントロールだけに頼るのは脆弱であり、複数レイヤーを組み合わせるべきとしています。 さらに重要なのが、実装方法です。 たとえばCloudflare Turnstileでは、画面上にウィジェットを表示するだけでは不十分で、発行されたトークンをサーバー側で検証することが必須と公式ドキュメントに明記されています。 GoogleのreCAPTCHA v3でも、取得したスコアやアクションなどをバックエンド側で検証する仕組みになっています。 つまり、 「見た目上CAPTCHAが付いている」＝「正しく守られている」 とは限りません。 導入するときは、制作会社やエンジニアに、 「サーバー側の検証まで実装されていますか？」 と確認すると安心です。 正規ユーザーを取りこぼさないフォーム設計も重要 スパムを完全に止めることだけを考えて対策を強くしすぎると、本物のお客様まで問い合わせできなくなる可能性があります。 たとえば、 何度も画像認証を求められる 少し時間をかけただけで送信できなくなる 海外からのアクセスをすべて拒否する 特定単語が入っただけでエラーになる エラー理由が表示されない といったフォームでは、問い合わせ前にユーザーが離脱してしまいます。 OWASPも、視覚的なCAPTCHAを主たる防御策として過度に頼るのではなく、より負担の少ないリスク判定などと組み合わせる考え方を示しています。 フォーム対策で重要なのは、 「迷惑メールをゼロにすること」ではなく、正規ユーザーの利便性を維持しながら迷惑メールを実用上問題ないレベルまで減らすこと です。 対策後は必ず、 PC iPhone Android 異なるブラウザ などから実際にフォームを送信し、正常に問い合わせできるか確認しましょう。 迷惑メールが急増したときの確認手順 突然フォームスパムが増えた場合は、次の順番で確認すると原因を整理しやすくなります。 ステップ1：本当にフォーム経由か確認する 管理者通知メールの形式などから、ホームページのフォーム経由なのか確認します。 ステップ2：どのフォームから届いているか確認する 複数のフォームがある場合、 お問い合わせ 資料請求 採用応募 見積もり依頼 予約 のどこが狙われているかを確認します。 ステップ3：送信パターンを見る 次のような特徴を確認します。 同じ文章が繰り返されている URLが大量に含まれている 短時間に集中している 同じ送信元から繰り返されている 特定フォームだけ大量に送られている ステップ4：現在のBot対策を確認する reCAPTCHAはあるか Turnstileはあるか Honeypotはあるか レート制限はあるか WAFは有効か などを確認します。 ステップ5：正規フォームの送信テストを行う 対策を変更したら、必ず自分たちでフォーム送信を行います。 「スパムは止まったが、お客様からの問い合わせまで止まった」 という状態は避けなければなりません。 ステップ6：一定期間モニタリングする 対策後、 スパム件数 正常な問い合わせ件数 フォームエラー CAPTCHA・Bot判定の失敗状況 などを確認します。 Cloudflare Turnstileでもチャレンジや検証状況を分析する機能が提供されており、Bot対策は導入して終わりではなく、状況を見ながら調整する考え方が重要です。 WordPressのお問い合わせフォームで確認したいポイント WordPressサイトで迷惑メールが増えている場合は、最低限次を確認しましょう。 どのフォームプラグインを使っているか Bot対策機能が有効になっているか reCAPTCHAやTurnstileが正しく接続されているか Honeypotなどを追加できるか フォームプラグインが更新されているか WordPress本体・テーマも管理されているか サーバー側でWAFが利用できるか 大量送信を制限できるか 特に注意したいのが、 「以前CAPTCHAを入れたから大丈夫だと思っている」 というケースです。 APIキーや設定変更、プラグインの変更などによって正常に機能していない可能性もあるため、実際に現在のフォーム環境を確認しましょう。 また、CAPTCHA系サービスを新しく導入する場合は、利用するサービスの規約やデータの取り扱いを確認し、プライバシーポリシーへの記載が必要かもあわせて確認することをおすすめします。Bot判定ではサービスによってブラウザ情報などが利用されるため、プライバシー面も含めた選定が重要です。 問い合わせフォームのスパム対策チェックリスト 迷惑メールが増えてきたら、次の項目を確認してください。 フォーム経由のスパムか確認したか どのフォームが狙われているか特定したか reCAPTCHA・Turnstileなどを導入しているか Bot判定をサーバー側でも検証しているか Honeypotを利用できるか 同一送信元からの大量送信を制限しているか WAF・Bot対策を利用しているか 入力値をサーバー側でも検証しているか フォームプラグインを最新状態にしているか WordPress・CMS本体を適切に管理しているか キーワード拒否だけに頼っていないか 対策後にPC・スマートフォンから送信テストをしたか 正常な問い合わせまでブロックしていないか スパム件数を対策前後で比較しているか 導入サービスのプライバシー条件を確認したか すべてを一度に導入する必要はありません。 まずは、 Bot判定 → Honeypot → レート制限 → WAF・監視 というように、現在のスパム量やサイト規模に合わせて対策を追加していきましょう。 まとめ：一つの対策ではなく“多層防御”で守る 問い合わせフォームの迷惑メールは、ホームページを運用していれば発生する可能性があります。 重要なのは、 「迷惑メールが届いたから危険」 と慌てるのではなく、原因を切り分けて必要な対策を行うことです。 基本的な考え方は、 Bot判定を導入する Honeypotを組み合わせる 大量送信をレート制限する 入力内容をサーバー側でも検証する 必要に応じてWAFを活用する CMS・プラグインを適切に保守する 正規ユーザーが問い合わせできるか必ず確認する という流れです。 現在のBot対策では、一つの仕組みだけにすべてを任せるのではなく、複数の防御を組み合わせる「多層防御」が基本的な考え方です。 そして、もう一つ忘れてはいけないのが、 お問い合わせフォームは“守るため”だけでなく、“問い合わせを受けるため”に存在する ということです。 セキュリティを高めながらも、ユーザーに余計な負担をかけないフォームを目指しましょう。 無料相談 Refuでは、ホームページ制作だけでなく、既存サイトのお問い合わせフォーム確認、WordPress・プラグインの保守、Bot対策、WAFなども含めて運用環境を確認しています。 「突然迷惑メールが増えた」「CAPTCHAを入れているのにスパムが止まらない」「本物のお問い合わせまで止めてしまわないか不安」といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら SSL（https）って何？ホームページの信頼性とSEOに必須な理由 ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本 ホームページの保守・更新費用の相場｜何が含まれて何が別料金？ ホームページの表示速度を改善する方法｜Core Web Vitalsと画像最適化の基本
2026/08/10
ホームページ制作の基本404エラーとは？ホームページで起きる原因と正しい対処法
404エラーとは？「ページが見つからない」を示すステータス ホームページを見ていると、 「404 Not Found」「お探しのページが見つかりません」 という画面が表示されることがあります。 これは、アクセスされたURLに対応するページがサーバー上に存在しないことを示すものです。 Webサーバーは、ブラウザや検索エンジンからアクセスを受けると、「正常に表示できた」「ページが存在しない」などの状態をHTTPステータスコードで返します。 その中で404は「要求されたページが見つからない」状態を示すコードです。 Googleも、すでに削除され、同じ内容の代替ページが存在しない場合には、404または410のステータスコードを返すことを案内しています。つまり、404が表示されること自体が必ずしも異常というわけではありません。 重要なのは、 「なぜ404になっているのか」「その404を直す必要があるのか」 を判断することです。 404エラーが発生する主な原因 404が発生する原因は一つではありません。 ホームページ運用でよくあるのは、次のケースです。 ページを削除した ブログ記事やサービスページなどを削除すると、そのURLへアクセスした際に404になります。 ページのURLを変更した たとえば、 /service-web/ だったURLを、 /web-production/ へ変更したにもかかわらず、旧URLから新URLへの転送設定をしていない場合です。 内部リンクのURLを間違えている メニューや記事内リンクの入力ミスでも404は発生します。 たとえば、 /service/ へリンクするつもりが、 /servise/ となっているケースです。 リニューアルでURL構造を変更した ホームページリニューアルでは、サイト構造を整理するためにURLを変更することがあります。 このとき旧URLへの対応をしていないと、検索結果や外部サイトからアクセスしたユーザーが404ページへ到達してしまいます。 外部サイトに古いURLが掲載されている 自社サイトを修正しても、 ポータルサイト SNS 過去のプレスリリース 他社ブログ メディア記事 などに古いURLが残っているケースがあります。 この場合も、旧URLが適切に処理されていなければ404になります。 404エラーがあるとSEOに悪影響？ 「404があるとGoogleから評価を下げられるのでは？」 と心配する方も多いでしょう。 しかし、404が存在すること自体を過度に恐れる必要はありません。 ページを削除し、代わりとなるページも存在しないのであれば、404または410を返すのはGoogleが案内している正しい処理です。 問題なのは、本来ユーザーに見せるべきページが404になっているケースです。 たとえば、 検索結果に表示されている重要ページが404 サイト内のメニューから404へリンクしている 外部サイトから多くリンクされているページを削除した リニューアル後に旧ページが大量に404になった といった状態です。 この場合、検索エンジン以前に、ユーザーが必要な情報へ到達できません。 したがって404対策では、 「404をゼロにする」 のではなく、 「ユーザーが本来到達すべきページを404にしない」 という考え方が重要です。 404のままで問題ないケース・修正すべきケース 404を見つけたからといって、すべてリダイレクトすればいいわけではありません。 ページの状態によって対応を変えます。 削除して代替ページがない→404または410 たとえば、 終了したキャンペーン 廃止したサービス 古くなり完全に不要になったページ などで、ユーザーを案内できる代替ページが存在しない場合です。 この場合は、無理に別ページへ転送せず、404または410を返す方法が適切です。 Googleも、削除済みで同様のコンテンツを持つ代替ページがない場合には、404または410を返すことを案内しています。 つまり、 「404＝必ず修正しなければならない」 ではありません。 ページを別URLへ移動した→301リダイレクト ページそのものは残っているものの、URLだけ変更した場合は対応が変わります。 たとえば、 旧URL：/old-service/ 新URL：/service/ へ移動したのであれば、旧URLから新URLへ301リダイレクトを設定します。 Googleも、ページが移動した場合や明確な代替ページが存在する場合には、301によって適切なページへリダイレクトすることを推奨しています。 301リダイレクトによって、 古いURLから来たユーザーを新ページへ案内できる ページの新しい場所を検索エンジンに伝えられる というメリットがあります。 URL変更やリンク設定のミス→リンクを修正 単純なリンクミスで404が起きている場合は、リダイレクトではなくリンクそのものを修正するのが基本です。 たとえば、 × /servise/○ /service/ という間違いであれば、内部リンクを正しいURLへ変更します。 特に確認したいのは、 グローバルメニュー フッターメニュー CTA ブログ記事内リンク バナー パンくずリスト などです。 ユーザーがよく利用する導線ほど、優先して修正しましょう。 注意したい「soft 404」とは？ 404対策で知っておきたいのが、soft 404（ソフト404）です。 通常の404では、サーバーが「このページは存在しません」という意味の404ステータスコードを返します。 一方soft 404では、 画面上では「ページがありません」と表示しているのに、サーバーは「200 OK＝正常なページです」と返している といった矛盾が発生しています。 Googleは、存在しないページが200のステータスを返している場合や、メインコンテンツがほとんどないページなどをsoft 404として認識することがあります。該当ページはSearch Consoleのインデックス登録レポートでsoft 404として表示される場合があります。 たとえば、 「商品がありません」 とだけ書かれているのに、正常なページとして200を返しているケースです。 soft 404が発生した場合は、 本当にページが存在しない→404または410 新しいページへ移動した→301 本来存在するページ→表示エラーや読み込み問題を修正 というように、ページの状態に合わせて対応します。 ユーザーを離脱させない404ページの作り方 正しい404を返していても、 「404 Not Found」 とだけ表示されているページでは、ユーザーは次に何をすればいいか分かりません。 そこでおすすめなのが、カスタム404ページです。 Googleも、404ページを分かりやすくカスタマイズし、ユーザーが他のコンテンツを探せるようにすることを案内しています。 最低限、次の要素を入れましょう。 ページが見つからないことを明確に伝える 例： 「お探しのページは見つかりませんでした。」 専門用語ではなく、ユーザーに分かりやすい表現にします。 トップページへのリンク まず戻れる場所を用意します。 👉 トップページへ戻る 主要サービスへのリンク 企業サイトなら、 サービス一覧 料金 制作事例 お問い合わせ などへ誘導すると、離脱防止につながります。 人気記事・おすすめコンテンツ オウンドメディアなら、 「よく読まれている記事」 を表示するのも有効です。 Googleも、人気のある記事やホームページへのリンクを404ページに追加する方法を案内しています。 サイト全体とデザインを統一する 突然真っ白なエラー画面になるのではなく、通常ページと同じヘッダー・フッター・デザインを使用します。 ただし重要なのは、見た目を通常ページのようにしても、サーバーは正しく404ステータスコードを返すことです。Googleもカスタム404ページについて、検索エンジンにインデックスされないよう404を返すよう案内しています。 404エラーを見つける方法 404はユーザーから指摘される前に、定期的に確認することが重要です。 Search Consoleを確認する Google Search Consoleでは、インデックス登録状況などから404やsoft 404に関連する問題を確認できます。 特定URLについて詳しく確認したい場合には、URL検査ツールでGoogleが取得した状態やHTTPレスポンスを確認する方法もあります。Googleもsoft 404やリダイレクトの確認にURL検査ツールを案内しています。 サイト内リンクをチェックする 特に、 サイトリニューアル後 URL変更後 古い記事を大量に整理した後 はリンク切れが発生しやすくなります。 重要ページから順番に確認しましょう。 GA4で404ページへのアクセスを見る 404ページにアクセス解析を入れておけば、 「実際にユーザーがどのくらい404ページへ到達しているか」 を確認できます。 大量にアクセスされている404があれば、検索結果・外部リンク・内部リンクなど、どこからアクセスされているかを調査することで優先順位を付けやすくなります。 リニューアル時に404を大量発生させないための対策 404対策で特に重要なのが、ホームページリニューアルです。 リニューアルでは、 URL構造を変更する ページを統合する 不要ページを削除する カテゴリを整理する といった作業が発生します。 ここで旧URLを整理せず公開すると、検索結果や外部サイトに残っている旧URLからアクセスしたユーザーが404へ到達してしまいます。 リニューアル前に、次のようなURL対応表を作成しておくと安全です。 旧URL → 新URL 例： /old/service-a/ ↓/service/service-a/ 移動先が明確なページは301リダイレクトを設定し、完全に廃止して代替ページもないものは404または410として処理します。これはGoogleが現在案内している考え方とも一致します。 また、リダイレクトはGoogleに対して新しい正規URLを伝える強いシグナルの一つとされています。 404対応でよくあるNG例 NG1：404をすべてトップページへ転送する ページがなくなったからといって、何でもトップページへ飛ばせばいいわけではありません。 ユーザーが探していた内容とトップページが無関係なら、かえって混乱させます。 明確な代替ページがある場合のみ301、ない場合は404または410 と判断するのが基本です。 NG2：削除したページを何でも301する 「SEO評価を失いたくない」という理由だけで、無関係なページへリダイレクトするのもおすすめできません。 サービスAの記事を、内容がまったく違うサービスBへ転送しても、ユーザーの検索意図を満たせないからです。 NG3：見た目だけ404にする 「ページがありません」と表示しているのに200 OKを返していると、soft 404として扱われる可能性があります。 カスタム404ページを作る場合も、HTTPステータスコードは正しく404を返す必要があります。 NG4：404を一件見つけるたびに慌てて直す 存在して当然の404もあります。 たとえば、ユーザーがURLを打ち間違えれば、存在しないURLへの404が発生します。 すべてを修正対象にするのではなく、 「本来存在すべきURLか？」「ユーザーが実際にアクセスしているか？」「代替ページがあるか？」 で優先順位を判断しましょう。 404エラー改善チェックリスト 404が見つかったら、次の順番で確認すると判断しやすくなります。 そのURLは本来存在するページか ページを削除したのか、移動したのか 代替となるページがあるか 代替ページがあるなら301を設定したか 代替ページがないなら404または410を返しているか 内部リンクから404へリンクしていないか Search Consoleで問題を確認したか soft 404になっていないか 404ページ自体が200を返していないか カスタム404ページにトップへの導線があるか サービス・記事など関連コンテンツへの導線があるか リニューアル時に旧URL→新URLの対応表を作ったか 特に優先すべきなのは、 「検索や内部リンクから多くアクセスされている404」 です。 ユーザーへの影響が大きいものから対応しましょう。 まとめ：404は全部消すのではなく「正しく処理する」 404エラーは、ホームページに存在してはいけないものではありません。 ページを削除し、代替ページも存在しないのであれば、404または410を返すこと自体が正しい対応です。 大切なのは、 ページがなくなった→404または410 ページが移動した→301リダイレクト リンクを間違えた→リンクを修正 正常ページなのにsoft 404→表示・読み込みを修正 404ページには次の行動につながる導線を設置 というように、原因ごとに正しく処理することです。 特にホームページリニューアルでは、URL変更による404が大量に発生しないよう、公開前に旧URLと新URLを整理することが重要です。 SEOだけを見るのではなく、 「ユーザーが探している情報へきちんとたどり着けるか」 という視点で404を管理しましょう。 無料相談 Refuでは、ホームページリニューアル時のURL整理・301リダイレクト設計・Search Console確認まで含めて、既存サイトのSEO資産をできるだけ活かしたサイト移行をサポートしています。 「リニューアルすると検索順位が落ちないか心配」「Search Consoleに404がたくさん出ているけれど、どこまで直せばいいか分からない」といった段階からでもお気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック SEOの前に整える「サイト構造」｜カテゴリ設計・URL・内部リンクの基本 リニューアル判断の基準｜いつ、何を、どこまで変えるべきか Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方 ドメイン・サーバーの選び方｜初心者でも失敗しない基礎知識と注意点
