Миграция сайта: как перенести без простоя и потери позиций

Окно простоя при переезде задается не скоростью копирования файлов, а значением TTL, которое вы поставили неделю назад. Внутри: 4 типа миграции и чем они отличаются, план переключения на 10 шагов, что сообщать Яндексу и Google, а что не нужно, и 7 ошибок, после которых трафик не возвращается.

Простой при переезде почти никогда не связан с самим переносом. Скопировать файлы и залить дамп базы — полчаса работы. Сайт лежит по другим причинам: кеш DNS у провайдеров живет ровно столько, сколько вы указали в TTL, а пока он расходится, часть посетителей попадает на старый сервер, часть на новый, и заказы раскладываются в 2 разные базы.

Полностью нулевого простоя не бывает. Но окно можно свести к нескольким минутам и сделать так, чтобы ни одна заявка не потерялась. Для этого нужны 3 вещи: заранее сниженный TTL, рабочая копия на новом сервере, проверенная до переключения, и короткая финальная синхронизация данных.

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

Сначала определите, какой из 4 переездов у вас

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

Смена хостинга — самый простой случай и единственный, где поисковики вообще не участвуют. Google в руководстве по смене хостинга отдельно оговаривает, что документ касается только переездов, не затрагивающих видимый URL. Все остальное — это уже переезд адреса, и там правила другие.

Часто переезды совмещают: новый сервер, новый домен и заодно новая CMS. Так делать не надо. Каждый слой добавляет свои поломки, и когда через неделю трафик проседает на 40%, вы не сможете сказать, что именно сломалось. Разносите по этапам: сначала инфраструктура, через 2–3 недели адрес.

Откуда берется простой

Источников ровно 3, и ни один из них не про скорость копирования файлов.

Кеш DNS. Когда вы меняете A-запись домена, провайдеры и браузеры не узнают об этом мгновенно. Они держат старый ответ столько секунд, сколько написано в поле TTL записи. Типовое значение у регистраторов — 3600 или 86400 секунд, то есть час или сутки. Все это время часть аудитории продолжает ходить на старый сервер.

Расхождение баз. Пока DNS расходится, сайт работает в 2 местах сразу. Заказ, оформленный на старом сервере через 10 минут после переключения, в новую базу не попадет. Для блога это ничего не значит. Для магазина это потерянные заказы и злой клиент.

Внешние привязки. Почта на домене, SSL-сертификат, вебхуки платежного шлюза, интеграция с 1С, cron-задачи, белые списки IP у партнеров. Все это привязано к старому серверу и после переключения просто перестает работать, причем тихо.

Отсюда простое следствие: день переключения — не начало работ, а их середина. Подготовка занимает неделю, и сокращать ее нельзя.

План переноса на другой хостинг

Порядок, при котором окно реального простоя укладывается в 5–15 минут, а данные не расходятся.

1. За 7 дней снизьте TTL. Поставьте у A-записей и CNAME значение 300 секунд. Google в своем руководстве советует сделать это минимум за неделю до переезда, чтобы старое большое значение успело истечь во всех кешах.
2. Разверните копию на новом сервере. Файлы, база, версии PHP и MySQL, расширения, права доступа. Версии должны совпадать с боевыми: переезд — плохой момент для одновременного обновления PHP.
3. Поднимите тестовый контур. Отдельное имя вида new.example.ru или доступ по IP с ограничением. Закройте его от индексации мета-тегом noindex или паролем, иначе в поиск попадет копия сайта.
4. Проверьте все, что не видно на главной. Формы, оплата, личный кабинет, выгрузка в 1С, отправка писем, загрузка файлов, поиск по каталогу, cron. Именно здесь обычно и вылезает разница в окружении.
5. Сверьте внешние сервисы. Почтовые MX-записи, SPF и DKIM трогать не нужно, если почта остается у прежнего провайдера, но проверить их состав до переключения обязательно. Письма с форм после переезда уходят с нового IP, и его репутация у почтовиков пустая — про это подробно в материале о том, почему письма с сайта уходят в спам.
6. Выпустите SSL-сертификат на новом сервере заранее. Проверить его до переключения DNS можно через локальную подмену в файле hosts.
7. Час X: закройте запись. Переведите сайт в режим, при котором новые заказы не принимаются: баннер «идут технические работы, заказ по телефону» на 15 минут дешевле, чем потерянная заявка.
8. Синхронизируйте дельту. Повторный rsync по измененным файлам и свежий дамп базы. Разница будет небольшой, импорт займет минуты.
9. Переключите DNS и снимите заглушку. Старый сервер не выключайте: он должен продолжать отдавать сайт, пока к нему идет трафик.
10. Мониторьте логи обоих серверов. Трафик на старом падает, на новом растет. Когда старый выходит на ноль по всем ботам и людям, можно отключать.

Команды для шагов 8 и 10 — минимальный набор, которым пользуемся мы в Design Lab.

# 1. Проверяем, какой TTL реально отдается по домену
dig +noall +answer example.ru A

# 2. Финальная синхронизация файлов (только изменения)
rsync -az --delete /var/www/example.ru/ deploy@203.0.113.10:/var/www/example.ru/

# 3. Дамп базы с блокировкой на время выгрузки
mysqldump --single-transaction --quick --routines --events \
  -u db_user -p example_db | gzip > /tmp/example_final.sql.gz

# 4. Проверяем новый сервер до переключения DNS, подменив адрес локально
curl -sI --resolve example.ru:443:203.0.113.10 https://example.ru/ | head -n 1

Четвертая команда — самая полезная и самая недооцененная. Она открывает сайт с нового сервера по боевому домену и боевому сертификату, не трогая DNS. Если здесь вернулось 200 OK, переключение будет скучным.

Что сообщать поисковым системам, а что нет

Короткий ответ: при смене хостинга — ничего. Адреса страниц не изменились, робот разницы не заметит, а заявка на переезд в такой ситуации просто не нужна. Google предупреждает лишь об одном побочном эффекте: сразу после смены инфраструктуры скорость обхода обычно временно падает, потом восстанавливается и может стать даже выше прежней.

Когда адрес меняется, работа делится на 2 части: редиректы на сервере и заявка в Вебмастере.

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

server {
    server_name old-example.ru www.old-example.ru;
    # Постраничный 301: путь и параметры сохраняются
    return 301 https://example.ru$request_uri;
}

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}

Заявка в Вебмастере. Оба адреса должны быть добавлены и подтверждены, содержимое сайтов должно совпадать, robots.txt на обоих доменах должен разрешать индексирование и быть одинаковым. Отдельная деталь, о которую спотыкаются чаще всего: на страницах нового сайта не должно быть атрибута rel="canonical", указывающего куда-то еще. Это первая причина в списке отказов справки Вебмастера.

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

Для Google при смене адреса используется инструмент «Изменение адреса» в Search Console. В руководстве по переезду с изменением URL он назван обязательным шагом при смене домена или поддомена. Отдельное требование там же: в Search Console должны быть подтверждены все варианты и старого, и нового сайта — с префиксом www и без него, по HTTP и по HTTPS.

Переход на HTTPS: переезд, который многие не считают переездом

Смена протокола меняет адрес сайта. Робот Яндекса видит http://example.ru и https://example.ru как 2 разных сайта, и до склейки они конкурируют между собой в выдаче: один из адресов теряет трафик и не занимает нужных позиций.

Порядок из справки Вебмастера: получить и установить сертификат, проверить его через «Проверку ответа сервера», перевести на HTTPS все внутренние ссылки и подключаемые файлы, поправить адреса в sitemap и ссылку на sitemap в robots.txt, поставить редирект, добавить обе версии в Вебмастер и включить опцию «Добавить HTTPS».

Пункт про внутренние ссылки выглядит формальным, но именно он ломает сайты: одна картинка или один скрипт, подключенный по HTTP, — и браузер перестает считать страницу безопасной, а посетитель видит предупреждение. Самое надежное решение — сделать внутренние ссылки относительными, без указания домена: /page/ вместо http://example.ru/page/.

Хорошая новость по HTTPS отдельная: ИКС при таком переезде переносится, хотя значение обновляется не мгновенно, а исследования Яндекса, по его же словам, показывают, что при соблюдении рекомендаций трафик не теряется. Для смены домена таких гарантий справка не дает.

Смена CMS: единственный переезд, где трафик теряют по-настоящему

Здесь меняются все адреса сразу, и работает правило: сколько страниц вы не сопоставили — столько и потеряли.

Рабочий порядок такой. Выгрузите полный список индексируемых URL старого сайта: из sitemap, из «Страниц в поиске» Вебмастера, из логов сервера за 3 месяца и из отчета по посадочным страницам Метрики. Объедините в одну таблицу, отсортируйте по числу переходов из поиска. Дальше для каждого адреса из верхней части списка должен быть ответ: какой URL нового сайта его заменяет.

Частный случай такого переезда — переход на 1С-Битрикс с другой CMS: там к карте адресов добавляется перенос каталога в инфоблоки, и он разобран отдельно. Страницы, которым замены нет, — отдельное решение для каждой: либо редирект на ближайший по смыслу раздел, либо честная 404. Массовый редирект несопоставленных страниц на главную работает хуже, чем 404: для поисковика это сигнал, что содержимое пропало, а пользователь получает не то, что искал.

Что переносится вместе со страницей и о чем забывают: заголовки H1, title и description, тексты целиком, микроразметка, alt у картинок, даты публикации, страницы пагинации и фильтров, если они участвовали в поиске. Новый шаблон с другим текстом на той же теме — это не перенос страницы, это новая страница, и ранжироваться она начнет с нуля.

Если речь о переезде на 1С-Битрикс, часть работы закрывается штатными средствами платформы: резервная копия из админки и служебный скрипт восстановления разворачивают сайт на новом хостинге без ручной возни с дампами. Но это относится к переносу самой системы, а таблицу соответствия URL все равно придется собирать руками — это часть проекта разработки сайта на 1С-Битрикс, а не разовая операция сисадмина.

7 ошибок, которые превращают переезд в аварию

• TTL не снижали. Переключение растягивается на сутки, и все это время база расходится. Самая частая и самая дорогая ошибка.
• robots.txt приехал с тестового контура. С Disallow: / внутри. Сайт выпадает из поиска за несколько дней, а заметят это через 2 недели по трафику.
• Редирект со всех страниц на главную. Делается одной строкой в конфиге и выглядит аккуратно. Стоит потери позиций по всем внутренним страницам.
• Забыли про почту. При смене хостинга вместе с A-записью иногда меняют весь набор DNS-записей, и MX уезжают в никуда. Заявки с сайта перестают доходить молча.
• Не перенесли cron. Выгрузка остатков из 1С, отправка писем из очереди, чистка кеша, автоматические бэкапы. На новом сервере их просто нет.
• Потеряли подтверждение прав в Вебмастере и Search Console. Файл подтверждения или мета-тег остались в старой сборке. Права слетают в момент, когда они нужнее всего.
• Старый сервер выключили в тот же день. Пока DNS расходится, часть посетителей и роботов идет туда. Отключать можно только когда логи старого сервера показали ноль.

Первые 72 часа после переключения

Сразу после переключения проверяются 4 вещи: сайт отдает 200 на главной и на 10 ключевых внутренних страницах, форма доходит до почты, оплата проходит тестовым платежом, сертификат валиден без предупреждений браузера.

В первые сутки смотрите логи обоих серверов и коды ответов. Всплеск 500-х на новом сервере обычно означает нехватку прав на папки загрузок или не тот модуль PHP. Всплеск 404-х — что переехали не все файлы.

На второй-третий день подключается поисковая часть: отчет «Страницы в поиске» в Вебмастере, статистика обхода, уведомления о смене главного адреса. Если переезжали с изменением адреса, отправьте sitemap с новыми URL и проверьте ответ сервера по нескольким старым адресам — редирект должен возвращать 301, а не 302 и не цепочку из 3 переходов.

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

Если переезд уже назначен

Сделайте 3 вещи прямо сейчас, до всякого планирования. Посмотрите текущий TTL у своего домена — если там 86400, снижайте сегодня, иначе окно переключения растянется на сутки. Выгрузите список страниц, которые дают вам трафик из поиска: он понадобится и при смене CMS, и при смене домена, и просто как точка отсчета. Проверьте, что у вас есть свежая резервная копия, которую вы умеете разворачивать, а не просто файл на диске.

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