Типичная история: у компании старый сайт — набор статических страниц или устаревшая CMS, которую страшно обновлять. Править тексты может только программист, фото меняются через FTP, а новые разделы появляются раз в полгода. Решение очевидно — переехать на нормальный движок с админкой. Через месяц после запуска владелец открывает Яндекс Вебмастер и видит, что половина страниц выпала из поиска, а главная опустилась со второй строки на третью страницу.
Мы недавно проходили этот путь на собственном сайте: перевели его со статического HTML на современный бэкенд с базой данных и админкой. Позиции сохранились. Ниже — порядок действий, который мы используем и для клиентских проектов.
Почему после переезда падают позиции
Поисковик не знает, что у вас «новый движок». Он видит набор адресов, текстов и связей между страницами. Если после переезда меняется что-то из этого, для Яндекса это уже другой сайт, и накопленное доверие приходится зарабатывать заново. Чаще всего ломаются четыре вещи:
- Адреса страниц. Было
/services.html, стало/services/, а редиректа нет. Старый адрес отдаёт 404, ссылки с других сайтов ведут в пустоту. - Тексты. «Раз уж делаем новый сайт, напишем всё заново» — и вместо проверенного временем текста появляется красивый, но непривычный для поисковика.
- Мета-теги. Title и description в новом шаблоне генерируются автоматически из названия страницы — и у десятка страниц оказываются одинаковыми.
- Техническая обвязка. Забыли sitemap, robots.txt закрывает всё от индексации (остался с тестового стенда), канонические адреса указывают на тестовый домен.
Ни одна из этих ошибок не связана с выбором технологии. Можно переехать на любую CMS или самописный бэкенд — и потерять всё, а можно переехать на них же без потерь.
Шаг первый: карта адресов до начала разработки
Прежде чем писать код, мы выгружаем полный список адресов старого сайта. Источников несколько, и лучше использовать все сразу:
- sitemap.xml старого сайта (если он есть и актуален);
- выгрузка страниц в поиске из Яндекс Вебмастера и Google Search Console;
- обход сайта краулером — он найдёт страницы, которые не попали в sitemap;
- страницы входа из метрики за последний год — по ним видно, какие адреса реально приносят трафик.
Из этого получается таблица: старый адрес, новый адрес, тип соответствия. Для каждой строки решаем, сохраняем ли адрес как есть, переносим с редиректом или страница больше не нужна. Удалять страницы, которые приносят трафик, без замены нельзя: если раздел упразднён, редиректим на ближайшую по смыслу страницу, а не на главную.
На нашем сайте мы заодно перешли на «чистые» адреса без расширений — вместо /about.html стало /about/. Это удобно, но каждый такой переход — строчка в таблице редиректов, а не повод забыть старый адрес.
Редиректы: только 301 и только один шаг
Постоянный редирект с кодом 301 говорит поисковику: страница переехала навсегда, перенеси её вес на новый адрес. Временный 302 этого не делает. Несколько практических правил:
- Один шаг: старый адрес → новый адрес. Цепочки вида
/page.html→/page→/page/поисковик проходит неохотно, и вес теряется. - Редиректы для вариантов: с
wwwи без,httpиhttps, со слешем на конце и без. Канонический вариант должен быть один. - Редиректы держим долго — минимум год, лучше бессрочно. Внешние ссылки на старые адреса никуда не денутся.
- Не перенаправляем всё подряд на главную. Массовый редирект на главную Яндекс воспринимает как «мягкую 404».
Если редиректов немного, их удобно держать прямо в конфигурации веб-сервера. Пример для nginx:
location = /about.html { return 301 /about/; }
location = /services.html { return 301 /services/; }
location = /contacts.php { return 301 /contacts/; }
Если редиректов сотни, их лучше хранить в базе и обрабатывать в приложении — тогда менеджер может добавить новый без программиста.
Тексты и мета-теги: переносим дословно
Это самый недооценённый пункт. Когда мы переводили собственный сайт, первым желанием было переписать тексты главной — новый дизайн, новый тон. Мы этого не сделали: старые title, description и основной текст главной хорошо ранжировались в Яндексе, и мы перенесли их дословно, слово в слово, из старого шаблона в новую админку.
Логика простая: переезд и смена текстов — две разные задачи. Если сделать их одновременно и позиции упадут, вы не узнаете, что именно сработало плохо. Если сначала переехать с теми же текстами, а через месяц-два переписывать по одной странице и смотреть на динамику, — каждое изменение измеримо.
Что переносим без изменений:
- title и meta description каждой страницы;
- заголовок h1 и структуру подзаголовков;
- основной текст, включая ключевые фразы, даже если они звучат немного «по-сеошному»;
- alt у изображений;
- микроразметку — организация, контакты, хлебные крошки.
При этом в новом движке сразу закладываем, чтобы все эти поля редактировались из админки отдельно для каждой страницы. Тогда следующие изменения не потребуют программиста.
Техническая обвязка: sitemap, robots, canonical
Перед переключением домена проверяем служебные файлы и заголовки:
- sitemap.xml генерируется автоматически и содержит только реальные, открытые для индексации страницы с кодом 200 — без редиректов и 404.
- robots.txt не закрывает сайт целиком. Тестовый стенд обычно закрыт от индексации, и эта строчка любит переезжать на боевой сайт.
- canonical указывает на боевой домен, а не на тестовый.
- Код ответа 404 для несуществующих страниц — именно 404, а не 200 с текстом «страница не найдена».
- HTTPS и автоматическое продление сертификата.
Отдельно — скорость. Новый движок не должен быть медленнее старого. Статический сайт отдаёт страницы мгновенно, и если динамический бэкенд без кэширования отвечает секунду, это заметят и пользователи, и поисковик.
Переключение и план отката
Мы никогда не удаляем старый сайт в день переезда. Новая версия поднимается рядом, проходит проверки на тестовом адресе, после этого переключается домен. Старая версия остаётся нетронутой и готовой к возврату: если в первые дни что-то пойдёт не так, откат занимает минуты, а не дни восстановления из архива.
Перед переключением прогоняем автоматические проверки: каждый адрес из sitemap должен отвечать кодом 200, каждый старый адрес из таблицы редиректов — кодом 301 на правильный новый адрес. На нашем сайте такой обход всех страниц стал частью каждой выкладки, а не разовой акцией.
Что проверить в первую неделю после переезда
- День 1. Добавить новый sitemap в Яндекс Вебмастер и Search Console, проверить, что старый удалён или обновлён. Отправить на переобход главную и ключевые разделы.
- День 1–2. Пройти таблицу редиректов скриптом: все старые адреса отвечают 301 на нужные страницы, без цепочек.
- День 2–3. Проверить в Вебмастере раздел ошибок: нет ли роста 404, нет ли страниц, «исключённых как дубли».
- День 3–5. Сравнить title и description в выдаче со старыми. Если Яндекс подставил что-то своё — значит, он не нашёл нормальных мета-тегов.
- День 5–7. Сравнить трафик из поиска с той же неделей до переезда. Небольшие колебания нормальны, падение в разы — сигнал искать ошибку в редиректах или индексации.
- Весь месяц. Следить за формами заявок: новый движок — новые обработчики, и тихо сломанная форма обходится дороже любой просадки позиций.
Обычно Яндекс полностью «переваривает» переезд за несколько недель. Если в течение этого времени позиции колеблются в пределах нескольких пунктов — это нормальная переиндексация. Если страница исчезла совсем — ищите её адрес в таблице редиректов.
Итог
Переезд без потерь — это дисциплина, а не магия: полная карта адресов, 301-редиректы в один шаг, дословный перенос текстов и мета-тегов, исправная служебная обвязка и старая версия наготове для отката. Улучшать тексты стоит уже после того, как поисковик привык к новому сайту, — по одной странице и с замером результата.
Планируете перенос сайта на новый движок или редизайн? Напишите нам — подготовим карту адресов и план переезда до того, как будет написана первая строка кода. Посмотреть, какие сайты мы уже делали, можно в портфолио.
