Короткий ответ
Миграция — это четыре разные работы под одним названием, и ломаются они независимо. Разбираем инвентаризацию, карту старых и новых адресов, редиректы, формы и интеграции, окно переключения и план отката, который пишут заранее.
Что на самом деле переносится при миграции: Миграция — это четыре независимые работы: адреса,…
Перенос сайта на новую платформу — это четыре разные работы под одним названием: адреса, которые уже знают люди и поисковые системы; контент и медиафайлы; данные форм и интеграций; и инфраструктура, на которой сайт живёт. Они ломаются независимо, и у каждой должен быть свой план.
Основной ущерб от неудачного переноса не виден в день запуска. Новый сайт выглядит правильно, его принимают; потери проявляются через две недели — страницами, которые больше не открываются, формой, переставшей доставлять письма, и аналитикой, начавшейся с нуля без возможности сравнения.
Способ этого избежать выглядит скучно. Записать, что есть, до того как что-то менять; решить, куда переезжает каждый пункт; и проверить список после переключения, а не полагаться на ощущение, что всё работает.
Дальше — этот список по порядку, план отката, который пишут до того, как он понадобится, и место миграции в пакетах с фиксированными ценами, включая тот, в который эта работа прямо не входит.
Инвентаризация: запишите, что есть, до любых изменений
Начните с полного списка адресов текущего сайта. Выгрузите его из карты сайта, из логов сервера, из аналитики и из обхода сайта краулером, а затем объедините четыре источника. Любой по отдельности что-то пропустит, и пропускает он обычно старые страницы, на которые всё ещё заходят.
Добавьте, чем является каждый адрес: страницей, файлом, уже существующим редиректом или чем-то, что и сегодня отдаёт ошибку. Про адреса, сломанные до переезда, полезно знать заранее, потому что после переезда любая неисправность выглядит следствием миграции.
Медиафайлы инвентаризируйте отдельно — изображения, документы, видео — с указанием папки. Пути к медиа при смене платформы меняются чаще, чем пути к страницам, а переставший открываться документ заметить труднее, чем пропавшую страницу.
Наконец, перечислите интеграции: что отправляет почту, что принимает заявки, что читает и пишет данные, что подгружает скрипт на страницу. Именно этот список чаще всего держат в голове, и именно поэтому его место в файле.
Карта адресов: один старый адрес — один новый
Главный документ миграции — таблица из двух колонок: слева каждый старый адрес, справа тот, который его заменяет. Составлять её нудно, и именно она решает, останется переезд незаметным для посетителей или нет.
По каждой строке нужно решение, и вариантов всего три: страница продолжается по новому адресу, страница сливается с другой, страница уходит. Убрать страницу — законный выбор; оставить строку пустой — нет, потому что пустые строки превращаются в страницы ошибки.
Не поддавайтесь желанию отправить всё сомнительное на главную. Посетитель, нажавший на конкретную статью и попавший на главную, получил тупик с приветливым лицом, а поисковые системы читают этот приём как мягкий отказ, а не как переезд.
Храните карту файлом в репозитории, а не таблицей в чьей-то почте. Это тот документ, который вы будете перечитывать при проверках после переключения и ещё раз через год, когда кто-нибудь спросит, почему старый адрес ведёт себя именно так.
Редиректы и то, что редирект не чинит
Постоянный редирект сообщает браузеру и краулеру, что страница переехала насовсем. Реализуйте карту постоянными редиректами, а не временными, если переезд действительно не временный: их обрабатывают по-разному, и разница не косметическая.
Цепочки — тихая плата. Адрес, ведущий на адрес, который ведёт дальше, работает, но для каждого посетителя он медленнее, а как сигнал — слабее. Разложите цепочки так, чтобы каждый старый адрес указывал сразу на конечный.
Редиректы не чинят ссылки внутри вашего же контента. Текст страницы, ссылающийся на старый внутренний адрес, продолжит работать через редирект, но теперь он платит за лишний переход. Перепишите внутренние ссылки на новые цели в рамках переезда.
И редирект ничего не делает с внешними ссылками, которыми вы не управляете. Это довод в пользу сохранения старой структуры адресов везде, где это разумно: каждый сохранённый адрес — ссылка, которую не нужно перенаправлять, и на одну возможную ошибку меньше.
Контент и медиа: часть больше, чем кажется
Контент редко переезжает между платформами чисто. Форматирование хранится иначе, встроенные медиа ссылаются иначе, а поля, существующие в одной системе, в другой не имеют места. Закладывайте время на проверку того, что приехало, а не только на сам перенос.
Проверяйте выборку по-настоящему, а не пробегайте глазами всё. Возьмите десяток страниц разных типов — длинную статью, карточку товара, страницу с таблицей, страницу со встроенным видео — и прочитайте их на новой платформе целиком.
Медиа требует отдельного прохода. Убедитесь, что файлы перенесены, что их адреса покрыты картой и что альтернативные описания пережили переезд. Alt-текст часто лежит в поле, у которого на новой платформе нет аналога, и молча теряется — это и регресс по доступности, и потеря контента; практическим стандартом для проверки служит краткий справочник W3C по WCAG 2.2.
Заодно исправьте вес изображений, раз файлы всё равно двигаются. Документация MDN по производительности — честный ориентир по тому, что здесь действительно имеет значение, а миграция — единственный момент, когда прикоснуться к каждой картинке почти ничего не стоит дополнительно.
Формы, интеграции и отказы, которые молчат
Сломанная страница заявляет о себе сама. Сломанная форма — нет: она принимает отправку, благодарит посетителя и доставляет сообщение в никуда. Это отказ, который обходится дороже всего и обнаруживается позже всего.
Проверьте каждую форму настоящей отправкой и убедитесь, что она дошла до всех адресатов, до которых должна, — до почты, до CRM, до канала уведомлений. Проверьте ещё раз после смены DNS: доставка писем особенно способна вести себя иначе, когда домен переехал.
Перечислите сторонние скрипты, которые загружал старый сайт, и по каждому примите осознанное решение. Миграция — разумный момент убрать те, назначение которых никто не может назвать; каждый оставшийся — это запрос, за который страница платит при каждом визите.
Там, где данные ходят в обе стороны — остатки, заказы, записи, — запланируйте период, когда обе стороны можно проверить на настоящих записях до отключения старой системы. Односторонняя проверка подтверждает половину интеграции и создаёт уверенность во второй половине без доказательств.
Аналитика: как сохранить читаемую историю
Решите до переключения, будет ли новый сайт писать в тот же ресурс аналитики или в новый. Сохранение ресурса сохраняет историю, но смешивает две разные структуры сайта в одном наборе данных; новый ресурс даёт чистые данные и лишает сравнения.
Что бы вы ни выбрали, отметьте дату. Пометка в день переключения — то, что не даст будущему читателю принять смену платформы за смену рынка, и добавляется она за минуту.
Перепроверьте, что нужные вам события по-прежнему срабатывают. Отправка формы, покупка, скачивание, нажатие на номер телефона обычно реализуются кодом, привязанным к странице, — а именно этот код смена платформы и переписывает.
Ожидайте, что первые дни после миграции будут выглядеть странно, и дайте цифрам время до выводов. Краулеры перепроверяют переехавший сайт в своём темпе, а реакция на показатели первой недели обычно порождает правки, которые потом приходится откатывать.
DNS, сертификаты и окно переключения
Само переключение — это изменение DNS: домен перестаёт указывать на старый сервер и начинает указывать на новый. Снизьте время жизни записи за сутки, чтобы изменение разошлось быстро, и верните прежнее значение, когда переезд устоится.
Сертификат должен быть выпущен и проверен на новой платформе до переключения, а не после. Сайт, который открывается, но выдаёт предупреждение безопасности, хуже сайта, ненадолго недоступного: браузеры делают это предупреждение громким, а посетители читают его как взлом.
Не трогайте почтовые записи, не проверив их. Почта и сайт часто делят домен и редко делят провайдера, и миграция, случайно утащившая почтовые записи за собой, кладёт тот адрес, на котором бизнес отвечает.
Выбирайте окно осознанно. Самые тихие часы для вашей аудитории при том, что люди, способные действовать, ещё не спят, лучше технически удобного времени, когда прочитать первые проверки некому.
Видимость в поиске: чего ждать и за чем следить
Хорошо размеченная миграция обычно даёт короткий неустойчивый период, а не длительное падение, но честный ответ таков: размер колебания зависит от того, насколько изменилась структура адресов и насколько полно карта её покрывает.
Отправьте новую карту сайта и оставьте старую доступной на время, чтобы краулеры нашли переехавшие адреса. В первые две недели смотрите на отчёты об ошибках, а не на отчёты о позициях: рост числа недоступных страниц — повод действовать, колебание позиций обычно нет.
Проверьте, что страницы не закрыты остатками служебных настроек. Тестовые окружения принято закрывать от краулеров, и правило, написанное для защиты тестового сайта, не в одном проекте уехало в продакшен и тихо убрало его из поиска.
Держите карту под рукой весь этот период. Почти любая проблема, о которой сообщат в первый месяц, сводится к её строке — пустой, указывающей не на ту страницу или написанной с опечаткой.
План отката, написанный заранее
До переключения запишите, как вернуться назад: какие DNS-записи восстановить, сколько времени остаётся доступным старое окружение, кто вправе принять решение и какое состояние его оправдает. Трёх предложений достаточно, и они меняют ощущение от всего дня.
Оставьте старый сайт работающим и доступным в фоне на заранее названный срок. Это стоит одного лишнего месяца хостинга и составляет разницу между плохим днём и плохой неделей.
Ничего не удаляйте в день переключения. Базы, папки с медиа и старая конфигурация должны пережить переезд на срок, названный заранее, потому что пропавшее обычно заявляет о себе после первой полной недели трафика.
Назовите в плане того, кто принимает решение. Решения об откате, принятые группой, в спешке и на неполных данных, — это способ превратить поправимую проблему в две миграции вместо одной.
Проверки до переключения и проверки после
До переключения прогоните новый сайт по тем же проверкам, которые будете делать после: открывается каждый шаблон, отправляются формы, работает поиск, страницы грузятся на телефоне, структура адресов совпадает с картой. На тестовом окружении это снимает большую часть сюрпризов.
После переключения прогоните саму карту. Запросите каждый старый адрес и запишите, что он вернул. Это скрипт, а не вечер кликанья, и он превращает вопрос «сработала ли миграция» в список строк, которые не сработали.
Проверьте страницы, о которых легко забыть: юридические, доступные только из подвала, файлы из почтовой рассылки и всё, чей адрес был написан руками, а не сгенерирован.
И проверьте ещё раз через неделю. Часть отказов проявляется только после того, как истекут кэши и вернутся краулеры, а второй проход по тому же списку — дешёвый способ поймать их, пока контекст ещё свеж.
Где миграция находится в пакетах VITON13
Об объёме стоит сказать прямо, потому что миграцию нередко оценивают как мелкую правку. Site Fix Pack стоит $70 и занимает 1-2 рабочих дня на не более чем пять согласованных правок, с проверкой на мобильном и десктопе, списком «до/после» при сдаче и одним кругом правок — и переносы в него прямо не входят.
Переезд, порождающий новый сайт, относится к пакету «Сайт для запуска» — $380 за 3-5 рабочих дней: адаптивная сборка, подключение базовой CMS или данных и настройка развёртывания, два круга правок до запуска; контент и переводы даёте вы. Launch Site Express — $520: тот же объём в приоритетной очереди за 2 рабочих дня с ежедневными сборками, чек-листом запуска и созвоном при передаче, один круг правок после первой полной сборки, без контента, съёмки и последующей поддержки.
Когда переезд ещё и меняет то, что продукт делает — новые функции, новая логика состояний и маршрутов, тестирование и укрепление, — это «Разработка продукта»: $880 за 2-3 недели с двумя кругами правок на каждую поставленную функцию, а нативные мобильные приложения и лицензирование платежей остаются за рамками.
Недели после переключения — как раз то место, где нужна «Постоянная техническая поддержка»: $290 в месяц помесячным циклом с уведомлением за 30 дней о прекращении, приоритетные обновления, недельный ритм релизов и техническое сопровождение; объём согласуется в начале каждого цикла, а новая сборка или редизайн оцениваются отдельно.
Практический чеклист
- Соберите список адресов из карты сайта, логов, аналитики и обхода краулером и объедините источники.
- Составьте таблицу «старый адрес — новый адрес» и не оставляйте пустых строк.
- Разложите цепочки редиректов так, чтобы каждый старый адрес вёл сразу на конечный.
- Отправьте настоящую заявку через каждую форму и проверьте все адресаты после смены DNS.
- Снизьте TTL за сутки и выпустите сертификат на новой платформе до переключения.
- Запишите план отката и срок, в течение которого старое окружение остаётся доступным.
Вопросы и ответы
Потеряет ли сайт позиции при переезде на новую платформу?
Хорошо размеченная миграция обычно даёт короткий неустойчивый период, а не длительное падение. Размер колебания зависит от того, насколько изменилась структура адресов и насколько полно её покрывает карта редиректов; поэтому карта и есть основная защита.
Входит ли перенос сайта в пакет мелких правок?
Нет. Site Fix Pack стоит $70 за 1-2 рабочих дня на до пяти согласованных правок, и переносы в него прямо не входят. Переезд, порождающий новый сайт, относится к пакету «Сайт для запуска» — $380 за 3-5 рабочих дней, либо к Launch Site Express за $520 за 2 рабочих дня.
Можно ли отправить все старые адреса на главную страницу?
Технически можно, но это плохое решение. Посетитель, нажавший на конкретную статью и попавший на главную, получает тупик, а поисковые системы читают массовое перенаправление на главную как мягкий отказ, а не как переезд.
Сколько держать старый сайт после переключения?
Назовите срок заранее и не удаляйте ничего в день переключения. Базы, папки с медиа и старая конфигурация должны пережить переезд на заявленный период: пропавшее обычно обнаруживается после первой полной недели трафика.
Что чаще всего ломается незаметно?
Формы и интеграции. Форма принимает отправку, благодарит посетителя и доставляет сообщение в никуда. Проверяйте каждую форму настоящей отправкой до и после смены DNS и убеждайтесь, что заявка дошла до всех адресатов — почты, CRM и канала уведомлений.