SEO-експерименти: як перевіряти зміни на даних
SEO-експеримент — це порівняння результатів групи сторінок, де ви змінили щось одне, з групою, де не змінювали нічого. Таке порівняння знижує вплив сезонності, оновлень Google і дій конкурентів, але не доводить причинність остаточно: пошук не детермінований, а Google не публікує методик тестів і строків. Тому нижче — що задокументовано (як не зашкодити сайту під час тестування, як Google радить перевіряти ефект розмітки), а що — практика, яку треба застосовувати обережно: розмір груп, контроль, строк, розрахунок ефекту.
Що каже документація Google
Прямого посібника з SEO-експериментів у Google немає. Є два джерела, які варто знати.
- Перевірка ефекту «до й після». У посібнику зі структурованих даних пропонується провести тест «до й після» на кількох сторінках: обрати сторінки з кількома місяцями даних у Search Console, не сезонні й стабільні, додати розмітку, переконатися, що вона валідна й знайдена (перевірка URL), і кілька місяців записувати результати у звіті про ефективність, фільтруючи за адресою.
- Як не зашкодити під час A/B-тестування. Довідка «Мінімізуйте вплив A/B-тестів на Пошук» говорить не про методику, а про обережність. Вона стосується тестів, у яких ви показуєте користувачам різні варіанти сторінки; SEO-спліт-тест, де зміни вносяться до групи сторінок, влаштований інакше, але правила обережності ті самі.
Правила обережності з довідки
- Не використовуйте клоакінг. Не можна показувати Googlebot одні адреси, а людям інші: це порушення політик проти спаму незалежно від того, чи робиться це логікою сервера, файлом robots.txt чи інакше (політики проти спаму). Googlebot, як правило, не підтримує cookie, тому, якщо варіант обирається за cookie, він побачить версію для браузерів без cookie.
- Використовуйте
rel="canonical"на альтернативних адресах із вказівкою на вихідну: довідка радить його, а неnoindex, бо він точніше виражає намір (тег canonical). - Використовуйте 302, а не 301, для перенаправлення на варіанти: тимчасове перенаправлення лишає в індексі вихідну адресу (редиректи).
- Дрібні зміни (розмір, колір, місце кнопки чи зображення, текст заклику) часто мало впливають на сніпет і ранжування. Якщо Google обходить сайт достатньо часто, щоб помітити експеримент, то й підсумкові зміни він, імовірно, швидко проіндексує.
Як побудувати експеримент (практика)
| Етап | Що робити | Що врахувати |
|---|---|---|
| 1. Гіпотеза | «Якщо змінити X на цих сторінках, то показник Y зросте»; метрика заздалегідь: кліки, CTR, покази, позиція | позиція — складна метрика, її треба читати обережно |
| 2. Групи | тестова й контрольна групи схожих сторінок (шаблон, тематика, рівень трафіку) | сторінок потрібно достатньо, щоб шум окремих сторінок згладився |
| 3. Ізоляція | змінюйте одну змінну, у контролі — нічого | не змінюйте інше на цих сторінках (посилання, контент) у період тесту |
| 4. Строк | період «до» такої самої довжини, як «після»; врахуйте, що спершу сторінки треба переобійти | обхід може тривати від кількох днів до кількох тижнів |
| 5. Аналіз | порівняйте зміну в тестовій групі зі зміною в контрольній | перевірте сезонність та оновлення Google в цей період |
Як рахувати ефект
Найпростіший розрахунок — порівняти зміни, а не рівні: ефект = (тест після ÷ тест до) ÷ (контроль після ÷ контроль до) − 1. Приклад із вигаданими числами: у тестовій групі кліки зросли з 10 000 до 11 800 (+18%), у контрольній — з 10 000 до 10 200 (+2%); відносний ефект становитиме 1,18 ÷ 1,02 − 1 ≈ +15,7%. Це навчальний приклад, а не результат реального тесту. Далі дивіться, наскільки стабільний ефект: чи зростає він на більшості сторінок групи, чи пояснюється кількома, чи не було зсувів у контролі й чи спричинений зріст самою зміною, а не новим запитом чи посиланням на одну зі сторінок.
Що задокументовано про дані: позиція у звіті — складна метрика, і її краще відстежувати в часі, а дрібні коливання позиції трапляються будь-коли й самі по собі не привід щось змінювати (Search Console для аналітика). Причини просідань, які варто виключити: оновлення алгоритму, проблема з безпекою чи спамом на всьому сайті, сезонність і зміна інтересів, технічна проблема, збій звіту (налагодження падіння трафіку; урок про падіння трафіку).
Інструменти платформи
- Wins & Losses порівнює два періоди Search Console і допомагає знайти сторінки, що зросли й впали; у ньому є пресети дат оновлень Google.
- Google Updates накладає історію core-оновлень на трафік, щоб відокремити вплив алгоритму від власних правок (основні оновлення).
- Інші джерела й сервіси — в уроці про просунуті інструменти.
Що лишається практикою, а не фактом
- «Мінімум 4 тижні». Google такого строку не називає; на практиці це нижня межа, бо сторінкам потрібен час на повторний обхід і накопичення даних. Для рідкісних запитів потрібно більше.
- «Єдиний спосіб довести причинність». Контрольна група зменшує вплив зовнішніх чинників, але не виключає їх: наприклад, оновлення може по-різному зачепити різні типи сторінок.
- Пороги значущості та розміри груп. У документації не задано; добирайте за розкидом даних ваших сторінок.
Чек-лист
- Гіпотезу й метрику записано до початку тесту.
- Тестова й контрольна групи схожі; сторінок достатньо.
- Змінюється одне; контроль не чіпається; паралельних правок на цих сторінках не вносять.
- Немає клоакінгу; для варіантів з окремими адресами — canonical на вихідну й 302.
- Період «до» й період «після» однакової довжини, враховано затримку на обхід.
- Перевірено сезонність та оновлення Google; результат зіставлено з контролем.
- Рішення й результат записано: що змінювали, де, коли, що побачили.
Помилки
- Упроваджувати зміну за розповіддю з блогу без перевірки на своїх сторінках.
- Порівнювати «до» і «після» без контрольної групи й робити висновок про причину.
- Змінювати кілька речей одразу й приписувати ефект одній із них.
- Показувати роботу й людям різні версії.
- Завершувати тест, не дочекавшись повторного обходу й накопичення даних.
Що далі
Далі — просунуті інструменти: які джерела даних і сервіси допомагають збирати й порівнювати дані експериментів і на що дивитися під час їх вибору.