COLUMN
よく検索されるキーワード
2026/09/29
リニューアル・運用ノウハウWebサイトのA/Bテスト入門｜何を検証し、どう改善につなげるか
A/Bテストとは？2つのパターンを比較する改善方法 A/Bテストとは、Webページの一部を変更した複数のパターンをユーザーへランダムに表示し、どちらがより成果につながるかを比較する方法です。 例えば、 A：お問い合わせはこちらB：無料相談をしてみる という2種類のCTAを表示し、クリック率や問い合わせ率を比較します。 GoogleもA/Bテストを、複数のパターンをランダムなユーザーへ同時に表示し、クリック率やキーイベント率など特定の目標への貢献を比較するテストとして説明しています。 A/Bテストはどんな時に使う？ A/Bテストが向いているのは、アクセスはあるものの、どの改善案が良いか判断できない時です。 例えば、 問い合わせ率を上げたい CTAがクリックされない LPから離脱されている フォーム完了率を上げたい といったケースです。 逆にアクセスが極端に少ないページでは、十分なデータを集めるまで時間がかかるため、まずはサイト構成やコンテンツそのものを改善した方がよい場合もあります。 何をテストする？改善しやすい5つの項目 ファーストビューの見出し ユーザーへ最初に伝える内容を比較します。 例： A「高品質なホームページ制作」B「問い合わせにつながるホームページ制作」 CTAの文言 ボタンの言葉を変えて反応を確認します。 例： 「お問い合わせ」「無料相談はこちら」 CTAの位置 ページ下部だけでなく、 ファーストビュー サービス説明後 料金説明後 など、配置を変えて比較します。 事例・料金・FAQの順番 コンテンツの掲載順も改善対象です。 ユーザーが問い合わせ前に料金を重視しているなら、料金情報を上へ移動した方が成果につながる可能性があります。 フォームの項目 入力項目を減らした場合に、フォーム完了率がどう変わるかを確認します。 ただし、項目を減らしすぎて問い合わせの質が下がらないかも合わせて確認しましょう。 A/Bテストの基本的な進め方 おすすめは、次の5ステップです。 課題を見つける GA4やヒートマップで問題のあるページを探します。 ↓ 仮説を立てる 例： 「CTAが分かりにくいからクリックされていないのでは？」 ↓ A・Bのパターンを作る 元の状態と改善案を用意します。 ↓ 一定期間テストする ユーザーをランダムに振り分けてデータを取得します。 ↓ 結果を見て反映する 成果の高かった案を本番へ反映し、次の改善につなげます。 A/Bテストでは、一度に多くの要素を変えすぎないことも大切です。 ボタン文言、色、位置、ページ構成を同時に変えると、何が成果に影響したのか判断しにくくなります。 結果を見る時に注意したいポイント 「Bの方が問い合わせが1件多かったからBに決定」と、すぐに判断するのは危険です。 確認したいのは、 十分なデータが集まっているか 特定の曜日やキャンペーンだけに偏っていないか クリック率だけでなく最終CVも改善したか です。 例えば、 CTAクリック率は上がった↓問い合わせ完了率は変わらない なら、問題はCTAではなくフォーム側にある可能性があります。 最終的な目的に近い指標まで確認することが重要です。 GA4とA/Bテストの関係 現在のGA4単体には、WebサイトのA/Bテストを作成・配信する機能はありません。 Googleは、A/Bテストを実施する場合、サードパーティのA/Bテストツールと連携し、テスト自体は外部ツールで管理しながらGA4で結果を分析する方法を案内しています。 なお、以前利用されていたGoogle Optimizeは2023年9月30日に提供終了しています。 古いSEO記事で「Google Optimizeを使いましょう」と紹介されている場合は、現在利用できないため注意しましょう。 SEOへの影響を防ぐための注意点 ページ全体を別URLでA/Bテストする場合は、SEO面にも注意が必要です。 Googleは主に、 Googlebotだけ別内容を見せるクローキングをしない 複数URLの場合は元ページをcanonicalとして示す 一時的なリダイレクトでは301ではなく302を使う 必要以上に長期間テストしない ことを推奨しています。 ボタン文言の変更程度であれば大きな問題になりにくいですが、URLを分ける大規模テストでは制作会社やSEO担当者と相談して設計するのがおすすめです。 A/Bテストでよくある失敗 アクセスが少ないのに結論を出す 少数のユーザーだけでは偶然の影響を受けやすくなります。 一度に多く変更する どの変更が良かったのか分からなくなります。 クリック率だけを見る 最終的な問い合わせや購入まで確認しましょう。 仮説なしでテストする 「とりあえずボタンを赤くしてみる」では改善ノウハウが蓄積されません。 テスト結果を記録しない 「何を試してどう変わったか」を残すことで、次回の改善に活かせます。 A/Bテストチェックリスト テスト前 改善したいKPIが決まっている GA4やヒートマップで課題を確認した 改善仮説がある 一度に変更する内容を絞っている 実施中 A・Bを公平に比較できている 十分なデータが集まる前に終了していない 途中結果を見て頻繁に内容を変更していない テスト後 クリックだけでなくCVまで確認した 結果を記録した 成果の良いパターンを本番へ反映した 次に検証する課題を決めた ※外部のA/Bテストツールを導入する場合は、Cookieや取得データの仕様を確認し、必要に応じてプライバシーポリシーや同意管理も見直しましょう。 まとめ：感覚ではなくデータで改善する A/Bテストは、 「こちらのデザインの方が良さそう」 という感覚だけで決めるのではなく、実際のユーザー行動から改善案を判断する方法です。 基本の流れは、 課題発見↓仮説作成↓A/Bテスト↓結果確認↓本番反映 です。 すべてのページでA/Bテストをする必要はありません。 まずは、 アクセスが多い 成果への影響が大きい 改善余地がありそう というページから始めると効率的です。 A/Bテストを単発で終わらせず、GA4やヒートマップと組み合わせながら、改善を継続する仕組みとして活用しましょう。 無料相談 Refuでは、GA4・ヒートマップなどを活用した現状分析から、CTA・ページ構成・フォームの改善まで、データに基づいたWebサイト運用を支援しています。 「アクセスはあるのに問い合わせにつながらない」「どこを改善するべきか分からない」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 「アクセスはあるのに成果が出ない」時の改善ポイント5選 コンバージョン率を上げる導線設計とは？成果を生むページ構成の考え方 問い合わせが増える！フォーム改善の具体的テクニック GA4のイベント設計入門｜「何を計測すべきか」を成果から逆算する ヒートマップ分析の見方｜クリック・熟読・離脱から改善点を見つける方法
2026/09/22
リニューアル・運用ノウハウヒートマップ分析の見方｜クリック・熟読・離脱から改善点を見つける方法
ヒートマップとは？ユーザーの行動を“見える化”する分析方法 ヒートマップとは、Webサイトを訪れたユーザーが、 どこをクリックしたかどこまでスクロールしたかページのどの部分に時間を使ったか といった行動を、色や数値を使って視覚的に確認する分析方法です。 アクセス解析では、 「このページを1,000人が見た」「問い合わせ率が1.5％だった」 という結果は分かります。 しかし、それだけでは、 「なぜ問い合わせしなかったのか」「どこで読むのをやめたのか」「どの情報に興味を持ったのか」 までは分かりません。 そこで役立つのがヒートマップです。 例えばMicrosoft Clarityでは、クリックマップ、スクロールマップ、エリアマップ、アテンションマップなど複数のヒートマップ機能が提供されています。クリック位置や到達率、各セクションに費やした時間などからユーザー行動を確認できます。 GA4とヒートマップは何が違う？ ヒートマップとGA4は、どちらか一方を使えばよいものではありません。 役割が異なります。 GA4→ 「何が起きたか」を数値で見る 例えば、 アクセス数 流入経路 ページ閲覧 イベント コンバージョン などを確認します。 一方で、 ヒートマップ→ 「ページ内でどのように行動したか」を見る ことに向いています。 例えば、 CTAより前に多くのユーザーが離れている 画像がボタンだと思われてクリックされている ページ下部の料金表まで見られていない といったことです。 おすすめは、 GA4で問題のあるページを見つける↓ヒートマップでページ内の原因を探す という使い方です。 ヒートマップで見るべき3つの基本データ クリック｜どこが押されているか クリックヒートマップでは、ユーザーがページ内のどこをクリック・タップしているか確認します。 Microsoft Clarityのクリックマップでは、リンクだけでなく、ユーザーがクリックした非リンク要素も確認できます。また、反応しない場所へのクリックである「Dead click」や、短時間に同じ場所を繰り返しクリックする「Rage click」なども確認できます。 見るべきポイントは、 CTAが押されているか グローバルメニューのどこが使われているか 画像や見出しが誤ってクリックされていないか 重要ではないリンクにクリックが集中していないか です。 スクロール｜どこまで見られているか スクロールヒートマップでは、ユーザーがページのどの位置まで到達したか確認します。 Clarityでは、ページ上の特定位置まで到達したユーザーの割合や、スクロール前に平均的に見えている範囲を確認できます。 例えば、 70％のユーザーがページ中央まで到達↓問い合わせCTAはページ最下部↓CTAを見る前に多くのユーザーがページを離れている可能性 という仮説を立てられます。 熟読・注目｜どこに時間を使っているか ツールによっては、ページの各エリアにユーザーがどの程度時間を使っているか確認できます。 Clarityのアテンションマップでは、各セクションの平均滞在時間や、セッション全体に対してその部分へどの程度時間を使ったかを確認できます。 ただし、 長く滞在している＝必ず熟読している とは限りません。 内容が分かりにくくて読むのに時間がかかっている可能性もあります。 ヒートマップは、数値だけで結論を出すのではなく、ページ内容と合わせて判断することが重要です。 クリックヒートマップの見方｜CTA・リンクの改善点を探す クリックマップを見る時は、単純に「赤いところ＝良い」と考えないようにします。 重要なのは、 押してほしいところが押されているか です。 例えば、問い合わせを目的としたページで、 会社概要 採用情報 SNSリンク ばかりクリックされ、 「無料相談はこちら」 がほとんど押されていなければ、ユーザーの関心とサイト側の導線にズレがある可能性があります。 逆に、 料金 事例 よくある質問 へのクリックが多い場合は、 問い合わせ前にこれらの情報を確認したいユーザーが多い という仮説を立てられます。 その場合、 料金 → 事例 → FAQ → 問い合わせ という導線を強化する方法があります。 スクロールヒートマップの見方｜離脱ポイントを推測する スクロールマップでは、ユーザーの到達率が大きく下がるポイントを確認します。 例えば、 ファーストビュー：100％サービス紹介：80％選ばれる理由：70％長い会社紹介：35％事例：25％問い合わせ：15％ という状態だったとします。 この場合、 会社紹介付近でユーザーが読むのをやめている 可能性があります。 そこで、 会社紹介を短くする 事例を上へ移動する 途中にもCTAを追加する 見出しだけで内容が分かる構成にする といった改善を検討できます。 ただし、スクロール到達率の低下だけで「ここで離脱した」と断定することはできません。 スクロールマップが示すのは「どこまで到達したか」であり、実際のページ離脱についてはGA4などのデータも組み合わせて判断することが重要です。 熟読・アテンションの見方｜読まれている場所を探す 熟読・アテンション系のデータでは、 ユーザーがどこに時間を使っているか を確認します。 例えばサービスページで、 サービス説明：短い料金：長い事例：長い会社概要：短い となっている場合、 「ユーザーは具体的な料金と実績を比較しているのではないか」 という仮説が立てられます。 この場合、 料金情報を充実させる 料金の考え方を説明する 事例を料金付近へ配置する 問い合わせCTAを近くに置く といった改善につなげられます。 重要なのは、よく見られている情報の周辺に次の行動を用意することです。 「クリックされていない＝不要」と判断してはいけない理由 ヒートマップ分析で特に注意したいのが、 「クリックされていないから、このコンテンツは削除しよう」 という判断です。 例えば、 会社の信頼性を伝える受賞実績 資格情報 対応エリア 保証内容 などは、クリックされなくてもユーザーの判断材料になっている可能性があります。 同様に、 スクロールされている↓必ず読まれている とも限りません。 そのため、ヒートマップでは、 クリックされたか到達したか時間を使ったかその後CVしたか を組み合わせて考えます。 ヒートマップから改善案を作る実践パターン CTAまで到達していない場合 ページ下部に問い合わせCTAがあるものの、そこまで到達するユーザーが少ない場合です。 改善案としては、 CTAをページ途中にも配置する ファーストビューにも問い合わせ導線を設置する 不要なコンテンツを削る 重要なコンテンツを上へ移動する などがあります。 ただし、CTAを増やせば必ずCVが増えるわけではありません。 ユーザーが問い合わせを判断するために必要な情報が不足している場合は、情報追加が先です。 押せない場所がクリックされている場合 画像や見出しなど、本来クリックできない場所にクリックが集中しているケースです。 これは、 ユーザーが「押せそう」と認識している 可能性があります。 Microsoft Clarityでは、押しても反応しない箇所へのクリックをDead clickとして確認できます。 例えば施工事例の画像が頻繁にクリックされているなら、 画像から事例詳細へリンクする といった改善が考えられます。 ユーザーの期待に合わせてUIを変更することで、自然な回遊につなげられます。 重要情報が読まれていない場合 「選ばれる理由」「事例」「料金」など、CVに重要な情報の到達率が低い場合です。 改善案としては、 ページ上部へ移動する 文章を短くする 見出しを分かりやすくする 写真・図解を活用する 不要な前置きを削る などがあります。 ホームページでは、 伝えたい順番ではなく、ユーザーが知りたい順番 で構成することが重要です。 熟読されているのにCVにつながらない場合 非常に重要なパターンです。 例えば料金ページがよく読まれているのに問い合わせが少ない場合、 料金が高い 条件が分かりにくい 追加費用が不安 次に何をすればよいか分からない など、別の課題がある可能性があります。 その場合は、 料金例を追加 見積もりの流れを説明 FAQを追加 CTA文言を変更 事例を追加 などを検討します。 読まれているのに動かない場所は、CV改善の重要なヒント になります。 トップ・サービス・LP・フォームで見るポイント トップページ ファーストビュー直後に大きく到達率が落ちていないか サービスへのクリックが発生しているか 重要ではないメニューへ流れていないか 問い合わせCTAが認識されているか サービスページ 料金・強み・事例のどこが見られているか CTAまで到達しているか 関連サービスへ適切に回遊しているか LP ファーストビューで離れていないか 途中の長い説明で到達率が落ちていないか どの訴求付近でCTAが押されているか 押せない要素への誤クリックがないか 問い合わせフォーム フォームへの到達だけでなく、入力開始後の完了状況もGA4などと合わせて確認します。 ヒートマップだけでフォーム離脱の原因を断定せず、 フォーム到達 入力開始 エラー 送信完了 といったイベント計測も組み合わせると分析しやすくなります。 GA4と組み合わせると分析精度が上がる ヒートマップだけを見ていても、 そのユーザーが問い合わせしたのか どこから流入したのか どのページから移動してきたのか までは十分に判断できないケースがあります。 そこでGA4と組み合わせます。 例えば、 GA4サービスページのアクセスは多い↓問い合わせ率が低い ヒートマップ料金説明まではよく見られている↓CTAはほとんど押されていない という場合、 料金説明から問い合わせへの導線に問題があるのではないか という具体的な仮説を作れます。 分析の基本は、 GA4＝問題の場所を見つけるヒートマップ＝問題の原因を推測する という組み合わせです。 ヒートマップ分析でよくある失敗 データが少ない状態で結論を出す 数人の行動だけでサイト全体を変更すると、偶然の行動に左右されます。 十分なデータが集まってから判断しましょう。 PCとスマホを一緒に見る PCとスマートフォンでは、 画面サイズ メニュー CTA位置 操作方法 が大きく異なります。 ClarityのヒートマップでもPC・タブレット・モバイルを切り替えて確認できます。 基本的にはデバイス別に分析しましょう。 赤い場所だけを見る ヒートマップは「よくクリックされた場所を探すゲーム」ではありません。 むしろ重要なのは、 押してほしいのに押されていない場所 見てほしいのに届いていない場所 押せないのに押されている場所 です。 ヒートマップだけで原因を断定する ユーザーがスクロールを止めた理由は、ヒートマップだけでは分かりません。 内容が悪かった 必要な情報を見つけて満足した 電話番号を確認して離脱した 別タブで問い合わせした など複数の可能性があります。 ヒートマップは事実を可視化しますが、理由そのものを直接教えてくれるわけではありません。 改善したまま効果検証をしない ボタン位置を変更して終わりではなく、 変更前↓変更後 で、 クリック率 到達率 CV率 がどう変化したか確認します。 Clarityには同一プロジェクト内でヒートマップを比較する機能もあります。 改善を繰り返す実務フロー ヒートマップ分析は、次の順番で進めると分かりやすくなります。 改善目的を決める例：問い合わせを増やす↓GA4で対象ページを選ぶアクセスはあるがCVが少ないサービスページなど↓ヒートマップを見るクリック・スクロール・アテンション↓問題を仮説化する例：CTAを見る前に多くのユーザーが止まっている↓改善するCTAを移動・文章を短くする・事例を前へ移動↓一定期間データを取得する↓改善前後を比較する このサイクルを回すことで、感覚ではなくユーザー行動をもとに改善できるようになります。 ヒートマップ分析チェックリスト 分析前 改善したい目的を決めている 対象ページを絞っている ある程度のアクセスデータがある PC・スマホを分けて見る準備をしている クリック 主要CTAがクリックされている 想定していない場所へのクリックがない 押せない画像・文字へのクリックがない 重要ではないリンクへ流れすぎていない Dead click・Rage clickが発生していない スクロール 重要情報まで到達している CTAまで到達している 急激に到達率が下がる場所がない 長すぎるセクションがない ファーストビュー直後で大きく落ちていない 熟読・注目 料金が見られている 事例が見られている 強みが見られている FAQが見られている 長く見られている場所の内容を確認した 改善 ヒートマップだけで結論を出していない GA4と組み合わせている 改善内容を記録している 改善前後を比較している 一度に大量の変更をしていない 導入時はプライバシー・同意管理にも注意する ヒートマップやセッション分析ツールを導入する場合は、ユーザー行動データをどのように取得・利用するかについても確認が必要です。 利用するツールによって、 Cookieの利用 取得されるデータ マスキング機能 データ保存期間 同意管理 などの仕様が異なります。 例えばMicrosoft Clarityでは、Cookieや同意管理、データ収集に関する公式ドキュメントが用意されており、EEA・英国・スイスからのアクセスについては、2025年10月31日以降、全機能を利用するための有効な同意シグナルが求められています。 企業サイトへ分析ツールを追加する際は、 プライバシーポリシーの内容利用しているCookie・分析ツール対象地域に応じた同意取得フォームなど個人情報入力部分のマスキング などを確認しましょう。 「無料だからとりあえずタグを入れる」のではなく、取得データと利用目的を把握したうえで導入することが重要です。 まとめ：ヒートマップは“答え”ではなく改善仮説を見つけるツール ヒートマップを活用すると、 クリック＝どこを押したかスクロール＝どこまで到達したかアテンション＝どこに時間を使ったか など、アクセス数だけでは分からないユーザー行動を確認できます。 Clarityなど現在の行動分析ツールでも、クリック・スクロール・アテンションなど複数の視点から分析できる機能が提供されています。 ただし、ヒートマップだけを見て、 「ここで離脱した」「ここは読まれていないから不要」「このボタンは人気だから成果につながっている」 と断定するのは危険です。 重要なのは、 GA4で課題を発見する↓ヒートマップで行動を見る↓原因の仮説を立てる↓ページを改善する↓改善前後を比較する という流れです。 ヒートマップは、ユーザーの気持ちを直接読み取るツールではありません。 「なぜこのページで成果が出ないのか」を考える材料を増やし、改善仮説の精度を高めるツール として活用しましょう。 ヒートマップを活用したサイト改善ならRefuへ Refuでは、GA4・Google Search Console・ヒートマップなどを組み合わせ、アクセス数だけでは分からないユーザー行動を分析し、ページ構成・CTA・コンテンツ・フォームなどの改善につなげるWebサイト運用を支援しています。 「アクセスはあるのに問い合わせにつながらない」「どの部分から改善すればよいか分からない」「感覚ではなくデータをもとにサイトを改善したい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら リニューアル前に必ずやるべき現状分析｜GA4×サーチコンソール×ヒートマップの使い分け コンバージョン率を上げる導線設計とは？成果を生むページ構成の考え方 問い合わせが増える！フォーム改善の具体的テクニック 問い合わせの質を上げる「サンクスページ」活用術｜計測・育成・CV最適化 リニューアル後の改善ロードマップ｜公開後90日でやるべき施策チェックリスト
2026/09/15
リニューアル・運用ノウハウWordPress更新で不具合を起こさない手順｜公開前チェックと復旧方法
WordPressは更新した方がいい？放置するリスクとは WordPressを運用していると、管理画面に、 「WordPressの新しいバージョンがあります」「プラグインを更新してください」「テーマの新しいバージョンが利用できます」 といった通知が表示されます。 「更新してサイトが壊れたら怖いから、そのままにしている」という企業も少なくありません。 しかし、基本的にはWordPress本体・テーマ・プラグインは適切に更新していく必要があります。 WordPress公式も、WordPress本体を最新バージョンへ更新することや、テーマ・プラグインを最新状態に保つことを推奨しています。更新には機能追加だけでなく、不具合修正やセキュリティ対応が含まれる場合があります。 一方で、 「更新通知が出たら、何も確認せず全部更新する」 という運用もおすすめできません。 重要なのは、 更新しないことではなく、安全に更新できる仕組みを作ること です。 WordPress更新で不具合が起きる主な原因 WordPressを更新したあと、 サイトが真っ白になった レイアウトが崩れた フォームが動かなくなった 管理画面へ入れなくなった 一部の機能だけ動かなくなった といった問題が発生することがあります。 代表的な原因は次のとおりです。 WordPress本体とプラグインの互換性 プラグイン同士の競合 テーマとプラグインの競合 PHPバージョンとの互換性 独自カスタマイズ部分への影響 更新途中の通信・サーバートラブル WordPress公式でも、プラグインが最新のWordPressで更新・検証されていない場合、互換性が不明または問題が生じる可能性があることを案内しています。 つまり、 WordPressだから不具合が起きるのではなく、複数のプログラムが組み合わさって動いているため、更新によって組み合わせが変わることがある と考えると分かりやすいでしょう。 結論：安全な更新は「バックアップ→確認→更新→検証→復旧準備」の順 企業サイトのWordPress更新は、次の流れを基本にすると安全性を高められます。 バックアップを取得する↓更新内容・互換性を確認する↓必要に応じてステージング環境で確認する↓WordPress・テーマ・プラグインを更新する↓サイト・フォーム・管理画面を確認する↓問題があれば原因を切り分ける↓必要ならバックアップから復元する 特に重要なのは、更新前の状態へ戻せることです。 WordPress公式も、本体やプラグインのアップデート前にはバックアップを取得するよう案内しています。 更新前に必ずバックアップを取得する ファイルとデータベースの両方を保存する WordPressサイトは、大きく、 ファイルデータベース の2つで構成されています。 ファイルには、 テーマ プラグイン 画像 PHPファイル 設定ファイル などが含まれます。 データベースには、 投稿 固定ページ WordPress設定 ユーザー情報 プラグイン設定 などが保存されています。 そのため、更新前には原則としてファイルとデータベースの両方をバックアップします。 WordPress公式も、アップグレード前のバックアップを推奨しており、データベースだけではテーマ・プラグイン・アップロードファイル等は保存されないと説明しています。 バックアップから戻せる状態か確認する 「自動バックアップがあるから大丈夫」と思っていても、 保存期間が分からない ファイルしか保存されていない 復元方法が分からない 復元に別途費用が必要 という場合があります。 更新前には、 いつのバックアップがあるかファイルとDBの両方があるか誰が復元するのかどのくらい前まで戻せるのか を確認しておきましょう。 バックアップについては、No.46「ホームページのバックアップは必要？」で詳しく解説しています。 更新前に更新内容と互換性を確認する WordPress本体との互換性を確認する プラグインを更新する場合は、そのプラグインが現在使用しているWordPressバージョンと互換性があるか確認します。 WordPress公式ディレクトリのプラグイン情報では、対応しているWordPressバージョンなどを確認できる場合があります。 特に、 長期間更新されていないプラグイン 開発元のサポートが終了したプラグイン 独自開発されたプラグイン は慎重に確認しましょう。 PHPバージョンとの互換性を確認する WordPressだけでなく、サーバー側のPHPバージョンも関係します。 例えば、 PHPを更新↓古いプラグインが新しいPHPに対応していない↓サイトでエラー というケースがあります。 WordPress公式もPHP更新前に、バックアップ、WordPress・テーマ・プラグインの更新、互換性確認などを行うよう案内しています。 PHP変更はサイト全体へ影響する可能性があるため、通常のプラグイン更新以上に慎重に進めます。 更新履歴・変更内容を確認する 重要なプラグインの場合は、更新前に変更内容も確認します。 例えば、 セキュリティ修正 軽微な不具合修正 新機能追加 大規模な仕様変更 対応PHPバージョン変更 では、更新リスクが異なります。 問い合わせフォーム、EC、予約、会員システムなど、事業に直結する機能を担うプラグインほど更新内容を確認することをおすすめします。 重要サイトはステージング環境でテストする アクセス数が多いサイトや、問い合わせ・予約・ECなど重要な機能があるサイトでは、いきなり本番環境を更新するのではなく、ステージング環境（テスト環境）で確認してから本番へ反映する方法があります。 ステージング環境とは、本番サイトに近いコピー環境です。 例えば、 本番サイト↓テスト環境を複製↓WordPress・プラグインを更新↓表示・機能を確認↓問題なければ本番を更新 という流れです。 すべての小規模サイトで必須というわけではありませんが、 ECサイト 予約サイト 会員サイト 大規模メディア 独自システムとの連携があるサイト などは、ステージング環境を利用するメリットが大きくなります。 WordPressを安全に更新する実務フロー 更新前のサイト状態を確認する 更新前に、まず現在のサイトが正常か確認します。 おすすめは、 トップページ 主要サービスページ 問い合わせフォーム 管理画面 スマートフォン表示 を確認しておくことです。 更新前から存在していた不具合を、 「更新したから壊れた」 と誤認しないためにも重要です。 また、WordPressの「ツール ＞ サイトヘルス」では、PHPやプラグインを含むサイトの状態について確認できる項目があります。 一度にすべて更新しない 更新対象が10個あるからといって、一気にすべて更新すると、不具合が起きた時に原因を特定しにくくなります。 重要なサイトでは、 プラグインAを更新↓動作確認↓プラグインBを更新↓動作確認 というように、段階的に更新すると原因を切り分けやすくなります。 特に、 フォーム セキュリティ キャッシュ ページビルダー 多言語 EC・予約 など、サイト全体に影響しやすいプラグインは慎重に進めましょう。 更新するたびに主要機能を確認する 更新ボタンを押して「更新しました」と表示されたからといって、サイト全体が正常とは限りません。 最低限、 トップページが表示される 下層ページが表示される ヘッダー・メニューが動く 問い合わせフォームが送信できる スマホ表示が崩れていない 管理画面へログインできる ことを確認します。 キャッシュを削除して再確認する 更新後に、 「修正されているはずなのに表示が変わらない」 場合は、キャッシュが影響している可能性があります。 ブラウザキャッシュだけでなく、 WordPressキャッシュプラグイン サーバーキャッシュ CDN などを利用している場合があります。 必要に応じてキャッシュをクリアし、シークレットウィンドウや別端末でも確認します。 更新後に必ず確認したいポイント WordPress更新後は、次の項目を確認します。 表示 トップページ サービスページ ブログ・お知らせ 画像・スライダー スマートフォン表示 機能 問い合わせフォーム 検索 メニュー アコーディオン モーダル ログイン機能 予約・EC機能 管理画面 投稿編集 固定ページ編集 画像アップロード プラグイン画面 エラーメッセージ 計測 GA4 GTM 広告CV フォーム完了計測 SEO title・description robots.txt noindex 構造化データ 特に問い合わせフォームは、 画面上では正常に見えていてもメールが届かない ケースがあります。 実際にテスト送信し、 送信完了自動返信管理者通知 まで確認しましょう。 自動更新はONにした方がいい？サイトごとに判断する WordPressでは、プラグインやテーマごとに自動更新を有効化できます。 WordPress 5.5以降では、管理画面から個別に自動更新を設定でき、WordPress公式も自動更新を利用する場合には定期的な自動バックアップを確保するよう案内しています。 では、すべて自動更新にすればよいのでしょうか。 これはサイトによって異なります。 例えば、 比較的シンプルな企業サイト→ バックアップ・監視体制が整っていれば、自動更新を活用しやすい 独自カスタマイズが多いサイト→ 更新前テストを挟んだ方が安全 EC・予約・会員機能があるサイト→ 影響範囲を確認してから更新した方がよい場合がある というように判断します。 重要なのは、 「自動更新ON/OFF」だけで考えないこと です。 自動更新するなら、 バックアップ 更新通知の確認 障害監視 復旧方法 までセットで設計します。 更新後に不具合が起きた時の復旧方法 直前に更新したプラグイン・テーマを特定する まず、 何を更新したか 更新前は正常だったか どの機能が壊れたか を整理します。 複数のプラグインを一括更新すると、この原因特定が難しくなるため、段階的な更新が役立ちます。 管理画面に入れる場合は停止して切り分ける 管理画面へアクセスできる場合は、問題が疑われるプラグインを停止して確認します。 原因が分からない場合には、プラグインを停止し、1つずつ有効化して問題が再発するか確認する方法があります。 WordPress公式のトラブルシューティングでも、プラグインを一つずつ無効化・有効化して競合原因を特定する方法が案内されています。 管理画面に入れない場合はリカバリーモード等を利用する 致命的なPHPエラーなどが発生すると、WordPressの管理画面自体へアクセスできない場合があります。 WordPressにはリカバリーモード（Recovery Mode）があり、重大なエラーが検出された場合、管理者メールアドレスへ専用ログインリンクが送信されることがあります。 リカバリーモードでは、問題を起こしているプラグインやテーマを管理者セッション上で停止し、原因を修正できます。 リカバリーモードが利用できない場合には、FTP/SFTPやサーバーのファイルマネージャーから問題のプラグインフォルダをリネームして無効化する方法もWordPress公式で案内されています。 ただし、FTP・データベース操作を誤ると状況を悪化させる可能性があります。 分からない場合は無理に操作せず、制作会社やサーバー会社へ相談する方が安全です。 解決できない場合はバックアップから復元する 原因を特定できない場合や、複数箇所へ影響が出ている場合は、更新前のバックアップから復元します。 基本的には、 更新前の正常なバックアップを確認↓ファイル・データベースを必要に応じて復元↓サイト表示を確認↓フォーム等の機能確認↓更新をいったん停止↓原因を調査して再実施 という流れです。 WordPress公式も、アップデート前にバックアップしておけば、問題発生時にサイトを元の状態へ復元できると案内しています。 WordPress更新でよくある失敗 バックアップせずに更新する 最も避けたいケースです。 更新自体は数秒でも、復旧には大きな時間がかかる可能性があります。 更新を何年も放置する 「壊れるのが怖い」と更新を避け続けると、古いWordPress・テーマ・プラグインが蓄積します。 将来まとめて更新すると、 PHPも古い テーマも古い プラグインも古い という状態になり、かえって更新難易度が高くなります。 すべてのプラグインを一括更新する 更新数が多いほど、問題発生時の原因特定が難しくなります。 重要サイトでは段階的な更新を検討しましょう。 更新後にトップページしか見ない トップページが正常でも、 問い合わせフォーム 投稿編集 スマホメニュー 予約機能 などが壊れている可能性があります。 本番サイトで初めて大規模更新を試す WordPress本体の大きな変更、PHP変更、主要プラグインの大型アップデートなどは、可能であればテスト環境で確認します。 制作会社の独自カスタマイズを把握していない テーマやプラグインのファイルを直接変更している場合、更新によってカスタマイズ内容が上書きされる可能性があります。 WordPress公式も、WordPress本体のアップグレードではコアファイルへの独自変更が失われることを警告しています。 サイトを引き継ぐ際には、 どこに独自カスタマイズが入っているか を制作会社へ確認しておくことが重要です。 WordPress更新チェックリスト 更新前 WordPress本体の現在バージョンを確認した PHPバージョンを確認した 更新対象のプラグイン・テーマを確認した 互換性・変更内容を確認した ファイルのバックアップを取得した データベースをバックアップした バックアップから復元できる状態を確認した 現在のサイトに既存不具合がないか確認した 重要な更新はステージング環境で確認した 更新作業 一度に大量更新していない 重要なプラグインは個別に更新している 更新ごとにサイトを確認している エラーが出た場合は作業を止めている 更新後 トップページを確認した 主要下層ページを確認した PC・スマートフォンで確認した グローバルメニューを確認した 問い合わせフォームを実際に送信した 自動返信メールを確認した 管理者通知メールを確認した WordPress管理画面を確認した 記事・固定ページの編集を確認した GA4・GTM等の計測を確認した キャッシュクリア後にも確認した 復旧体制 更新した内容を記録している 問題が起きた時に停止する方法を把握している FTP/SFTP等の管理情報を管理している バックアップの復元担当が決まっている 制作会社・サーバー会社への連絡方法を確認している まとめ：更新しないのではなく「安全に更新できる運用」を作る WordPressでは、 WordPress本体テーマプラグインPHP など、複数の要素が連携してサイトを動かしています。 そのため、更新によって互換性の問題が発生する可能性はあります。 しかし、 「壊れる可能性があるから更新しない」 という運用も適切ではありません。 WordPress公式も、WordPress本体・テーマ・プラグインを最新状態に保つことを推奨しています。 重要なのは、 バックアップを取る↓互換性を確認する↓必要ならテスト環境で試す↓段階的に更新する↓更新後に表示・機能を確認する↓問題があればすぐ戻せる という運用です。 特に企業サイトの場合、ホームページは問い合わせ・採用・予約などの窓口になっています。 「管理画面に更新通知が出ているからクリックする」という作業ではなく、サイトを安定して運用するための保守業務の一つとしてWordPress更新を考えましょう。 WordPressの保守・運用ならRefuへ Refuでは、WordPress本体・テーマ・プラグインの更新対応から、更新前バックアップ、動作確認、不具合調査、サーバー・PHP環境の確認まで、企業サイトの継続的な保守・運用に対応しています。 「WordPressの更新通知が溜まっていて怖くて更新できない」「以前プラグインを更新したらサイトが壊れた」「現在のサイトを安全に保守できる状態にしたい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ホームページのバックアップは必要？保存頻度・範囲・復元方法を解説 セキュリティ最低限チェックリスト｜改ざん・乗っ取りを防ぐ運用習慣 保守契約とは？制作後に必要な運用サポートの種類と相場 目的別：CMSの選び方｜WordPressだけじゃない最適解の見つけ方 Core Web Vitalsの改善方法｜LCP・INP・CLSを初心者向けに解説
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/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/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/18
リニューアル・運用ノウハウrobots.txtとnoindexの違い｜検索に表示されない原因と正しい使い分け
robots.txtとnoindexの違い｜まず結論から理解しよう robots.txtとnoindexは、どちらも検索エンジンに関係する設定ですが、役割はまったく異なります。 最初に結論を整理すると、 robots.txt→ 検索エンジンのクローラーに「このURLをクロールしないで」と伝える noindex→ 検索エンジンに「このページを検索結果へ掲載しないで」と伝える という違いがあります。 Googleは、robots.txtについてクローラーがどのページやファイルをリクエストできるかを制御する仕組みとして案内しています。一方、noindexはページをGoogleのインデックスから除外し、検索結果に表示されないようにするためのルールです。 この違いを理解しないまま設定すると、 検索から消したかったのに残っている Googleに見てほしいページをブロックしてしまった noindexを設定したのに反映されない といったSEOトラブルにつながります。 そもそも「クロール」と「インデックス」は何が違う？ robots.txtとnoindexを理解するには、まずクロールとインデックスの違いを知っておく必要があります。 簡単に整理すると、 クロール→ Googlebotなどの検索エンジンがページを訪れて内容を取得すること インデックス→ 取得したページの内容をGoogleが解析し、検索結果に表示できる状態として登録すること です。 イメージすると、 Googleがページを見に来る＝クロール↓ページの内容を理解する↓検索データベースへ登録する＝インデックス↓検索結果に表示される可能性が生まれる という流れです。 robots.txtは最初の「クロール」に関係し、noindexは主に「インデックス」に関係します。 この違いが、今回の記事で最も重要なポイントです。 robots.txtとは？検索エンジンのクロールを制御するファイル robots.txtでできること robots.txtは、検索エンジンのクローラーに対して、サイト内のどのURLへアクセスしてよいか、またはアクセスしてほしくないかを伝えるためのテキストファイルです。 通常は、 https://example.com/robots.txt のように、サイトのルート直下へ設置します。 Googleもrobots.txtは対象ホストのルートに配置する必要があり、サブディレクトリ内に置いても有効にならないと案内しています。 例えば、 管理上クロールさせる必要がないURL サイト内検索結果など大量にURLが生成される領域 重要性の低い類似ページ などについて、クロールを制御する用途があります。 Googleはrobots.txtを、クロールトラフィックの管理や、重要性の低いページ・類似ページへのクロールを防ぐ用途として案内しています。 robots.txtでできないこと ここが非常に重要です。 robots.txtは「Google検索に表示しないための設定」ではありません。 Googleは、robots.txtでクロールを禁止したページであっても、他のページからそのURLがリンクされている場合などには、ページ内容をクロールせずURLだけをインデックスする可能性があると説明しています。 つまり、 robots.txtでブロック＝検索結果から必ず消える ではありません。 「検索結果に表示したくない」という目的なら、原則としてnoindexなど別の方法を検討します。 基本的な記述例 例えば、すべてのクローラーに対して/private-directory/以下へのクロールを許可しない場合、考え方としては次のようになります。 User-agent: * Disallow: /private-directory/ 一方、すべてのページをクロール可能にする場合は、特別な制限を設けない構成にします。 robots.txtは書き方を間違えると、サイト全体をクロールできなくしてしまう可能性があります。 そのため、「何となくSEO対策として設定する」ものではありません。 noindexとは？検索結果への掲載を防ぐための設定 noindexとは、検索エンジンに対して、 「このページを検索結果に表示しないでください」 と伝えるためのルールです。 Googlebotがページをクロールし、noindexを確認すると、そのページはGoogle検索結果から除外されます。 Googleは、他サイトからリンクされている場合でも、Googlebotがnoindexを検出すればGoogle検索結果から除外すると説明しています。 HTMLページでnoindexを設定する方法 代表的なのは、HTMLのrobots metaタグを使う方法です。 例えば、 <meta name="robots" content="noindex"> という設定です。 この設定によって、対応する検索エンジンへ「インデックスしない」という指示を出します。 WordPressなどのCMSでは、HTMLを直接編集しなくても、管理画面やSEO関連機能から設定できる場合があります。 PDFなどHTML以外ではX-Robots-Tagを使える PDFなど、HTMLの<head>内へmetaタグを設置できないファイルについては、HTTPレスポンスヘッダーのX-Robots-Tagを使ってnoindexを指定できます。 Googleも、PDF・動画・画像などHTML以外のリソースについてX-Robots-Tagを利用できると案内しています。 例えば、 営業資料PDF 過去資料 検索から見つけてもらう必要のないファイル などで検討するケースがあります。 noindexを設定してもすぐ消えるとは限らない noindexは設定した瞬間にGoogle検索からページを消すスイッチではありません。 Googlebotがそのページを再度クロールし、 「noindexが設定されている」 と認識する必要があります。 Googleは、ページの重要度などによって再クロールまで時間がかかる場合があり、必要に応じてSearch ConsoleのURL検査ツールから再クロールをリクエストできると説明しています。 そのため、 「昨日noindexを入れたのに、今日も検索結果に出ている」 からといって、必ず設定失敗とは限りません。 robots.txtとnoindexの決定的な違いを比較 項目robots.txtnoindex主な目的クロール制御インデックス制御Googlebotのアクセスブロックできるアクセスさせる必要がある検索結果から除外保証されないGooglebotが認識すれば除外主な設定場所ドメイン直下のrobots.txtmetaタグ／HTTPヘッダーページ単位の検索除外不向き適している機密情報の保護不向き不向き 特に覚えておきたいのは、 検索結果に表示させたくない＝noindexクロールそのものを制限したい＝robots.txt という基本です。 絶対に注意したい「robots.txt＋noindex」の組み合わせ 初心者の方が最も間違いやすいのが、この設定です。 「検索に出したくないから、robots.txtでブロックして、さらにnoindexも付けておこう」 一見すると二重に対策できて安全そうですが、逆効果になる可能性があります。 理由は、robots.txtでクロールをブロックすると、Googlebotがページへアクセスできなくなるからです。 Googlebotがページを開けなければ、ページ内にあるnoindexも確認できません。 Googleは明確に、noindexを機能させるにはrobots.txtでページをブロックせず、クローラーがアクセスできる状態にする必要があると案内しています。 つまり、 robots.txt：入るなnoindex：中に入ったら「検索に載せるな」と書いてある という状態になります。 入れないので、中の指示を読めません。 検索結果から除外したいページなら、 クロールを許可する↓Googlebotにnoindexを読ませる という流れが基本です。 目的別｜robots.txtとnoindexの正しい使い分け 検索結果に表示させたくないページ 例えば、 検索結果ページ ユーザーにとって検索流入させる必要のない完了ページ 一部の管理上必要な公開ページ など、公開状態ではあるもののGoogle検索には載せたくない場合は、noindexを検討します。 ただし「そのページを本当に検索から除外すべきか」は慎重に判断しましょう。 SEO上価値がないと思ってnoindexにしたページが、実は検索流入を持っていた、というケースもあります。 Googlebotのクロールを抑えたいページ 大量のURLが生成されるなど、Googlebotに積極的にクロールしてもらう必要がない領域ではrobots.txtを検討します。 Googleも、robots.txtをクロールトラフィックの管理などに利用できるとしています。 ただし、小規模な企業サイトで、 「SEOに良さそうだから、とりあえずrobots.txtで色々ブロックする」 必要はありません。 むしろ重要なCSS・JavaScriptやページを誤ってブロックするリスクに注意が必要です。 会員限定・社内限定・機密情報を守りたいページ これはrobots.txtでもnoindexでもありません。 ログイン認証やパスワード保護など、アクセス自体を制限する仕組みが必要です。 robots.txtは誰でも閲覧できるファイルであり、セキュリティ機能ではありません。 noindexも検索結果への掲載を制御するもので、URLを知っている人からページを守る機能ではありません。 Googleも、検索結果に出したくないページについて、必要に応じてパスワード保護などを利用するよう案内しています。 機密情報を守る目的でrobots.txtやnoindexだけを使うのはNGです。 テスト環境・ステージングサイト リニューアルで特に注意したいのが、制作中のテストサイトです。 テストサイトがGoogleにインデックスされると、 本番サイトとほぼ同じ内容が検索される 制作途中の情報が一般公開される 会社名検索でテストサイトが出る といった問題につながります。 テスト環境では、noindexだけに依存するのではなく、認証をかけて一般ユーザーや検索エンジンからアクセスできない状態にするのが安全です。 そして本番公開時には、認証・noindex・robots.txtなどのテスト用設定が残っていないか必ず確認します。 検索に表示されない時に確認すべきポイント noindexが残っていないか リニューアル後に検索へ出なくなった場合、最優先で確認したいのがnoindexです。 制作中に設定していたnoindexを、本番サイトでもそのまま残してしまう事故があります。 特に、 トップページ サービスページ ブログ・お知らせ 施工事例 採用ページ など重要ページのnoindexは致命的です。 robots.txtで重要ページをブロックしていないか robots.txtの設定ミスによって、重要なページ群をGooglebotがクロールできなくなっている可能性もあります。 例えば、 Disallow: / のような設定は、対象ユーザーエージェントに対してサイト全体へのクロールを禁止する意味になります。 制作環境用の設定を本番へそのまま移さないよう注意しましょう。 WordPressの検索エンジン表示設定を確認する WordPressでは管理画面に、検索エンジンがサイトをインデックスしないよう促すための設定があります。 制作中に有効にしていた場合、公開時の解除忘れに注意が必要です。 リニューアル公開時のチェックリストに、 「検索エンジン関連設定の確認」 を必ず入れておきましょう。 HTTPヘッダーのX-Robots-Tagを確認する HTMLを見てもnoindexが見つからないのに検索へ出ない場合、HTTPレスポンスヘッダーにX-Robots-Tagが設定されている可能性があります。 Googleでは、X-Robots-Tagでもnoindexなどのルールを指定できます。 特に、 PDF サーバー設定 .htaccess NGINX設定 などが関係する場合は、制作会社やエンジニアへ確認しましょう。 そもそもGoogleにクロールされているか noindexもrobots.txtも問題がないのに表示されない場合、 新しく公開したばかり 内部リンクがない XMLサイトマップに含まれていない GoogleがまだURLを発見していない など、別の理由も考えられます。 「検索に出ない＝noindex」と決めつけず、Search Consoleで状況を確認することが大切です。 リニューアル時に起こりやすいrobots.txt・noindex事故 テスト環境のnoindexを本番に残す 最も危険な事故の一つです。 デザインもフォームも正常なのに、検索流入だけが急激に落ちる可能性があります。 robots.txtでサイト全体をブロックしたまま公開する 制作中にクロールを抑える目的で設定し、そのまま本番公開するケースです。 公開前チェックで必ずrobots.txtを確認します。 noindexページをrobots.txtでもブロックする 先ほど説明した通り、Googlebotがnoindexを確認できなくなる可能性があります。 検索から外したいなら、Googlebotがnoindexを読み取れる状態にすることが必要です。 robots.txt内に「Noindex:」と書く robots.txtへnoindexを記述して検索結果から除外しようとする方法は、Googleではサポートされていません。 Googleは、noindexはmetaタグまたはHTTPレスポンスヘッダーで実装するよう案内しています。 インデックスさせたい重要ページまでnoindexにする カテゴリページやサービス詳細などを、「重複しそうだから」という理由だけでnoindexにするのも注意が必要です。 そのページがユーザーの検索意図に応えられるなら、検索流入の入口になる可能性があります。 noindexは、 「SEO評価が低そうだから」ではなく、「検索結果に存在する必要があるか」 で判断しましょう。 設定を確認する方法｜Search Consoleでチェックする robots.txtやnoindexの状態を確認する際は、Google Search Consoleを活用します。 特に便利なのがURL検査ツールです。 対象URLについて、 Googleにインデックスされているか クロールできているか noindexが検出されているか GoogleがどのURLを正規URLとして認識しているか などを確認できます。 Googleも、noindexが正しく実装されているか確認する方法としてURL検査ツールやページのインデックス登録レポートを案内しています。 robots.txtについても、Search Consoleのrobots.txtレポートなどを利用して公開済みファイルの問題を確認できます。 「設定したつもり」で終わらず、Googleから実際にどう見えているかを確認することが重要です。 robots.txt・noindexチェックリスト robots.txt robots.txtがドメインのルート直下にある 重要ページを誤ってDisallowしていない サイト全体を意図せずブロックしていない 制作環境用の設定が本番に残っていない 「検索から消す目的」でrobots.txtを使っていない robots.txtにNoindexルールを書いていない noindex 検索結果に必要なページへnoindexが付いていない noindexページをrobots.txtで同時にブロックしていない WordPress等の検索エンジン設定を確認している HTTPヘッダーのX-Robots-Tagも確認している noindex設定後、Search Consoleで認識状況を確認している リニューアル公開時 トップページをURL検査した 主要サービスページをURL検査した robots.txtを確認した noindexを全ページ横断で確認した XMLサイトマップを確認した 旧URL→新URLの301を確認した 公開後もSearch Consoleでインデックス状況を監視している まとめ：検索に出したくない＝robots.txtではない robots.txtとnoindexは似ているようで、役割が明確に違います。 robots.txt→ クロールを制御する noindex→ 検索結果へのインデックスを制御する そして最も注意したいのが、 robots.txtでクロールを止めると、Googlebotがnoindexを読めなくなる という点です。 Googleも、noindexを有効にするには、そのページをrobots.txtでブロックせずGooglebotがアクセスできる状態にする必要があると明記しています。 また、robots.txtもnoindexもセキュリティ機能ではありません。 社内限定・会員限定・機密情報など、本当に第三者へ見せたくない情報については、認証などアクセス自体を制限する仕組みが必要です。 特にサイトリニューアルでは、制作中の設定が本番へ残り、検索流入が失われる事故があります。 公開前には、 robots.txt noindex X-Robots-Tag Search Console XMLサイトマップ をセットで確認し、検索エンジンが正しくサイトをクロール・インデックスできる状態を整えましょう。 無料相談 Refuでは、リニューアル時のrobots.txt・noindex設定確認から、Search Consoleを使ったインデックス状況の調査、301リダイレクト、XMLサイトマップ、公開後のSEO監視まで一括で対応しています。 「リニューアル後に検索に出なくなった」「noindexが残っていないか確認したい」「Search Consoleにエラーが出ているけれど原因が分からない」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら Googleサーチコンソールの基本操作と改善への活かし方 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 コンテンツ移行で失敗しないために｜旧サイト資産の棚卸しと移行判断基準 ホームページの404エラーとは？SEOへの影響と正しい対処法
2026/08/11
リニューアル・運用ノウハウCore Web Vitalsの改善方法｜LCP・INP・CLSを初心者向けに解説
Core Web Vitalsとは？ホームページの「使いやすさ」を測る3つの指標 Core Web Vitals（コアウェブバイタル）とは、Webページを利用したユーザーが感じる読み込み速度・操作への反応・表示の安定性を測るための指標です。 現在のCore Web Vitalsは、次の3つで構成されています。 LCP（Largest Contentful Paint）→ メインコンテンツがどれくらい早く表示されるか INP（Interaction to Next Paint）→ クリックやタップなどの操作にどれくらい早く反応するか CLS（Cumulative Layout Shift）→ ページ表示中にレイアウトがどれくらいズレるか つまりCore Web Vitalsは、単純な「ページの速さ」だけを見る指標ではありません。 表示されるまで待たされないかボタンを押したのに反応しない状態にならないか読んでいる途中で文字やボタンが突然動かないか といった、実際のユーザー体験を数値化する考え方です。Googleも、Core Web Vitalsを実際のユーザー体験を測定する指標として位置づけています。 Core Web VitalsはSEOにどこまで影響する？ Core Web Vitalsについて、「数値を改善すれば検索順位が上がる」と考えている方もいます。 しかし、これは少し違います。 GoogleはCore Web Vitalsを、検索ランキングを決定する際に考慮するページエクスペリエンス関連の要素の一つとして扱っています。一方で、Core Web Vitalsだけを改善すれば上位表示できるわけではなく、検索意図に合った有益なコンテンツであることの方が重要です。 例えば、 Aサイト：Core Web Vitalsは非常に良いが、内容が薄いBサイト：表示速度は少し劣るが、検索ユーザーの疑問に詳しく答えている という場合、単純にAサイトが上位になるわけではありません。 そのため、Core Web Vitals改善の目的は、 「SEOの点数を上げること」ではなく、ユーザーがストレスなく利用できる環境を整えること と考えるのが重要です。 問い合わせや採用を目的とした企業サイトなら、ユーザー体験の改善は離脱防止やフォーム到達にもつながるため、SEO以外の意味でも取り組む価値があります。 まず覚えたいLCP・INP・CLSの基準値 Googleが示している「良好」の目安は次のとおりです。 LCP：2.5秒以下INP：200ミリ秒以下CLS：0.1以下 Core Web Vitalsでは一部の高速ユーザーだけを見るのではなく、実際のユーザー体験を広く捉えるため、ページ訪問の75パーセンタイルで3指標すべてが推奨値を満たしているかが重要な基準になります。 指標何を測る？良好の目安LCP読み込み速度2.5秒以下INP操作への反応200ms以下CLS表示の安定性0.1以下 まずは、この3つの意味を理解することから始めましょう。 LCPとは？ページの「表示速度」を改善する方法 LCPは、ページを開いてから、ファーストビュー内の大きな画像やテキストなど、主要なコンテンツが表示されるまでの時間を測ります。 Googleが推奨する良好なLCPは2.5秒以下です。 企業サイトでLCPの対象になりやすいのが、 メインビジュアル 大きな写真 メインコピーを含む大きなテキスト領域 などです。 ファーストビューの大きな画像を軽くする 企業サイトでLCPが悪化する代表的な原因の一つが、ファーストビューの大きな画像です。 例えば、 5MB以上ある写真をそのまま掲載 PC用の巨大画像をスマホでも読み込む 必要以上に高解像度な画像を使用 といった状態です。 改善する場合は、 適切な画像サイズへリサイズするWebPなど効率的な画像形式を検討する端末サイズに合った画像を配信する必要以上に高画質な画像を使用しない といった方法を検討します。 LCPはメインコンテンツが表示されるまでの時間を測るため、特にファーストビュー画像の読み込み方法は重要な改善ポイントです。 サーバーの応答速度を見直す 画像だけではなく、サーバー側の応答が遅ければページ表示全体が遅くなります。 例えば、 サーバースペックが不足している アクセス集中で処理が遅れている CMS側の処理が重い キャッシュが適切に利用されていない といった原因が考えられます。 画像を圧縮してもLCPが改善しない場合は、フロント側だけでなくサーバー・CMS環境まで確認することが大切です。 不要なCSS・JavaScript・外部読み込みを減らす ページを開く際に大量のCSSやJavaScriptを読み込んでいると、重要なコンテンツの表示が後回しになることがあります。 よくあるのが、 使用していないプラグイン 大量のアニメーション 計測タグ チャットツール SNS埋め込み Webフォント などです。 「便利だから」「以前から入っているから」と残すのではなく、本当に必要なものか定期的に棚卸しすることが重要です。 LCP画像を遅延読み込みしすぎない 画像の遅延読み込み（lazy load）は、ページ全体の読み込み量を減らすためには便利です。 しかし、最初から表示されるメインビジュアルなど、LCPの対象になる重要画像まで不必要に遅延させると、逆に表示が遅くなることがあります。 「すべての画像を遅延読み込みする」のではなく、ファーストビュー画像と下層画像を分けて設計することが大切です。GoogleのLCP最適化ガイドでも、LCPリソースを早く発見・読み込み・レンダリングできる状態にすることが重要とされています。 INPとは？クリック後の「反応の遅さ」を改善する方法 INPは、ユーザーがページ内で行ったクリック・タップ・キーボード操作などに対して、画面がどれだけ早く反応したかを評価する指標です。 良好な目安は200ミリ秒以下です。INPはページ滞在中に発生した対象インタラクションの応答性を継続的に見て、ページ全体として反応が悪くないかを評価します。 例えば、 メニューを押したのに開かない フォームの選択肢を押しても反応が遅い 「もっと見る」を押してから表示まで時間がかかる といった状態は、INP悪化につながる可能性があります。 重いJavaScript処理を減らす INPが悪い場合、代表的な原因の一つがJavaScriptです。 JavaScriptの処理中は、ブラウザがユーザー操作への反応をすぐに返せない場合があります。 不要なスクリプトを削除する 処理内容を見直す 必要なタイミングまで読み込みを遅らせる などによって改善を検討します。GoogleのINP最適化ガイドでも、入力遅延・イベント処理・次の描画までの時間を短縮することが重要とされています。 長時間メインスレッドを占有する処理を分割する 一つの重い処理が長時間実行されていると、その間ユーザー操作への反応が遅れます。 処理を小さく分けたり、不要な処理を減らしたりすることで、ユーザー操作を処理できる余裕を作ります。 専門的な実装になるため、INPに問題がある場合は制作会社やエンジニアへの相談をおすすめします。 外部ツール・タグを整理する 企業サイトでは公開後、さまざまなツールが追加されていきます。 GA4 GTM 広告タグ ヒートマップ チャット MAツール SNS関連 一つひとつは必要でも、積み重なることでサイトが重くなる場合があります。 リニューアル時には、現在使っているタグをすべて棚卸しするのがおすすめです。 「昔の広告用タグが残っていた」「使っていないヒートマップが動いていた」 というケースは珍しくありません。 フォームやメニューの操作感を実機で確認する 数値だけでなく、自分でスマートフォンを操作することも重要です。 ハンバーガーメニュー 問い合わせフォーム アコーディオン 検索機能 スライダー モーダル など、ユーザーが触る機能を実際に試してみましょう。 INPはユーザー操作への応答性を見る指標なので、「自分で触って遅いと感じる場所」が改善箇所を探すヒントになります。 CLSとは？突然レイアウトがズレる問題を改善する方法 CLSは、ページを閲覧している途中にレイアウトが予期せず移動する現象を評価します。 良好な目安は0.1以下です。 例えば、 ボタンを押そうとした瞬間に広告が表示され、位置がずれる 文章を読んでいたら上から画像が読み込まれて文章が移動する Webフォント読み込み後に文字サイズが変わる といった状態です。 ユーザーにとって非常にストレスの大きい現象なので、改善する価値があります。 画像・動画の表示領域をあらかじめ確保する 画像のwidth・heightなどが適切に設定されていないと、ブラウザは画像が読み込まれるまで必要なスペースを判断できません。 結果として、 文章が先に表示↓画像読み込み↓文章が下へ移動 というレイアウトシフトが発生します。 画像や動画のサイズ・アスペクト比を事前に指定し、読み込み前から表示領域を確保することが、CLS改善の基本です。 後から表示されるバナーやコンテンツに注意する Cookieバナー、広告、キャンペーン案内などをページ上部へ後から挿入すると、既存コンテンツを押し下げることがあります。 対策として、 あらかじめ表示スペースを確保する 既存コンテンツを押し下げない表示方法にする ユーザー操作後の表示方法を見直す などを検討します。サイズを確保していない動的コンテンツは、CLS悪化の代表的な原因の一つです。 Webフォントによる文字ズレを抑える Webフォントの読み込み前後で文字幅や高さが大きく変わると、文章の位置がずれることがあります。 日本語サイトでは文字量が多いため、フォント選択や読み込み方法による影響が大きくなるケースもあります。 デザイン性だけでなく、 読み込み速度 可読性 レイアウトへの影響 まで考えてフォントを選択しましょう。 Core Web Vitalsの確認方法｜まず見るべき3つのツール Google Search Console Search ConsoleにはCore Web Vitalsのレポートがあり、実際のユーザーデータをもとにサイトの問題を確認できます。GoogleもCore Web Vitals改善時の確認手段としてSearch Consoleのレポートを案内しています。 「サイト全体として問題があるページ群を探す」用途に向いています。 まずは、 良好 改善が必要 不良 となっているページがどれくらい存在するのか確認しましょう。 PageSpeed Insights PageSpeed Insightsは、URLを入力するだけでパフォーマンスを確認できるGoogleのツールです。 利用可能な場合は実際のユーザー環境から収集されたフィールドデータを確認でき、同時にLighthouseによるラボ環境での診断も改善箇所の特定に役立ちます。フィールドデータとラボデータは測定環境が異なるため、数値が一致しない場合があります。 重要なのは、 点数だけを見るのではなく、「何が遅くしているか」を見ること です。 Chrome DevTools・Lighthouse 具体的な原因を調べたい場合は、Chrome DevToolsやLighthouseを利用します。 例えば、 どの画像がLCP対象か どの処理が重いか どの要素がレイアウトシフトしているか など、問題の原因をより細かく分析できます。Googleは、Core Web Vitalsは実際のユーザーデータで評価しつつ、Lighthouseなどのラボツールを問題診断に活用するワークフローを案内しています。 「PageSpeed Insightsで100点」を目標にしなくていい理由 Core Web Vitals改善でよくある失敗が、 「とにかくPageSpeed Insightsを100点にする」 ことが目的になってしまうことです。 Google自身も、Core Web Vitalsのスコアが良いからといって検索上位が保証されるわけではなく、SEOだけを理由に満点を追い求めることは有効な時間の使い方とは限らないと説明しています。 例えば、100点を取るために、 必要な写真を極端に小さくする 便利な機能を削除する ブランド表現をすべてなくす となってしまえば、本末転倒です。 目指すべきなのは、 ユーザーがストレスなく閲覧できる伝えたい情報がきちんと伝わる問い合わせ・応募につながるそのうえでCore Web Vitalsも良好 という状態です。 リニューアル時にCore Web Vitalsが悪化しやすい原因 「古いサイトより新サイトの方が遅くなった」ということは実際に起こります。 原因として考えられるのは、 大きなメインビジュアルを追加した動画をファーストビューへ追加したアニメーションを増やしたWebフォントを増やしたJavaScriptライブラリが増えた計測・広告・チャットタグが増えたWordPressプラグインが増えた などです。 つまり、デザインを豪華にすることと、快適に使えることは必ずしも同じではありません。 リニューアルではデザイン確認だけでなく、公開前にPageSpeed Insightsや実機でパフォーマンス確認を行いましょう。 Core Web Vitals改善チェックリスト LCP｜読み込み速度 ファーストビュー画像が必要以上に大きくない 画像を適切なサイズ・形式にしている LCP対象画像を不必要に遅延読み込みしていない 不要なCSS・JavaScriptを減らしている サーバー応答が極端に遅くない 不要な外部ツールを削除している INP｜操作への反応 ボタン・メニューがすぐ反応する 重いJavaScript処理を見直している 不要なタグ・外部スクリプトを整理している フォームを実際のスマートフォンで操作確認している アニメーションやUI機能を増やしすぎていない CLS｜表示の安定性 画像に表示サイズ・アスペクト比を設定している 動画・iframeの領域を確保している 後から挿入されるバナーの領域を確保している フォント読み込みによる大きなズレがない ページをスクロールしても突然コンテンツが動かない 計測・運用 Search ConsoleでCore Web Vitalsを確認している PageSpeed Insightsで重要ページを確認している トップページだけでなくサービスページも確認している PC・スマートフォンの両方を確認している リニューアル公開後も継続して数値を監視している まとめ：数字を良くすることではなく“快適に使えるサイト”を目指す Core Web Vitalsは、 LCP＝表示されるまでの速さINP＝操作への反応の速さCLS＝画面の安定性 という、ユーザーがホームページを利用するときの基本的な体験を数値化したものです。 現在Googleが示している良好の目安は、LCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下です。 ただし、Core Web Vitalsだけを改善すればSEOで勝てるわけではありません。 検索意図を満たすコンテンツ企業としての信頼性分かりやすい導線問い合わせしやすい設計快適なページ体験 これらを総合的に整えることが重要です。Googleも、特定のページエクスペリエンス指標だけに集中するのではなく、全体として良いページ体験を提供することを推奨しています。 Core Web Vitalsは「SEOのための点数」ではなく、ユーザーが快適にサイトを利用できているかを確認する健康診断として活用しましょう。 無料相談 Refuでは、PageSpeed Insights・Search Consoleなどを活用した現状分析から、画像最適化、JavaScript・外部タグの整理、WordPress・サーバー環境の見直しまで、サイトごとの原因に合わせた改善をご提案しています。 「リニューアルしたらサイトが重くなった」「PageSpeed Insightsの数値をどう見ればいいか分からない」「SEOと問い合わせの両方を考えて改善したい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ページスピード改善で成果が変わる！画像・構造の見直し術 画像サイズとページ速度の関係を理解する｜表示速度を改善する実践テクニック リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴 リニューアル後の改善ロードマップ｜公開後90日でやるべき施策チェックリスト
2026/08/04
リニューアル・運用ノウハウホームページの404エラーとは？SEOへの影響と正しい対処法
404エラーとは？ページが見つからない時に表示される状態 404エラーとは、ユーザーがアクセスしたURLに、該当するページが存在しない時に返されるHTTPステータスコードです。 ホームページを閲覧していて、次のような表示を見たことがある方も多いでしょう。 「ページが見つかりません」 「404 Not Found」 「お探しのページは削除または移動された可能性があります」 これらは、サーバーには接続できているものの、指定されたURLにページが存在しないことを示しています。 404エラーが発生したからといって、必ずしもサイトに重大な不具合が起きているわけではありません。重要なのは、なぜ404になっているのかを確認し、状況に合った処理をすることです。 404エラーが発生する主な原因 404エラーが発生する原因は、主に次のようなものです。 ページを削除した 古いサービスや終了したイベントなどのページを削除した場合、旧URLへアクセスすると404になります。 ページのURLを変更した リニューアルやサイト構造の変更でURLが変わり、旧URLから新URLへの転送が設定されていないケースです。 リンク先のURLが間違っている サイト内のリンクに入力ミスがある場合、存在しないURLへ移動してしまいます。 ユーザーがURLを間違えて入力した URLのスペルミスや文字の入力漏れでも404が発生します。 外部サイトに古いURLが掲載されている 取引先やポータルサイト、過去のSNS投稿などに旧URLが残っている場合もあります。 リニューアル直後に404が急増した場合は、URL変更に伴う301リダイレクトの設定漏れを最初に疑う必要があります。 404エラーはSEOに悪影響を与える？ 結論として、正しく返されている404エラーが存在するだけで、サイト全体の検索順位が下がるわけではありません。 Googleも、存在しないURLが正しい404レスポンスを返している場合、通常はサイトの検索パフォーマンスに影響しないと説明しています。 したがって、存在したことのないURLや、代替ページのない削除済みページまで、無理に修正する必要はありません。 ただし、次のような404は問題になります。 検索流入があった重要ページが404になっている 外部サイトからリンクされているページが404になっている サイト内の主要導線が404へつながっている リニューアル後に大量の404が発生している XMLサイトマップに404のURLが残っている 問題なのは404というステータスそのものではなく、本来ユーザーを案内すべきページが失われ、検索流入や導線が途切れていることです。 404エラーを修正すべきケース・修正しなくてもよいケース ページのURLを変更した場合 ページの内容は残っているものの、URLだけを変更した場合は、旧URLから新URLへ301リダイレクトを設定します。 例 旧URL /service-old/ 新URL /service/ この場合、旧URLを404のままにすると、検索評価や外部リンクからの流入が途切れる可能性があります。 ページを統合した場合 複数のページを1ページへまとめた場合は、それぞれの旧URLから統合先へ301リダイレクトを設定します。 ただし、内容の関係が薄いページへ無理に転送するのは避けましょう。旧ページで説明していた内容を引き継いだ、関連性の高い受け皿ページへ転送することが重要です。 ページを完全に削除した場合 ページを完全に削除し、代わりとなるページも存在しない場合は、404を返して問題ありません。 Googleは、コンテンツを完全に削除し、関連する代替ページがない場合は、404または410を返す方法を案内しています。また、Google検索では410も404と同じように扱われます。 「404があるとSEOに悪い」と考え、関係のないトップページへ転送する必要はありません。 サイト内のリンク先が間違っている場合 自社サイト内のリンクミスで404が発生している場合は、リンク先を正しいURLへ修正します。 特に確認したい場所は次のとおりです。 グローバルメニュー フッターメニュー バナー 記事内の内部リンク 事例からサービスページへのリンク 問い合わせボタン PDFや画像へのリンク サイト内リンクの間違いは、ユーザーの離脱だけでなく、検索エンジンによるページ発見にも影響するため、優先的に修正します。 Googleも、ページの発見やサイト内の関係性の理解にリンクが利用されると説明しています。 存在したことのないURLの場合 ユーザーの入力ミスや、不正なボットによって生成されたURLなど、もともと存在したことのないURLが404になる場合があります。 このような404は、基本的に修正しなくても問題ありません。 ただし、同じ入力ミスが繰り返されている場合や、外部サイトから間違ったURLでリンクされている場合は、正しいページへの転送を検討します。 301リダイレクトと404の正しい使い分け 301リダイレクトと404は、次の基準で使い分けます。 ページが移動した → 新しいURLへ301リダイレクト 複数ページを統合した → 内容を引き継いだ統合先へ301リダイレクト 同じ内容の代替ページがある → 関連性の高い代替ページへ301リダイレクト ページを完全に削除し、代替ページがない → 404または410 存在したことのないURL → 404のままで問題なし 避けたいのは、すべての404をトップページへ一括転送する方法です。 ページの内容とトップページの関連性が低い場合、ユーザーは探していた情報にたどり着けません。また、Googleからソフト404と判断される可能性があります。 Googleも、存在しないページをホームページなどへ転送したり、robots.txtでブロックしたりする対応を控えるよう案内しています。 ソフト404とは？通常の404との違い ソフト404とは、実際にはページが存在しない、または「ページが見つかりません」と表示されているにもかかわらず、サーバーが正常表示を示す「200」のステータスを返している状態です。 通常の404 ページが存在しない → HTTPステータスも404 ソフト404 ページが存在しないように見える → HTTPステータスは200など ソフト404になると、ユーザーにも検索エンジンにもページの状態が正しく伝わりません。 よくある原因は次のとおりです。 404ページを表示しているがステータスコードが200 削除ページをすべてトップページへ転送している 内容がほとんどないページを公開している 検索結果が0件のページを正常ページとして返している Googleは、存在しないページで404や410以外のコードを返したり、無関係なページへ転送したりすると、ソフト404として扱われる可能性があると説明しています。 404ページを使いやすくする改善ポイント ページが見つからないことを明確に伝える まずは、ユーザーに現在の状況を分かりやすく伝えます。 例 「お探しのページは見つかりませんでした」 「ページが移動または削除された可能性があります」 「URLが正しく入力されているかご確認ください」 専門用語だけでなく、ユーザーが次に何をすればよいかまで説明することが大切です。 トップページや主要ページへの導線を設置する 404ページに行き止まりしかないと、そのまま離脱されてしまいます。 次のようなリンクを設置しましょう。 トップページ サービス一覧 制作実績・導入事例 よくある質問 お知らせ・ブログ お問い合わせ ただし、サーバーが返すステータスコードは正しい404のままにします。 404ページ内にリンクを設置することと、URL自体をトップページへ転送することは別です。 サイト内検索や問い合わせ導線を用意する ページ数が多いサイトでは、サイト内検索を設置すると目的の情報を探しやすくなります。 また、サービスや商品を探しているユーザーを取りこぼさないように、問い合わせ導線を設置する方法もあります。 例 「お探しのサービスが見つからない場合は、お問い合わせください」 「ご相談内容に応じて担当者がご案内します」 404ページも、ユーザーを正しい情報へ戻すための導線として設計できます。 404エラーの確認方法 Google Search Consoleで確認する Google Search Consoleでは、インデックス関連のレポートやURL検査を使って、404として認識されているURLを確認できます。 確認するポイントは次のとおりです。 重要ページが404になっていないか サイトマップに記載したURLが404になっていないか リニューアル前のURLが大量に404になっていないか ソフト404が発生していないか リダイレクトエラーが出ていないか ただし、Search Consoleに404が表示されたからといって、すべてを修正する必要はありません。 そのURLに流入や代替ページがあるかを確認してから判断します。 サイト内リンクをチェックする サイト内のリンク切れは、定期的に確認しましょう。 目視だけでは漏れが出るため、ページ数が多い場合はリンクチェックツールやクロールツールを活用します。 特に確認したいのは次の場所です。 共通メニュー 古い記事 過去のキャンペーンページ 事例ページ PDF・画像ファイル 外部予約システムへのリンク リニューアル後は旧URLを重点的に確認する リニューアル後は、旧URLと新URLの対応表をもとに確認します。 旧URLへアクセスする 正しい新URLへ転送されるか確認する 最終ページが正常に表示されるか確認する 多段リダイレクトになっていないか確認する 転送先の内容が旧ページと関連しているか確認する 公開直後だけでなく、Search Consoleの情報が更新される期間も継続して確認します。 404エラー対応でよくある失敗 すべての404をトップページへ転送する 関連性のない一括転送は、ユーザーを迷わせ、ソフト404の原因にもなります。 404をrobots.txtでブロックする 検索エンジンがページの状態を確認できなくなるため、404を隠す目的でのブロックは避けます。 重要ページの404を放置する 流入や被リンクがあるページは、関連する新ページへ引き継ぐ必要があります。 404ページを正常な200ステータスで表示する 見た目だけ404でも、ステータスが200ならソフト404になる可能性があります。 404をゼロにすること自体を目標にする 存在しないURLが正しい404を返すのは正常です。 数を減らすことではなく、重要な導線が失われていないかを確認します。 404エラーチェックリスト 旧URLと新URLの対応表を作成している 移動したページには301リダイレクトを設定している 完全に削除したページは正しい404または410を返している すべての旧URLをトップページへ一括転送していない 404ページが200ステータスを返していない サイト内のリンク切れを確認している XMLサイトマップから削除済みURLを除外している Search Consoleで404・ソフト404を確認している 外部リンクや検索流入のあるURLを把握している 404ページに主要ページへの導線を設置している まとめ：すべての404を消すのではなく、原因に合わせて処理する 404エラーは、存在するだけでサイト全体のSEO評価を下げるものではありません。 重要なのは、404になっている理由を確認し、次のように処理を分けることです。 ページを移動したなら301リダイレクト 関連する代替ページがあるなら適切なページへ転送 完全に削除したなら404または410 サイト内リンクの間違いならリンクを修正 存在したことのないURLなら基本的に対応不要 リニューアル後やページ整理後は、404・リダイレクト・内部リンクをまとめて確認し、検索流入とユーザー導線を守りましょう。 無料相談 Refuでは、サイト内の404調査から、旧URLと新URLの整理、301リダイレクト設定、内部リンク修正、Search Consoleでの公開後確認まで一括で対応しています。 「リニューアル後に404が増えた」「どのURLを転送すべきか分からない」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 コンテンツ移行で失敗しないために｜旧サイト資産の棚卸しと移行判断基準 SEOを落とさないページ統合・削除の進め方｜残す/統合/消す判断基準と301設計 Googleサーチコンソールの基本操作と改善への活かし方
