モバイルとデスクトップの Google 順位はなぜ違うのか（2026）

順位は単一の数字ではありません。同じサイト、同じクエリ、同じ 90 日間で尋ねても、モバイルとデスクトップは一致しません。私たち自身の Search Console データでは、あるクエリでその差は 11.4 順位に達し、しかも優劣の向きはクエリによって入れ替わりました。モバイルのほうが上位のこともあれば、デスクトップのほうが上位のこともあったのです。

これはデータの不具合ではなく、モバイル順位トラッカーを買う理由にもなりません。Google が検索結果ページをどう組み立てるかの性質であり、混ぜ合わせた平均値を見ているかぎり見えてこないものです。

本記事では、この分離が実際に何によって起きるのか、私たち自身の数字がどうだったのか、そして両者を切り分けて「モバイルのトラフィックについてデスクトップの判断をしてしまう」状態をやめるための短い Claude Code ワークフローを扱います。

よくある誤解

多くのチームが、たいてい口に出さないまま抱えている前提があります。順位とはページの属性だ、という前提です。あるクエリで 8 位なら、8 位である、と。順位トラッカーはこの前提を補強します。既定がひとつのデバイスで、キーワードごとに数字をひとつ印刷するからです。

実務上の帰結は報告の習慣になります。誰かがデスクトップの順位を調べ、表計算に入れ、その下流のすべてがそれを可視性の真実として扱う。それだけのことです。

より役に立つ現実

Google 自身が文書化している 2 つの事実が、単一数値モデルを壊します。

事実 1：順位づけされているのはモバイルページです。 Google の Search Central のドキュメントはこう明言しています。「Google はサイトのコンテンツのモバイル版を、スマートフォン エージェントでクロールして、インデックス登録とランキングに使用します。」検索している人がノートパソコンの前にいても、デスクトップの HTML が主要な入力ではありません。

事実 2：検索結果ページは目の前のデバイス向けに組み立てられます。 Search Console のヘルプ ドキュメントはそれを率直に述べています。二度読む価値があります。「検索結果は、検索した人の時間、場所、デバイス、最近の履歴に固有のものです。」

この 2 つを合わせると、あなたが書き留めた順位は、デバイスによってずれる分布からの 1 サンプルにすぎません。数字が間違っているわけではありません。ただ、使われ方よりもずっと狭いのです。

この神話がこれほど広がる理由

4 つのありふれた事情が、単一数値モデルを生き延びさせています。

• トラッカーの既定はデスクトップです。 デスクトップの SERP は取得が安く保存も簡単なので、既定の列になります。デバイス切り替えは多くのプランに存在しますが、それは既定でオンであることとは別の話です。
• Search Console はデバイスを混ぜます。 既定の [Performance] レポートはモバイル、デスクトップ、タブレットを平均します。分離を見るには [デバイス] タブを開くか、device をディメンションとして API を叩く必要があります。既定のビューには、混ざっていることを警告するものは何もありません。
• モバイル順位トラッキングは追加料金として売られます。 ベンダーが「モバイル順位トラッカー」を機能として並べるとき、標準レポートがすでにすべてをカバーしているという含意が生まれます。実際にカバーしているのは一部です。
• 小さなサンプルでは効果が見えません。 10 個のクエリを見てすべて一致していたら、問題は理論上のものに見えます。見えてくるのはクエリ単位、平均を取れるだけの表示回数があるクエリにおいてです。

私たち自身の 90 日間でわかったこと

私たちは自社の Search Console プロパティから、2026 年 9 月 11 日で終わる 90 日間を、query と device をディメンションとして取得しました。

同じプロパティ、同じ期間、3 つの異なる物語。モバイルの平均掲載順位のほうが良く、モバイルの CTR のほうが悪い点に注目してください。

この表には注意して読むべき点が 2 つあります。

ひとつ目は逆転したシグナルです。モバイルの平均掲載順位はデスクトップより良かった（30.8 対 34.4）のに、モバイルの CTR は悪かった（0.97% 対 1.10%）。順位が良くてクリック率が悪いのはモバイルでは普通のことです。結果ページは縦に長く、レイアウトも異なり、ページ上部はさまざまな機能で混み合っています。順位だけを報告していたら、モバイルのほうが強い面だと言ってしまい、クリックの差をまるごと見落としていたでしょう。

ふたつ目は、サイト全体の平均を読むこと自体に潜む罠です。この 2 行は異なるクエリ構成を要約しています。私たちの読者はデスクに向かう SEO 実務者なので、デスクトップが表示回数の 82% を占めており、モバイルは別の、より小さなクエリ群を担っています。サイト全体の平均はそれを隠します。数字を実行可能にするのはクエリ単位の結合です。

そこで私たちは結合しました。表示回数 20 以上の 130 クエリのうち、85 が両デバイスにデータを持っていました。以下は最も大きい 6 件の乖離です。

差は両方向に走ります。「モバイルは順位が悪い」は「順位は順位である」と同じくらい誤りです。

向きは入れ替わります。これがあなたの運用習慣を変えるべき発見です。経験則でデバイス間の乖離を直すことはできません。補正すべき一貫した向きが存在しないからです。クエリごとに測るしかありません。

代わりにやるべきこと：分割、結合、しきい値、判断

4 つのステップ、ワークフローさえあれば約 20 分です。

ステップ 1：query と device を一緒に取得する。 Search Console で [Performance] を開き、[クエリ] と並べて [デバイス] タブを追加し、90 日でエクスポートします。API 経由なら、ディメンション ["query","device"] を、クエリ集合を保持できるだけの行数上限でリクエストします。API は中規模サイトが必要とする数をはるかに超える行数上限を受け付けるので、大きめに要求してローカルで絞り込みます。

すでに週次の順位レポートを出しているなら、これは新しいブックではなく、自分が持っているものにディメンションをひとつ足すだけになります。私たちの週次順位レポートのワークフローで示したレポートの型には、そのための枠があります。

ステップ 2：クエリをキーに結合する。 クエリごとに 1 行、モバイル列とデスクトップ列を持たせます。片方のデバイスにしか存在しない行は、それ自体が発見です。そのクエリが一方の面では表示回数を得て、もう一方では得ていないという意味だからです。

ステップ 3：見る前にしきい値を適用する。 5 順位が出発点として使えるしきい値です。それ未満はノイズを読んでいます。それ以上なら、2 つの面が本当に食い違っているクエリです。

ステップ 4：クエリ単位ではなく、クエリ分類単位で判断する。 マネークエリから先に直します。比較系のクエリは、あなたのページが弱いからではなく、SERP のレイアウトが違うために乖離することが普通です。ブランドクエリの乖離は、まず SEO の問題ではありません。情報系のクエリは後回しで構いません。

分割を実行する Claude Code ワークフロー

繰り返し可能な部分は機械的です。取得、結合、しきい値、要約。これはまさに、あなたの一週間ではなくエージェントに入れるべき形の仕事です。

Claude Code が読める指示ファイルとして保存し、自分が所有するプロパティを指し示してください。

直近 90 日間について、プロパティ <property> の Search Console データを取得する。
ディメンションは query, device を使う。表示回数 20 以上のクエリだけを残す。

クエリをキーにモバイルとデスクトップを結合する。
両方のデバイスに存在するすべてのクエリについて、平均掲載順位の絶対差を計算する。

差が 5.0 以上の行だけを、合計表示回数の降順で出力する。
各行には次を表示する：クエリ、モバイル順位、デスクトップ順位、差、どちらが上位か、
モバイルの表示回数、デスクトップの表示回数。

最後に要約を 2 行つける：
1. モバイルが上位のクエリ数と、デスクトップが上位のクエリ数。
2. 差が最も大きい単一のクエリと、その合計表示回数。

修正案は出すな。コンテンツの提案も書くな。
出力は作業フォルダに mobile-desktop-gap-YYYY-MM-DD.md として保存する。

この指示には意図的な選択が 3 つあり、応用する場合も残す価値があります。

表示回数の下限を設定しています。モバイルの表示回数が 4 しかないクエリの平均順位は何の意味も持ちません。修正案の提示を禁じています。判断はクエリ分類と事業の文脈に依存し、そこでエージェントが推測すると自信満々のナンセンスが出力されるからです。そして日付つきのファイルに保存するので、来月の分割を今月と比較できます。修正が効いたかどうかを見る唯一の方法です。

このプロンプトは形としてはエージェント中立です。Codex は同じ指示を独自のファイル規約で実行し、レビューのステップは同一です。

ガードレール

• 表示回数がおよそ 20 を下回ったら止めます。 一握りの表示回数での平均順位は、それだけで二桁動きます。プロンプトのしきい値はこの理由で存在します。
• タブレットはモバイルではありません。 私たちのタブレット行は表示回数 156、クリック 0 でした。タブレットをモバイルにまとめると、モバイル検索とは何の関係もない理由でモバイルの数字が悪くなっていたでしょう。
• 本記事は計測の話であり、適格性の話ではありません。 Google があなたのモバイルコンテンツをそもそも見られているかは、別の問題で別のチェックです。監査側は2026 年のモバイル ファースト インデックスで扱いました。
• 順位が良くても結果が悪いことはあります。 私たち自身のデータで、モバイルは順位が良く、クリックは悪いという結果でした。順位とクリック率は一緒に読む必要があります。
• すべての差を追いかけないでください。 月間検索 30 回のクエリの 6 順位差はプロジェクトではありません。リストを表示回数で並べ替え、テールはそのままにしておきましょう。
• 深い順位は挙動が違います。 クエリが両デバイスで 100 位より下にあるなら、まず深さの問題を直してください。Google の検索結果が実際どこまで続くかは順位チェックの深さ検証で計測しました。

Auspia の見解：デバイス間の乖離は、順位の問題である前に計測の問題です。ほとんどのチームは一度も見たことがありません。既定のレポートが分離を隠すからです。分離が見えるようになると、ほとんどの差は説明がつき、興味深いいくつかだけが修正に値します。

FAQ

Google はモバイルページとデスクトップページを別々に順位づけしますか？ 実質的にははい。Google はコンテンツのモバイル版をインデックスし、スマートフォンに返される結果ページはノートパソコンに返されるものと異なります。2 つの順位は同じ基盤システムから来ていますが、同じ数字ではありません。

順位トラッカーと Search Console の数字が違うのはなぜですか？ 測っているものが違うからです。トラッカーは 1 つの場所とデバイスでライブ SERP を取得します。Search Console はすべてのデバイス、国、期間全体にわたって表示回数を平均します。どちらも正しく、かつ食い違うことがあります。

モバイル順位トラッカーとは何で、必要ですか？ モバイル順位トラッカーは、キーワードセットに対してスマートフォンの SERP を取得します。競合の順位や、自社データでは見えない地域が必要なら、費用を払う価値があります。自社サイトのモバイル可視性だけが必要なら、Search Console がすでにデバイス別に、無料で持っています。

デバイス別の順位が信頼できるのは表示回数いくつからですか？ おおよそ 20 が粗い読みの実用上の下限で、100 以上になると数字は週ごとに動かなくなります。20 未満はリストには残しつつ、行動しないでください。

Claude Code は Search Console を直接読めますか？ はい、サービス アカウントまたは OAuth 認証情報を使った Search Console API 経由で可能です。上記のワークフローはその接続が存在する前提です。どの順位タスクをエージェントに渡す価値があり、どれはないかはSEO エージェントのガイドで扱っています。

モバイルの順位が悪いとき、モバイルページを直すべきですか？ まず SERP を確認してください。モバイルの結果ページにより多くの動画、より多くのローカルパック、あるいは異なるページ種別の構成が含まれるなら、直すべきはページ品質ではなくコンテンツ形式です。SERP の形が一致していてページも問題ないなら、コンテンツのパリティ問題として扱い、モバイル ファーストのチェック項目と突き合わせて監査してください。

著者：Marcus Ellery、Auspia で 150 以上の SEO テストを率いるグロース実験担当。ベンチマークデータ、統制されたテスト、そして指標が動くことと指標が意味を持つことの違いについて書いています。