Когда нужен перенос сайта и что именно рискует
Трафик теряется не от самого факта переезда, а от того, что старые адреса перестают отвечать так, как их запомнил поиск. Робот приходит на знакомый URL и получает 404, цепочку из трёх редиректов или страницу с чужим canonical. Дальше страница выпадает из индекса, а вместе с ней уходят запросы, по которым она собирала трафик.
Миграция сайта бывает разной по цене ошибки. Перенос сайта на другой хостинг при сохранении домена и структуры — самый спокойный сценарий. Смена CMS и смена домена одновременно — самый тяжёлый: меняются и адреса, и разметка, и шаблоны, и сервер. Я всегда стараюсь разделить такие изменения по времени, чтобы при просадке было понятно, какая именно часть виновата.
Перед стартом мы фиксируем, что меняется, а что остаётся неизменным. Этот список — основа всей дальнейшей работы: он определяет, нужна ли карта соответствия адресов, сколько редиректов придётся написать и какие шаблоны надо проверять руками.
| Тип переезда | Что меняется | Главный риск |
|---|---|---|
| Перенос сайта на другой хостинг | Сервер, IP, конфигурация | Медленный отклик, обрыв доступности, потеря правил в .htaccess или nginx |
| Перенос сайта на новый домен | Домен, все адреса | Незакрытые редиректы, старый домен в sitemap и внутренних ссылках |
| Смена CMS (перенос сайта на Битрикс или WordPress) | Структура URL, шаблоны, разметка | Новые слаги, дубли пагинации, пропавшие метатеги и микроразметка |
| Редизайн сайта | Вёрстка, тексты, навигация | Потеря контента и внутренних ссылок, скрытые блоки, рост времени загрузки |
Чек-лист до переезда: аудит, карта URL, эталонные метрики
Подготовка занимает больше времени, чем само переключение, и именно она определяет результат. Сначала снимаю полный слепок текущего состояния: краулинг всех доступных адресов, выгрузка страниц из Яндекс Метрики и из панелей вебмастеров, список запросов с показами, карта внутренних ссылок. Это эталон, с которым я буду сравнивать сайт после переезда.
Дальше собираю карту URL — таблицу соответствия «старый адрес → новый адрес» для всех страниц, которые приносят трафик или имеют внешние ссылки. Если страниц много, приоритет отдаю каталогу, категориям, карточкам и статьям с показами. Точка входа в подготовку — SEO-аудит сайта, он же показывает технические проблемы, которые лучше не тащить на новую платформу.
- Полный краул старого сайта: коды ответов, title, description, h1, canonical, robots-meta
- Выгрузка страниц с трафиком за 12 месяцев и списка запросов с показами
- Эталонные метрики: визиты и конверсии по разделам, число страниц в индексе, скорость загрузки
- Карта URL со всеми соответствиями и отдельный список адресов, которым нет замены
- Инвентаризация внешних ссылок на важные страницы
- Список страниц с микроразметкой, фидами и интеграциями, которые надо перенести
- Доступы: хостинг, DNS, панели вебмастеров, аналитика, репозиторий
- Резервная копия старого сайта и план откату, если переключение пойдёт не так
Если карту URL не собрать заранее, после переезда придётся восстанавливать её по 404-м из логов. Это работает, но дороже и дольше.
Редиректы 301 и типовые ошибки
Редирект 301 — основной инструмент переезда. Его задача проста: каждый старый адрес отвечает одним переходом на релевантный новый адрес. Не на главную, не на общий раздел, а на страницу с тем же смыслом. Массовый редирект всего на главную — самый частый способ обнулить результаты нескольких лет работы.
Правила пишу шаблонами там, где структура предсказуема, и поштучно там, где слаги менялись вручную. После настройки прогоняю весь список адресов из карты URL и проверяю не только конечный код ответа, но и длину цепочки. Механику проверки я разбирал в статье как я проверяю редиректы и canonical, а быстро прогнать список адресов можно через проверку редиректов и canonical.
Отдельно проверяю согласованность: редирект ведёт на страницу, у которой canonical указывает на неё саму, она открыта в robots.txt и присутствует в sitemap. Конфликт этих четырёх сигналов — вторая по частоте причина проблем после переезда.
| Ошибка | Как проявляется | Что делаю |
|---|---|---|
| 302 вместо 301 | Поиск не склеивает адреса, старые страницы держатся в индексе | Меняю тип редиректа на постоянный |
| Цепочки из 2–4 переходов | Замедляется обход, часть сигналов теряется | Переписываю правила так, чтобы был один переход |
| Редирект на главную | Нерелевантные страницы, резкое падение по внутренним запросам | Подбираю ближайший по смыслу аналог, при отсутствии — 404 или 410 |
| Циклы и петли | Страница не открывается, браузер выдаёт ошибку | Разбираю порядок правил, разделяю шаблоны по приоритету |
| Редирект на страницу с чужим canonical | Поиск выбирает третий адрес | Привожу canonical к самореферентному виду |
Что ломается чаще всего
Список повторяется из проекта в проект и почти не зависит от платформы. Новая CMS генерирует адреса по своим правилам, и то, что раньше было продуманной структурой, превращается в набор технических URL.
Поэтому после переключения я прохожу не только по карте URL, но и по шаблонам: одна сломанная категория в шаблоне означает десятки или сотни битых страниц.
- Слаги: транслитерация по другим правилам, добавленные ID, пропавшие или появившиеся слэши в конце адреса
- Пагинация: вторые и третьи страницы отдают 404, либо все страницы получают canonical на первую и теряют товары из индекса
- GET-параметры: фильтры и сортировки открываются к индексации и создают тысячи дублей
- Canonical: захардкоженный старый домен, ссылки на тестовый поддомен, canonical на несуществующий адрес
- Sitemap: не обновился, содержит старые адреса, закрытые страницы или редиректы
- robots.txt: с тестового контура перенесён запрет Disallow: /, закрыты скрипты и стили
- Метатеги и микроразметка: title собираются шаблоном без учёта старых настроек, Schema.org не переехала
- Внутренние ссылки и изображения: абсолютные URL со старым доменом в текстах и баннерах
Как контролировать первые 4–8 недель
Переезд не заканчивается в день переключения. Поиску нужно время, чтобы обойти сайт, склеить адреса и пересобрать индекс. В это время нормально видеть колебания трафика и позиций — ненормально видеть устойчивое снижение без признаков восстановления.
Первую неделю смотрю сайт ежедневно, дальше — раз в два-три дня, к концу второго месяца сравниваю показатели с эталонными метриками, снятыми до переезда. Крупные правки по структуре и текстам в этот период я не делаю: иначе непонятно, что повлияло на динамику.
- Серверные логи и отчёты об обходе: какие адреса запрашивают роботы и какие коды получают
- Число страниц в индексе и статусы исключённых страниц по причинам
- 404 и 5xx в панелях вебмастеров — каждый новый адрес разбираю и добавляю в карту URL
- Динамика показов и кликов по разделам, а не только суммарный трафик
- Скорость ответа сервера и Core Web Vitals на новой платформе
- Работа форм, корзины и передачи заявок — техническая просадка конверсии заметна не сразу
Средний срок стабилизации при аккуратном переезде — от двух до восьми недель, на больших каталогах дольше. Это зависит от того, как быстро робот обойдёт все адреса.
Вопросы про формат работы
Насколько упадёт трафик при переносе сайта на новый домен?
При аккуратной подготовке колебания обычно укладываются в несколько недель, после чего показатели возвращаются к прежнему уровню. Гарантировать отсутствие просадки не может никто: решение о склейке адресов принимает поиск. Моя задача — убрать технические причины, из-за которых просадка становится затяжной.
Можно ли перенести сайт без потери трафика, если он на конструкторе?
Можно, но с ограничениями. На многих конструкторах нет доступа к серверным настройкам, поэтому редиректы приходится делать средствами платформы или через промежуточный слой. Перед оценкой я проверяю, какие возможности даёт текущая площадка и какие адреса удастся сохранить.
Что выбрать: перенос сайта на Битрикс или на WordPress?
С точки зрения переезда разницы почти нет: важна не платформа, а возможность сохранить прежние адреса и метатеги. Битрикс чаще выбирают под интеграции с 1С и сложный каталог, WordPress — под контентные проекты и небольшие магазины. Решение принимаем по задачам бизнеса, а не по SEO.
Нужно ли закрывать новый сайт от индексации до переезда?
Тестовый контур — да, закрывать обязательно, иначе в индекс попадут дубли. Но главная ошибка обратная: запрет с тестового сервера переносят на боевой и оставляют. Снятие запрета и проверка robots.txt — отдельный обязательный пункт в день переключения.
Мы уже переехали и потеряли трафик. Поможете?
Да, разбор постфактум — частая задача. Восстанавливаю карту URL по логам, аналитике и архивам, нахожу битые адреса, цепочки редиректов и конфликты canonical, затем закрываю правки по приоритету трафика. Чем раньше начать, тем больше страниц ещё держится в индексе.
Если переезд ещё только планируется, начните с короткого разговора и SEO-аудита: по его итогам я скажу, какие адреса надо сохранить, что переделать до переключения и нужна ли вам отдельная услуга вообще. Если сайт уже переехал и трафик просел — присылайте домены, старый и новый, вместе с датой переключения, и я начну с проверки редиректов и canonical.