bitrix редирект на 404

Bitrix и ошибка 404

Давно бились над проблемой с SEO и применением стандартных комплексных компонентов (bitrix:news, bitrix.catalog) при использовании ЧПУ.

Проблема заключалась вот в чем: при отдаче страницы с отсутствующим элементом или секцией инфоблока выставляется статус «404 Not Found» (в теле компонентов bitrix:news.list, bitrix:news.detail, bitrix:catalog.section, bitrix:catalog.element есть соответствующие строки, но к сожалению не было способа показать тело 404-ой страницы (мы обычно создаем страницу /404.php) с ее оформлением и пр.

Поначалу нас устраивал редирект на эту страницу вида:

но чтобы им воспользоваться приходилось создавать дубликаты компонентов в своем пространстве имен (anima:catalog.section, например).
[spoiler]
Потом было найдено более изящное решение, не задевающее компоненты. В стандартных компонентах используется определение константы ERROR_404 в случае проблем с поиском инфоблока, секии, элемента во время выполнения компонента, но по заверениям разработчиков она используется исключительно для статистики. Однако, отображение стрницы – единый runtime и определенные константы можно использовать практически в самом его (runtime-a) конце. Результатом этих роазмышлений стал код в init.php:

Довольно легко для понимания и универсально и работает везде, но. У данной конструкции (у редиректа) естьи темные стороны.

Путем экспериментов, проб и ошибок мы пришли к довольно универсальной записи:

Внимательный зритель заметит, что в функции появилась константа PATH_TO_404. Определять данную константу предлагается первой строкой в визуальной части пролога:

Источник

Настраиваем страницу 404-й ошибки в Битриксе

Введение

Страница 404-й ошибки должна загружаться в том случае, если человек попытался открыть несуществующую страницу. Увидев сообщение «Страница не найдена» пользователь поймет, что ошибся при вводе адреса, либо перешел по нерабочей ссылке.

Но по нерабочей ссылке может перейти не только человек, но и робот поисковой системы. Поэтому, кроме текстового сообщения об ошибке, страница должна отдавать HTTP-код 404 – так поисковики понимают, что они попытались попасть на несуществующую страницу. Разберемся, как создать страницу 404-й ошибки на сайте, который работает на системе управления 1С-Битрикс.

Создаем страницу /404.php

Для начала создаем в корне сайта файл 404.php со следующим кодом:

Если в корне сайта этот файл уже существует, проверяем, чтобы в самом начале были эти три строчки, они важны, если их нет – добавляем:

Если интересно разобраться — отдельно рассмотрим каждую строчку нашего файла:

— подключаем систему обработки адресов Битрикса, чтобы корректно обрабатывать адреса динамических разделов (статей, новостей, каталогов).

— устанавливаем HTTP-статус 404, благодаря этим строчкам поисковики поймут, что запрашиваемой страницы не существует.

— подключаем шапку сайта.

— отключаем отображение цепочки навигации (хлебных крошек) на этой странице.

— устанавливаем h1 и title страницы.

— контент страницы, его можете отредактировать на своё усмотрение.

— подключаем подвал сайта.

Окей, страничку создали, идем дальше.

Проверяем настройки главного модуля

В админке идем в настройки Главного модуля (Настройки => Настройки продукта => Настройки модулей => Главный модуль) и проверяем, чтобы опция Посылать в заголовке статус 200 на 404 ошибку была отключена:

По названию опции понятно: если галочка стоит – страница с 404-й ошибкой будет возвращать статус 200, а это нам ни к чему. Поэтому если галочка стоит – убираем её.

Настраиваем компоненты

В настройках всех компонентов, которые отвечают за страницы детального просмотра, нужно настроить режим обработки 404-й ошибки. Например, это могут быть компоненты «Новости», «Каталог», «Новость детально», «Элемент каталога детально» — одним словом все компоненты, которые генерируют страницы детального просмотра.

Тут без конкретного примера не обойтись, поэтому рассмотрим следующую ситуацию: на сайте есть раздел «Новости», страница детального просмотра новостей генерируется компонентом «Новость детально». Урлы новостей выглядят следующим образом /news/simvolnyj-kod-novosti/

Если мы перейдем в настройки данного компонента — в самом низу увидим блок Настройки 404 ошибки. По-умолчанию он выглядит вот так:

Т.е. обработка 404-й ошибки не настроена. Если мы попытаемся открыть страницу с несуществующей новостью, например /news/asdfgffj4/ — получим вот такое стандартное сообщение:

Сама страничка отдает HTTP-код 200. Так быть не должно, срочно исправляем! В настройках компонента отмечаем галочки Устанавливать статус 404 и Показ специальной страницы, поле Страница для показа не заполняем, т.к. по умолчанию это страница /404.php – т.е. то, что нам нужно. Блок настроек компонента теперь выглядит следующим образом:

Теперь при попытке открыть несуществующую новость получаем нашу страницу 404:

Проверяем результат работы

Мы всё настроили, остается проверить, отдает ли наш сайт код 404 для несуществующих страниц. Для таких целей можно использовать сервис яндекса https://webmaster.yandex.ru/tools/server-response/

Указываем ему любую несуществующую страницу нашего сайта и получаем ответ:

Если Код статуса HTTP равен 404 Not Found — поздравляю, вы всё сделали правильно. Теперь вы знаете, как настроить страницу-обработчик 404-й ошибки в Битриксе 🙂

Другие посты из этой же рубрики:

Copyright © 2015-2021, Алфавитка.ру – IT-блог разработчика.

Источник

301 redirect на страницу 404.html

Всем доброго времени суток
Задача стоит такая:
На сайте настроена отдача 404й ошибки без изменения урла, нужно сделать 301 редирект на статическую страницу 404.html которая будет отдавать 404 статус.

CHTTP::SetStatus(404); или header(«HTTP/1.0 404 Not Found»);

переключает статус для данной страницы на 404. добавьте в начало кода страницы 404.php

А с чего бы существующей странице отдавать статус что она не существует?

Но если прямо очень надо, то в станртной 404.php сделайте LocalRedirect(‘/404.html’,301), в Обработке адресов правило «#^/404.html» и файл «/404_404.php» и в него поместите то что у вас сейчас в 404.php.

Вроде правильно же написал?

переключает статус для данной страницы на 404. добавьте в начало кода страницы 404.php

Это ничего не меняет. так как вконце идет LocalRedirect.

Suntechnic, 301 редирект идет не со всех страниц а только с несуществующих, тоесть если раньше у меня были ссылки:
http://mysite/tovar_1
http://mysite/tovar_2
http://mysite/tovar_3

А потом товар 2 сняли с продаж но в поисковиках он остался проиндексированным, нужно чтоб при переходе по ссылке на него происходил 301 редирект на 404.html. Остальные товары же как положено отдают 200.

Вот это и сделал, а вот по следующему пункту непонятно

Добавил правило и в «404_404.php» прописал:

Источник

Не работает 404 ошибка в 1с битрикс. Правильная настройка

В битриксе 404 ошибка отрабатывается весьма специфически — неправильный адрес со статических страниц и разделов корректно перебрасывает на страницу 404.php, при этом сохраняя неправильный URL в адресной строке браузера. То есть все по seo.

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

В интернете данный вопрос поднимался не раз. Когда-то популярным решением была настройка в битрикс принудительного редиректа на 404 страницу.))) Перечитав изрядно статей, выполнив несколько найденных инструкций, желаемого результата добиться не удалось(((. Пришлось, вооружившись командой print backtrace, отловить негодяйскую 404 ошибку и заставить ее работать как положено.

Ставим задачу:

На что стоит обратить внимание:

1. Файл 404.php — лежит в корне сайта. Должен выглядеть вот так (тут все стандартно):

Если у вас сервер на nginx, то нужно прописать в конфиге, в секции location, следующее:

тех. отступление:

Попробуем сэмулировать 404 ошибку с какой-нибудь статической страницы и отловить результат через команду debug_print_backtrace ( ) ;

Смотрим файл — видим там строку с инклюдом 404 страницы. Она вызывается, очевидно, в том случае, если страница не найдена в структуре файлов и папок, а также в файле urlrewrite.php в корне сайта, где как раз описаны все наши инфоблоки и каталоги (для правильной работы ЧПУ).

Первая поставленная нами задача выполняется настройкой инфоблоков и компонентов:

3. Проверим настройки самих каталогов:

URL страницы ИБ — должен указывать на папку, из которой будет осуществляться вызов инфоблока.

URL страницы раздела — если структура инфоблока будет иметь подразделы, то ссылка должна строиться на основе символьного кода раздела.

URL страницы детального просмотра — если элемент находится в подразделе, то к ссылке будет прибавляться символьный код раздела перед символьным кодом элемента. Иначе — только символьный код элемента.

4. И инфоблоков:

то есть, как мы видим, для инфоблоков подразделы можно не описывать.

5. Проверяем настройки вызова инфоблоков:

Обязательно проверяем, что отмечена галка «Включить поддержку ЧПУ»!

Каталог ЧПУ — корневая папка инфоблока

Раздел — #SECTION_CODE#/ — повторяем из настроек инфоблока, но не ставим слеш в начале, иначе компонент будет работать не верно

Детальная информация — #SECTION_CODE#/#ELEMENT_CODE#/ — ссылка формируется на основе символьного кода раздела (если есть) и кода элемента. Опять же, слеш в начале не ставим!

Если предполагается, что все элементы будут располагаться в корне инфоблока, без подразделов, то можно использовать следующие настройки:

6. Отмечаем галочку там же в настройках: «Устанавливать статус 404, если не найдены элемент или раздел:».

тех. отступление:

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

Этим мы и воспользуемся, а чтобы данный статус правильно обрабатывался

7. Добавим следующий код в файл /bitrix/php_interface/init.php:

С этого момента страница ошибок будет работать! (наверно))) Если нет, опишите вашу ситуацию в комментариях

UPD от 29.08.15: чуть обновил код файла 404.php и сниппет для init.php

UPD от 15.01.18: настраивал сегодня на одном проекте отладку 404-й ошибки по данной инструкции. Все работает отлично)) Версия битрикса — последняя на указанную дату

Роман Моренец

Конвертируем гостей и анонимов в честных пользователей wordpress

Источник

Ошибка 404

Как правило, при попытке обращения к объекту, который не существует или более неактивен, стандартный компонент Битрикс выводит надпись » Элемент не найден «.

Иногда вместо указанной надписи заказчик просит выводить содержимое страницы 404:

При этом, требуется соблюдение следующих условий: сохранение оригинального адреса обращения, установка правильного кода ответа (404) и отсутствие дополнительных перенаправлений (301 или 302). По мнению некоторых специалистов по продвижению, перечисленные требования необходимы для корректной обработки страницы поисковыми роботами.

Существует несколько решений данной задачи. Далее будет рассмотрено, пожалуй, наиболее лаконичное из всех. Единственным обязательным требованием, которое определяет работоспособность результата, является наличие сервера nginx «на входе». При этом, доступ к файлам конфигурации веб-сервера не требуется.

В файле с обработчиками событий (например, /bitrix/php_interface/init.php) следует разместить следующий обработчик:

Первое условие проверяет наличие и значение константы ERROR_404. Данная константа определяется большинством стандартных компонентов Битрикс в том случае, если не удалось найти объект, к которому произошло обращение. В качестве объекта может выступать, например, элемент информационного блока.

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

Особое внимание стоит обратить на служебный заголовок «X-Accel-Redirect». Этот заголовок ожидается исключительно веб-сервером nginx и позволяет организовать внутреннее перенаправление из PHP. Как ни странно, информации об этом заголовке в Сети незаслуженно мало: из разумных примеров мне удавалось найти лишь способ построения системы контролируемых скачиваний. На деле же, данный функционал предоставляет возможность для элегантного решения широкого класса задач.

Источник