301-редиректы при переносе сайта: пошаговая настройка

Как пошагово настроить 301-редиректы при переносе сайта

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

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

1. Определите тип миграции и цели редиректов

Начните с простого вопроса: какой именно перенос сайта вы делаете? Смена домена требует одного подхода, смена платформы — другого, а изменение структуры URL вообще стоит отдельно. Если всё это происходит одновременно, зафиксируйте это сразу. Не потом. В частности, настройка редиректов при смене домена требует отдельной карты соответствий и более тщательной проверки старых ссылок.

Например, при смене бренда с oldsite.com на newsite.com может потребоваться перенаправить почти каждую живую страницу, а при переходе с одной CMS на другую URLs могут остаться прежними, изменится только способ отображения страниц. Это разные задачи. Если считать их одной и той же задачей, план редиректов быстро станет хаотичным.

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

Опишите правила миграции простыми словами. Коротко. «Старые страницы категорий переезжают в новые категории». «Удалённые промо-страницы редиректы не требуют». «Тонкие архивные страницы можно убрать». Такие решения экономят много времени позже, потому что 301-редиректы должны следовать реальной структуре сайта, а не догадкам, сделанным на неделе запуска.

Если при миграции меняются ещё и права на контент или настройки аналитики, сделайте это заметным для команды. Переезд сайта часто затрагивает не одну группу, и карта редиректов должна соответствовать не только структуре URL, но и бизнес-плану. Для более широкого взгляда на сопутствующие задачи при переезде см. сколько стоит обслуживание сайта.

2. Соберите только те URL, которым действительно нужны редиректы

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

Собирайте URL из нескольких источников. Используйте текущую sitemap, аналитику, серверные логи и любые старые выгрузки сканирования, которые у вас уже есть. URL без посещений и без ссылок может не требовать внимания. А вот URL со внешними ссылками — может. Иногда именно он остаётся важным ещё полгода после переезда.

Исключайте страницы, которые должны быть сознательно закрыты. Сезонной кампании 2021 года не нужен новый дом только потому, что она существует. Как и старой внутренней тестовой странице. Здесь помогает дисциплина. Лучше меньше редиректов, чем слишком много, если при этом покрыты действительно важные страницы.

Разбейте список на простые группы: страницы, папки, файлы и особые случаи. Здесь помогают цифры. Список из 12 URL можно обработать одним способом. Список из 1200 URL уже требует правил по шаблонам, а не ручных правил для каждой строки. Если пропустить этот шаг, карту редиректов будет трудно проверять.

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

3. Сопоставьте старые URL с правильными новыми

Теперь переходите к маппингу. Чистая схема один-к-одному — самый простой вариант: один старый URL ведёт на один новый, и связь очевидна. Статья в блоге о ценах переезжает в новую статью о ценах. Страница услуги об аудитах — на новую страницу аудита. Всё просто.

В реальных миграциях так бывает редко. Иногда одна старая страница превращается в две новые, а иногда три старые страницы объединяются в одну более сильную. В таких случаях решите, зачем пользователь, скорее всего, пришёл. Если старая страница закрывала и «настройку», и «поддержку», а на новом сайте это разделено на разные страницы, выберите лучший вариант по основному намерению, а остальное свяжите внутренними ссылками позже. Такой подход особенно полезен, когда вы планируете 301 редиректы при миграции сайта пошагово и хотите сохранить логику пользовательского пути.

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

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

Рядом со спорными URL добавляйте комментарии. Коротко объясняйте объединённые страницы, разделённые страницы и удалённый контент. Эти заметки очень помогают, когда кто-то смотрит план за два дня до запуска и спрашивает, почему страница A ведёт на страницу B. Ответ должен быть виден в карте, а не потерян в чате.

4. Выберите подходящий способ внедрения 301-редиректов

Где именно размещать 301-редиректы, зависит от того, как устроен перенесённый сайт. На одних стэках самым чистым вариантом будет серверная конфигурация. На других лучше подойдёт CMS, CDN или слой маршрутизации приложения. Выбирайте то место, где редиректы будут работать надёжно и без лишних сущностей.

Если сайт работает на классическом веб-сервере, правила на уровне сервера могут быть самым прямым вариантом. Если сайт управляется через CMS со встроенными инструментами редиректов, этого может хватить для небольших переносов. Если трафик проходит через CDN, правила на edge-уровне помогают, особенно когда нужны быстрые обновления для большого числа URL.

У каждого варианта есть компромиссы. Серверные правила мощные, но требуют аккуратности. Плагины CMS удобны, но могут превращаться в свалку. Правила CDN быстрые, но важно точно понимать, как они взаимодействуют с кэшированием и сопоставлением путей. Выбирайте по требованиям нового сайта, а не по привычке.

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

Для больших команд полезно описать способ в одном месте. Укажите рядом с картой редиректов владельца, платформу и путь деплоя. Тогда человек, который меняет правила, будет понимать, писать ли их в Nginx, Apache, таблице CMS, панели CDN или в коде приложения.

5. Напишите и структурируйте правила 301

Теперь преобразуйте карту в реальные 301-редиректы. Держите правила аккуратными. Один шаблон должен делать одну задачу. Если правило пытается захватить слишком много форм URL, оно может зацепить не те страницы и отправить пользователей куда-то не туда.

Следите за петлями. Петля возникает, когда страница A редиректит на страницу B, а страница B возвращает обратно на A, или когда две страницы по кругу отправляют друг друга туда-сюда. Для поисковых роботов и пользователей это тупик. К тому же это расходует crawl budget — скучный термин, который внезапно становится очень важным, когда ничего нормально не индексируется.

Избегайте и цепочек. Цепочка — это когда один редирект ведёт на следующий, а затем ещё на один. Страница A идёт на B, потом B — на C. Это работает плохо и всё замедляет. Если можно направить A сразу на C, так и сделайте.

Используйте единые названия и группировку внутри файла или интерфейса. Разделите правила по секциям: старые пути блога, старые пути услуг, старые пути товаров, удалённые активы. Аккуратный список проще тестировать. И его проще отдать другому разработчику в 18:00 в день запуска без долгих пояснений.

Не забывайте об исключениях. Широкое правило вроде «всё из /blog/ перенаправлять в /insights/» может казаться эффективным, но оно легко ломает теги, страницы авторов или старые ссылки на медиафайлы. Если у шаблона есть исключения, вынесите их до релиза. Это сэкономит время на исправления позже.

6. Проверьте работу редиректов до и после запуска

Тестирование должно проходить до запуска, а не после первого сообщения о сломанной странице. Проверьте выборку отдельных URL из карты, затем протестируйте группы шаблонов, а потом — нестандартные случаи вроде слэшей в конце, заглавных букв в путях, query string и файлов с расширениями. Редирект, который работает для одного URL, может сломаться на его близком варианте.

Подтвердите, что код ответа — именно 301, а не 302 и не soft rewrite, который только выглядит как редирект в браузере. Разница важна. Поисковые системы по-разному относятся к постоянному переезду и временному перенаправлению, а пользователям не нужно гадать, что произошло. Проверяйте статус-код инструментом, который показывает реальный ответ.

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

Проводите проверки в два этапа: один раз до запуска в staging-среде и ещё раз сразу после запуска на рабочем сайте. Вторая проверка выявляет проблемы с деплоем, сюрпризы кэширования и любое правило, которое ведёт себя иначе, когда уже работает реальный хост. Именно тогда многие команды находят тот самый URL, который забыли.

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

7. Обновите сопутствующие сигналы после миграции

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

Обновите XML-карты сайта с новыми URL. При необходимости отправьте их заново. Уберите старые URL из живой sitemap, если они теперь редиректят, и оставьте там только адреса назначения. Sitemap, наполненная устаревшими адресами, подаёт смешанные сигналы, даже если редиректы работают идеально.

Проверьте canonical-теги. Они должны указывать на новую страницу, а не на старую. Это небольшая строка кода, но она важна. Canonical, который по-прежнему ссылается на старый URL, может запутать сообщение для поисковых систем, особенно в первый цикл обхода после запуска.

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

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

8. Отслеживайте проблемы с обходом и трафиком в первый период после запуска

Именно в первый период после запуска проблемы и проявляются. Проверяйте пропущенные URL, неожиданные 404, аномалии редиректов и всплески запросов к старым путям. Для большого сайта в первые дни это лучше делать ежедневно. Дважды в день — это не чрезмерная реакция, если миграция совсем свежая.

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

Закрывайте пробелы быстро. Если URL был пропущен — добавьте его. Если шаблон слишком широкий — сузьте его. Если появилась цепочка — сократите её. Карта редиректов не заканчивается на запуске; это рабочий документ как минимум в первые дни после переезда.

Отслеживайте самые важные страницы в первые 7 дней, а затем снова через 30 дней, если миграция крупная. Так у вас будут две контрольные точки: одна для немедленных поломок и одна для более медленных эффектов обхода и индексации. Если цифры выглядят неправильно, не ждите, что они сами исправятся.

Держите команду в курсе конкретикой, а не расплывчатыми статусами. «Четыре URL товаров всё ещё возвращают 404» — полезно. «Остались некоторые проблемы» — нет. Если маркетинговая кампания, упоминание в прессе или часто ссылающаяся страница всё ещё ведут на старый адрес, сначала исправьте именно этот путь. Один пропущенный URL может иметь больший эффект, чем дюжина страниц с низкой ценностью.

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