Редизайн сайта без потери трафика: карта редиректов и чек-лист

После запуска обновлённого сайта первые недели аналитика читается тяжело: органический трафик проседает, заявок с формы становится меньше, а часть запросов, которые раньше приводили клиентов, вообще перестают приводить кого-либо. Дизайн здесь чаще всего ни при чём — просто между старыми адресами сайта и новыми не построен мост.
Google переносит накопленный сайтом вес — позиции, ссылки, историю кликов — только одним способом: постоянным редиректом на уровне сервера. Если этот шаг пропущен или сделан наполовину, даже безупречный по дизайну редизайн отбрасывает выдачу почти к нулю.
Почему трафик теряется из-за адресов, а не из-за дизайна
У каждой проиндексированной страницы есть свой адрес, и Google годами копит к этому адресу «вес» — входящие ссылки, статистику кликов, стабильность содержимого. Если при обновлении сайта структура адресов меняется (например, /uslugi/dizayn вместо /services/design), накопленный вес автоматически на новый адрес не переходит. Пока сервер продолжает отвечать «страница не найдена», Google постепенно вычёркивает этот адрес из индекса — а вместе с ним уходит и вес.
Единственный способ этого избежать — заранее и явно связать каждый старый адрес с конкретным новым. Такой список называется картой редиректов, и составлять её нужно не после того, как дизайн готов, а в самом начале проекта.
До переезда: как строится карта редиректов
1. Выгрузите полный список старых адресов
Соберите его из трёх источников: файла sitemap старого сайта, серверных логов (какие адреса реально получали трафик) и отчёта Google Analytics по самым посещаемым страницам. Не ограничивайтесь пунктами меню — множество старых статей блога или карточек товара в меню не выведены, но трафик из поиска получают.
2. Свяжите каждый адрес с конкретным новым
Самая распространённая ошибка — направить все старые адреса на главную страницу. Google не считает это настоящим редиректом, потому что между темой старой страницы и новой целью нет связи. Каждый адрес должен вести на максимально близкую по смыслу новую страницу; если точного соответствия нет, вторым по качеству вариантом будет ближайшая по теме категория.
3. Выбирайте постоянный редирект и не стройте цепочки
Собственная документация Google прямо об этом говорит: там, где возможно, нужно использовать постоянные редиректы 301 или 308 — временный (302) редирект посылает неверный сигнал, если адрес меняется навсегда. Та же документация советует не связывать один редирект с другим — то есть избегать цепочек: каждый дополнительный переход и задерживает посетителя, и усложняет обход страницы поисковым роботом.
День запуска: что проверить перед выпуском
Когда карта готова, сам день запуска требует нескольких небольших, но напрямую влияющих на результат действий:
- Уберите
noindexи блокирующие строки вrobots.txt, оставшиеся с тестового окружения — этот запрет ставят, чтобы недоделанный сайт не попал в поиск, и забывают снять его после запуска чаще всего. - Проверьте, что на каждой новой странице стоит
canonical, указывающий на её собственный адрес. - Сразу отправьте новый sitemap; старый удаляйте только после того, как Google распознает новые адреса.
- Пройдите карту редиректов построчно вручную — одна опечатка в автоматическом правиле способна превратить в «страница не найдена» целый раздел.
- Откройте каждый старый адрес прямо в браузере и убедитесь, что он останавливается на верном новом адресе с кодом ответа
301или308— это делается до публикации, а не после.
Забытая деталь: внутренние ссылки самого сайта
Карта редиректов обычно продумывается для внешних ссылок и позиций в поиске, но собственные внутренние ссылки сайта не менее важны. Меню, подвал, блок «похожие материалы», перекрёстные ссылки между старыми статьями блога — всё это может по-прежнему указывать на старые адреса. В результате при каждом клике посетитель сначала попадает на редирект и только потом на нужную страницу, а это и добавляет задержку, и заставляет поискового робота делать лишний переход, чтобы дойти до страницы. Правильный подход прост: заменить внутренние ссылки на новый адрес напрямую, а не полагаться на редирект.
Это особенно легко упустить при смене платформы (например, при переезде с готового конструктора на индивидуальную разработку), потому что вручную найти сотни внутренних ссылок на старой платформе долго — но именно здесь «мелкие» детали дают наибольшую разницу.
После переезда: что и сколько отслеживать
Отправьте запрос «Смена адреса» в Google Search Console — это официальный инструмент, доступный при смене домена, которым вы сообщаете о переезде. После этого следите за отчётами «Покрытие» и «Эффективность»: там видно, какие старые адреса ещё числятся проиндексированными, а какие уже заменены новыми.
Переход не происходит мгновенно. Google говорит о нескольких неделях переходного периода для сайта среднего размера — колебания трафика в это время считаются нормой, а не устойчивым падением. А сами редиректы убирать рано не стоит: та же документация советует держать их минимум год, потому что старые ссылки и сохранённые в браузерах адреса привыкают к новому адресу именно за это время. Проверить, что скоростные показатели нового сайта после переезда остались на прежнем уровне, можно бесплатным инструментом аудита скорости и SEO.
Новый сайт не наследует доверие, которое старый зарабатывал годами, — его можно только передать, и передаётся оно исключительно через правильно построенную карту редиректов.
Когда без помощи не обойтись
Для сайта в несколько десятков страниц такую карту реально составить самостоятельно, хоть в обычной таблице. Но при смене платформы (например, с готового конструктора на индивидуальную разработку), в интернет-магазине с сотнями карточек товара или если структура адресов старого сайта нигде не задокументирована, ручная сверка резко повышает риск ошибки — каждая пропущенная строка означает потерянную страницу.
Например, при переезде интернет-магазина с готового конструктора (Tilda, WordPress) на индивидуальную разработку адреса товаров обычно меняют формат целиком — вместо /product-id-123 появляется что-то вроде /catalog/category/name. Сопоставить вручную полторы сотни карточек товара можно за несколько дней, а пропустить этот шаг — значит потерять трафик на месяцы.
В таких случаях доверить технический переход команде разработки, которая планирует его заранее, обходится дешевле — потому что правки вносятся до запуска, а не после него.