SEO-чеклист міграції сайту та карта редиректів

Заміри та інвентаризація до міграції

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

Етап 1: заміри та інвентаризація

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

• Вивантажте поточні позиції в органіці за пріоритетними запитами [Дата фіксації]
• Запишіть органічний трафік і конверсії з аналітики за останні 3-6 місяців
• Зафіксуйте загальні цифри покриття індексу в Search Console (валідні, виключені, помилки)
• Зробіть повний краул живого сайту [Інструмент краулінгу] і збережіть вивантаження
• Складіть повний перелік URL зі статус-кодами, заголовками та мета-тегами
• Зафіксуйте сторінки з найбільшою кількістю посилань, щоб захистити їхні відповідники
• Збережіть поточні robots.txt, XML-карту сайту та мікророзмітку

Відповідальний: [Ім'я] & Базу зафіксовано: [Дата]. Складайте всі вивантаження в одну спільну теку: порівнювати з ними ви будете ще не один тиждень.

Карта редиректів (1:1 стара → нова)

Коли використовувати: Складіть чисту посторінкову карту редиректів, щоб кожна стара URL вела на найближчий новий відповідник через один 301.

Етап 2: карта редиректів

Редиректи переносять вагу зі старих URL на нові. Мета: карта 1:1. Кожна URL, яку ви виводите, веде на одну найрелевантнішу сторінку нового сайту. Неохайне зіставлення, це найчастіша причина втрати трафіку під час міграції.

1. Випишіть усі старі URL з переліку, зібраного на етапі 1 [Файл-джерело]
2. Підберіть до кожної найближчу нову URL: та сама тема, той самий намір користувача
3. Для перенесених сторінок використовуйте постійні 301 редиректи, а не 302
4. Уникайте ланцюжків і циклів редиректів. Ведіть одразу на кінцеву URL
5. Ніколи не зливайте все масово на головну; сироти ведіть на найдоречнішу сторінку розділу
6. Вирішіть, що робити зі сторінками без відповідника [410 чи редирект]
7. Свідомо визначте долю параметрів URL і слеша в кінці адреси

Перевірте всю карту на staging до запуску. Карту перевірив: [Ім'я]. Повна карта без ланцюжків, це найбільший важіль, який у вас є.

Збереження сторінкових елементів

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

Етап 3: збереження сторінкових елементів

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

• Перенесіть теги title точно або покращіть свідомо, але ніколи не втрачайте їх
• Збережіть мета-описи для сторінок, які приносять кліки
• Залиште H1 та ієрархію підзаголовків такими ж, як на старій сторінці
• Збережіть основний текст, не вирізайте тишком частини ключових сторінок
• Оновіть внутрішні посилання, щоб вони вели на кінцеві нові URL, а не через редиректи
• Перепропишіть посилання в меню, футері та хлібних крихтах
• Перенесіть мікророзмітку й alt-тексти зображень [Типи схем]

Спершу вибірково перевірте шаблони з найбільшим трафіком і найкращою конверсією. Відповідальний за перевірку: [Ім'я]. Якщо все ж міняєте текст, записуйте це, щоб потім пов'язати зміну позицій із правкою.

Технічні налаштування

Коли використовувати: Правильно налаштуйте robots.txt, карти сайту, канонічні теги, hreflang та аналітику на новому сайті до запуску й під час нього.

Етап 4: технічні налаштування

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

1. Переконайтеся, що robots.txt не блокує обхід на проді [URL]
2. Приберіть усі теги noindex, що лишилися зі staging
3. Згенеруйте чисту XML-карту сайту лише з кінцевими індексованими URL
4. Проставте самопосилальні канонічні теги на кожній сторінці
5. Налаштуйте hreflang, якщо у вас кілька мов чи регіонів
6. Перевірте HTTPS і те, що HTTP-запити ведуть на захищену версію
7. Підключіть аналітику та Search Console до нового ресурсу [GA / GSC ID]

Провалідуйте карту сайту й зробіть свіжий краул staging, щоб зловити помилки завчасно. Технічні перевірки погодив: [Ім'я]. Зробіть це до дня запуску, а не під час нього.

Чеклист дня запуску

Коли використовувати: Проведіть переїзд у години низького трафіку за чіткою послідовністю, щоб під тиском нічого не пропустити.

Етап 5: день запуску

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

1. Заплануйте переїзд на період низького трафіку [Дата / час]
2. Розгорніть новий сайт і увімкніть усі 301 редиректи одночасно
3. Переконайтеся, що бойовий robots.txt дозволяє обхід і не містить старих блокувань
4. Подайте нову XML-карту сайту в Search Console
5. Вибірково перевірте, що ключові редиректи дають 301 → 200, а не ланцюжки чи 404
6. Переконайтеся, що аналітика спрацьовує й фіксує нові URL
7. Протестуйте форми, пошук, оформлення замовлення та інші критичні сценарії

Тримайте команду на зв'язку кілька годин після запуску. Відповідальний за запуск: [Ім'я] & Час запуску: [Час]. Не піддавайтеся спокусі правити контент того ж дня: відокремте запуск від редагувань.

Моніторинг після запуску

Коли використовувати: Стежте за Search Console, помилками обходу та позиціями після запуску, щоб швидко знаходити й виправляти проблеми.

Етап 6: моніторинг після запуску

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

• Щодня перевіряйте Search Console на покриття й помилки обходу
• Слідкуйте за сплесками 404 і швидко виправляйте чи перенаправляйте їх
• Переобходьте живий сайт, щоб зловити биті посилання й хибні редиректи
• Переконайтеся, що нові URL індексуються, а старі випадають з індексу
• Порівнюйте позиції й трафік із базою з етапу 1
• Скористайтеся інструментом зміни адреси сайту, якщо ви змінили домен
• Перевірте, що карта сайту оброблена, а якщо налаштовували hreflang, переконайтеся, що там немає помилок

Записуйте кожне виправлення з датою, щоб пов'язати дії з відновленням. Відповідальний за моніторинг: [Ім'я] & Спостерігаємо до: [Кінцева дата]. Не панікуйте від ранніх просідань: розбирайтеся, фіксуйте й дайте переобходу час.

Робоча таблиця редиректів (для заповнення)

Коли використовувати: Один рядок на кожну стару URL: нова ціль, поточний статус, канонічний тег, трафік, домени-донори, тип редиректу, відповідальний і результат перевірки.

Робоча таблиця редиректів

Один рядок на кожну стару URL. Не на шаблон і не на розділ. Саме пропущені рядки віддають 404 у ніч запуску.

Колонки

• Стара URL: [адреса, яка працює сьогодні]
• Нова URL: [куди має вести, або "вивести"]
• Статус зараз: [200 / 301 / 404 / noindex]
• Канонічний зараз: [що сторінка вказує сьогодні]
• Сеанси за останні 90 днів: [число і джерело]
• Домени-донори: [число] · зберігайте ті, що мають посилання, навіть коли трафік дорівнює 0
• Тип редиректу: [301 постійний / 410 видалено, і нічого іншого]
• Відповідальний: [одна конкретна людина]
• Результат перевірки: [ок / не ок, із датою перевірки на живому сайті]

Таблиця

Правила, які рятують міграцію

• Ведіть на найближчу за змістом сторінку й ніколи не зливайте все масово на головну. Редирект на головну, це той самий soft 404, тільки в обхід.
• Жодних ланцюжків. Зі старої на нову, один крок, навіть якщо стару адресу вже колись перенаправляли.
• Сторінка з посиланнями й без трафіку все одно отримує редирект. Цінність тут у посиланнях.
• Рішення "вивести" ухвалюйте свідомо й ставте 410, щоб сторінка швидко зникла з індексу, а не висіла там місяцями.
• Вивантажте список старих URL із 3 джерел: краул, карта сайту й аналітика. Кожне з них пропускає щось своє.

Умови запуску та відкату

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

Умови запуску та відкату

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

Умова 1, до запуску

• Кожна стара URL має свій рядок і рішення: [так / ні]
• Редиректи перевірено на staging, вибірка з [число] URL, ланцюжків: [0]
• Канонічний тег, title і мета-опис перевірено на [число] шаблонах з найбільшим трафіком
• Аналітика й Search Console готові на новому ресурсі: [так / ні]
• Погодив [ім'я] [дата]

Умова 2, день запуску

• robots.txt не блокує новий сайт: [хто перевірив, час]
• Вибірка з [число] живих редиректів дає один 301: [ок / не ок]
• Нову карту сайту подано, стару лишено активною на [період]
• Перевірка рівня помилок на [T+1 год] і [T+24 год]: [ок / не ок]

Умова 3, відкат

Пропишіть тригер заздалегідь, щоб об 11 вечора ніхто про нього не сперечався.

• Тригер: [напр., 5xx понад X%, або падіння індексованих сторінок на Y% за 24 год]
• Хто вирішує: [ім'я] · Хто виконує: [ім'я]
• Скільки триває відкат: [хвилини / години], перевірено [дата]
• Що зберігається під час відкату: [контент, замовлення, заявки з форм]

Після запуску

• Переобхід на [3 день], [14 день] і [30 день] з порівнянням індексованих сторінок і 404 із передстартовою базою.
• Готуйтеся до просідання. Позиції рухаються, поки Google переобходить сайт, а міграція зі зміною URL, це таки зміна, а не нейтральна подія.
• Ніхто не може пообіцяти нульовий вплив, і підрядник, який обіцяє, просто каже вам те, що ви хочете почути. Обіцяйте натомість запуск із картою, тестами й можливістю відкату.

Живий приклад (4 рядки і 2 порятунки)

Коли використовувати: Чотири заповнені рядки з вигаданого переїзду на нову платформу, разом зі сторінкою без трафіку, яку варто зберегти, і тим, що зловили умови запуску.

Живий приклад: 4 рядки з переїзду на нову платформу

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

Рядок 2, це саме той, який команди пропускають: трафіку немає, зате 6 доменів-донорів, і редирект зберігає посилання, які заробляли роками. Рядок 4, навпаки: зберігати нічого, тому сторінка свідомо йде з індексу.

Що зловили умови запуску

Тести на staging знайшли 41 ланцюжок редиректів, усі виправили до запуску. У день запуску перевірка на T+1 год показала, що новий robots.txt блокує /guides/, виправили за 8 хвилин, бо відповідальний був призначений і не спав. Позиції просідали 9 днів, а потім піднялися вище за базу, і це нормальна картина.

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

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