301 редирект — это ответ сервера, в котором сказано: страница переехала навсегда, иди на новый адрес. Нужен он ровно в четырёх случаях: вы сменили домен, сменили адрес страницы, перевели сайт на HTTPS или свели вместе версии с www и без. Во всех четырёх без редиректа старый адрес остаётся в поиске отдельной страницей и конкурирует с новой.
Это вся теория. Дальше начинается то, из-за чего переезды ломаются: кода 301 недостаточно, потому что важно, откуда и куда он ведёт, сколько он стоит и какой код реально отдаёт сервер, а не какой вы хотели поставить. Я открыл справки Яндекса, Google, Тильды, Битрикса, nginx и Apache, выписал оттуда сроки и ограничения, а потом прогнал восемнадцать живых сайтов командной строкой и посмотрел, что они отдают на самом деле.
В выдаче по запросу «301 редирект страницы» я разобрал четырнадцать страниц. Рецептов для .htaccess там много — у одной страницы их двадцать два блока кода. А вот ни одной дословной цитаты из справки и ни одного официального срока нет ни у кого: все четырнадцать пересказывают первоисточники своими словами, и половина пересказывает друг друга.
01Четыре кода, а не один: что робот делает с каждым
Постоянных кодов перенаправления два, временных — три. Справка Вебмастера делит их одной строкой: «301/308 — постоянное перенаправление; 302/303/307 — временное перенаправление; перенаправление с использованием метатега refresh при небольших задержках считается временным перенаправлением».
| Код | Что это по справке Яндекса | Что делает Google | Когда применять |
|---|---|---|---|
| 301 | «Ресурс перемещен навсегда». Робот старую страницу не индексирует, но «проиндексирует страницу, на которую установлено перенаправление» | «Поисковые роботы выполняют переход в переадресации, и системы Google считают ее весомым поводом для обработки целевой страницы» | Основной случай: страница или домен переехали |
| 308 | «Ресурс перемещен навсегда». Использовать, «когда важно сохранить» метод запроса, тело запроса и заголовки | «Аналогично коду 301. Google обрабатывает эти коды статуса одинаково, однако семантически они разные» | Когда по адресу ходит форма или API, а не человек |
| 302 | «Ресурс временно перемещен». Использовать «только для временных перенаправлений» — тесты страниц и технические работы | «Поисковые роботы выполняют переход… но системы Google считают ее недостаточно весомым поводом для обработки целевой страницы» | Короткая заглушка на время работ |
| 307 | «Временное перенаправление». Применять, когда важно сохранить метод, тело и заголовки запроса | Временная переадресация: «в результатах поиска показывается исходная страница» | Временная подмена для формы или API |
Разница между 301 и 308 — не формальность, и именно она объясняет половину поломок после переезда. В RFC 9110 к описанию 301 приписана отдельная сноска: «For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead». То есть браузер, получив 301 на отправку формы, имеет полное право превратить POST в GET — и данные формы потеряются. У Apache это сказано ещё прямее, в документации к директиве Redirect: «Note that POSTs will be discarded».
Практический вывод простой. Адреса, по которым ходят люди, переводите кодом 301. Адреса, на которые что-то отправляется — приём заявки, вебхук платёжной системы, обмен с 1С, — либо кодом 308, либо не трогайте вовсе.
И ещё одна строчка из RFC, которая объясняет самый частый вопрос «я поправил редирект, а он всё равно ведёт не туда»: «A 301 response is heuristically cacheable». Браузер кеширует постоянное перенаправление и будет ходить по старому правилу, даже когда на сервере уже новое. Справка Тильды предупреждает о том же своими словами: «Результаты переадресации могут кешироваться браузером. Часто при изменении адреса редиректа будет срабатывать старое правило».
02Замер: какой код отдают восемнадцать живых сайтов
Чужие статьи объясняют, как редирект поставить. Я решил посмотреть, как он стоит у тех, кто этим зарабатывает. Взял двадцать сайтов платформ, хостингов, регистраторов и CRM, запросил у каждого http://домен/ и http://www.домен/ и записал, какой код приходит первым и сколько переходов до кода 200. Замер сделан 2 октября 2026 года обычным curl без браузера.
Два сайта из двадцати в выборку не попали: mottor.pro не отвечал на соединение вовсе, а tilda.cc на второй запрос ответил кодом 410 с текстом про автоматическую блокировку — по нему сравнивать нечего. Осталось восемнадцать, то есть тридцать шесть проверок.
Что отдаёт сервер на http:// |
Сколько сайтов из 18 |
|---|---|
| 301 — постоянное перенаправление | 14 |
| 308 — постоянное, с сохранением метода | 1 (moysklad.ru) |
| 302 — временное перенаправление | 1 (craftum.com) |
| Никакого перенаправления, сразу 200 | 2 (reg.ru, nic.ru) |
Три результата из четырёх строк этой таблицы стоит разобрать отдельно.
302 вместо 301. craftum.com переводит посетителя с HTTP на HTTPS временным кодом. Справка Вебмастера про 302 говорит ровно обратное: применять «только для временных перенаправлений» — «при проведении сравнительных тестов страниц», «во время технических работ», — и добавляет: «Если перенаправление планируется постоянным — используйте код 301». Перевод на HTTPS постоянный по определению.
Отсутствие перенаправления. reg.ru и nic.ru отвечают по HTTP кодом 200 и не переводят на HTTPS. Для робота это означает, что http://домен/ и https://домен/ — два разных сайта: справка Вебмастера формулирует это прямо, говоря про несколько адресов одного домена, и предупреждает, что «адреса начинают конкурировать между собой в результатах поиска».
Длина цепочки. У пятнадцати сайтов из восемнадцати путь от http:// до 200 — один переход. У beget.com и moysklad.ru — два, у ecwid.ru — три, а beget.com с префиксом www проходит три перехода. Google разрешает до десяти: «поисковые роботы Google выполняют до 10 переходов в цепочке переадресаций», — но тут же просит так не делать: «Пусть их будет максимум четыре, а лучше три или два. Длинные цепочки переадресации замедляют загрузку страниц и поддерживаются не всеми агентами пользователя или браузерами». Каждый лишний переход — это лишний запрос к серверу на каждом заходе. В замере, из чего складывается время до первого экрана, такие переходы попадают в самое начало цепочки — то есть добавляются ко всем остальным задержкам, а не вместо них.
03Переезд, сделанный до половины: что я нашёл во втором замере
Второй проход был про то, что происходит не с главной страницей, а с внутренними. Я запросил у тех же восемнадцати сайтов заведомо несуществующий адрес.
Шестнадцать из восемнадцати в итоге ответили кодом 404 — правильно. Два ответили кодом 200: reg.ru и nic.ru на запрос https://reg.ru/net-takoy-stranicy-12345/ и https://nic.ru/net-takoy-stranicy-12345/ отдают 200 OK без заголовка Location. Для робота это значит, что страница существует, и любой придуманный адрес на этих домах — отдельная индексируемая страница.
А самое интересное нашлось у ecwid.ru. Главная страница там переезжает на другой домен: https://ecwid.ru/ отвечает 301 на https://www.ecwid.ru/, а тот — 301 на https://www.ecwid.com/. Но внутренняя страница остаётся на месте: https://www.ecwid.ru/pricing отвечает 200 OK и никуда не ведёт. То есть домен переехал только главной страницей.
Справка Вебмастера описывает такой переезд как незакрытый. Она требует двух перенаправлений, а не одного: «С главной страницы старого сайта на главную страницу нового. Это необходимо для правильного переезда» и «С внутренних страниц старого сайта на аналогичные страницы нового. Это позволит передать показатели новым страницам, а также поможет посетителям сайта находить нужную им информацию». Половина работы — это не половина результата: показатели внутренних страниц остаются на старом домене, а две версии одного прайса продолжают конкурировать.
Рядом в той же справке стоит обратное предупреждение, и его нарушают чаще: «По возможности не ставьте редирект со всех страниц старого сайта на главную страницу нового. Такая организация редиректов неудобна пользователям и, следовательно, снижает скорость индексации нового сайта роботом Яндекса». Google говорит то же: «Мы не рекомендуем настраивать переадресацию с нескольких старых URL на одну страницу, контент которой не имеет к ним отношения».
Если переезд уже назначен и страниц больше сотни, сопоставлять старые и новые адреса руками — отдельная работа, и дешевле заказать перенос сайта с сохранением адресов и карты редиректов вместе с самой разработкой, чем потом собирать выпавшие страницы по отчёту «Исключённые страницы» в Вебмастере.
приносит заявки,
или
разбор рекламы, которая
их не приносит?
Ответьте на три вопроса — посчитаем стоимость под вашу нишу и пришлём расчёт.
- Сайт под рекламу с нуля
- Яндекс Директ с отчётом по заявкам
- Разбор рекламы, которая
не работает
04Сколько держать редирект: шесть месяцев или год
Это число есть у обеих поисковых систем, и они называют разные.
Яндекс пишет срок прямо в справочнике кодов ответа, в строке про 301: «Сохраняйте перенаправление минимум 6 месяцев для корректной обработки поисковыми системами».
Google в инструкции по переносу сайта со сменой адресов требует вдвое больше: «Не отменяйте переадресацию как можно дольше, по крайней мере год. За этот срок Google сможет связать все сигналы с новыми URL, выполнит повторное сканирование и переназначение ссылок на других сайтах, которые указывают на ваши старые URL».
Выбирать надо большее из двух, то есть год. Отдельно стоит знать, что сам переезд в Яндексе занимает не дни: «Смена главного адреса сайта происходит в течение нескольких недель», а заявка на переезд «будет выполнена, когда новый адрес сайта станет главным и начнет участвовать в результатах поиска. На это может потребоваться от нескольких недель до месяцев». Переобход отдельных страниц быстрее: отправленные через инструмент «Переобход страниц» адреса «смогут попасть в поиск в течение двух недель».
И ещё предупреждение, которое стоит прочитать до переезда, а не после: «При смене главного адреса сайта Яндекс не гарантирует сохранение количества страниц сайта в результатах поиска, его позиций или посещаемости».
05Как это ставится на сервере и где в обеих документациях ловушка
У nginx и Apache одна и та же ловушка: короткая запись даёт не 301, а 302.
В nginx директива return с единственным параметром-адресом отдаёт временный код. Документация говорит: «в качестве единственного параметра можно указать URL для временного перенаправления с кодом 302». Чтобы получить 301, код надо назвать явно. У директивы rewrite то же самое спрятано во флагах: «redirect — возвращает временное перенаправление с кодом 302», «permanent — возвращает постоянное перенаправление с кодом 301».
В Apache директива Redirect без указания статуса ведёт себя так же: «If no status argument is given, the redirect will be "temporary" (HTTP status 302)», а permanent «Returns a permanent redirect status (301)».
| Сервер или платформа | Постоянное перенаправление | Что легко написать по ошибке |
|---|---|---|
nginx, return |
return 301 https://example.ru$request_uri; |
return https://example.ru; — это 302 |
nginx, rewrite |
rewrite ^/old$ /new permanent; |
флаг redirect вместо permanent — это 302 |
Apache, .htaccess |
Redirect permanent "/one" "http://example.com/two" |
Redirect "/one" "/two" без статуса — это 302 |
| Тильда | Настройки сайта → SEO → Редиректы страниц (Code 301) | блок T223 — это JavaScript и код 200 |
| 1С-Битрикс | правила mod_rewrite в .htaccess с флагом R=301 |
urlrewrite.php — это не редирект, а внутренняя подмена |
| Object Storage | правила условной переадресации с httpRedirectCode: "301" |
HTTP→HTTPS включается сам, править не надо |
Про nginx полезно знать ещё одно число, которого нет ни у кого в выдаче: внутренний цикл обработки «повторяется, если URI запроса изменялся, но не более 10 раз». Документация тут же показывает, чем это кончается при неверном флаге: «иначе nginx сделает 10 циклов и вернёт ошибку 500». То есть неудачное правило перенаправления отдаёт не бесконечный редирект, а пятисотую ошибку — и ищут её обычно совсем не там.
У Apache есть и вторая особенность, про которую не пишет никто: порядок строк в конфиге не определяет порядок обработки. «First, all Redirects are processed before Aliases are processed, and therefore a request that matches a Redirect or RedirectMatch will never have Aliases applied». Перенаправления всегда раньше псевдонимов, независимо от того, что выше в файле.
06Битрикс: в официальной документации только .htaccess
Запрос «301 редирект битрикс» стоит четвёртым по частоте среди соседних формулировок, и честный ответ на него такой: в документации ядра штатного интерфейса для 301-редиректов нет.
Раздел «Обработка адресов» в документации для разработчиков показывает перенаправления только рецептами mod_rewrite — например, «Настройка переадресации (301 редирект) на папки со слешем ( / ) в конце» с правилом RewriteRule ^(.*)$ http://[имя_вашего_сайта]/$1/ [L,R=301]. Механизм urlrewrite.php, который по названию похож на редирект, редиректом не является: «Обработка адресов (UrlRewrite) применяется для того, чтобы скрипт мог отвечать не только по своему физическому, но и по любому другому указаному адресу», и код ответа при этом остаётся 200.
Отсюда практическое: кнопка «Редиректы» в административной панели Битрикса — это почти всегда сторонний модуль с Маркетплейса, а не функция платформы. Знать это полезно до обсуждения сметы: вопрос «кто и чем будет ставить редиректы» стоит в том же списке, что и остальные вопросы разработчику до старта работ, и ответ на него меняет и состав работ, и требования к хостингу.
Оговорка о методе: сверить эти цитаты по сырому HTML я смог, а вот даты редакции у страниц документации Битрикса нет — в подвале стоит только «© «Битрикс», 2001-2026».
ваш сайт бесплатно
Посмотрю страницу и рекламу, найду,
где теряются заявки, и пришлю план,
что поменять.
- 1Где теряются заявкипуть от объявления до формы
- 2Что поправить на сайтепервый экран, оффер, формы
- 3Что поменять в рекламезапросы, объявления, бюджет
07Тильда: 301 есть, но работает не так, как кажется
Запрос «тильда 301 редирект» тоже в верхушке, и здесь в справке платформы стоят три ограничения, которых нет ни в одной статье выдачи.
Первое. Инструмент есть: «Для того, чтобы сделать переадресации с кодом 301 со старых адресов на новые, перейдите в Настройки сайта → SEO → Редиректы страниц (Code 301). Укажите старый и новый адреса страницы без домена, начиная со слэша (символ «/»)».
Второе, и самое неожиданное. «301 редирект работает только с несуществующих страниц». То есть правило не сработает, пока старая страница в проекте опубликована: она будет отдавать 200 и дальше. Сначала страницу надо удалить, и только потом редирект начнёт работать. Из той же справки следует, почему так: маска /blog/* описана как редирект «с любых несуществующих страниц, адрес которых после домена начинается с /blog/».
Третье. Смену домена Тильда полноценным 301 не закрывает: «Это не получится автоматически сделать ни с помощью блока T223, ни с помощью 301 редиректов в кабинете Тильды, так как они работают только в рамках одного домена… К сожалению, все эти решения не позволят сделать полноценный редирект с кодом 301 и для реализации такого редиректа нужно прикрепить домен к стороннему серверу и реализовать такой редирект самостоятельно».
Блок T223, который в выдаче рекомендуют как замену, заменой не является по признанию самой справки: «Данная статья описывает Javascript-редирект с одной страницы на другую. Это не серверный редирект с HTTP-кодом 301», и «страница, с которой будет идти перенаправление, при проверке будет отдавать код ответа HTTP 200». Для робота это означает, что старая страница жива и индексируется.
Это и есть граница платформы — одна из тех, про которые стоит узнавать до переезда, а не в его середине. Про них написано отдельно: и про то, что именно умеет и чего не умеет SEO-модуль конструктора, и про то, что ломается при переносе проекта с Тильды, где карта редиректов оказывается самой долгой частью работы и единственной, которую нельзя сделать задним числом.
08HTTPS и www: два случая, которые выглядят одинаково
Переход на HTTPS Яндекс считает сменой адреса сайта: «При смене протокола меняется адрес сайта». Инструкция требует редиректа: «Установите на сервере постоянный или временный редирект (например, с HTTP-кодом 301 или 302) со страниц старого адреса сайта на аналогичные страницы нового адреса, которые должны участвовать в поиске», и объясняет, зачем: «Это позволит передать новому адресу сайта некоторые накопленные показатели (например, оригинальных текстов и внешних ссылок)».
Отдельно справка отвечает на два вопроса, которые задают чаще всего. Про трафик: «Проведенные Яндексом исследования показывают, что при соблюдении описанных выше рекомендаций трафик на сайт при переезде на HTTPS не теряется». Про ИКС: «Да, индекс качества сайта при переезде переносится, хотя правильное значения ИКС может отобразиться не мгновенно». И одна ловушка, про которую не пишут: «Что будет с моими регионами из Каталога? При переезде нужно задать регионы заново». Сам сертификат разобран отдельно: зачем сайту SSL и что видит посетитель без него — предупреждение браузера отпугивает человека раньше, чем он дойдёт до формы заявки, и никакой редирект этого уже не исправит.
С www история другая. Справка Вебмастера пишет: «Для Яндекса нет разницы в том, содержит адрес сайта префикс www или нет», и расклеивать такие адреса не нужно — «Разгруппировка сайтов не нужна, если: у группы сайтов различается только протокол (HTTP / HTTPS); адреса сайтов различаются наличием префикса www». Но редирект всё равно нужен: пока оба адреса отвечают 200, робот «воспринимает такие адреса как разные сайты», и один из них «может терять трафик и не занимать желаемых позиций».
Важная деталь для тех, кто переезжает и на новый домен, и на новую структуру одновременно. Яндекс просит не склеивать это в один шаг: «Если у сайта изменились доменное имя и названия каталогов, нужно установить двойной редирект. Например, адрес страницы http://сайт.рф/стр/ изменился на http://example.ru/page/. Тогда перенаправление должно работать следующим образом: http://сайт.рф/стр/ -> http://example.ru/стр/ -> http://example.ru/page/». Цепочка здесь не ошибка, а требование: «При необходимости можно использовать цепочку редиректов: индексироваться и участвовать в поиске будет конечная цель перенаправления».
09Что сломает переезд, даже если 301 стоит правильно
Четыре вещи, которые Яндекс называет причинами отказа или замедления, и ни одна из них не про сам код ответа.
rel=canonical на новом адресе. Заявку на переезд не примут: «В исходном коде страниц сайта, который должен стать главным адресом, присутствует атрибут rel="canonical". Удалите его и отправьте заявку на переезд снова». Для смены протокола canonical тоже больше не годится: «Атрибут rel="canonical" для адресов такого формата больше не поддерживается».
Старый адрес, отдающий 404 вместо редиректа. Требование к ответу сервера сформулировано числом: «Ответ сервера не превышает 10 секунд и содержит для нового адреса HTTP-статус с кодом 200 OK, для старого — 200 OK или код перенаправления (постоянного или временного)».
Дублирующее правило в двух местах. Если редирект прописан и в CDN, и в .htaccess, получается цепочка или цикл — про это предупреждает база знаний Reg.ru: «Не создавайте одинаковое перенаправление одновременно в Cloudflare и .htaccess. В некоторых случаях это приводит к цепочке или циклу перенаправлений».
Смешанный контент после перехода на HTTPS. «Если на сайте, который работает по протоколу HTTPS, есть HTTP-ссылки на внутренние страницы или файлы, то браузеры, роботы поисковых систем и других сервисов перестают считать сайт безопасным».
Проверяется всё это тремя инструментами Вебмастера: «Проверка ответа сервера» показывает код и Location, «Переобход страниц» ускоряет учёт изменений, а отчёт «Внешние ссылки» показывает, кто ещё ссылается на старые адреса — справка советует этим воспользоваться: «По возможности попросите владельцев этих ресурсов изменить адреса ссылок на актуальные».
Если переезд уже идёт и часть страниц выпала из поиска, разбор обычно занимает один вечер и начинается с таблицы «старый адрес — код ответа — новый адрес» на все адреса сразу. Можно прислать список адресов и собрать такую таблицу вместе, и тогда сразу видно, какие строки ведут в 404, какие в цепочку, а какие на главную вместо своего раздела.
Частые вопросы
Сколько времени нужно держать 301 редирект?
Минимум шесть месяцев по Яндексу и минимум год по Google — значит, год. Справочник кодов ответа Яндекс Вебмастера про 301 говорит прямо: «Сохраняйте перенаправление минимум 6 месяцев для корректной обработки поисковыми системами». Google в инструкции по переносу сайта со сменой адресов требует больше: «Не отменяйте переадресацию как можно дольше, по крайней мере год. За этот срок Google сможет связать все сигналы с новыми URL, выполнит повторное сканирование и переназначение ссылок на других сайтах, которые указывают на ваши старые URL». Два разных числа в двух справках — это не противоречие, а две нижние границы, и выбирать надо большую. Практический вывод: если редирект стоит в .htaccess или в конфиге nginx, его просто не надо убирать при следующей правке — строка не мешает и ничего не стоит. Снимать её имеет смысл только тогда, когда старый адрес перестал приносить переходы и пропал из отчёта «Внешние ссылки» в Вебмастере.
Чем 301 отличается от 302 и от rel=canonical?
Кодом ответа и тем, что делает с ним робот. Справка Вебмастера делит коды так: «301/308 — постоянное перенаправление; 302/303/307 — временное перенаправление; перенаправление с использованием метатега refresh при небольших задержках считается временным перенаправлением». При временном перенаправлении в поиске остаётся исходная страница, при постоянном — конечная; у Google это сформулировано теми же двумя строчками. Атрибут rel=canonical вообще не редирект: человек по нему никуда не переходит, и для робота это только рекомендация — справка Яндекса предупреждает, что «Робот Яндекса воспринимает указание на канонический адрес как рекомендацию и может проигнорировать его в нескольких случаях», и прямо советует: «Чтобы повысить вероятность перехода пользователей и поисковых роботов на нужную версию сайта, используйте редирект 301/302». Для перехода с HTTP на HTTPS canonical уже не работает: «Атрибут rel="canonical" для адресов такого формата больше не поддерживается».
Можно ли сделать полноценный 301 на Тильде?
Внутри одного домена — да, при смене домена — нет. Справка Тильды описывает штатный инструмент: «Для того, чтобы сделать переадресации с кодом 301 со старых адресов на новые, перейдите в Настройки сайта → SEO → Редиректы страниц (Code 301)». Но там же стоит ограничение, которое ломает половину сценариев: «301 редирект работает только с несуществующих страниц». То есть если старая страница в проекте осталась и опубликована, правило не сработает — её надо сначала удалить. А на вопрос о смене домена справка отвечает без обиняков: «Это не получится автоматически сделать ни с помощью блока T223, ни с помощью 301 редиректов в кабинете Тильды, так как они работают только в рамках одного домена… К сожалению, все эти решения не позволят сделать полноценный редирект с кодом 301 и для реализации такого редиректа нужно прикрепить домен к стороннему серверу и реализовать такой редирект самостоятельно». Блок T223 заменой не будет: «Данная статья описывает Javascript-редирект с одной страницы на другую. Это не серверный редирект с HTTP-кодом 301», и страница при проверке «будет отдавать код ответа HTTP 200».
Что делать со страницами, которых больше нет: редирект или 404?
Зависит от того, изменилась ли тематика. Справка Вебмастера разводит два случая в одном абзаце: «Если какие-то определенные страницы уже отсутствуют на сайте, однако тематика сайта не изменилась и на нем можно найти схожие товары (фильмы, статьи и т. д.), настройте редирект c HTTP-кодом 301 на главную страницу соответствующего раздела или в раздел со схожей тематикой. Если вместе со структурой сайта меняется его тематика, необходимо настроить сервер таким образом, чтобы прежние страницы отдавали в заголовке код HTTP-404». Чего делать не надо — сваливать всё на главную: «По возможности не ставьте редирект со всех страниц старого сайта на главную страницу нового. Такая организация редиректов неудобна пользователям и, следовательно, снижает скорость индексации нового сайта роботом Яндекса». У Google то же самое сказано мягче, но про то же: «Мы не рекомендуем настраивать переадресацию с нескольких старых URL на одну страницу, контент которой не имеет к ним отношения».
Как проверить, что 301 действительно стоит?
Запросом без браузера. Браузер кеширует постоянные перенаправления — в RFC 9110 про это сказано, что «A 301 response is heuristically cacheable», и справка Тильды предупреждает о том же: «Результаты переадресации могут кешироваться браузером. Часто при изменении адреса редиректа будет срабатывать старое правило». Поэтому проверка в своём браузере ничего не доказывает. Надёжнее всего посмотреть сами заголовки: в Яндекс Вебмастере есть инструмент «Проверка ответа сервера», а из командной строки достаточно одной команды — она покажет код и адрес из заголовка Location, не следуя за перенаправлением. Смотреть надо три вещи: код (301 или 308, а не 302), адрес в Location (конечный, а не промежуточный) и число переходов — у Google «поисковые роботы Google выполняют до 10 переходов в цепочке переадресаций», но рекомендация другая: «Пусть их будет максимум четыре, а лучше три или два».
Источники · 18
- Коды состояния HTTP — справка Яндекс Вебмастера
- Обработка редиректов — справка Яндекс Вебмастера
- Переезд сайта на новый домен — справка Яндекс Вебмастера
- Изменение структуры сайта — справка Яндекс Вебмастера
- Переезд на HTTPS — справка Яндекс Вебмастера
- Канонический адрес страницы — справка Яндекс Вебмастера
- RFC 9110. HTTP Semantics, разделы 15.4.2, 15.4.8, 15.4.9
- Переадресация и Google Поиск — Google Search Central
- Перенос сайта со сменой URL — Google Search Central
- Модуль ngx_http_rewrite_module — документация nginx
- Apache Module mod_alias — документация Apache HTTP Server 2.4
- Настройка переадресации (блок T223) — Справочный центр Тильды
- Гид по SEO: продвижение сайта — Справочный центр Тильды
- Обработка адресов (UrlRewrite) — документация 1С-Битрикс
- Типовые перенаправления в .htaccess — документация Timeweb
- Редирект через .htaccess — база знаний Reg.ru
- Хостинг статического сайта в бакете — документация Yandex Object Storage
- Что такое 301 редирект и как его настроить — блог Timeweb
«Делаем сайты и запускаем Яндекс Директ так, чтобы
сайт приносил заявки, а не просто был»
