短い答え
モバイルファーストインデックスは完了しました。2024年7月以降、Googleはインデックスとランキングにサイトのモバイル版のみを使用しています。コンテンツ、構造化データ、内部リンクがデスクトップには存在してもモバイルに存在しない場合、Googleはそれらを認識しません。2026年には、ほとんどのサイト運営者がまだ対応できていない3つの新しい影響があります：INPがFIDに代わるCore Web Vitalになったこと、AI Overviewsがモバイルレンダリングコンテンツから情報を取得すること、そして2026年3月のCore Updateでモバイルページ体験のランキング重みが増加したことです。
以下に、完全な監査ワークフローと、ほとんどのチェックを自動実行するコピーペースト可能なCodexスキルを紹介します。
2026年に「モバイルオンリー」が実際に意味すること
Googleは2018年にモバイルファーストインデックスへのサイト移行を開始しました。この移行には6年以上かかりました。2024年7月以降、デスクトップではアクセス可能でもモバイル版が存在しないコンテンツはGoogleのインデックスから削除されました。オプトアウトもデスクトップ専用のフォールバックも存在しません。
しかし話はこれで終わりではありません。2025〜2026年に起きた3つの変化が、「モバイルファースト」がサイトに要求するものを変えました：
変化1：INPがFIDに取って代わり、ほとんどのモバイルサイトが不合格に
2024年3月、GoogleはFirst Input Delay（FID）をInteraction to Next Paint（INP）に置き換え、Core Web Vitalとしました。INPは、タップ、クリック、キー入力に対してページが視覚的に応答するまでの時間を、最初の操作だけでなくページセッション全体にわたって測定します。
厳しい数字：FIDに合格していたサイトの約40%がINPに合格していません。モバイルでは、約65%のサイトしか「良好」の基準である200ミリ秒以下を達成できていません。2026年3月のCore Updateにより、Core Web Vitalsのランキング重みはさらに増加しました。モバイルINPに不合格のサイトは、より高速な競合に順位を奪われています。
変化2：AI OverviewsとAIクローラーがモバイルコンテンツを読み取る
GoogleのAI Overviewsは2026年半ば時点で約47%の検索に表示されています。GoogleのAIシステムが回答を生成する際、通常の検索と同じモバイルインデックスされたコンテンツから情報を取得します。サードパーティのAIクローラー（GPTBot、ClaudeBot、PerplexityBot）もモバイルレンダリングページにアクセスします。
モバイル版に構造化データ、明確な見出し、重要なテキストが欠けていると、デスクトップ版にそれらのコンテンツがあってもAIシステムはあなたのサイトを引用できません。
変化3：コンテンツパリティの欠如が測定可能なランキング影響に
2026年には、モバイルとデスクトップのコンテンツに一貫性がないサイトは、完全なコンテンツパリティを持つサイトと比較して、平均で31.2%低いオーガニック検索露出を示しています。モバイルで最も欠落しやすい要素：非表示タブのコンテンツ、サイドバーリンク、構造化データマークアップ、画像altテキスト、内部ナビゲーションリンクです。
コンテンツ要素 | モバイルで欠落しているサイトの割合 |
|---|---|
構造化データ（JSON-LD） | 23% |
内部リンク（メニュー、パンくずリスト） | 18% |
画像altテキスト | 27% |
タブ・アコーディオン内の全文 | 15% |
メタrobotsタグ | 9% |
サイトが合格しているかの確認方法（2分版）
完全な監査を実行する前に、これら3つのシグナルを確認してください。それぞれ1分未満で、深く調査すべきかを判断できます。
シグナル1：Google Search Consoleのインデックスステータス
Google Search Consoleを開く → 設定（左下の歯車アイコン）をクリック → 「概要」セクションを確認。「インデックス クローラ」の下に「Googlebot スマートフォン」と表示されていれば、サイトはモバイルファーストインデックスです。2026年には事実上すべてのサイトがそうなっていますが、確認しておきましょう。
さらに確認：URL検査ツール → 重要なページを入力 → 「クロール」を展開 → 「クロール済み：Googlebot スマートフォン」を確認。Googleが提供するスクリーンショットを見てください。これはGoogleが実際に見ているものです。そのスクリーンショットに重要なコンテンツが欠けていれば、それはインデックスからも欠けています。
シグナル2：実際のモバイルデータを使用したPageSpeed Insights
PageSpeed Insightsにアクセスし、URLを入力して、「実際のユーザーが体験しているデータ」セクションを確認します。これはChrome User Experience Report（CrUX）のフィールドデータであり、Googleがランキングに使用するのと同じデータです。
モバイルレポートでINP（Interaction to Next Paint）がオレンジまたは赤で表示されている場合、アクティブなランキング上の負債を抱えています。「良好」の基準は200ミリ秒未満です。
シグナル3：Chrome DevToolsのモバイルビューポート簡易チェック
Chrome DevTools（F12またはCmd+Option+I）を開き、デバイスツールバーアイコン（Ctrl+Shift+M）をクリックし、「Pixel 7」などのモバイルデバイスプリセットを選択します。ページをリロードして以下を確認：
- 横スクロールが必要なテキスト
- タップするには小さすぎるボタンやリンク（48×48 CSSピクセル未満）
- HTMLソースに存在しない「もっと読む」トグルに隠されたコンテンツ
- 画面の大部分を覆うポップアップ
これらはいずれも、デスクトップユーザーが見るものと異なる場合、モバイルインデックスの問題となります。
30分でできるモバイルファースト監査（Codexを使用）
今日、完全なモバイルファースト監査を最も早く実行する方法は、AIコーディングエージェント（Claude CodeまたはCodex）に構造化されたタスクを与えることです。エージェントがサイトのソースを読み取り、ルールをチェックし、優先順位付きの修正リストを生成します。
以下が完全なスキルファイルです。プロジェクトにコピーして、エージェントに実行を依頼してください。
ステップ1：スキルファイルの作成
.claude/skills/mobile-first-audit/SKILL.md（Claude Codeの場合）または.codex/skills/mobile-first-audit/SKILL.md（Codexの場合）にファイルを作成します：
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### ステップ2：監査の実行
エージェントに以下のように依頼します。`[あなたのURL]`の部分を確認したいURLに置き換えてください：
```text
Run the mobile-first audit skill on [your URL]エージェントが11項目それぞれのPASS/WARN/FAILと優先修正キューを含むレポートを生成します。
複数ページを一度に確認したい場合は、以下のようにリストを提供します：
Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]修正1：コンテンツパリティ — 最初にチェックすべきこと
コンテンツパリティは、Googleが何をインデックスできるかを直接決定するため、最も影響の大きい修正です。以下が最も頻繁に問題になる点とその修正方法です。
タブやアコーディオン内の非表示コンテンツ
多くのモバイルサイトでは、長いコンテンツをタブ、アコーディオン、「もっと読む」トグルに折りたたんでいます。これはコンテンツがHTMLソースに存在する限り問題ありません。GoogleはUX目的で非表示になっているコンテンツを割引しなくなりました。しかし、タブがユーザーのタップ後にJavaScriptでコンテンツを読み込む場合、Googlebotはそのタップをトリガーしないため、コンテンツは見えません。
確認方法： Chrome DevToolsで、非表示コンテンツを右クリックし「検証」を選択します。Elementsパネルにテキストが表示されていれば、DOMに存在しGoogleが見ることができます。タブをクリックするまでElementsパネルに空のコンテナしか表示されない場合、コンテンツは動的に読み込まれておりGoogleはそれを認識できません。
修正方法： 非表示コンテンツをサーバーサイドでHTMLにレンダリングします。表示/非表示の動作にはJavaScriptによるコンテンツ注入ではなくCSS（display: noneまたは可視性トグル）を使用します。
モバイルでの構造化データの欠落
構造化データ（JSON-LD）はモバイルHTMLに存在しなければなりません。モバイルテーマやAMPバージョンが異なるテンプレートを使用している場合、これは見落としがちです。
確認方法： モバイルページを開き、ソースを表示（Cmd+Option+U）して application/ld+json を検索します。デスクトップでも同じことを行います。両方に同じJSON-LDブロックが表示されるはずです。
修正方法： 構造化データがサーバーサイドでレンダリングされ、モバイルとデスクトップの両方で同じHTMLレスポンスに含まれるようにします。CMSを使用している場合、スキーマプラグインやテーマがデバイス検出に基づいて条件付きでスクリプトを読み込んでいないか確認します。
モバイルメニューから削除されたナビゲーションリンク
モバイルメニューでは、デスクトップナビゲーションに存在するリンク（パンくずリスト、カテゴリリンク、フッターカラム、サイドバーリンク）が簡略化または削除されることがよくあります。Googleは内部リンクをサイト構造の理解とPageRankの分散に使用します。モバイルにないリンクはGoogleのグラフからも欠落します。
確認方法： デスクトップソースとモバイルソースの <a href> タグの数を数えます。レスポンシブデザインではほぼ同じ数になるはずです。モバイルのカウントが30%以上少ない場合は、どのリンクが消えたのか調査します。
修正方法： 欠落しているナビゲーションリンクをモバイルメニュー、ハンバーガーメニュー、またはフッターに追加します。重要なカテゴリページ、主要記事、親ページへのリンクを優先します。
修正2：INP — ほとんどのサイトが無視しているモバイル速度指標
Interaction to Next Paint（INP）は、ユーザーがタップ、クリック、またはキーを押した後にページが視覚的に応答するまでの時間を測定します。基準は200ミリ秒以下です。
最初の操作の入力遅延のみを測定していたFIDとは異なり、INPはすべての操作を測定し、最も悪いものを報告します。これにより、はるかに厳格なテストとなっています。
モバイルINPを損なうもの
最も一般的な原因、重要度順：
- メインスレッドで実行される重いJavaScript。 大きなバンドル、最適化されていないReact/Vueコンポーネント、トラッキングスクリプトがブラウザのタップへの応答をブロックします。
- UIを更新する前に過剰な処理を行うクリックハンドラ。 タップがAPIコール、状態更新、DOM変更をトリガーし、視覚的なフィードバックを表示する前に処理が走るとINPが悪化します。
- サードパーティタグ。 アナリティクス、チャットウィジェット、広告ネットワーク、パーソナライゼーションスクリプト、特に複数のタグがメインスレッドを奪い合う場合に問題となります。
INPの診断方法
- PageSpeed Insightsを開き、URLを入力し、「実際のユーザーが体験しているデータ」までスクロールします。「モバイル」の下のINP値がGoogleの使用するものです。
- Chrome DevToolsで、Performanceパネルを開き、録画をクリックし、ページを操作（ボタンをタップ、メニューを開く、入力欄にタイプ）してから録画を停止します。長いタスク（赤く表示、200ms以上）を探します。これがINPの問題です。
- AIエージェントに以下のように尋ねることもできます：
Check the Core Web Vitals for [URL] and tell me specifically what is hurting INP on mobile. Give me the top 3 fixes in priority order.INPの修正方法（優先順）
優先度1：重要でないサードパーティスクリプトを遅延または延期する。
→ チャットウィジェット、アナリティクス、広告タグはページがインタラクティブになった後に読み込む。
→ <script defer> を使用するか、ページ読み込みの3〜5秒後に読み込む。
優先度2：長いJavaScriptタスクを分割する。
→ ルートごとにコード分割。ファーストビューより下のコンポーネントを遅延読み込み。
→ 重い計算を requestIdleCallback() またはWeb Workerに移動。
優先度3：クリックハンドラが即座にUIを更新するようにする。
→ 最初の50msでローディング状態、スピナー、または無効化ボタンを表示。
→ 実際の処理（APIコール、状態更新）は視覚的応答の後に実行。修正3：AIクローラー対応（2026年の新レイヤー）
モバイルファーストインデックスにAIレイヤーが加わりました。GoogleのAI OverviewsやサードパーティのAIシステムが質問に回答する際、同じモバイルインデックスコンテンツから情報を取得します。モバイルページにAIシステムが求めるシグナルが欠けていると、引用を失います。
AIシステムがモバイルページに求めるもの
シグナル | 重要な理由 | 簡易チェック |
|---|---|---|
構造化データ（JSON-LD） | AIシステムがエンティティ、製品、記事、FAQを理解するのを助ける | ソース表示 → |
明確な見出し階層 | AI抽出機能がH1-H4でページ構造を解析 | ページを確認：各セクションに説明的な見出しがあるか？ |
簡潔な回答ブロック | AI Overviewsは上部付近の2〜4文の回答を好む | ページは最初の200単語でメインの質問に答えているか？ |
AIクローラーのrobots.txtアクセス | ブロックされているとAIシステムはコンテンツを取得できない | robots.txtで |
llms.txtファイル | AIシステムが重要なコンテンツを効率的に発見するのを助ける |
|
エージェント向けAI対応簡易プロンプト
以下のプロンプトをエージェントに渡してください：
Check [URL] for AI search readiness. Tell me: (1) is JSON-LD structured data present and valid? (2) is there a clear answer to the page's main question in the first 200 words? (3) are AI crawlers allowed in robots.txt? (4) does llms.txt exist at the root? Give me a PASS/FAIL for each and tell me what to fix first.初心者向けモバイルファースト監査プロンプト集
Claude CodeやCodexに今すぐコピーできるプロンプト集です。各プロンプトは特定の作業を1つ実行します。エージェントを開いてプロジェクトまたはURLを指定する以外の設定は不要です。
プロンプト1：単一ページモバイル監査
Run a mobile-first indexing audit on [YOUR URL HERE].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.プロンプト2：ページタイプ横断の一括監査
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.プロンプト3：コンテンツパリティ詳細調査
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.プロンプト4：INP診断と修正計画
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.プロンプト5：AIクローラーと構造化データ監査
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).FAQ
Q: 引き続き別のモバイルサイト（m.example.com）を使用できますか？技術的には可能ですが、Googleはレスポンシブデザインを推奨しています。別のモバイルURLは複雑さを増します：2つのURLセット間で同一のコンテンツ、canonicalタグ、hreflangを維持する必要があります。何かが同期ずれすると、Googleは最後にクロールしたバージョンをインデックスします。レスポンシブデザインはこのリスクを完全に排除します。
Q: 私のサイトがデスクトップ専用でモバイル版がまったくない場合は？ Googlebot Smartphoneがコンテンツにアクセスしてレンダリングできない場合、そのコンテンツはインデックスされません。2026年にデスクトップ専用のサイトはGoogleに対して事実上不可視です。この状況にある場合、レスポンシブテーマへの切り替えが最優先のタスクです。
Q: タブレットサイズを気にする必要がありますか？ Googlebotはタブレットではなくスマートフォンとしてクロールします。スマートフォンのビューポートに集中してください。ただし、タブレットユーザーは実際のユーザーです。レスポンシブデザインが中間の幅（768-1024px）で崩れないことを確認してください。
Q: サイトがすでにモバイルファースト移行を完了したかどうかはどうやって確認できますか？ Google Search Console → 設定 → 「概要」セクションで「インデックス クローラ: Googlebot スマートフォン」を確認します。そう表示されていれば、モバイルファーストインデックスです。今ではほぼすべてのサイトがそうなっています。
Q: Googleは今でも何かのためにデスクトップuser-agentでサイトをクロールしますか？はい。Googleは特定のチェック（関係性の検証、一部の構造化データの再処理）のためにデスクトップuser-agentで時折クロールします。ログにデスクトップGooglebotが表示されても心配いりません。その訪問はサイトがデスクトップファーストインデックスであることを意味しません。
Q: モバイルファーストの問題を修正するとAI Overviewsの表示が改善されますか？モバイルファーストインデックスの修正は基盤を改善します。モバイルコンテンツ、構造化データ、ページ速度がすべて健全であれば、コンテンツは引用対象となりますが、GoogleのAIシステムは関連性、権威性、回答品質に基づいて引用するものを選択します。モバイルファーストの問題を修正することはブロッカーを取り除くことであり、AIへの掲載を保証するものではありません。
Author: Julian Mercer, 14-Year Technical SEO Practitioner at Auspia。Julianはクロール可能性、レンダリング、スキーマ、サイトアーキテクチャ、そして検索エンジンとAIシステムにコンテンツを発見可能にする技術的基盤について執筆しています。
