Редирект в nginx: настройка без циклов и потери SEO

Почему редиректы задают на уровне сервера

В nginx нет файлов .htaccess, привычных по Apache. Правила лежат в конфигурации сервера, а после правки её нужно перезагрузить. Для этого нужен доступ к VPS или хостингу, зато ответ 301 уходит быстро и предсказуемо.

Для SEO редиректы нужны в трёх типичных ситуациях: сайт переезжает на https, вы выбираете основной адрес (с www или без), после редизайна меняются адреса страниц. Код 301 сообщает поисковику, что новый адрес постоянный, и помогает сохранить накопленный вес страницы. А люди, пришедшие по старым ссылкам из Instagram, с OLX, из Telegram-каналов и рассылок, не упираются в ошибку 404.

Return или rewrite: что выбрать

Директива return сразу отдаёт код ответа и новый адрес. Rewrite работает по регулярному выражению и нужен, когда часть пути надо перенести по шаблону. Простое правило: если можно обойтись return, используйте его, конфигурация будет читаться легче.

Самая частая путаница связана с флагами. Rewrite без флага permanent или redirect выполняет внутреннюю перезапись: в браузере адрес не меняется, и поисковик никакого редиректа не видит. Флаг permanent даёт 301, redirect даёт временный 302. Для переезда страницы нужен именно 301.

Одно главное зеркало: www, http и https

Вынесите все неосновные варианты адреса в отдельные блоки server, которые только перенаправляют. Основной блок при этом обслуживает единственный адрес, например https://example.uz.

server { listen 80; listen 443 ssl; server_name www.example.uz; # сертификат, покрывающий и www return 301 https://example.uz$request_uri; } server { listen 80; server_name example.uz; return 301 https://example.uz$request_uri; }

Переменная $request_uri сохраняет путь и параметры, поэтому посетитель попадает на ту же страницу, а не на главную. Любой вариант должен вести на финальный адрес за один шаг. Отдельно проверьте сертификат: если он не покрывает www, браузер покажет предупреждение раньше, чем сработает редирект.

Перенос одной страницы и целого раздела

Для одной страницы подойдёт точное совпадение со знаком равенства. Допустим, интернет-магазин объединил две страницы доставки в одну:

location = /dostavka-tashkent/ { return 301 /dostavka/; } location ^~ /stati/ { rewrite ^/stati/(.*)$ /blog/$1 permanent; }

Второе правило переносит весь раздел и сохраняет окончание адреса. Ведите старую страницу на самую близкую по смыслу новую, а не на главную: массовые переходы на главную поисковики нередко воспринимают как мягкую ошибку 404.

Сотни адресов после редизайна: карта map

Когда меняются адреса всего каталога, писать сотни блоков location неудобно. Директива map сопоставляет старые адреса с новыми по таблице, которую можно держать в отдельном файле и собирать из таблицы Excel.

map $uri $new_uri { default ""; include /etc/nginx/redirects.map; } server { if ($new_uri) { return 301 $new_uri$is_args$args; } }

Ключом здесь взят $uri, а не $request_uri: так метки utm из рекламы не мешают найти совпадение, а мы возвращаем их в конце адреса. Условие if на уровне server с одним return безопасно, а сложную логику внутри location лучше не строить.

Откуда берутся циклы и цепочки

Браузер пишет о слишком большом числе перенаправлений, когда правило срабатывает и на адресе назначения. Обычно причина в одном из пунктов:

• прокси или Cloudflare сам делает https и передаёт в nginx запрос по http, а nginx снова отправляет его на https
• правило добавления слеша спорит с приложением, которое слеш убирает
• одно и то же правило прописано и во внешнем nginx, и внутри Docker-контейнера
• общее правило задевает sitemap.xml и robots.txt, и файлы перестают открываться
• после второго переезда старые редиректы ведут на уже устаревшие адреса, получается цепочка из нескольких шагов

Применение правок, проверка и когда нужна помощь

Платёжные адреса Click и Payme и webhook Telegram-бота лучше исключить из общих правил и проверить отдельно: редирект на таких запросах легко ломает обработку.

Порядок работы такой: сохраните копию текущей конфигурации, проверьте синтаксис командой nginx -t, затем мягко перезагрузите конфигурацию через reload без остановки сервера. После этого проверьте через curl -I зеркала, старые и новые адреса и убедитесь, что цепочка состоит из одного шага. Откройте сайт в режиме инкогнито и пройдитесь по страницам, которые не должны перенаправляться. После запуска сверьте отчёты Search Console.

Редиректы редко живут отдельно: они связаны со структурой сайта, картой sitemap, канонические адреса и рекламные ссылки. Если вы готовите переезд или не уверены в текущих правилах, команда markdev проведёт аудит и поможет всё настроить без потери позиций в рамках SEO-оптимизации сайта в Узбекистане. Опишите задачу, и мы обсудим, с чего начать.