В 1С-Битрикс недостаточно просто деактивировать инфоблок, раздел инфоблока или элементы внутри него. Даже после отключения контента старый адрес страницы может продолжать открываться и возвращать серверный ответ 200 OK.
Для поисковых систем такой ответ означает, что страница существует и успешно работает. При этом пользователь может видеть пустой раздел, старый шаблон, сообщение об отсутствии элементов или полностью белый экран.
Разберём, почему это происходит и как для конкретной страницы принудительно вернуть настоящий ответ 404 Not Found, сохранив старый код для возможного восстановления.
Почему отключённый раздел продолжает открываться
В Битрикс необходимо разделять две разные вещи:
- активность инфоблока, раздела или элемента;
- маршрутизацию URL и выполнение PHP-файла страницы.
Когда администратор снимает галочку «Активен» у инфоблока или его раздела, данные перестают выводиться стандартными компонентами. Однако сам адрес страницы при этом не обязательно исчезает.
Например, для раздела видеоинструкций может существовать физический файл:
/video_instruktsii/index.php
Кроме того, в файле /urlrewrite.php может находиться правило:
191 =>
array(
'CONDITION' => '#^/video_instruktsii/#',
'RULE' => '',
'ID' => 'bitrix:news',
'PATH' => '/video_instruktsii/index.php',
'SORT' => 100,
),Это правило продолжает направлять все обращения по адресам внутри раздела в файл:
/video_instruktsii/index.phpПоэтому даже после деактивации инфоблока запрос успешно обрабатывается PHP-файлом, а сервер может вернуть код 200 OK.
Почему ответ 200 является проблемой
Если раздел больше не должен существовать, ответ 200 вводит поисковые системы в заблуждение. Робот считает, что страница доступна, продолжает хранить её в индексе и периодически переобходит.
В результате могут возникнуть следующие проблемы:
- в индексе остаются удалённые или пустые страницы;
- появляются так называемые мягкие ошибки 404;
- поисковый робот тратит ресурсы на несуществующие URL;
- пользователи переходят на пустую или некорректную страницу;
- вебмастеры Яндекса и Google могут фиксировать неправильные ответы сервера.
Если страница действительно удалена, она должна возвращать HTTP-статус:
404 Not FoundПочему простой вызов process404 может показать белый экран
Для формирования ошибки 404 в Битрикс часто используют метод:
\Bitrix\Iblock\Component\Tools::process404()Иногда его вызывают после подключения только служебного пролога:
<?php
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/modules/main/include/prolog_before.php"
);
\Bitrix\Iblock\Component\Tools::process404(
"",
true,
true,
true,
"/404.php"
);
exit;HTTP-ответ 404 в таком случае может устанавливаться правильно, но вместо оформленной страницы ошибки пользователь увидит белый экран.
Причина в том, что файл prolog_before.php только инициализирует ядро Битрикс. Он не подключает шапку сайта, визуальный шаблон, стили и рабочую область страницы.
Чтобы штатная страница 404 вывелась внутри дизайна сайта, перед вызовом process404() необходимо подключить полный файл:
/bitrix/header.phpРабочее решение для конкретной страницы
В начало файла отключаемого раздела необходимо добавить переключатель и обработку ошибки 404.
Например, файл:
/video_instruktsii/index.phpможет начинаться следующим образом:
<?php
$pageDisabled = true;
if ($pageDisabled) {
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/header.php"
);
if (\Bitrix\Main\Loader::includeModule("iblock")) {
\Bitrix\Iblock\Component\Tools::process404(
"",
true,
true,
true,
"/404.php"
);
}
/*
* Резервная установка статуса.
* Она сработает, если модуль инфоблоков
* по какой-либо причине не подключился.
*/
\CHTTP::SetStatus("404 Not Found");
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/footer.php"
);
exit;
}
/*
* Ниже остаётся старый код страницы.
* Пока $pageDisabled равен true,
* этот код не выполняется.
*/
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/header.php"
);
$APPLICATION->SetPageProperty(
"title",
"Как пользоваться техникой MIE и Grand Master — видео"
);
$APPLICATION->SetPageProperty(
"description",
"Смотрите видео о том, как пользоваться техникой MIE и Grand Master."
);
$APPLICATION->SetPageProperty(
"HIDE_LEFT_BLOCK",
"Y"
);
$APPLICATION->SetTitle(
"Как пользоваться техникой MIE и Grand Master — видео"
);
/*
* Здесь остаются старые компоненты,
* HTML-разметка и другой код страницы.
*/
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/footer.php"
);Что делают параметры process404
Вызов метода выглядит так:
\Bitrix\Iblock\Component\Tools::process404(
"",
true,
true,
true,
"/404.php"
);Параметры означают следующее:
- первый параметр — текст сообщения об ошибке;
- второй параметр — определить константу
ERROR_404; - третий параметр — установить HTTP-статус 404;
- четвёртый параметр — показать специальную страницу ошибки;
- пятый параметр — путь к файлу штатной страницы 404.
В результате Битрикс должен вернуть настоящий серверный ответ 404 и вывести существующий файл:
/404.php
При этом изменять сам общий файл /404.php не требуется.
Зачем использовать переключатель
Переменная:
$pageDisabled = true;позволяет отключить страницу, не удаляя старый код.
Это удобно, если раздел может понадобиться позднее. Весь прежний код страницы остаётся в файле, но не выполняется, поскольку обработка завершается командой:
exit;Для восстановления страницы достаточно изменить значение:
$pageDisabled = true;на:
$pageDisabled = false;После этого обработка 404 будет пропущена, а Битрикс снова выполнит старый код страницы.
Нужно ли удалять правило из urlrewrite.php
В рассматриваемом случае правило из /urlrewrite.php можно оставить без изменений:
array(
'CONDITION' => '#^/video_instruktsii/#',
'RULE' => '',
'ID' => 'bitrix:news',
'PATH' => '/video_instruktsii/index.php',
'SORT' => 100,
),Оно продолжит направлять основной и вложенные адреса раздела в один PHP-файл:
/video_instruktsii/
/video_instruktsii/category/
/video_instruktsii/category/video/
После этого файл index.php принудительно вернёт для каждого такого URL ответ 404.
Это даже удобно: все старые адреса раздела обрабатываются централизованно и гарантированно получают корректный статус.
Удалять правило из urlrewrite.php имеет смысл только при окончательном удалении физической страницы и всего связанного с ней функционала.
Почему не стоит подключать только prolog_before.php
Для фоновых обработчиков, AJAX-запросов и служебных скриптов часто используют:
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/modules/main/include/prolog_before.php"
);Но для вывода штатной страницы ошибки в дизайне сайта этого может быть недостаточно.
В рассматриваемой задаче необходимо подключать:
require(
$_SERVER["DOCUMENT_ROOT"] .
"/bitrix/header.php"
);
Именно header.php подключает полный публичный пролог, шаблон сайта, стили, метаданные и рабочую область страницы.
Как проверить правильность ответа
Недостаточно визуально увидеть надпись «Страница не найдена». Необходимо проверить фактический HTTP-статус.
Это можно сделать через инструменты разработчика браузера:
- Открыть инструменты разработчика.
- Перейти на вкладку Network или Сеть.
- Обновить страницу.
- Выбрать основной запрос документа.
- Проверить значение Status Code.
Корректный результат:
404 Not FoundТакже можно выполнить проверку через командную строку:
curl -I https://site.ru/video_instruktsii/В ответе должна присутствовать строка:
HTTP/2 404или:
HTTP/1.1 404 Not FoundНе забудьте очистить кеш
После изменения файла желательно очистить кеш Битрикс. Если на сайте используется композитный режим, старая версия страницы может продолжать некоторое время показываться из HTML-кеша.
Следует проверить:
- управляемый кеш Битрикс;
- композитный кеш;
- серверный кеш;
- кеш CDN, если он используется;
- кеш браузера.
Распространённые ошибки
Страница показывает текст ошибки, но возвращает 200
Это означает, что была выведена визуальная страница «Не найдено», но серверный статус не был установлен.
Необходимо использовать:
\CHTTP::SetStatus("404 Not Found");
или передать третьим параметром true в метод process404().
Возвращается 404, но экран остаётся белым
Наиболее вероятная причина — подключён только:
/bitrix/modules/main/include/prolog_before.phpВместо него для полноценной страницы следует подключить:
/bitrix/header.phpПосле команды exit старый код не работает
Это ожидаемое поведение. Команда exit завершает выполнение текущего PHP-файла.
Для восстановления страницы необходимо изменить переключатель:
$pageDisabled = false;После деактивации раздела старые вложенные URL всё ещё открываются
Это происходит потому, что правило urlrewrite.php продолжает направлять их в общий файл раздела.
При использовании описанного решения это не является проблемой: общий файл вернёт для всех вложенных адресов настоящий ответ 404.
Заключение
Деактивация инфоблока или его раздела в административной части Битрикс не всегда означает, что соответствующий URL перестанет существовать.
Если физический файл страницы и правило ЧПУ продолжают работать, сервер может возвращать код 200 даже для отключённого раздела.
Для корректного удаления страницы необходимо:
- подключить полный публичный пролог через
/bitrix/header.php; - вызвать
process404(); - установить настоящий HTTP-статус 404;
- завершить выполнение файла через
exit; - оставить старый код ниже переключателя для возможного отката;
- проверить ответ сервера через браузер или команду
curl.
Такой подход позволяет отключить конкретный раздел, не изменяя общий шаблон страницы 404 и не удаляя правило из urlrewrite.php.
После такого отключения полезно проверить не только основной адрес раздела, но и несколько старых вложенных URL. Правило urlrewrite.php может продолжать направлять их в тот же index.php, поэтому корректность удаления лучше подтверждать именно по HTTP-статусу каждой страницы. Для сайтов с большим количеством ЧПУ-адресов такую проверку удобно проводить при сопровождении сайта на 1С-Битрикс.



