GCLIDが遷移先LPで消える・取得できない原因と対処手順|リダイレクト・自動タグ・LP実装の3層切り分け
Google広告のGCLIDが遷移先LPで消える・取得できない原因を、リダイレクト・自動タグ設定・LP実装の3層で切り分け。1分でできる検証テストから原因別の診断手順、修正後の確認フローまで当日中に解決できる形で解説します。
この記事のポイント
- GCLID消失の原因はリダイレクト・自動タグ設定・LP実装の3層のいずれかに必ず存在する
- まず?gclid=testの1分検証を行い、消える段階を先に絞り込むのが最短ルートである
- Apache/NginxのQSA設定漏れとSPAのクエリ非保持が実務で最も多い2大要因と言われる
- Safari利用者はwbraid/gbraidでの代替計測を前提に設計するのが定石である
- 原因層を特定できたら当日中にDevToolsで再検証し、修正の効果を必ず確認する

GCLIDが消える原因は3層のどこかにある|診断の全体地図
図1: 3層構造で見る、GCLID消失の全体像
Google広告のコンバージョンが急に計測できなくなったとき、多くの担当者はまず広告アカウント側を疑います。ですが実際にgclidが消えるlpのトラブルを切り分けていくと、原因はリダイレクト・自動タグ設定・LP実装という3つの層のどこかに必ず存在します。この3層構造を最初に頭に入れておくかどうかで、原因特定にかかる時間が大きく変わります。
リダイレクト層は、広告のクリックURLから最終的な着地ページまでの経路上でパラメータが剥がれ落ちる問題です。自動タグ設定層は、Google広告の管理画面側の設定ミスによってgclid自体が正しく付与されていない問題です。そしてLP実装層は、パラメータは届いているのにページ内のJavaScriptやリンク遷移の作りによって失われてしまう問題です。この記事では、この3層をひとつずつ検証しながら、当日中にどこが原因かを特定し、自力で修正まで進められる状態を目指します。
この記事で特定できること
本記事を読み進めることで、以下の判断ができるようになります。gclidが「そもそも付与されていないのか」「付与されているのに途中で消えているのか」「LP到達後に失われているのか」の切り分け、そして各層に対応する具体的な修正手順です。GA4側で(direct)/(none)が急増しているケースについても、原因層との対応関係を後半で整理します。
対象読者と前提知識
想定しているのは、Google広告のコンバージョン数が急減し、リダイレクトかLPかタグ設定かの切り分けに迷っている広告運用担当者です。GTM(Google タグ マネージャー)やGA4の管理画面を操作した経験がある方であれば、専門的なエンジニア知識がなくても本記事の手順は再現できるように書いています。
まず1分でできる切り分けテスト
一本の道に立てる小さな検査の印
原因を推測する前に、まず症状の有無そのものを機械的に確認します。ここを飛ばしていきなり原因探しに入ると、遠回りになりがちです。
テスト用URLの作り方
確認したいランディングページのURLの末尾に、ダミーのgclidパラメータを手動で付け足します。たとえば https://example.com/lp/?gclid=test123 のような形です。実際の広告クリックを待たずに、任意のタイミングで検証できるのがこの方法の利点です。
ブラウザでの確認手順と正常/異常の見分け方
このURLをブラウザで開き、最終的に表示されたページのアドレスバーを確認します。gclid=test123 がそのまま残っていれば、少なくともブラウザ表示上は保持されている状態です。消えていれば、リダイレクトまたはLP内部の処理でパラメータが落ちていることが分かります。次に、開発者ツール(DevTools)を開いた状態で同じ検証を行い、Networkタブでリクエストの一覧を確認します。ここで複数回の3xxリダイレクトが挟まっていないか、Cookieに _gcl_aw が保存されているかを見ておくと、次の章の判断がスムーズになります。この段階ではまだ深追いせず、症状の有無だけを記録しておけば十分です。
原因①:リダイレクトがGCLIDを剥ぎ取っているケース
1分テストでパラメータが消えていた場合、まず疑うべきはリダイレクトです。海外の独立系PPCブログAdnan Agic氏の記事「GCLID Stripped by Redirects」では、リダイレクトによるgclid消失を7つの典型パターンに分類し、DevToolsでの確認からApache/NginxのQSA設定までを一直線の診断フローとして提示しています。日本語圏の記事では原因を1〜2パターンしか挙げないことが多いため、この分類は切り分け表として転用価値が高いと言えます。
起きやすい状況7パターン
実務で遭遇しやすいのは、サイト移行に伴うURL変更、広告専用LPから本サイトへの遷移、クロスドメイン計測をまたぐ遷移、決済用サブドメインへの受け渡し、外部のトラッキングソフトを経由する構成、HTTP からHTTPSへの常時化、そして末尾スラッシュの正規化リダイレクトです。いずれもリダイレクト自体は正しく機能していても、クエリ文字列だけが引き継がれずに消えることがあります。
DevTools Networkタブでの確認手順
DevToolsのNetworkタブを開いた状態でテスト用URLにアクセスし、ステータスコードが301や302のリクエストを上から順に追います。どのリクエストの直後でgclidパラメータがURLから消えているかを見つければ、そこが原因のリダイレクト箇所です。海外ではRedirect DetectiveやWhereGoes.comのような外部トレースツールにURL全体を貼り付け、何段目でパラメータが落ちているかを可視化する手法もPPC Heroで紹介されています。日本の運用現場ではDevTools目視確認で止まってしまうケースが多いため、こうした無料ツールを併用する発想は選択肢として持っておく価値があります。
Apache/Nginxでのパラメータ保持設定
サーバー側の設定に原因がある場合、Apacheであればリダイレクトルールに QSA (Query String Append)フラグを付与することでクエリ文字列を保持できます。Nginxの場合は return 301 $scheme://example.com$request_uri; のように $request_uri を使う書き方であればパラメータが引き継がれますが、固定文字列で書き換えている設定だと落ちてしまいます。サイトリニューアル時にこの設定が漏れるのは典型的な失敗パターンで、サイトリニューアル時の広告・計測引き継ぎチェックリストで体系的な引き継ぎ設計を確認しておくと再発を防ぎやすくなります。
原因②:自動タグ設定・最終URLの設定ミス
1分テストの時点でgclid自体が付与されていない、あるいは広告クリック時のURLにgclidが見当たらない場合は、Google広告の管理画面側を確認します。
自動タグ設定の確認箇所
Google広告の管理画面で「設定」内の「自動タグ設定」がオフになっていると、そもそもgclidが生成されません。この項目は代理店切り替えやアカウント統合の際に見落とされがちで、意図せずオフのまま運用が続いているケースも見られます。まずここがオンになっているかを確認するのが最初の一歩です。
トラッキングテンプレートとの競合パターン
自動タグ設定がオンでも、広告グループやキャンペーン単位で個別のトラッキングテンプレートが設定されていると、そちらが優先されて期待通りのURLにならないことがあります。特に旧LPのURLがトラッキングテンプレートに固定的に残ったままだと、最終URLを変更したつもりでも古い遷移先が使われ続けます。
並列トラッキングの設定確認
現在のGoogle広告では並列トラッキング(Parallel Tracking)が標準仕様となっており、クリック計測用のURLと実際に表示される最終URLが分離しています。この仕組み自体はgclid消失の直接原因になることは少ないものの、トラッキングテンプレートとの組み合わせ次第では想定外のリダイレクトが挟まることがあるため、設定内容を一度確認しておくと安心です。
原因③:LP側の実装でGCLIDが失われるケース
リダイレクトも自動タグ設定も問題なく、gclidがLPの初回アクセス時点までは届いているのに、その後のCV計測でうまく紐付かない場合はLP実装を疑います。
SPA/JSルーティングでのクエリ消失
React やVueなどで作られたSPA(シングルページアプリケーション)では、ページ内遷移の際にクエリパラメータを引き継がずにURLを書き換えてしまう実装がよく見られます。フォーム画面や確認画面に遷移した時点でgclidがURLから消えている場合、この可能性が高いと言えます。対応としては、初回アクセス時にgclidをCookieやセッションストレージに保存し、ページ遷移後もその値を参照する実装に変更する必要があります。
フォーム送信・別ドメイン遷移時の未保持
問い合わせフォームが別ドメインやサブドメインで提供されている場合、遷移時にgclidを引き継ぐ仕組みがなければパラメータは失われます。フォーム側でhiddenフィールドとしてgclidを保持し、送信データに含める設計が一般的な対策です。
Safariのプライバシー保護機能との関係
Safari Link Tracking Protection(リンク追跡保護)は、プライベートブラウジングなど一部の条件下でURLパラメータやトラッキング用Cookieを削除する挙動を持ちます。Conversios.ioのブログでは、gclidと同じ値を持つ独自パラメータをデコイとして併設し、サーバーサイド計測側で読み替える手法が紹介されています。Safariの正式版では自動削除機能自体は見送られましたが、プライベートブラウジングでは依然として一部削除が起こり得るため、保険的な対策として押さえておく価値はあると考えられます。
当日中に原因を特定する診断フローチャート
図2: 症状から原因層を絞り込む診断フロー
ここまでの3層を踏まえて、症状から原因層を絞り込む表を整理します。
| 症状 | 疑うべき層 |
|---|---|
| ?gclid=testが最終URLで完全に消える | リダイレクト層 |
| 広告クリック直後のURLにgclid自体がない | 自動タグ設定層 |
| LP初回表示では残るがフォーム送信後に消える | LP実装層 |
| SafariのみでCV計測が漏れる | LP実装層(Safari固有) |
症状別切り分け表
この表はあくまで初動の目安です。実務では複数層が同時に影響しているケースもあるため、上から順に一つずつ潰していくのが確実です。まずリダイレクト、次に自動タグ設定、最後にLP実装という順番で検証すると、手戻りが少なくなります。
GA4の(direct)/(none)急増との関係
GA4でセッションのデフォルトチャネルグループが急に(direct)/(none)へ寄っている場合、gclidを含む参照元情報がどこかで失われている兆候です。特にリダイレクトやLP実装でパラメータが消えているケースでは、GA4側がGoogle広告経由のセッションを正しく認識できず、こうした表示になりやすいと言えます。GA4とGoogle広告のコンバージョン数が合わない原因も合わせて確認すると、CV数の不一致がgclid消失によるものかどうかの判断材料が増えます。
修正後の検証手順とコンバージョン計測への影響確認
原因層を特定して修正を入れたら、直しっぱなしにせず必ず再検証します。ここを省くと、修正が不十分なまま本番運用に戻してしまうリスクがあります。
修正直後に確認すべき指標
修正後は、最初の1分テストと同じ手順で?gclid=testが最終URLまで保持されているかを再確認します。それに加えて、GTMのプレビューモードでタグが正しく発火しているかも確認しておくと安心です。この確認手順に不安がある場合は、GTMプレビュー・タグ発火の診断チェックリストを併用すると抜け漏れを減らせます。実際の広告クリックを待たず、修正当日のうちに検証を終えられるのがこのフローの利点です。
スマート入札学習への影響チェック
gclidが一定期間消失していた場合、その間のコンバージョンデータが欠落し、スマート入札の学習データにも影響が及んでいる可能性があります。修正後は数日から1〜2週間程度、コンバージョン数と入札単価の推移を通常時より注意深く観察するのが望ましいと言われています。急激な変動が見られる場合は、学習期間がリセットされている可能性も視野に入れて判断します。
再発防止のガバナンス設計
仕組みで守る、静かな見張り塔
一度直しても、サイト改修や新規LP制作のたびに同じ問題が再発するケースは少なくありません。仕組みとして防ぐ発想が必要です。
改修前チェック項目のテンプレート化
サイトリニューアルやLP制作を外部の制作会社に依頼する際は、着手前にgclidの引き継ぎ確認、リダイレクト設定のQSA有無、フォーム送信時のパラメータ保持の3点を確認項目としてテンプレート化しておくと、担当者が変わっても抜け漏れを防げます。
外部ツール導入時の確認フロー
チャットツールや予約システムなど、別ドメインへ遷移する外部サービスを新規導入する際は、gclidが引き継がれるかどうかを事前に検証してから本番反映するフローを設けておくと安全です。UTM.ioのブログでは、サードパーティCookieの縮小に伴いサーバーサイドタグ経由でのパラメータ転送が主流化しつつあると位置付けられています。日本の現場でも、gclid欠損対策を単発の不具合修正としてではなく、計測基盤整備の一部として捉え直す時期に来ていると考えられます。gclidを起点にオフラインコンバージョンまで活用を広げたい場合は、GCLIDを使ったオフラインコンバージョンのCRM連携設計も参考になります。
よくある質問
Q:GCLIDの有効期間はどのくらいですか?期限を過ぎるとどうなりますか 目安は90日程度とされています。この期間を過ぎた後にオフラインコンバージョンをインポートしようとしても、gclidと該当のクリックデータが紐付かず、コンバージョンとして計上されない点に注意が必要です。
Q:wbraid・gbraidとgclidの違いは何ですか wbraidとgbraidは、iOSなど一部のプライバシー制限が強い環境でgclidの代替として発行される仕組みです。基本的な役割はgclidと同様にクリックとコンバージョンを紐付けることですが、オフラインコンバージョンのインポート時にはgclidと別のパラメータとして扱われるため、CRM側の取り込み設計でも区別して保持しておく必要があります。
Q:SafariでGCLIDが消えるのはなぜですか?広告側で対処できますか Safariのプライベートブラウジングでは、リンク追跡保護の機能によってURLパラメータやトラッキング用Cookieが削除される場合があります。広告側だけで完全に防ぐことは難しいものの、並列トラッキングの設定確認やサーバーサイド計測の導入によって影響をある程度緩和できると言われています。
Q:リダイレクトを使わずに済む方法はありますか 最終URLを最初からリダイレクトを挟まないLPに直接向けておく運用であれば、そもそもこの問題は発生しません。事情によりリダイレクトが必須な場合は、Apache/NginxでのQSA相当の設定を必ず入れ、クエリ文字列を保持したままリダイレクトさせる構成にしておくことが基本的な対策になります。
GCLIDの消失は、リダイレクト・自動タグ設定・LP実装のどの層に原因があるかによって対応方法が大きく異なります。真策堂ではこうした計測トラブルの切り分けや、サイト改修時の広告・計測引き継ぎ設計についてのご相談を受けています。原因の特定に時間がかかっている場合は、一度この3層診断フローに沿って現状を整理してみることをおすすめします。
- アクセス解析
GA4でGoogleシグナル有効化後にユーザー数が減る2つの原因とデータしきい値の回避設計
GA4でGoogleシグナルを有効化した後にユーザー数が急減する原因を「クロスデバイス重複排除」と「データしきい値」の2つに切り分けて診断する手順を解説。2024年2月のレポート用識別子仕様変更を踏まえ、リマーケティング等の広告機能を壊さずにしきい値を回避する優先順位まで実務視点で体系化します。
- アクセス解析
LINE広告のCVがGA4と合わない原因を3レイヤーで診断する実務手順|LINE Tag・ビュースルー混在・計算方式の切り分けフロー
LINE広告とGA4のコンバージョン数値が合わない原因を、LINE Tag実装・ビュースルーCV混在・計算方式の3レイヤーで体系的に診断する実務手順を解説。当日中に原因を特定し、マーケ責任者が意思決定できる診断フローとチェックリスト付き。
- アクセス解析
Metaピクセルのイベントがイベントマネージャに反映されない原因と切り分け手順
Metaピクセルのイベントがイベントマネージャに表示されない・遅延が続く原因を発火なし・非反映・遅延・CAPI重複排除の4パターンに分類。Pixel Helper・ネットワークタブ・テストイベントの順で当日中に原因を特定できる切り分けフローを解説します。