最終確認：2026年9月5日
今あるホームページの問題点は、見た目の好みから探すのではなく、①止まっている機能、②会社が期待する役割、③検索での見つかり方、④ページを見た人の行動、⑤文章と使いやすさ、⑥表示速度や安全性の順に確認します。
各ページについて「何のためのページか」「根拠は何か」「次に何を直すか」を一行で残し、影響が大きく確かめやすい問題から三つに絞ると、調査だけで終わりません。
最初に、急いで直す問題がないか確認する
アクセス数を見る前に、問い合わせや応募を受けられない、電話番号が古い、リンク先がなくなっているといった問題を確認します。数字が良くても、利用者の行動が最後で止まっていれば会社の窓口としては機能していないためです。
| 先に見るもの | 確認方法 | 見つかったとき |
|---|---|---|
| 問い合わせ・応募・購入 | テスト情報で最初から完了まで操作し、会社側の通知も見る | 受付できない問題を最優先で直す |
| 電話・住所・営業時間 | ヘッダー、フッター、会社案内、地図、構造化データを比べる | 正しい一つの情報へそろえる |
| 主要リンク | サービス、料金、事例、相談へのリンクを実際に開く | 404、意図しない転送、別会社への誤リンクを直す |
| 公開状態 | シークレットウィンドウとスマートフォンで見る | ログイン中だけ見える状態や表示崩れを切り分ける |
| 安全性 | HTTPS、更新、管理者、バックアップ、警告を確認する | 公開作業を増やす前に保守担当へ共有する |
安全面の確認は、中小企業向けホームページのセキュリティ対策で、更新、権限、復元、事故時の初動まで確認できます。
調査表には、感想ではなく事実を残す
「古く見える」「分かりにくい」だけでは、直す範囲も完了条件も決まりません。ページごとに、目的、見てほしい人、期待する行動、見つかった事実、証拠、対応、担当、期限を記録します。
| 記録欄 | 記入例 |
|---|---|
| ページ | 採用情報 / URL |
| 役割 | 仕事と応募条件を伝え、募集要項へ進んでもらう |
| 見つかった事実 | スマートフォンで応募ボタンが画面外にある |
| 証拠 | 実機画面、確認日、端末名、該当箇所 |
| 対応と完了条件 | ボタン位置を修正し、320pxと390pxで押せることを確認 |
| 担当・期限 | 制作担当 / 9月12日 |
最初から全ページを同じ深さで調べると時間がかかります。まず、トップページ、主要サービス、料金、事例、会社案内、問い合わせ・応募など、会社にとって重要なページから始めます。リニューアルを考えている場合は、残す・統合・転送を決めるURL棚卸しへ調査表をつなげます。
手順1：ホームページの目的と期待する行動を決める
問題とは、目的と現在の状態の差です。目的が曖昧なままでは、アクセス数、デザイン、記事数のどれを改善すべきか判断できません。ホームページ全体で一つ、重要ページごとに一つ、主な役割を言葉にします。
- 会社を知ってもらい、安心して相談してもらう
- 商品やサービスの違いを理解し、料金や事例を確認してもらう
- 仕事内容と働く環境を伝え、募集要項や応募へ進んでもらう
- 既存顧客が必要な資料や連絡先を迷わず見つけられるようにする
ページの役割が複数ある場合は、最初に見てほしい順を決めます。「全部伝える」ではなく、読んだ人が次に何を判断できればよいかまで書くと、文章やボタンの不足を見つけやすくなります。
手順2：検索で見つかる状態を確認する
Search Consoleでは、検索結果での表示回数、クリック数、クリック率、検索語、ページを確認できます。まずページ単位に絞り、会社が答えたい質問で表示されているかを見ます。
| 見え方 | 考えられること | 次の確認 |
|---|---|---|
| 表示回数がほとんどない | ページが登録されていない、検索需要と内容がずれている、評価材料が不足している | URL検査、サイト内リンク、検索語と本文の一致 |
| 表示はあるがクリックが少ない | タイトルや説明が検索意図と合わない、競合の答えが明確 | 検索語ごとの順位と実際の検索結果 |
| 想定外の検索語で表示される | ページの主題や見出しが曖昧 | 中心回答、タイトル、H1、重複ページ |
| 急に減った | 期間、季節、計測、技術、検索結果の変化など複数の可能性 | 前年・前期間比較、URL検査、変更履歴 |
URL検査には、Googleが把握している登録状態と公開ページのライブテストがあります。同じものではないため、修正直後のライブテストだけで検索結果への反映を確定しません。SEO全体の優先順位は、中小企業のSEO対策の基本、タイトルの見直しはページタイトルの書き方で詳しく確認できます。
手順3：アクセス数より、ページの役割に合う行動を見る
GA4の「ページとスクリーン」では、ページごとの表示、利用時間、イベント、設定済みのキーイベントなどを確認できます。ただし、数字だけで原因は決まりません。問い合わせ送信を計測していなければ、問い合わせが少ないのか、計測できていないのかを先に分けます。
- サービスページから料金、事例、問い合わせへ進んでいるか
- 採用ページから募集要項や応募へ進んでいるか
- 記事から関連サービスや次に読む記事へ進んでいるか
- 電話、外部予約、地図など、GA4だけでは把握しにくい行動を別記録で確認できるか
GA4の直帰率は、エンゲージメント率の反対として計算されます。高いか低いかだけで良し悪しを決めず、一ページで電話番号を確認して目的を達成した人や、計測していない外部行動がないかを考えます。見る数字と判断手順は、中小企業のアクセス解析で見る項目、離脱ページの絞り込みはGA4で問題ページを特定する方法へつなげます。
手順4：文章と情報が、今の利用者の疑問に答えているか見る
ページを開いた人が、最初の画面で「自分に関係がある」「知りたい答えがありそう」と分かるかを確認します。検索語だけを足すのではなく、営業や電話で実際に聞かれる質問を集めます。
- 冒頭で、誰のどんな疑問へ答えるページか分かる
- サービス内容、対象、料金の考え方、期間、進め方、対応範囲が矛盾していない
- 会社独自の判断、実際の手順、写真、根拠があり、一般論だけで終わらない
- 古い日付、終了した制度、退職者、旧住所、提供していない内容が残っていない
- 著者、確認日、参考資料が必要なページで分かる
Googleも、検索順位だけを目的に量産するのではなく、読者が目的を達成できる、根拠と独自性のある内容かを自己点検するよう案内しています。確認予定は、更新計画と担当を編集カレンダーへ整理する方法で管理できます。
手順5：スマートフォンとキーボードで実際に操作する
自動検査だけでは、言葉の分かりやすさ、押しやすさ、入力の迷いは分かりません。会社のパソコンだけでなく、実際のスマートフォンで主要ページとフォームを操作します。
| 見る場所 | 確認すること |
|---|---|
| 見出しと文章 | 文字が小さすぎず、長い言葉が不自然に分かれず、意味が順に伝わる |
| メニュー | 開閉でき、現在地と閉じ方が分かり、キーボードでも操作できる |
| ボタンとリンク | 押せると分かり、具体的な行き先が書かれ、近すぎるボタンがない |
| 画像と表 | 切れや重なりがなく、代替テキストや必要な横スクロールがある |
| フォーム | ラベル、必須、エラー、確認、完了、会社側の通知まで分かる |
端末ごとの具体的な確認は、スマートフォン表示の7つの実機チェックを使えます。W3CのWCAGは、知覚、操作、理解、堅牢性という観点でアクセシビリティを確認する国際的な基準です。自動スコアだけで合否を決めず、キーボードと実際の読み方も確認します。
手順6：表示速度とWordPressの状態を確認する
PageSpeed Insightsは、ページの表示性能をモバイルとパソコンで調べ、改善候補を示します。一回の点数だけを目標にせず、遅い画像、読み込みを妨げる処理、画面のずれ、操作への反応など、利用者が困る原因を見ます。
- 代表的な一ページだけでなく、トップ、サービス、記事、フォームなど種類ごとに測る
- 同じURLでも測定条件で結果が変わるため、変更前後を同じ条件で比べる
- Search ConsoleのCore Web Vitalsに十分な実利用データがない場合は、「問題なし」と決めつけない
- WordPressの「ツール」→「サイトヘルス」で、重大な問題、推奨改善、構成情報を確認する
- 更新、バックアップ、フォーム、表示をまとめて保守・運用の点検項目へ残す
問題は、影響・根拠・直しやすさで優先順位を決める
見つかった項目をすべて「至急」にすると進みません。次の四つを一件ずつ確認し、まず三件に絞ります。
| 判断軸 | 質問 |
|---|---|
| 影響 | 放置すると問い合わせ、応募、購入、信用、安全へどの程度影響するか |
| 範囲 | 一ページだけか、全ページや全利用者に及ぶか |
| 根拠 | 実機、問い合わせ記録、Search Console、GA4、エラーなどで確かめられるか |
| 直しやすさ | 小さな修正で確かめられるか、設計やシステム変更が必要か |
例えば、フォームが送れない問題はアクセス数が少ないページより先に直します。一方、「トップページが古く見える」は範囲が大きすぎるため、「主なサービスが最初の画面で分からない」「事例へのリンクが見つからない」のように、確認できる問題へ分けます。
一度に一つ変え、変更前後を同じ条件で確かめる
複数の場所を同時に変えると、どの修正が良かったのか、どれが不具合の原因か分かりにくくなります。変更前の画面、数値、文章、更新日時を残し、可能な範囲で一つずつ進めます。
- 問題、根拠、直す理由、完了条件を一行で書く
- 変更前のページ、数値、画面、設定を記録する
- 必要なバックアップを取り、できれば確認環境で試す
- 公開後にパソコン、スマートフォン、キーボード、フォーム、リンクを確認する
- すぐ分かる不具合と、時間が必要な検索・アクセス結果を分けて記録する
- 7日後、28日後など、次に見る日と判断する指標を決める
検索順位や問い合わせ数は公開直後に結論を出せません。表示崩れやフォーム不達は当日に、検索での見つかり方や利用者の行動は一定期間後に確認し、同じ台帳へ結果を追記します。
調査だけで終わらない90分の進め方
| 時間 | 行うこと | 残すもの |
|---|---|---|
| 0〜15分 | 目的、重要ページ、問い合わせ・応募・購入の状態を確認 | 止まっている問題と対象URL |
| 15〜35分 | Search ConsoleとURL検査を見る | 表示回数、クリック、検索語、登録状態 |
| 35〜55分 | GA4と社内の問い合わせ記録を見る | ページごとの行動と計測不足 |
| 55〜75分 | スマートフォン、キーボード、速度、WordPressを確認 | 画面、端末、再現手順 |
| 75〜90分 | 影響・範囲・根拠・直しやすさで三件に絞る | 担当、期限、完了条件、次の確認日 |
確認できる時間が短い場合も、ページを無作為に眺めるより、この順で一つずつ証拠を残します。継続する作業は毎日30分で回すホームページ改善へ分けられます。自社だけで原因を切り分けにくい場合は、現在のホームページの状況をご相談ください。
よくある質問
アクセス数が少ないページは削除したほうがよいですか？
アクセス数だけでは決めません。会社案内、採用条件、既存顧客向け資料など、少ない閲覧でも必要なページがあります。検索実績、固有情報、社内での役割、更新可能性、統合先、外部リンクを確認して判断します。
直帰率が高いページは悪いページですか？
直帰率だけでは判断できません。GA4ではエンゲージメントされなかったセッションの割合であり、一ページで用事を済ませた行動や、計測していない電話・外部予約が含まれる場合があります。ページの役割と合わせて見ます。
PageSpeed Insightsの点数は何点なら合格ですか？
点数だけを会社の合格基準にしません。モバイルとパソコン、実利用データと検査環境の結果、ページの種類を分け、利用者が待つ・押せない・画面が動く原因を優先して直します。
デザインを新しくすれば問題は解決しますか？
見た目の変更だけでは、目的の曖昧さ、古い情報、検索での未登録、計測不足、フォーム不達は解決しません。先に問題と証拠を整理し、部分修正でよいか、設計から見直すかを決めます。
調査はどのくらいの頻度で行いますか？
問い合わせ・応募・購入など重要な機能は定期確認と変更直後に、検索・アクセスの傾向は月ごとや四半期ごとに確認します。担当変更、料金変更、サービス変更、制度変更があったときは予定日を待たず見直します。
参考資料
- Google Search Central「有用で信頼性の高い、ユーザー第一のコンテンツの作成」（2026年9月5日確認）
- Google Search Console「Google におけるパフォーマンス」（2026年9月5日確認）
- Google Search Console「URL 検査ツール」（2026年9月5日確認）
- Google Analytics「ページとスクリーンのレポート」（2026年9月5日確認）
- Google Analytics「エンゲージメント率と直帰率」（2026年9月5日確認）
- Google for Developers「About PageSpeed Insights」（2026年9月5日確認）
- Google Search Console「Core Web Vitals レポート」（2026年9月5日確認）
- WordPress.org「Site Health screen」（2026年9月5日確認）
- W3C WAI「How to Meet WCAG」（2026年9月5日確認）
