Webサイト運用スケジュールで使う週次・月次・四半期の確認表

Webサイトの運用スケジュールを作るとき、すべての確認を同じ頻度にそろえる必要はありません。問い合わせができない状態は、次の月次確認まで待てない問題です。一方で、検索流入の増減は、短い期間だけを見ても改善の判断材料にならないことがあります。

先に決めたいのは、何曜日に作業するかではありません。その問題をいつまでに見つけたいか、判断にはどの記録が必要か、確認後に誰が動くかです。ここが決まると、週次・月次・四半期という区分にも意味が生まれます。

この記事では、重大な問題を随時対応へ分けたうえで、定例確認の役割を組み立てます。最後に掲載する空欄の確認表へ記入すれば、自社の担当と次に対応を引き継ぐ相手まで含む運用スケジュールを作れます。

運用スケジュールは判断の期限から作る

確認する頻度は、作業の種類だけでは決まりません。放置したときに影響が広がる速さと、判断材料がそろうまでの時間を分けて考えます。

たとえば、問い合わせフォームを利用できない状態は、見つけた時点で対応の要否を判断したい問題です。週次の予定に入れるだけでは、発生した曜日によって確認までの時間が変わります。通知や監視で把握できるなら、その検知を対応のきっかけにします。

検索流入や問い合わせの傾向は、見方が異なります。最新の一日だけで結論を出すと、曜日や施策による一時的な変化を原因だと思い込むことがあります。比較する期間と条件をそろえ、次に調べるページを選ぶ場が必要です。

さらに、重点商材や契約条件とのずれは、Web担当者だけでは直せません。事業や営業の判断を持つ人が参加できる機会へ置きます。この三つを分けると、随時・週次・月次・四半期の役割を決めやすくなります。

公開直後の確認と障害対応は随時行う

随時対応に分けるのは、検知してから次の定例日まで待つことで影響が広がる問題です。随時とは、担当者が画面を常に見張ることではありません。問題を知ったときに、確認と連絡を始められる状態を指します。

候補になるのは、問い合わせを完了できない状態や主要ページを表示できない状態です。実際と異なる提供条件を公開している場合も、気づいた時点で確認します。セキュリティに関する通知は、週次の作業一覧へ混ぜません。自社で決めた基準に照らし、影響の範囲と緊急性を確認できる担当へ渡します。

GOV.UKのサービス監視に関する手引きでは、技術的な数値だけでなく、利用者が目的の操作を完了できるかを見る考え方が示されています。BtoBサイトなら、問い合わせや資料請求など、自社にとって重要な操作へ置き換えて考えられます。ただし、この資料がすべてのサイトへ同じ監視体制を求めているわけではありません。

ページを公開した直後の確認も、次の週次まで先送りしません。変更した箇所と、その変更が影響し得る導線を公開環境で確かめます。どこまで確認するかは変更内容によって異なるため、すべての公開に同じ時間や検査項目を当てはめる必要はありません。

週次では見逃した異常と未対応の問題を確認する

週次確認は、随時対応だけでは拾えなかった問題を見つけるための安全網です。ここでサイト全体の改善案を出し切ろうとすると、異常の確認と改善会議が混ざってしまいます。

まず見るのは、事業への影響が大きい導線です。問い合わせ手段と主要なサービスページについて、利用者が目的を完了できるかを確かめます。直近で変更したページも確認の対象です。前回までに見つけた問題が未処理なら、現在の担当と次の判断日も確認します。

何を週次確認に含めるかは、サイトの状況によって変わります。週を待てない問題は随時対応へ移します。反対に、毎週見ても判断材料が増えないものは月次へ移せます。週次という区分を守ることより、見つけたい時期と確認日が合っていることのほうが大切です。

確認結果は「見た」で終わらせません。異常がなかったのか、対応が必要なのか、別の調査へ渡すのかを記録します。担当者が不在でも、次の人が状態を読み取れるところまでが週次確認です。

月次ではデータの比較条件をそろえる

月次確認では、一定期間の記録を見比べ、次に詳しく調べる対象を選びます。この場で複数のページを一度に直すのではなく、変化が起きている場所と、判断に足りない情報を分けます。

自然検索を確認する場合、Search ConsoleではGoogle検索でページが表示され、クリックされるまでの状況を見ます。Google Analyticsでは、検索以外も含む流入経路と、サイトを訪れた後の行動を見ます。両者は観測する範囲が異なるため、Search Consoleのクリック数とGoogle Analyticsのセッション数が一致することを確認作業のゴールにはできません。Googleの両データを使う手引きでも、それぞれを異なる基準として使う考え方が説明されています。

直近の数値を使うときは、データが処理中ではないかも確かめます。Search Consoleの検索パフォーマンスには通常2〜3日の遅れがあり、暫定値は後から変わることがあります。Google Analyticsも処理中の値が更新されます。詳しい条件は、GoogleのSearch Consoleのデータに関する説明とGoogle Analyticsのデータ鮮度に関する説明で確認できます。

前月と今月を比べるなら、同じ日数までを見るのか、完了した月どうしを見るのかを先に決めます。曜日の並びや未完了の日を含んでいないかも確かめます。数字が動いた理由を考える前に、比較条件の違いで生じた変化を分けるためです。

Googleは、Search Consoleを毎日見る必要はなく、月に一度程度またはサイトの内容を変更したときに確認すると案内しています。新しい問題が見つかった場合は、Search Consoleからメール通知を受け取れます。これはSearch Consoleの基本的な利用頻度についての案内です。問い合わせ記録や営業情報まで含むWebサイト運用全体に、月次が適していると保証するものではありません。

月次では検索データと問い合わせ記録から改善対象を選ぶ

検索データだけで改善対象を決める必要はありません。実際の問い合わせ内容、商談で繰り返し受ける質問、現在案内しているサービス条件を合わせて見ます。そのうえで、次に調べるページと理由を一つ残します。改善案が複数出た場合は、その場の声の大きさで着手順を決めず、Webサイト改善のバックログへ渡します。

四半期ではサイトと事業のずれを見直す

四半期確認で見るのは、個別ページの小さな変化よりも、サイトが現在の事業に合っているかです。重点的に案内したい商品が変わっても、サイトの入口や導線が以前のままなら、月次の数値だけを見ても直す方向を決められません。

事業責任者や営業担当者と、増やしたい相談を確認します。受けられる案件の条件や、説明に時間がかかっている内容も聞き取ります。サイトに載っている価格や契約条件が古くないかも見ます。対象外の問い合わせが続いているなら、入口で誰に向けた情報か伝わっているかを検討します。

四半期は、すべての会社に共通する推奨周期ではありません。サービスや条件が変わったときは、次の四半期まで待たずに確認します。事業の見直しが半年ごとに行われる会社なら、その機会へ合わせる判断もできます。

この場で残したいのは、細かな修正項目の長い一覧ではなく、どの方向を変えるかという判断です。ページを追加するのか、重複した説明をまとめるのか、既存ページを直すのかを決めます。一つの記事を直すと決まった後の確認は、SEOリライトの監査手順へ引き渡せます。

一枚の確認表に担当と完了条件を記入する

運用スケジュールは、確認項目を並べただけでは動きません。実施のきっかけと判断する担当者を決めたうえで、完了条件と結果を読む人も定めると、次の対応へつなげられます。次の表は本文の要約ではなく、自社の運用項目を記入する空欄の確認表です。一つの重要な導線または運用項目につき一枚を使い、複数を管理する場合は表ごと複製してください。

「担当者」には、画面を見る人だけでなく、異常時に判断する人も書きます。担当者へすぐ連絡できるように、表のセルには連絡先も添えます。

「判断結果」には、異常の有無と次に調べる対象を記入します。方針を変えると決めた場合は、その結論も残します。「完了条件」は単に作業済みとせず、次の人が状態を読み取れる内容にします。

「実施時期」は、カレンダーの日付に限りません。通知やページの公開を起点にできます。提供条件が変わったときに確認する項目も置けます。運用してみて確認が遅すぎる、または判断材料がまだそろわないと分かったら、その理由を記録して周期を変えます。

問い合わせフォームを最初の対象に選ぶなら、「確認事項」を「フォームが表示されるか」だけにしません。送信した内容が受付先へ届き、担当者が読める状態までを自社の完了地点として書きます。送信操作をする人と受信を確かめる人が異なる場合は、両方の担当と連絡先を残します。こうすると、画面を開いただけで確認済みになるのを防げます。

運用を始めた後に確認頻度を見直す

確認表へ最初の予定を入れても、その周期が自社に合っているとは限りません。実際に使った結果から、早める項目と間隔を空ける項目を分けます。

顧客や営業担当者から連絡を受けて初めて異常に気づく状態が続くなら、現在の確認では遅い可能性があります。影響が大きい問題は、通知を起点にした随時対応へ移せないかを検討します。すべての表示上の違いを緊急扱いにせず、利用者が目的を完了できるかで対象を絞ります。

反対に、毎回見ても「まだ判断できない」という結果が続く項目は、確認する間隔が短すぎるかもしれません。必要な記録がいつそろうかを確かめ、次回の日付を置き直します。データが少ないことを異常とみなして、変更を急ぐ必要はありません。

問題を見つけても対応へ進まない場合は、周期より引き渡し方を見直します。判断できる担当者が書かれているか、完了条件が共有されているかを確かめます。確認の回数を増やしても、次に動く人が決まっていなければ同じ問題が残ります。

確認結果は種類ごとに次の担当へ渡す

同じ確認表を使っても、見つかった内容によって次の行き先は変わります。不具合と改善候補では、動ける担当が異なります。事業方針とのずれまで一つの作業として扱うと、誰が判断するのか曖昧になります。

利用者が目的を完了できない問題は、影響を確認できる担当へ渡します。表示上の小さな違和感でも、主要な導線を妨げているなら後回しにしません。対応後は、何を直し、どこまで再確認したかを元の記録へ戻します。

成果を良くするための変更案は、根拠と期待する変化を添えて改善バックログへ入れます。記事の検索意図や説明を見直す場合は、対象ページを決めてからリライト手順へ進みます。重点商材や契約条件とのずれは、Web担当者だけの修正にせず、決定できる人へ判断を返します。

この引き渡しまで決めておけば、定例確認は報告会で終わりません。次の担当は、なぜその作業が必要になったのかを記録から確認できます。

最初は重要な導線を一つだけ予定に入れる

初めからサイト全体の確認項目を埋めようとすると、表を作ること自体が大きな作業になります。まずは、問い合わせや商談への影響が大きい導線を一つ選びます。

その導線について、定例日まで待てない状態は何かを決めます。次に、週次で拾う異常を決めます。月次で見比べる記録と、事業側で見直す内容も分けます。

最後に、それぞれの担当と完了条件を確認表へ記入します。記録先と次に引き継ぐ担当まで書けば、その後に対応する人も分かります。

実際に運用すると、予定した日では遅い項目や、反対に毎回見ても判断できない項目が分かります。そのときに周期を変える根拠が残っていれば、担当者が変わっても運用スケジュールを見直せます。