Позиція — це не одне число. Запитайте той самий сайт, за тим самим запитом, за ті самі 90 днів, і мобільні та десктопні результати не збігатимуться. У наших власних даних Search Console розрив сягнув 11,4 позиції за одним запитом, і напрямок перевертався залежно від запиту: іноді краще було на мобільному, іноді на десктопі.
Це не збій у даних і не привід купувати трекер мобільних позицій. Це властивість того, як Google будує сторінку результатів, і вона залишається невидимою, поки ви читаєте змішане середнє.
Ця стаття про те, що насправді спричиняє розділення, як виглядали наші власні цифри та про короткий робочий процес у Claude Code, який розділяє одне й друге, щоб ви перестали ухвалювати десктопні рішення про мобільний трафік.
Хибне уявлення
Припущення, яке більшість команд носить із собою, зазвичай не проговорюючи його вголос, полягає в тому, що позиція — це властивість сторінки. Ви на 8 місці за запитом, отже ви на 8 місці. Трекери позицій підсилюють це припущення, бо за замовчуванням працюють з одним пристроєм і друкують одне число на ключове слово.
Практичний наслідок — звичка звітувати: хтось перевіряє десктопну позицію, записує її в таблицю, і все подальше ставиться до неї як до істини про видимість.
Корисніша реальність
Два факти, обидва задокументовані Google, ламають модель одного числа.
Факт перший: ранжується ваша мобільна сторінка. Документація Google Search Central каже це прямо: «Google використовує мобільну версію вмісту сайту, проскановану агентом для смартфонів, для індексації та ранжування». Ваш десктопний HTML не є основним входом, навіть коли людина, яка шукає, сидить за ноутбуком.
Факт другий: сторінка результатів будується під пристрій, який перед нею. Довідкова документація самої Search Console каже це без прикрас, і це варто прочитати двічі: «Результати пошуку залежать від часу, місця, пристрою та недавньої історії людини, яка виконує пошук».
Складіть одне з одним — і занотована позиція є вибіркою з розподілу, що зсувається разом із пристроєм. Число не хибне. Воно просто значно вужче, ніж те, як його використовують.
Чому міф поширюється так легко
Чотири звичайні речі тримають модель одного числа живою.
- Трекери за замовчуванням налаштовані на десктоп. Отримати десктопну SERP дешевше й простіше зберегти, тож вона стає стовпцем за замовчуванням. Перемикання пристрою є в багатьох тарифах, і це не те саме, що бути увімкненим за замовчуванням.
- Search Console змішує пристрої. Типовий звіт «Ефективність» усереднює мобільні, десктопні та планшетні дані. Щоб побачити розділення, потрібно відкрити вкладку «Пристрої» або викликати API з device як виміром. Ніщо в типовому поданні не попереджає, що відбувається змішування.
- Відстеження мобільних позицій продають як додаток. Коли постачальник перелічує «трекер мобільних позицій» як функцію, імплікація в тому, що стандартний звіт уже охоплює все. Він охоплює один зріз.
- Ефект невидимий на малих вибірках. Якщо подивитися на десять запитів і всі вони збігаються, проблема видається теоретичною. Вона стає видимою на рівні запиту — за запитами, що мають достатньо показів, аби їх усереднювати.
Що показали наші власні 90 днів
Ми витягли власний ресурс Search Console, 90 днів, що закінчуються 11 вересня 2026 року, з query і device як вимірами.
Пристрій | Покази | Кліки | CTR | Середня позиція |
|---|---|---|---|---|
Десктоп | 34 028 | 375 | 1,10% | 34,4 |
Мобільний | 7 147 | 69 | 0,97% | 30,8 |
Планшет | 156 | 0 | 0,00% | 40,8 |
Той самий ресурс, те саме вікно, три різні історії. Зверніть увагу, що середня позиція на мобільному краща, тоді як CTR на мобільному гірший.
У цій таблиці є дві речі, варті уваги.
Перша — це перевернутий сигнал. Середня позиція на мобільному була кращою за десктопну (30,8 проти 34,4), і все ж CTR на мобільному був гіршим (0,97% проти 1,10%). Краща позиція за гіршого показника кліків — це нормально для мобільного: сторінки результатів вищі, розмітка інша, а верх сторінки забитий функціями. Той, хто звітував би лише позицію, оголосив би мобільний сильнішою поверхнею й повністю пропустив би розрив у кліках.
Друга — це пастка читання середніх на рівні всього сайту. Ті два рядки узагальнюють різні суміші запитів. Десктоп несе 82% наших показів, бо наша аудиторія — це SEO-практики за робочими столами, а мобільний несе інший і менший набір запитів. Середні на рівні сайту це приховують. Саме зіставлення за запитом робить число таким, з яким можна працювати.
Тож ми зробили зіставлення. З 130 запитів із щонайменше 20 показами 85 мали дані за обома пристроями. Ось шість найбільших розходжень.
Запит | Позиція мобільний | Позиція десктоп | Різниця |
|---|---|---|---|
auditoria seo on page | 64,5 | 53,1 | 11,4 (краще десктоп) |
perplexity seo checking tool | 20,5 | 31,1 | 10,6 (краще мобільний) |
geo seo | 92,9 | 85,4 | 7,5 (краще десктоп) |
auspia | 5,4 | 1,6 | 3,8 (краще десктоп) |
perplexity referral traffic | 11,2 | 12,0 | 0,9 (краще десктоп) |
amazon echo keywords | 13,9 | 13,8 | 0,1 (нічия) |
Розрив іде в обидва боки. «Мобільний ранжується гірше» так само хибно, як «позиція — це позиція».
Напрямок перевертається. Саме цей висновок має змінити вашу робочу звичку: ви не можете виправити розходження між пристроями якимось практичним правилом, бо немає сталого напрямку, який можна було б виправляти. Його треба вимірювати за кожним запитом.
Що робити замість цього: розділити, зіставити, поріг, рішення
Чотири кроки, приблизно 20 хвилин, коли робочий процес уже існує.
Крок 1: витягніть query і device разом. У Search Console відкрийте «Ефективність», додайте вкладку «Пристрої» поряд із «Запити» та експортуйте за 90 днів. Через API запитайте виміри ["query","device"] із лімітом рядків, достатньо високим, щоб умістити ваш набір запитів. API приймає ліміт рядків значно вищий за потреби середнього сайту, тож просіть високо й обрізайте локально.
Якщо ви вже формуєте щотижневий звіт про позиції, це стає додатковим виміром до того, що у вас уже є, а не новою книгою. Контракт звіту в нашому робочому процесі щотижневого звіту про позиції має для цього місце.
Крок 2: зіставте за ключем запиту. Один рядок на запит, зі стовпцем мобільного та стовпцем десктопу. Рядки, що існують лише на одному пристрої, самі по собі є висновком: вони означають, що запит отримує покази на одній поверхні й не отримує на іншій.
Крок 3: застосуйте поріг перед тим, як дивитися. П'ять позицій — це робочий початковий поріг. Нижче ви читаєте шум. Вище — у вас запит, щодо якого дві поверхні справді не згодні.
Крок 4: вирішуйте за класом запиту, а не за запитом. Грошові запити виправляють першими. Порівняльні запити зазвичай розходяться тому, що розмітка SERP інша, а не тому, що ваша сторінка слабка. Брендові запити, що розходяться, майже ніколи не є проблемою SEO. Інформаційні запити можуть зачекати.
Робочий процес у Claude Code, який робить розділення
Повторювана частина механічна: витягти, зіставити, застосувати поріг, підсумувати. Це саме та форма завдання, яка належить агенту, а не вашому тижню.
Збережіть це як файл інструкцій, який Claude Code може прочитати, і націліть його на ресурс, яким ви володієте:
Витягни дані Search Console для ресурсу <property> за останні 90 днів.
Використай виміри: query, device. Залиш лише запити з щонайменше 20 показами.
Зістав мобільний проти десктопу за ключем запиту.
Для кожного запиту, наявного на обох пристроях, обчисли абсолютну різницю середньої позиції.
Виведи лише рядки, де різниця становить 5.0 або більше, відсортовані за загальними показами за спаданням.
Для кожного рядка покажи: запит, позиція мобільний, позиція десктоп, розрив, який пристрій кращий,
покази мобільний, покази десктоп.
Заверши двома підсумковими рядками:
1. Кількість запитів, де кращий мобільний, і кількість, де кращий десктоп.
2. Єдиний запит із найбільшим розривом та його загальні покази.
Не пропонуй виправлень. Не пиши рекомендацій щодо контенту.
Збережи вивід як mobile-desktop-gap-YYYY-MM-DD.md у робочій теці.У цій інструкції є три свідомі рішення, які варто зберегти, якщо ви її адаптуєте.
Вона задає нижню межу показів, бо запит із чотирма мобільними показами дає середню позицію, яка не означає нічого. Вона забороняє пропозиції виправлень, бо рішення залежить від класу запиту й бізнес-контексту, а агент, який тут вгадує, видає впевнену нісенітницю. І вона зберігає у файл із датою, щоб ви могли порівняти розділення наступного місяця з цим місяцем — це єдиний спосіб побачити, чи виправлення спрацювало.
Підказка нейтральна за формою щодо агента. Codex виконує ту саму інструкцію через власні домовленості щодо файлів, і крок перевірки ідентичний.
Запобіжники
- Нижче приблизно 20 показів — зупиніться. Середні позиції за жменею показів самі собою стрибають на дві цифри. Поріг у підказці існує саме тому.
- Планшет — це не мобільний. Наш рядок планшета мав 156 показів і нуль кліків. Об'єднання планшета з мобільним погіршило б мобільні цифри з причин, які не мають нічого спільного з мобільним пошуком.
- Ця стаття про вимірювання, а не про відповідність. Чи взагалі Google бачить ваш мобільний вміст — це інша проблема з іншими перевірками. Аудиторський бік ми розібрали в Mobile-first індексації у 2026 році.
- Краща позиція може бути гіршим результатом. У наших власних даних мобільний ранжувався краще й клікався гірше. Позицію й показник кліків треба читати разом.
- Не ганяйтеся за кожним розривом. Розрив у 6 позицій за запитом із 30 пошуками на місяць — це не проєкт. Відсортуйте список за показами й залиште хвіст спокій.
- Глибокі позиції поводяться інакше. Якщо запит лежить за межами 100 позиції на обох пристроях, спершу виправте проблему глибини. Ми виміряли, як далеко насправді сягають результати Google, у нашому тесті глибини перевірки позицій.
Погляд Auspia: розходження між пристроями — це проблема вимірювання раніше, ніж проблема ранжування. Більшість команд ніколи не дивилися, бо типовий звіт приховує розділення. Щойно розділення стає видимим, більшість розривів виявляються пояснюваними, а цікава жменя варта виправлення.
Часті запитання
Чи Google ранжує мобільні та десктопні сторінки окремо? Практично так. Google індексує мобільну версію вашого вмісту, і сторінка результатів, що подається на телефон, відрізняється від тієї, що подається на ноутбук. Обидві позиції походять із тих самих базових систем, але це не те саме число.
Чому мій трекер позицій розходиться з Search Console? Бо вони вимірюють різні речі. Трекер отримує живу SERP в одній локації й на одному пристрої. Search Console усереднює покази за всіма пристроями, країнами та всім діапазоном дат. Обидва можуть бути праві й при цьому не збігатися.
Що таке трекер мобільних позицій і чи потрібен він мені? Трекер мобільних позицій отримує SERP для смартфонів за набором ключових слів. Він вартий грошей, якщо вам потрібні позиції конкурентів або локації, яких ви не бачите у власних даних. Якщо вам потрібна лише мобільна видимість власного сайту, Search Console уже це має, розбито за пристроями й безкоштовно.
Скільки показів потрібно, щоб позиція за пристроєм стала надійною? Приблизно 20 — це практична нижня межа для грубого читання; від 100 число перестає рухатися від тижня до тижня. Нижче 20 тримайте запит у списку, але не дійте за ним.
Чи Claude Code може читати Search Console напряму? Так, через Search Console API з сервісним акаунтом або обліковими даними OAuth. Наведений вище процес припускає, що це з'єднання існує. Наш посібник з SEO-агента розбирає, які завдання з ранжування варто передавати агенту, а які ні.
Чи варто виправляти мобільну сторінку, якщо мобільний ранжується гірше? Спершу подивіться на SERP. Якщо мобільна сторінка результатів несе більше відео, більше локальних пакетів або іншу суміш типів сторінок, виправлення стосується формату контенту, а не якості сторінки. Якщо форма SERP збігається й сторінка гаразд, ставтеся до цього як до проблеми паритету контенту й перевіряйте за mobile-first перевірками.
Автор: Маркус Еллері, growth-експериментатор, за яким стоять понад 150 SEO-тестів в Auspia. Він пише про бенчмарк-дані, контрольовані тести та різницю між метрикою, що рухається, і метрикою, що щось означає.
