2026年10月8日にGoogleのURL移行、web.dev Web Vitals、GA4のトラフィック・セッション資料を再確認した。緊急対応、原因調査、公開計画を分け、フォーム障害の対応で観測期間を待たない。LCP 2.5秒、INP 200ms、CLS 0.1と端末別75パーセンタイルは性能確認の参考で、流入別4%と1%から全体34/1000=3.4%が16/1000=1.6%へ変わる架空例は、構成・分母・期間を示す教材である。URL変更を伴う公開は対応表・転送・サイトマップ・移行後監視・低アクセス時期を含めるが、順位の一時変動はあり得る。
問い合わせが減った、更新に時間がかかる、新サービスを載せられない。サイトを見直すきっかけはさまざまです。ただし、「作ってから何年経ったか」や「不満がいくつ出たか」だけでは、全面リニューアルを始める時期は決まりません。
まずすぐ直す問題、原因を調べる問題、公開時期を計画する問題を分けましょう。フォームが使えないのに数か月観察を続けることと、季節性のあるアクセスの一時的な減少で全面制作を決めることを、同じ判断で扱わないためです。
30秒で要点
- 緊急の不具合、原因を調べる問題、公開時期の計画を分ける。障害は観測期間を待たずに対応する。
- 問い合わせ率は流入元や分母も確かめる。全体の率や性能の単発測定だけで全面制作を決めない。
- URL移行の確認と公開後の担当・戻す条件を揃えて、次の判断日を決める。
先に、今すぐ対応が必要かを確かめる
表が収まらない場合は、横にスクロールできます
| 状況 | 最初の対応 | 全面リニューアルとの関係 |
|---|---|---|
| フォームが送れない、重要情報を開けない | 不具合を確認し、修正または代替手段を案内する | 作り直す結論を待たずに対応する |
| 数字が突然下がった | 計測の変更、障害、広告、流入元を確認する | 数字だけで原因をサイトと決めない |
| 更新のたびに制約に当たる | 更新履歴と手戻りを集める | 部分改修と土台の変更を比較する |
| 商品や対象者が変わった | 必要な情報と現状の差を整理する | 情報構造の変更が必要か検討する |
セキュリティ上の問題が疑われる場合は、保守担当者と対応を進めてください。複数のシグナルや一定の観測期間を待つ条件はありません。緊急対応後に、同じ問題を繰り返さないための土台の見直しを検討します。
問い合わせ率の低下が、サイトの劣化とは限らない
次は説明用の架空例です。同じ定義の相談を数え、流入元ごとのセッションと相談があったセッションを比較します。件数は実績ではありません。
表が収まらない場合は、横にスクロールできます
| 期間 | 自然検索 | 広告 | 全体 |
|---|---|---|---|
| 変更前 | 800中32＝4% | 200中2＝1% | 1,000中34＝3.4% |
| 変更後 | 200中8＝4% | 800中8＝1% | 1,000中16＝1.6% |
全体の割合は3.4%から1.6%へ下がっています。しかし、自然検索は4%、広告は1%のままです。この例では、割合の低い広告からの訪問が増えたことが、全体の割合を下げています。全体の低下だけでは、サイトが悪くなったとは言えません。
実際には、同じ流入元の中でも対象者やページが変わることがあります。この比較だけで原因を確定せず、流入元、ページ、端末、キャンペーン、計測の変更履歴を確認します。
GA4のセッション キーイベント レートは、キーイベントが発生したセッションを総セッション数で割った指標です。キーイベントの回数、ユーザー数、フォームに到達したセッション数を分母にした率と混ぜないでください。Google アナリティクスの定義
技術的な課題は、利用者の体験と更新作業から見る
「点数が低い」「CMSが古い」という言葉だけでなく、何ができなくなっているかを書きます。スマートフォンで文章が読めない、押したボタンの反応が遅い、編集担当者が安全に原稿を更新できない、といった観測です。
表示や操作の性能には、GoogleのCore Web Vitalsを参考にできます。良好な目安はLCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下で、モバイルとデスクトップを分けた75パーセンタイルを見ます。単発の測定値や、制作を始める合否条件とは違います。Web Vitalsの公式説明
Lighthouseのような模擬環境の測定は、改善箇所を調べる材料になります。実利用者のデータを置き換えるものではなく、利用者の操作がない測定ではINPを直接測れません。性能の問題が見つかっても、画像、スクリプト、特定の導線の改善で解ける可能性を確かめます。
観測期間は、必要な判断材料から決める
「2つ以上の不満が数か月続けば作り直す」という普遍的な基準はありません。低頻度の相談なら件数が集まるまで時間が必要ですし、季節性のある事業なら同じ季節との比較が役立ちます。障害はその期間を待ちません。
検討の記録には、次の情報を並べてください。
- 困っている利用者と、できなくなっている行動。
- 観測期間、件数、指標の分子と分母。
- 同じ期間の広告、商品、価格、計測、サイト変更。
- 部分改修で試したことと、残っている制約。
- いつまでに判断材料を集め、誰が次の案を決めるか。
数字が少ない場合は、問い合わせ担当者の記録や利用者への確認も使います。数件の感想を全利用者の割合として扱わず、何が起きたかを知る材料として残してください。
公開日は、移行の確認と対応体制に合わせる
作り直す方針を決めても、完成したデザインだけで公開日を決めないことが大切です。URLが変わるなら、旧新URLの対応と転送、内部リンク、サイトマップ、計測、重要なフォームを確認する時間が必要です。
GoogleはURL変更を伴う移転で、可能ならアクセスの少ない時期を選び、変更を同時に詰め込まず、移転後の旧新URLを監視するよう案内しています。検索結果の変動も起こり得るため、公開翌日の検索流入だけで成功・失敗を決めません。Google 検索セントラルの移行手順
公開後に問題を確認する人、問い合わせに対応する人、元に戻す条件も、日付と一緒に決めます。低アクセスの時間でも、対応できる担当者がいなければ、問題の発見や復旧が遅れることがあります。
次の判断を、いま決められる形にする
「今月作り直すか」という大きな問いに、すぐ答える必要はありません。「フォームの送信を今日確認する」「広告と自然検索を分けて比較する」「更新担当者と制約を整理する」なら、次に行うことが具体的になります。
問題の範囲と原因の候補が整理できたら、作り直す前の判断の軸で、作る・直す・待つ・別の打ち手を比較してください。外部からの要望がきっかけなら、リニューアルを求められたときの整理も判断材料になります。