Чекліст міграції сайту (PDF)

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

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

6 готових варіантів

Фаза 1: План і резервна копія

Зафіксуйте план і зробіть повні резервні копії, перш ніж хтось змінить бодай один URL.

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

Позначте перед початком

  • ☐ Повну резервну копію поточного сайту (файли й база даних) зроблено, відновлення протестовано
  • ☐ Повне сканування старого сайту експортовано й збережено
  • ☐ Зіставлення URL (старі на нові) складено для кожної сторінки
  • ☐ Базовий рівень аналітики й Search Console зафіксовано: [знімок трафіку / позицій]
  • ☐ План відкату написано й узгоджено з відповідальним розробником
  • ☐ Вікно запуску заплановано на години низького трафіку: [Дата / час]

Погодження фази 1
Відповідальний: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Фаза 2: QA на стейджингу

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

Мета: підтвердити, що новий сайт коректний і скануваний, поки він ще приватний.

Позначте на стейджингу

  • ☐ Редиректи протестовано на стейджингу, вони повертають очікувані коди
  • ☐ Заголовки, meta-описи й підзаголовки наявні на ключових сторінках
  • ☐ Canonical-теги вказують на нові URL
  • ☐ Внутрішні посилання оновлено на нові URL, немає посилань на старий домен
  • ☐ robots.txt дозволятиме сканування на запуску (noindex стейджингу знято при go-live)
  • ☐ XML sitemap згенеровано з новими URL і валідовано
  • ☐ Мобільний рендеринг і швидкість сторінок перевірено на ключових шаблонах

Погодження фази 2
Відповідальний: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Фаза 3: День запуску

Послідовність go-live, яку позначають по порядку, коли кожен крок завершено.

Мета: чисто виконати перемикання й підтвердити найважливіше в момент, коли сайт стає живим.

Позначте під час запуску

  • ☐ noindex / парольний захист стейджингу знято
  • ☐ Редиректи розгорнуто на продакшн
  • ☐ robots.txt живий і дозволяє сканування нового сайту
  • ☐ Новий sitemap надіслано в Search Console
  • ☐ Підтверджено, що аналітика й теги відстеження спрацьовують на новому сайті
  • ☐ Вибірку високопріоритетних старих URL вручну підтверджено на редирект
  • ☐ SSL-сертифікат дійсний по всьому новому домену

Погодження фази 3
Запустив: [Ім'я]   Час запуску: [Час]   Підпис: [Підпис]

Фаза 4: Перші 48 годин

Виявіть помилки, що з'являються лише коли на живий сайт приходить реальний трафік.

Мета: знайти й виправити поломки дня запуску, перш ніж вони коштуватимуть позицій.

Позначте протягом 2 днів

  • ☐ Повне сканування живого сайту виконано; 404 і зламані редиректи зафіксовано
  • ☐ Ланцюжки й цикли редиректів перевірено й усунено
  • ☐ Search Console перевірено на помилки сканування й попередження про покриття
  • ☐ Частоту помилок сервера й час завантаження сторінок відстежено: [статус]
  • ☐ Підтверджено, що високопріоритетні сторінки індексовані й повертають 200
  • ☐ Будь-який контент, втрачений під час переїзду, відновлено або позначено: [примітки]

Погодження фази 4
Відповідальний: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Фаза 5: Моніторинг тижнів 1–4

Стежте, як усталюються позиції, індексація й трафік, щоб реальні падіння опрацювати рано.

Мета: підтвердити, що міграція втрималася, і зреагувати на все, що просіло.

Позначте протягом першого місяця

  • ☐ Індексація нових URL просувається в Search Console
  • ☐ Позиції за пріоритетними ключовими словами порівняно з базовим рівнем до запуску
  • ☐ Органічний трафік відстежено відносно того самого періоду минулого циклу: [тренд]
  • ☐ Будь-які сторінки, що втратили позиції, досліджено й виправлено
  • ☐ Зворотні посилання на старі URL досі вирішуються через редиректи
  • ☐ Старий sitemap видалено, щойно нові URL проіндексовано

Погодження фази 5
Відповідальний: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Фаза 6: Фінальне погодження

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

Мета: формально закрити міграцію з підзвітністю кожного відповідального за фазу.

Підтвердьте перед закриттям

  • ☐ Усі попередні фази погоджено
  • ☐ Немає незакритих 404 чи зламаних редиректів на пріоритетних сторінках
  • ☐ Трафік і позиції в прийнятному діапазоні від базового рівня або відновлюються за планом
  • ☐ Відкриті проблеми зафіксовано з відповідальними й термінами: [список]
  • ☐ Звіт після міграції надано стейкхолдерам

Погодження проєкту

SEO-відповідальний: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Відповідальний розробник: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Затверджувач: [Ім'я]   Дата: [Дата]   Підпис: [Підпис]

Як використовувати цей шаблон

  1. Роздрукуйте чекліст і призначте іменного відповідального на кожну фазу, перш ніж почнеться будь-яка робота.
  2. Завершіть фазу 1: зробіть і протестуйте повну резервну копію, зафіксуйте базові рівні й узгодьте план відкату.
  3. Опрацюйте фазу 2 повністю на стейджингу, щоб редиректи, метадані й скануваність перевірити приватно.
  4. Виконайте послідовність запуску фази 3 по порядку й підтвердьте редиректи й відстеження в момент go-live.
  5. Протягом 48 годин проскануйте живий сайт на 404 і проблеми з редиректами й швидко їх виправте.
  6. Відстежуйте індексацію, позиції й трафік протягом тижнів 1–4 і досліджуйте все, що просідає.
  7. Вимагайте, щоб відповідальний за фазу підписав кожну фазу, перш ніж міграція перейде до наступної.
  8. Завершуйте фінальне погодження лише тоді, коли пріоритетні сторінки чисті, а стейкхолдери мають звіт.

Поради

  • Ставтеся до кожного рядка погодження як до реальних воріт, а не формальності: непідписана фаза означає, що роботу не перевірено, а неперевірена робота — це те, де міграції втрачають трафік.
  • Зробіть і протестуйте відновлення резервної копії, перш ніж чіпати будь-що; план відкату, який ви ніколи не тестували, — це надія, а не план.
  • Плануйте запуск на справді малотрафікові години, щоб неминучі виправлення першої години торкнулися найменшої кількості користувачів.
  • Продовжуйте моніторинг цілий місяць; позиції й індексація усталюються поступово, а найгірші падіння часто спливають за тиждень-два після запуску, а не в перший день.

Поширені запитання

Чому друкований PDF, а не таблиця?

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

За скільки часу до запуску має початися фаза 1?

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

Яка фаза найважливіша?

Чесно кажучи, QA на стейджингу у фазі 2 і 48-годинне сканування у фазі 4 виявляють найбільше. Тестування редиректів до запуску й повторне сканування одразу після охоплюють найбільші джерела втрати трафіку. Проте пропуск резервної копії у фазі 1 — це та єдина помилка, яку ви справді не можете скасувати.

Чи варто очікувати падіння трафіку після міграції?

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

Хто має підписувати кожну фазу?

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

Чи можу я повторно використати це для меншої зміни, як-от редизайн?

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