301 редирект и страница 404 на Битриксе: настройка, частые ошибки и проверка

301 редирект нужен, когда страница переехала; честный 404 (или 410), когда страницы больше нет. Всё остальное в теме, производные от этих двух случаев.

Типичная история: магазин на 1С-Битрикс сменил структуру каталога, часть товаров сняли с продажи. Через месяц просадка поискового трафика и рост стоимости обращения в Директе, потому что старые URL отдавали код 200 с пустой карточкой, а объявления вели в никуда. На Битриксе это болит сильнее: URL проходит несколько слоёв обработки (nginx, .htaccess, urlrewrite.php, компонент), сверху ЧПУ инфоблоков и композитный кэш.

Дальше: порядок обработки URL, четыре способа редиректа, дерево решений, разбор вредных советов, ТЗ разработчику, чек-лист приёмки и мониторинг на 2 месяца. Все проверки через curl и Вебмастер, не «на глаз»: браузер показывает контент, но скрывает код ответа.

Коротко: что настроить в Битриксе за 30 минут

Сводная таблица: ситуация, код ответа, где настраивается

Минимум на полчаса: включить установку статуса 404 в Главном модуле, прогнать curl -I по 10 URL, открыть раздел «Страницы в поиске» в Вебмастере.

Сколько стоит неправильная 404: деньги Директа, заявки, выпадение каталога

Цена считается просто: доля кликов на несуществующие URL, умноженная на стоимость клика и период. Подставьте свои цифры, выдуманных процентов тут не будет.

Реклама: оплаченный клик в пустоту

В Метрике возьмите отчёт по страницам входа, отфильтруйте по заголовку страницы ошибки и сделайте срез по Яндекс Директу и Google Ads. Пока объявление живо, клики списываются; при недоступной посадочной модерация отклоняет объявление или товар в фиде.

SEO: товары в индексе, но без контента

Код 200 на странице ошибки плодит тысячи почти одинаковых страниц: каталог размывается дублями, бюджет обхода уходит на мусор. Массовый 404 без редиректов при переезде даёт падение сначала показов, потом трафика и заявок, с восстановлением за месяцы.

Как заметить раньше

Рост «Страниц с ошибками» и исключённых в Вебмастере виден до просадки трафика. Считаем в заявках и стоимости обращения: сама по себе ошибка в панели никого не волнует, волнует цена обращения.

Как Битрикс обрабатывает несуществующий URL: nginx, .htaccess, urlrewrite.php, компонент

Запрос идёт сверху вниз, и правило на верхнем слое перебивает всё, что ниже. Отсюда значительная часть случаев «настроил, а не работает».

1. nginx. Отдаёт статику и решает, что передать в PHP. Здесь уместны домен, протокол, слэш, index.php и тяжёлые массовые правила. Конфиги в /etc/nginx/, на BitrixVM в отдельных include-файлах сайта.
2. .htaccess в корне. Переносы разделов и регулярки, правится без доступа к серверу.
3. urlrewrite.php. Таблица ЧПУ: URL сопоставляется с компонентом. Файл /bitrix/urlrewrite.php.
4. Компонент. Разбирает параметры и решает, это 404 или нет. ЧПУ инфоблока часто совпадает по шаблону, элемента в базе нет, страница «нашлась» и отдала 200 с пустым шаблоном.
5. Шаблон 404.php и код ответа.

Где именно отработало правило, видно по curl -I -L: сравните заголовки и временно отключите правило на тестовом URL. Конфиг nginx на продакшене правим только с бэкапом и nginx -t.

Ошибка №1, код 200 на странице ошибки: как проверить и починить

Проверка одна: curl -I 'https://site.ru/net-takoy-stranicy-123/'. В первой строке должно быть HTTP/2 404, а не 200.

1. Браузер обманывает: вкладка пишет «Страница не найдена», сервер отдаёт 200. Отсюда вопросы вида «в браузере открывается, а Вебмастер пишет, что не отвечает».
2. Проверяем в админке: Настройки, Настройки продукта, Настройки модулей, Главный модуль. Опция «Посылать в заголовке статус 200 на 404 ошибку» должна быть выключена (в свежих версиях её может не быть). Пути к странице ошибки в настройках нет: это файл /404.php в корне сайта, в начале которого стоят CHTTP::SetStatus("404 Not Found") и @define("ERROR_404", "Y"). Для Apache в .htaccess нужен ErrorDocument 404 /404.php, для nginx строка error_page 404 /404.php.
3. Убеждаемся, что страница ошибки не редиректит на главную. Редирект вместо 404 хуже, чем 404.

Контрольная выборка после правки: несуществующий раздел, несуществующий товар в живом разделе, живой URL (должен быть 200), URL с опечаткой в ЧПУ, URL с параметрами. Отдельно проверьте, что живые страницы не начали отдавать 404: при неаккуратной правке правил это частый побочный эффект.

404 внутри компонентов: SET_STATUS_404, SHOW_404 и process404()

SHOW_404 отвечает за внешний вид страницы ошибки, SET_STATUS_404 за код ответа сервера. Нужны оба: без второго вы получите красивую ошибку с кодом 200.

• Где включать. Параметры комплексных компонентов bitrix:catalog и bitrix:news: через визуальный редактор или прямо в вызове компонента.
• Снятый с публикации элемент. По умолчанию легко получить 200 и пустую карточку, это и есть источник тысяч мусорных URL в индексе.
• Пустой раздел каталога. Раздел есть, товаров нет. Постоянно пустой раздел закрываем или отдаём 404, временное отсутствие в наличии оставляем 200 с подбором аналогов.
• Новости и статьи. Логика та же, последствия мягче, но дубли копятся так же.
• process404() в коде. Полное имя метода: \Bitrix\Iblock\Component\Tools::process404(). Он ставит статус 404, определяет ERROR_404 и при нужном флаге показывает /404.php. Нужен при нестандартном роутинге, своих компонентах и сборных лендингах под Директ.

После правки компонента обязательно сбросьте кэш: он мог сохранить старое поведение.

Шаблон 404.php, который возвращает посетителя в воронку

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

Что добавить

Популярные и похожие товары, последние поступления, кнопка «подобрать аналог» с передачей исходного URL в заявку.

Чего не делать

Гигантская картинка с роботом вместо навигации, авторедирект через 5 секунд, форма на 8 полей. Технически: никакого canonical на главную, никакой индексируемой ссылки из меню, в карте сайта страницы ошибки нет.

Трафик с рекламы

Если человек пришёл по объявлению на снятый товар, ценнее всего быстрый контакт с менеджером и список аналогов. Показы страницы ошибки отмечайте целью или событием в Метрике и GA4 с передачей URL: это ваш постоянный монитор, а не разовая проверка.

301 редирект в Битриксе: четыре способа и когда какой использовать

Способов четыре, и выбор зависит от объёма правил и от того, нужна ли логика по данным. Системные правила вниз, в nginx; карту переезда в таблицу правил; решения по товарам в PHP.

• .htaccess. Redirect 301 /old/ /new/ и RedirectMatch 301 ^/catalog/old/(.*)$ /catalog/new/$1. Массовые правила и регулярки, правит SEO-специалист без деплоя.
• nginx. return 301 https://site.ru$request_uri;. Домен, протокол, слэш, тяжёлые правила. Быстро, но нужен доступ к серверу.
• PHP: urlrewrite.php и init.php. LocalRedirect($url, false, '301 Moved Permanently');. Единственный вариант, когда решение зависит от данных: есть ли товар, есть ли аналог по артикулу, активен ли раздел.
• Штатные «Короткие ссылки» и модули редиректов. Короткие ссылки задуманы под промо, не под SEO-склейку; модуль редиректов удобен списком и доступен без разработчика.

И главное: 301 должен быть именно 301, а не 302 или 307. Проверяйте заголовок, а не интерфейс модуля.

Дерево решений: 301, 404, 410, canonical или 200

Критерий один: закроет ли целевая страница ту же потребность пользователя. Если нет, это не редирект, а 404 с подбором аналогов.

• Контент переехал на новый адрес: 301.
• Товар снят, есть близкий аналог: 301 на аналог, не на главную.
• Товара больше не будет, аналога нет: 404, или 410, если нужно ускорить выпадение при массовом удалении ассортимента.
• Раздел закрыт целиком: 301 на родительский раздел, если есть входящие ссылки и живой трафик.
• Технический дубль: canonical, а 301 только для адресных дублей (слэш, index.php).
• Фильтр, пагинация, параметры: 200 плюс свои правила индексации.
• Сезонная страница, вернётся через полгода: 200 или 404, но не 301.

Редирект «на всякий случай» склеивает нерелевантные страницы и даёт в Вебмастере исключения с причиной дублирования. Шпаргалка перед написанием правила: есть ли у URL трафик, есть ли внешние ссылки, есть ли релевантный аналог, вернётся ли страница, видит ли пользователь на цели то, что искал.

Почему нельзя редиректить все 404 на главную

Совет «поставьте в 404.php редирект 301 на главную и забудьте про ошибки» вредный. Вариант с форумов RedirectMatch 301 ^(.*)$ / ещё хуже: он совпадает с любым адресом, включая главную, и зацикливает весь сайт. Поисковик видит массовую подмену контента, считает такой редирект ненастоящим и всё равно обрабатывает URL как 404, только теперь вы ещё и ослепили себе диагностику.

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

Что вместо: честный 404 с полезным шаблоном и точечные 301 там, где есть релевантный аналог. Для тысяч URL группировка по паттернам, а не одно правило на всё. Массовое правило допустимо только когда группа URL одного паттерна уходит на соответствующий раздел.

Массовый переезд: как собрать карту редиректов из Вебмастера, логов и Метрики

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

1. Яндекс Вебмастер: страницы в поиске, исключённые, внутренние и внешние ссылки.
2. Google Search Console: отчёт об индексировании и страницы с трафиком.
3. Логи сервера: что реально запрашивают люди и роботы.
4. Метрика и GA4: страницы входа с трафиком и заявками за 12 месяцев.
5. Старая карта сайта и выгрузка из базы или 1С.

Таблица: old_url, new_url, код, приоритет, источник, статус проверки. Сопоставляем по артикулу, по совпадению части ЧПУ, по нормализованному названию, затем вручную просматриваем выборку. Хвост без аналогов закрываем групповыми правилами на раздел плюс честный 404. До внедрения проверьте карту на циклы (A в B и B в A), цепочки (A в B в C) и цели, которые сами отдают 404. Правила генерируются из таблицы, а не дописываются руками в .htaccess.

Регулярки для разделов каталога: рабочие примеры и как не получить петлю

Массовый перенос раздела делается одним правилом с сохранением хвоста URL. Главное условие: правило не должно совпадать с целевым URL, иначе получите бесконечный цикл.

• Перенос раздела: RedirectMatch 301 ^/catalog/staryj/(.*)$ /catalog/novyj/$1. Здесь ^ начало строки, (.*) запомненный хвост, $1 его подстановка.
• Смена вложенности: RewriteRule ^catalog/razdel/([^/]+)/$ /catalog/novyj-razdel/$1/ [R=301,L].
• Склейка двух разделов: два правила с разными источниками и одной целью.
• nginx: location ~ ^/catalog/staryj/(.*)$ { return 301 /catalog/novyj/$1$is_args$args; }.

Три правила безопасности: подставьте новый URL в своё же выражение и убедитесь, что совпадения нет; более специфичные правила ставьте выше общих; не забывайте якоря ^, $ и экранирование точек, иначе поймаете живые URL. Тестируйте на списке из 50 URL, включая 10 живых, которые совпасть не должны. При подозрении на петлю: curl -I -L --max-redirs 5, в браузере это ошибка о слишком многих редиректах.

Цепочки редиректов: слэши, index.php, www и http в один хоп

Цепочки возникают, когда нормализации живут на разных слоях и срабатывают по очереди. Лечение одно: все системные правила собрать в один слой nginx.

Типичный путь на три хопа: http://www.site.ru/razdel, затем https://www.site.ru/razdel, затем https://site.ru/razdel, затем https://site.ru/razdel/. Вместо этого одно правило приводит запрос сразу к каноническому виду: протокол, домен без www, слэш для разделов, без index.php.

Про слэш на конце: в Битриксе со ЧПУ разделы обычно со слэшем. Важно не «какой вариант правильный», а чтобы вариант был один и редирект был один. Паниковать из-за цепочек не нужно, роботы проходят несколько переходов, но каждый хоп это задержка ответа, расход краулингового бюджета и риск, что промежуточное звено сломается при следующей правке. Проверка: curl -I -L -s -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n'. После второго переезда старые правила переписывайте сразу на финальный URL, а не дополняйте.

Кэш Битрикса против редиректов: композит, автокэширование и «настроили, а не работает»

Если правка в PHP не даёт эффекта, почти всегда виноват кэш. Композитный режим и кэш компонентов отдают сохранённый результат до того, как выполнится ваш код с LocalRedirect или SET_STATUS_404.

Важное следствие: правила в nginx и .htaccess срабатывают до PHP и до композита, кэш на них не влияет. Это ещё один аргумент держать массовые правила на серверном уровне.

Порядок действий после любой правки редиректов и 404:

1. Сбросить кэш: Настройки, Автокэширование, очистка файлов кэша.
2. Отключить композит на время проверки или сбросить его кэш.
3. Сбросить кэш CDN или прокси, если он стоит перед сайтом.
4. Проверять через curl, а не в своём браузере: браузеры кэшируют 301 агрессивно, и вы будете ловить призраков.

Если после сброса кэша поведение изменилось, проблема была в кэше. Правило трогать не надо.

Что не надо редиректить: фильтры, пагинация, UTM, параметры

Редирект меняет адрес, а не управляет индексацией. Для индексации есть canonical, noindex и настройки обработки параметров.

Умный фильтр

Нужные комбинации это отдельные индексируемые страницы с текстом и своими метатегами. Ненужные: код 200 плюс noindex, не редирект и не 404. Если комбинация стала невозможна и трафика нет, честный 404; при живом трафике 301 на раздел.

Пагинация

Страницы 2, 3, N отдают 200 с canonical на себя. Редирект на первую страницу вредит обходу товаров. Битая пагинация (страница 999 при 12 существующих) это 404.

UTM и служебные параметры

UTM не редиректим никогда, иначе ломается атрибуция в Метрике и Директе. Канонизируем на чистый URL. Сортировки и служебные параметры: 200 плюс canonical.

Коротко: делаем canonical и noindex, не делаем редиректы и 404 на живых параметрических URL.

ТЗ разработчику: готовый текст задачи

Ниже текст, который можно скопировать и отправить как есть. Он закрывает и редиректы, и 404, и приёмку.

Контекст и цель. Сайт на 1С-Битрикс. Цель: сохранить трафик и посадочные рекламы при смене структуры каталога.

Что сделать. 1) Внедрить редиректы по таблице-карте (ссылка на Google Sheets), код строго 301. 2) Все системные нормализации (протокол, www, слэш, index.php) собрать в один слой nginx, один хоп. 3) Проверить, что в Главном модуле выключена опция «Посылать в заголовке статус 200 на 404 ошибку», файл /404.php в корне вызывает CHTTP::SetStatus("404 Not Found") и определяет ERROR_404, а в конфиге прописано ErrorDocument 404 /404.php (Apache) или error_page 404 /404.php (nginx). 4) Включить SET_STATUS_404 и SHOW_404 в компонентах каталога и новостей, проверить снятые с публикации элементы. 5) Сбросить кэш и кэш композита.

Запреты. Не редиректить на главную, не редиректить UTM, не трогать пагинацию и фильтры, не использовать 302 и 307, не создавать цепочки и петли.

Приёмка. Вывод curl -I -L по согласованной выборке 20 URL. Скриншот Вебмастера доказательством не считается.

Откат. Бэкап конфигов, возврат предыдущего состояния одной командой.

По срокам предметно: включение 404 и системных правил это часы, сборка и внедрение карты на тысячи строк это дни.

Чек-лист приёмки: как проверить работу до оплаты

Проверяем пять блоков, и до оплаты, а не после. Успех по строке: ожидаемый код, один хоп, целевой URL из карты.

1. Выборка 20 URL: 5 из топа по трафику, 5 с внешними ссылками, 3 заведомо несуществующих, 3 живых для контроля, 2 с UTM, 2 из пагинации и фильтра. Пакетно: while read u; do curl -s -I -L -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective} $u\n" "$u"; done < urls.txt.
2. Краулер по всему сайту (site-audit, Screaming Frog): коды ответа, цепочки, петли.
3. Живые страницы: количество URL с кодом 200 после правки не должно упасть.
4. Вебмастер и Search Console: переобход приоритетных URL, динамика исключённых.
5. Реклама: прогон всех посадочных активных кампаний Директа и Google Ads на код ответа. Эту проверку забывают почти всегда.

После запуска: переобход и мониторинг на 2, 14 и 60 день

Мониторинг разбивается на три окна, и единого числа дней для склейки нет. Ориентир для среднего магазина: недели, а не дни, при массовом переезде до двух-трёх месяцев на полную картину.

День 0-2

Прогон чек-листа, отправка приоритетных URL на переобход в Вебмастере и Search Console, обновление карты сайта, проверка логов на новые 404.

День 3-14

Смотрим исключённые страницы и причины, в GSC отчёт об индексировании. Ждём роста числа «Страница с переадресацией» и падения «Не найдено (404)».

День 14-60

Склейка старых и новых URL, перераспределение показов. Восстановление идёт неравномерно по разделам.

Сигналы тревоги

Трафик падает после 3-4 недель, растут исключённые с причиной дублирования, старые URL в выдаче не сменились. Тогда перепроверьте код ответа, релевантность цели, цепочки и canonical, противоречащий редиректу. Постоянно следите за числом 404 в логах по неделям, целью на страницу ошибки в Метрике и отчётом по посадочным рекламы.

Частые вопросы

Можно ли сделать 301 со всех 404 на главную, если их несколько тысяч?

Нет. Массовую подмену контента поисковик обрабатывает как 404, но вы при этом теряете диагностику, а пользователь, понимание происходящего. Для тысяч URL работает группировка: правила по паттернам на релевантные разделы для URL с трафиком и ссылками, честный 404 с поиском и аналогами для остального хвоста.

Через сколько дней после настройки 301 склеиваются страницы?

Единого срока нет, зависит от объёма сайта, частоты обхода и авторитетности домена. Ориентир по практике: первые сигналы в Вебмастере через 1-2 недели, основная склейка за 3-8 недель, полная картина по массовому переезду до двух-трёх месяцев. Переобход и обновлённая карта сайта ускоряют, но не кратно.

301 или 410 для товаров, которых больше не будет?

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

Настроил редирект, а он не срабатывает. При чём тут композитный кэш?

Если редирект сделан на уровне PHP (init.php, LocalRedirect, логика компонента), композит и кэш компонентов отдают сохранённую версию страницы до выполнения вашего кода. Сбросьте кэш и кэш композита, проверяйте через curl, а не в своём браузере: он кэширует 301 агрессивно. Правила nginx и .htaccess работают до PHP, кэш на них не влияет.

Почему Вебмастер пишет «страница не отвечает», если в браузере она открывается?

Браузер показывает содержимое, робот смотрит код ответа и заголовки. Типичные причины: 404 или 5xx при визуально нормальном контенте, сервер режет запросы робота, редирект уводит на недоступный URL, слишком долгий ответ. Запустите curl -I по этому URL и прочитайте первую строку, именно её видит робот.

На BitrixVM с nginx и Apache: правила в .htaccess или в конфиг nginx?

Системные правила (протокол, www, слэш, index.php) в nginx: срабатывают первыми, одним хопом, без расхода PHP. Карту переезда из сотен строк удобнее держать в .htaccess или модуле редиректов, её правят чаще и без доступа к серверу. Логику по данным только в PHP. Правило верхнего слоя перебивает нижние.

Сколько веса теряется при цепочке из трёх редиректов?

Называть процент некорректно, проверяемых цифр нет, а старые оценки про потерю доли веса на хоп давно не подтверждаются. Реальные издержки другие: задержка ответа, расход краулингового бюджета, риск поломки промежуточного звена при следующей правке. Схлопывать стоит, но не в первую очередь: сначала закройте 404 на страницах с трафиком и рекламой.

Старый и новый URL различаются только слэшем на конце, что делать?

Выберите один канонический вариант (в Битриксе со ЧПУ обычно со слэшем для разделов) и зафиксируйте одним правилом в nginx. Важно не «какой правильный», а чтобы вариант был один, редирект был один хоп и правило не совпадало с целевым URL, иначе получите бесконечный цикл. Проверка: подставьте новый URL в своё же выражение.

Как 404 влияют на Директ и Google Ads и почему отклоняют объявления?

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

Нужно ли закрывать 404-страницу от индексации в robots.txt?

Нет. Правильный код 404 сам говорит поисковику не индексировать страницу, а запрет в robots.txt мешает роботу увидеть этот код, получается хуже, чем без запрета. Что действительно нужно: честный 404, отсутствие canonical на главную, отсутствие страницы ошибки в карте сайта и в меню.

Аналога старой страницы нет: редиректить на раздел или отдавать 404?

Критерий простой: закроет ли новая страница ту же потребность. Аналога нет, но есть релевантный раздел и у старого URL живой трафик или внешние ссылки: 301 на раздел. Нет ни аналога, ни релевантного раздела: честный 404 с поиском, похожими товарами и быстрым контактом менеджера. Редирект «куда-нибудь, лишь бы не 404» хуже, чем 404.

Передаются ли по 301 поведенческие факторы и внешние ссылки?

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

Можно ли сделать 301 через «Короткие ссылки» Битрикса?

Механизм задуман под короткие промо-ссылки, а не под SEO-склейку, и по умолчанию отдаёт не тот код, который нужен для переезда. Для единичного случая сойдёт, если вы проверили curl -I и видите 301. Для карты переезда используйте .htaccess, nginx или модуль редиректов: там правила видны списком, версионируются и проверяются пакетно.

Как проверить все редиректы разом, а не по одному URL?

Два инструмента. Пакетный curl: файл со списком old_url, цикл с curl -I -L, вывод кода ответа и Location, сравнение с колонкой new_url из карты. И краулер (site-audit, Screaming Frog) в режиме списка URL: покажет коды, цепочки и петли по всему сайту. Руками остаётся только контрольная выборка 20 URL.

Что делать с 404 от старых фильтров и битых пагинаций?

Битая пагинация (страница 999 при 12 существующих), честный 404; редирект на первую страницу вредит обходу каталога. Старые URL фильтров: комбинация невозможна и трафика нет, 404; идёт живой трафик или есть внешние ссылки, 301 на соответствующий раздел. Живые, но ненужные в индексе комбинации: код 200 плюс noindex или canonical, не редирект.

Нужна помощь с Битриксом и потерянным трафиком

Разбираемся с кодами ответа предметно: аудит кодов, карта редиректов, ТЗ разработчику и приёмка, настройка 404 под воронку, проверка посадочных Директа и Google Ads. С 2012 года ведём SEO и контекст для e-commerce на 1С-Битрикс, медицины, B2B и промышленности, результат считаем в заявках и стоимости обращения, а не в позициях.

На выходе у вас остаётся таблица редиректов, протокол проверки и план мониторинга на 2 месяца.

Что сделать на этой неделе

1. Прогнать curl -I по 10 URL: живые страницы, заведомо несуществующие, снятые товары.
2. Включить установку статуса 404 в Главном модуле и проверить SET_STATUS_404 в каталоге.
3. Прогнать все посадочные активных кампаний Директа и Google Ads на код ответа.
4. Открыть в Вебмастере исключённые страницы и выписать битые URL с трафиком.
5. Начать таблицу old_url, new_url, код, приоритет.

Пришлите домен, и мы бесплатно сделаем экспресс-аудит сайта или рекламы: посмотрим коды ответа по выборке URL и по посадочным кампаний.

Материалы по теме

• SEO для сайтов на 1С-Битрикс
• Кейс: каталог на 33 915 товаров
• SEO-аудит интернет-магазина
• X-Robots-Tag и noindex: как закрыть страницу от индексации в Яндексе и Google
• Микроразметка хлебных крошек и мета-теги на Битриксе: внедрение, проверка, результат