Как настроить 301 редиректы через .htaccess и Nginx в 2026

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

Что такое 301 редирект и когда он реально нужен

Если коротко, 301 — это постоянный редирект. Сервер отвечает: «страница переехала навсегда, иди сюда». Для пользователя это почти незаметно, а для поисковых систем это сигнал передать большую часть веса на новый адрес. Грубо говоря, если у вас была страница /catalog/iphone-13/, а стала /apple/iphone-13/, 301 — это нормальный способ не терять накопленный SEO-потенциал.

Я часто вижу одну и ту же ошибку: редиректы ставят только на главную, а все внутренние URL оставляют как есть. Это плохая идея. Поисковик не обязан сам «догадываться», что /old-page/ теперь стала /new-page/. И если таких URL десятки или сотни, сайт начинает раздавать 404, а потом люди удивляются просадке трафика. У меня был клиент на WordPress 6.6 и PHP 8.2: после смены структуры URL они потеряли почти 18% органики просто потому, что редирект сделали не по карте, а «как получится».

301 нужен не только при переезде домена. На практике я ставлю его в таких случаях:

• смена домена или зеркала;
• переход с HTTP на HTTPS;
• склейка www и без www;
• смена структуры каталога или slug у товаров;
• удаление устаревших страниц и перенос их на релевантные новые;
• исправление дублей с параметрами, слэшами и регистром;
• миграция с одной CMS на другую — например, с WordPress на Битрикс;
• после редизайна, когда URL меняются из-за новой архитектуры.

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

Как работает 301 на уровне сервера и почему это не «просто строка в конфиге»

301 можно реализовать на уровне Apache через .htaccess, на уровне Nginx через server и location, а иногда — уже в PHP-коде, если по-другому никак. Но я всегда говорю: если есть возможность сделать редирект на сервере, делайте его там. Это быстрее, чище и надёжнее. PHP-редирект — запасной вариант, а не основной инструмент.

С точки зрения запроса всё выглядит просто. Браузер обращается к старому URL, сервер отвечает кодом 301 и заголовком Location: https://site.ru/new-url/. После этого клиент идёт по новому адресу. Но есть нюанс: если редиректов слишком много, появляются цепочки. А цепочки — это лишние запросы, замедление загрузки и риск потерять часть веса. Иногда я видел цепочку из трёх-четырёх переадресаций: HTTP → HTTPS → без www → новая структура → канонический URL. Это уже перебор.

На моей практике в 2026 году чаще всего всплывают три проблемы:

• неверный порядок правил, из-за которого срабатывает не тот редирект;
• циклы, когда URL редиректит сам на себя или по кругу;
• конфликт с CMS, когда правила сервера пересекаются с логикой WordPress или Битрикс.

Если у вас уже есть HTTP→HTTPS, www→без www и ещё куча старых страниц, я советую сначала посмотреть общий порядок переадресаций в связке с настройкой домена. Очень полезно почитать как настроить HTTP→HTTPS и канонические URL в 2026 году и как настроить переадресацию с HTTP на HTTPS и WWW в 2026. Там хорошо видно, как не запутаться на базовом уровне.

Как настроить 301 редиректы через .htaccess

.htaccess — это классика для Apache. Если сайт работает на Apache или LiteSpeed, то именно здесь чаще всего и живут правила редиректа. Честно говоря, для небольших и средних проектов это удобный вариант: изменил файл, очистил кэш, проверил ответ сервера — и готово.

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

Базовые правила

Если нужен один конкретный редирект, используйте простое правило:

Redirect 301 /old-page/ https://example.com/new-page/

Это простой и рабочий вариант. Но я чаще использую mod_rewrite, потому что так проще делать сложные условия и массовые правила.

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteRule ^old-page/?$ /new-page/ [R=301,L]
RewriteRule ^catalog/([0-9]+)/?$ /product/$1/ [R=301,L]
</IfModule>

Вторая строка — типичный кейс, когда нужно перенести старые числовые URL на новые. Но тут есть нюанс: если вы передаёте ID, проверьте, что новая структура действительно умеет его принимать. Если нет — лучше делать точную карту соответствий, а не пытаться «угадать» шаблоном.

Редирект с http на https и с www

Если сайт ещё не полностью переведён на HTTPS, лучше сначала закрыть этот вопрос. Иначе редиректы будут жить в полусломанном состоянии. Я обычно настраиваю так:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>

Это нормальный базовый вариант для Apache. Но если у вас уже есть отдельная логика для www и без www, аккуратнее: не смешивайте всё в одну кучу. Сначала решите, какое зеркало главное, потом стройте остальную схему. Иначе редиректы начнут спорить между собой.

Типичные ошибки в .htaccess

Ошибка номер один — забыть про слэш в конце. Например, /old-page и /old-page/ сервер может воспринимать как разные адреса. Ошибка номер два — ставить редирект после CMS-правил, когда часть запросов уже перехвачена системой. Ошибка номер три — применять regex там, где нужен точный адрес. На деле это приводит к неожиданным совпадениям.

Для WordPress я обычно отдельно проверяю, не конфликтует ли .htaccess с правилами пермалинков. Для Битрикса — смотрю, не перекрывают ли редиректы обработку urlrewrite.php. Если сайт на WordPress, советую ещё заглянуть в как ускорить WordPress: практическое руководство — там видно, почему лишние серверные цепочки бьют и по скорости, и по стабильности.

Как настроить 301 редиректы в Nginx

Nginx — это мой любимый вариант для редиректов на продакшене. Если конфигурация сделана нормально, она работает быстро, прозрачно и без сюрпризов. Особенно это заметно на проектах под PHP 8.2 и 8.3, где Nginx часто стоит в связке с PHP-FPM 8.2/8.3, Redis и OPcache. Там серверные правила должны быть короткими и понятными.

Главная идея в Nginx простая: редиректы лучше делать в отдельном server-блоке или внутри location, если это точечное правило. Я обычно не делаю редиректы через PHP, если могу решить всё на уровне конфигурации. Это и быстрее, и надёжнее.

Простой редирект в server-блоке

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Это базовый и очень полезный шаблон. Он переводит весь трафик с HTTP на HTTPS и сразу убирает www. Но если у вас отдельные поддомены, сначала проверьте, не затронет ли это нужные зоны. Я один раз видел, как подобное правило случайно уводило ещё и api.example.com. Потом пришлось быстро всё откатывать из бэкапа.

Редирект конкретной страницы

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

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

location ^~ /catalog/old-category/ {
    return 301 https://example.com/catalog/new-category/;
}

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

Редирект с сохранением URI

Иногда нужно просто сменить домен или основной хост, сохранив весь путь и параметры:

server {
    listen 443 ssl http2;
    server_name old-domain.ru;
    return 301 https://new-domain.ru$request_uri;
}

Это удобный сценарий при миграции. Кстати, про сам переезд у меня есть подробный материал как перенести сайт на другую CMS, а если речь именно о переезде с потерей старых URL и восстановлением логики SEO, то полезно держать под рукой как настроить sitemap при переезде сайта в 2026 году.

Редиректы при смене URL и структуры сайта

Вот здесь начинается самая интересная часть. Если меняется не только домен, а вся архитектура сайта, то одного шаблона уже мало. Нужна карта соответствий: старый URL → новый URL. И чем крупнее сайт, тем важнее эта таблица. Для интернет-магазина на 10 000 товаров это вообще не опция, а обязательный этап.

На практике я всегда прошу выгрузку URL из старого сайта, список новых адресов и хотя бы черновую матрицу соответствий. Если этого нет, редиректы превращаются в ручную угадайку. А угадайка в SEO — это плохая идея. Лучше потратить пару часов на таблицу, чем потом месяц разбирать просадку в трафике.

Как я обычно делаю карту редиректов

1. Собираю список старых URL из XML sitemap, логов, Screaming Frog, Яндекс.Вебмастера и Google Search Console.
2. Сверяю, какие страницы реально были в индексе и приносили трафик.
3. Сопоставляю старые и новые адреса по смыслу, а не только по шаблону.
4. Отдельно проверяю категории, товары, статьи и служебные страницы.
5. Тестирую, чтобы не было цепочек и 404.

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

Если нужно массово перенести старую структуру в новую, я иногда использую правило с маской, но только когда структура действительно совпадает. Например:

RewriteRule ^blog/([0-9]{4})/([a-z0-9-]+)/?$ /articles/$2/ [R=301,L]

Но честно говоря, я не люблю слишком умные регулярки. Они красивы ровно до того момента, пока клиент не добавит исключение. После этого поддержка становится мучением. Для долгоживущих проектов я предпочитаю явные списки или автогенерацию правил из CSV/JSON.

Проверка и отладка редиректов без сюрпризов

После настройки 301 редиректов я всегда проверяю не только сам факт переадресации, но и весь путь запроса. В 2026 году браузерный кэш, CDN и прокси-серверы вполне могут скрыть проблему. Поэтому я обычно использую несколько инструментов сразу: curl, браузерные DevTools, Screaming Frog и серверные логи.

Простейшая команда для проверки:

curl -I https://example.com/old-page/

В ответе должно быть что-то вроде:

HTTP/2 301
location: https://example.com/new-page/

Если видите 302 вместо 301 — это уже ошибка. Если видите несколько Location подряд — у вас цепочка. Если ответ вообще 200, значит правило не сработало. И вот тут многие начинают чинить не там, где сломалось. Сначала проверяйте сервер, потом CMS, потом CDN, потом кэш.

Для сайтов с CDN и кэшем вопрос сложнее. Я не раз ловил ситуацию, когда правило уже исправили, а на Edge-серверах Cloudflare или другом CDN ещё висела старая версия. Поэтому после изменения редиректов я обычно делаю purge кэша. Это особенно актуально, если сайт использует CDN для сайта или агрессивное кэширование.

И ещё момент. Если редиректы массовые, проверьте логи. На больших проектах я часто смотрю access.log и error.log, чтобы увидеть неожиданные запросы. Часто именно там всплывает старый URL из письма, рекламной кампании или внешней ссылки, о которой уже забыли.

SEO и технические нюансы в 2026 году

Сами по себе 301 редиректы не магия. Они работают в связке с canonical, sitemap, robots.txt, заголовками и страницами ошибок. Если у вас сайт после переезда всё ещё отдаёт старые URL в sitemap, а canonical указывает на несуществующий адрес, 301 уже не спасает полностью. Поэтому я всегда проверяю редиректы вместе с общей SEO-техничкой.

Очень полезно держать рядом статьи по сопутствующим темам, например аудит robots.txt и XML Sitemap на сайте в 2026 году и как настроить canonical URL для SEO в 2026 году. Это помогает не сделать редирект, который потом конфликтует с индексацией.

Ещё один момент — скорость. Да, один 301 сам по себе не критичен. Но если у вас цепочки и десятки лишних переходов, Core Web Vitals страдают. Особенно заметно это на мобильных устройствах и при слабом соединении. У меня был случай на интернет-магазине с 40 000 страниц: после вычищения цепочек PageSpeed Insights на мобильных поднялся с 62 до 78, а LCP стал стабильнее примерно на 0,4–0,6 секунды. Не космос, но в коммерции это уже чувствуется.

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

Типичные ошибки и как их избежать

Самая частая ошибка — делать редиректы «в лоб» без тестирования. Вторая — редиректить всё на главную. Третья — оставлять старые страницы в индексе, надеясь, что поисковик сам всё поймёт. Не поймёт, если вы не помогли ему правильно.

Вот список того, что я проверяю почти всегда:

• нет ли циклов редиректа;
• нет ли цепочек из 2+ переходов;
• нет ли 302 там, где нужен 301;
• сохраняются ли UTM-метки и query string, если они нужны;
• нет ли конфликтов между Apache/Nginx и CMS;
• отдаются ли корректные коды в браузере и через curl;
• обновлены ли sitemap и canonical;
• не сломались ли изображения, скрипты и внутренние ссылки.

Если проект большой, я ещё советую поставить мониторинг битых ссылок и 404-ошибок. Хорошо работает связка с уведомлениями в Telegram — тогда вы видите проблемы почти сразу. Посмотрите, кстати, 404-мониторинг и уведомления о битых ссылках в 2026 и настройка 404-мониторинга сайта и Telegram-уведомлений. Это очень полезно, когда сайт живой и постоянно меняется.

Если у вас уже есть десятки или сотни редиректов, поддерживать их вручную — сомнительное удовольствие. Тогда я обычно делаю либо отдельный блок правил в Nginx, либо выношу логику в конфиг через генерацию. Иногда даже проще хранить карту редиректов в таблице и автоматически собирать конфиг при деплое. Для проектов на Laravel это особенно удобно, потому что можно связать карту с деплоем и тестами.

Когда лучше отдать настройку специалисту

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

На практике ко мне часто приходят уже после неудачного запуска. Сайт переехал, URL поменялись, 301 вроде бы поставили, но в Search Console выросли ошибки, в Яндекс.Вебмастере появились странные дубли, а трафик просел. И почти всегда причина одна: редиректы сделали частично или с лишними переходами. В таких случаях я сначала останавливаю хаос, потом составляю карту старых и новых URL, а уже потом вношу правки через серверную конфигурацию и CMS.

Если вам нужно не просто «поставить пару строк», а нормально выстроить логику переадресаций, внутренних ссылок и технической части, лучше сразу заказывать доработку сайта. Если нужно оценить масштаб работ и понять, во что это выльется по бюджету, можно сначала открыть калькулятор стоимости сайта и прикинуть фронт работ. Я обычно именно так и делаю с новыми проектами: сначала оценка, потом план, потом внедрение.

И да, если у вас Bitrix, WordPress или Laravel — это не меняет принципа. Меняется только способ внедрения. На Bitrix я чаще смотрю на .htaccess и компонентные роуты, на WordPress — на структуру пермалинков и плагины редиректов, на Laravel — на маршруты и серверную обвязку Nginx. Но логика одна: старый URL должен вести на новый один раз, без цирка и без потерь.

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