モバイルファーストインデックスは「完了」しているか ── 2026年、公式情報で確認する14項目

01 何が起きたか — 「移行は完了した」は、いつ、どこまで正しいのか

2023年10月31日、Googleは「完了」を宣言した

Googleは2023年10月31日、モバイルファーストインデックスへの移行が完了したと公式ブログで発表した(Mobile-first indexing has landed — thanks for all your support（訳: モバイルファーストインデックス、ついに到達 — 皆様のご協力に感謝）)。この発表を伝えたSearch Engine Landの記事によれば、Google担当者は次のように述べたという(Google says mobile-first indexing is complete after almost 7 years（訳: Googleが、モバイルファーストインデックスは約7年を経て完了したと発表）)。

"It's been a long road, getting from there to here. We're delighted to announce that the trek to Mobile First Indexing is now complete."

（訳: ここまで、長い道のりだった。モバイルファーストインデックスへの旅路が、ついに完了したことを発表できて嬉しく思う。）

同時にGoogleは、Search Consoleの設定画面から「インデックスに使うクローラー」という表示項目を削除したことも明らかにしている。理由はほぼ全サイトが常にモバイルクローラーで巡回されるようになり、その情報自体が不要になったためだと説明されている。「完了した」という言葉は、この設定項目の廃止という具体的な変更を伴っていた。

公式発表を年表で見る

2016年の構想発表から2023年の完了宣言まで、Googleの公式ブログでの節目は次のとおりである。

時期	出来事	出典
2016年11月	モバイル版のコンテンツを優先してインデックスする方針を初めて発表	Google公式ブログ
2018年3月	対象サイトへの段階的な切り替え（ロールアウト）を開始	Google公式ブログ
2019年7月	この日以降に作成された新規ドメインは、原則モバイルファーストインデックスがデフォルトに	Google公式ブログ
2020年3月	既存サイトを含む全サイトへの適用開始を発表（当初は同年9月をめどとすると公式ブログが明記していた）	Google公式ブログ
2021年11月	移行状況に関する続報を公開。この時点でも全サイトの切り替えは終わっていなかった	Google公式ブログ
2023年10月31日	「移行は完了した」と公式に発表。Search Console設定から関連項目を削除	Google公式ブログ
2025年12月10日	現行のモバイルファーストインデックス公式ヘルプページの最終更新日（本記事執筆時点で最新）	Google Search Central ヘルプ

「完了」の中に残っていた例外と、いまの書きぶり

完了宣言と同じ発表の中で、Googleは例外の存在も認めている。前掲のSearch Engine Journalの記事は、発表内容を次のように伝えている(Google Completes Switch to Mobile-First Indexing（訳: Googleがモバイルファーストインデックスへの切り替えを完了）)。

"a small number of sites still do not function properly on mobile"

（訳: ごく一部のサイトは、いまもモバイルで正しく機能していない。）

そして現行のモバイルファーストインデックス公式ページ自体も、実は「いつ完了したか」を一言も書いていない。書かれているのは、次のような現在形の事実だけである(Mobile-first indexing best practices（訳: モバイルファーストインデックスのベストプラクティス）)。

"Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. This is called mobile-first indexing."

（訳: Googleは、スマートフォン用のクローラーで取得したサイトのモバイル版のコンテンツを、インデックス登録とランキングに使う。これをモバイルファーストインデックスと呼ぶ。）

「表示できている」ことと「評価の対象になっている」ことが別だ、という構図は、このサイトが他のテーマでも繰り返し確認してきたことである。HTTPが200を返しても、その出力を誰も見ていなければ、問題は誰にも気づかれないまま残り続ける(archives/128)。モバイルファーストインデックスにおいても、「モバイル版が一応表示される」ことと「モバイル版がGoogleの評価対象として機能している」ことは、確かめるまで同じかどうか分からない。

02 なぜ・背景 — なぜ「モバイル版」が基準になったのか

クロールする版と、評価に使う版がずれていた時代

モバイルファーストインデックス以前、Googleは主にデスクトップ版のコンテンツをクロールし、それを検索結果の並び順（ランキング）の判断材料にしていた。ところが検索する側の多くは、すでにスマートフォンを使っていた。デスクトップ版とモバイル版で内容・構造化データ・画像が食い違うサイトでは、Googleが実際に見ている版と、多くの利用者が実際に見る版が一致しないという状態が起きていた。モバイルファーストインデックスは、この不一致を「評価に使う版をモバイル版に統一する」という形で解消する施策である。

クローラーをスマートフォン用に切り替えるだけなら、Google側の変更で完結する。実際に7年近い年月がかかったのは、サイト側の実装が、その前提を満たしていなかったためである。レスポンシブでないサイト、モバイル版だけ構造化データが抜けているサイト、モバイル版の方が画像を間引いているサイトは、切り替えた瞬間にモバイル版の薄い情報だけで評価されることになる。だからGoogleは、新規ドメインへの適用（2019年）、全サイトへの適用開始（2020年）、延期を挟んだ完了（2023年）という、複数年にわたる段階を踏んだ。

03 この記事で出てくる用語

混同しやすい2つの言葉

「モバイルフレンドリー」と「モバイルファーストインデックス」は、日常の会話ではほぼ同じ意味で使われがちだが、指している範囲が違う。モバイルフレンドリーはそのページがモバイル端末で見やすいかどうかという個別ページの評価軸であり、モバイルファーストインデックスはどちらの版を評価の基準にするかというサイト全体の仕組みである。モバイルで見やすく作られていても、モバイル版にPC版と同じ情報が入っていなければ、モバイルファーストインデックスの観点では不利になる。逆にモバイル版に情報を詰め込みすぎて見づらくなれば、モバイルフレンドリーの観点で不利になる。両方を同時に満たす必要がある。

04 型別 — 適用範囲・この移行が測っていないこと・手順

🅰 適用範囲 — どんなサイト構成が対象になるか

モバイルファーストインデックスの対象は、モバイル端末からもアクセスできるほぼすべてのサイトである。ただし、サイトの実装方式によって、注意すべき点が変わる。公式ページはサイトの構成を大きく3種類に分けており、それぞれ扱いが異なる（3種類の比較は06章で表にまとめる）(Separate URLs（訳: 別々のURL）)。

PC版とモバイル版で同じURL・同じHTMLを返すレスポンシブ構成であれば、この記事のチェック項目の多くは「そもそも版が1つしかないので、ずれようがない」という形で自動的にクリアされる。一方、モバイル版だけ別のURL（m.example.com型）を持つ構成や、同じURLでもユーザーエージェントによって出し分ける動的配信の構成では、PC版とモバイル版の内容を意図的に揃え続ける作業が必要になる。

🅱 この移行が測っていないこと — 「表示できる」と「評価される」は別

公式ページが明記している内容確認の基準は、次の一文に集約されている(前掲のGoogle公式ページ)。

"Make sure that your mobile site contains the same content as your desktop site."

（訳: モバイルサイトが、デスクトップサイトと同じコンテンツを含んでいることを確認する。）

逆に言えば、PC版にしかないコンテンツ・構造化データ・画像・動画は、モバイルファーストインデックスの下では評価に使われない。ページが「表示できる」ことと、そこに書かれた情報が「評価に使われる」ことは別であり、この移行が測っているのは後者だけである。PC版だけ厚く作り込み、モバイル版を簡易版のまま放置しているサイトでは、力を入れて書いた部分がそもそも評価の対象から外れている可能性がある。

この5項目のうち、見落とされやすいのが構造化データとrobotsメタタグである。公式ページは構造化データについて次のように述べている。

"Make sure that your mobile and desktop sites have the same structured data."

（訳: モバイルサイトとデスクトップサイトが、同じ構造化データを持っていることを確認する。）

すべての構造化データを両方の版に入れる余裕がない場合、公式ページはパンくずリスト（Breadcrumb）・商品（Product）・動画（VideoObject）の3種類を優先するよう勧めている。パンくずリストのマークアップ自体が検索結果に反映されるとは限らないという別の論点もあるが(パンくずリストをマークアップしても、検索結果に出るとは限らない)、両方の版に同じ構造化データを入れておくこと自体は、モバイルファーストインデックスの前提条件として独立に必要である。

"Use the same robots meta tags on the mobile and desktop site. If you use a different robots meta tag on the mobile site (especially the noindex or nofollow tags), Google may fail to crawl and index your page when your site is enabled for mobile-first indexing."

（訳: モバイルサイトとデスクトップサイトで、同じrobotsメタタグを使う。モバイルサイトで異なるrobotsメタタグ（特にnoindexやnofollow）を使っていると、モバイルファーストインデックスが有効になったときに、Googleがそのページをクロール・インデックス登録できなくなる可能性がある。）

PC版にはnoindexを付けず、モバイル版にだけ古い設定でnoindexが残っている、といった出し分けの事故は、切り替わった瞬間にページ全体がインデックスから外れる形で表面化する。しかもこの種の食い違いは、PC版だけを見て確認している限り、いつまでも気づかれない。

🅲 手順 — 自分のサイトの構成を先に見分ける

確認の手順は、まず自分のサイトがどの構成なのかを判断することから始まる。ブラウザの開発者ツールで、PCの画面幅とスマートフォンの画面幅（横幅375px程度）でページを開き、URLが変わるかどうかを見る。URLが変わらずレイアウトだけ変わるならレスポンシブ、URLがm.example.comのように変わるなら別々のURL構成である。URLが変わらないのに、開発者ツールのネットワークタブで確認するとレスポンスの中身がユーザーエージェントによって違う場合は、動的配信を使っている。この判定結果によって、05章のチェックリストのうち一部の項目が「対象外」になる（レスポンシブ構成であれば、rel="alternate"やVaryヘッダーの確認は不要になる）。

この項目が「パソコン」と表示されている場合、そのページはまだモバイル版を基準に評価されていない可能性がある。ライブテストを実行して成功すれば、「テスト済みページを表示」からレンダリング後のスクリーンショットも確認できるため、実際にモバイル版として何が取得されているかを目で見て確かめられる。

05 明日、自分のサイトで確認できることチェックリスト

チェックリストの観点と、かかる時間の目安

ここまでの内容を、今日から手を動かせる作業に翻訳した。観点は、現状把握（自分のサイトがどの構成で、どちらの版でクロールされているかを確認する）、内容の突き合わせ（PC版とモバイル版のずれを探す）、実装方式ごとの点検（レスポンシブ以外の構成でのみ必要な項目）の3つに分かれる。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。

• URL検査ツールに代表的なURLを1件入力し、「ページのインデックス登録」欄の「クロール」の値がスマートフォンかパソコンかを確認する
• 同じ画面で「ライブテスト」を実行し、成功したら「テスト済みページを表示」からスクリーンショットを開いて見た目を確認する
• ブラウザの開発者ツールで画面幅を375px程度に縮め、PC版で見えている見出し・段落の数を、モバイル版でも数えて突き合わせる
• PC版とモバイル版で、titleタグとmeta descriptionの文字列を1文字ずつコピーして比較する
• 構造化データを入れているページを1つ選び、PC版とモバイル版でJSON-LDのtypeとプロパティの数が一致しているか数える
• その構造化データがパンくずリスト・商品・動画のいずれかであれば、優先して両方の版に入れる
• robots.txtを開き、PC版とモバイル版で参照するファイルが同じかどうか、Disallowの行数を数えて突き合わせる
• 個別ページのhead内にあるrobotsメタタグを、PC版とモバイル版で1行ずつ見比べ、noindex・nofollowの有無が一致しているか確認する
• 自分のサイトの構成がレスポンシブか、別々のURLか、動的配信かを、04章の手順で判定する
• 別々のURL構成の場合、PC版にrel="alternate"、モバイル版にrel="canonical"のタグが1対1で入っているか、ソースコードを開いて数える
• 動的配信の場合、開発者ツールのネットワークタブでレスポンスヘッダーに「Vary: User-Agent」が含まれているか確認する
• 画像を掲載しているページで、モバイル版のalt属性の文字数がPC版と一致しているか、代表的なページで3件数える
• 過去に公開した記事から3本選び、モバイル版で本文の末尾まで表示されるのにかかる時間を、自分のスマートフォンで実際に計測する
• ここまでで見つかったずれを1件ずつ書き出し、優先度の高いものから3件を選んで今週中に直す

14項目の内訳は次のとおりである。最初の3項目は現状把握、4番目から8番目は内容の突き合わせ、9番目から11番目は実装方式ごとの点検、12番目以降は仕上げの確認と修正に対応している。すべてに目を通す時間の目安は1サイトあたり30分程度である（13番目の実機での読み込み計測を含む）。9番目で自分のサイトがレスポンシブだと判明した場合、10・11番目は対象外として読み飛ばしてよい。

06 サイト構成、3つの選択肢を比較する

3つの実装方式、それぞれの負担

モバイル対応のサイト構成には、公式ページが挙げる3つの方式がある(前掲のSeparate URLs)。以下は、それぞれがモバイルファーストインデックスの下でどう扱われ、運用にどれだけ手間がかかるかを整理した表である。

方式	モバイルファーストインデックスでの扱い	実装・運用の負担
レスポンシブ ウェブデザイン	同一URL・同一HTMLのため、内容がずれるという事故がそもそも起きにくい。Googleが公式に推奨	低い（多くのCMSやテーマが標準対応している）
動的配信 （Dynamic Serving）	同一URLだがユーザーエージェントで出し分ける。Varyヘッダーの設定漏れが評価事故になりやすい	中程度（サーバー設定を継続的に管理する必要がある）
別々のURL （セパレートURL）	rel="alternate"とrel="canonical"を1対1で対応させる必要がある。対応漏れが起きやすい	高い（2つのHTML・2つのURL構成を維持し続ける）

Googleが別々のURL構成からの移行を勧めている理由

Googleは2017年、別々のURL構成（m.example.com型）からレスポンシブへの移行を促す記事を公式ブログに掲載している(How to move from m-dot URLs to responsive site（訳: m-dot URLからレスポンシブサイトへ移行する方法）)。レスポンシブに統一する場合は、rel="alternate"・rel="canonical"・条件付きリダイレクト・Varyヘッダーといった、別々のURL構成のために追加していた設定を、すべて取り除く必要がある。設定を消し忘れたまま統合すると、存在しないモバイルURLへの参照が残り、別の不整合を生む。

07 起きやすい落とし穴 — 「モバイル対応している」のに評価が下がる典型パターン

落とし穴1 — 設定の出し分けミス（Varyヘッダー・noindexの食い違い）

動的配信を使っているのに、レスポンスヘッダーに「Vary: User-Agent」を含めていないケースがある。このヘッダーが無いと、Googleのクローラーだけでなく、CDNやプロキシのキャッシュも、ユーザーエージェントによって内容を出し分けていることを認識できない。結果として、モバイル用のキャッシュがPC向けに配信される、あるいはその逆といった事故につながる。開発者ツールのネットワークタブで、レスポンスヘッダーを一度確認しておく価値がある。

もう一つ起きやすいのが、PC版とモバイル版を別々のテンプレートで管理しているサイトで、片方のテンプレートにだけ古いnoindex設定が残っているケースである。04章で引用した公式の警告のとおり、この食い違いはページ全体をインデックスから除外する形で表面化する。しかも多くの担当者は、日常的にPC版のブラウザで作業を確認しているため、モバイル版だけがnoindexになっている事故は、PC版をいくら確認しても見つからない。

落とし穴2 — JavaScriptで後から読み込む本文

公式ページは、遅延読み込み（lazy load）について次のように注意している。

"Don't lazy-load primary content upon user interaction. Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load."

（訳: 主要なコンテンツを、ユーザーの操作をきっかけに遅延読み込みしない。Googleは、スワイプ・クリック・入力といったユーザー操作を必要とする形の読み込みを行わない。）

「もっと見る」ボタンを押さないと表示されない本文、タブを切り替えないと出てこない説明文は、モバイル版でこの形になっているとGoogleに読まれない可能性がある。画面に表示された時点で自動的に読み込む形にしておくことが、公式の推奨に沿った実装である。クロールが2MBという上限を持っているという別の制約とあわせて考えると(Googleのクロールは2MBで止まる)、本文を後から少しずつ読み込ませる設計は、複数の理由で不利に働きやすい。

08 このテーマの、これまで

「見た目」だけでは、どちらの版かを判断できないと確認した回

見た目が同じに見えるファイルでも、実際には別の場所で作られ、運ばれてきたものだと判明した調査を、画像のタイムスタンプを実際に開いて確認した回がある(archives/133)。04章で扱った「PC版とモバイル版が同じに見えても、内容が一致しているとは限らない」という論点は、この回で確認した「見た目では区別できない」という構図と重なる。

「出力はあった。だから誰も測らなかった」と確認した回

HTTPが正常な値を返し続けていたために、その中身を誰も長期間にわたって確認していなかった事例を、実際のログを開いて確認した回がある(archives/128)。01章で触れた「表示できる」ことと「評価される」ことの違いは、この回で確認した構図と同じである。URL検査ツールでHTTP 200が返ることと、モバイル版として正しく評価されていることは、別々に確認する必要がある。

「測定中」と書いたまま、実際には測っていなかった回

ラベルを付けたまま、実際にはその測定を長期間行っていなかった事例を、公開から52日分のログを開いて確認した回がある(archives/135)。05章のチェックリストも、一度実行して終わりにする性質のものではない。サイトを更新するたびにPC版とモバイル版が再びずれていないか、定期的に開き直す運用を決めておくことが、このテーマにおいても同じように重要である。