Короткий ответ
Переход на Mobile-First индексацию завершён. С июля 2024 года Google использует только мобильную версию вашего сайта для индексации и ранжирования. Если контент, структурированные данные или внутренние ссылки присутствуют на десктопной версии, но отсутствуют на мобильной — Google их не видит. В 2026 году появились три новых последствия, которые большинство владельцев сайтов ещё не устранили: INP заменил FID как Core Web Vital, AI Overviews извлекают данные из мобильного контента, и мартовское Core Update 2026 года повысило вес мобильного пользовательского опыта в ранжировании.
Ниже представлен полный рабочий процесс аудита — а также готовый Codex-скилл, который выполняет большинство проверок за вас.
Что на самом деле означает «только мобильная версия» в 2026
Google начал переводить сайты на Mobile-First индексацию в 2018 году. Переход занял более шести лет. По состоянию на июль 2024 года все сайты, у которых оставался контент на десктопе без мобильного эквивалента, потеряли этот контент из индекса Google. Отказаться от этого нельзя, и десктопного резервного варианта не существует.
Но на этом история не закончилась. Три изменения в 2025–2026 годах изменили то, что «Mobile-First» требует от вашего сайта:
Изменение 1: INP заменил FID — и большинство мобильных сайтов его не проходят
В марте 2024 года Google заменил First Input Delay (FID) на Interaction to Next Paint (INP) в качестве Core Web Vital. INP измеряет, насколько быстро ваша страница реагирует на касания, клики и нажатия клавиш в течение всей сессии на странице, а не только первого взаимодействия.
Сухие цифры: примерно 40% сайтов, проходивших FID, не проходят INP. На мобильных устройствах только около 65% сайтов соответствуют «хорошему» порогу в 200 миллисекунд или меньше. Мартовское Core Update 2026 года дополнительно повысило вес Core Web Vitals в ранжировании. Сайты, не проходящие мобильный INP, теперь теряют позиции в пользу более быстрых конкурентов.
Изменение 2: AI Overviews и AI-краулеры читают ваш мобильный контент
AI Overviews от Google появляются примерно в 47% поисковых запросов по состоянию на середину 2026 года. Когда AI-системы Google генерируют ответы, они извлекают данные из того же мобильно-индексированного контента, который используется обычным поиском. Сторонние AI-краулеры (GPTBot, ClaudeBot, PerplexityBot) также получают доступ к вашим мобильным страницам.
Если в вашей мобильной версии отсутствуют структурированные данные, чёткие заголовки или критически важный текст, AI-системы не могут цитировать вас — даже если десктопная версия содержит этот контент.
Изменение 3: Разрывы в паритете контента теперь имеют измеримое влияние на ранжирование
В 2026 году сайты с несоответствием мобильного и десктопного контента показывают на 31,2% меньше органической поисковой видимости в среднем по сравнению с сайтами с полным паритетом контента. Наиболее часто отсутствующие элементы на мобильной версии: скрытый контент вкладок, ссылки боковой панели, разметка структурированных данных, alt-текст изображений и внутренние навигационные ссылки.
Элемент контента | % сайтов, где он отсутствует на мобильной |
|---|---|
Структурированные данные (JSON-LD) | 23% |
Внутренние ссылки (меню, хлебные крошки) | 18% |
Alt-текст изображений | 27% |
Полный текст во вкладках/аккордеонах | 15% |
Мета-теги robots | 9% |
Как проверить, проходит ли ваш сайт проверку (версия на 2 минуты)
Перед запуском полного аудита проверьте эти три сигнала. Каждый занимает менее минуты и показывает, стоит ли копать глубже.
Сигнал 1: Статус индексации в Google Search Console
Откройте Google Search Console → нажмите Настройки (иконка шестерёнки, внизу слева) → посмотрите раздел «О программе». Если там указано «Googlebot для смартфонов» в разделе «Сканер индексации», ваш сайт находится на Mobile-First индексации. В 2026 году это справедливо практически для всех сайтов — но проверьте это.
Также проверьте: Инструмент проверки URL → введите любую важную страницу → разверните «Сканирование» → убедитесь, что «Сканировано как: Googlebot для смартфонов». Посмотрите на скриншот, который предоставляет Google — это именно то, что видит Google. Если ключевой контент отсутствует на этом скриншоте, он отсутствует и в индексе.
Сигнал 2: PageSpeed Insights с реальными мобильными данными
Перейдите на PageSpeed Insights, введите ваш URL и посмотрите на раздел «Узнайте, что испытывают ваши реальные пользователи». Это полевые данные Chrome User Experience Report (CrUX) — те же данные, которые Google использует для ранжирования.
Если мобильный отчёт показывает оранжевый или красный цвет для INP (Interaction to Next Paint), у вас есть активный риск для ранжирования. Порог — менее 200 миллисекунд для зелёной зоны.
Сигнал 3: Быстрая проверка мобильного viewport в Chrome DevTools
Откройте Chrome DevTools (F12 или Cmd+Option+I), нажмите иконку панели устройств (Ctrl+Shift+M) и выберите пресет мобильного устройства, например «Pixel 7». Перезагрузите страницу. Проверьте:
- Текст, требующий горизонтальной прокрутки
- Кнопки или ссылки, слишком маленькие для нажатия (менее 48x48 CSS-пикселей)
- Контент, скрытый за переключателями «читать далее», отсутствующий в HTML-исходнике
- Всплывающие окна, закрывающие большую часть экрана
Каждый из этих пунктов является проблемой Mobile-First индексации, если контент или ссылки за ними отличаются от того, что видят пользователи десктопа.
30-минутный Mobile-First аудит (с Codex)
Самый быстрый способ провести полный Mobile-First аудит сегодня — дать 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: Запустите аудит
Попросите агента: **«Запусти скилл mobile-first аудита на [ваш URL]»** и вставьте URL, который нужно проверить. Агент подготовит отчёт с PASS/WARN/FAIL по каждому из 11 пунктов, а также приоритизированную очередь исправлений.
Если нужно проверить несколько страниц сразу, предоставьте список: **«Запусти mobile-first аудит на этих 5 URL: [URL1, URL2, URL3, URL4, URL5]»**.
## Исправление №1: Паритет контента — с чего начать
Паритет контента — это наиболее эффективное исправление, поскольку оно напрямую определяет, что Google может проиндексировать. Вот что ломается чаще всего и как это исправить.
### Скрытый контент во вкладках и аккордеонах
Многие сайты на мобильных устройствах сворачивают длинный контент во вкладки, аккордеоны или переключатели «читать далее». Это нормально, **пока контент присутствует в HTML-исходнике** — Google больше не дисконтирует контент, скрытый по UX-причинам. Но если ваши вкладки загружают контент через JavaScript после касания пользователя, Googlebot не инициирует это касание. Контент невидим.
**Как проверить:** В Chrome DevTools щёлкните правой кнопкой мыши по скрытому контенту и выберите «Inspect». Если текст виден в панели Elements, он находится в DOM и Google может его видеть. Если панель Elements показывает пустой контейнер до тех пор, пока вы не нажмёте на вкладку, контент загружается динамически и Google его пропускает.
**Как исправить:** Отрендерите скрытый контент на стороне сервера в HTML. Используйте CSS (`display: none` или переключение видимости) для поведения показа/скрытия вместо внедрения контента через JavaScript.
### Отсутствующие структурированные данные на мобильной версии
Структурированные данные (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
Наиболее частые причины, по порядку:
1. **Тяжёлый JavaScript, работающий в главном потоке.** Крупные бандлы, неоптимизированные React/Vue-компоненты и скрипты отслеживания блокируют способность браузера реагировать на касания.
2. **Обработчики кликов, выполняющие слишком много работы до обновления UI.** Если касание вызывает API-запрос, изменение состояния и изменение DOM до отображения какой-либо визуальной обратной связи, страдает INP.
3. **Сторонние теги.** Аналитика, чат-виджеты, рекламные сети и скрипты персонализации — особенно когда несколько тегов конкурируют за главный поток.
### Как диагностировать INP
1. Откройте [PageSpeed Insights](https://pagespeed.google.com/), введите ваш URL, прокрутите до «Узнайте, что испытывают ваши реальные пользователи». Значение INP в разделе «Мобильные» — это то, что использует Google.
2. В Chrome DevTools откройте панель **Performance**, нажмите запись, взаимодействуйте со страницей (нажимайте кнопки, открывайте меню, вводите текст в поля), затем остановите запись. Ищите длинные задачи (отмечены красным, 200ms+). Это ваши проблемы INP.
3. Также можно спросить AI-агента: **«Проверь Core Web Vitals для [URL] и скажи, что именно ухудшает INP на мобильных устройствах. Дай мне топ-3 исправлений в порядке приоритета.»**
### Как исправить INP (порядок приоритетов)
```text
Приоритет 1: Отложите или задержите некритичные сторонние скрипты.
→ Загружайте чат-виджеты, аналитику и рекламные теги после того, как страница стала интерактивной.
→ Используйте <script defer> или загружайте их через 3-5 секунд после загрузки страницы.
Приоритет 2: Разбейте длинные задачи JavaScript.
→ Разделите код по маршрутам. Лениво загружайте компоненты ниже линии сгиба.
→ Перенесите тяжёлые вычисления в requestIdleCallback() или Web Worker.
Приоритет 3: Сделайте так, чтобы обработчики кликов немедленно обновляли UI.
→ Покажите состояние загрузки, спиннер или заблокированную кнопку в течение первых 50ms.
→ Выполняйте основную работу (API-запрос, обновление состояния) после визуального ответа.Исправление №3: Готовность к AI-краулерам (уровень 2026 года)
У Mobile-First индексации теперь есть AI-уровень. Когда AI Overviews от Google или сторонние AI-системы отвечают на вопрос, они извлекают данные из того же мобильно-индексированного контента. Если на ваших мобильных страницах отсутствуют сигналы, которые ищут AI-системы, вы теряете цитирования.
Что AI-системам нужно от ваших мобильных страниц
Сигнал | Почему это важно | Быстрая проверка |
|---|---|---|
Структурированные данные (JSON-LD) | Помогают AI-системам понимать сущности, продукты, статьи, FAQ | Просмотр кода → поиск |
Чёткая иерархия заголовков | AI-экстракторы используют H1-H4 для разбора структуры страницы | Проверьте страницу: каждый ли раздел имеет описательный заголовок? |
Лаконичные блоки ответов | AI Overviews предпочитают ответы из 2-4 предложений в начале страницы | Отвечает ли ваша страница на главный вопрос в первых 200 словах? |
Доступ robots.txt для AI-краулеров | Если заблокированы, AI-системы не могут получить ваш контент | Проверьте robots.txt на наличие |
Файл llms.txt | Помогает AI-системам эффективно находить ваш ключевой контент | Проверьте |
Быстрый промпт для проверки готовности к AI
«Проверь [URL] на готовность к AI-поиску. Сообщи: (1) присутствуют ли и валидны ли JSON-LD структурированные данные? (2) есть ли чёткий ответ на главный вопрос страницы в первых 200 словах? (3) разрешён ли доступ AI-краулерам в robots.txt? (4) существует ли llms.txt в корне? Дай PASS/FAIL по каждому пункту и скажи, что исправить в первую очередь.»
Полные промпты Mobile-First аудита для начинающих
Вот набор промптов, которые можно скопировать в Claude Code или Codex прямо сейчас. Каждый выполняет одну конкретную задачу — настройка не требуется, кроме открытого агента, направленного на ваш проект или 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
В: Можно ли по-прежнему использовать отдельный мобильный сайт (m.example.com)? Технически да, но Google рекомендует адаптивный дизайн. Отдельные мобильные URL добавляют сложности: необходимо поддерживать идентичный контент, канонические теги и hreflang для двух наборов URL. Если что-то рассинхронизируется, Google индексирует ту версию, которую сканировал последней. Адаптивный дизайн полностью исключает этот риск.
В: Что если мой сайт только для десктопа — мобильной версии нет вообще? Если Googlebot Smartphone не может получить доступ и отрендерить ваш контент, этот контент не будет проиндексирован. Точка. Десктопный сайт в 2026 году фактически невидим для Google. Если вы в такой ситуации, переход на адаптивную тему — ваша первоочередная задача.
В: Нужно ли беспокоиться о размерах планшетов? Googlebot сканирует как смартфон, а не как планшет. Сосредоточьтесь на viewport смартфона. Тем не менее, пользователи планшетов — реальные пользователи, поэтому убедитесь, что адаптивный дизайн не ломается на промежуточных ширинах (768-1024px).
В: Как узнать, прошёл ли мой сайт переход на Mobile-First? Откройте Google Search Console → Настройки → проверьте раздел «О программе» на наличие «Сканер индексации: Googlebot для смартфонов». Если там это указано, вы на Mobile-First индексации. К настоящему времени почти все сайты уже переведены.
В: Сканирует ли Google мой сайт десктопным user-agent для чего-либо ещё? Да. Google иногда сканирует десктопным user-agent для определённых проверок (верификация связей, повторная обработка некоторых структурированных данных). Не беспокойтесь, если видите десктопного Googlebot в своих логах. Эти визиты не означают, что ваш сайт на десктопной индексации.
Автор: Джулиан Мерсер, специалист по техническому SEO с 14-летним опытом в Auspia. Джулиан пишет о сканируемости, рендеринге, схеме, архитектуре сайта и технических основах, которые делают контент доступным для поисковых систем и AI-систем.
