Продолжая пользоваться сайтом, вы соглашаетесь на обработку файлов cookie и других пользовательских данных в соответствии с политикой конфиденциальности.
#SEO
Что такое редирект (301/302) и как его настроить в htaccess
URL страницы может измениться по десяткам причин: сайт переезжает на другой домен, меняется структура каталога, удаляется старый материал или владелец переводит проект на HTTPS. Проблема начинается в тот момент, когда старый адрес уже не соответствует новой структуре.
Человек всё ещё может открыть сохранённую закладку, перейти по ссылке из старой статьи или найти прежний URL в поиске. Если сервер ничего не объяснит такому посетителю, тот увидит ошибку 404.
Есть другой вариант: сервер получает обращение к прежнему адресу и отправляет запрос дальше. Такой механизм называется редиректом.
Человек всё ещё может открыть сохранённую закладку, перейти по ссылке из старой статьи или найти прежний URL в поиске. Если сервер ничего не объяснит такому посетителю, тот увидит ошибку 404.
Есть другой вариант: сервер получает обращение к прежнему адресу и отправляет запрос дальше. Такой механизм называется редиректом.
Что такое редирект простыми словами
Проще всего представить ситуацию с переездом офиса. Организация больше не работает по прежнему адресу, но оставляет на двери сообщение с новым местом. Посетитель не ищет компанию заново — он сразу получает нужное направление.
В интернете роль такой подсказки выполняет серверный ответ.
Допустим, статья раньше находилась здесь:
https://site.ru/articles/prodvizhenie/
После изменения структуры её адрес стал таким:
https://site.ru/blog/prodvizhenie/
При обращении к старому URL сервер может сообщить браузеру, что материал теперь находится по другому пути.
Это и есть ответ на вопрос, что такое редирект сайта: способ автоматически перенаправить запрос с одного сетевого адреса на другой.
При этом сам переход может выглядеть для посетителя практически незаметно. Он вводит старую ссылку, а через короткое время оказывается на актуальной странице.
В интернете роль такой подсказки выполняет серверный ответ.
Допустим, статья раньше находилась здесь:
https://site.ru/articles/prodvizhenie/
После изменения структуры её адрес стал таким:
https://site.ru/blog/prodvizhenie/
При обращении к старому URL сервер может сообщить браузеру, что материал теперь находится по другому пути.
Это и есть ответ на вопрос, что такое редирект сайта: способ автоматически перенаправить запрос с одного сетевого адреса на другой.
При этом сам переход может выглядеть для посетителя практически незаметно. Он вводит старую ссылку, а через короткое время оказывается на актуальной странице.
Для чего используют перенаправления
Такая настройка нужна не только после переезда отдельных публикаций.
На практике она помогает решить несколько задач:
На практике она помогает решить несколько задач:
- заменить устаревший URL новым;
- перевести проект с HTTP на HTTPS;
- изменить доменное имя;
- объединить несколько материалов;
- перенести целый раздел;
- избавиться от технических дублей;
- сохранить доступ к старым ссылкам.
301 и 302: в чём разница
Коды 301 и 302 обозначают разные сценарии.
Постоянный вариант — 301
Код 301 используют, когда прежний URL больше не планируется возвращать.
Например, страница:
site.ru/news-old/
окончательно заменена на:
site.ru/news/
В таком случае поисковым системам и клиентам нужно передать информацию о постоянном переезде.
Если объяснять, что такое редирект 301, одной фразы достаточно: старый адрес заменён новым на постоянной основе.
Временный вариант — 302
302 нужен для другой ситуации. Новый маршрут действует сейчас, но впоследствии исходная схема может вернуться.
Например, владелец временно направляет посетителей на альтернативную страницу во время тестирования или технических работ.
Поэтому выбирать код только по принципу «какой чаще используют» неправильно. Сначала нужно определить, является ли изменение окончательным.
Для постоянного изменения URL Google рекомендует серверные перенаправления 301 или 308.
Постоянный вариант — 301
Код 301 используют, когда прежний URL больше не планируется возвращать.
Например, страница:
site.ru/news-old/
окончательно заменена на:
site.ru/news/
В таком случае поисковым системам и клиентам нужно передать информацию о постоянном переезде.
Если объяснять, что такое редирект 301, одной фразы достаточно: старый адрес заменён новым на постоянной основе.
Временный вариант — 302
302 нужен для другой ситуации. Новый маршрут действует сейчас, но впоследствии исходная схема может вернуться.
Например, владелец временно направляет посетителей на альтернативную страницу во время тестирования или технических работ.
Поэтому выбирать код только по принципу «какой чаще используют» неправильно. Сначала нужно определить, является ли изменение окончательным.
Для постоянного изменения URL Google рекомендует серверные перенаправления 301 или 308.
Как настроить редирект страницы в. htaccess
Если сайт работает на Apache, правила можно разместить в файле.htaccess.
Обычно он находится в корневой папке проекта. Перед редактированием желательно сохранить копию исходного файла. Это особенно важно, если там уже находятся другие настройки.
Для использования механизма mod_rewrite применяется директива:
RewriteEngine On
После неё можно описывать конкретные маршруты.
Один старый URL вместо другого
Допустим, прежняя страница имела путь:
/catalog/old-model/
а новая:
/catalog/new-model/
Правило будет выглядеть так:
RewriteEngine On
RewriteRule ^catalog/old-model/?$ /catalog/new-model/ [R=301,L]
Здесь не происходит изменения всего сайта. Условие относится только к указанному пути.
R=301 задаёт постоянный статус, а L прекращает дальнейшую обработку правил после совпадения.
Так можно настроить редирект страницы, когда изменился один конкретный URL.
Обычно он находится в корневой папке проекта. Перед редактированием желательно сохранить копию исходного файла. Это особенно важно, если там уже находятся другие настройки.
Для использования механизма mod_rewrite применяется директива:
RewriteEngine On
После неё можно описывать конкретные маршруты.
Один старый URL вместо другого
Допустим, прежняя страница имела путь:
/catalog/old-model/
а новая:
/catalog/new-model/
Правило будет выглядеть так:
RewriteEngine On
RewriteRule ^catalog/old-model/?$ /catalog/new-model/ [R=301,L]
Здесь не происходит изменения всего сайта. Условие относится только к указанному пути.
R=301 задаёт постоянный статус, а L прекращает дальнейшую обработку правил после совпадения.
Так можно настроить редирект страницы, когда изменился один конкретный URL.
Когда адреса меняются массово
Иногда вручную перечислять страницы нет смысла.
Представим, что у проекта была структура:
/articles/название/
а после обновления все публикации оказались в:
/materials/название/
Если внутренние части адресов остались прежними, можно использовать шаблон:
RewriteEngine On
RewriteRule ^articles/(.*)$ /materials/$ 1 [R=301,L]
Запрос:
/articles/seo/
будет направлен сюда:
/materials/seo/
Однако подобное правило нельзя создавать только потому, что «так короче». Сначала нужно убедиться, что соответствие действительно одинаковое для всего раздела.
Если десять старых страниц получили десять новых адресов по разным правилам, лучше составить отдельную карту переходов.
Представим, что у проекта была структура:
/articles/название/
а после обновления все публикации оказались в:
/materials/название/
Если внутренние части адресов остались прежними, можно использовать шаблон:
RewriteEngine On
RewriteRule ^articles/(.*)$ /materials/$ 1 [R=301,L]
Запрос:
/articles/seo/
будет направлен сюда:
/materials/seo/
Однако подобное правило нельзя создавать только потому, что «так короче». Сначала нужно убедиться, что соответствие действительно одинаковое для всего раздела.
Если десять старых страниц получили десять новых адресов по разным правилам, лучше составить отдельную карту переходов.
Как настроить редирект сайта при смене домена
Смена домена требует большей аккуратности.
Допустим, проект переезжает:
oldsite.ru
→
newsite.ru
Если структура сохраняется, путь можно оставить без изменений:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.ru$ [NC]
RewriteRule ^(.*)$ newsite.ru/$ 1 [R=301,L]
Тогда:
https://oldsite.ru/blog/article/
получит направление на:
https://newsite.ru/blog/article/
Но автоматическое правило подходит только при совпадении структуры.
Если старый /catalog/ превратился в /shop/, а часть товаров получила совершенно новые адреса, универсальная маска уже не решит задачу корректно.
При переносе большого проекта Google рекомендует заранее составлять соответствие между прежними и новыми URL, а затем проверять перенаправления после запуска.
Допустим, проект переезжает:
oldsite.ru
→
newsite.ru
Если структура сохраняется, путь можно оставить без изменений:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\.ru$ [NC]
RewriteRule ^(.*)$ newsite.ru/$ 1 [R=301,L]
Тогда:
https://oldsite.ru/blog/article/
получит направление на:
https://newsite.ru/blog/article/
Но автоматическое правило подходит только при совпадении структуры.
Если старый /catalog/ превратился в /shop/, а часть товаров получила совершенно новые адреса, универсальная маска уже не решит задачу корректно.
При переносе большого проекта Google рекомендует заранее составлять соответствие между прежними и новыми URL, а затем проверять перенаправления после запуска.
Переезд с HTTP на HTTPS
Отдельный распространённый случай — подключение SSL-сертификата и переход на защищённый протокол.
Было:
http://site.ru/page/
Нужно:
https://site.ru/page/
Один из вариантов правила для Apache:
RewriteEngine On
RewriteCond %{HTTPS} ≠on
RewriteRule ^ %{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Здесь сохраняется исходный путь.
Поэтому адрес:
http://site.ru/catalog/item/
перейдёт именно на:
https://site.ru/catalog/item/
а не потеряет часть URL.
После включения такого правила стоит проверить несколько страниц сайта. Ошибка в условии может привести к циклическим переходам или затронуть больше запросов, чем планировалось.
Было:
http://site.ru/page/
Нужно:
https://site.ru/page/
Один из вариантов правила для Apache:
RewriteEngine On
RewriteCond %{HTTPS} ≠on
RewriteRule ^ %{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Здесь сохраняется исходный путь.
Поэтому адрес:
http://site.ru/catalog/item/
перейдёт именно на:
https://site.ru/catalog/item/
а не потеряет часть URL.
После включения такого правила стоит проверить несколько страниц сайта. Ошибка в условии может привести к циклическим переходам или затронуть больше запросов, чем планировалось.
Почему нельзя строить длинную цепочку
Представим, что страницу переносили несколько раз:
/page/
↓
/article/
↓
/blog/
Технически последний адрес доступен, но запрос проходит через два промежуточных шага.
Гораздо лучше привести конфигурацию к схеме:
/page/
↓
/blog/
То есть старый URL должен по возможности сразу указывать на конечный.
Google также рекомендует избегать цепочек и направлять пользователя непосредственно к финальному адресу.
Это особенно важно после нескольких последовательных изменений структуры. Старые правила иногда продолжают работать годами, хотя конечный адрес уже успел измениться.
/page/
↓
/article/
↓
/blog/
Технически последний адрес доступен, но запрос проходит через два промежуточных шага.
Гораздо лучше привести конфигурацию к схеме:
/page/
↓
/blog/
То есть старый URL должен по возможности сразу указывать на конечный.
Google также рекомендует избегать цепочек и направлять пользователя непосредственно к финальному адресу.
Это особенно важно после нескольких последовательных изменений структуры. Старые правила иногда продолжают работать годами, хотя конечный адрес уже успел измениться.
Что делать с удалёнными страницами
Здесь часто допускают одну ошибку: любую исчезнувшую страницу отправляют на главную.
Например, раньше существовала статья:
/blog/rezervnoe-kopirovanie/
Её удалили, а правило сделали таким:
/blog/rezervnoe-kopirovanie/ → /
Посетитель действительно попадёт на сайт, но не получит информацию, которую искал.
Если существует новая публикация на ту же тему, логичнее направить запрос туда.
Если подходящей замены нет, искусственный переход на главную может быть бессмысленным. Google отдельно предупреждает о проблемах с массовыми нерелевантными перенаправлениями на homepage.
Например, раньше существовала статья:
/blog/rezervnoe-kopirovanie/
Её удалили, а правило сделали таким:
/blog/rezervnoe-kopirovanie/ → /
Посетитель действительно попадёт на сайт, но не получит информацию, которую искал.
Если существует новая публикация на ту же тему, логичнее направить запрос туда.
Если подходящей замены нет, искусственный переход на главную может быть бессмысленным. Google отдельно предупреждает о проблемах с массовыми нерелевантными перенаправлениями на homepage.
Как проверить, что правило работает
После сохранения. htaccess не стоит сразу считать задачу законченной.
Возьмите несколько старых URL и проверьте каждый.
Нужно убедиться в четырёх вещах:
Старый адрес действительно открывает новую страницу.
Если вместо неё появляется ошибка сервера, правило составлено неправильно.
Используется нужный код.
Для окончательного переезда ожидается 301, а не временный 302.
Нет промежуточных переходов.
Старый адрес должен по возможности вести непосредственно к финальному.
Новая страница соответствует старой по смыслу.
Рабочий переход сам по себе ещё не означает, что маршрут настроен правильно.
Для массового переноса URL Google рекомендует тестировать правила и отслеживать состояние старых и новых адресов после запуска.
Возьмите несколько старых URL и проверьте каждый.
Нужно убедиться в четырёх вещах:
Старый адрес действительно открывает новую страницу.
Если вместо неё появляется ошибка сервера, правило составлено неправильно.
Используется нужный код.
Для окончательного переезда ожидается 301, а не временный 302.
Нет промежуточных переходов.
Старый адрес должен по возможности вести непосредственно к финальному.
Новая страница соответствует старой по смыслу.
Рабочий переход сам по себе ещё не означает, что маршрут настроен правильно.
Для массового переноса URL Google рекомендует тестировать правила и отслеживать состояние старых и новых адресов после запуска.
Внутренние ссылки после изменения структуры
Есть ещё одна деталь, которую легко пропустить.
Предположим, сайт уже перешёл на новый URL, но статьи внутри проекта продолжают ссылаться на старый:
/old-section/article/
Сервер каждый раз исправляет такой запрос, и человек в итоге получает нужную страницу.
Но правильнее заменить внутреннюю ссылку на актуальный вариант:
/new-section/article/
Так не создаётся лишний переход.
После серьёзного изменения структуры стоит также проверить:
Предположим, сайт уже перешёл на новый URL, но статьи внутри проекта продолжают ссылаться на старый:
/old-section/article/
Сервер каждый раз исправляет такой запрос, и человек в итоге получает нужную страницу.
Но правильнее заменить внутреннюю ссылку на актуальный вариант:
/new-section/article/
Так не создаётся лишний переход.
После серьёзного изменения структуры стоит также проверить:
- внутреннюю перелинковку;
- sitemap;
- canonical;
- ссылки в меню;
- хлебные крошки;
- страницы категорий.
Внутренние ссылки после изменения структуры
Есть ещё одна деталь, которую легко пропустить.
Предположим, сайт уже перешёл на новый URL, но статьи внутри проекта продолжают ссылаться на старый:
/old-section/article/
Сервер каждый раз исправляет такой запрос, и человек в итоге получает нужную страницу.
Но правильнее заменить внутреннюю ссылку на актуальный вариант:
/new-section/article/
Так не создаётся лишний переход.
После серьёзного изменения структуры стоит также проверить:
Предположим, сайт уже перешёл на новый URL, но статьи внутри проекта продолжают ссылаться на старый:
/old-section/article/
Сервер каждый раз исправляет такой запрос, и человек в итоге получает нужную страницу.
Но правильнее заменить внутреннюю ссылку на актуальный вариант:
/new-section/article/
Так не создаётся лишний переход.
После серьёзного изменения структуры стоит также проверить:
- внутреннюю перелинковку;
- sitemap;
- canonical;
- ссылки в меню;
- хлебные крошки;
- страницы категорий.
Как не сломать сайт при работе с. htaccess
Самая безопасная последовательность выглядит так:
Особенно осторожно нужно работать с универсальными выражениями вроде:
(.*)
Они способны охватить значительно больше URL, чем предполагалось.
- Сохранить резервную копию файла.
- Выписать старый и новый адрес.
- Определить, постоянное изменение или временное.
- Добавить одно правило.
- Проверить его работу.
- Только после этого добавлять следующую группу.
Особенно осторожно нужно работать с универсальными выражениями вроде:
(.*)
Они способны охватить значительно больше URL, чем предполагалось.
Как подготовить большой перенос
Для крупного сайта удобнее сначала составить таблицу
После этого становится понятно, какие страницы можно объединить одним шаблоном, а где потребуются отдельные условия.
Такой список полезен не только разработчику. По нему можно проверить, не потерялись ли важные страницы при изменении структуры.
При смене домена Google также рекомендует заранее подготовить карту соответствий и после запуска контролировать обработку старых и новых URL.
После этого становится понятно, какие страницы можно объединить одним шаблоном, а где потребуются отдельные условия.
Такой список полезен не только разработчику. По нему можно проверить, не потерялись ли важные страницы при изменении структуры.
При смене домена Google также рекомендует заранее подготовить карту соответствий и после запуска контролировать обработку старых и новых URL.
Что происходит после установки 301
Постоянное перенаправление не означает мгновенного исчезновения старого URL из поисковой выдачи.
Поисковику требуется время, чтобы снова обойти старые адреса, увидеть новый маршрут и обработать обновлённую структуру. При масштабной миграции некоторое время возможны колебания видимости страниц. Google рекомендует сохранять перенаправления достаточно долго; для переезда сайта ориентиром называется срок не менее года.
Поэтому после крупного изменения не стоит удалять правила через несколько дней только потому, что новые страницы уже появились в поиске.
Поисковику требуется время, чтобы снова обойти старые адреса, увидеть новый маршрут и обработать обновлённую структуру. При масштабной миграции некоторое время возможны колебания видимости страниц. Google рекомендует сохранять перенаправления достаточно долго; для переезда сайта ориентиром называется срок не менее года.
Поэтому после крупного изменения не стоит удалять правила через несколько дней только потому, что новые страницы уже появились в поиске.
Когда .htaccess лучше не трогать самостоятельно
Если на сервере уже настроено большое количество правил, используется сложная CMS или проект работает за прокси, CDN и несколькими уровнями серверной конфигурации, добавление нового условия без понимания существующей схемы может привести к конфликтам.
В таком случае сначала нужно посмотреть действующие правила.
Для простой страницы достаточно одной директивы. Для большого магазина с тысячами URL задача уже превращается в отдельную настройку маршрутизации.
В таком случае сначала нужно посмотреть действующие правила.
Для простой страницы достаточно одной директивы. Для большого магазина с тысячами URL задача уже превращается в отдельную настройку маршрутизации.
Короткая схема работы
Чтобы правильно выполнить перенос, сначала определите причину изменения адреса.
Если URL исчезает окончательно — используйте постоянное перенаправление. Если изменение временное — выбирайте временный вариант.
Затем сопоставьте старый и новый адреса. В .htaccess добавьте правило, проверьте ответ сервера и убедитесь, что запрос сразу приходит на нужную страницу.
После этого обновите внутренние ссылки, sitemap и canonical.
Главная идея проста: старый URL не должен превращаться в тупик. Он должен либо привести человека к актуальному содержимому, либо корректно сообщить, что подходящей страницы больше нет.
Если URL исчезает окончательно — используйте постоянное перенаправление. Если изменение временное — выбирайте временный вариант.
Затем сопоставьте старый и новый адреса. В .htaccess добавьте правило, проверьте ответ сервера и убедитесь, что запрос сразу приходит на нужную страницу.
После этого обновите внутренние ссылки, sitemap и canonical.
Главная идея проста: старый URL не должен превращаться в тупик. Он должен либо привести человека к актуальному содержимому, либо корректно сообщить, что подходящей страницы больше нет.
Первая встреча ни к чему не обязывает, но уже приносит пользу:
Онлайн-встреча с экспертом по маркетингу
Поиск точек роста бизнеса
Анализ unit-экономики и эффективности каналов
Выявление критических ошибок в маркетинге
Никаких шаблонных рекомендаций. Только выводы, основанные на вашей ситуации.