ホームページ公開後にGA4とSearch Consoleで最初に確認すること

ホームページを公開した直後に、GA4のユーザー数やSearch Consoleの表示回数が少ないからといって、成果が出ていないとは判断できません。公開当日に先に確かめるべきなのは、「計測データが届いているか」「問い合わせなどの重要な操作を一度だけ数えられるか」「Googleが公開URLへ到達できるか」の三点です。

この三点が確認できていない状態でアクセス数や検索順位を比べても、サイトの反応ではなく、計測漏れや公開設定の違いを見ている可能性があります。反対に、公開直後の確認結果と日時を残しておけば、数日後や数週間後に数字が変わったとき、サイトの変化なのか、設定変更の影響なのかを切り分けやすくなります。

GA4は「サイトへ来た後の行動」を確認する道具、Google Search Consoleは「Google検索からサイトがどう見えているか」を確認する道具です。役割が異なるため、どちらか一方だけを開くのではなく、公開確認、計測確認、検索エンジンからの発見確認を順番に分けて進めます。

※GA4とSearch Consoleの画面名・配置は2026年8月8日確認時点です。権限や段階的な画面更新によって表示が異なる場合があります。設定を変更する前に、対象のプロパティと公開URLが合っているかを確認してください。

公開直後に決めるのは「良い数字」ではなく、確認の基準日

公開日の数字には、複数の時間軸が混ざります。ホームページは公開操作が完了すれば見られますが、GA4の通常レポートは受信したデータを処理してから表示します。Search Consoleも、GoogleがURLを発見し、クロールし、インデックス登録の判断をした後に情報が増えていきます。三つを同じ速さでそろうものとして扱うと、「公開は成功しているのに検索データがない」「自分で見たのに通常レポートが増えていない」といった誤解が起きます。

そこで公開直後は、成果を採点する日ではなく、今後の比較に使える起点を作る日と考えます。確認するのは、サイトが一般公開されていること、GA4がテスト操作を受信できること、Search Consoleで正しいサイトを管理できることです。問い合わせ数、検索表示回数、検索順位などの成果指標は、計測と発見の土台を確認してから観察します。

確認する層	公開直後に確かめること	この時点で決めないこと
公開状態	主要ページが外部端末から開き、フォームや電話導線が動く	売上や問い合わせの成否
GA4	自分の訪問と重要操作が、正しいプロパティへ届く	ユーザー数が多いか少ないか
Search Console	所有権、サイトマップ、主要URLの取得可否を確認する	初日の表示回数や順位の良し悪し

基準日として残したいのは、公開日時、確認した担当者、GA4のプロパティ名とウェブデータストリーム、テストしたページと操作、Search Consoleのプロパティ、サイトマップの状態、URL検査の結果です。測定IDや認証用情報を公開資料へ書く必要はありません。社内の運用メモに、後から同じ対象を開ける程度の情報を残します。

公開作業と確認作業を別の人が担当する場合は、確認開始前に「どのURLが本番か」「旧サイトから切り替えた時刻はいつか」「フォームや予約の送信先はどこか」を共有します。URLの末尾やサブドメインが違うだけでも、別の計測先や別プロパティを見てしまうことがあるためです。

図：公開直後は、GA4の受信確認、重要操作の実テスト、Search Consoleの発見確認を行い、結果と確認日を基準メモへ残します。

GA4は、まず自分の訪問が届くかをリアルタイムで確かめる

最初にGA4のリアルタイムを開き、公開サイトへ自分でアクセスします。可能なら、管理画面へログインしていないブラウザ、シークレットウィンドウ、または別のスマートフォンを使います。ホームページを一度開くだけではなく、トップページからサービスページ、問い合わせページなど、公開後に特に見てほしいページへ実際の導線で移動してください。

リアルタイムで確認したいのは、単に「ユーザーが1人増えたか」だけではありません。現在見ているページ、ページタイトル、発生したイベントが、想定している公開URLと一致しているかを見ます。旧ドメイン、テスト環境、別のGA4プロパティへ送っていると、数字は表示されても本番サイトの確認にはなりません。

主要ページを順に開き、ページ単位の抜けを探す

トップページの訪問が見えたら、次に公開直後の確認対象を三〜五ページほど選びます。すべてのページを同時に開くより、ページごとに時刻をずらして移動したほうが、どの操作がどのイベントに対応したかを追いやすくなります。

• トップページ：本番ドメインと基本のページ表示が計測されるか
• 主要なサービス・商品ページ：テンプレートが異なるページでも計測されるか
• 問い合わせページ：フォームを開くまでの遷移が記録されるか
• 公開日に追加した新しいページ：タグや同意管理の組み込み漏れがないか
• 外部サービスへ移動する直前のページ：離脱前までの動きが確認できるか

トップページだけが見えて下層ページが見えない場合は、GA4全体の停止と決めつけず、該当テンプレートにGoogleタグやGTMコンテナが入っているか、キャッシュが古いHTMLを配信していないかを確認します。反対に、下層ページだけ二重に表示される場合は、テーマとプラグイン、直接設置とGTMなど、複数の方法で同じタグが入っていないかを調べます。

リアルタイムに出ないときは、設定変更より条件を切り分ける

自分の訪問がすぐに見えない場合でも、いきなりタグを入れ直さないでください。広告ブロック機能、ブラウザの追跡防止、Cookie同意の状態、社内アクセス除外、ログイン中ユーザーの除外、タグの公開忘れなど、データが届かない理由は複数あります。まず別端末・別回線で同じページを一度開き、条件を一つだけ変えて再確認します。

リアルタイムは受信確認に向く一方、集客経路を確定するための最終レポートではありません。とくに新しい訪問の参照元情報は、処理前の段階では限定的なことがあります。公開当日は「訪問とイベントが届くか」を判断し、参照元やチャネルの評価は通常の集客レポートが処理された後に行うと、画面ごとの役割を混同しません。

問い合わせなどの重要操作は、数より先に「一度だけ届く」を試す

ページ表示が届いたら、次はサイトで最も重要な操作を一つ選んで実テストします。問い合わせフォームが中心なら正常送信、電話相談が中心なら電話リンクのタップ、予約サービスが中心なら予約画面への遷移などです。公開初日にすべての補助イベントを検査するより、事業上の成果に最も近い操作が欠けず、重複せず届くことを優先します。

テストでは、サイト側の結果とGA4側の結果を同じ時刻で照合します。フォームなら、完了画面が出ただけでなく、通知メールや管理画面など運用側で一件受け付けられたかを確かめます。そのうえで、DebugViewやリアルタイムに想定したイベントが一回だけ表示されるかを見ます。実際の受付が一件なのにイベントが二回出るなら二重計測、受付済みなのにイベントが出ないなら欠落です。

同じテストで照合する場所	期待する結果	ずれたときに先に疑うこと
サイト・受付側	正常送信が一件だけ保存・通知される	フォームの送信先、エラー、迷惑送信対策
GTM・タグ側	成功時だけ対象タグが一回動く	広すぎるトリガー、二重設置、公開忘れ
GA4側	想定イベントが正しいプロパティへ一回届く	イベント名、測定先、同意状態、反映待ち

送信ボタンのクリックと問い合わせ成立は同じではありません。入力エラーや通信失敗でもクリックは発生します。公開後の受け入れ確認では、何を「成立」と数えているかを一文で説明できる状態にしておくことが重要です。設定方法やフォーム方式ごとの詳しい検証は、GA4で問い合わせを計測する方法｜キーイベント設定とテスト手順で分けて解説しています。この記事では、公開時に一回の実テストと受信結果をそろえるところまでを確認範囲とします。

テストには実在する顧客の個人情報を使わず、「公開確認用」など運用側で識別できるテスト情報を使います。また、メールアドレス、氏名、相談内容などをGA4のイベント名やパラメータへ送らないようにします。必要なのは、誰の問い合わせかではなく、どの操作が、いつ、何回成立したかです。

キーイベントに指定した直後は、リアルタイムやDebugViewでイベント受信を確認できても、通常レポートの集計が同時にそろうとは限りません。公開当日の合否は、実受付とリアルタイムの結果を先に残し、翌日以降の通常レポートで大きなずれがないかを追います。

内部アクセスと別ドメイン遷移は、公開直後の基準を濁らせる

公開日は、制作会社、社内担当者、経営者などが何度もサイトを開きます。そのままでは、初日のアクセスの多くが確認作業になることがあります。一方で、内部アクセスを急いで除外すると、自分のテストまで見えなくなり、「タグが動いていない」と誤判断することがあります。公開確認では、除外すること自体より、現在どの条件で除外されているかを把握することが先です。

内部トラフィックは、定義・フィルタ状態・テスト方法を一組で見る

GA4で内部トラフィックを扱う場合は、社内IPなどの定義と、データフィルタの状態を確認します。フィルタがテスト中なのか有効なのか、公開確認に使う端末や回線が対象に入るのかを記録してください。固定IPがない在宅勤務やモバイル回線では、IPだけで全担当者を正確に分けられないこともあります。

公開初日のテストは、内部除外の対象外になる回線を一つ用意すると分かりやすくなります。たとえば社内Wi-Fiではなくスマートフォン回線から開き、リアルタイムで確認します。除外設定を変更する場合は、変更前の状態、変更時刻、変更理由を残します。後から数字が急に減ったとき、サイトの利用が減ったのか、社内閲覧を除外した結果なのかを説明できるようにするためです。

外部フォームや予約・決済へ移る場合は、実際の一往復で確認する

問い合わせ、予約、決済などで別ドメインへ移動するサイトは、トップページの受信確認だけでは足りません。自社で管理する複数ドメインを一つの利用経路として計測する場合はクロスドメイン測定、第三者サービスから戻る参照元を調整する場合は不要な参照の除外など、構成に合った設定が必要です。どちらを使うかは、ドメインの所有関係とタグを設置できる範囲で変わります。

確認では、サイトから外部画面へ進み、完了後に戻るところまで実際に通ります。途中で新しいセッションに分かれていないか、参照元が自社ドメインや決済サービス名へ置き換わっていないか、重要操作が二回発生していないかを確認します。設定名だけを見て完了とせず、実際の導線で結果を見ることが大切です。

なお、外部サービスを参照元から除外すれば常に正しいわけではありません。新しい利用者を連れてくる外部サイトまで除外すると、集客経路を見えにくくします。公開時には、どの遷移だけを一続きにしたいのかを図やメモで明確にし、その範囲に合わせて設定します。

Search Consoleは、正しいプロパティと所有権から確認する

GA4の受信確認と並行して、Search Consoleで本番サイトを管理できる状態かを確認します。最初に見るのは検索順位ではなく、選択しているプロパティです。URLプレフィックスプロパティでは、https://とhttp://、wwwの有無、サブドメイン、ディレクトリの違いが対象範囲に影響します。公開したURLと、画面左上で選んでいるプロパティが一致しているかを確認してください。

ドメインプロパティを使う場合は複数のプロトコルやサブドメインをまとめて確認できますが、所有権確認の方法や社内の権限管理がURLプレフィックスとは異なります。どちらが上位という話ではなく、運用したい範囲に合っていることが重要です。既存サイトからURL構成を変えた場合は、旧プロパティだけを見続けていないかも確認します。

次に、担当者が所有権確認済みの状態でアクセスできるかを見ます。制作会社のアカウントだけが確認済みで、社内担当者が閲覧できない状態では、公開後の確認や引き継ぎが止まりやすくなります。少なくとも、誰が確認済みオーナーで、誰が日常確認を担当するかを社内メモに残します。

所有権の確認方法を変更したり、DNSやHTMLファイルを削除したりすると、後から確認状態を失うことがあります。公開作業でDNSを切り替えた場合は、Search Consoleへ入れることだけでなく、所有権確認に使った記録が維持されているかを確認します。不要な確認方法を整理する場合も、別の確認方法と管理者が残っていることを確かめてから行います。

サイトマップの状態と主要URLの検査を組み合わせる

Search Consoleのプロパティが正しければ、次にサイトマップを確認します。サイトマップのURLが本番環境のものか、送信履歴の状態が成功か、最終読み込みに不自然な古さがないかを見ます。リニューアルでドメインは同じでもCMSやサイトマップの場所が変わった場合、旧URLの送信履歴だけが残っていることがあります。

サイトマップが正常に読み込まれていることは、GoogleへURLの候補を伝えられる状態を意味します。ただし、サイトマップに入れたページがすべて直ちにインデックス登録される保証ではありません。公開確認では「サイトマップを送信した」と「主要ページが取得・登録できる状態」を別々に確認します。

URL検査は、代表するページを選んで行う

すべてのURLを一件ずつ検査するのではなく、構造の異なる代表ページを選びます。トップページ、最重要のサービスページ、問い合わせページ、公開日に追加した記事や実績ページなどです。同じテンプレートのページを何十件も選ぶより、ヘッダーやタグの入り方、公開設定、正規URLが異なる可能性のあるページを含めたほうが、公開漏れを見つけやすくなります。

• Googleのインデックスに登録された情報：Googleが最後に把握したURL、正規URL、クロール状態を確認する
• 公開URLのライブテスト：現時点でGoogleがページを取得できるか、インデックス登録を妨げる明確な条件がないかを確認する
• ページのHTMLと公開設定：noindex、robots.txt、ログイン制限、サーバーエラー、意図しないリダイレクトを確認する
• 正規URL：検査したURL自身が正規として扱われる想定か、別URLへ統合する設計かを確認する

URL検査の「登録済みの情報」と「ライブテスト」は時間軸が違います。登録済みの情報はGoogleが以前取得した状態、ライブテストは現在の取得可否を確認するものです。リニューアル直後に古いタイトルや旧URLが表示されても、ライブテストが新しい公開状態を取得できていれば、反映待ちとして観察する余地があります。反対に、ライブテストでも取得できない場合は、待つ前に公開設定やサーバー応答を確認します。

インデックス登録リクエストは、重要なURLをGoogleへ知らせる補助にはなりますが、登録を保証する操作ではありません。サイト全体の発見は内部リンクとサイトマップを整え、代表URLのライブテストで取得可否を確かめる、という順にすると、リクエストだけへ依存しません。

インデックス数と表示回数は、初日評価ではなく変化を見る起点にする

Search Consoleのページ インデックス登録レポートには、登録済みページだけでなく、登録されていない理由も表示されます。ここで「未登録」があること自体をすべて障害と扱う必要はありません。重複URL、別の正規URLへ統合するページ、意図的にnoindexにした完了ページなど、検索結果へ出さない設計も含まれるためです。

公開直後に見るべきなのは、想定外の理由が主要ページへ出ていないかです。たとえば、公開したサービスページがnoindexで除外されている、リダイレクト先が旧URLへ戻る、サーバーエラーで取得できない、正規URLがテスト環境を向いている、といった状態は優先して直します。一方、まだクロールされていないだけの新規URLは、サイトマップや内部リンクを確認したうえで経過を見ます。

検索パフォーマンスの表示回数、クリック数、検索クエリも、公開当日から十分に並ぶとは限りません。そもそもGoogleがページを表示する機会がなければ0のままですし、データの処理にも時間があります。初日の0を失敗と判定するのではなく、「最初に表示回数が発生した日」「最初に確認できたクエリ」「最初にクリックが発生したページ」を基準として記録します。

表示回数が出始めた後も、一日だけの増減で方針を変えません。公開ページ数、指名検索の有無、季節性、広告やSNSでの告知、既存ドメインからの移行など、サイトごとに条件が違います。まず同じ期間と同じページ範囲で変化を見て、ページが発見されているか、狙った内容と検索クエリがずれていないかを確認します。

GA4とSearch Consoleの数値は同じ意味ではありません。Search ConsoleのクリックはGoogle検索結果からサイトへ移動した回数、GA4のセッションやユーザーはサイト側で計測できた訪問です。Cookie同意、ブラウザ設定、時刻や集計方法の違いで一致しないことがあります。公開確認では完全一致を合格条件にせず、それぞれが本来の役割でデータを持ち始めているかを見ます。

設定を変える前に、公開後の確認メモを残す

公開後の確認は、画面を見て終わりにすると、数日後に同じ問題を再調査することになります。簡単な表でよいので、確認時刻、操作、結果、次の確認日を一行ずつ残します。スクリーンショットには対象プロパティ名や期間が分かる範囲を含めますが、測定ID、認証情報、テストに使った個人情報を社外共有用資料へ入れないようにします。

記録項目	公開直後の記録例	次に見るタイミング
公開情報	公開日時、本番URL、切り替え方法、確認担当	URLやDNSを変更したとき
GA4ページ受信	確認した端末・回線、主要URL、リアルタイムの結果	当日中と翌日
重要操作	テスト時刻、実受付件数、イベント名、受信回数	翌日以降の通常レポート
内部・別ドメイン	除外状態、テスト回線、外部遷移後の参照元	設定変更後
Search Console	プロパティ種別、所有権を持つ担当	担当変更・DNS変更時
サイトマップ	送信URL、状態、最終読み込み	更新やエラー発生時
主要URL検査	対象URL、登録情報、ライブテスト、正規URL	修正後と数日後
検索の起点	登録済み数、主な除外理由、最初の表示回数	同じ期間で定期確認

メモには「正常」だけでなく、確認できなかった理由も残します。たとえば「社内アクセス除外中のため社用回線では見えず、モバイル回線で確認」「外部予約サービスは別計測のため完了後の参照元を翌日確認」のように書きます。判断条件が分かれば、別の担当者が引き継いでも、同じ設定を不用意に作り直さずに済みます。

修正が必要な場合は、一度に複数の設定を変えません。タグの測定先、内部フィルタ、クロスドメイン、サイトマップ、noindexを同時に変えると、どの変更で直ったか分からなくなります。症状を「GA4に訪問がない」「実受付とイベント数が違う」「Googleが主要URLを取得できない」のように分け、一項目ずつ変更し、同じテストを再実行します。

公開直後の確認担当と、その後の運用担当が異なる場合は、基準メモの受け渡しまでを公開作業に含めます。公開できたこと、計測できたこと、検索に出る準備ができたことを分けて共有すれば、運用担当は成果評価を急がず、観察すべき数字と技術的な未対応を区別できます。

まとめ｜公開直後は計測と発見を確認し、判断の起点を残す

ホームページ公開後にGA4とSearch Consoleで最初に行うのは、成果の採点ではありません。GA4で主要ページの訪問が届くこと、問い合わせなどの重要操作が実受付と一致して一度だけ届くこと、内部アクセスや別ドメイン遷移の条件が把握できていることを確認します。

Search Consoleでは、公開URLに合うプロパティと所有権を確認し、サイトマップの状態と代表URLのライブテストを組み合わせます。インデックス数や表示回数は、初日の多寡ではなく、想定外の除外や取得エラーがないかを見たうえで、数日後以降の変化を追う起点にします。

最後に、確認日時、対象、操作、結果、変更点を基準メモへ残してください。公開直後の状態が記録されていれば、後から数字が動いたとき、サイトの利用変化と計測・検索設定の変化を分けて考えられます。