Webサイト公開後の検証チェックリスト

Webサイトは、公開ボタンを押した時点で検証が終わるわけではありません。公開後に初めて確認できるのは、本番HTMLが想定どおり返っているか、canonicalやrobotsが正しいか、構造化データが画面の内容と一致しているか、GA4のイベントが重複せず発火しているかです。

この記事では、Webサイト公開後の確認項目を、公開直後、24時間以内、7日後、28日後に分けます。公開直後の検証は実装の正しさを確認する作業、7日後と28日後の確認は検索エンジンの再クロールや利用者行動を観測する作業です。この2つを同じ「成果確認」として扱わないことが重要です。

リニューアル前のURL対応表、redirect、canonical、初期HTMLの準備は、WebサイトリニューアルでSEO・AI検索・問い合わせ計測を失わない方法で扱います。この記事は、公開された後に何を見るかに限定します。

結論：公開直後は「見られる・読める・測れる」を確認する

公開後の最初の判定は、検索順位や問い合わせ数ではありません。次の3つを確認します。

1. 見られる：主要URLが200で返り、redirect、canonical、robots、sitemapが意図どおりである
2. 読める：初期HTML、metadata、構造化データ、内部リンクに公開前の重要情報が含まれている
3. 測れる：CTAクリック、フォーム開始、フォーム送信などが正しい条件で一度だけ計測される

検索順位、AI検索への掲載、問い合わせ数は、公開直後に確定する指標ではありません。Googleも再クロールや検索結果への掲載を保証していないため、公開直後の合否と、一定期間後の観測結果を別の記録にします。

1. 公開直後に確認する項目

公開直後は、担当者がブラウザでトップページを眺めるだけでは不十分です。代表URLを一覧にして、取得結果・HTML・計測・表示を一つずつ記録します。

構造化データは、正しく書けば必ずリッチリザルトになるものではありません。Googleの公式ガイドも、構造化データは表示機能の対象になり得る手がかりであり、検索結果への表示を保証するものではないと説明しています。公開後は、画面に表示される情報とJSON-LDの値が一致しているかを先に確認します。

2. 24時間以内に確認するGA4とフォーム

GA4の確認は、標準レポートの数字を待つ前に、実際の操作でイベントを確認します。標準レポートに反映されるまで時間がかかる場合があるため、公開直後はRealtimeやDebugView、本番ブラウザのネットワーク通信を証拠にします。

イベントは「名前がある」だけでは検証になりません。対象ページ、パラメータ、発火回数、発火条件、同意状態、送信後の状態を一緒に記録します。同じクリックでタグが二重に発火していないか、フォームの再読み込みで送信イベントが重複しないかも確認します。

3. 7日後に確認する検索と公開状態

7日後は、公開直後の技術確認では見えない移行漏れを確認する時点です。検索データの増減を成果と断定するのではなく、GoogleがどのURLを取得し、どのURLを登録対象として扱っているかを調べます。

• Search ConsoleのURL検査で、代表URLの取得状態とcanonicalを確認する
• 新旧URLのredirectエラーや、旧URLの意図しない404を確認する
• sitemapに掲載したURLと、公開対象の一覧を突き合わせる
• 内部リンクから孤立したページがないかを確認する
• GA4で、公開後にイベントが急減・急増していないかを基準日と照合する
• フォーム受信件数とGA4の送信イベントを、個人情報を含めず件数だけ照合する

Search ConsoleのURL検査は、検索結果への掲載を保証する機能ではありません。取得できたこと、canonicalが選ばれたこと、検索結果に掲載されたことは別の状態として記録します。

4. 28日後に評価する項目

28日後は、公開前に保存した基準期間と比較します。ここで初めて、表示回数、クリック数、CTR、自然検索セッション、CTAクリック、フォーム送信、問い合わせの質を並べます。

28日という期間は、当社の運用目安です。更新頻度が低いサイト、季節性が強いサイト、公開期間が短いページでは、別の比較期間を設定します。公開後に別の広告、記事、価格、サービス変更が入った場合は、同じ表に変更日を記録します。

5. AI検索の確認は同じ質問を再実行する

AI検索や生成AIでの説明は、検索順位のような単一の固定値ではありません。確認するときは、会社名、サービス名、地域、課題を含む質問文を保存し、同じ質問を同じ条件で再実行します。

記録する項目は次のとおりです。

• 質問文
• 実行日と時刻
• 利用した検索サービスやモデル
• 会社・サービスが説明されたか
• 参照・引用されたURL
• 誤っていた説明
• 前回から変わった点

AI検索で表示された、引用された、問い合わせが増えたという因果は、観測だけでは確定できません。回答の変化を記録し、公式ページの事実整合性や引用されるページの構造を確認する材料として使います。

6. 検証記録を改善仕様へ変換する

検証で「canonicalが違う」「フォーム送信が二重」「JSON-LDと画面の料金が不一致」と分かっても、担当者と完了条件がなければ修正は止まります。1件ごとに次の項目を持たせます。

仕様書の14項目と記入例はWeb改善仕様書の書き方へ委譲します。この記事では、公開後に異常を見つけたときの記録の入口だけを扱います。

よくある質問

公開翌日の検索順位でリニューアルの成否を判断できますか？

できません。公開翌日は技術的な反映確認を優先します。検索エンジンの再クロール、検索結果の変化、利用者の行動には時間差があるため、事前に決めた期間で観測します。

構造化データのテストが通れば公開後の確認は不要ですか？

不要ではありません。公開後のHTMLに実際に出ているか、画面の情報と一致するか、対象外ページへ誤出力されていないかを確認します。テスト通過は一つの確認であり、検索結果への表示を保証しません。

GA4の数字がまだ出ない場合は0件と記録しますか？

0件と未計測を分けます。DebugViewで発火を確認できても標準レポートに反映されていない場合があります。確認時刻、対象イベント、見ているレポートを記録します。

まとめ

Webサイト公開後の検証は、次の順番で進めます。

1. 公開直後に、URL、redirect、canonical、robots、sitemap、HTML、JSON-LD、リンク、フォームを確認する
2. 24時間以内に、GA4イベントとフォーム受信を実操作で確認する
3. 7日後に、Search Consoleの取得状態、移行漏れ、計測の異常を確認する
4. 28日後に、基準期間との変化と同時期の変更を並べて観測する
5. 異常は対象URL・事実・変更・完了条件の改善仕様へ変換する

公開後に何を見ればよいかを先に決めると、検索順位だけでリニューアルを評価する状態から抜けられます。SIGNALの無料診断では、公開情報をもとに最初に確認すべきURLと事実を整理します。検索順位、AI回答への掲載、問い合わせ数を保証するものではありません。

参考：

• Google Search Central「サイトの再クロールをリクエストする」
• Google Search Central「構造化データの概要」
• Google Analytics「イベントを設定する」