GA4の計測確認｜設置後に本当に効いているかを自分で確かめる手順

Q: タグを設置したのにレポートに数字が出ません。何から見ればよいですか？

まず開発者ツールのNetworkタブを collect で絞り、/g/collect が2xx（実測では204）で飛んでいるかを見てください。飛んでいれば送信は成功しているので原因はGA4側（反映待ち・同意モード・データフィルタによる除外）です。飛んでいなければ設置側（タグ未設置・JSエラー・広告ブロッカー・キャッシュ）です。この一点で原因の置き場所が二分できます。

Q: 数字が実際の2倍になります。どう確認しますか？

1ページ表示あたりの「en=page_view を含み、かつ tid が自分の測定IDと一致するリクエスト」の本数を数えてください。2本あれば二重計測です。/g/collect というリクエスト自体は広告連携や後続の送信でも飛ぶため、本数だけでは判定できません。また _ga_ で始まるCookieが複数あっても二重計測の証拠にはなりません（過去のプロパティのCookieが残っているだけのことがあります）。

GA4（Googleアナリティクス4）の計測が効いているかどうかは、ブラウザの開発者ツールで collect へのリクエストが飛んでいるかを見れば、その場で判定できます。レポートに数字が出るのを24時間待つ必要はありません。

GA4の動作確認とは、ブラウザからGoogleの計測サーバーへリクエストが実際に送信され、正常なステータスで受理されていることを、自分の目で確認する作業のことです。GA4の管理画面はデータが「届いた後」しか映しません。届いていないのか、届いているのに表示されていないのかは、送信そのものを見ないと切り分けられません。

この記事では、測定ID（G-で始まるID）の取得とタグ設置から始めて、開発者ツールで合否を判定する手順、合格ライン、外れたときの分岐までを一続きで扱います。掲載している判定基準は、すべて筆者が実ブラウザで当サイトを読み込んで確認した実測にもとづいています（実測日 2026年8月2日）。

GA4とは｜UAはすでに終了し、いま計測できるのはGA4だけ

GA4とは、Googleが提供する無料のアクセス解析ツールの現行世代で、ページの表示やクリックなどをすべて「イベント」として記録する計測モデルを採用したものです。前世代のユニバーサルアナリティクス（UA）はすでに稼働しておらず、現在Googleアナリティクスと呼ばれているものはGA4を指します。

UAは2023年7月1日に計測停止、2024年7月1日の週にデータもAPIも消えた

Google公式のサポート終了アナウンス（Universal Analytics のサポート終了・2026年8月2日取得）には、次の2段階が明記されています。

2023年7月1日：標準のUAプロパティがヒットの処理を停止した（Starting July 1, 2023: Standard Universal Analytics properties stopped processing hits）
2024年7月1日の週：UAプロパティにもAPIにもアクセスできなくなり、データはすべて削除された。読み取り専用アクセスも残っていない（You won’t be able to access any Universal Analytics properties or the API (not even with read-only access), and all data will be deleted）

つまりUAは「使わなくなったツール」ではなく、プロパティごと存在しなくなったツールです。ウェブ上に残っている UA- で始まるIDを載せた設置手順は、コピーしても1件も計測されません。手元の設置コードに UA- があれば、それは動いていないコードです。

だから「UAとの違い」を学ぶ必要はもうない

比較対象が消えている以上、「UAとGA4はどう違うのか」を学んでも行動は変わりません。いま必要なのは違いの理解ではなく、UA時代の語彙をGA4のどこに読み替えるかという対応表だけです。読み替えが必要な人は、この記事の後半にある対応表だけを見れば足ります。

GA4を設置する｜測定IDの取得からタグ設置まで

すでにGA4を設置済みで、確認方法だけを知りたい場合はこの章を飛ばして次の章へ進んでください。

測定IDを取得する（管理 > プロパティ設定 > データストリーム）

Google公式ヘルプ（Find your Google tag ID・2026年8月2日取得）は、測定IDについて「通常は G- で始まる英数字の並び」と定義し、取得手順を次のように示しています。

GA4の「管理」を開き、「プロパティ設定」の下にある「データストリーム」をクリックする
対象のデータストリーム名をクリックする
「ストリームの詳細」に表示される測定ID（G- で始まる）をコピーする

なお、測定IDを取得するにはそのプロパティで編集者以上の権限が必要である点も公式に明記されています。権限が足りないと、そもそもこの画面にたどり着けません。

公式のGoogleタグ（gtag.js）をhead内のできるだけ上に置く

現行の公式スニペットは次の形です。Google公式の設置ドキュメント（Set up the Google tag with gtag.js・2026年8月2日取得／ページ最終更新 2026年7月30日）の記載と1行ずつ照合しています。G-XXXXXXXXXX の部分を、前項でコピーした自分の測定IDに置き換えてください。

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-XXXXXXXXXX');
</script>

置き場所について、公式は「計測したいすべてのページで、開いた <head> タグの直後に配置する」と指定しています。トラブルシューティングのガイド（Verify and troubleshoot your Google Analytics setup・2026年8月2日取得）でも、設置ミスの代表例として「タグが全ページに入っていない」「<head> 内の可能な限り上に置かれていない」の2つが挙げられています。

なぜ上部でなければならないのか、下の方に置いたときに何が起きるのかは、タグをhead上部に設置するべき理由とパフォーマンス影響で分解しています。設置位置の根拠が知りたい場合はそちらを参照してください。

WordPressでの設置先3パターンと選び方

WordPressでの設置先は実質3つです。どれを選んでも計測は成立しますが、2つ以上を同時にやってしまうと二重計測になります。これがこの記事の後半で扱う症状の最大の原因です。

設置先	向いている人	注意点
テーマの `header.php` に直接書く	テーマを自分で管理していて、PHPを触れる	親テーマを直接編集するとテーマ更新で消える。子テーマで行う
子テーマの `functions.php` から `wp_head` フックで出力する	テンプレートファイルを汚したくない	他のプラグインの出力と前後するため、head内での位置が下がりやすい
Site Kit by Google（プラグイン）に任せる	PHPを触らずに済ませたい	既存タグを検出するとコード配置を自動でオフにする（後述）

header.php と functions.php の役割分担や、子テーマでの安全な編集手順は WordPress header.phpとfooter.phpの作り方にまとめてあります。テンプレートを直接触るのが初めてなら、先にそちらを読んでから戻ってきてください。

Site Kit by Google はWordPress公式ディレクトリで配布されているGoogle製の公式プラグインです。配布ページのAPI情報（wordpress.org/plugins/google-site-kit・2026年8月2日取得）によれば、バージョン 1.184.0、必要なWordPressは 5.2 以上、必要なPHPは 7.4 以上、最終更新は 2026年7月27日です。

計測が本当に効いているかを自分で確かめる

ここがこの記事の本題です。GA4のレポートは反映に時間がかかるため、「数字が出ないのは待ち時間なのか、設置が失敗しているのか」が判断できません。ブラウザの開発者ツールなら、ページを1回読み込むだけで、送信されたかどうかが二値で確定します。

この方法はGoogle自身が公式に案内している確認手段でもあります。前掲のトラブルシューティングガイドは、即座に確認できる手段としてDebugView・Tag Assistant・ブラウザの開発者ツールの3つを挙げ、開発者ツールについては「サイトを移動しながら google-analytics.com/g/collect または analytics.google.com/g/collect へのネットワークリクエストを探す」と説明しています。

手順｜開発者ツールのNetworkを「collect」で絞る

確認したいページをChromeで開く
開発者ツールを開く（表示 > 開発 > デベロッパーツール、またはF12）
「Network」タブを選び、フィルタ欄に collect と入力する
その状態でページを再読み込みする
現れたリクエストの Name / Method / Status と、URLの tid= と en= を確認する

フィルタを開く前にページを読み込んでしまうと、最初のリクエストを取り逃します。開発者ツールを開いた状態で再読み込みするのが手順として重要です。広告ブロッカーやプライバシー拡張機能を入れている場合は、それ自体がリクエストを止めるため、シークレットウィンドウか拡張機能を無効にしたブラウザで確認してください。

合否ライン早見表

上から順に見て、5項目すべてが合格なら計測は効いています。どこかで外れたら、その行の右端に書いた「次にやること」を1つだけ実行してください。

見る場所	合格	外れたときに起きていること	次にやること（1つだけ）
① `collect` で絞った結果	`/g/collect` が1本以上ある	タグ未設置／JSエラーで停止／広告ブロッカーが遮断	ページのソースに `gtag/js?id=G-` があるか確認する。あればConsoleタブのエラーを見る
② リクエストのホスト	`analytics.google.com` または `google-analytics.com`	GA以外の解析ツールを見ている（`collect` は他社ツールも使う）	ホスト名を読み直し、GAのリクエストだけを対象にする
③ URLの `tid=`	自分の測定ID（`G-`〜）と完全一致	別プロパティに送っている（テーマとプラグインでIDが違う等）	データストリームで正しいIDを再確認し、設置箇所を1つに絞る
④ Method と Status	POST で 2xx（実測は 204）	4xx／5xx はリクエストが壊れている	手で書き換えたスニペットを公式の形に戻す
⑤ `en=page_view` の本数	1ページ表示につきちょうど1本	2本以上は二重計測。0本は設定コマンドが実行されていない	設置箇所を棚卸しして片方を外す（次章の症状③へ）

ステータスについて1点補足します。Google公式のトラブルシューティングガイドは「200 OK が送信成功を示す」と書いていますが、実際に返ってくるのは 204 No Content です。204はレスポンス本文を持たない成功ステータスなので、200でなくても問題ありません。判定は「2xxかどうか」で行ってください。この差は、公式の記述だけを見て「200が出ないから失敗だ」と誤判定しやすいところです。

実測サンプル｜実際に飛んだリクエスト

2026年8月2日に、当サイトの記事ページ1枚を実ブラウザで読み込んだときのネットワークログです（パラメータは判定に使うものだけ抜粋）。読者が同じページを開けば、同じ形のリクエストを再現できます。

[POST] https://analytics.google.com/g/collect
         ?v=2
         &tid=G-7Z6M3CJEV3
         &en=page_view
         &dl=https%3A%2F%2Fcodequest.work%2Fgtm-head-position-performance%2F
         &_s=1
       => 204

[POST] https://analytics.google.com/g/collect
         ?v=2
         &tid=G-7Z6M3CJEV3
         &_s=2
       => 204

注目すべきは、/g/collect は2本飛んでいるのに en=page_view は1本しかない点です。2本目は en= パラメータを持たない後続の送信で、ページ表示を二重に記録しているわけではありません。ここを読み違えると、正常なサイトを「二重計測だ」と誤診します。判定に使うのはリクエストの本数ではなく en=page_view の本数です。

つまずきやすい5つの落とし穴

いずれも、実際に測って初めて分かったものです。手順を機械的になぞるだけでは踏み抜きます。

ホスト名で絞ると片方を取りこぼす。 送信先は1つではありません。公式ガイド自体が google-analytics.com と analytics.google.com の2つを併記しており、当サイトの実測で実際に飛んだのは後者でした。google-analytics.com だけで絞ると1件もヒットせず、「計測されていない」と誤診します。だからパス文字列の collect で絞ります。
ただし collect で絞るとGA以外も混ざる。 実測では、GAのリクエストに混じって別の解析ツールのエンドポイント（j.clarity.ms/collect）も同じフィルタに引っかかり、こちらも204を返していました。ステータスだけ見て「飛んでいる」と判断せず、必ずホストと tid を確認してください。
メソッドはGETではなくPOSTである。 実測はすべてPOSTでした。開発者ツールのMethod列でGETだけを目で追っていると、飛んでいるのに見落とします。
/g/collect の本数で二重計測を判定しない。 前掲の実測どおり、正常な1ページ表示でも /g/collect は複数本飛びます。en= を持たない後続リクエストや、広告連携のイベント（en=ad_impression など）が含まれるためです。判定は「en=page_view かつ同一 tid」の本数だけで行います。
_ga_ で始まるCookieの個数は二重計測の証拠にならない。 実測時のブラウザには _ga／_ga_7Z6M3CJEV3／_ga_R2YZYY6PE1 の3つが残っていましたが、R2YZYY6PE1 は配信HTMLにもタグの配信ファイルにも1件も出現せず、実際に送信された tid は1つだけでした。過去に設置していたプロパティのCookieが消えずに残るため、Cookieを根拠にすると存在しない二重計測を追いかけることになります。

症状別の切り分け｜飛ばない・204なのに出ない・数字が2倍

前章の合否ラインで外れた場所によって、原因の置き場所が変わります。「送信側の問題」と「GA4側の問題」を混ぜて考えると、いつまでも切り分けられません。

症状①：リクエストが1本も飛ばない

送信側の問題です。原因は次の4つにほぼ絞られます。公式のトラブルシューティングガイドが挙げる代表例と一致します。

原因	確かめ方	直し方
そのページにタグが入っていない	ページのソースを表示して `gtag/js?id=` を検索する	全ページ共通のテンプレートに移す（1ページだけ入っていない状態をなくす）
JavaScriptエラーで止まっている	開発者ツールのConsoleタブに赤いエラーが出ていないか見る	エラーの発生元スクリプトを特定する。タグより前で止まっていると後続が実行されない
広告ブロッカー・プライバシー拡張機能	シークレットウィンドウ、または別ブラウザで開き直す	確認作業のときだけ無効にする（訪問者側の遮断は仕様として受け入れる）
キャッシュが古いHTMLを返している	ソース内にタグが無いのに、管理画面上は設定済みになっている	サーバー・プラグイン・CDNのキャッシュを削除してから再確認する

症状②：204で飛んでいるのにレポートに数字が出ない

送信は成功しています。ここから先はGA4側の話です。まず反映のタイミングを確認してください。公式のトラブルシューティングガイドは、データが見えるまでの時間を次のように示しています。

見る場所	反映までの目安	見るべき状況
DebugView	数秒	イベントとパラメータが意図どおりか確かめたいとき
リアルタイムレポート	数分	いま自分のアクセスが届いているかを見たいとき
通常のレポート	24〜48時間	ここで焦らない。設置直後に数字が無いのは正常

リアルタイムレポートは「レポート > リアルタイム」から開きます。公式ヘルプ（Realtime report・2026年8月2日取得）によれば、表示されるのは直近5分間と30分間のアクティブユーザーです。それより前のアクセスはこの画面には出ません。

数分待ってもリアルタイムに出ないなら、GA4側で除外されている可能性を疑います。公式ガイドが挙げる原因は、同意モード（ユーザーが同意するまでタグは発火しない）と、データフィルタ（管理 > データ設定 > データフィルタ）の2つです。自分のアクセスだけが出ない場合は、内部トラフィックの除外設定が効いていることがよくあります。

個々のイベントを1件ずつ追いたい場合はDebugViewを使います。公式ヘルプ（Monitor events with DebugView・2026年8月2日取得）によれば、画面は「管理 > データの表示 > DebugView」にあり、事前にデバッグモードを有効にする必要があります。自分の端末だけで有効にするなら Tag Assistant（tagassistant.google.com）を使うのが公式の案内です。サイト全体で有効にする場合は設定コマンドにパラメータを足します。

gtag('config', 'G-12345ABCDE', { 'debug_mode':true });

ここで確実に踏む罠が1つあります。デバッグモードは 'debug_mode':false にしても無効化されません。公式ヘルプに「パラメータをfalseに設定してもデバッグモードは無効にならない」と明記されており、止めるにはパラメータごと削除する必要があります。falseにしただけで安心して本番に残すと、全ユーザーのイベントがDebugViewに流れ込み続けます。なお、公式ヘルプが有効化の手段として案内しているのは、上記の設定コマンド・Tag Assistant・タグマネージャーのプレビューモードの3つです。URLに ?debug_mode=true を付けるという方法は公式ドキュメントには記載がないため、その手順を紹介している情報は裏取りしてから試してください。

症状③：数字がおよそ2倍になる

合否ラインの⑤で en=page_view が2本出ていたなら、二重計測が確定しています。WordPressで起きる典型は「テーマに直接書いたタグ」と「プラグインが出力するタグ」の併存です。前章の設置先3パターンのうち2つを同時にやっている状態を探してください。

Site Kit by Google については、よくある説明が実際の挙動と逆になっているので注意が必要です。Site Kit公式ドキュメント（Managing Site Kit-placed code・2026年8月2日取得）には、既存のアナリティクスタグを検出した場合、Site Kitが重複を避けるために「Place Google Analytics code」トグルを自動でオフにすると書かれています。つまりSite Kitは、放っておくと勝手に二重計測するのではなく、むしろ自動で回避しにいきます。

ただし同じドキュメントには、二重になる条件も明記されています。既存タグを残したまま、Site Kitで別のプロパティのタグを挿入させた場合は、両方のプロパティにデータが送られます。逆に、Site Kitのアナリティクス機能とタグマネージャー機能が同じデータストリームに紐づくコードを挿入している場合は、イベントは重複しません。したがって「Site Kitを入れたかどうか」ではなく、実際に飛んでいる en=page_view と tid を数えることだけが確実な判定になります。

トグルの位置は「Site Kit > Settings > Connected Services > Analytics > Edit > Place Google Analytics code」です。既存タグ側を残すのか、Site Kit側に一本化するのかを決めて、どちらか一方だけを残してください。

GA4の画面はどこを見るのか｜UAのレポート名は存在しない

計測が効いていることを確認できたら、次は画面の読み方です。ここでUA時代の記憶が邪魔をします。ウェブ上に残る解説記事の多くがUAのメニュー階層のままなので、そのとおりに操作しようとして詰まります。

GA4に「行動」「コンバージョン」というレポートは無い

Google公式ヘルプのレポート一覧（Overview of Google Analytics reports・2026年8月2日取得）に載っている事前定義レポート35本を全件確認しましたが、「行動（Behavior）」というレポートも「コンバージョン（Conversions）」というレポートも存在しません。左ナビは「レポートのスナップショット」「リアルタイム」と、その下のレポートコレクション（App developer／Business objectives／Games reporting／Life cycle／User）という構成です。

したがって「［コンバージョン］→［目標］→［目標URL］を設定」「［行動］→［サイトコンテンツ］→［すべてのページ］を確認」といった手順は、GA4では実行できません。そうした記述が出てくる記事はUA時代のまま更新されていないと判断して構いません。

UA用語 → GA4用語対応表

読み替えが必要なのは実質この範囲です。出典はいずれもGoogle公式ヘルプで、2026年8月2日に取得して確認しています。

UAでの呼び方	GA4での扱い
「行動」レポート	同名のレポートは無い。ページ単位の閲覧は「ページとスクリーン」、入口ページは「ランディングページ」、イベントは「イベント」で見る
「コンバージョン」レポート／目標（Goals）	同名のレポートは無い。UAの5種類の目標（到達・滞在時間・ページ数/セッション・スマートゴール・イベント）はキーイベントに一本化された
コンバージョン（用語）	ビジネス上重要な行動はキーイベントと呼ぶ。GA4の「コンバージョン」は広告キャンペーンの成果を測るための語に再定義された
ページビュー	「表示回数（Views）」。ウェブのページビューとアプリのスクリーンビューの合算値
ユニークページビュー	対応する指標なし
直帰率	同名の指標はあるが定義が別物。GA4の直帰率＝エンゲージメントのなかったセッションの割合（エンゲージメント率の裏返し）
平均セッション時間	指標としては存続している。ただしGA4で読むべきはエンゲージメント率・エンゲージのあったセッション数のほう
セッション	30分の無操作で終了するのは同じ。日付をまたいだとき・キャンペーンパラメータが変わったときにリセットされる挙動は無くなった

直帰率だけは、名前が同じで中身が違うため特に危険です。公式ヘルプ（Engagement rate and bounce rate・2026年8月2日取得）によれば、GA4は「10秒を超えて続いた」「キーイベントが発生した」「2ページ以上表示された」のいずれかを満たすセッションをエンゲージのあったセッションと定義し、直帰率はそれ以外の割合です。「1ページだけ見て離れた割合」というUAの説明でGA4の数字を読むと、解釈を誤ります。

キーイベントの設定場所は「管理 > データの表示 > イベント」です（Create or modify key events・2026年8月2日取得）。ここでイベントを作成し、「キーイベントとしてマーク」のトグルを入れます。公式が注意しているとおり、page_view をそのままキーイベントにすると全ページ閲覧がキーイベントとして数えられてしまうため、条件を絞った新しいイベントを作ってからマークしてください。

次の一手｜このままgtag.jsで行くか、GTMに寄せるか

計測が効いていることを確認できたら、次に決めるのは運用方式です。判断基準は単純で、これから増やしたいタグが1つだけならgtag.jsのまま、複数になるならGoogleタグマネージャー（GTM）に寄せるのが目安になります。フォーム送信やスクロール率など計測したいイベントが増えるたびにテーマファイルを触ることになるなら、その時点でGTMに移す価値が出ます。

両者のメリット・デメリットを具体的に比べたい場合は GA4直接埋め込みとGTM経由の比較と判断基準を読んでください。GTMに寄せると決めた後の移行手順は WordPressでGA4をGTM経由に移行する方法にまとめてあります。

どちらへ進んだ場合でも、切り替えた直後にこの記事の合否ライン表をもう一度通してください。移行作業でいちばん多い失敗は、新しい方を入れたのに古い方を外し忘れる二重計測です。en=page_view を数えるだけで検出できます。

よくある質問（FAQ）

Q. タグを設置したのにレポートに数字が出ません。何から見ればよいですか？

まず開発者ツールのNetworkタブを collect で絞り、/g/collect が2xx（実測では204）で飛んでいるかを見てください。飛んでいれば送信は成功しているので原因はGA4側（反映待ち・同意モード・データフィルタによる除外）です。飛んでいなければ設置側（タグ未設置・JSエラー・広告ブロッカー・キャッシュ）です。この一点で原因の置き場所が二分できます。

Q. 数字が実際の2倍になります。どう確認しますか？

1ページ表示あたりの「en=page_view を含み、かつ tid が自分の測定IDと一致するリクエスト」の本数を数えてください。2本あれば二重計測です。/g/collect というリクエスト自体は広告連携や後続の送信でも飛ぶため、本数だけでは判定できません。また _ga_ で始まるCookieが複数あっても二重計測の証拠にはなりません（過去のプロパティのCookieが残っているだけのことがあります）。

Q. Site Kit by Google を入れると二重計測になりますか？

既存のアナリティクスタグを検出した場合、Site Kitは「Place Google Analytics code」トグルを自動でオフにして重複を避けます。ただし既存タグを残したまま別のプロパティのタグをSite Kitに挿入させると、両方のプロパティにデータが送られます。導入後は必ず en=page_view の本数で実際に確認してください。設定は Site Kit > Settings > Connected Services > Analytics > Edit から変更できます。

Q. 測定ID（G-で始まるID）はどこで確認できますか？

GA4の「管理」から「プロパティ設定」の下にある「データストリーム」を開き、対象のストリーム名をクリックすると「ストリームの詳細」に測定IDが表示されます。IDは「G-」で始まります。この画面を開くにはプロパティで編集者以上の権限が必要です。

Q. UA（ユニバーサルアナリティクス）のデータはもう見られませんか？

見られません。標準のUAプロパティは2023年7月1日にヒットの処理を停止し、2024年7月1日の週にプロパティ・過去データ・APIへのアクセスがすべて終了してデータも削除されました。読み取り専用でもアクセスできないため、いま手元のコードに UA- で始まるIDが残っていれば、それは1件も計測していないコードです。

Q. UAの「行動」レポートはGA4のどこにありますか？

GA4に「行動」という名前のレポートはありません。ページ単位の閲覧数は「ページとスクリーン」レポート、入口ページは「ランディングページ」レポート、発生したイベントは「イベント」レポートで確認します。Google公式のレポート一覧に載っている事前定義レポート35本の中に「行動」は含まれていません。

Q. GA4の「コンバージョン」はどこへ行きましたか？

ビジネス上重要な行動を示すイベントは「キーイベント」という名称に統一されました。設定は「管理 > データの表示 > イベント」で行い、対象のイベントを「キーイベントとしてマーク」します。GA4で「コンバージョン」という語は、広告キャンペーンの成果を測るGoogle Ads側の概念を指すものとして再定義されています。

Q. デバッグモードを止めたいのですが、falseにすれば無効化されますか？

無効化されません。公式ヘルプに「パラメータをfalseに設定してもデバッグモードは無効にならない」と明記されており、止めるには debug_mode パラメータそのものを設定から削除する必要があります。falseのまま本番に残すと、全ユーザーのイベントがDebugViewに流れ続けます。

まとめ

GA4の動作確認は、開発者ツールのNetworkを collect で絞り、POSTで2xx（実測204）が返り、tid が自分の測定IDと一致し、en=page_view が1ページにつきちょうど1本であることを見るだけで完了します。ここが通れば送信は成功しており、以降の不具合はすべてGA4側の設定として切り分けられます。

逆に、この確認を省いたまま「レポートに数字が出ない」と悩む時間がいちばん無駄になります。設置した直後、テーマを変えた直後、プラグインを追加した直後の3つのタイミングで、この記事の合否ライン表を1回通す習慣にしてください。所要時間は1分です。

計測が信用できる状態になったら、次は取れた数字をサイト改善につなげる番です。検索側のデータと突き合わせて改善サイクルを回す手順はデータドリブンSEOで改善PDCAを回す｜無料ツール3つの実践ガイドでまとめています。

ページ側の構造化データ・メタタグ・見出し構造にも抜けがないかをまとめて確かめたい場合は、SEO診断ツールを使うと1画面で把握できます。

サイトをSEO診断する → Direbase（ディレベース）

GA4設置後の動作確認｜計測が効いているか自分で確かめる手順