Перенос сайта на CMS | Инструкция по переезду

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

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

Когда переезд оправдан, а когда его лучше отложить

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

Ситуация	Переезд оправдан	Почему
Движок самописный, разработчик недоступен	Да	Любая правка требует поиска специалиста и стоит дороже переезда
Нет доступа к метатегам, адресам, файлу robots	Да	Без этих настроек продвижение упирается в потолок
Система не обновляется, есть известные уязвимости	Да	Взлом обойдётся дороже плановой миграции
Нужны функции, которых в платформе нет в принципе	Да	Костыли поверх ограничений живут плохо и ломаются при обновлениях
Сайт медленный из-за тяжёлого шаблона	Скорее нет	Скорость чаще чинится оптимизацией шаблона и изображений
Нравится дизайн другой системы	Нет	Дизайн меняется без смены движка
Позиции упали, причина не установлена	Нет	Сначала диагностика: переезд на фоне проблемы смешает причины
Так посоветовал новый подрядчик	Нет, пока не обоснует	Перевод сайта на знакомую подрядчику систему — его удобство, а не ваша выгода

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

Подготовка: полный слепок текущего сайта

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

• Полный список адресов. Выгрузка из панелей вебмастеров плюс обход краулером. Два источника нужны потому, что краулер находит только связанные ссылками страницы, а в индексе бывают адреса, на которые внутренних ссылок уже нет.
• Метатеги всех страниц. Заголовок и описание построчно, в таблице с адресами. Теряются при переносе чаще всего именно они.
• Заголовки в содержании. Структура h1–h3 по каждой странице: при смене шаблона она нередко съезжает.
• Тексты и изображения с подписями. Атрибут alt у изображений — то, что при автоматическом переносе слетает почти всегда.
• Позиции по ключевым запросам. Съём до переезда, иначе после падения вы не докажете даже себе, что было раньше.
• Трафик по разделам за год. Именно за год, а не за месяц: сезонность легко принять за последствия переезда.
• Список входящих ссылок. Страницы с внешними ссылками — приоритет номер один при настройке перенаправлений.
• Текущий файл robots.txt и карта сайта. Пригодятся как образец и как способ найти забытые разделы.
• Настройки аналитики и целей. Скриншоты или выгрузка: цели после переезда часто перестают срабатывать, потому что изменились адреса или классы кнопок.
• Резервная копия базы и файлов. Полная, проверенная на разворачивание, а не просто лежащая на сервере.

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

Карта URL — главный документ переезда

Таблица соответствия старых и новых адресов — то, вокруг чего строится вся работа. Без неё перенаправления делаются на глазок, и часть страниц теряется молча.

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

Если адреса меняются, таблица заполняется по такому формату.

Столбец	Что в нём	Зачем нужен
Старый адрес	Полный путь как в индексе	Основа правила перенаправления
Новый адрес	Путь на новой системе	Цель перенаправления
Трафик за год	Число визитов из поиска	Приоритет проверки после запуска
Внешние ссылки	Есть или нет	Такие страницы нельзя терять ни при каких условиях
Тип страницы	Категория, статья, товар, служебная	Позволяет составить правила группами, а не поштучно
Решение	Переносим, объединяем, удаляем	Фиксирует, что делать со страницей
Статус проверки	Отметка после запуска	Не даёт потерять страницы при массовой проверке

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

Смежный материал по теме — «Бесплатное продвижение сайта в поисковиках».

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

Перенос контента, метатегов и изображений

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

Что проверяется после импорта в первую очередь:

1. Заголовки страниц и описания. Сверяйте с выгрузкой, сделанной на этапе подготовки. Частая картина: описания не перенеслись вообще, и система сгенерировала их автоматически.
2. Единственный h1 на странице. При смене шаблона бывает, что заголовок дублируется — один из шаблона, второй из содержания.
3. Изображения и атрибуты alt. Картинки могут перенестись файлами, а подписи потеряться. Проверяется выборочно по десятку страниц.
4. Внутренние ссылки в текстах. Если адреса изменились, все ссылки внутри статей ведут на старые пути. Их правят массовой заменой в базе, а не руками.
5. Таблицы и списки. Конвертеры часто разваливают сложную разметку в сплошной текст.
6. Структурированные данные. Разметка организации, хлебных крошек, товаров переносится редко и обычно настраивается заново.
7. Кодировка и спецсимволы. Кавычки, тире и неразрывные пробелы после импорта иногда превращаются в мусор.

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

Техническая настройка нового сайта

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

Перед запуском проверяется набор технических элементов.

• Файл robots.txt. Переписан под новую структуру, служебные разделы закрыты, запрет на индексацию всего сайта снят.
• Карта сайта. Генерируется автоматически, содержит только новые адреса, отдаёт корректные даты изменения.
• Канонические адреса. Формируются без параметров, каждая страница указывает на себя.
• Протокол и версия домена. Один вариант основной, остальные перенаправляются: с www на без www или наоборот, с http на https.
• Обработка ошибок. Несуществующая страница отдаёт код 404, а не 200 с текстом об ошибке — это разные вещи, и вторая создаёт бесконечное количество мусорных страниц.
• Скорость загрузки. Сжатие изображений, кэширование, отложенная загрузка скриптов. Новый шаблон часто тяжелее старого.
• Мобильная версия. Проверяется не на одном экране, а на нескольких размерах, включая узкие.
• Счётчики аналитики. Установлены, цели пересозданы под новые адреса и новые классы кнопок.
• Формы обратной связи. Проверены отправкой тестовой заявки, письма доходят до почты.
• Структурированные данные. Настроены заново и проверены инструментом валидации.

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

Редиректы: как настроить без цепочек и потерь

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

Если нужны детали, смотрите «Самостоятельное SEO продвижение сайта».

Ошибка	Что происходит	Как правильно
Временное перенаправление вместо постоянного	Система считает переезд обратимым и держит старый адрес в индексе	Только постоянное перенаправление
Цепочка из нескольких переходов	Часть сигналов теряется, обход замедляется	Свести к одному переходу, обновив исходные правила
Перенаправление всех страниц на главную	Расценивается как ошибка, страницы просто исключаются	Каждый адрес ведёт на ближайший по смыслу
Перенаправление на страницу с другим содержанием	Человек не находит то, зачем пришёл, и уходит	Совпадение по смыслу важнее совпадения по структуре
Забытые адреса с параметрами и слэшем в конце	Дубли и ошибки у части посетителей	Правила пишутся с учётом вариантов написания
Отключение перенаправлений через месяц	Все накопленные сигналы обнуляются	Держать не меньше года, а лучше постоянно

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

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

День переезда: порядок действий

Запуск делают в период низкой посещаемости — обычно это ночь или выходной, но выбирать надо по вашей статистике, а не по общему правилу.

1. Сделать свежую резервную копию старого сайта. Файлы и база, проверенные на разворачивание.
2. Перенести новый сайт на боевой адрес. Способ зависит от хостинга: смена корневой папки, перенос файлов или переключение домена.
3. Снять запрет на индексацию. Проверить и файл robots.txt, и настройку видимости в самой системе — это два разных места, и забывают обычно второе.
4. Включить перенаправления. Проверить работу на десятке адресов вручную, затем прогнать полный список.
5. Проверить главные страницы. Тот самый список из двадцати-тридцати страниц с трафиком.
6. Отправить новую карту сайта. В обеих панелях вебмастеров, старую при этом удалить.
7. Запросить переобход ключевых страниц. Главная, разделы верхнего уровня, страницы услуг.
8. Проверить работу форм и целей. Отправить тестовую заявку, убедиться, что письмо пришло и цель засчиталась.
9. Проверить скорость и мобильную версию. На боевом адресе результат может отличаться от тестового.
10. Оставить старый сайт в архиве. Не удалять минимум несколько месяцев — он ещё пригодится для сверки.

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

Первые недели после запуска: что смотреть и когда

Просадка после переезда почти всегда бывает — вопрос в её глубине и длительности. Нормальная картина: небольшое колебание в первые дни и возврат к прежним показателям в течение нескольких недель.

Срок	Что проверять	Тревожный признак
Первые сутки	Коды ответа главных страниц, работа форм, счётчики	Любая страница из списка отдаёт ошибку
Первая неделя	Ошибки обхода в панели вебмастера, отчёт по 404	Растёт число несуществующих страниц
Вторая неделя	Число страниц в индексе, статус карты сайта	Новые адреса не появляются в индексе
Третья-четвёртая неделя	Позиции по основным запросам, органический трафик	Падение продолжается, а не выравнивается
Второй месяц	Сравнение трафика по разделам с периодом до переезда	Отдельный раздел просел сильнее остальных
Третий месяц	Полный аудит: дубли, скорость, разметка	Показатели так и не вернулись к прежним

Если нужна помощь по теме — курсы SEO-оптимизации.

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

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

Подробнее об этом — в статье «Оптимизация сайта под мобильные устройства».

Частые ошибки при переезде

• Забыть снять запрет индексации. Самая обидная ошибка: сайт работает, а в поиске исчезает. Проверяйте два места — файл robots.txt и настройку видимости в системе.
• Совместить переезд с редизайном и сменой структуры. Если что-то пойдёт не так, вы не поймёте, что именно виновато. Разносите изменения хотя бы на месяц.
• Не перенести метатеги. Автоматически сгенерированные заголовки заметно хуже написанных, и по коммерческим запросам это видно сразу.
• Оставить внутренние ссылки на старые адреса. Каждый переход становится лишним звеном, а часть ведёт в никуда.
• Удалить старый сайт сразу. Пока идёт сверка, он нужен: из него достают потерянные тексты, картинки и настройки.
• Не проверить формы. Заявки перестают доходить, а обнаруживается это через неделю тишины.
• Паниковать на третий день. Колебания в первую неделю — норма. Решения принимают по данным за две-три недели.
• Переехать в сезон. Миграцию планируют на спад спроса, а не на пик продаж.

Частые вопросы

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

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

Можно ли менять структуру адресов при переезде? Можно, но это отдельный риск поверх основного. Если структура вас устраивает, сохраняйте её. Если она объективно плохая, меняйте — но тогда карта адресов и проверка перенаправлений становятся обязательными, а не желательными.

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

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

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

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

Подробнее — в моём курсе по продвижению сайтов:

8:14

Коротко

• Смена движка не улучшает позиции сама по себе: она даёт инструменты, которыми надо отдельно пользоваться, поэтому переезд без внятной причины — лишний риск.
• Главный документ миграции — таблица соответствия старых и новых адресов с отметками о трафике и внешних ссылках.
• Лучший переезд тот, где адреса не меняются: это снимает основную часть рисков одним решением.
• Перенаправления делаются постоянные, прямые, без цепочек и без массового сведения на главную; держать их нужно не меньше года.
• До запуска новый сайт закрывается от индексации паролем и файлом robots, а в день запуска запрет обязательно снимается в обоих местах.
• Метатеги, атрибуты изображений и внутренние ссылки — три вещи, которые чаще всего теряются при импорте содержания.
• Оценивать последствия нужно по данным за две-три недели, а не по третьему дню, и следить за отчётом об ошибках обхода — там видны все забытые адреса.

Если переезд предстоит на сайте с накопленным трафиком и терять его нельзя, приходите на SEO-консультацию — разберём текущую структуру, соберём карту адресов и составим порядок проверок под ваш случай.