Шаблон перевірки мобільного SEO та зручності сторінок

Аркуш перевірки зручності мобільного SEO (для заповнення)

Коли використовувати: Один аркуш на шаблон сторінки: viewport, відповідність контенту, навігація, взаємодія та шлях до конверсії, з критичністю, відповідальним, статусом і підсумковою перевіркою.

Аркуш перевірки зручності мобільного SEO

Один аркуш на шаблон сторінки, перевірка на екрані розміру телефона. Заповніть шапку, пройдіть кожен рядок, а потім призначте відповідального за кожну відкриту знахідку.

• Сайт і шаблон: [домен, наприклад сторінка товару] · Приклад URL: [URL]
• Пристрої для тесту: [модель реального телефона + ширина в режимі пристрою DevTools, наприклад 360px]
• Хто перевіряє: [ім'я] · Дата: [дата] · Відповідальний за перевірку: [ім'я, команда]

Дії

• Дія 1: [виправлення] · Відповідальний: [ім'я] · Термін: [дата]
• Дія 2: [виправлення] · Відповідальний: [ім'я] · Термін: [дата]
• Повторна перевірка: [дата], інструмент і пристрій: [інструмент + пристрій]

Підсумкова перевірка: у кожному рядку є знахідка (або «немає»), кожна проблема високої та середньої критичності має відповідального і термін, виправлення повторно перевірено на реальному телефоні, а знімок екрана з живого тесту в «Перевірці URL-адреси» (URL Inspection) має правильний вигляд.

Viewport та адаптивна верстка

Коли використовувати: Переконайтеся, що кожен шаблон вміщується в екран телефона, дозволяє масштабування і Google може його відрендерити, перш ніж перевіряти щось глибше.

Viewport і адаптивна верстка

Почніть звідси. Якщо сторінка не вміщується в екран, решта аркуша вже не має значення. Google радить один адаптивний сайт, який віддає той самий HTML за тією самою адресою на всі пристрої.

Перевірте [URL сторінки] на ширині [360px і найпопулярніших ширинах ваших пристроїв]:

• Метатег viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> є в HTML, який віддає сервер.
• Масштабування дозволене: немає user-scalable=no. Перевірки доступності в Lighthouse позначають його як помилку, бо він заважає людям, яким потрібно збільшити сторінку.
• Немає прокрутки вбік: контент перебудовується в одну колонку. Широкі таблиці, зображення та вбудовані блоки не виходять за межі екрана.
• Ресурси доступні для сканування: CSS, JavaScript і зображення не заблоковані в robots.txt, тож Google може відрендерити сторінку так, як це робить телефон.

Як перевірити: спочатку режим пристрою в Chrome DevTools, щоб швидко пройтися різними ширинами, потім реальний телефон. У документації DevTools Google називає режим пристрою лише приблизним наближенням, тож він не замінить справжній пристрій.

Переконайтеся, що тег viewport є у сирій відповіді сервера, за допомогою Get Source Code of Webpage. Перемкніть інструмент на мобільний user agent.

Результат: кожен дефект верстки з пристроєм, шириною, знімком екрана та виправленням.

Відповідність контенту (mobile-first індексування)

Коли використовувати: Переконайтеся, що мобільна версія містить той самий контент, структуровані дані, метадані, alt-тексти зображень і посилання, що й десктопна.

Відповідність контенту в умовах mobile-first індексування

Перехід на mobile-first індексування завершено: Google оголосив про це в жовтні 2023 року. Для індексування та ранжування Google переважно використовує мобільну версію сторінки. Якщо щось є лише на десктопі, вважайте, що Google може цього не побачити.

Порівняйте мобільну та десктопну версії для [URL сторінки]:

• Основний контент і заголовки: однакові в обох версіях. Вкладки та акордеони підходять, якщо текст є в HTML.
• Відкладене завантаження: основний контент не вимагає натискання, свайпу чи введення тексту, щоб завантажитися. Google таких дій не виконує.
• Структуровані дані: однакова розмітка в обох версіях. Якщо мобільна версія живе на окремих URL, у розмітці мають бути мобільні URL.
• Метадані: рівнозначні title і meta description. Той самий метатег robots, щоб мобільна версія випадково не опинилася з noindex.
• Зображення: ті самі alt-тексти, підписи та назви файлів. URL зображень не змінюються, а самі зображення не крихітні й не низької роздільної здатності.
• Внутрішні посилання: мобільне меню і посилання в тексті ведуть на ті самі ключові сторінки, що й на десктопі.

Як перевірити: запустіть живий тест в інструменті «Перевірка URL-адреси» (URL Inspection) у Search Console і відкрийте знімок екрана перевіреної сторінки. Саме так її рендерить тестовий інструмент Google.

Потім двічі отримайте код сторінки через Get Source Code of Webpage (спочатку з десктопним, потім з мобільним user agent) і порівняйте title, метатеги та структуровані дані. Інструмент показує HTML до виконання JavaScript.

Результат: список усього, що є на десктопі, але відсутнє або відрізняється в мобільній версії.

Перевірка навігації та взаємодії

Коли використовувати: Знайдіть меню, елементи для натискання, нечитабельний текст і повільну реакцію, через які сторінкою незручно користуватися одним пальцем.

Навігація та взаємодія

Сторінка може вміщуватися в екран і все одно бути незручною, коли користуєшся нею одним пальцем. Пройдіть її як відвідувач із телефоном, а не як аудитор за ноутбуком.

Навігація

• Меню відкривається, закривається і не замикає користувача всередині.
• [5] головних сторінок, які приносять гроші, доступні з мобільного меню за два натискання або менше.
• Пункти меню - це справжні посилання <a href>, тож Google може за ними переходити.
• Пошук, кнопка «Нагору» і хлібні крихти працюють на малих екранах.

Взаємодія

• Елементи для натискання: WCAG 2.2 встановлює мінімум 24 x 24 CSS px або достатній відступ. Lighthouse перевіряє це в аудиті доступності target-size.
• Розмір тексту: основний текст читається без масштабування. Оцінюйте на око: у Lighthouse 13 аудит розміру шрифту прибрали.
• Реакція: фільтри, меню та кнопки швидко відгукуються на натискання. Повільна реакція проявляється як поганий INP у звіті Core Web Vitals.
• Зсуви макета: під час завантаження нічого не стрибає під пальцем.

Результат: кожне незручне місце зі знімком екрана, переліком шаблонів, яких воно стосується, і виправленням.

Перевірка шляху до конверсії на мобільних

Коли використовувати: Пройдіть основний шлях від посадкової сторінки до підтвердження на телефоні й позначте кожну перешкоду.

Перевірка шляху до конверсії

Трафік із мобільного пошуку корисний лише тоді, коли люди можуть довести справу до кінця з телефона. Перевірте основний шлях від посадкової сторінки до підтвердження.

Шлях: [посадкова сторінка] → [кнопка дії] → [форма або оформлення замовлення] → [підтвердження]

1. Кнопку дії видно: головна дія є на першому екрані або до неї легко дістатися. Липка панель не закриває контент чи інші кнопки.
2. Форми: підписи полів не зникають, поля мають правильний тип (email, tel, number), автозаповнення працює.
3. Помилки: повідомлення з'являються біля поля, а введене користувачем не стирається.
4. Контакти: номери телефонів - це посилання, на які можна натиснути (tel:), а адреси відкриваються в картах.
5. Оплата та вхід: жоден крок не змушує збільшувати сторінку пальцями чи переходити на сторінку лише для десктопа.
6. Підтвердження: сторінка подяки завантажується, а подія в аналітиці спрацьовує на мобільних.

Відповідальний за цей шлях: [ім'я] · Повторно перевіряйте після кожної зміни в [компоненті форми, оформлення замовлення або кнопки дії].

Результат: шлях у вигляді знімків екрана, кожна перешкода позначена, з відповідальним і терміном.

Міжсторінкові оголошення, діалоги та реклама

Коли використовувати: Складіть перелік спливаючих вікон, банерів і реклами та звірте їх з актуальними рекомендаціями Google щодо міжсторінкових оголошень.

Міжсторінкові оголошення, діалоги та реклама

Позиція Google: нав'язливі міжсторінкові оголошення та діалогові вікна дратують користувачів і заважають Google зрозуміти ваш контент, а це може погіршити видимість у пошуку.

Складіть перелік усіх оверлеїв на [URL сторінки]: що їх викликає і яку частину екрана вони закривають. Потім звірте кожен із правилами Google:

• Банери замість повноекранних оверлеїв: банер, що займає невелику частину екрана, дає користувачам і Google дістатися до контенту.
• Не закривайте всю сторінку міжсторінковим оголошенням, якщо цього не вимагає закон.
• Не перенаправляйте користувачів на окрему сторінку, щоб отримати згоду чи дані.
• Обов'язкові бар'єри (наприклад, перевірка віку) - виняток, але показуйте їх поверх контенту, а не перенаправляйте на окрему сторінку.
• Реклама: дотримуйтеся стандарту Better Ads (Better Ads Standard). Реклама вгорі екрана телефона не повинна витісняти контент з поля зору.

Для підписки зазвичай вистачає форми в тексті сторінки або вузького банера, який можна закрити, і сторінка при цьому не блокується.

Результат: перелік оверлеїв із тригером, часткою екрана, рішенням (залишити чи замінити) і відповідальним.

Зручність сторінок та актуальні інструменти перевірки

Коли використовувати: Замініть вимкнену «Перевірку оптимізації для мобільних» інструментами, які Google підтримує зараз, і задайте періодичність моніторингу.

Перевірка зручності сторінок та актуальні інструменти

1 грудня 2023 року Google вимкнув «Перевірку оптимізації для мобільних» (Mobile-Friendly Test), її API і звіт «Зручність для мобільних» (Mobile Usability) у Search Console. Зручність мобільної версії досі важлива: замість цих інструментів Google порадив, зокрема, Lighthouse.

Не перебільшуйте очікувань. Google каже, що єдиного сигналу зручності сторінки (page experience) немає. Core Web Vitals використовуються його системами ранжування, але хороші показники не гарантують топових позицій.

Для швидкого сканування багатьох сторінок безкоштовний аудит сайту перевіряє відсутній мобільний viewport, alt-тексти зображень, title, структуровані дані та HTTPS.

Результат: план моніторингу: інструмент, відповідальний, періодичність ([щомісяця / після кожного релізу]) і подія, що запускає нову перевірку.

Заповнений приклад (вигаданий магазин туристичного спорядження)

Коли використовувати: Заповнений аркуш перевірки для вигаданого магазину туристичного спорядження, у якого на сторінках категорій були проблеми зі зручністю мобільної версії та відповідністю контенту.

Заповнений приклад: сторінки категорії наметів Ridgeline Supply

Лише приклад. Компанія, люди, URL і цифри вигадані, щоб показати, як виглядає зручна заповнена версія.

• Шаблон: сторінка категорії, приклад URL ridgeline-supply.example/tents
• Пристрої: Android-телефон середнього класу + режим пристрою DevTools на 360px
• Хто перевіряє: Maya (SEO) · Відповідальний за перевірку: Daniel (продукт) · Дата: 3 листопада

Підсумкова перевірка: 5 із 7 рядків виправлено (2 підтверджено, 3 чекають повторної перевірки на реальному телефоні). Виправлення навігації та зручності сторінки потрібно зробити до 14 листопада, повторну перевірку живим тестом у «Перевірці URL-адреси» (URL Inspection) заплановано.

Чому це спрацювало

Команда перевіряла один шаблон, а не 400 URL, тож кожне виправлення охопило всі сторінки категорій наметів. У кожного рядка був конкретний відповідальний. А рядок про відповідність контенту виявив розмітку й текст, яких мобільний краулер Google ніколи не бачив.

Наступний крок

Запустіть безкоштовний аудит сайту, щоб знайти відсутні теги viewport і alt-тексти по всьому сайту. Потім порівняйте десктопний і мобільний код сторінки за допомогою Get Source Code of Webpage і перегляньте, як виглядатиме ваш сніпет у мобільній видачі, у SERP Simulator.

Хочете, щоб хтось подивився свіжим поглядом? Запишіться на безкоштовну консультацію з Anatolii Ulitovskyi.