Запуск нового сайту й редизайн наявного — два моменти, коли бізнес найчастіше втрачає накопичені позиції в Google, причому не через зміст, а через технічні деталі, які візуально непомітні. Сайт може виглядати навіть краще за попередній і при цьому повністю зникнути з пошуку на кілька тижнів. Нижче — чек-лист, який закриває типові причини таких провалів до того, як вони сталися, а не після.
01 Чому сайти втрачають трафік при запуску і редизайні
Падіння позицій після запуску або редизайну майже ніколи не пов'язане з якістю дизайну чи контенту — Google не вміє оцінювати красу інтерфейсу. Причина майже завжди технічна, і здебільшого це одна й та сама схема: старі адреси сторінок перестали існувати, а нові для пошуковика ще не існують.
Три сценарії трапляються найчастіше:
- Змінилася адреса сторінок без 301-редиректів — старий URL віддає 404, накопичена вага і позиції сторінки обнуляються;
- Індексацію випадково заблокували — на новій версії сайту залишився noindex або заборона в robots.txt, успадкована з тестового домену;
- Зник вміст, за який сторінка ранжувалася — при редизайні текст скоротили або переписали, і сторінка перестала відповідати на попередній запит.
Кожен із цих сценаріїв запобігається заздалегідь, а не лікується після того, як трафік уже впав. Якщо позиції все ж просіли і причина незрозуміла, загальна діагностика розібрана в статті чому сайт не росте в Google — цей же чек-лист звужує список причин саме до контексту запуску і редизайну.
02 До запуску: технічне SEO-завдання для розробника
Більшість проблем закладається на етапі розробки, коли SEO-вимоги не були письмово зафіксовані, і розробник ухвалював рішення за замовчуванням. Технічне завдання закриває це заздалегідь.
У завдання для розробника мають входити щонайменше такі пункти:
- тестова версія сайту (staging) закрита від індексації паролем або мета-тегом noindex, а не тільки через robots.txt;
- структура URL збігається з поточною, якщо явної причини її змінювати немає;
- заголовки Title, метаописи, атрибути alt і структура заголовків H1–H3 переносяться з поточного сайту, а не створюються заново за замовчуванням CMS;
- на новій версії налаштовані канонічні адреси без випадкових дублів за параметрами URL;
- швидкість завантаження і мобільна версія перевірені до запуску, а не після скарг користувачів.
Письмове завдання дає розробнику чіткі критерії приймання і знімає ситуацію, коли «не втратити позиції» залишається усною домовленістю без конкретних технічних вимог.
03 Карта 301-редиректів: як її скласти
Якщо структура адрес сторінок змінюється хоча б частково, карта редиректів обов'язкова. Це таблиця вигляду «старий URL → новий URL», за якою сервер автоматично перенаправляє користувачів і пошукових роботів на актуальну адресу, передаючи накопичену вагу сторінки.
Карту складають у три кроки: спершу вивантажують повний список поточних URL сайту — із sitemap.xml, логів сервера або звіту про індексування сторінок у Search Console; потім кожній старій адресі підбирають найближчу за змістом нову; і в останню чергу редиректи тестують на staging-версії до того, як сайт стане публічним. Офіційні рекомендації Google щодо переїзду сайту зі зміною адрес докладно розбирають цю логіку в документації про переїзд сайту зі зміною URL.
Часта помилка — спрямовувати всі старі адреси на головну сторінку замість конкретної нової сторінки. Формально редирект є, але він не передає релевантність, і Google фактично вважає це такою самою втратою позицій, як і відсутність редиректу взагалі.
04 Robots.txt, sitemap.xml і canonical на новому сайті
Три технічні файли визначають, що пошуковий робот взагалі побачить на новому сайті. Помилка в будь-якому з них здатна закрити від індексації весь сайт, навіть якщо зовні він працює ідеально.
Що потрібно перевірити перед публічним запуском:
- robots.txt — не повинен містити директиву Disallow: /, успадковану з тестового домену; принципи роботи файлу та його директив описані в документації Google про robots.txt;
- sitemap.xml — містить актуальний список нових адрес без старих URL, оновлений і готовий до відправлення через Google Search Console, а вимоги до самого файлу описані в документації про карти сайту;
- canonical — на кожній сторінці вказує на саму себе або на правильну основну версію при дублях; помилки тут Google описує в матеріалі про об'єднання дублікатів URL.
Усі три файли варто перевірити саме на staging-версії перед перемиканням домену, а не після — виправляти індексаційну помилку постфактум завжди довше і дорожче, ніж не допустити її.
05 Що перевірити в день запуску
У момент перемикання домену на нову версію рахунок іде на години: що раніше знайдено технічну помилку, то менші реальні втрати в індексації.
Мінімальний набір перевірок одразу після запуску:
- ключові сторінки сайту віддають код відповіді 200, а не 404 чи 500 — перевіряється вручну або через сервіс масової перевірки кодів відповіді;
- robots.txt нової версії більше не блокує сканування;
- ресурс підтверджено в Search Console, а свіжий sitemap.xml відправлено через розділ «Файли Sitemap»;
- вибіркові редиректи зі старих URL перевірені вручну — відкриваються в браузері і ведуть на релевантну нову сторінку з кодом 301, а не 302;
- лічильники аналітики і коди конверсій встановлені на новій версії і фіксують події.
Якщо хоча б один пункт не виконано, краще відкласти публічний запуск на кілька годин, ніж потім усувати наслідки індексаційної помилки, яка вже встигла зафіксуватися в пошуку.
06 Моніторинг перших 2–4 тижнів після запуску
Навіть за ідеально налаштованого запуску перші тижні вимагають частішого контролю, ніж звичайний режим роботи із сайтом, — саме в цей період технічні помилки найпомітніше впливають на індексацію.
У цей період варто перевіряти частіше за звичайне: звіт про індексування сторінок у Search Console — чи не зростає число сторінок зі статусом «Виявлено, але не проіндексовано»; звіт «Ефективність» — чи не просіли покази за ключовими запитами, за якими сайт раніше ранжувався; а також позиції за контрольним списком із 15–20 найцінніших комерційних запитів, щоб помітити проблему раніше, ніж вона стане помітною у виторгу.
07 Що робити, якщо позиції все ж просіли
Навіть за підготовленого запуску невелика просадка позицій на 1–2 тижні — нормальна реакція пошуковика на зміни, а не привід для паніки. Тривогу має викликати падіння, яке не відновлюється або продовжує наростати.
Якщо за місяць позиції не повернулися, варто по черзі перевірити: чи не пропущено якийсь старий URL у карті редиректів, чи не залишився десь noindex або Disallow, успадкований зі staging-версії, чи не змінився фактично вміст сторінок, за який вони раніше ранжувалися. Повний алгоритм такої діагностики, застосовний не тільки до запуску, а до будь-якого падіння трафіку, розібрано в статті чому сайт не росте в Google. Якщо самостійно знайти причину не вдається, далі потрібен повноцінний SEO-аудит сайту, який звіряє технічний стан нової версії з тим, що було до змін.
Після запуску чи редизайну окремі сторінки іноді все одно не індексуються навіть за правильно налаштованого sitemap — що робити в такому разі, розібрано в статті як прискорити індексацію сайту в Google.
Ще до запуску чек-листа технічної перевірки варто визначитися з платформою сайту — від вибору CMS залежить, які пункти взагалі будуть доступні для налаштування; порівняння платформ — у статті порівняння CMS для SEO: WordPress vs Tilda vs Shopify.
Що буває, якщо частину цього чек-листа пропустити при переїзді на новий домен, розібрано на ілюстративному прикладі у статті відновлення трафіку після переїзду сайту.
08 Часті запитання
За скільки до запуску потрібно готувати SEO-частину?
Мінімум за 2–3 тижні, якщо йдеться про редизайн наявного сайту з уже напрацьованими позиціями: цього часу достатньо, щоб зібрати карту редиректів, узгодити її з розробником і протестувати на staging-версії. Для сайту без історії в пошуку критичного поспіху немає, але чек-лист усе одно варто пройти до, а не після запуску.
Що робити, якщо сайт уже запустили без карти редиректів?
Скласти карту постфактум і додати 301-редиректи якомога швидше — втрачена вага сторінок частково відновлюється, якщо зробити це протягом кількох тижнів після запуску. Що довше старі URL віддають 404, то більше накопиченої посилальної ваги і позицій зникає безповоротно.
Чи потрібно закривати staging-версію сайту від індексації?
Обов'язково. Тестовий домен, доступний пошуковим роботам, створює дублі контенту і може випадково проіндексуватися раніше за основний сайт. Закривають його паролем на рівні сервера або мета-тегом noindex, а не через robots.txt — файл сам по собі не забороняє індексацію вже знайдених сторінок.
Як довго відновлюються позиції після редизайну?
За акуратної міграції з повною картою редиректів помітна просадка зазвичай не перевищує 1–2 тижні, а позиції повертаються до попереднього рівня за 4–8 тижнів. Якщо редиректи налаштовані з помилками або відсутні, відновлення може розтягнутися на місяці або не відбутися зовсім, бо накопичена вага сторінок втрачається безповоротно.
Чи обов'язково змінювати структуру URL при редизайні?
Ні, і за замовчуванням краще цього не робити. Навіть неідеальна на вигляд адреса сторінки вже накопичила історію індексації, зовнішні посилання і позиції. Змінювати структуру URL варто тільки за явної технічної потреби — і в цьому разі обов'язково закривати перехід повною картою 301-редиректів.
Хто має відповідати за SEO-частину запуску — розробник чи SEO-фахівець?
Формально ставить завдання SEO-фахівець — саме він знає, які сторінки приносять трафік і які технічні вимоги не можна порушувати. Але виконує їх розробник, тому технічне SEO-завдання має бути письмовим і максимально конкретним, а не усною домовленістю «не втратити позиції».