リファラーとは？「リファラーなし」になる原因とGA4 (direct)/(none)の読み方

2026.07.06
Webサイト・HP改善

リファラーなしは直接訪問やボットとは限らない: 参照元が分からなくなる理由とアクセス解析の読み方アクセス解析で「(direct) / (none)」と表示された訪問を、URLの直接入力やお気に入り（ブックマーク）からの訪問だと考えていないでしょうか。サーバーログにリファラーがないアクセスを、ボットによる巡回と判断しているケースもあります。

どちらも可能性の一つです。しかし、「リファラーなし」という結果だけでは、訪問前の行動やアクセスした主体を特定できません。

なぜなら…

  • メールやチャット、スマートフォンアプリ、プライバシー保護、リダイレクト、計測設定など、参照元が分からなくなる理由はほかにもあるから
  • 反対に、利用者がURLを直接入力して訪問しても、Google Analytics 4のレポートで必ず(direct) / (none)になるとは限りません。実際の操作、ブラウザから送られる情報、アクセス解析製品の分類は、それぞれ別のものだから

などです。

また、ここでは、一般的な呼び方として「リファラー」を使い、HTTPヘッダ名は仕様どおりRefererと記します。リファラーなしから分かる範囲と、アクセス解析で扱う際の注意点を順にまとめます。

  1. リファラーなし＝ブックマーク？ではなく、分かるのは「参照元情報を使えない」ことまで
  2. HTTP、ブラウザ上の計測、Google Analytics 4の分類は別の層にある
  3. (direct) / (none)は、利用者の操作を確定するラベルではない
    1. directと表示されても、直接入力とは限らない
    2. 逆に…実際に直接訪問しても、directと表示されない場合がある
  4. 参照元情報がなくなる代表的な理由
    1. HTTPのRefererが送られない、または範囲が限られる場面
    2. Referrer Policyは「送り出す側」の制御
    3. リダイレクトや短縮URLだけで必ず情報が消えるわけではない
  5. アクセス解析側で参照元を判断できなくなる場面
    1. 未計測とdirectへの分類を分ける
    2. 複数ドメインをまたぐ場合は計測設定も見る
  6. ボットかどうかは別の情報を組み合わせて判断する
  7. directが増えたときに、この順番で見るべし
  8. 補記：Webマーケティングでは「取得できない情報」とどう付き合うか
    1. 2013年の検索SSL化でも、見えない情報を推測する問題があった
    2. 取得できない情報は、複数の材料から仮説として扱う
    3. 計測精度のためにプライバシー保護を弱めない
  9. まとめ
  10. 参考文献

リファラーなし＝ブックマーク？ではなく、分かるのは「参照元情報を使えない」ことまで

現行のHTTP仕様であるRFC 9110の10.1.3節では、Refererは、リクエスト対象のURIを得た参照元をユーザーエージェントが示すためのヘッダとされています。

URLを直接入力した場合やブックマークを開いた場合には、参照元となるURIがありません。このとき、ユーザーエージェントはRefererを送らないか、about:blankを送ります。

したがって、直接入力やブックマークは「リファラーなし」になる代表的な経路です。ただし、逆は成り立ちません。リファラーがなければ必ず直接入力かブックマークである、とはいえないのです。

同じことは、ボット（自動アクセス）にも当てはまります。ボットはRefererを送らない場合もあれば、送る場合もあります。ヘッダがないという一点だけでは、人によるアクセスか、自動アクセスかを判定できません。

観測した状態 確実にいえること 可能性として考えられること
HTTPリクエストにRefererがない そのリクエストでは参照元ヘッダを利用できない 直接入力、ブックマーク、アプリ経由、Referrer Policy、プライバシー機能、ボットなど
アクセス解析で(direct) / (none)と表示された 製品が別の参照元やキャンペーンを割り当てていない 直接入力、ブックマーク、UTMのないメールやSNS、リダイレクトによる情報消失など
サーバーログにリファラーが記録されていない サーバーが参照元を受け取っていないか、ログへ残していない ブラウザが送信しなかった、ログ設定で記録されなかった、自動アクセスだったなど

「リファラーなし」はざっくり言えば”参照元情報を利用できなかった”ということ。この範囲を越えて、利用者の操作や意図まで結びつけるのは結構早計です。

HTTP、ブラウザ上の計測、Google Analytics 4の分類は別の層にある

参照元が分からなくなった原因を探すには、どの段階の情報を見ているのかを分ける必要があります。

層 主な情報 何を示すか
HTTPリクエスト Refererリクエストヘッダ ブラウザなどからサーバーへ送られた参照元情報
ブラウザ上の計測 document.referrer、Google Analyticsへ送るpage_referrerなど ページ上の計測処理が取得し、送信した参照元情報
Google Analytics 4 参照元、メディア、チャネル UTM、広告クリック識別子、参照元、帰属処理などを使った分類結果
  • HTML Standardで定められたdocument.referrerは、ページ上のJavaScriptから参照できる値です。HTTPのRefererと関係はありますが、同じ場所で取得する同一の値ではありません。
  • また、Google Analytics 4のpage_referrerは、計測時に送るイベントパラメータです。サーバーサイド計測や独自の値の指定が加われば、情報の流れはさらに変わります。
  • Google Analyticsのキャンペーンとトラフィックソースに関する説明によると、レポート上の参照元やメディアは、参照URLだけで決まるものではありません。広告プラットフォームとの連携、自動タグ、UTMパラメータ、イベントやセッションに対する処理も関係します。

UTMパラメータとは、リンクURLへ流入元、媒体、キャンペーン名などを付け加える識別情報です。メールやSNSなど、自社で配信URLを管理できる施策では、リファラーに頼らず流入元を伝える手段になります。

ここで、タグが動かなかった場合と、計測後にdirectへ分類された場合を分けて考える必要があります。タグがまったく動作しなければ、その訪問やイベント自体がGoogle Analytics 4へ記録されない可能性があります。未計測の訪問が、そのままdirectとして残るわけではありません。

(direct) / (none)は、利用者の操作を確定するラベルではない

directと表示されても、直接入力とは限らない

Google Analyticsの(direct) / (none)に関する説明では、この分類を明確な参照元がないトラフィックとしています。URLの直接入力やブックマークは代表例ですが、次のような場面でも参照元を判断できなくなる可能性があります。

  • UTMパラメータが付いていないメール、SNS、QRコードなどのリンク
  • 広告・マーケティングプラットフォームとの連携不足
  • リダイレクトの途中でキャンペーン情報が失われた場合
  • 広告ブロッカーなどが計測を妨げた場合

そのため、directが増えただけでは、サイト名を覚えて訪問した人が増えたとも、ブランド認知が高まったとも結論づけられません。

逆に…実際に直接訪問しても、directと表示されない場合がある

Google Analytics 4の参照元ディメンションには、初回ユーザー、セッション、イベントという三つのスコープがあります。トラフィックソースディメンションのスコープに関する公式資料に示された違いは、次のとおりです。

スコープ 代表的なディメンション 主に表すもの
ユーザー 初回ユーザーの参照元、メディア その利用者を最初に獲得した経路
セッション セッションの参照元、メディア セッションの開始に割り当てられた経路
イベント 参照元、メディア キーイベントへの貢献を帰属処理した結果

セッションスコープでは、非ダイレクトの直近接点（セッション）が引き継がれるようになります。

つまり、GA4で設定されたルックバック期間内に過去の非ダイレクト流入があれば、利用者が今回はブックマークやURL入力で訪れても、その過去の参照元がセッションへ割り当てられるケースもあるわけです。

つまり、(direct) / (none)は直接入力を証明するラベルではありません。逆に、直接入力という操作が必ず(direct) / (none)を生むわけでもないのです。「directが増えた」と説明するときは、どのレポートで、どのスコープのディメンションを見たのかまで明らかにする必要があります。

参照元情報がなくなる代表的な理由

HTTPのRefererが送られない、または範囲が限られる場面

場面 起きること 読む際の注意点
URLの直接入力、お気に入り（ブックマーク） 参照元となるWebページがない 代表例だが、リファラーなしの全件を説明するものではない
メール、チャット、ネイティブアプリ アプリが参照元を渡さずにブラウザを開くことがある アプリ、OS、開き方によって挙動が異なる
no-referrerやnoreferrerを指定したリンク リンク元の方針としてRefererを送らない 到着先の計測タグの故障とは限らない
HTTPSからHTTPへの移動 標準的なReferrer Policyでは参照元を送らない 移動先がHTTPのままの場合に起き得る
ブラウザのプライバシー機能や拡張機能 参照元の送信を抑えることがある ブラウザ、設定、拡張機能によって動作が異なる
ボットやクローラー 実装によってRefererを送らないことがある リファラーの有無だけでボットと判定しない

メールやアプリからの移動を、すべてリファラーなしと見なすこともできません。アプリ内ブラウザで開くのか、外部ブラウザへ渡すのか、リンクにUTMパラメータが付いているのかによって、アクセス解析での見え方は一定ではありません。

Referrer Policyは「送り出す側」の制御

W3CのReferrer Policyは、文書などから発生するリクエストやページ移動で、ブラウザが参照元情報をどこまで送るかを定めています。

2026年7月4日時点での既定値strict-origin-when-cross-originでは、同一オリジンへの移動にパスを含むURLを使うのが基本です。別オリジンのHTTPSサイトには原則としてオリジンだけが送られ、HTTPSからHTTPへの移動では送られません。

Webサイトは、Referrer-PolicyレスポンスヘッダやHTMLの指定によって、そのページから次に発生するリクエストへ送る参照元の範囲を制御できます。これは主として「送り出す側」の設定です。

外部サイトから自社サイトへ届くRefererの範囲は、リンク元の設定とブラウザの処理によって決まります。自社サイトのReferrer-Policyを変更しても、到着時点ですでに失われていた外部参照元は復元できません。計測のためだけに、自社サイトから送る情報の範囲を広げることも避けるべきです。

リダイレクトや短縮URLだけで必ず情報が消えるわけではない

リダイレクトそのものが、必ずRefererやUTMパラメータを消すわけではありません。次の条件が加わると、参照元やキャンペーン情報が失われる場合があります。

  • HTTPSからHTTPへ移動する
  • 転送先へクエリパラメータを引き継がない
  • 中間ページや転送レスポンスで制限的なReferrer Policyが指定される
  • 短縮URLサービスが独自の中間ページや転送処理を使う
  • 広告クリック識別子やクロスドメイン用パラメータが途中で削除される

問題が疑われる場合は、配信したURLを実際に開き、転送後のURLにUTMや広告クリック識別子が残っているかみてもいいかもしれません。困ったときなど、リダイレクトの有無だけで原因を確定しないことが大切です。WordpressのRedirectionプラグインでも、パラメータを引き継ぐかどうかのオプション有りますよね。

アクセス解析側で参照元を判断できなくなる場面

未計測とdirectへの分類を分ける

計測タグ、同意管理、広告ブロッカーの影響は一様ではありません。

場面 起きる可能性があること 読む際の注意点
タグが読み込まれない、または通信が遮断される 訪問やイベント自体が記録されない 未計測をdirectとして数えない
タグは動くが参照元やキャンペーン情報を使えない 計測はされても、想定した参照元へ分類できない 送信されたイベントパラメータを調べる
計測後の処理 製品のルールによってdirect、別の参照元、Unassignedなどへ分類される HTTPヘッダの有無だけで説明しない

同意管理についても、実装方式を区別する必要があります。GoogleのConsent Modeに関する公式資料では、基本的な実装では同意を得るまでGoogleタグの読み込みを止めます。一方、高度な実装では、既定の同意状態でタグを読み込み、同意が拒否されている間もCookieを使わない測定情報を送る仕組みです。

したがって、「同意しなかった訪問はすべて未計測になる」「すべてdirectになる」と一律にはいえません。判断には、自社で採用した同意管理の方式、タグの動作、実際に送られた情報が必要です。

複数ドメインをまたぐ場合は計測設定も見る

予約、決済、会員管理などで複数ドメインをまたぐサイトでは、参照元の問題に見えても、実際にはクロスドメイン計測や不要な参照元設定に原因が隠れているケースも見られます。Google Analyticsのアカウント構成に関する公式資料では、ドメインをまたぐ一連の行動を一貫して計測する場合、一つのWebデータストリームとクロスドメイン計測を使うのが公式の案内です。

設定に問題があると、利用者やセッションが分かれ、自社の関連ドメインが参照元として現れる可能性もあります。これは単純な「リファラーなし」とは別の問題です。ただし、参照元の異常を調べる際には候補へ含めます。

ボットかどうかは別の情報を組み合わせて判断する

Google Analyticsの既知ボットに関する公式資料では、既知のボットやスパイダーによるトラフィックは自動的に除外されると説明されています。ただし、対象はGoogleの調査やIABのリストなどによって識別できる既知のボットです。あらゆる自動アクセスが除外されることを意味しません。

Google Analytics 4とサーバーログでは、記録する対象も除外処理も異なります。サーバーログには、Google Analytics 4が除外した既知のボット、計測タグを実行しないクローラー、画像やファイルだけを取得したリクエストも残り得ます。そのため、サーバーログのリクエスト数とGoogle Analytics 4のイベント数を、一対一では比較できません。

例えば、Cloudflareのボット検出に関する技術資料が示すのは、HTTPヘッダの特徴、リクエストの振る舞い、セッションやブラウザの信号など、複数の方法を組み合わせる仕組みです。自社で不自然なアクセスを調べる場合も、次の情報を併用します。

  • ユーザーエージェント
  • IPアドレスと、そのIPが属するネットワーク事業者を示すASN
  • 短時間のリクエスト数と間隔
  • 同じURL群を機械的に巡回する挙動
  • JavaScriptや画像など、HTML以外のリソースへのアクセス状況
  • 検索エンジンなどが公開する正規ボットの検証方法

これらの情報にも偽装や誤判定の余地が残ります。リファラーなしは調査のきっかけになっても、それだけでボットを示す証拠にはなりません。

directが増えたときに、この順番で見るべし

directに共通の正常比率はありません。知名度、再訪の多さ、メール配信、アプリやオフライン施策、計測設定によって割合が変わるためです。他社平均だけで良否を決めず、自社サイトの平常時からの変化を見ます。

急な増加を見つけたときは、次の順序で状況を見ていくと、原因の候補を絞りやすくなります。

  1. 使用しているレポートと、初回ユーザー・セッション・イベントのどのスコープを見ているかを確かめる
  2. 増加した日付と期間を特定し、ランディングページ別に分ける
  3. デバイス、ブラウザ、地域に偏りがないかを見る
  4. メール、広告、SNS、QRコード、PDF、チャットなどで配信したURLを実際に開く
  5. 転送後もUTM、広告クリック識別子、クロスドメイン用パラメータが残るかを見る
  6. タグの発火、page_referrer、同意状態を調べる
  7. サーバーログやCDN（コンテンツ配信基盤）のログと比較する
  8. サイト更新、タグ変更、同意管理変更、広告開始、メール配信などの履歴と照合する
  9. 一つの原因へ決めつけず、複数の仮説として評価する

UTMは、担当者ごとに自由な表記で付けると集計が分かれます。utm_source、utm_medium、utm_campaignなどの命名規則を決め、大文字と小文字、略称、日付形式を統一します。配信したURLと施策の実施日も、管理表へ残しておくと後から照合しやすくなります。

補記：Webマーケティングでは「取得できない情報」とどう付き合うか

2013年の検索SSL化でも、見えない情報を推測する問題があった

当社では2013年、Google検索のSSL化によって流入キーワードを取得しにくくなった際に、Referer内の別のパラメータから情報を補えないか検証しました。一部には規則性が見えたものの、公式仕様ではなく、変更や誤判定の余地が残りました。取得できなくなった検索キーワードを正確に復元する手段にはならなかったのです。

この経験から得たのは、見えなくなった情報を断片から完全に復元しようとすると、推測を事実として扱いやすいということです。現在のdirectやリファラーなしにも、同じ注意が必要になります。

取得できない情報は、複数の材料から仮説として扱う

リファラーなしの数値も、施策を考える手がかりにはなります。ただし、レポートのラベルを利用者の行動や意図に置き換えず、別の材料と照らし合わせることが欠かせません。

知りたい内容 組み合わせる情報 注意点
指名や認知の変化 指名検索、Search Console、アンケート、問い合わせ時の聞き取り directの増加だけを認知向上の根拠にしない
メールやSNS施策の効果 UTM、配信記録、短縮URLの仕様、ランディングページ パラメータの付け忘れや命名の不統一を考慮する
広告の流入と成果 自動タグ、媒体管理画面、アクセス解析、顧客・商談情報 製品ごとに集計範囲や帰属処理が異なる
ボットを含む異常なアクセス サーバーログ、ユーザーエージェント、IP・ASN、アクセス頻度 単一の特徴だけで機械的に除外しない
数値が変わった背景 サイト更新記録、タグ変更履歴、同意率、社内イベント 変更履歴がなければ前後関係を追いにくい

例えば、メール配信後にdirectが増え、配信先URLにUTMが付いていなかったのであれば、「メール経由の一部がdirectへ含まれた可能性がある」という仮説を持てます。しかし、その増加分をすべてメール経由へ置き換えることはできません。分かる範囲と分からない範囲を残したまま判断する方が、施策の評価を誤りにくくなります。

計測精度のためにプライバシー保護を弱めない

RFC 9110は、Refererによって直前の閲覧履歴や、参照元URLに含まれる情報が移動先へ伝わる可能性を、プライバシー上の懸念として挙げています。リファラーが取れないからといって、必要以上に送信範囲を広げればよいわけではありません。

まずは、管理できるリンクへUTMを適切に付ける、サイトやタグの変更履歴を残す、Search Consoleやサーバーログなど目的の異なる情報を併用するといった対応を優先します。それでも分からない部分は残ります。Webマーケティングでは、すべてを一つのツールで把握しようとせず、取得できない情報があることを前提に意思決定する姿勢が必要です。

まとめ

  • リファラーなしは、参照元情報を利用できないという観測結果であり、原因の名称ではない
  • HTTPのReferer、ブラウザ上の参照元、Google Analytics 4の分類は異なる層の情報である
  • (direct) / (none)は直接入力を証明せず、実際の直接入力が必ず(direct) / (none)になるわけでもない
  • Referrer Policyは主として送り出す側の制御であり、到着前に失われた外部参照元を自社サイト側で復元することはできない
  • タグが動かず未計測になることと、計測後にdirectへ分類されることを分けて考える
  • Google Analytics 4は既知のボットを除外するが、すべての自動アクセスを除外できるわけではない
  • directの増加を、ブランド認知や利用者の操作と直ちに結び付けない
  • 取得できない情報を推測で埋めず、UTM、Search Console、サーバーログ、施策履歴などを組み合わせて仮説として扱う
  • 計測精度を高めるために、プライバシー保護を必要以上に弱めない

リファラーなしの数値を見たときに必要なのは、一つの原因へ当てはめることではありません。どの段階で情報が欠けた可能性があるのかを考え、手元にある別の材料と照らし合わせることです。取得できない情報を取得できないまま扱う慎重さも、アクセス解析とWebマーケティングに欠かせない判断の一部です。

最近は海外からのクローリングなのかいわゆる悪質BOTなのか分からないスパイクも多く悩ましいですね、AIによって諸処大きな規模のものを楽にできるようになったので、Web上のアクセスは人間だった時代はそのうちなくなるのは自然な流れかなと思います（嫌ですが…）

この記事が参考になれば幸いです。

参考文献

[ZOHO-mm-compact]
このWebサイトをフォローする
中小企業専門WEBコンサルティング会社・ラウンドナップWebコンサルティング(株式会社ラウンドナップ）
まずは、今のWeb活用状況を一緒に整理しましょう。 課題がはっきりしていなくても大丈夫です。
今の状況を伺ったうえで、必要な入口をご案内します。
無料相談する → 無料Webサイト診断 → サービス一覧を見る →
✓ 相談は無料です
✓ オンラインで完結
✓ 無理な営業は
いたしません
無料公開中 令和時代の買い手を理解する Webコンサルの基礎資料