
Ошибка 403 Forbidden значит, что сервер понял запрос, но отказался его выполнять. Сайт работает, страница существует, но кто-то на пути запроса решил, что именно этому посетителю туда нельзя. Этим «кем-то» бывает правило в nginx или Apache, файл .htaccess, проактивная защита 1С-Битрикс, плагин безопасности WordPress, сервис защиты от DDoS или неверные права на файлы.
Поэтому при 403 ищут не поломку, а запрещающее правило: кто его поставил, когда и кого оно задевает. Самые неприятные случаи в магазине выглядят тихо. Владелец со своего компьютера видит сайт, а 403 получают робот Яндекса, загрузчик товарного фида, покупатели из одной сети или сервер платёжного сервиса, который присылает уведомление об оплате. До «Чёрной пятницы» 27 ноября 2026 года осталось меньше трёх недель. Защиту сейчас подкручивают многие, и ложные блокировки появляются как раз в эти дни.
.htaccess или nginx, права на файлы, отсутствие индексного файла в каталоге.Код описан в стандарте HTTP, RFC 9110, раздел 15.5.4. Сервер понял запрос, но отказывается его выполнять. Если в запросе были логин и пароль, сервер считает их недостаточными. Стандарт отдельно оговаривает, что запрет может быть вызван причинами, не связанными с учётными данными. Там же сказано, что сервер, который хочет скрыть само существование закрытого ресурса, вправе ответить 404.
Отличия на практике:
В справочнике кодов Яндекс Вебмастера про 403 написано коротко: доступ к документу запрещён, и если вы хотите, чтобы страница индексировалась, доступ к ней нужно разрешить. В разделе о доступности сайта сказано, что страница с кодом, отличным от 200 OK, недоступна для роботов и посетителей и не может попасть в поиск.
В ноябре магазины готовятся к 11.11 и «Чёрной пятнице»: включают защиту от ботов, закрывают админку по IP, ставят плагины безопасности, обновляют модули после летних уязвимостей. Каждое такое изменение добавляет правила запрета. Правило, которое отсекает подозрительный трафик, легко задевает и нужный.
Кого задевает чаще всего:
yandex.ru, yandex.net или yandex.com. Список IP-адресов Яндекс не раскрывает, потому что адреса часто меняются. Белый список робота по IP поэтому ненадёжен, а блокировка «всех, кто часто ходит по каталогу» рано или поздно задевает робота./bitrix/admin/ может остановить выгрузку цен и остатков..htaccess после обновления плагина, правки конфигурации nginx, включённая геоблокировка, новый уровень защиты у провайдера. Если 403 появился в день изменения, начните с отката именно его.wp-config.php и предупреждает, что каталогам никогда не стоит давать 777. Права «на всякий случай» не повышайте.Если сайт отдаёт 403 на всех страницах всем посетителям, порядок первых действий тот же, что при любом простое: «Сайт лежит: что делать».
| Источник | Признак | Кто проверяет | Как проверить | Как часто |
|---|---|---|---|---|
| Сервис защиты от DDoS или CDN | Страница ошибки провайдера, в журнале вашего сервера запросов нет | Владелец аккаунта защиты | Журнал событий провайдера, правила по странам и ботам | После каждой смены уровня защиты |
| Проактивная защита Битрикса | 403 у отдельных IP, страница в оформлении сайта | Разработчик | «Стоп-лист» и «Монитор проактивной защиты» | Еженедельно в сезон |
| Плагин безопасности WordPress | 403 после обновления плагина или при входе | Разработчик | Журнал блокировок плагина, правила в .htaccess |
После обновлений |
| Правила nginx или Apache | 403 на конкретных путях у всех | Разработчик или хостинг | access.log, error.log, конфигурация |
При каждом изменении конфигурации |
| Права на файлы и владелец | 403 на картинках, стилях, загрузках после переноса | Разработчик | Права и владелец каталогов | После переезда и восстановления из копии |
| Нет индексного файла в каталоге | 403 на адресе каталога | Разработчик | Наличие index.php или index.html |
При выкладке |
| Блокировка робота Яндекса | Страницы выпадают из поиска, у людей всё открывается | SEO-специалист | «Проверка ответа сервера», проверка IP робота в Вебмастере | Еженедельно в сезон |
| Блокировка уведомлений об оплате | Деньги списаны, заказ не оплачен | Владелец магазина и разработчик | Коды ответов на адрес уведомлений, недоставленные уведомления у провайдера | Ежедневно до конца распродаж |
Команды для первого часа. Пути к журналам зависят от системы и хостинга, формат журнала предполагается стандартный (combined):
# Какие адреса чаще всего отдают 403
awk '$9 == 403 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# С каких IP приходят запросы, получившие 403
awk '$9 == 403 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Что отвечает сайт на адрес уведомлений об оплате (подставьте свой путь)
grep "/payment/notify" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c
# Причины отказов в журнале ошибок
grep -i "forbidden" /var/log/nginx/error.log | tail -20
# Настоящий ли это робот Яндекса: обратный и прямой DNS-запрос
host 203.0.113.10 # имя должно оканчиваться на yandex.ru, yandex.net или yandex.com
host <полученное имя> # адрес должен совпасть с исходным IP
Чек-лист на неделю до распродажи:
[ ] Выписать все правила запрета: CDN/защита, nginx/Apache, .htaccess, стоп-лист Битрикса, плагин WordPress
[ ] Для каждого правила записать, кто его включил и зачем
[ ] Разрешить адрес приёма уведомлений об оплате для адресов из документации платёжного сервиса
[ ] Разрешить адреса обмена с 1С и выгрузки фидов для тех, кто их реально вызывает
[ ] Проверить, что робот Яндекса не блокируется: «Проверка ответа сервера» по 10 ключевым страницам
[ ] Открыть каталог, карточку, корзину и оплату с мобильного интернета двух разных операторов
[ ] В кабинете платёжного сервиса проверить, нет ли недоставленных уведомлений
[ ] Договориться, кто и как быстро снимает ложную блокировку в день распродажи
[ ] Записать, как снять самоблокировку админки, пока доступ есть
Шаблон сообщения хостингу или подрядчику:
Тема: 403 Forbidden на <домен>, нужна причина отказа
С <дата, время по Москве> на адресах <список адресов> посетители получают 403.
Кто видит ошибку: <все / только мобильный интернет / робот Яндекса / платёжный сервис>.
Пример запроса из журнала: <строка из access.log с IP, временем и адресом>.
Что меняли в последние дни: <обновления, правила защиты, перенос>.
Просим: найти правило, которое отдаёт 403 на эти запросы, и сообщить, можно ли сузить его до нужных адресов.
Ситуация условная, собрана для иллюстрации.
Магазин на 1С-Битрикс за две недели до «Чёрной пятницы» включил у провайдера защиты от DDoS повышенный уровень и блокировку запросов из-за рубежа. Сайт у владельца и менеджеров открывается, проверка главной зелёная. Через сутки бухгалтер замечает расхождение: в кабинете ЮKassa оплаченных платежей больше, чем оплаченных заказов на сайте. Менеджеры вручную звонят покупателям, которые пишут, что деньги списались, а письма нет.
В журнале nginx запросов на адрес уведомлений об оплате за сутки нет совсем. Значит, отказ шёл раньше, у провайдера защиты. В его журнале событий такие запросы отклонены правилом для автоматического трафика. Адрес уведомлений вывели из-под этого правила и разрешили для адресов из документации ЮKassa. Уведомления, которые ещё укладывались в 24 часа, дошли повторно, остальные заказы сверили вручную по выгрузке платежей. Вывод для команды: после каждой смены уровня защиты проверять не только главную, но и путь оплаты, фид и робота.
Ограничения. Команды выше подходят для своего сервера или VPS с nginx. На виртуальном хостинге журналы и часть правил видит только хостинг: начните с шаблона сообщения выше. На Tilda и InSales сайт работает на инфраструктуре платформы, и 403 там чаще связан с настройками доступа к странице или с защитой платформы, поэтому пишите в поддержку. Ни одна настройка не гарантирует отсутствия ложных блокировок. Задача в том, чтобы узнавать о них за минуты, а не по жалобам.
Если сайт открывается из другой сети, а у вас нет, скорее всего, заблокирован ваш IP или подсеть: защита сайта, стоп-лист Битрикса или ваш корпоративный прокси. Если 403 видят все, запрет стоит на сайте или у его провайдера защиты.
Найдите правило, которое отдало отказ: по виду страницы ошибки, журналу доступа и журналу ошибок. Затем сузьте или уберите это правило, проверьте права на файлы и пройдите путь покупки из внешней сети. Перезагрузка сервера 403 не лечит.
Страница с кодом, отличным от 200, по справке Вебмастера не может попасть в поиск. Если робот долго получает 403, страницы выпадают из индекса. После исправления проверьте их в «Проверке ответа сервера» и отправьте на переобход. Как действовать, если страницы уже пропали, разобрано в статье «Сайт пропал из поиска Яндекса».
Require all denied): https://httpd.apache.org/docs/2.4/mod/mod_authz_core.htmlПроверено: 10 ноября 2026 года.
Шаг «узнать о 403 раньше покупателей» можно автоматизировать. Pingvera раз в минуту проверяет доступность сайта по HTTP из нескольких регионов и с мобильным User-Agent, подтверждает сбой повторными проверками и присылает алерт в Telegram, MAX, VK, на почту или в webhook. Для WooCommerce сервис следит и за потоком заказов: если страницы открываются, а заказы перестали приходить, придёт отдельный алерт. Бесплатный тариф покрывает до 5 сайтов, разовую проверку можно сделать без регистрации на https://pingvera.ru/check.
Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.
Попробовать Pingvera бесплатноЧитайте также: Ошибка 503 на сайте: что значит и что делать · Ошибка 504 на сайте: причины и что делать магазину · Сайт взломан: что делать магазину в первые 24 часа · Белый список сайтов: что делать интернет-магазину · Бесплатно проверить сайт.