входим в Топ-20 агентствСклейка www, переход на HTTPS, слеш в конце, index.php, папки и список старых и новых адресов — готовый код для .htaccess или nginx. Собираем правила так, чтобы любой адрес открывался за один редирект, без цепочек.
/blog/* /articles/* — каждая страница на такую же в новой папке; /old-catalog/* /catalog/ — все страницы папки на одну. Своё правило: строка, которая начинается с ^, — регулярное выражение, в новом адресе можно использовать $1: ^news/(\d+)\.html$ /novosti/$1/.Считаем по этим правилам, без запроса к сайту. Цель — один редирект на любой адрес, без цепочек.
301 редирект говорит браузеру и поисковому роботу: страница переехала навсегда, вот её новый адрес. Посетитель попадает на нужную страницу, а Яндекс и Google заменяют в индексе старый адрес новым и передают ему накопленные ссылки и поведенческие сигналы. На сайтах с Apache (а это большинство shared-хостингов, включая Beget, Timeweb и REG.RU) редиректы настраиваются в файле .htaccess.
Ниже — готовые правила для всех типовых задач, объяснение, как они работают, и разбор ошибок, из-за которых редирект не срабатывает или уводит сайт в бесконечный цикл. Если не хочется собирать код вручную, заполните генератор выше: он учтёт CMS, сохранит UTM-метки и соберёт правила так, чтобы любой адрес открывался за один редирект.
site.ru и www.site.ru, http:// и https:// для поисковика — четыре разных сайта с одинаковым содержимым. Редирект оставляет один главный адрес. С 2018 года Яндекс не учитывает директиву Host в robots.txt — главное зеркало определяется только редиректом.http:// нужно перенаправить на https://.?id=15, переименованный раздел./index.php, /catalog//item/.| Код | Что означает | Когда использовать |
|---|---|---|
| 301 | Перемещено навсегда | Смена адреса, склейка зеркал, HTTPS, переезд. Самый частый вариант. |
| 302 | Временно | Страница на ремонте, временная акция, A/B-тест. В индексе остаётся старый адрес. |
| 307 | Временно, метод запроса сохраняется | Как 302, но форма, отправленная методом POST, останется POST. Нужен разработчикам API. |
| 308 | Навсегда, метод сохраняется | Как 301 для POST-запросов. Для обычных страниц разницы с 301 нет. |
| canonical | Не редирект, а подсказка | Обе страницы должны открываться (например, сортировка или фильтр каталога), но в индекс нужна одна. |
Если страница переехала, а вы поставили 302, поисковик долго держит в индексе старый адрес. Это частая причина того, что после смены структуры сайт «проседает» на месяцы.
Файл лежит в корневой папке сайта — там же, где index.php и robots.txt. На Beget это ~/site.ru/public_html/. Имя начинается с точки, поэтому файл скрытый: в файловом менеджере хостинга или FTP-клиенте включите показ скрытых файлов. Если файла нет, создайте обычный текстовый файл с именем .htaccess.
index.php. Правило, записанное ниже, до редиректа просто не дойдёт.Редиректы в .htaccess пишутся через модуль mod_rewrite. Блок начинается с RewriteEngine On, дальше идут пары «условия + правило»:
RewriteCond %{HTTP_HOST} ^www\.site\.ru$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]https://site.ru/catalog/ шаблон видит catalog/.%1 — то же самое из последнего условия RewriteCond.| Флаг | Что делает |
|---|---|
R=301 | Внешний редирект с кодом 301. Без кода Apache отдаст 302. |
L | Последнее правило: дальше не проверять. Ставится почти всегда вместе с R. |
NC | Без учёта регистра букв. |
QSA | Дописать к новому адресу исходные GET-параметры, если в новом адресе уже есть свои. |
NE | Не кодировать спецсимволы повторно — нужен, если в новом адресе есть %D0%B0 и подобное. |
Есть и простая директива Redirect 301 /old.html https://site.ru/new/ из модуля mod_alias. Она удобна для одной-двух страниц, но у неё две ловушки: она срабатывает на все адреса, которые начинаются с указанного (/old/ заберёт и /old/page/), и выполняется отдельно от mod_rewrite, так что при смешении двух способов порядок правил становится непредсказуемым. Если в файле уже есть RewriteRule, пишите редиректы тоже через RewriteRule.
Все примеры вставляются после строки RewriteEngine On. Замените site.ru на свой домен.
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]Второе условие важно. На многих хостингах перед Apache стоит nginx или CDN (например, Cloudflare): HTTPS-соединение принимает он, а Apache получает запрос уже по HTTP. Без проверки заголовка X-Forwarded-Proto сервер будет перенаправлять на HTTPS бесконечно — браузер покажет ERR_TOO_MANY_REDIRECTS.
# www.site.ru → site.ru
RewriteCond %{HTTP_HOST} ^www\.site\.ru$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]
# site.ru → www.site.ru
RewriteCond %{HTTP_HOST} ^site\.ru$ [NC]
RewriteRule ^(.*)$ https://www.site.ru/$1 [R=301,L]Какой вариант выбрать — неважно для поисковиков. Важно выбрать один и использовать его везде: во внутренних ссылках, sitemap.xml, рекламе и Вебмастере.
Если поставить правило для HTTPS и правило для www по отдельности, адрес http://www.site.ru/page сначала уйдёт на https://www.site.ru/page, а затем на https://site.ru/page. Это цепочка из двух редиректов: робот тратит лишний запрос, страница открывается медленнее. Решение — в каждом правиле сразу вести на окончательный адрес и начинать с правила для зеркала:
RewriteCond %{HTTP_HOST} ^www\.site\.ru$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]Теперь любая из четырёх версий адреса попадает на https://site.ru/page за один шаг. Генератор выше собирает правила именно так — и показывает, сколько редиректов будет для разных адресов.
# /catalog → /catalog/
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(\.[a-z0-9]{1,5}|/)$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1/ [R=301,L]
# /catalog/ → /catalog
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ https://site.ru/$1 [R=301,L]Условия защищают то, что ломать нельзя: файлы (/robots.txt, /sitemap.xml, картинки), настоящие папки на сервере и отправку форм методом POST — при редиректе данные формы теряются. Формат слеша выбирайте по тому, как адреса уже записаны в ссылках сайта и в sitemap.xml, чтобы не перенаправлять половину сайта.
RewriteCond %{THE_REQUEST} \s/[^?\s]*index\.(php|html?)[?\s] [NC]
RewriteRule ^(.*/)?index\.(php|html?)$ https://site.ru/$1 [R=301,L,NC]Условие с %{THE_REQUEST} проверяет адрес, который запросил посетитель, а не внутренний. Без него правило перехватит собственное обращение CMS к index.php, и сайт уйдёт в цикл.
RewriteRule ^old-page\.html$ https://site.ru/new-page/ [R=301,L]
RewriteRule ^catalog/divany/?$ https://site.ru/catalog/myagkaya-mebel/divany/ [R=301,L]Точки и другие спецсимволы в шаблоне экранируются обратным слешем. /? в конце означает «слеш может быть, а может не быть» — одно правило ловит оба варианта старого адреса. Новый адрес пишите полностью, с протоколом и доменом: так не будет второго редиректа на главное зеркало.
RewriteCond %{QUERY_STRING} ^id=15$
RewriteRule ^catalog/item\.php$ https://site.ru/catalog/divany/? [R=301,L]RewriteRule не видит часть адреса после ? — параметры проверяются отдельным условием. Знак вопроса в конце нового адреса отбрасывает старые параметры, иначе получится /catalog/divany/?id=15.
# /blog/любой-адрес → /articles/любой-адрес
RewriteRule ^blog/(.*)$ https://site.ru/articles/$1 [R=301,L]Подходит, когда меняется только начало адреса, а всё остальное остаётся прежним. В генераторе выше такое правило записывается одной строкой: /blog/* /articles/*. Если весь старый раздел нужно отправить на одну страницу — /old-catalog/* /catalog/. Если адреса внутри раздела меняются по-разному, нужен список «старый → новый» по каждой странице, а правило для папки поставьте ниже — оно подхватит всё, что не попало в список.
RewriteCond %{HTTP_HOST} ^(www\.)?old-site\.ru$ [NC]
RewriteRule ^(.*)$ https://new-site.ru/$1 [R=301,L]Каждая страница старого домена ведёт на такую же страницу нового. Не перенаправляйте весь старый сайт на главную нового: поисковики воспринимают это как удаление страниц, и позиции по внутренним страницам теряются.
В .htaccess домен на кириллице записывается в punycode — так, как его видит сервер. пример.рф превращается в xn--e1afmkfd.xn--p1ai:
RewriteCond %{HTTP_HOST} ^www\.xn--e1afmkfd\.xn--p1ai$ [NC]
RewriteRule ^(.*)$ https://xn--e1afmkfd.xn--p1ai/$1 [R=301,L]Генератор переводит кириллический домен в punycode сам.
RewriteEngine On, выше строк с bitrix/urlrewrite.php. Исключите из редиректов файл обмена с 1С /bitrix/admin/1c_exchange.php: если 1С обращается к сайту по HTTP, редирект на HTTPS может сломать выгрузку товаров. Папки /bitrix/ и /upload/ не трогайте правилами для слеша.# BEGIN WordPress и # END WordPress, WordPress перезаписывает сам при сохранении настроек постоянных ссылок. Ставьте свои правила выше этого блока. Главный адрес сайта также должен совпадать в «Настройки → Общие», иначе WordPress сам будет перенаправлять обратно.ht.access уже есть закомментированные примеры для www и HTTPS — используйте их или свои правила, но не оба набора сразу. Свои правила ставьте после RewriteBase /, выше блока «The Friendly URLs part».RewriteBase / или RewriteEngine On, выше правил SEO-адресов CMS.На VPS с одним nginx (например, под FASTPANEL или ISPmanager в режиме «только nginx») файл .htaccess не читается вообще — правила в нём ничего не меняют. Редиректы пишутся в конфигурации сайта:
server {
listen 80;
server_name site.ru www.site.ru;
return 301 https://site.ru$request_uri;
}
# внутри основного server { … }:
rewrite "^/old-page\.html$" "https://site.ru/new-page/" permanent;После правки проверьте синтаксис командой nginx -t и перезагрузите конфигурацию. Генератор показывает те же правила для nginx на отдельной вкладке. Если nginx стоит перед Apache (так устроено большинство shared-хостингов), используйте .htaccess.
X-Forwarded-Proto, или один и тот же редирект включён дважды: в .htaccess и в панели хостинга (или в настройках CMS, или в Cloudflare).? и + — служебные знаки. ^page.html$ поймает и pagexhtml; правильно — ^page\.html$.^item\.php\?id=15$ никогда не сработает — параметры проверяются через RewriteCond %{QUERY_STRING}.curl.До загрузки на сервер — в песочнице для .htaccess. Вставьте свой файл целиком, вместе с правилами CMS, и список адресов: для каждого адреса видно, какая строка сработала, какое условие не прошло и почему, куда уйдёт посетитель и сколько будет редиректов. Код из генератора открывается там одной кнопкой «Проверить в песочнице».
После загрузки:
curl -I http://www.site.ru/page — в ответе будет строка HTTP/1.1 301 и заголовок Location с новым адресом.Все типовые правила с разбором ошибок собраны в полном справочнике 301 редиректа.
В корневой папке сайта — там же, где index.php (на Beget это папка public_html). Файл скрытый: включите показ скрытых файлов в файловом менеджере или FTP-клиенте. Если файла нет, создайте текстовый файл с именем .htaccess в кодировке UTF-8 без BOM.
301 — постоянное перемещение: поисковики заменяют старый адрес новым и передают ему накопленные сигналы. 302 — временное: в индексе остаётся старый адрес. Для смены адресов, склейки зеркал и перехода на HTTPS нужен 301.
Обычно это цикл: правило перенаправляет адрес сам на себя. Чаще всего так бывает с HTTPS за прокси или CDN — сервер не видит, что запрос уже пришёл по HTTPS. Добавьте условие RewriteCond %{HTTP:X-Forwarded-Proto} !https, как делает генератор, и проверьте, что одно и то же правило не задано дважды — в .htaccess и в панели хостинга.
Да. Без редиректа site.ru и www.site.ru — два разных сайта с одинаковым содержимым. Поисковик сам выберет главное зеркало, а ссылки и поведенческие сигналы разделятся между двумя адресами.
Частые причины: правила стоят ниже правил CMS и до них не доходит очередь; на сервере только nginx без Apache, и .htaccess не читается; отключён mod_rewrite; браузер закэшировал старый 301 — проверяйте в режиме инкогнито или командой curl -I.
На nginx .htaccess не работает: правила пишутся в конфигурации сайта (блок server) директивами return 301 и rewrite … permanent, после чего конфигурацию нужно перезагрузить. Генератор показывает тот же набор правил для nginx на отдельной вкладке.
Составим карту редиректов для всех страниц, настроим их без потери позиций и проследим за переиндексацией в Вебмастере.
Любые коммерческие сведения, ставшие известными нашей компании в ходе совместной работы над проектом, признаются конфиденциальными. Мы обязуемся не разглашать их и не предоставлять иным лицам без вашего согласия
Раз в месяц присылаем подборку лучших материалов, практических кейсов и инсайдов интернет-маркетинга. Только самое важное, что поможет расти вашему бизнесу.
Иногда проще спросить, чем искать самому
8 800 101-81-85исследование точек роста и разработка стратегии продвижения в подарок
