1. Главная
  2. Блог
  3. 1С-Битрикс
  4. Как отключить раздел в 1С-Битрикс и вернуть 404 вместо ответа 200

Как отключить раздел в 1С-Битрикс и вернуть 404 вместо ответа 200

9 августа 2026
107

В 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-статус.

Это можно сделать через инструменты разработчика браузера:

  1. Открыть инструменты разработчика.
  2. Перейти на вкладку Network или Сеть.
  3. Обновить страницу.
  4. Выбрать основной запрос документа.
  5. Проверить значение 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.

404 на раздел 1с-битрикс

После такого отключения полезно проверить не только основной адрес раздела, но и несколько старых вложенных URL. Правило urlrewrite.php может продолжать направлять их в тот же index.php, поэтому корректность удаления лучше подтверждать именно по HTTP-статусу каждой страницы. Для сайтов с большим количеством ЧПУ-адресов такую проверку удобно проводить при сопровождении сайта на 1С-Битрикс.

После отключения инфоблока старые URL продолжают отвечать 200? Проверим правила ЧПУ, обработку 404 и фактические ответы сервера в рамках поддержки сайта на 1С-Битрикс.

Понравилась статья?

Поддержать нас рублями:

Нужна помощь? Обращайтесь!

Комментарии
Name
Email
Phone
Ваше имя
Ваш email
Оставить комментарий
Нажмите для звонка
+7 (499) 341-00-19