Чек-лист миграции сайта, который пропускают большинство агентств

Peretz Group

Chapters

The Website Migration Checklist Most Agencies Skip

Большинство миграций сайта проваливаются не с грохотом.

Они проваливаются тихо, спустя недели после того, как все уже переключились на следующий проект.

Запуск выглядит чистым. Новый сайт быстрее. Дизайн лучше. CMS работает. Редиректы вроде на месте. Трафик немного падает, как все и ожидали, и команда начинает называть миграцию успешной.

Иногда так и есть.

Иногда настоящая проблема просто ещё не проявилась.

Чек-лист миграции существует не просто так. Но большинство чек-листов фокусируются на видимой механике: редиректы, sitemap, мобильная версия, аналитика, DNS.

Сложная часть, это всё, что находится между старым сайтом и новым: накопленные URL, обратные ссылки, внутренние связи, структурированные данные, языковые сигналы и история поиска, на строительство которых бизнес мог потратить годы. Мы писали о том, как это накопление происходит незаметно со временем, в статье Всё, что ты строишь, начинает стареть в день завершения.

Успешная миграция, это не про запуск нового сайта.

Это про перенос всего, что делало старый сайт ценным, без потери сигналов, благодаря которым поисковые системы его понимали.

Почему провал выглядит тихо

Чистая миграция и сломанная могут выглядеть почти одинаково в первую неделю.

Некоторая потеря трафика нормальна. Google нужно проиндексировать новые URL, обработать редиректы и переоценить связь между старой и новой версиями сайта.

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

Проблемная миграция может выглядеть похоже поначалу.

Разница в том, что происходит дальше.

Опасность поэтому не в первом падении трафика. Она в предположении, что это падение и есть вся история.

Мы неоднократно наблюдали такое мышление: команда запускается в пятницу, проверяет аналитику в понедельник, видит, что цифры примерно там, где ожидалось, и двигается дальше.

Этого недостаточно, чтобы назвать миграцию успешной.

О миграции нужно судить по траектории, что следует за ней, а не по скриншоту, снятому через три дня после запуска.

Карта редиректов, которую никто не заканчивает

Все знают, что редиректы важны.

Гораздо меньше команд редиректят всё, что на самом деле нужно редиректить.

Очевидные страницы обычно выживают: главная, ключевые страницы услуг, важные продукты.

Сложная часть, это длинный хвост.

Старые статьи. Категорийные страницы. Лендинги. URL, что по отдельности почти не приносят трафика, но накопили обратные ссылки, внутренний авторитет или поисковую видимость за многие годы.

Одна задокументированная миграция прокраулила 14 200 URL и создала редиректы на весь набор, а не только на страницы, важные по аналитике. Другая протестировала почти тысячу отдельных редиректов до запуска.

Такой уровень подготовки может казаться избыточным, пока что-то не сломается.

Причина, по которой команды пропускают длинный хвост, обычно не небрежность. Это приоритизация.

Под дедлайном люди естественно защищают страницы, которые видят в отчётах по трафику.

Поисковым системам всё равно на дедлайн.

Есть ещё одна проблема, которую ещё легче упустить: варианты URL.

HTTP против HTTPS. С www или без. Trailing slash. Регистр. Старые структуры URL. Параметры и устаревшие пути.

Для человека это может выглядеть одной и той же страницей.

Для поисковой системы это могут быть разные URL, и, соответственно, разные накопленные сигналы.

Карта миграции, что покрывает страницы, которые люди помнят, но игнорирует URL, которые никто не помнит, не полная карта миграции.

Та же логика распространяется за пределы URL. Миграция также переносит всё, от чего бизнес незаметно стал зависим: плагины, интеграции, сторонние скрипты, тот тип накопленных зависимостей, что мы разбирали в статье Большинство компаний не владеют своим сайтом. Они владеют коллекцией зависимостей.

Длинный хвост, это где обычно прячутся годы накопленной истории.

Старые сайты бывает труднее перенести

Одна миграция восстанавливается за недели. Другая может занять много месяцев.

Хочется винить платформу, CMS или реализацию редиректов.

Это имеет значение. Но это не вся картина.

Исследование, отслеживающее 892 миграции доменов, нашло сильную связь между временем восстановления и размером существующего backlink-профиля сайта.

В этом есть интуитивный смысл.

У относительно молодого сайта меньше истории, которую Google нужно перекраулить, переоценить и переприсвоить. У зрелого сайта могут быть тысячи накопленных за годы ссылок: внешние ссылки, проиндексированные URL, внутренние связи и исторические сигналы.

Это создаёт неудобный парадокс.

Чем более устоявшийся сайт, тем более аккуратно, возможно, нужно обращаться с его миграцией.

Возраст сам по себе не проблема. Проблема, накопленная сложность.

Поэтому десятилетний сайт с сильной поисковой видимостью не стоит трактовать просто как более крупную версию двухлетнего сайта.

Его риск миграции другой.

И этот риск нужно понимать до того, как кто-то начнёт редизайнить шаблоны или выбирать новую CMS.

Мы сами проходим через ровно такой переход прямо сейчас со SHTAYER, перенося растущий мультиязычный каталог с WordPress на Laravel, поскольку старая платформа исчерпала себя. Мы писали о том, какое решение запускает такой переезд, в статье Когда бизнес перерастает WordPress?.

Слепая зона трёх недель

Один из самых опасных моментов в миграции, это когда ничего не выглядит неправильным.

Рейтинги и трафик могут оставаться относительно стабильными первые несколько недель, пока Google обрабатывает изменения.

Потом сигнал может сдвинуться.

Иногда позитивно. Иногда негативно.

Это создаёт практическую проблему: люди, ответственные за миграцию, часто уже не отвечают за сайт.

Команда разработки перешла на другой проект. SEO-консультант сдал отчёт по запуску. Клиент принял новый сайт. В худших случаях старая инфраструктура уже деактивирована.

Теперь есть проблема с трафиком, но нет чистого бейзлайна и никого с полным контекстом.

Поэтому мы относимся к постзапускному мониторингу как к части самой миграции, не как к опциональному постпродакшену.

Запуск, это веха.

Это не конец миграции.

Структурированные данные заслуживают внимания

Микроразметку легко забыть, потому что посетители её не видят.

Именно поэтому она теряется во время миграций.

Новая CMS может генерировать свою собственную структурированную разметку. Может не генерировать вообще никакой. Может заменить тщательно реализованную разметку на общую.

Сайт может выглядеть полностью корректным, пока поисковая система получает существенно другую информацию.

Product schema, review schema, article schema и другие типы структурированных данных имеют разные требования. Миграции поэтому нужна не только визуальная проверка.

Живую реализацию нужно протестировать.

Здесь тоже есть важное различие.

Мы бы не стали говорить клиенту, что потеря микроразметки автоматически означает крупный обвал трафика. Поисковая производительность редко управляется одним изолированным сигналом.

Более реалистичный риск в том, что миграция убирает сразу несколько мелких преимуществ.

Rich-результат исчезает. Страница становится менее понятной поисковику. CTR меняется. Рейтинг немного сдвигается.

По отдельности ни одно не выглядит катастрофой.

Вместе они могут стать дорогими.

Именно так часто работают проблемы миграции: не как один драматичный провал, а как несколько мелких потерь, которые никто не связывает с одним и тем же запуском.

Hreflang может сломаться незаметно

Для мультиязычных сайтов проблема усложняется.

Hreflang сообщает поисковым системам о связи между языковыми и региональными версиями страниц. Во время миграции эти связи особенно уязвимы, потому что структуры URL, шаблоны, логика CMS и внутренняя перелинковка часто меняются одновременно.

Некорректная или неполная реализация может не давать явной ошибки на странице.

Сайт всё ещё открывается.

Переключатель языка всё ещё работает.

Контент всё ещё на месте.

Но сигналы, отправляемые Google, могут больше не соответствовать структуре, которую задумал бизнес.

Поэтому мультиязычные миграции требуют архитектурного мышления, а не просто проверки переводов.

Вопрос не только в том, существует ли каждая языковая версия.

Вопрос в том, сохраняет ли новая система связи между этими версиями.

Это различие особенно важно для бизнесов, работающих на нескольких рынках, где техническая ошибка может незаметно затронуть один язык или регион, оставив остальные внешне здоровыми.

Работа происходит до запуска

Сильнейшие миграции разделяют одну простую черту:

Большая часть сложной работы происходит до смены DNS.

Карта редиректов готовится, пока старый сайт ещё живой.

Инвентарь URL сверяется с новой архитектурой.

Внутренние ссылки аудируются.

Микроразметка документируется.

Связи hreflang картируются.

Данные аналитики и Search Console устанавливают бейзлайн.

Важные рейтинги и посадочные страницы идентифицируются.

Новый сайт тестируется против старого до того, как старое окружение исчезает.

Это не эффектная работа.

Никто не смотрит на идеальную таблицу редиректов в день запуска и не думает: какая прекрасная миграция.

Но эта таблица, возможно, и есть причина, по которой запуск скучный.

А скучный, это именно то, что нам нужно.

Здесь есть более широкий принцип, который мы применяем к техническому due diligence в целом, и о котором подробнее писали в статье Скрытый технический долг, из-за которого редизайн сайта стоит дороже плана: самое дешёвое время обнаружить структурную проблему, это до того, как ты построил вокруг неё новую структуру.

Найти проблему во время планирования, это находка аудита.

Найти её после запуска, это инцидент.

Мониторинг не заканчивается на запуске

Если реальный сигнал может проявиться спустя недели после запуска, проверка аналитики через три дня, это не мониторинг.

Это самоуспокоение.

Серьёзной миграции нужен определённый период наблюдения.

Это значит отслеживать органический трафик, рейтинги, покрытие индекса, поведение краулера, 404-ошибки, ответы сервера и страницы, которые были важнее всего до миграции.

Это не обязательно требует огромного технологического стека.

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

Точный период мониторинга должен зависеть от размера и сложности сайта.

Шесть недель могут быть разумным минимумом для многих миграций, но крупный, авторитетный или мультиязычный сайт может заслуживать существенно более долгого наблюдения.

Это ещё одно место, где жёсткие чек-листы могут стать опасными.

Чек-лист должен контролировать риск, не заменять суждение.

Во что обходится пропуск этого

Задокументированные случаи сложно игнорировать.

Одна миграция потеряла 42% органического поискового трафика за двенадцать дней после того, как компания пошла без нормальной стратегии редиректов, сославшись на ограниченные IT-ресурсы.

Другой сайт среднего размера в ритейле запустился с полностью новыми URL и без редиректов и потерял примерно 60% органического трафика за две недели. Восстановление потребовало месяцев выделенной работы.

Есть и другие примеры, где изменения URL превратили позитивный год-к-году органический рост в резкое недельное падение сразу после запуска.

Эти цифры не стоит трактовать как универсальное предсказание.

Сайт не обязательно потеряет 42%, потому что кто-то пропустил редирект.

Поиск так не работает.

Более полезный урок проще: ошибки миграции могут уничтожить ценность, накапливавшуюся годами, а восстановить её обычно намного дороже, чем защитить до запуска.

Стоимость поэтому не только в потерянном трафике.

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

Что нужно чек-листу

Серьёзный чек-лист миграции меньше про больше пунктов для галочки и больше про правильные вопросы.

Мигрируем ли мы каждый значимый URL, или только страницы, видимые в топ-трафик отчёте?

Учли ли мы варианты URL и устаревшие структуры?

Понимаем ли мы, сколько авторитета и истории накопил существующий домен?

Задокументировали ли мы структурированные данные сайта до замены CMS?

Сохранены ли мультиязычные связи, а не воссозданы по памяти?

Есть ли у нас предзапускный бейзлайн?

Кто отвечает за мониторинг сайта после запуска?

И, возможно, самое важное:

Что происходит, если цифры выглядят нормально три недели, а потом внезапно нет?

Этот вопрос меняет план миграции.

Потому что самая безопасная миграция не та, у которой самый длинный чек-лист.

Это та, где команда уже продумала, что может пойти не так, установила, как это будет обнаружено, и приняла сложные решения, пока ещё есть время их изменить.

Мы не считаем, что миграцию сайта нужно трактовать как технический сброс.

Сайт несёт историю.

Его URL несут историю. Его обратные ссылки несут историю. Его поисковая видимость несёт историю. Его языковая архитектура, внутренние ссылки и структурированные данные несут историю.

Новый сайт может выглядеть совершенно иначе.

Накопленная ценность за ним всё равно должна совершить это путешествие.

Готовишься к миграции сайта? Самое полезное время обнаружить техническую или структурную проблему, это до того, как новый сайт заработает. Наша Сессия технического due diligence создана именно для того, чтобы изучить существующую архитектуру, риски миграции и критические технические зависимости до того, как они станут дорогими проблемами.

Забронировать Сессию технического due diligence