Шаблон SEO-контролю перед релізом сайту

Аркуш SEO-контролю релізу (для заповнення)

Коли використовувати: Один аркуш на реліз: критичні URL зі статусом, robots, canonical і аналітикою, плюс відповідальний за відкат і підпис.

Аркуш SEO-контролю релізу

Заповнюйте окремий аркуш для кожного релізу. Перевірте той самий набір URL на staging перед деплоєм і на production одразу після нього.

• Реліз: [версія або тікет] · Вікно деплою: [дата, час, часовий пояс]
• Що змінилося: [шаблони, маршрути, конфігурація, CMS, CDN, robots.txt]
• Хост production: [https://www.example.com] · Хост staging: [URL staging]

Критичні URL для перевірки

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

Відповідальний за відкат і підпис

• Відповідальний за відкат: [ім'я, телефон або нік у чаті] · Може відкотити без погодження: [так / ні]
• SEO-перевірку провів: [ім'я] · Технічну перевірку провів: [ім'я]
• Умова відкату: [будь-який критичний URL не пройшов перевірку статусу, robots або canonical]
• Рішення: [випускаємо / випускаємо з тікетом на доопрацювання / не випускаємо] · Підпис: [ім'я, час]

Перевірка завершена, коли: кожен рядок заповнено для staging і для production, жоден збій не лишився без тікета, відповідальний за відкат призначений, а аркуш збережено разом із нотатками до релізу.

Чекліст SEO переходу в production

Коли використовувати: Перший запуск зі staging: зняти блокування доступу, задати основний хост для canonical, перевірити редиректи, sitemap і аналітику, підписати запуск.

Перед перемиканням DNS або викладанням збірки

Staging зазвичай закривають трьома способами. Кожен із них треба зняти на production, і тільки там.

1. HTTP-автентифікація або вхід за логіном: знята на production. На staging залиште її.
2. robots.txt: на production не лежить файл зі staging із Disallow: /. Якщо потрібен чистий файл, створіть його в генераторі robots.txt.
3. noindex: у HTML немає <meta name="robots" content="noindex">, а сервер, CDN чи налаштування платформи не віддають заголовок X-Robots-Tag: noindex.

Основний хост

• Основний хост лише один: [https://www.example.com]. Інші версії (http, без www) ведуть на нього одним редиректом 301.
• Теги canonical містять абсолютні URL і вказують на хост production, ніколи на staging.
• Внутрішні посилання, hreflang і URL в Open Graph використовують хост production. Пошукайте в HTML [хост staging].

Редиректи

• Кожен URL, який існував до запуску, віддає 200 або один редирект 301 на нову адресу.
• Пройдіть кілька з них у Redirect Checker: один крок, фінальний статус 200, без циклу.
• Змінюєте багато URL? Замість цієї сторінки скористайтеся повним чеклістом міграції та картою редиректів.

Sitemap і Search Console

• Sitemap містить URL production, які віддають 200 і доступні для індексації.
• Sitemap вказано в robots.txt і надіслано в Search Console для ресурсу production.

Аналітика

• Працює ID аналітики production, а не тестовий ID чи ID зі staging.
• Ключові події спрацьовують один раз: [надсилання форми, покупка, реєстрація].
• Банер згоди на cookie поводиться так само, як на staging.

Підпис запуску

• Запуск погодив: [ім'я] · Час: [час]
• Staging після запуску досі закритий: [так, перевірено з браузера без входу в акаунт]

Перевірки перед релізом

Коли використовувати: Що перевірити на staging або тестовій збірці (preview) до деплою, щоб конфігурація production була правильною з першого дня.

Пройдіть це на staging до деплою

Staging закритий, тож перевіряйте його з увімкненою автентифікацією. Ви перевіряєте, що конфігурація production буде правильною, а не те, що staging доступний для індексації.

• Порівняйте SEO-налаштування: robots.txt, типові значення meta robots, базовий URL для canonical і ID аналітики беруться зі змінних середовища, а не прописані в коді.
• Шаблони: кожен змінений шаблон і далі виводить один title, один meta description, один canonical і H1.
• Вихідний HTML: перегляньте HTML і заголовки від сервера до виконання JavaScript. Source Code Viewer показує вихідний код, метатеги та HTTP-заголовки для публічного URL.
• Рендеринг: важливий контент і посилання є на сторінці після рендерингу, а не з'являються лише після кліку.
• Маршрути: для перейменованих або видалених маршрутів редиректи додано в тому самому релізі.
• Коди відповіді: відсутні сторінки віддають 404, а не 200 з повідомленням про помилку.

Правило контролю

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

Швидка перевірка після релізу

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

Перші 15 хвилин

Пройдіть увесь набір критичних URL на production. Використовуйте браузер без входу в акаунт і запит із сервера, бо кеш і авторизація приховують проблеми.

• Кожен рядок збігається з очікуваним статусом, robots і canonical.
• /robots.txt віддає 200. Помилка 5xx тут може змусити Google призупинити сканування сайту.
• У заголовках відповіді немає зайвого X-Robots-Tag.
• Аналітика показує живі відвідування на ID production.

Перша година

• Перевірте 2-3 ключові URL живим тестом у «Перевірці URL-адреси» (URL Inspection) в Search Console. Подивіться рядки про дозвіл на сканування та дозвіл на індексування.
• Переконайтеся, що очищення CDN або кешу завершилося і старий HTML більше не віддається.

Перший день і перший тиждень

• Запустіть безкоштовний аудит сайту, щоб перевірити коди відповіді, редиректи, robots.txt, noindex і canonical на вибірці сторінок.
• Стежте за логами сервера або «Статистикою сканування» (Crawl Stats): чи не зросла кількість відповідей 404 або 5xx.
• Упродовж наступних днів перевіряйте звіт «Індексування сторінок» (Page indexing) у Search Console: чи не з'явилися нові причини виключення, наприклад "URL marked 'noindex'" (URL позначено тегом noindex).
• Порівнюйте органічні кліки з тим самим днем тижня минулого тижня, а не з учорашнім днем.

Правила відкату

Коли використовувати: Погоджені умови, за якими вирішують: відкат, хотфікс чи тікет, і хто ухвалює рішення.

Погодьте це до деплою, а не під час нього

Чому важлива швидкість

• За словами Google, сторінки з noindex випадають з індексу, щойно Google повторно їх просканує.
• Google зазвичай кешує robots.txt до 24 годин, тож поганий файл може впливати на сканування навіть після виправлення.
• URL, які постійно віддають помилки сервера, згодом видаляються з індексу.

Після будь-якого відкату: повторно пройдіть набір критичних URL, запишіть у нотатки до релізу, що саме не пройшло, і додайте перевірку, щоб така помилка більше не проскочила.

Обсяг перевірки за типом релізу

Коли використовувати: Масштабуйте перевірку під зміну: від правки тексту в CMS до оновлення фреймворку чи першого запуску.

Підберіть перевірку під реліз

Не кожному деплою потрібен повний аркуш. Обсяг перевірки визначає тип зміни.

Де зазвичай ховаються SEO-налаштування

• Змінні середовища для базового URL і типових значень robots.
• Перемикач у CMS на кшталт «Не рекомендувати пошуковим системам індексувати сайт» або «Приховати від пошуку».
• Правила CDN або edge-серверів, які додають заголовки.
• Прапорці функцій (feature flags), через які частина користувачів бачить інший шаблон.

Заповнений приклад (вигаданий сервіс для бухобліку)

Коли використовувати: Заповнений аркуш для вигаданого релізу SaaS, де правило заголовків зі staging ледь не закрило сторінку цін через noindex.

Заповнений приклад: редизайн сторінки цін Tallyfin

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

Tallyfin, вигадана компанія з сервісом для бухгалтерського обліку, у вівторок викотила новий шаблон сторінки цін і порівняння тарифів. Реліз 4.12, деплой о 10:00.

• Що знайшла перевірка: новий маршрут сторінки цін отримав правило заголовків, скопійоване з edge-конфігурації staging. HTML виглядав нормально. noindex було видно лише в заголовках відповіді.
• Рішення: «не випускаємо» о 09:40. Правило перенесли лише на staging. Повторна перевірка пройшла о 10:25, деплой о 10:30.
• Відповідальна за відкат: Mara (платформа), має право відкотити реліз без погодження.
• Після релізу: живий тест у «Перевірці URL-адреси» (URL Inspection) для /pricing показав, що індексування дозволене. Аудит на другий день не знайшов нових сторінок з noindex.

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

Аркуш перевіряв заголовки, а не лише HTML, і в набір URL потрапив саме той шаблон, який змінював реліз. Відповідальну за відкат призначили ще до 10:00, тому рішення «не випускаємо» ухвалили за лічені хвилини.

Що далі

Вставте свої критичні URL у Source Code Viewer, щоб побачити вихідний HTML і заголовки, а старі URL пройдіть у Redirect Checker. Наступного дня після релізу запустіть безкоштовний аудит сайту.