COLUMN
よく検索されるキーワード
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/08
リニューアル・運用ノウハウホームページのバックアップは必要？保存頻度・範囲・復元方法を解説
ホームページのバックアップはなぜ必要？ ホームページは、一度公開したら同じ状態が永久に維持されるわけではありません。 例えば、 WordPressの更新 プラグインの更新 記事・画像の追加 プログラム修正 サーバー設定変更 担当者による操作 など、日々さまざまな変更が行われます。 その中で不具合や操作ミスが発生した場合、元の状態に戻すために必要なのがバックアップです。 バックアップがあれば、 更新前の状態へ戻す消してしまったデータを復元するサイト改ざん前の状態へ戻すサーバートラブルから復旧する といった対応ができます。 逆に、バックアップがなければ、過去の状態を再現できず、サイトを一から作り直さなければならない可能性もあります。 バックアップが必要になる代表的なトラブル ホームページでバックアップが必要になる原因は、サーバー障害だけではありません。 例えば、 WordPress更新後にサイトが表示されなくなったプラグイン同士が干渉してエラーが発生した誤ってページや画像を削除したコード修正でレイアウトが崩れた不正アクセスによってファイルを書き換えられたデータベースが破損したサーバー移行時にデータが欠損した などがあります。 つまりバックアップは、「もしサーバーが壊れたら」という特殊なケースだけの対策ではありません。 普段の更新作業そのものに伴うリスクを減らすための運用対策です。 WordPressは「ファイル」と「データベース」の両方を保存する WordPressサイトで特に理解しておきたいのが、バックアップ対象です。 WordPress公式ドキュメントでは、WordPressサイトのバックアップは大きくファイルとデータベースの2つに分かれると説明されています。 完全に復元するためには、一般的に両方が必要です。 ファイルに保存されているもの WordPressのファイルには、例えば次のようなものがあります。 WordPress本体 テーマ プラグイン アップロードした画像・PDF JavaScript・PHPなどのプログラム 設定ファイル 独自に追加したファイル 特に、 wp-contentwp-config.php などは、サイト固有の設定・画像・テーマ・プラグインと深く関係します。 WordPress公式でも、サイトのファイルとデータベースは別々に保存されており、ファイルをダウンロードしただけでは通常データベースまでバックアップされないと説明されています。 データベースに保存されているもの データベースには、主に次のような情報が保存されています。 投稿 固定ページ コメント WordPress設定 プラグイン設定 ユーザー情報 フォームやシステムによって保存されたデータ WordPress公式でも、投稿やページなど多くのコンテンツはデータベース側に保存されるため、定期的なデータベースバックアップが推奨されています。 片方だけでは完全復元できない場合がある 例えば、 ファイルだけバックアップ→ デザインや画像は戻せても投稿内容が戻らない データベースだけバックアップ→ 記事は戻っても画像・テーマ・プログラムが不足する という可能性があります。 そのため、基本的には、 同じタイミングの「ファイル＋データベース」を1セットとして管理する ことが重要です。 WordPress公式も、ファイルとデータベースを同じバックアップセットとして扱う方法を案内しています。 バックアップ頻度はどのくらいが適切？ バックアップ頻度に「すべてのサイトで毎日が正解」という決まりはありません。 重要なのは、 「どこまでデータが失われても許容できるか」 から逆算することです。 更新頻度が低い企業サイト 月に数回程度しか更新しないコーポレートサイトであれば、 定期バックアップ＋サイト更新前後のバックアップ という設計でも対応できる場合があります。 例えば、 週次 月次 更新作業前 など、サイトの更新頻度に合わせて設定します。 ブログ・お知らせを頻繁に更新するサイト 毎日のように記事を投稿するサイトでは、バックアップ頻度も高める必要があります。 仮に1週間に1回しかバックアップしていなければ、障害発生時に最大1週間分の記事更新を失う可能性があります。 そのため、 毎日更新する↓毎日バックアップする というように、更新頻度を基準に考えると分かりやすくなります。 EC・予約・会員サイトなどデータ更新が多いサイト ECサイトや予約システムでは、 注文情報 顧客情報 予約情報 会員データ などが継続的に増えていきます。 このようなサイトでは、「1日前の状態に戻せればよい」とは限りません。 バックアップ頻度だけでなく、 どの時点までデータ損失を許容できるか まで含めて、より慎重に設計する必要があります。 WordPress・プラグイン更新前は別途取得する 定期バックアップとは別に、重要な作業前にはバックアップを取得しておくと安全です。 特に、 WordPress本体の更新 プラグイン更新 テーマ更新 PHPバージョン変更 大規模なページ修正 プログラム改修 などです。 WordPress公式も、データベースについて定期的なバックアップに加え、アップグレード前にバックアップすることを強く推奨しています。 問題が起きた場合に、 「変更直前の状態」 へ戻せるようにしておくことが重要です。 「世代管理」が重要｜最新バックアップ1つだけでは危険 バックアップでは、最新ファイルを1つだけ保存するのではなく、複数世代を残すことが重要です。 例えば、サイトが改ざんされていたものの、1週間気づかなかったとします。 毎日バックアップしていても、 昨日のバックアップだけ保存↓昨日のデータもすでに改ざん済み なら、正常な状態へ戻せません。 そこで、 昨日 3日前 1週間前 1か月前 など、複数の時点を残しておく世代管理が役立ちます。 具体的な保存期間・世代数は、 更新頻度 データ量 サイトの重要性 保管コスト によって決めます。 バックアップはどこに保存する？3-2-1の考え方 バックアップは、サイトと同じサーバーだけに保存するのではなく、別の保管先にも持つことが重要です。 バックアップ設計では「3-2-1ルール」と呼ばれる考え方があります。 3：重要なデータを3つ持つ（本番＋バックアップ2つ）2：異なる種類・環境の媒体に保存する1：そのうち1つを別拠点・オフサイトに保存する CISAのバックアップ資料でも、データ消失・破損からの復旧可能性を高める方法として3-2-1ルールが紹介されています。 ホームページであれば、例えば、 本番サーバー↓サーバー会社のバックアップ↓別クラウド・別ストレージ というように、同じ障害で全部消えない構成を考えます。 サーバー会社の自動バックアップだけで十分？ レンタルサーバーには、自動バックアップ機能が付いていることがあります。 非常に便利な機能ですが、 「サーバー会社がバックアップしているから何もしなくていい」 とは限りません。 確認したいのは、 何日前まで保存されるか ファイルとデータベースの両方が対象か 復元操作を誰が行えるか 復元に追加料金が必要か バックアップ対象外のデータはないか 障害時に利用できる保証範囲はどこまでか です。 サーバー会社によって条件は異なります。 特に企業サイトでは、契約しているサーバーのバックアップ仕様を一度確認しておくことをおすすめします。 バックアップから復元できる状態か確認する バックアップ運用で最も重要なのは、 「データがあること」ではなく「実際に戻せること」 です。 復元対象を確認する トラブルの内容によって、戻す範囲は異なります。 画像を1枚削除した→ ファイルだけ復元 記事を削除した→ データベース側の復元が必要になる可能性 サイト全体が改ざんされた→ ファイル・データベースの両方を確認 というように判断します。 復元ポイントを判断する 「最新バックアップへ戻せばよい」とは限りません。 不具合や改ざんが発生した時点を調べ、 問題が発生する前の正常なバックアップ を選ぶ必要があります。 そのためにも、複数世代の保存が重要です。 復元後にサイトを確認する 復元が完了しても、それで終了ではありません。 トップページ 主要サービスページ 画像 問い合わせフォーム WordPress管理画面 SSL リンク 計測タグ などが正常に動作するか確認します。 データベースを復元した場合、バックアップ取得後に追加された記事・問い合わせデータ等が失われていないかも確認が必要です。 定期的に復元テストを行う バックアップファイルが存在していても、 データが破損している 必要なファイルが含まれていない 復元方法が分からない 担当者が退職して手順が分からない というケースがあります。 そのため重要なサイトでは、テスト環境などを使って復元できることを定期的に確認するのが理想です。 バックアップは、復元できて初めて意味があります。 バックアップ運用でよくある失敗 サーバー内にしかバックアップがない サーバー自体に障害が起きると、本番データとバックアップを同時に失う可能性があります。 ファイルだけ保存してデータベースを保存していない WordPressではファイルとデータベースが別管理です。 最新1世代しか保存していない 不具合に気づくのが遅れた場合、正常な時点まで戻せない可能性があります。 自動バックアップを設定しただけで確認していない 容量不足や設定ミスで、実際にはバックアップが取れていないケースも考えられます。 復元方法を誰も知らない 緊急時に手順確認から始めると、サイト停止時間が長くなります。 バックアップと保守契約の範囲が曖昧 「バックアップされていると思っていた」「復元まで保守費用に含まれると思っていた」という認識違いは、事前に防ぐ必要があります。 保守契約で確認しておきたいバックアップ範囲 制作会社や保守会社へサイト管理を依頼している場合は、契約時にバックアップ条件を確認しましょう。 最低限確認したいのは、 バックアップの有無 取得頻度 保存世代数・保存期間 ファイルとデータベースの両方が対象か 外部保存の有無 障害発生時の復元作業が契約内か 復元対応可能な時間帯 復元作業に別途費用が発生するか です。 「保守契約＝必ずバックアップ・復元まで含まれる」とは限りません。 契約書・見積書で対応範囲を明文化しておくことが、制作会社とクライアント双方のトラブル防止につながります。 個人情報を含むバックアップの管理にも注意する バックアップはセキュリティ対策である一方、バックアップデータ自体が情報漏えいの原因になる可能性もあります。 特に、 問い合わせ内容 顧客情報 会員情報 注文情報 採用応募情報 などをデータベースに保存しているサイトでは、バックアップにも同じ情報が含まれる可能性があります。 そのため、 誰がアクセスできるか どこへ保存するか 不要になったデータをどう削除するか クラウドストレージを適切に管理しているか まで考える必要があります。 例えば、バックアップファイルを誰でもアクセスできるWeb公開領域へ置くような運用は避けるべきです。 「バックアップだから安全」ではなく、バックアップも重要な情報資産として管理することが大切です。 ホームページバックアップチェックリスト 保存対象 WordPressファイルをバックアップしている データベースもバックアップしている 画像・PDFなどアップロードデータが含まれている 独自プログラム・設定ファイルも対象になっている 頻度 サイトの更新頻度に合わせて取得している 重要な更新作業前にバックアップしている WordPress・プラグイン更新前に取得している 許容できるデータ損失期間から頻度を決めている 世代・保管 複数世代を保存している 本番サーバー以外にも保存している バックアップ保存先の容量を確認している バックアップデータへのアクセス権限を管理している 復元 復元方法が決まっている 誰が復元を担当するか決まっている 正常なバックアップを判断できる 復元後の確認項目を決めている 必要に応じて復元テストを実施している 契約・運用 サーバー会社のバックアップ仕様を確認している 制作・保守会社の対応範囲を確認している 復元費用の有無を確認している 保存期間・世代数が明確になっている 個人情報を含むバックアップを適切に管理している まとめ：バックアップは「取れている」ではなく「戻せる」ことが重要 ホームページのバックアップは、サーバー障害だけではなく、 操作ミスWordPress・プラグイン更新の不具合サイト改ざんデータベース破損サーバー移行トラブル など、さまざまなリスクに備えるために必要です。 特にWordPressでは、ファイルとデータベースの両方をバックアップすることが基本です。 そして、 更新頻度に合わせて取得する複数世代を残す本番サーバーとは別の場所にも保存する重要な作業前にバックアップする実際に復元できる状態を確認する という運用まで設計しておきましょう。 バックアップで最も重要なのは、 「バックアップファイルが存在すること」ではなく、「トラブル時に必要な状態へ戻せること」 です。 ホームページを事業の重要な窓口として利用しているのであれば、バックアップも日常的なサイト運用の一部として考えておくことをおすすめします。 WordPressのバックアップ・保守ならRefuへ Refuでは、WordPressサイトの保守・運用に加え、バックアップ環境の確認、サーバー設定、WordPress更新前のバックアップ、障害発生時の復旧などにも対応しています。 「現在バックアップが取れているのか分からない」「サーバー会社の自動バックアップだけで大丈夫か確認したい」「万が一のときに復元できる体制を整えたい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 保守契約とは？制作後に必要な運用サポートの種類と相場 SSL対応は本当に必要？セキュリティと信頼性の関係 セキュリティ最低限チェックリスト｜改ざん・乗っ取りを防ぐ運用習慣 フォームスパム対策まとめ｜reCAPTCHAだけに頼らない防止策 リニューアル後の改善ロードマップ｜公開後90日でやるべき施策チェックリスト
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/01
リニューアル・運用ノウハウWebアクセシビリティ改善の基本｜企業サイトで見直すべきポイント
Webアクセシビリティとは？誰でも情報を利用しやすくする考え方 Webアクセシビリティとは、年齢や障害の有無、利用している端末や操作方法などにかかわらず、できるだけ多くの人がWebサイトの情報や機能を利用できる状態にすることです。 例えば、Webサイトを見る人の中には、 視覚に障害があり、画面読み上げソフトを利用している人 マウスを使わずキーボードで操作する人 色の違いを判別しにくい人 小さな文字が読みづらい人 動画の音声を聞くことができない環境にいる人 スマートフォンの小さな画面を利用している人 など、さまざまなユーザーがいます。 W3Cが策定するWCAG（Web Content Accessibility Guidelines）は、Webコンテンツを障害のある人を含め、より利用しやすくするための国際的なガイドラインです。WCAG 2.2は、W3C Recommendationとして公開されています。 アクセシビリティ改善は、「一部の人だけのための特別対応」ではありません。 文字を読みやすくするボタンを押しやすくするフォームの入力方法を分かりやすくするページ構造を整理する といった改善は、多くのユーザーにとって使いやすいサイトづくりにもつながります。 なぜ企業サイトでもアクセシビリティが重要なのか Webアクセシビリティというと、行政機関や大企業だけが取り組むものと思われることがあります。 しかし、企業サイトでも、 問い合わせ 資料請求 採用応募 予約 商品・サービス情報の確認 など、Webサイトが事業と直接つながる場面が増えています。 もし「文字が読めない」「キーボードでフォームを操作できない」「ボタンがどこにあるか分からない」という理由で利用できなければ、ユーザーに必要な情報を届けられません。 デジタル庁も、行政機関だけでなく事業者を含む初心者向けに「ウェブアクセシビリティ導入ガイドブック」を公開し、アクセシビリティ改善の考え方や実践方法を案内しています。 また、日本では2024年4月1日から、障害者差別解消法に基づく事業者による合理的配慮の提供が義務化されています。 ただし、これは「すべての民間Webサイトが直ちに特定のWCAG適合レベルを満たさなければならない」という意味ではありません。 個別の場面や状況、事業者への負担などを踏まえながら、必要な対応を検討することが求められます。 WCAG・JIS X 8341-3とは？最低限知っておきたい基準 Webアクセシビリティを調べると、 WCAGJIS X 8341-3 という言葉がよく出てきます。 WCAGはW3Cが策定する国際的なWebアクセシビリティガイドラインで、達成基準には主にA・AA・AAAという適合レベルがあります。 日本では、Webコンテンツのアクセシビリティに関する規格としてJIS X 8341-3:2016が利用されています。 デジタル庁のアクセシビリティ方針や検証でも同規格が参照されており、WAIC（ウェブアクセシビリティ基盤委員会）も対応度表記や試験などに関するガイドラインを公開しています。 企業サイトを改善する際に、最初からすべての基準を完璧に理解する必要はありません。 まずは、ユーザーが利用できなくなる可能性の高い問題から改善することが現実的です。 改善ポイント①：文字と背景のコントラストを確保する デザイン性を重視するあまり、 薄いグレーの文字 淡い背景色＋白文字 写真の上に細い白文字 などを使用すると、文字が読みにくくなることがあります。 WCAG 2.2の達成基準1.4.3では、通常サイズのテキストについて、背景とのコントラスト比を原則4.5：1以上とする基準が設けられています。大きな文字には別の基準があります。 特に確認したいのは、 本文 グローバルメニュー CTAボタン フォームラベル リンク文字 画像上のコピー です。 「ブランドカラーだから変えられない」と考えるのではなく、ロゴなどのブランド表現と、実際に操作・閲覧するUIの色を分けて考える方法もあります。 おしゃれに見えるかだけでなく、きちんと読めるかまで確認することが重要です。 改善ポイント②：画像に適切な代替テキスト（alt）を設定する 画像には、必要に応じて代替テキスト（alt属性）を設定します。 代替テキストは、画像を見ることができないユーザーに対して、画像が伝えている情報をテキストとして補う役割があります。 例えば施工事例の画像であれば、 ×「写真」×「施工事例」 だけではなく、 「相模原市の工場で施工したステンレス配管」 など、画像から伝える必要がある情報を簡潔に記述します。 一方で、単なる背景装飾や意味を持たない画像まで、すべて詳しく説明する必要はありません。 ポイントは、 「その画像が表示されなかった場合、ユーザーへどの情報を補う必要があるか」 で判断することです。 画像やアイコンなどの視覚情報について、適切なテキスト代替を用意することは、Webアクセシビリティの基本的な考え方の一つです。 改善ポイント③：キーボードだけでも操作できるようにする Webサイトは、マウスだけで利用されているわけではありません。 Tabキーなどを使い、キーボードだけでWebサイトを操作するユーザーもいます。 確認したいのは、 グローバルメニューを開けるか リンクへ移動できるか フォームへ入力できるか モーダルを閉じられるか CTAボタンを操作できるか です。 実際にマウスを使わず、 「Tabキーだけでトップページから問い合わせフォームまで移動できるか」 を確認すると、問題を発見しやすくなります。 また、キーボードで現在どこを選択しているのか分かるフォーカス表示も重要です。 デザイン上の理由だけでフォーカス表示を消してしまうと、キーボード利用者が現在位置を把握できなくなる可能性があります。 ブランドイメージに合った形で、見やすいフォーカス表示を用意しましょう。 改善ポイント④：ボタン・リンクを押しやすく、意味が伝わる設計にする スマートフォンでは、ボタンが小さかったり、間隔が狭かったりすると押し間違いが発生します。 WCAG 2.2では、一定の例外を除き、操作対象について24×24 CSSピクセル以上、または同等の間隔を確保することを求める「Target Size (Minimum)」というAAレベルの達成基準が追加されています。 ただし、 「すべて24pxにすれば対応完了」 と機械的に考えるのではなく、 十分に押しやすいか 隣のボタンを誤って押さないか スマートフォンで操作しやすいか を実機で確認することが重要です。 また、リンクテキストも、 ×「詳しくはこちら」 だけではなく、 「ホームページ制作サービスについて詳しく見る」 のように、移動先が分かる表現にすると理解しやすくなります。 改善ポイント⑤：見出し構造を正しく設計する Webページの見出しには、 h1 h2 h3 h4 などのHTML見出しがあります。 これらは文字を大きくするためだけの機能ではなく、ページの情報構造を表すものです。 例えば、 h1：Webアクセシビリティ改善の基本h2：企業サイトで改善すべきポイントh3：文字色のコントラスト のように、内容の階層に合わせて設定します。 見出し構造を整えることで、 ページを拾い読みする人 スクリーンリーダーを利用する人 サイトを更新する担当者 にとっても、内容を理解しやすくなります。 見出しの見た目だけを変えるのではなく、情報の意味に合わせて適切なHTML要素を使うことが重要です。 改善ポイント⑥：問い合わせフォームを使いやすくする 企業サイトでは、問い合わせフォームのアクセシビリティが特に重要です。 どれだけサービス情報が分かりやすくても、最後のフォームを利用できなければ問い合わせにつながりません。 確認したいポイントは、 各入力欄に何を入力するか分かるラベルがある 必須・任意が分かる エラーの原因が具体的に分かる 色だけでエラーを表現していない キーボードだけでも入力・送信できる 入力欄の順番が自然になっている ことです。 例えば、 ×「入力内容にエラーがあります」 だけでは、ユーザーはどこを修正すればよいか分かりません。 「メールアドレスを正しい形式で入力してください。例：info@example.com」 など、問題と修正方法が分かる表現にします。 アクセシビリティ改善は、結果的に問い合わせフォームの入力離脱を減らす改善とも共通する部分が多くあります。 改善ポイント⑦：動画・音声コンテンツにも情報を補う 企業サイトでも、 会社紹介動画 採用インタビュー 施工動画 サービス説明動画 などを掲載するケースが増えています。 動画で重要な情報を伝えている場合は、音声を聞けないユーザーにも内容が伝わるように、字幕やテキスト情報を用意することを検討します。 一方、音声だけでは伝わらない重要な視覚情報がある場合には、その情報をどのように補うかも考える必要があります。 重要なのは、 「動画を再生できること」ではなく、「動画の中にある情報へアクセスできること」 です。 動画だけに重要情報を閉じ込めず、必要に応じてテキストでも確認できる状態を整えましょう。 改善ポイント⑧：スマートフォン・拡大表示でも崩れないか確認する アクセシビリティ確認では、PCの標準サイズだけを見るのでは不十分です。 例えば、 文字を拡大する スマートフォンを使う 画面幅を狭くする といった環境でも、情報を利用できるか確認します。 レスポンシブ対応していても、 ボタンが重なる テキストが切れる メニューが押せない 横スクロールしないと読めない といった問題が残っている場合があります。 リニューアル時には、デザインカンプ上の確認だけでなく、実際のスマートフォンやブラウザで操作するところまで確認することが大切です。 企業サイトでアクセシビリティを確認する方法 アクセシビリティは、自動チェックツールだけですべて確認できるものではありません。 おすすめは、 ① 自動チェック↓② 手動チェック↓③ 実際の操作確認 を組み合わせる方法です。 例えば、 コントラストチェックツール ブラウザのアクセシビリティ機能 HTML・altの確認 キーボード操作 画面拡大 スマートフォン実機確認 必要に応じてスクリーンリーダーでの確認 などを組み合わせます。 特に、 「リンクの意味が分かるか」「操作する順番が自然か」「エラーが起きたときに修正方法が分かるか」 といった内容は、自動チェックだけでは十分に判断できません。 また、JIS X 8341-3への「準拠」など正式な対応度を表明する場合は、単なる自動チェックだけでなく、対象範囲を定めた試験や結果の公開など、必要な手順を確認することが重要です。 リニューアル時にアクセシビリティを組み込むメリット 既存サイトへ後からアクセシビリティ対応を追加するより、リニューアルの設計段階から考える方が効率的です。 例えば、 ブランドカラーを決める時にコントラストを確認する ワイヤーフレームで見出し階層を整理する ボタン設計時にサイズやフォーカスを確認する CMS設計時に画像altを入力できるようにする フォーム開発時にラベル・エラー表示を設計する といった形で最初から組み込めます。 完成後に、 「このブランドカラーでは文字が読みにくい」「このメニューはキーボード操作できない」「CMSからaltを設定できない」 と判明すると、修正範囲が大きくなります。 そのためアクセシビリティは、公開前だけ確認する項目ではなく、要件定義・デザイン・実装・運用のすべてに関係する品質要件として考えるのがおすすめです。 アクセシビリティ対応でよくある誤解・失敗 「高齢者向けサイトだけ対応すればよい」と考える アクセシビリティは特定のユーザーだけを対象にしたものではありません。 スマートフォン利用、一時的なけが、騒音環境、明るい屋外での閲覧など、さまざまな状況で使いやすさにつながります。 デザイン性が下がると思い込む コントラストや文字サイズを確保しながら、ブランドイメージを表現することは可能です。 アクセシビリティを制約として後から加えるのではなく、デザイン要件として最初から組み込むことが重要です。 altをすべての画像に長文で入れる 重要なのは量ではなく、その画像が持つ意味を適切に補うことです。 装飾画像まで長い説明を読み上げさせると、かえって利用しにくくなる場合があります。 自動チェックツールでエラー0なら完了と考える 自動ツールだけでは、 リンク文言が分かりやすいか 操作順序が自然か コンテンツの意味が伝わるか といった文脈までは十分に判断できません。 手動確認も必要です。 「法律対応済み」と安易に表現する 障害者差別解消法による合理的配慮の義務化と、特定のWCAG・JIS適合レベルは同じものではありません。 個別の法的義務や適合表明については、対象となる事業・サービス・状況に応じた確認が必要です。 Webアクセシビリティ改善チェックリスト 文字・色 本文の文字サイズが小さすぎない 文字と背景のコントラストを確認している 色だけで「エラー」「必須」などを伝えていない 画像内文字が読みにくくなっていない 画像・動画 意味のある画像に適切なaltがある 装飾画像を不要に読み上げさせていない 動画の重要情報を字幕・テキストでも確認できる 画像だけで重要事項を伝えていない 操作 キーボードだけで主要機能を利用できる フォーカス位置が分かる 固定ヘッダーなどでフォーカス部分が隠れない スマートフォンでボタンを押しやすい リンク・ボタンの役割が分かる コンテンツ h1・h2・h3の階層が整理されている 見出しだけ読んでもページ構造が分かる 「こちら」だけの曖昧なリンクが多くない 専門用語を必要以上に多用していない フォーム 各入力項目にラベルがある 必須・任意が分かる エラー箇所と修正方法が分かる キーボードで入力・送信できる 入力途中で意図せず内容が消えない 運用 記事投稿時にaltを確認している 画像・動画追加時のルールがある サイト更新後にもアクセシビリティを確認する 定期的にキーボード・スマートフォンで実操作確認している 必要に応じてJIS・WCAGに沿った検証を行っている まとめ：完璧を目指すより、重要な問題から継続的に改善する Webアクセシビリティは、チェック項目を一度クリアして終わるものではありません。 企業サイトでは、 文字が読める画像の意味が伝わるキーボードでも操作できるボタンを押しやすいフォームから問い合わせできるスマートフォンや拡大表示でも利用できる といった、ユーザーが情報や機能へアクセスするうえで重要な部分から改善していくことが大切です。 WCAG 2.2には幅広い達成基準があり、日本ではJIS X 8341-3:2016もWebアクセシビリティを考えるうえで参照されています。 最初からすべてを完璧にしようとして動けなくなるより、 現状を確認する↓利用できなくなる重大な問題から改善する↓更新時にも確認する↓定期的に検証する という運用を作る方が現実的です。 アクセシビリティを「特別な対応」ではなく、使いやすく、伝わりやすく、企業として信頼されるWebサイトを維持するための品質管理として取り組んでいきましょう。 Webアクセシビリティを意識したホームページ改善ならRefuへ Refuでは、ホームページリニューアル時のデザイン・情報設計だけでなく、文字コントラスト、画像alt、見出し構造、フォーム、キーボード操作、スマートフォン表示など、アクセシビリティを意識したサイト改善にも対応しています。 「今のサイトが使いにくくなっていないか確認したい」「リニューアルを機にアクセシビリティも見直したい」「どこから改善すればいいのか分からない」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ワイヤーフレームで失敗が減る｜作り方・レビュー観点・よくある落とし穴 運用で差がつく！Webサイトの更新ルール（品質・表記・画像・承認フロー） E-E-A-Tを強化するサイト改修ポイント｜信頼を積み上げる情報設計 Core Web Vitalsの改善方法｜LCP・INP・CLSを初心者向けに解説 問い合わせが増える！フォーム改善の具体的テクニック
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/27
集客・マーケティング戦略SEO記事のリライト方法｜新規作成より優先すべきページの見つけ方
SEO記事は「増やす」だけでは強くなりません。 オウンドメディアを運用していると、 「今月は何本記事を書こうか」 という新規記事中心の考え方になりがちです。 もちろん、新しい検索意図を獲得するためには新規記事も必要です。 しかし、すでに数十本、数百本の記事が存在するサイトであれば、新しい記事を増やす前に、 「今ある記事から、まだ取り切れていない検索流入はないか？」 を確認することが重要です。 Search Consoleには、ページごとのクリック数・表示回数・CTR・平均掲載順位など、既存記事を改善するためのデータが蓄積されています。 リライトの強みは、感覚ではなく、実際のGoogle検索データを見ながら改善対象と内容を判断できることです。 まず結論：リライト対象は「古い記事」ではなく“需要があるのに取り切れていない記事” リライトというと、 公開から2年以上経ったから更新する 古い記事から順番に書き直す 更新日が古い記事を新しくする といった運用を想像するかもしれません。 しかし、記事の古さだけで優先順位を決める必要はありません。 重要なのは、 検索需要がある×Googleからある程度評価されている×まだクリックや問い合わせを取り切れていない ページを見つけることです。 つまりリライトは、 「古いページを新しく見せる作業」ではなく、「成果が伸びる余地のある既存ページを改善する作業」 と考えましょう。 内容をほとんど変更していないにもかかわらず、更新日だけを新しくするような対応では、本質的な改善にはなりません。 新規記事よりリライトを優先したい5つのページ 表示回数が多く、5〜20位付近にいるページ 最初に確認したいのが、検索結果には多く表示されているものの、上位を取り切れていないページです。 例えば、 表示回数：月5,000回 平均掲載順位：11位 クリック数：120回 というページがあったとします。 すでにGoogleから一定の評価を受け、検索結果へ表示されているため、 検索意図とのズレ 情報不足 独自性不足 タイトル 内部リンク コンテンツの鮮度 などを改善することで、さらに成果を伸ばせる可能性があります。 なお、「5〜20位」はGoogle公式のリライト基準ではなく、改善候補を探す際の実務上の目安です。 順位だけでなく、表示回数・クリック数・CVへの貢献も合わせて判断しましょう。 過去はクリックされていたのに継続的に落ちているページ 以前は検索流入を獲得できていたものの、 半年前から少しずつ減っている 前年同期より大きく落ちている 特定クエリだけクリックが減っている ページも重要なリライト候補です。 ただし、クリックが減ったからといって、すぐに本文を書き直すのはおすすめできません。 まずは、 検索需要そのものが減っていないか 季節性ではないか 検索意図が変化していないか 競合ページの内容が充実していないか 自社の記事内に古い情報が残っていないか を確認します。 「減った原因」を確認してから、必要な部分だけ改善することが重要です。 表示回数は多いのにCTRが低いページ 検索結果には表示されているのにクリックされていない場合、コンテンツ全体ではなく、検索結果上の見え方に問題がある可能性があります。 確認したいのは、 title 検索意図との一致 競合ページのタイトル スニペット 訴求の具体性 です。 例えば、検索ユーザーが「料金」を知りたいにもかかわらず、タイトルから料金について書かれていることが分からなければ、クリックされにくくなります。 このケースでは、全文を書き直す前に、 タイトル・導入文・検索意図との一致 を調整するだけで改善できる場合もあります。 同じ検索意図の記事が複数存在するページ 長期間オウンドメディアを運用していると、似たテーマの記事が増えていきます。 例えば、 SEO記事の書き方 SEOライティングの方法 SEOコンテンツの作り方 検索上位を取る記事構成 という4記事があり、内容や表示されている検索クエリまで似ている場合です。 この状態で新しい5本目の記事を追加すると、サイト内でページの役割がさらに曖昧になる可能性があります。 この場合は、 検索意図 実際に表示されているクエリ クリック数 被リンク CVへの貢献 を比較し、既存記事の統合を検討します。 流入はあるのに問い合わせにつながっていないページ SEOの目的が問い合わせ獲得であれば、 検索流入が多い＝成功 とは限りません。 例えば月5,000アクセスある記事でも、 サービスページへ進まない 事例を見てもらえない CTAがクリックされない 問い合わせにつながらない のであれば、ビジネス成果には十分につながっていません。 この場合は順位だけでなく、 記事の検索意図 サービスとの関連性 内部リンク CTA 次に読むページ まで含めて改善します。 Search Consoleで検索までの動きを確認し、GA4で訪問後の行動を確認すると、検索流入から問い合わせまでの流れを分析しやすくなります。 STEP1：Search Consoleからリライト候補を抽出する 「直近3か月」と「その前の3か月」を比較する まずSearch Consoleの検索パフォーマンスから期間比較を行います。 最初は、 直近3か月とその前の3か月 を比較すると分かりやすいでしょう。 確認する指標は、 クリック数 表示回数 CTR 平均掲載順位 です。 どの記事で、どの数字が変化しているかを確認します。 前年同期も確認して季節性を除外する 季節によって検索需要が変わるテーマでは、前年同期も比較します。 例えば、 今年4〜6月と昨年4〜6月 を比較します。 特に、 採用 確定申告 エアコン 引越し 年末調整 季節イベント などは、検索需要が時期によって大きく変わる可能性があります。 需要そのものが減っているのに「SEO評価が落ちた」と判断してリライトすると、原因と対策がズレてしまいます。 クリックが下降しているページから候補を探す 新規テーマを考える前に、以前よりクリックが減っているページを確認する運用を取り入れるのがおすすめです。 例えば、 以前は安定して流入していた 現在も表示回数はある 徐々にクリックが減っている ページは、改善余地がある可能性があります。 月次で確認しておけば、大きく流入を失う前に対策しやすくなります。 ページ単位からクエリ単位まで掘り下げる 例えば、 「ホームページ制作費用の記事のクリックが30％減った」 ことが分かったとします。 そこで終わらず、そのページを選択して検索クエリまで確認します。 すると、 ホームページ制作 費用 → 維持 ホームページ制作 相場 → 大幅減 ホームページ制作 見積もり → 増加 のように、検索意図ごとの差が見える場合があります。 リライトでは、 「記事全体が弱くなったのか」「一部の検索意図だけ取り切れていないのか」 まで切り分けることが重要です。 STEP2：リライトする前に検索意図を再確認する 現在の検索結果と記事内容が一致しているか リライト前には、対象キーワードの現在の検索結果を確認します。 例えば「ホームページ制作 費用」で、以前は一般的な解説記事が多かったとしても、現在は、 料金ページ 制作会社のサービスページ 価格比較ページ 費用シミュレーション などが中心になっている可能性があります。 検索結果は固定ではありません。 現在の検索ユーザーが何を求めているのかを改めて確認しましょう。 そもそも記事ページで狙うべき検索なのか すべてのキーワードをブログ記事で上位表示させる必要はありません。 例えば、 「相模原 ホームページ制作」 で検索する人は、情報収集よりも「依頼できる制作会社」を探している可能性があります。 この場合、ブログ記事を繰り返しリライトするよりも、サービスページや地域ページを強化する方が適切な場合があります。 検索意図に合わせて、 記事 サービスページ 料金ページ 事例ページ FAQ のどこを主役にするか判断しましょう。 検索意図が変わっていれば構成から見直す 検索意図そのものが変化している場合、数百文字を追加する程度では改善できないことがあります。 例えば、 以前：意味を知りたい という検索から、 現在：比較して選びたい という検索へ変化しているのであれば、 比較項目 費用 メリット・デメリット 選び方 失敗例 判断基準 などを追加し、ページ構成そのものを見直す必要があります。 リライトは、 古い文章を新しくする作業ではなく、現在の検索意図に合わせてページの役割を再設計する作業 と考えましょう。 STEP3：「リライト・統合・維持・新規作成・削除」を判断する 検索データを確認したら、すべての記事を同じようにリライトするのではなく、対応方法を分類します。 リライト｜検索意図は合っているが情報が弱い 対象例 8〜15位前後で安定している 表示回数が多い 情報が古い 競合より具体性が弱い 独自事例が少ない この場合は、既存URLを維持したまま内容を改善します。 統合｜同じ検索意図の記事が複数ある 例えば、 記事A：SEO記事の書き方記事B：SEOライティングの方法記事C：検索上位を取る記事構成 があり、Search Console上でも似たクエリで表示されている場合です。 この場合は、最も適切なページを軸に内容を統合します。 維持｜小幅な順位変動だけなら触らない すでに成果が出ているページを、 2位から4位になった という理由だけで全面的に書き換える必要はありません。 順位は日々変動します。 クリック数・表示回数・CVに大きな問題がなければ、経過観察または必要箇所だけの微調整にとどめます。 新規作成｜既存ページでは満たせない検索意図がある 新規記事が必要なのは、既存ページとは異なる検索意図がある場合です。 例えば、 既存記事：SEO対策とは？ 新規候補：SEOとリスティング広告の違い であれば、ユーザーが知りたい内容が異なります。 無理に1記事へ詰め込まず、別ページとして作成する方が分かりやすい場合があります。 削除｜改善も統合もできない場合の最終手段 順位が低いという理由だけで記事を削除するのは避けましょう。 まずは、 情報を改善できないか 他の記事へ統合できないか 被リンクがないか CVへの貢献がないか ユーザーに役立つ別の役割がないか を確認します。 削除は、改善・統合しても価値を残せない場合の最終手段として判断します。 STEP4：リライトの優先順位を点数化する 記事が100本、200本と増えてくると、 「全部リライトする」 という運用では現実的に回りません。 そこで、候補記事を簡単に点数化すると優先順位を決めやすくなります。 Refu式・リライト優先度スコア例 評価項目0点1点2点3点検索需要ほぼ表示なし少ない中程度多い現在順位圏外21位以下11〜20位4〜10位クリック推移増加横ばい少し減少大幅減少事業への近さ関係が薄い周辺テーマ関連あり問い合わせ直結情報の古さ問題なし一部古い複数古い大幅に古い 合計15点として、 11点以上：最優先 8〜10点：次に対応 5〜7点：経過観察 4点以下：優先度低 といった形で整理できます。 ※この点数や順位レンジはGoogle公式の基準ではなく、社内で改善対象を選びやすくするための運用上の目安です。 特に重視したいのが、 検索需要 × 事業への近さ です。 検索回数が多くても、自社サービスとほとんど関係がなければ、問い合わせへの貢献は限定的です。 SEO流入だけでなく、事業成果まで見て優先順位を決めましょう。 STEP5：順位を戻すだけではない“価値のあるリライト”を行う タイトルと冒頭を検索意図に合わせる 最初に確認するのは、 title H1 導入文 最初の結論 です。 検索ユーザーがページを開いたときに、 「この記事に自分が知りたい答えがありそう」 と分かる状態を作ります。 CTRが低い場合は、本文を全面的に書き換える前にタイトル改善から試す方法もあります。 足りない疑問・比較材料を追加する Search Consoleの検索クエリを見ると、記事制作時には想定していなかったニーズが見つかる場合があります。 例えば「ホームページ制作 費用」の記事に、 月額費用 保守費用 写真撮影費 原稿制作費 追加料金 といった検索クエリが出ている場合です。 これらが記事内で十分に説明されていないのであれば、新しい見出しとして追加できないか検討します。 実際の検索データを、次のコンテンツ改善へ反映する ことがポイントです。 古い情報を更新・削除する リライトでは「何を追加するか」だけでなく、「何を削るか」も重要です。 例えば、 終了したサービス 古い管理画面 過去の料金 現在は推奨されていない施策 重複している説明 結論に関係しない長い前置き などを整理します。 「せっかく書いたから残す」ではなく、現在の読者に必要かどうかで判断しましょう。 一次情報・経験・事例を追加する 競合サイトとの差を作るうえで重要なのが、自社にしか書けない情報です。 例えば、 実際のお客様から受けた質問 自社で対応した事例 現場で起きた失敗例 自社独自の判断基準 数値データ アンケート 担当者の見解 などです。 他サイトの内容を整理しただけの記事ではなく、自社だから書ける情報を加えることで記事の価値を高めます。 不要な文章を削る リライトは文字数を増やす作業ではありません。 例えば、 「ホームページ制作とは、ホームページを制作することです」 のように、読者にとって不要な説明であれば削除します。 目標を、 3,000文字の記事を5,000文字にする と決めるのではなく、 必要なら増やし、不要なら減らす という考え方が重要です。 内部リンクを再設計する 過去の記事は、公開後に追加された新しいページへリンクできていない場合があります。 リライト時には、 関連記事 サービスページ 料金ページ 事例ページ FAQ への内部リンクも確認しましょう。 特に問い合わせ獲得を目的とするオウンドメディアでは、 記事 → 関連記事 → サービス → 事例・料金 → 問い合わせ という流れを設計することが重要です。 CTAまで改善する SEO順位が上がっても、問い合わせにつながらなければWeb集客として十分とは言えません。 例えば、 「お問い合わせはこちら」 だけではなく、 「自社サイトで優先して改善すべきページを相談する」 のように、記事内容とつながったCTAへ変更する方法があります。 リライトでは、検索順位だけでなくCV導線までセットで改善しましょう。 STEP6：記事統合・URL変更で失敗しないための注意点 リライトだけなら原則URLを変えない タイトルや本文を改善するだけであれば、安易にURLまで変更する必要はありません。 URLを変更すると、 内部リンクの修正 外部リンクへの影響 リダイレクト設定 Search Console上での管理 など、追加の対応が必要になります。 特別な理由がなければ、既存URLを維持したまま改善する方がシンプルです。 記事を統合するなら301リダイレクトを設定する 例えば、 記事A記事B記事C を記事Aへ統合する場合、B・Cを削除するだけで終わらせないようにします。 内容を適切に記事Aへ統合したうえで、 B → AC → A へ301などの恒久的なリダイレクトを設定します。 また、旧ページから張られていた内部リンクも、可能であれば統合後のURLへ直接変更します。 内容と関係のないページをトップページへ一括転送するような設定は避けましょう。 更新日だけ変更する“見せかけのリライト”はしない 本文をほとんど変更していないにもかかわらず、 2024年版 → 2026年版 とタイトルだけ変更したり、更新日だけ最新にしたりするのは、本質的な改善ではありません。 更新日は、 内容を確認し、読者にとって意味のある変更を行った場合 に変更する運用がおすすめです。 STEP7：公開後の効果をSearch ConsoleとGA4で検証する リライト日と変更内容を記録する 記事を更新したら、最低限次の情報を残しておきます。 URL 更新日 更新理由 変更した内容 更新前のクリック数 更新前の表示回数 更新前の順位 更新前のCV これを記録していないと、 「リライトした結果、本当に良くなったのか」 を判断できなくなります。 表示回数・クリック・CTR・クエリの変化を見る リライト後はSearch Consoleで、 表示回数 クリック CTR 平均掲載順位 表示される検索クエリ を確認します。 ただし、公開翌日に成果を判断するのは避けましょう。 検索エンジンによる再クロールや再評価には時間がかかる場合があります。 一定期間の変化を見たうえで判断することが重要です。 順位だけでなく問い合わせへの貢献を見る 例えば、 リライト前月1,000PV問い合わせ0件 リライト後月850PV問い合わせ3件 だった場合、PVだけを見れば減っています。 しかし、Web集客としては改善している可能性があります。 そのため、 Search Consoleで見るもの 検索表示 クリック 検索クエリ GA4で見るもの サービスページへの遷移 CTAクリック フォーム到達 問い合わせ 資料請求 を組み合わせて評価しましょう。 SEOリライト判断チェックリスト リライト候補の抽出 Search Consoleで前期間比較を行った 前年同期も確認した クリックが下降しているページを抽出した 表示回数が多いページを確認した 5〜20位前後のページを確認した 高表示・低CTRページを確認した 流入はあるがCVにつながらないページを確認した 検索意図 現在のGoogle検索結果を確認した 記事と検索意図が一致している 記事ページで狙うべきキーワードか確認した Search Consoleのクエリを確認した 競合が満たしている検索意図を確認した 対応判断 次のどれにするか決めた。 リライト 統合 維持 新規作成 削除 リライト内容 タイトルを確認した 導入文・結論を見直した 古い情報を削除・更新した 不足している疑問を追加した 自社独自の経験・事例を追加した 不要な文章を削った 関連記事への内部リンクを追加した サービスページへのリンクを確認した CTAを改善した 技術確認 不要にURLを変更していない 統合ページには301リダイレクトを設定した 内部リンクを統合先URLへ変更した 更新日だけを変更していない 効果測定 リライト日を記録した 更新内容を記録した Search Consoleの変化を確認した GA4でサイト内行動・CVを確認した 再改善する条件を決めた まとめ：記事数ではなく「既存資産から成果を取り切る」 SEO記事を増やし続ける前に、一度Search Consoleを確認してみましょう。 サイトの中には、 「もう少し改善すれば上位を狙える記事」 「以前は成果を出していたのに流入が落ちている記事」 「検索結果には表示されているのにクリックされていない記事」 「流入はあるのに問い合わせへつながっていない記事」 が眠っている可能性があります。 リライトは、 データから候補を探す↓検索意図を確認する↓リライト・統合・維持・新規作成を判断する↓必要な部分だけ意味のある改善を行う↓公開後の検索データ・CVを確認する という流れで進めます。 SEOで重要なのは、 「毎月何本の記事を公開したか」ではなく、「検索ユーザーに必要なページをどれだけ強くできたか」 です。 新規記事とリライトを役割分担しながら、既存コンテンツを単なる「公開済みの記事」ではなく、これからも成果を生み続けるWeb資産として育てていきましょう。 オウンドメディア・SEOリライトのご相談ならRefuへ Refuでは、Search Console・GA4をもとに既存記事を分析し、 「新規記事を作るべきか」「どの記事をリライトすべきか」「似た記事を統合すべきか」「問い合わせにつなげるには何を改善すべきか」 まで整理したオウンドメディア改善を行っています。 「記事は増えたけれどSEO流入が伸びなくなった」「100本以上の記事があり、何から直せばいいか分からない」「新規記事とリライトの優先順位を決めたい」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら コンテンツSEOとは？中小企業でも成果を出せる記事戦略 成果を出す企業が必ずやっているアクセス解析の活用法 成功企業のSEO改善ステップ｜順位UPまでの実例を紹介 中小企業でも再現できる“成果の出るSEO改善プロセス” ホームページの集客が伸びない原因10選｜まず見直すべき優先順位 GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順 検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法 ホームページの回遊率を上げる導線改善｜内部リンクと関連記事設計のコツ
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/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/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を高めるコンテンツ設計｜信頼されるホームページの作り方
