Чек-лист миграции сайта (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 на стейджинге, резервной копии и мониторинга после запуска. Сократите лист до фаз, соответствующих масштабу вашего конкретного изменения.