1. До переноса сохранить baseline

Перед релизом я выгружаю индексируемые URL, органические landing pages, запросы, клики/показы, конверсии, важные внешние ссылки и текущие HTTP/canonical. Это не бюрократия: без baseline после миграции невозможно быстро отличить нормальную переиндексацию от реальной потери.

2. Сделать URL mapping один-к-одному там, где это возможно

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

Если эквивалента нет и контент действительно удалён, иногда честный 404/410 корректнее нерелевантного редиректа.

3. Прокраулить staging как новый сайт

До запуска нужно увидеть будущую структуру: 200/3xx/4xx, canonical, noindex, robots, sitemap, внутренние ссылки, hreflang при наличии, метаданные и рендеринг. Важно, чтобы staging был закрыт от индексации, но доступен аудитору.

Я отдельно проверяю, что внутренние ссылки уже ведут на конечные новые URL и не создают цепочек редиректов.

4. После запуска мониторить сегментами

Сразу после переключения повторяется crawl, проверяются redirects и sitemap, затем наблюдаются поисковые данные. Я сравниваю типы страниц: категории, услуги, статьи, карточки — общий график может скрыть проблему одного важного шаблона.

При крупном переносе полезно вести журнал дат: DNS, релиз, изменение robots/sitemap, исправления после QA.

Авторский чек-лист

Что проверяет Владимир Николаев

  1. Зафиксировать baseline органических URL и конверсий.
  2. Сделать таблицу old URL → new URL → expected status.
  3. Проверить staging отдельным crawl.
  4. Убрать redirect chains из внутренних ссылок.
  5. После запуска сравнивать шаблоны, а не только общий трафик.
Граница рекомендации: Даже технически правильная миграция может сопровождаться временной волатильностью. Цель — минимизировать неопределённость и быстро находить реальные ошибки.