はじめに
第45章では、
何を成果として見るか
を決めました。
ここからは、そのデータを使って、
何を変えるか
を考えます。
ホームページは、公開した瞬間にはまだ答えが出ていません。
実際に公開して初めて、
- どんな検索で見つかる？
- どのページが読まれる？
- どこから問い合わせが来る？
- 何を聞かれる？
- どこで離脱する？
というデータが集まり始めます。
つまり公開は、
完成ではなく、観察の開始
です。
改善とはデザインを変えることではない
ホームページ改善というと、
- 色を変える
- 写真を変える
- レイアウトを変える
ことを想像しがちです。
もちろん、それが必要な場合もあります。
でも本来の改善は、
現在と目的の差を小さくすること
です。
そして、その目的は第12章で決めたものです。
たとえば目的が問い合わせなら、
「デザインが古いか？」
より先に、
必要な人に届いている？
↓
内容は伝わっている？
↓
相談する理由がある？
↓
相談方法が分かる？を考えます。
何を観察する？
一つの数字だけでサイトを判断しません。
たとえば、
Search Console
+
GA4
+
問い合わせ
+
お客様の声
+
ビジネス目的を組み合わせます。
Search Consoleは第43章。
GA4は第44章。
成果の測り方は第45章で扱いました。
第46章では、それらを改善へつなげます。
最初に目的を確認する
改善する前に、
「このサイトは何のためにある？」
を確認します。
目的はサイトによって違います。
- 問い合わせ
- 予約
- 商品購入
- 来店
- 資料請求
- 採用
- 情報提供
目的が違えば、同じ数字でも意味が変わります。
さらに、ビジネスが変化すれば目的自体が変わることもあります。
第12章で決めた目的が、
今も正しいか
まで確認します。
事実と仮説を分ける
たとえば、
問い合わせが少ないこれは事実かもしれません。
でも、
CTAの色が悪いからは仮説です。
この2つを混ぜないことが大切です。
考え方は、
観察
↓
仮説
↓
追加確認
↓
変更
↓
再計測です。
Search Consoleから改善する
たとえば、
Impressionsは増えている。
でもClicksが増えない。
そこで、いきなりタイトルを書き換えるのではなく、
- どのQuery？
- どのページ？
- Average Positionは？
- 検索意図と内容は合っている？
を確認します。
第43章で見たデータを、ここで実際の改善判断へつなげます。
GA4から改善する
Searchからサイトへ来た後は、GA4などを使って行動を確認します。
第45章で決めたキーイベントや途中指標も参考になります。
ただし、
「滞在時間が短いから悪い」
のように、一つの数字だけで決めません。
目的をすぐ達成して帰った可能性もあります。
数字は、
答えではなく、確認する場所を教えるもの
として使います。
問い合わせ内容は強いデータ
アクセス解析 ツールだけがデータではありません。
実際に、
- 電話で聞かれたこと
- LINEで相談されたこと
- 問い合わせフォームで質問されたこと
- 店頭でよく聞かれること
も重要です。
同じ質問が何度も来るなら、
サイト上で説明が足りない可能性があります。
FAQ、サービスページ、ブログ記事などへ反映できます。
改善候補に優先順位をつける
改善案は増えます。
全部同時にやる必要はありません。
初心者なら、
効果が大きそう？
×
作業量はどれくらい？くらいの簡単な考え方でも十分です。
たとえば、
「問い合わせ ボタンがモバイルで見えない」
なら優先度は高いでしょう。
一方、
「フッターの文字間隔を2px変える」
は後でもよいかもしれません。
一度に全部変えない
トップページの文章。
写真。
CTA。
メニュー。
フォーム。
全部同時に変更すると、
結果が良くなっても、
何が効いたのか分かりにくくなります。
必ず一項目ずつである必要はありませんが、
「何を良くするための変更なのか」
が追える単位で進めます。
コンテンツを改善する
公開後に見えてくる検索クエリやお客様の声から、
- 説明不足
- 分かりにくい言葉
- 新しい質問
- 古くなった情報
- 足りない事例
などを見つけます。
新しい記事を増やすだけが改善ではありません。
既存ページを強くする方が良い場合もあります。
内部リンクを改善する
良い記事があっても、必要なページへつながっていなければ読者は迷います。
たとえば、
ブログ記事
↓
詳しいサービス説明
↓
FAQ
↓
相談のように、読者が自然に次へ進めるか確認します。
具体的な内部リンク設計は第37章で扱いました。
CTA・フォームを改善する
CTAは、
「目立たせれば良い」
ではありません。
- 何をすると？
- 何が起きる？
- 誰向け？
- 不安はない？
が伝わっているか確認します。
第45章でCTAクリックはあるのにフォーム送信が少ないと分かったなら、
CTAの先やフォーム側を確認する理由になります。
トップページも改善対象になる
第23章では、トップページを「表紙 + 案内板」として設計しました。
公開後は、
- ヒーローで意味が伝わっている？
- 主なサービスへ進んでいる？
- CTAが使われている？
- モバイルで順番は自然？
をデータとお客様の声で見直します。
トップページは一度作って固定するページではありません。
モバイルで確認する
制作はPCで行うことが多くても、訪問者はスマートフォンかもしれません。
改善後は、
- 文字
- ボタン
- メニュー
- 画像
- フォーム
- CTA
を実機またはモバイル表示で確認します。
速度も定期的に見る
ページへ機能や画像を追加していくと、サイトが徐々に重くなることがあります。
第40章で扱った表示速度も、公開後に再確認します。
ただし、
「スコア 100を取る」
こと自体を目的にしません。
ユーザー体験やビジネス目的とのバランスを見ます。
変更したら記録して再計測する
変更を記録する
改善を続けるほど、
「いつ何を変えた？」
が分からなくなります。
簡単でよいので、
| 日付 | 8 / 9 |
| URL | service |
| 変更 | CTA文章変更 |
| 理由 | 相談内容を明確化 |
| 結果 | 後日確認 |
のように残します。
これは人間だけでなく、AIと改善を続けるときにも重要です。
過去の変更理由が残っていれば、
AIも「なぜ今の形になっているのか」を理解しやすくなります。
再計測する
変更したら終わりではありません。
一定期間後に、
「どうなった？」
を確認します。
結果は、
- 良くなった
- 変わらない
- 悪くなった
- まだ判断できない
のどれでも構いません。
重要なのは、
変更を学習へ変えること
です。
定期的に見直す
月1回の見直し例
小規模サイトなら、まず月1回程度から始めても構いません。
□ 第45章で決めた主要成果
□ Search Console
□ GA4
□ 問い合わせ
□ メインページ
□ モバイル
□ 速度
□ 古い情報
□ 改善候補
□ 前回変更の結果ソフトウェア 更新は第41章。
セキュリティは第42章。
バックアップは第32章。
ここではサイトの成果とコンテンツを中心に見ます。
数か月ごとの見直し例
もう少し長い期間では、
- 目的は変わっていない？
- 主なサービスは変わった？
- 顧客の質問は変わった？
- よく読まれるページは？
- 読まれなくなったページは？
- 新しく必要なコンテンツは？
- ナビゲーションは今のサイトに合っている？
など、サイト全体を見直します。
ホームページは学習する仕組みになる
改善を続けると、
第12章
目的を決める
↓
第23章
トップページとサイトを設計する
↓
公開
↓
第45章
成果を測る
↓
第46章
改善する
↓
目的を見直すという循環ができます。
この循環が回り始めると、ホームページは単なる会社案内ではなく、
顧客とビジネスを理解するための仕組み
にもなります。
今回のポイント
- 第45章で決めた成果指標を改善判断に使う
- 改善はデザイン変更ではなく目的との差を埋めること
- Search Console / GA4 / 問い合わせ / お客様の声を組み合わせる
- 事実と仮説を分ける
- 改善候補には優先順位をつける
- 一度に全部変えない
- トップページも公開後の改善対象
- 変更理由を記録する
- 変更後は再計測する
- 最後に第12章の目的自体も見直す
今回の視点
ホームページは、
「作って置いておくもの」
ではありません。
何のために作る？
↓
どう見せる？
↓
うまくいった？
↓
何を変える？を繰り返します。
そして、ときには、
そもそも今の目的でよいか
まで戻る。
その循環があることで、ホームページは完成品ではなく、
学習しながら育つ仕組み
になります。
Part 7｜公開後に運用・計測・改善する