SEO-перевірка після оновлення сайту: регресійні тести

Регресійне SEO-тестування — це SEO-перевірка після оновлення сайту: ви переконуєтеся, що реліз не зламав нічого, на що покладаються пошукові системи, — індексацію, коди відповіді, редиректи, canonical, внутрішні посилання, відрендерений контент, мікророзмітку та швидкість. Перед релізом ви фіксуєте базовий стан (baseline), запускаєте ті самі перевірки на staging, а потім ще раз у продакшені й виправляєте всі розбіжності, поки Google не переобійшов змінені сторінки.

Більшість падінь трафіку після релізів не мають жодного стосунку до алгоритмів. Хтось викотив noindex зі staging, оновлення теми прибрало теги canonical, або нова структура URL запрацювала без редиректів. У цьому посібнику — план тестування, який можна повторювати на кожному релізі, незалежно від того, чи ви розробник із CI-пайплайном, чи власник бізнесу, який щойно погодив редизайн.

Що таке регресійне SEO-тестування?

Регресійне SEO-тестування — це контроль якості (QA) для видимості в пошуку. Воно перевіряє, що ненавмисні зміни (у шаблонах, конфігурації сервера, плагінах чи JavaScript) не прибрали й не змінили сигнали, завдяки яким ваші сторінки вже ранжуються. Воно не вимірює, чи покращилися позиції. Воно лише підтверджує, що те, що працювало, не перестало працювати.

Слово «регресія» прийшло з тестування ПЗ: так називають те, що вчора працювало, а сьогодні — ні. В SEO регресії важко помітити, бо для відвідувачів сайт виглядає нормально. Сторінка з <meta name="robots" content="noindex"> відображається точнісінько так само, як індексована. Search Console може показати шкоду лише за кілька днів або тижнів, бо Google спершу має повторно просканувати змінені URL.

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

Які оновлення сайту потребують регресійного SEO-тесту?

Повний тест потрібен для будь-якої зміни, що зачіпає шаблони, URL, конфігурацію сервера чи спосіб рендерингу сторінок. Для дрібніших правок контенту зазвичай достатньо вибіркової перевірки. На практиці найризикованіші релізи — ті, які описують як «просто оновили дизайн», бо від них ніхто не чекає змін в SEO.

Зміни, що потребують повного тесту:

• Редизайн і зміна теми. Шаблони керують title, заголовками, canonical, мікророзміткою та внутрішніми посиланнями одразу на тисячах сторінок.
• Оновлення CMS, фреймворку чи плагінів. Одне оновлення SEO-плагіна може змінити генерацію карти сайту, canonical чи метатегів robots.
• Зміна структури URL і міграції. Нові slug, шляхи категорій, перехід з HTTP на HTTPS, зміна домену або додавання мовних папок.
• Перехід на клієнтський рендеринг. Перехід на JavaScript-фреймворк чи додавання оболонки single-page app змінює те, що Googlebot бачить у початковому HTML.
• Зміна сервера, CDN і хостингу. Це може вплинути на редиректи, заголовки (зокрема X-Robots-Tag), кешування та час відповіді.
• Масові операції з контентом. Наприклад, імпорт, обʼєднання сторінок, видалення категорій і нові фільтри.

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

SEO чекліст перед релізом: що має перевіряти регресійний тест?

Перевіряйте сигнали, які визначають, чи можна сторінку просканувати, проіндексувати й зрозуміти: коди відповіді, директиви robots, canonical, редиректи, title і заголовки, відрендерений основний контент, внутрішні посилання, мікророзмітку, hreflang і продуктивність. Порівнюйте кожен сигнал із базовим станом до релізу, а не з ідеалом. Питання в тому, що змінилося.

Що означає кожен сигнал, читайте в посібниках про тег canonical і robots.txt.

Чому noindex і robots.txt потребують особливої уваги

Саме вони спричиняють найгірші регресії, бо діють на весь сайт. У документації Google зазначено, що правило noindex можна передати або метатегом, або HTTP-заголовком X-Robots-Tag. Noindex на рівні заголовка, доданий конфігурацією сервера чи CDN, не помітиш, якщо дивитися лише на код сторінки, тож тест має читати й заголовки відповіді.

Помилки в robots.txt ще й довго «розсмоктуються». Google пише, що зазвичай кешує robots.txt до 24 годин, тож навіть після виправлення випадкового Disallow: / Googlebot ще до доби може дотримуватися старих правил.

Як провести регресійне SEO-тестування крок за кроком?

Зробіть базове сканування продакшену, просканируйте staging з тими самими налаштуваннями, порівняйте результати, виправте розбіжності, а одразу після релізу знову просканіюйте продакшен. Наступні два–чотири тижні стежте за Search Console. Увесь процес тримається на списку URL і базовому стані, з яким є що порівнювати.

1. Зафіксуйте базовий стан до будь-яких змін

Просканіюйте робочий сайт і збережіть результати: код відповіді, індексованість, canonical, title, H1, кількість слів, вхідні посилання й мікророзмітку для кожного URL. Додайте найцінніші URL із Search Console (топ сторінок за кліками) та XML-карту сайту, щоб охопити й сторінки-сироти. Також збережіть копію robots.txt і результати Lighthouse для основних шаблонів: головної, категорії, товару чи послуги, статті.

2. Тестуйте на staging з налаштуваннями, як у продакшені

Staging-сайти зазвичай навмисно закриті від краулерів, тож важко відрізнити заплановане блокування від справжніх багів. Пропустіть власний краулер (за IP або з автентифікацією) і памʼятайте, які правила існують лише на staging, щоб переконатися, що жодне з них не потрапить у реліз. Просканіюйте staging з тією ж конфігурацією, що й baseline, і порівняйте URL за URL.

3. Перевіряйте всю мапу редиректів, а не вибірку

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

# old_urls.txt: one old URL per line
while read url; do
  curl -s -o /dev/null -w "%{http_code} %{redirect_url} $url\n" "$url"
done < old_urls.txt | grep -v "^301"

Усе, що він виведе, треба переглянути: 404, 302 або редиректи, які ведуть не туди, куди заплановано в мапі.

4. Порівняйте сирий і відрендерений HTML

Якщо реліз змінює JavaScript, перевірте, що насправді бачить Google. Google рендерить сторінки за допомогою headless Chromium і радить дивитися відрендерений HTML в інструменті перевірки URL або в Rich Results Test, бо контент, якого немає у відрендереному HTML, не може бути проіндексований. Також перевірте, щоб title, canonical і основний текст були в початковому HTML скрізь, де це можливо. Інші краулери, зокрема багато ШІ-краулерів, можуть узагалі не виконувати JavaScript.

5. Перевірте продакшен одразу після релізу

Staging і продакшен відрізняються змінними оточення, правилами CDN і кешуванням. Протягом години після запуску повторно просканіюйте ключові URL, завантажте robots.txt і карту сайту, перевірте кілька шаблонів у Search Console. Потім знову порівняйте з baseline. Усе, що ви знайдете зараз, обійдеться значно дешевше, ніж те, що Google знайде наступного тижня.

Якщо у вас немає базового сканування чи інструментів, щоб його зробити, безкоштовний SEO-аудит SEORecheck просканує ваші сторінки справжнім браузером і Lighthouse та позначить проблеми з індексацією, редиректами, canonical, рендерингом і доступом ШІ-краулерів із прикладами URL, а повторна перевірка згодом порівняє кожну проблему з попереднім аудитом.

6. Моніторте два–чотири тижні

Регресії, які прослизнули, проявляться у звіті «Індексування сторінок» у Search Console та в кліках по шаблонах. Google зазначає, що після переїзду сайту зі зміною URL для сайтів середнього розміру може минути кілька тижнів або більше, перш ніж нові URL замінять старі, і радить зберігати редиректи щонайменше рік. Про постійні сповіщення читайте в посібнику про SEO-моніторинг.

Чи можна автоматизувати регресійні SEO-тести?

Так, частково. Перевірки з чіткою відповіддю «пройдено/не пройдено» (коди відповіді, noindex, наявність canonical, що вказує сам на себе, непорожній title, незмінний robots.txt, бюджет продуктивності) добре працюють у CI-пайплайні. Перевірки, що потребують судження, — наприклад, чи переписаний контент досі відповідає на запит, — і далі має переглядати людина.

Приклади того, що автоматизують команди:

• Lighthouse CI. Lighthouse CI від Google створений, щоб запускати Lighthouse на кожен коміт і зупиняти регресії в аудитах продуктивності, доступності та SEO за допомогою assertions. Він може запускати Lighthouse кілька разів для кожного URL, щоб зменшити розкид результатів.
• Smoke-тести шаблонів. Короткий end-to-end тест для кожного шаблону, який завантажує один URL і перевіряє HTTP-статус, відсутність noindex в HTML і заголовках, canonical на продакшен-домен, а також непорожні title і H1.
• Порівняння robots.txt. Збірка падає, якщо robots.txt у продакшені відрізняється від затвердженої версії.
• Перевірка карти сайту. Після деплою завантажте карту сайту й переконайтеся, що кожен URL у ній віддає 200 і доступний для індексації.

Памʼятайте, що оцінка SEO в Lighthouse охоплює лише кілька перевірок на рівні сторінки. Зелена оцінка на пʼяти URL нічого не каже про мапу редиректів чи про 3000 сторінок товарів, зібраних з іншого шаблону. Автоматизовані тести ловлять очевидні збої. Повне сканування ловить решту.

Регресійний SEO-тест чи SEO-аудит: у чому різниця?

Регресійний тест ставить одне вузьке питання: чи зламав цей реліз щось, що раніше працювало? SEO-аудит ставить ширше: що стримує сайт і в якому порядку це виправляти? Регресійні тести запускають на кожному вагомому релізі, а аудити — за графіком.

Вони добре доповнюють одне одного. Аудит дає чистий базовий стан із відомими проблемами. Регресійні тести не дають новим проблемам накопичуватися між аудитами. А наступний аудит показує, які проблеми виправлено, а які нові, — приблизно як у попроблемному порівнянні в прикладі звіту-порівняння SEORecheck. Як коректно читати таке порівняння, розповідаємо в статті порівняння SEO-аудиту до і після.

Які SEO-регресії після оновлень трапляються найчастіше?

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

1. Noindex або Disallow: / зі staging потрапили в продакшен. Зазвичай через прапорець оточення, який забули перемкнути.
2. Відсутні редиректи після зміни URL. Часто трапляється з новими шляхами категорій або прибраними слешами в кінці URL.
3. Canonical вказує на staging або неправильний хост. Причина — часто жорстко прописаний базовий URL.
4. Навігацію переписали на JavaScript-обробники кліків замість посилань <a href>. Сторінки втрачають внутрішні посилання й скануються рідше.
5. Шаблонні значення перезаписують власні title. Кожна сторінка товару отримує заголовок «Магазин».
6. Нова тема прибрала мікророзмітку. Розмітка Organization і Product тихо зникає.
7. Важчі сторінки. Нові слайдери, шрифти чи скрипти погіршують LCP і INP на ключових шаблонах. Порогові значення дивіться в посібнику про Core Web Vitals.

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

Головне

• Регресійне SEO-тестування порівнює критичні для SEO сигнали до і після релізу. Воно виявляє те, що змінилося, а не те, що можна покращити.
• Завжди майте базовий стан: повне сканування, копію robots.txt, карту сайту й результати Lighthouse для основних шаблонів.
• Перевіряйте noindex і в HTML, і в HTTP-заголовках, а robots.txt порівнюйте на кожному деплої, бо Google може кешувати robots.txt до 24 годин.
• Перевіряйте всю мапу редиректів і зберігайте редиректи щонайменше рік після зміни URL.
• Автоматизуйте перевірки «пройдено/не пройдено» в CI (Lighthouse CI, smoke-тести шаблонів). Для всього іншого — повне сканування й люди.
• Перевірте продакшен протягом години після релізу, а потім два–чотири тижні стежте за Search Console.