Переезд на новую структуру адресов пугает сильнее, чем должен. Сама по себе смена шаблонов ссылок позиции не рушит: поисковые системы спокойно переживают тысячи переименованных страниц, если им честно показали, где теперь живёт каждый старый материал. Ломается всё в другом месте, в таблице соответствий между старыми и новыми адресами. Одна небрежная строка в этой таблице обесценивает месяцы работы над контентом, причём внешне всё благополучно: страницы открываются, ошибок никто не видит, а трафик тихо тает неделю за неделей. Разобраться, как строится массовое перенаправление без потерь и где утекает накопленный вес, стоит до переключения сервера, а не после.
Карта перенаправлений один к одному как фундамент смены адресов
Основа грамотной миграции умещается в одну фразу: каждый старый адрес получает собственное правило, ведущее на самый близкий по смыслу новый адрес. Не на раздел и не на главную, а именно на преемника. Статья /blog/kak-vybrat-nasos переезжает в /articles/vybor-nasosa, категория /shop/pumps/ становится /catalog/nasosy/, карточка товара меняет префикс, сохраняя идентификатор. Поисковая система видит понятную картину: материал не исчез, он сменил прописку, а значит, всё накопленное, от ссылочного веса до истории запросов и показов, переносится на новый адрес.
Для наглядности подойдёт типичный сайт с 5000 адресов: статьи, категории, карточки товаров и служебные страницы. Полная карта в таком проекте насчитывает 4800 правил, столько адресов нашли преемников. Оставшиеся 200, устаревшие акции, дубли и черновики, случайно попавшие в индекс, преемника не имеют, и с ними поступают иначе, о чём речь пойдёт отдельно. Составить 4800 правил вручную нереально, поэтому карту генерирует скрипт по шаблонам, а вручную сверяют только важнейший слой, страницы, приносящие основной трафик. Обычно это несколько сотен адресов, и час их персональной проверки окупается лучше, чем недели последующего лечения.
Соблазн написать одно общее правило на весь раздел очевиден и опасен. Старые адреса почти никогда не совпадают с новым шаблоном аккуратно: часть материалов переехала в другие разделы, часть склеена с соседними. Общее правило неизбежно отправляет часть страниц не туда, и каждая неточность превращается в потерю.
Массовый сброс старых адресов на главную и мягкие 404
Самая вредная экономия при миграции выглядит так: все старые адреса разом перенаправляются на главную страницу. Настраивается за минуту, и первое время кажется, что всё в порядке. Робот заходит по старой ссылке, получает код 301, попадает на главную, та отвечает кодом 200, формальных претензий нет. Но у поисковой системы есть более строгий судья, соответствие содержания. Страница, которая когда-то отвечала на запрос про ремонт насосов, теперь ведёт на витрину, где про насосы ни слова. Тема не совпала, запрос не закрыт.
Через несколько недель система начинает помечать подобные адреса как мягкие 404. Термин описывает ситуацию, когда формальной ошибки нет, а содержимого, ради которого страница существовала, уже нет. Помеченные адреса постепенно исключаются из индекса, и вместе с ними из поиска исчезают все запросы, по которым эти страницы ранжировались. Для сайта из примера это означало бы списание тысяч показов: значительная часть из 4800 адресов дала бы не перенос веса, а его утрату. Релевантность на главную не передаётся, она теряется, ведь главная не способна ранжироваться по тысячам разных запросов сразу.
Отсюда правило: перенаправление оправдано только тогда, когда цель отвечает на те же вопросы, что и источник. Отвечать нечем, значит страницу честнее признать устаревшей и вывести из игры осознанно, по правилам, описанным дальше.
Постоянный 301 и временный 302 в глазах поисковых систем
Код ответа сервера для поисковой системы звучит как обещание. Код 301 говорит: переезд окончательный, старый адрес можно забыть, накопленные сигналы переносите на новый. Код 302 сообщает обратное: это временно, источник ещё пригодится, поэтому индексируйте старый адрес и не спешите с переносом. Разница кажется формальностью, на практике она решает судьбу трафика.
При 301 старый адрес со временем выпадает из индекса, а новый занимает его место вместе со ссылочным весом и историей запросов. Процесс не мгновенный, зато предсказуемый. При 302 система месяцами держит старый адрес в индексе, ведь ей обещали, что перенаправление снимут. Новый адрес полноценного переноса не получает и растёт медленно. Причина частой ошибки с 302 банальна, перестраховка: кажется, что временный код надёжнее, вдруг захочется откатиться. Итог: через полгода оба адреса существуют параллельно, сигналы размазаны, и ни один не работает в полную силу.
Существует ещё код 308, постоянный аналог 301, сохраняющий метод запроса; для обычных страниц разницы с 301 нет, поэтому в миграциях он встречается редко. Практичный вывод: окончательный переезд получает 301, а 302 остаётся коротким акциям, где откат действительно планируется.
Цепочки перенаправлений и потери сигнала на каждом лишнем прыжке
Ссылочный сигнал при перенаправлении не переносится целиком, каждый прыжок съедает часть, и на цепочке потери складываются. Условный расчёт для наглядности: пусть один прыжок доносит 90 процентов сигнала, тогда цепочка из трёх адресов донесёт до финальной цели около 73 процентов. Разница с одним прыжком выглядит как недобор в 17 процентных пунктов, и это только сигнал, без учёта времени.
Вторая цена цепочек измеряется в обходах: при 5000 адресов с цепочкой в три прыжка робот тратит порядка 10000 лишних обращений, которые легли бы на новые страницы. Бюджет обхода ограничен, и растраченный на промежуточные скачки ресурс замедляет переиндексацию остальных материалов.
Лекарство известно: правило должно вести сразу на финальный адрес. При генерации карты полезно добавить автопроверку, чтобы целевой адрес сам не оказался источником другого правила. Если старый адрес A ведёт на B, а B отдельно перенаправлен на C, правило для A переписывается на C. Такая проверка занимает минуту в скрипте и срезает половину хвостов, оставшихся от прежних перестроек, о которых уже никто не помнит.
Выгрузка адресов из sitemap и Search Console с примерами правил для nginx и Apache
Карта начинается с полного списка того, что нужно перенаправить. Источников обычно три: старый файл sitemap.xml, если он сохранился, панель Search Console, где отчёт "Эффективность" даёт страницы с показами и кликами за последние месяцы, а отчёт "Индексирование страниц" показывает, что реально сидит в индексе, и краулер вроде Screaming Frog, собирающий все адреса с кодами ответов. Три списка объединяют, чистят от дублей и получают рабочее множество.
Дальше адреса сопоставляются с новыми. Там, где шаблоны совпадают, работает скрипт: всё, что лежало в /blog/, переносится в /articles/ с тем же слагом. Спорные случаи разбираются вручную, приоритет у страниц с трафиком. На выходе таблица из двух колонок, и она превращается в конфигурацию сервера.
Для nginx тысячи правил удобно держать в блоке map, который ищет по таблице мгновенно и почти не грузит сервер:
map $request_uri $redirect_target {
default "";
/blog/kak-vybrat-nasos /articles/vybor-nasosa;
/shop/pumps/ /catalog/nasosy/;
}
server {
if ($redirect_target) {
return 301 $scheme://$host$redirect_target;
}
}Та же таблица в Apache разворачивается в построчные правила файла .htaccess:
RewriteEngine On
RewriteRule ^blog/kak-vybrat-nasos/?$ /articles/vybor-nasosa [R=301,L]
RewriteRule ^shop/pumps/?$ /catalog/nasosy/ [R=301,L]При сотнях и тем более тысячах правил построчные RewriteRule начинают тормозить, они проверяются последовательно на каждом запросе. Поэтому для проектов, где счёт правил идёт на тысячи, соответствия выносят на уровень nginx либо хранят в отдельной таблице на стороне приложения. Мелочью в .htaccess жить можно, массовой миграцией нет.
Шаблонные правила с регулярками требуют бдительности: конструкция, переводящая всё содержимое /blog/ в /articles/, молча переведёт и те адреса, которые переезжать не должны. Поэтому регулярку сужают, а исключения перечисляют раньше общего правила. Каждое сгенерированное правило проверяется на выборке из десятка реальных адресов, для каждого ожидается точный новый адрес.
Перед запуском карту тестируют без риска для индекса: достаточно выборки из пары сотен адресов и запроса заголовков утилитой curl. Команда ниже показывает итоговый код и конечный адрес после всех прыжков:
curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://site.ru/blog/kak-vybrat-nasosИдеальный ответ здесь один: код 301 и в поле Location ровно тот адрес, что записан в карте. Любой другой результат, 404, 302, двойной прыжок, помечается как дефект и правится до переключения, а не после.
Обновление внутренних ссылок и статус 410 для адресов без наследников
Перенаправления страхуют посетителей и роботов, но строить на них всю стратегию нельзя. Каждая внутренняя ссылка, идущая через редирект, создаёт лишний прыжок внутри собственного сайта со всеми потерями из предыдущего раздела. Поэтому до переключения шаблоны, меню, футеры, перелинковка в текстах и новый файл sitemap.xml должны ссылаться сразу на новые адреса. Задача решается поиском старых фрагментов адресов в шаблонах и базе данных с точечной заменой, а проверка простая: обойти обновлённый сайт краулером и убедиться, что внутренние переходы не возвращают кодов 301.
Оставшиеся 200 адресов без преемников требуют отдельного решения. Устаревшая акция, по которой никто не ищет, не должна притворяться вечной. Для таких адресов честнее статус 410 вместо 404: он сообщает роботу, что материал удалён намеренно и навсегда. На 410 система реагирует быстрее, чем на 404, и убирает адрес из индекса без лишних повторных обходов. Выгода двойная: индекс не захламляется мёртвыми страницами, а бюджет обхода достаётся живым материалам.
Типовые ошибки, сроки переиндексации и мониторинг после миграции
Даже аккуратная карта не застрахована от классических промахов, поэтому перед переключением её полезно прогнать по чек-листу:
- Петли, когда правило ведёт на адрес, который перенаправляет обратно, и обход зацикливается;
- Редирект на несуществующий адрес из-за опечатки в карте, для робота это противоречивый сигнал хуже отсутствия правила;
- Несовпадение регистра и слэшей, когда /Blog/Post-1 и /blog/post-1/ считаются разными адресами, а правило покрывает лишь один вариант;
- Временный 302 там, где переезд окончательный, из-за чего старые адреса месяцами держатся в индексе;
- Потерянные параметры, когда адрес с меткой ?utm_source не попадает под правило и отдаёт 404;
- Цепочки из двух и более прыжков, унаследованные от прежних перестроек сайта.
Со сроками всё спокойнее, чем принято бояться. В первые одну-две недели после переключения трафик обычно проседает на 10-30 процентов, и это нормальная картина: робот заново обходит тысячи адресов и проверяет обещания сервера. К четвёртой-шестой неделе кривая возвращается к прежним значениям, если карта составлена без ошибок. Полная переиндексация занимает от нескольких недель до месяцев: лёгкий сайт робот перечитывает за считанные недели, а крупный проект с десятками тысяч страниц и скромным бюджетом обхода переваривается несколько месяцев. Для примера с 5000 адресов реалистичный ориентир такой: основной возврат трафика за 6-8 недель, полное обновление индекса за 2-4 месяца.
Если через восемь недель трафик так и не вернулся, искать стоит не в алгоритмах, а у себя: выборка двадцати главных страниц, по каждой проверяется цепочка и ответ сервера, затем сравнивается содержание старой и новой версии, ведь переезд нередко совпадает с редизайном и часть текстов теряется.
Мониторинг ведётся в тех же панелях, откуда брались адреса. Отчёт "Индексирование страниц" в Search Console показывает динамику проиндексированных адресов и причины исключений, отчёт "Статистика обхода" отвечает, сколько запросов робот тратит на редиректы и какие коды ответов преобладают, а отдельные подозрительные адреса проверяются инструментом проверки URL. Практичный ритм: раз в неделю сверять позиции топ-страниц и список выпавших из индекса адресов, а через месяц после переключения пройтись краулером по старым адресам ещё раз, чтобы поймать забытые цепочки и петли.
Карта, однажды собранная и проверенная, остаётся документом сайта, выручает при следующих перестройках и экономит будущие недели. А лучший показатель качества проведённой работы звучит неожиданно: переезд прошёл настолько аккуратно, что читатели его вообще не заметили, а поисковая система просто продолжила показывать те же страницы по новым адресам. К такой незаметности и стоит стремиться.