SEO・Web改善の提案はどう判断する？ 施策を実装する前に確認したい7つのポイント

最近、実務でフォーム改善の提案をレビューする機会がありました。
あるBtoBサイトで、フォーム通過率を改善するために「入力項目を減らす」「ナビゲーションを削除する」「フォームを短く見せる」といった施策が提案されていたケースです。

どれもEFOではよく見かける改善案で、方向性として不自然なものではありません。
ただ、実装前にデータや既存の運用を確認していくと、「この数値だけで、この施策まで言い切ってよいのか」「一部の流入を見た分析を、全ユーザー向けのUI変更に広げてよいのか」など、いくつか確認したい点が出てきました。

そこで改めて感じたのが、Web改善では「誰が提案したか」よりも、「なぜその施策なのかを説明できるか」が重要だということです。

本記事では、この実際のフォーム改善事例をベースにしつつ、企業名・数値・具体的な仕様は一般化し、Web改善施策を実装する前に確認したい判断軸を整理します。

まず見るべきは「何を改善したい施策なのか」

最初に確認したいのは、意外と施策そのものではありません。最終的に何を良くしたいのかです。

たとえば「資料ダウンロードページを改善する」という話でも、

• 資料ダウンロード数を増やしたい
• フォームに到達した人の完了率を高めたい
• 検索流入からのCVを増やしたい
• ダウンロード後の問い合わせを増やしたい

では、取るべき施策が変わります。

フォームの完了率だけを考えれば、入力項目は少ない方が有利かもしれません。

しかし、フォームで取得している情報を営業担当者がリード選別に使っているなら、単純に項目を減らせばよいとは限りません。

Web上の数字を改善することと、事業成果を改善することは、必ずしも同じではありません。まず「この施策が成功したと言える状態は何か」の確認が必要です。

「数字が悪い」だけでは、原因までは分からない

アクセス解析をしていると、

• 「このページは直帰率が高い」
• 「このフォームはCVRが低い」

といった数字が見つかることがあります。

ここで注意したいのが、数字は現象を示してくれますが、原因まで教えてくれるわけではないことです。

例えばフォーム完了率が低いとしても、

• 項目が多すぎる
• 質問内容が分かりにくい
• そもそも資料への期待値が低い
• 流入しているユーザーと資料内容が合っていない
• 入力途中でエラーが発生している

など、さまざまな原因が考えられます。

「CVRが低いからフォームを短くする」は仮説としては成立します。でも、「CVRが低い＝フォームが長いことが原因」とまでは言えません。

ここを混同すると、数字は改善しないまま別のUXを悪化させてしまうことがあります。

相関と因果は分けて考える

似たページ同士を比較することもよくあります。

たとえば、「問い合わせフォームの完了率は高いのに、資料ダウンロードフォームは低い」というデータがあったとします。

確かに比較材料にはなります。

ただ、問い合わせをしようとしているユーザーと、「ちょっと資料を見てみよう」と考えているユーザーでは、行動意欲が違います。

問い合わせフォームの方が完了率が高いからといって、「問い合わせフォームのUIを資料ダウンロードにも採用すれば同じCVRになる」とは限りません。

UIの差なのか、ユーザーの意図の差なのか。比較データを見るときは、この2つを切り分けて考える必要があります。

分析したユーザーと、施策の対象ユーザーは同じか

個人的に、かなり重要だと思っているポイントです。

たとえばOrganic Searchから訪問したユーザーだけを分析して、「このページは離脱が多い」という課題が見つかったとします。

その結果としてページ全体のナビゲーションを削除すれば、影響を受けるのは検索ユーザーだけではありません。

メール、広告、Directなど、すべての流入経路のユーザーに同じUIが表示されます。流入元が違えば、ページを訪れる目的も違う可能性があります。

つまり、「一部のユーザーで見つかった課題」を「すべてのユーザーに適用する改善施策」へ変換してよいのかを確認する必要があります。

分析対象と施策対象がズレている場合は、対象ページを限定したり、まず小さく検証したりする方が適切な場合もあります。

ベンチマークは「正解」ではなく参考値

「一般的なBtoBサイトではCVR○％が目安です」こうしたベンチマークも、改善判断ではよく使われます。参考にはなりますが、私はその数字だけで良し悪しを決めないように心がけています。

同じBtoBサイトでも、

• 商材
• ユーザーの検討段階
• 流入チャネル
• フォームの目的
• ブランド認知
• 入力を求める情報

は違います。

平均より低いから問題、平均より高いから問題なし、というほど単純ではありません。

むしろ、自社サイトの過去データや同じ目的を持つページなど、条件の近いデータと比較する方が判断材料として有効なこともあります。

「短いフォーム」と「入力しやすいフォーム」は同じではない

一般的にEFOでは、フォームを短くすることがよく推奨されます。私自身、不要な項目は減らした方がよいと考えます。
ただし、画面上の高さを小さくすることと、ユーザーの負担を減らすことは別です。

たとえば、フォームを短く見せるために、最初から見えていたチェックボックスの選択肢をプルダウンの中へ隠した場合。確かに縦幅は短くなります。
一方でユーザーは、「どんな選択肢があるのか確認するために、一度操作する」必要が生まれます。

同じように、

• 離脱を防ぐためにナビをすべて消す
• CVを目立たせるために説明情報を大幅に減らす
• 入力項目を減らすために営業に必要な情報まで削除する

といった施策にも、それぞれトレードオフがあります。

CVRだけを見るのではなく、理解しやすさ、操作しやすさ、信頼感、回遊性など別のUXを悪化させていないか。私はここも実装前に確認したいポイントだとと考えています。

その仮説、改善後に検証できますか？

意外と忘れられがちなのが計測です。

「フォームで離脱している人が多いので改善しましょう」と考えても、そもそもフォーム開始を計測していなければ、本当にそこで離脱しているのか確認できません。

最低限でも、ページ到達 → フォーム開始 → 送信 → CVくらいの流れが取得できれば、改善前後を比較しやすくなります。

必要に応じて、

• CTAクリック
• 入力エラー
• 完了ページからの遷移

なども計測します。

施策を実装して数字が上がったとしても、何が効いたのか分からなければ、次の改善に知見をつなげることができません。改善施策と計測設計はできるだけセットで考えるようにしています。

アクセス解析では分からないこともある

そして、GA4などのアクセス解析だけでは判断できないこともあります。

たとえば、「このフォーム項目、営業担当者は実際に使っていますか？」という問いです。
これはGA4をいくら見ても分かりません。

CRMやSFAでどのように利用されているのか、営業担当者が問い合わせ対応時に参照しているのか。あるいは、資料をダウンロードしたユーザーが、30日後に問い合わせや商談へ進んでいるのか。

こうした情報まで考えるなら、Web解析だけでなく、実際の業務フローを見る必要があります。サイト改善とはいえ、Webサイトの中だけを見ればよいとは限らないのです。

Web改善の提案を受けたときに確認したい7つのこと

私自身は、施策を実装する前に次の7点を確認しています。

1. 何を改善したい施策なのか
2. その課題を示すデータは何か
3. 原因の仮説は、そのデータから説明できるか
4. 分析対象と施策の適用対象は一致しているか
5. 別のUXを悪化させる可能性はないか
6. 改善前後を同じ指標で検証できるか
7. 営業・運用・CRMなど、Web以外への影響はないか

すべての施策で完璧なデータが揃うわけではありません。むしろ実務では、分からないことの方が多いと思います。

それでも、「分からないけれど仮説として試す」のと、「正しいものとしてそのまま実装する」のではそもそもの意味が異なります。

提案は、誰が出したかではなく根拠で判断する

専門家の経験則やベンチマークには価値があります。
私自身もWebディレクターとして、経験から「この方法の方が良さそうです」と提案することがあります。

だからこそ、自分が提案する側でも、受け取る側でも、「なぜそう考えたのか」をできる限り説明できる状態にしておきたいと思っています。

提案を疑うことが目的ではありません。
専門家の提案も、社内から出たアイデアも、自分自身が考えた施策も、まずはひとつの仮説として扱う。

そして、課題 → データ → 仮説 → 施策 → 検証がつながっているかを確認する。

それが、Web改善を「なんとなく良さそうな施策の積み重ね」にしないための、大切な判断軸だと考えています。