Індексація Mobile-First у 2026: Що насправді означає «тільки мобільна версія»

Коротка відповідь

Mobile-first індексація завершена. З липня 2024 року Google використовує тільки мобільну версію вашого сайту для індексації та ранжування. Якщо контент, структуровані дані або внутрішні посилання присутні на десктопі, але відсутні на мобільній версії, Google їх не бачить. У 2026 році з'явилися три нові наслідки, які більшість власників сайтів ще не врахували: INP замінив FID як Core Web Vital, AI Overviews використовують контент з мобільної версії, а березневе Core Update 2026 підвищило вагу ранжування мобільного досвіду сторінки.

Нижче ви знайдете повний робочий процес аудиту — і готовий до копіювання Codex skill, який виконує більшість перевірок за вас.

Що насправді означає «тільки мобільна версія» у 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 року. Коли системи штучного інтелекту Google генерують відповіді, вони використовують той самий проіндексований мобільний контент, що й звичайний пошук. Сторонні AI-сканери (GPTBot, ClaudeBot, PerplexityBot) також отримують доступ до ваших мобільних сторінок.

Якщо у вашій мобільній версії відсутні структуровані дані, чіткі заголовки або критичний текст, системи ШІ не можуть вас цитувати — навіть якщо десктопна версія має цей контент.

Зміна 3: Прогалини в паритеті контенту тепер мають вимірний вплив на ранжування

У 2026 році сайти з невідповідністю мобільного та десктопного контенту показують у середньому на 31,2% нижчу видимість в органічному пошуку порівняно з сайтами з повним паритетом контенту. Найпоширеніші відсутні елементи на мобільних пристроях: прихований контент у вкладках, посилання бічної панелі, розмітка структурованих даних, альтернативний текст зображень та внутрішні навігаційні посилання.

Як перевірити, чи ваш сайт проходить (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: Швидка перевірка мобільного вигляду в Chrome DevTools

Відкрийте Chrome DevTools (F12 або Cmd+Option+I), натисніть значок панелі пристроїв (Ctrl+Shift+M) і виберіть пресет мобільного пристрою, наприклад «Pixel 7». Перезавантажте сторінку. Перевірте наявність:

• Тексту, що потребує горизонтального прокручування
• Кнопок або посилань, занадто малих для натискання (менше 48×48 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: Запустіть аудит

Запитайте свого агента, використовуючи наступний текст, і вставте URL, який потрібно перевірити. Агент створить звіт із PASS/WARN/FAIL для кожної з 11 перевірок, а також пріоритетну чергу виправлень.

```text
Run the mobile-first audit skill on [YOUR URL HERE]

Якщо ви хочете перевірити кілька сторінок одночасно, надайте список:

Run the mobile-first audit on these 5 URLs: [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, введіть свою URL-адресу, прокрутіть до «Дізнайтеся, що відчувають ваші реальні користувачі». Значення INP у розділі «Мобільні» — це те, що використовує Google.
2. У Chrome DevTools відкрийте панель Performance, натисніть запис, взаємодійте зі сторінкою (натискайте кнопки, відкривайте меню, вводьте текст у поля), потім зупиніть запис. Шукайте довгі завдання (позначені червоним, 200 мс+). Це ваші проблеми з INP.
3. Ви також можете запитати свого 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 негайно.
  → Показуйте стан завантаження, спінер або вимкнену кнопку протягом перших 50 мс.
  → Виконуйте основну роботу (API-запит, оновлення стану) після візуальної відповіді.

Виправлення №3: Готовність до AI-сканерів (рівень 2026 року)

Mobile-first індексація тепер має рівень штучного інтелекту. Коли AI Overviews від Google або сторонні системи ШІ відповідають на запитання, вони використовують той самий проіндексований мобільний контент. Якщо вашим мобільним сторінкам не вистачає сигналів, які шукають системи ШІ, ви втрачаєте цитування.

Що потрібно системам ШІ від ваших мобільних сторінок

Швидкий запит для перевірки готовності до ШІ для вашого агента

"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."

Повні запити для mobile-first аудиту для початківців

Ось набір запитів, які ви можете скопіювати в Claude Code або Codex прямо зараз. Кожен запит виконує одне конкретне завдання — налаштування не потрібне, крім відкритого агента, спрямованого на ваш проєкт або URL-адресу.

Запит 1: Мобільний аудит однієї сторінки

Run a mobile-first indexing audit on [ВАША URL-АДРЕСА].

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. [URL ГОЛОВНОЇ СТОРІНКИ]
2. [URL СТОРІНКИ ПРОДУКТУ АБО ПОСЛУГИ]
3. [URL ДОПИСУ В БЛОЗІ АБО СТАТТІ]
4. [URL СТОРІНКИ КАТЕГОРІЇ АБО КОЛЕКЦІЇ]
5. [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).

Поширені запитання

П: Чи можу я все ще використовувати окремий мобільний сайт (m.example.com)? Технічно так, але Google рекомендує адаптивний дизайн. Окремі мобільні URL-адреси додають складності: ви повинні підтримувати ідентичний контент, канонічні теги та hreflang для двох наборів URL-адрес. Якщо щось виходить із синхронізації, Google індексує ту версію, яку він востаннє сканував. Адаптивний дизайн повністю усуває цей ризик.

П: Що робити, якщо мій сайт тільки для десктопу — без мобільної версії взагалі? Якщо Googlebot для смартфонів не може отримати доступ і відрендерити ваш контент, цей контент не буде проіндексований. Крапка. Сайт тільки для десктопу в 2026 році фактично невидимий для Google. Якщо ви в такій ситуації, перехід на адаптивну тему — ваше найпріоритетніше завдання.

П: Чи потрібно турбуватися про розміри планшетів? Googlebot сканує як смартфон, а не як планшет. Зосередьтеся на вигляді для смартфона. Водночас користувачі планшетів — реальні користувачі, тому переконайтеся, що ваш адаптивний дизайн не ламається на проміжних ширинах (768-1024px).

П: Як дізнатися, чи мій сайт уже пройшов перехід на mobile-first? Відкрийте Google Search Console → Налаштування → перевірте розділ «Про сервіс» на наявність «Сканер індексації: Googlebot для смартфонів». Якщо це зазначено, ви на mobile-first індексації. Зараз майже кожен сайт на ній.

П: Чи Google все ще сканує мій сайт з десктопним user-agent для чогось? Так. Google іноді сканує з десктопним user-agent для певних перевірок (верифікація зв'язків, повторна обробка деяких структурованих даних). Не хвилюйтеся, якщо бачите десктопного Googlebot у своїх логах. Ці візити не означають, що ваш сайт на десктопній індексації.

П: Чи покращить виправлення проблем mobile-first мою видимість в AI Overviews? Виправлення mobile-first індексації покращують фундамент. Якщо ваш мобільний контент, структуровані дані та швидкість сторінки надійні, ваш контент може бути процитований — але системи ШІ Google все одно вибирають, що цитувати, на основі релевантності, авторитетності та якості відповіді. Виправлення проблем mobile-first усуває перешкоду, але не гарантує включення в AI.

Автор: Джуліан Мерсер, 14-річний фахівець з технічного SEO в Auspia. Джуліан пише про сканованість, рендеринг, схеми, архітектуру сайтів та технічні основи, які роблять контент видимим для пошукових систем та систем штучного інтелекту.