Редиректы, 404 и склейка URL в 1С-Битрикс: чистим индексацию

Пока сайт маленький, кажется, что редиректы и коды ответа — забота сисадмина, а не владельца магазина. Но стоит каталогу вырасти, пережить пару переездов и десяток обменов с 1С, как в индексе начинается хаос: одна и та же карточка открывается по пяти адресам, удалённые товары отдают код 200 вместо 404, старые ссылки ведут в никуда, а позиции необъяснимо проседают. Всё это — следствие того, что редиректы в Битрикс, склейка дублей и обработка 404 не настроены как единая система.

Эта статья — практическое руководство по технической гигиене URL для интернет-магазина на 1С-Битрикс. Разберём, зачем нужен 301-редирект и чем он отличается от 302 и 307, где именно в Битриксе настраивать перенаправления (сервер, интерфейс SEO, обработчик OnPageStart), как склеить дубли (www и без www, http и https, слеш, регистр, index.php, параметры и UTM), как сделать правильную страницу 404 в Битрикс с честным кодом ответа и как не наплодить «мягких» 404. Материал вырос из нашей практики переездов и техподдержки магазинов — по делу, без магии.

Зачем чистить индексацию: редиректы и дубли

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

Технически чистка индексации держится на трёх опорах:

• Редиректы (301). Отправляют пользователя и поисковика со старого/дублирующего адреса на единственно правильный, передавая накопленный вес.
• Склейка дублей. Приведение всех вариаций одного URL (www, https, слеш, регистр, параметры) к одной канонической форме.
• Корректные коды ответа. Существующие страницы отдают 200, переехавшие — 301, несуществующие — 404 (или 410). Никаких «мягких» 404 с кодом 200.

Все три задачи связаны. Нельзя настроить редиректы, но забить на 404, — переехавший каталог начнёт отдавать 200 на удалённых товарах. Нельзя склеить www, но проигнорировать слеш, — дубли просто переползут в другую плоскость. Поэтому смотреть на них нужно как на единую дисциплину: это часть технического SEO, тесно связанная с настройкой ЧПУ и управлением robots.txt и sitemap.xml.

Зачем нужен 301: смена URL без потери позиций

Главная ценность 301-редиректа — возможность менять адреса, не теряя накопленные позиции. Представьте страницу, которая годами собирала трафик, ссылки и поведенческие сигналы по адресу /catalog/uglovye-divany/. Вы перестроили дерево каталога, и раздел переехал на /catalog/mebel/divany/uglovye/. Без редиректа старый адрес отдаст 404: поисковик увидит, что страница исчезла, выбросит её из индекса, а весь накопленный вес просто испарится. Новый адрес при этом начнёт путь с нуля.

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

Ситуации, когда 301 обязателен:

• Переименование раздела или товара — изменился символьный код, изменился URL.
• Перестройка дерева каталога — товары и разделы сменили место в иерархии.
• Переход с параметров на ЧПУ — старые ?ELEMENT_ID=... нужно увести на чистые пути.
• Смена домена — весь старый сайт склеивается на новый.
• Склейка дублей — www, https, слеш, регистр приводятся к одной форме.
• Объединение страниц — две похожие карточки схлопнулись в одну.

Обратная сторона: 301 кэшируется браузерами и надолго запоминается поисковиком. Это его сила (стабильность) и его опасность — ошибочный 301 сложно быстро откатить, потому что браузер продолжает вести на новый адрес из кэша. Поэтому карту 301-редиректов готовят внимательно и проверяют до выкатки.

Виды редиректов: 301, 302, 307, 308

Редирект — это ответ сервера со статусом 3xx и заголовком Location, указывающим, куда идти дальше. Кодов несколько, и они не взаимозаменяемы: поисковик по-разному трактует постоянные и временные перенаправления. Разберём четыре ключевых.

Разница между «нестрогими» (301/302) и «строгими» (307/308) кодами — в поведении с методом запроса. Исторически при 301 и 302 браузеры часто меняли метод POST на GET при переходе. Коды 307 и 308 были введены, чтобы гарантированно сохранять исходный метод и тело запроса. Для обычных страниц каталога, которые открываются по GET, это не критично, но для форм и API разница важна.

Для SEO-задач магазина в 99% случаев используется 301: это стандарт для постоянной смены адреса и склейки дублей. 308 — его строгий аналог, применяется реже, в основном там, где важно сохранить метод. 302 и 307 — временные и для смены URL каталога не подходят: они не передают вес и сохраняют старый адрес в индексе.

Когда какой редирект применять

Чтобы не держать таблицу в голове, полезно свести выбор кода к простым сценариям. Логика одна: постоянно и навсегда — 301, временно и обратимо — 302/307.

Отдельно про товары «нет в наличии». Частая ошибка — редиректить временно отсутствующий товар на раздел или отдавать по нему 404. Если товар вернётся, вы теряете рабочую страницу с позициями. Правильнее оставить карточку доступной (код 200), показать статус «нет в наличии» и предложить аналоги. 404/410 — только для того, что удалено навсегда.

Где в 1С-Битрикс настраивать редиректы

В 1С-Битрикс нет единственной «кнопки редиректов» — есть несколько уровней, и у каждого своя зона ответственности. Понимание этой иерархии избавляет от конфликтов, когда одно и то же перенаправление случайно настроено в двух местах и они спорят друг с другом.

Про интерфейсные редиректы стоит сказать подробнее. В 1С-Битрикс есть механизм редиректов, доступный из административной части (в модуле SEO / инструментах управления структурой сайта). Он хранит правила «старый URL → новый URL» в базе данных и позволяет контент-менеджеру добавлять постраничные перенаправления без доступа к файлам сервера. Это удобно для точечных случаев: переименовали пару страниц, объединили карточки, увели старый URL акции на новую. Каждое правило можно задать как 301 или 302 и указать, учитывать ли параметры.

Практическая раскладка по задачам:

• Нормализация домена и протокола (www, https, слеш, регистр) — на сервере. Это самый быстрый уровень, не грузит PHP и срабатывает раньше приложения.
• Точечные постраничные редиректы — через интерфейс SEO. Ими управляет команда без правки конфигов.
• Массовые правила по шаблону (все ?ELEMENT_ID= на ЧПУ) — на сервере или в urlrewrite.php.
• Условные редиректы (по региону, по группе, по статусу товара) — в обработчике OnPageStart.

.htaccess и mod_rewrite

На Apache редиректы уровня сервера настраивают в файле .htaccess через модуль mod_rewrite. Это самый ранний и быстрый уровень: правило срабатывает ещё до того, как запрос дойдёт до PHP и Битрикса. Именно здесь логично держать нормализацию — приведение домена, протокола и формы адреса к канону.

Типовые правила нормализации выглядят так (фрагмент, порядок и условия важны):

RewriteEngine On

# 1) Принудительный HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# 2) Склейка www → без www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

# 3) Отдать несуществующие пути движку Битрикса
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

Флаг [R=301,L] здесь ключевой: R=301 задаёт постоянный редирект, L — «last», прекратить обработку правил после срабатывания. Условия RewriteCond — это фильтры: правило применится, только если условие истинно. Например, HTTPS-редирект срабатывает, лишь когда протокол ещё не защищённый (%{HTTPS} !=on).

Несколько принципов работы с .htaccess, которые экономят часы отладки:

• Порядок правил критичен. Нормализация (https, www) должна идти до передачи запроса движку.
• Не зацикливайте. Каждое правило должно менять адрес так, чтобы при повторном проходе оно уже не срабатывало, иначе получите бесконечный редирект.
• Объединяйте нормализацию. Плохо, когда https, www и слеш редиректят тремя последовательными прыжками — это цепочка. По возможности приводите к канону за один шаг.
• Один источник правды. Не дублируйте правило, которое уже есть в интерфейсе SEO или в конфиге сервера.

urlrewrite.php и обработчик OnPageStart

Когда логика редиректа сложнее, чем «поменять домен», в дело вступают средства самого Битрикса. Два основных инструмента — файл правил urlrewrite.php и обработчики событий пролога.

urlrewrite.php в первую очередь отвечает за разбор ЧПУ (превращение красивого пути в параметры компонента), но в нём же можно держать групповые правила перенаправления. Его сила — в регулярных выражениях: одно правило способно поймать целый класс старых адресов. Минус — файл частично управляется автоматически при сохранении компонентов, поэтому ручные правки в нём документируют.

Обработчик OnPageStart (или OnBeforeProlog) — это точка входа, которая срабатывает в самом начале обработки любой страницы, ещё до вывода контента. В нём на PHP можно реализовать какую угодно логику редиректа: по региону, по группе пользователя, по статусу товара, по наличию параметра. Схематично обработчик, который увóдит старые параметрические адреса на ЧПУ, выглядит так:

AddEventHandler("main", "OnPageStart", "checkLegacyRedirect");

function checkLegacyRedirect()
{
    $uri = $_SERVER["REQUEST_URI"];

    // Старый адрес карточки по ELEMENT_ID → отдать 301 на ЧПУ
    if (preg_match('~/catalog/index\.php\?ELEMENT_ID=(\d+)~', $uri, $m)) {
        $newUrl = getChpuUrlByElementId((int)$m[1]); // ваша функция
        if ($newUrl) {
            LocalRedirect($newUrl, false, "301 Moved Permanently");
        }
    }
}

Ключевой момент — функция LocalRedirect с явным указанием статуса "301 Moved Permanently". Если статус не задать, редирект может уйти как 302, и вы потеряете передачу веса. Это ровно та ситуация, где «редирект работает, но не тот код».

Типы дублей URL: полная карта

Прежде чем склеивать дубли, полезно увидеть их все сразу. «Склейка дублей URL» — это не одна проблема, а целый набор вариаций, каждая из которых порождает копию страницы. Вот полная карта типовых дублей магазина на 1С-Битрикс.

Обратите внимание на разделение инструментов. Там, где адреса технически разные, но должны вести к одной физической странице (www, https, слеш, регистр, index.php), работает 301-редирект — второй вариант просто не должен существовать как самостоятельный URL. А там, где параметр несёт функцию (сортировка, UTM, пагинация) и страница по нему реально открывается, редирект неуместен — там применяют rel="canonical", указывая главную версию. Путаница между этими двумя инструментами — источник половины проблем с дублями.

Склейка www и без www

Самый базовый дубль — сайт, открывающийся одновременно по www.shop.ru и shop.ru. Для человека это один сайт, для поисковика — два разных хоста с полностью идентичным содержимым. Пока склейка не настроена, вес делится между версиями, а в индексе висят пары дублей на каждую страницу.

Решение в два шага:

1. Выберите главную форму. Чаще выбирают без www (короче), но принципиальной разницы нет — важно определиться и не менять решение.
2. Настройте 301 на уровне сервера. Вторая форма постоянным редиректом уводится на выбранную главную.

Правило для .htaccess при выборе версии без www мы уже видели выше: если хост начинается с www., редиректим на тот же адрес без него с кодом 301. Дальше форму закрепляют во всех сигналах: rel="canonical" ссылается на бесхостовую версию, в sitemap.xml только адреса без www, внутренние ссылки тоже без www. Разнобой сигналов (внутренние ссылки на www, а canonical на без-www) сам по себе создаёт путаницу.

http → https: принудительный протокол

Если сайт доступен и по http://, и по https://, каждый адрес существует в двух протокольных вариантах — это ещё один класс дублей, к тому же с проблемой безопасности. HTTPS давно стал стандартом, поисковики предпочитают защищённые страницы, а браузеры помечают http как «небезопасно».

Задача — принудительно переводить все запросы на https постоянным 301-редиректом. Настраивается на сервере (правило мы видели в разделе про .htaccess): если протокол не https, редиректим на тот же адрес по https. После этого:

• Все внутренние ссылки должны быть на https (или протокол-относительными).
• В sitemap.xml — только https-адреса.
• rel="canonical" ссылается на https-версию.
• Проверить, что нет «смешанного контента» — картинок и скриптов, подгружаемых по http.

Тонкий момент — порядок нормализации. Если у вас одновременно решаются http→https и www→без-www, важно свести их к канону минимальным числом прыжков. Плохой сценарий: http://www.shop.ru → https://www.shop.ru → https://shop.ru — это цепочка из двух 301. Лучше настроить правила так, чтобы http://www.shop.ru уходил сразу на https://shop.ru одним редиректом.

Слеш в конце адреса

Дубль «со слэшем и без» — один из самых незаметных и массовых. Адреса /catalog/divany и /catalog/divany/ для поисковика различны, а контент за ними одинаковый. На большом каталоге это буквально удваивает число потенциальных URL.

1С-Битрикс с его концепцией «страниц-папок» естественно тяготеет к адресам со слэшем на конце, поэтому канонической почти всегда выбирают версию со слэшем. Меры:

• 301-редирект с формы без слэша на форму со слэшем (или наоборот, но единообразно по всему сайту).
• Схлопывание повторных слэшей: //catalog//divany/ → /catalog/divany/.
• rel="canonical" на форму со слэшем — дополнительная страховка.
• Единый формат внутренних ссылок: все ссылки в меню, карточках и sitemap — со слэшем.

Важна аккуратность с исключениями. Файлы с расширением (.pdf, .xml, robots.txt) и служебные адреса слэш на конце не получают — правило нормализации должно их пропускать, иначе вы сломаете доступ к реальным файлам. Обычно в правило добавляют условие «применять только к путям без точки в последнем сегменте».

Регистр URL: upper и lower

Ещё один источник незаметных дублей — регистр символов в адресе. /Catalog/Divany/, /catalog/DIVANY/ и /catalog/divany/ для веб-сервера на Linux — три разных URL (файловая система чувствительна к регистру), а контент один. Ссылки в верхнем или смешанном регистре легко попадают на сайт из внешних источников, старых материалов, ошибок при вёрстке.

Стратегия — принудительно приводить адреса к нижнему регистру постоянным редиректом. На уровне сервера это делается правилом, которое ловит наличие заглавных букв в пути и редиректит на его lowercase-версию с кодом 301. Заодно это дисциплинирует символьные коды: их и так генерируют в нижнем регистре (см. настройки транслитерации в статье про ЧПУ в Битрикс), а серверная нормализация страхует от «случайно заглавных» ссылок.

Что учесть при нормализации регистра:

• Не трогайте query-строку без нужды. Значения параметров (?utm_content=BlackFriday) могут быть регистрозависимыми — нормализуют обычно только путь.
• Исключите служебные пути. Админка, некоторые API и файлы могут требовать оригинальный регистр.
• Согласуйте с символьными кодами. Если коды в нижнем регистре, а ссылки где-то в верхнем — редирект сгладит, но лучше чинить и источник ссылок.

index.php и дубль главной

Классический дубль главной страницы: сайт открывается и по https://shop.ru/, и по https://shop.ru/index.php. Второй адрес — это «сырой» путь к скрипту, который в норме не должен светиться, но на него легко наткнуться, и поисковик может его проиндексировать как отдельную страницу-дубль главной.

То же касается любого раздела: /catalog/ и /catalog/index.php — потенциальная пара дублей. Решение — 301-редирект с версии с index.php на чистый адрес папки:

# Убрать /index.php из адреса → чистый слеш-путь
RewriteCond %{THE_REQUEST} \s/+(.*/)?index\.php[\s?] [NC]
RewriteRule ^(.*?)index\.php$ /$1 [R=301,L]

Правило читается так: если в исходном запросе встречается index.php в конце пути, отдаём 301 на тот же путь без него. Проверка ведётся по %{THE_REQUEST} (оригинальная строка запроса), чтобы не сработать на внутренних обращениях движка, которые технически идут через index.php, но не видны в адресной строке. Это тонкость: слишком грубое правило может сломать работу CMS, поэтому его тестируют аккуратно.

Параметры, UTM и сортировки

Отдельный большой класс дублей рождают GET-параметры. Один и тот же раздел открывается как /catalog/divany/, /catalog/divany/?utm_source=ya, /catalog/divany/?sort=price, /catalog/divany/?view=list&sort=price. Контент почти идентичен, а адресов — множество. Здесь важно не спутать инструмент: параметрические дубли в большинстве случаев решаются не редиректом, а каноническим адресом.

Почему не редирект? Потому что параметр часто несёт функцию: UTM нужен для аналитики, сортировка — для пользователя, фильтр реально меняет выборку. Если жёстко редиректить любой параметр на чистый адрес, вы сломаете и аналитику, и функциональность. Поэтому логика такая:

UTM-метки — показательный случай. Их нельзя редиректить (иначе аналитика не увидит источник), но и индексировать ?utm_source=... как отдельную страницу не нужно. Решение: страница с UTM отдаёт код 200 и работает, но в её rel="canonical" прописан чистый адрес без меток. Поисковик понимает, какая версия главная, и не плодит дубли, а аналитика получает свои данные. Про то, как разграничить осмысленные фильтры (посадочные) и мусорные комбинации, подробно в отдельных материалах рубрики SEO и продвижение.

Канонический адрес против редиректа

Мы несколько раз противопоставили 301-редирект и rel="canonical" — пора закрепить разницу, потому что их путают чаще всего. Оба говорят поисковику «главная версия вот тут», но действуют принципиально по-разному.

Правило выбора простое. Если вариант адреса не должен существовать вообще (никому не нужны и http, и https одновременно) — это работа для 301: старый адрес просто перестаёт быть самостоятельной страницей. Если вариант адреса нужен для работы сайта (пользователь сортирует, аналитика метит) — это работа для canonical: страница живёт, но поисковик знает, какую версию считать основной. Ошибка в любую сторону вредна: редирект там, где нужен canonical, ломает функциональность; canonical там, где нужен редирект, оставляет дубль доступным и не гарантирует склейку.

Кастомная страница 404 с кодом 404

Страница 404 — это то, что видит пользователь, попав на несуществующий адрес. Хорошая 404 не пугает, а помогает: показывает, что страницы нет, и предлагает пути дальше (поиск, популярные разделы, ссылка на главную). Но с точки зрения индексации ключевое в 404 — не дизайн, а код ответа сервера.

Правильная страница 404 должна отдавать HTTP-статус 404 Not Found. Это важнее любой вёрстки. Если несуществующий адрес отдаёт код 200 OK, поисковик считает страницу валидной и индексирует её — так рождаются «мягкие» 404 и мусор в индексе.

В 1С-Битрикс за корректную 404 отвечает несколько вещей, которые должны работать вместе:

1. Файл страницы 404. В системе есть страница 404.php (шаблон ошибки) с оформлением, навигацией и поиском.
2. Константа обработки. В .htaccess / настройках указана обработка ошибки: ErrorDocument 404 /404.php.
3. Установка статуса в коде. Страница 404 должна принудительно выставлять статус: @define("ERROR_404", "Y") и вызов установки заголовка 404 в прологе.
4. Проверка кода. Инструментом убедиться, что несуществующий адрес реально отдаёт 404, а не 200.

Схематично установка статуса в шаблоне 404 выглядит так:

// В начале страницы 404
@define("ERROR_404", "Y");
CHTTP::SetStatus("404 Not Found");
// далее — оформленная страница с поиском и ссылками

Без явной установки статуса Битрикс может показать красивую страницу «не найдено», но с кодом 200 — и это уже soft 404, о которой ниже. Дизайн 404 и её HTTP-код — две независимые вещи, и вторая для SEO важнее.

Мягкие 404 (soft 404) и как их избежать

Soft 404 — коварная проблема именно потому, что визуально всё в порядке: пользователь видит нормальную страницу, а беда скрыта в коде ответа. Это ситуация, когда страница пустая или отсутствующая по смыслу, но сервер отдаёт 200 OK. Поисковик распознаёт такие страницы как малополезные, но сначала тратит на них краулинговый бюджет и портит общую картину качества сайта.

Типичные источники soft 404 в интернет-магазине на 1С-Битрикс:

• Заглушка «Товар не найден» с кодом 200. Карточку удалили, а движок отдаёт шаблон-заглушку со статусом 200 вместо 404.
• Редирект удалённого товара на главную. Вместо честной 404 — 301/302 на главную, что поисковики тоже трактуют как soft 404.
• Пустой раздел каталога. Раздел есть, товаров в нём нет — страница почти пустая, но код 200.
• Пустые результаты поиска и фильтра. «Ничего не найдено» с кодом 200 при индексируемом адресе.
• Битые ЧПУ после обмена. Адрес формально открывается, но контента нет.

Как избегать soft 404:

1. Удалено навсегда — отдавайте 404/410. Никаких заглушек с кодом 200 и никаких «редиректов на главную оптом».
2. Пустой раздел — решайте осмысленно. Либо скрывайте пустые разделы, либо наполняйте, либо отдавайте 404, если раздел больше не нужен.
3. Временно нет товара — оставляйте страницу. Код 200, статус «нет в наличии», аналоги — но не удаляйте и не редиректьте.
4. Проверяйте код, а не вид. Регулярно контролируйте, что «не найдено» отдаёт именно 404.

Карта редиректов при переезде

Переезд — смена домена, перестройка структуры, миграция со старой CMS — самый ответственный сценарий для редиректов. Здесь цена ошибки максимальна: неправильная карта перенаправлений обрушивает трафик на недели. Поэтому переезд начинается не с выкладки новой версии, а с подготовки карты редиректов.

Порядок подготовки:

1. Соберите все старые URL. Выгрузите проиндексированные адреса из вебмастера, логов сервера, старого sitemap и аналитики. Особое внимание — страницам с трафиком и ссылками.
2. Сопоставьте старое → новое. Для каждого старого адреса определите конкретный релевантный новый. Не «оптом на главную», а страница в страницу.
3. Обработайте «безответные». Если новой страницы-аналога нет, решите заранее: 404/410 (контента больше нет) или 301 на ближайший релевантный раздел.
4. Проверьте на цепочки. Убедитесь, что старые адреса ведут сразу на конечные новые, а не через промежуточные.
5. Настройте 301 до выкладки. Карта должна быть готова и залита одновременно с новой структурой, а не после того, как посыпались 404.
6. Обновите внутренние сигналы. Меню, sitemap, canonical, перелинковка — всё указывает уже на новые адреса.
7. Мониторьте после переезда. Следите за отчётами об ошибках и кодах ответа первые недели, оперативно чините промахи.

Массовые редиректы без хаоса

Когда старых адресов тысячи (например, весь каталог переходит с параметров на ЧПУ), поштучно правила не пропишешь. Массовые редиректы делают по шаблону — одним правилом ловят целый класс адресов. Но именно здесь легко устроить хаос: слишком широкое правило перехватит лишнее, слишком узкое — пропустит часть страниц.

Подходы к массовым редиректам:

Для магазина частый сценарий — увести все старые ?ELEMENT_ID=N на ЧПУ. Поскольку новый адрес зависит от товара, чистым regex его не построишь: нужна логика, которая по ID найдёт актуальный ЧПУ-адрес в базе (см. пример обработчика OnPageStart выше). А вот нормализацию слеша, регистра и протокола, где преобразование чисто механическое, наоборот, отдают regex-правилам сервера — они быстрее и не трогают базу.

Редирект старых ЧПУ после обмена с 1С

Отдельная боль магазинов на 1С-Битрикс — «уехавшие» адреса после обмена с 1С. Если символьный код товара не зафиксирован, при пересоздании товара он может сгенерироваться заново или с суффиксом уникальности (divan-milan → divan-milan1). Проиндексированный адрес начинает отдавать 404, позиции сыплются, а причину ищут неделями.

Правильная стратегия двойная: сначала предотвратить смену кода, а если она уже случилась — перекрыть редиректом.

1. Зафиксируйте символьный код. Привяжите его к неизменному XML_ID или передавайте из 1С, запретите перегенерацию существующего кода. Это убирает саму причину «переездов».
2. Соберите изменившиеся адреса. Из логов и вебмастера выявите старые ЧПУ, которые начали отдавать 404 после обменов.
3. Настройте 301 на актуальные адреса. Старый ЧПУ → текущий ЧПУ товара, желательно вычисляя новый адрес по стабильному идентификатору.
4. Не плодите цепочки. Если товар «переезжал» несколько раз, редиректьте все прошлые адреса сразу на актуальный, а не по цепочке версий.

Первичная профилактика важнее лечения: стабильный символьный код, привязанный к XML_ID, снимает проблему в корне — адрес товара перестаёт зависеть от числа обменов. Механику стабильных кодов мы подробно разбираем в статье про ЧПУ в 1С-Битрикс; редиректы здесь — страховка для тех адресов, что успели «уехать» до наведения порядка.

Цепочки редиректов и почему они вредны

Цепочка редиректов — это последовательность из нескольких перенаправлений: адрес A ведёт на B, B на C, C на D. Каждое звено технически работает, но вместе они создают проблемы, которые копятся годами по мере переездов и правок.

Чем вредны цепочки:

• Замедление. Каждый прыжок — лишний запрос-ответ; страница открывается дольше, особенно на мобильных.
• Размывание веса. При каждом переходе часть передаваемого веса теряется — до финального адреса доходит меньше.
• Риск обрыва. Если середина цепочки сломается, весь путь оборвётся, и конечная страница станет недостижимой.
• Лимит переходов. Поисковики и браузеры проходят ограниченное число редиректов и могут не дойти до финала.
• Зацикливание. Неаккуратные правила способны замкнуть цепочку в кольцо — бесконечный редирект и полный отказ страницы.

Откуда цепочки берутся? Обычно из истории: сделали переезд (A→B), через год ещё один (B→C), потом третий (C→D) — и никто не «схлопнул» старые правила. Пользователь, пришедший по древней ссылке A, проходит три прыжка вместо одного. Лечится это ревизией: любой старый адрес должен вести сразу на конечный актуальный URL, а не на промежуточный.

robots.txt и редиректы

robots.txt и редиректы работают в связке, и их легко случайно рассогласовать. Главное правило: не закрывайте в robots.txt адреса, которые редиректите. Если старый URL закрыт директивой Disallow, поисковик не сможет его обойти, а значит — не увидит 301 и не узнает о переезде. Вес не передастся, потому что робот до редиректа просто не дойдёт.

Как правильно сочетать:

• Редиректите — оставляйте открытым. Старый адрес с 301 должен быть доступен роботу, чтобы он «увидел» переезд и перенёс вес.
• Закрываете — не редиректите. Служебные и мусорные разделы, которые не нужны в индексе, закрывают в robots.txt, но не редиректят.
• Не редиректьте на закрытое. Бессмысленно вести 301 на страницу, запрещённую в robots.txt, — цель окажется недостижимой для робота.
• Sitemap — только рабочие 200. В карту попадают конечные адреса с кодом 200, без редиректов и без запрещённых в robots.

Ещё один нюанс — сам файл robots.txt и правила нормализации. Убедитесь, что редиректы слеша и регистра не задевают /robots.txt и /sitemap.xml: эти файлы должны отдаваться напрямую с кодом 200, без перенаправлений. Про грамотную настройку самих файлов — отдельная статья про robots.txt и sitemap.xml для большого магазина.

Проверка: коды ответа сервера

Любую работу с редиректами и 404 проверяют не глазами в браузере, а по кодам ответа сервера. В браузере вы видите итоговую отрисованную страницу и не отличите честный 404 от soft 404, а 301 от 302. Нужен инструмент, показывающий HTTP-заголовки и цепочку статусов.

Что и как проверять:

Способы проверки:

• Инструмент вебмастера «проверка ответа сервера». Показывает статус и заголовки для конкретного URL.
• Консоль (curl). Команда с показом заголовков выводит статус и цепочку редиректов: curl -sI -L https://shop.ru/staryj-adres/.
• Расширения браузера. Показывают цепочку кодов ответа при переходе.
• Отчёты об индексации. Регулярный контроль ошибок обхода: 404, soft 404, редиректы.

Проверять стоит именно «граничные» варианты: адрес со слэшем и без, с www и без, http и https, в разном регистре, с index.php и без. Каждый должен корректно приводиться к канонической форме одним 301 с правильным кодом. Это финальная приёмка, без которой нельзя считать настройку завершённой.

Частые ошибки

Эти промахи встречаются чаще всего и дорого обходятся в трафике и индексации:

• 302 вместо 301. Редирект «работает», но вес не передаётся, старый адрес держится в индексе.
• Soft 404 с кодом 200. Удалённые товары и пустые разделы отдают 200 — мусор в индексе.
• Редирект удалённого товара на главную. Поисковик трактует это как soft 404; честный 404 полезнее.
• Цепочки редиректов. A→B→C→D вместо прямого A→D — потеря скорости и веса.
• Незакрытая склейка дублей. www, https, слеш или регистр не приведены к канону — множатся копии.
• Редирект на закрытое в robots.txt. Робот не доходит до цели, вес не передаётся.
• Закрыли редиректируемый адрес в robots.txt. Робот не видит 301, переезд не засчитывается.
• Редирект параметров, которые несут функцию. UTM и сортировку нельзя редиректить — их канонизируют.
• Зацикленное правило нормализации. Бесконечный редирект из-за неаккуратного условия.
• Правила в двух местах. Один редирект в .htaccess, другой в интерфейсе SEO — конфликт и цепочки.
• Уехавшие ЧПУ после обмена без редиректов. Старые адреса отдают 404, позиции падают.
• Проверка «на глаз». Судят по виду страницы, а не по коду ответа — и не замечают soft 404 и 302.

Чек-лист

Сведём всё в практический список для приёмки перед запуском и после переезда:

1. Протокол склеен. Весь http принудительно уходит на https с кодом 301.
2. Домен склеен. www и без-www приведены к одной канонической форме через 301.
3. Слеш нормализован. Единая форма (обычно со слэшем), вторая редиректится, файлы-исключения не задеты.
4. Регистр нормализован. Адреса приводятся к нижнему регистру, служебные пути исключены.
5. index.php убран. Версии с index.php редиректятся на чистые пути.
6. Параметры под контролем. UTM и сортировки — через canonical, а не редирект.
7. Страница 404 отдаёт 404. Оформленная 404 с честным кодом ответа, без soft 404.
8. Удалённое отдаёт 404/410. Никаких заглушек с кодом 200 и редиректов «оптом на главную».
9. Карта редиректов готова. Старые адреса ведут на конкретные новые, без цепочек, кодом 301.
10. ЧПУ стабильны. Код привязан к XML_ID, уехавшие адреса перекрыты редиректами.
11. robots и редиректы согласованы. Редиректируемое открыто, закрытое не редиректится.
12. Коды проверены инструментом. Граничные варианты дают правильные 200/301/404 за один прыжок.

Вывод

Редиректы, обработка 404 и склейка дублей — это не разрозненные мелочи, а единая система технической гигиены URL. 301-редирект позволяет менять адреса и переезжать, не теряя позиции: он переносит на новый URL накопленный вес. Склейка дублей (www, https, слеш, регистр, index.php, параметры) сводит все вариации адреса к одной канонической форме, чтобы поисковик видел одну страницу вместо десяти. А правильная страница 404 с честным кодом ответа не даёт удалённым и пустым адресам засорять индекс мнимыми «мягкими» 404.

Соберите связку целиком: нормализацию домена и протокола — на сервере, постраничные смысловые редиректы — через интерфейс SEO и обработчик OnPageStart, стабильные ЧПУ на XML_ID против «уезжающих» после обмена адресов, канонические адреса для функциональных параметров и заранее подготовленную карту 301 для любого переезда. И проверяйте результат не по виду страниц, а по кодам ответа. Настроенная один раз, эта дисциплина работает годами: каталог растёт, товары приходят и уходят через обмен, структура меняется — а индекс остаётся чистым, позиции сохраняются, и поисковик видит ровно те страницы, которые вы хотите ему показать.