Настройка 404-мониторинга сайта и Telegram-уведомлений

Я обычно настраиваю 404-мониторинг в пару слоёв: сначала ловлю сами 404-ошибки на сервере, потом завожу Telegram-уведомления, чтобы не сидеть и не вылавливать битые ссылки руками. На деле это сильно экономит время, особенно если сайт живёт на WordPress, Bitrix или Laravel и в день получает не 20 визитов, а 5000+.

Если у вас уже есть нормальный мониторинг сайта, то 404-ошибки всё равно нельзя бросать на самотёк. Они появляются после редизайна, переезда на другой URL, удаления товаров, смены структуры каталога, кривых внешних ссылок и банальных опечаток. И чем раньше вы увидите такую ошибку, тем меньше потеряете трафика и нервов. Я отдельно это разбираю в рамках доработки сайта, потому что 404-мониторинг почти всегда становится частью технической поддержки, а не разовой настройкой.

Зачем вообще нужен 404-мониторинг

404 — это не просто «страница не найдена». Это сигнал, что пользователь, бот или какой-то внешний сервис попытался открыть URL, которого больше нет или который никогда не существовал. И если таких запросов становится много, у вас начинаются вполне конкретные проблемы: проседает поведенческий фактор, теряется часть SEO-трафика, появляются жалобы от менеджеров и клиентов, а иногда ломается внутренняя логика сайта.

У меня был клиент на WordPress 6.5 с WooCommerce, где после обновления темы полетели ссылки из меню и карточек товаров. В логе за сутки накопилось 1800 запросов на 404. Пользователь, конечно, иногда и сам виноват, но 40–50% этих случаев были наши же старые URL. И вот здесь мониторинг нужен не для красоты, а чтобы сразу увидеть, что на сайте пошло не так.

Честно говоря, многие путают 404-мониторинг с общей проверкой доступности. Это разные вещи. Uptime-мониторинг говорит: «сайт отвечает или нет». А 404-мониторинг отвечает на другой вопрос: «какие конкретно адреса на сайте сломались и кто на них ходит». Я обычно ставлю оба инструмента вместе. Про базовый подход к этому я уже писал в статье Как настроить мониторинг сайта: полное руководство, а если нужен фокус именно на 404 и битые URL — смотрите также Как настроить 404-отчет и мониторинг сломанных URL в 2026.

Какие 404 стоит ловить, а какие можно игнорировать

Не все 404 одинаково полезно тащить в Telegram. Если начать слать каждую мелочь, через сутки вы просто отключите уведомления. Это плохая идея. Я обычно делю 404 на три категории: критичные, важные и шум.

Критичные — это когда сломалась внутренняя ссылка на важную страницу, товар, услугу, раздел, форму заявки или посадочную страницу. Важные — это массовые 404 на популярных URL после релиза, редизайна или переноса сайта. Шум — это запросы к несуществующим favicon.ico, wp-login.php, случайным сканерам, ботовым мусорным адресам и странным UTM-хвостам от внешних сервисов.

На моей практике шум надо фильтровать сразу. Иначе Telegram превратится в помойку. Если у вас WordPress, обязательно отсекайте типовые запросы ботов и мусорные пути. Если Bitrix — отдельно проверьте служебные URL, которые иногда 404-ят у новых шаблонов или после смены маршрутизации. Про общую гигиену ссылок и устаревших адресов полезно почитать Настройка устаревших ссылок и поиск битых URL в 2026 году.

Откуда брать данные для мониторинга 404

Источников обычно два: серверные логи и прикладные логи CMS/фреймворка. Идеально — использовать оба. Серверные логи дают реальную картину по запросам, а логика в коде позволяет отдельно обработать 404 на уровне приложения, если это важно для аналитики или интеграций.

Если сайт крутится на Nginx, я чаще всего смотрю access.log и error.log. Для Apache — access.log плюс error_log и, если нужно, .htaccess-обработку. Для Laravel можно отдельно логировать несуществующие маршруты через middleware или глобальный handler. Для Bitrix иногда удобно завести отдельный обработчик на уровне шаблона или через event.

На деле, если у клиента хостинг без root-доступа, я всё равно настраиваю мониторинг через PHP-скрипт по cron. Да, это не идеал. Но это рабочее решение, когда у вас обычный shared-hosting, PHP 8.2 и доступ только к файловой системе и панели управления. Если нужна профессиональная настройка силами специалиста, это как раз тот случай, где разумнее не изобретать велосипед, а заказать проверку сайта и потом уже внедрить мониторинг аккуратно.

Пример: что удобно ловить в логе

• внутренние ссылки на удалённые страницы;
• ошибки после смены структуры каталога;
• битые ссылки из меню, хлебных крошек и footer;
• URL из старой версии сайта после миграции;
• ссылки из писем, PDF, рекламных креативов и соцсетей.

И отдельно я бы проверял страницы, на которые идут внешние переходы. Если на них есть трафик, а они 404-ят, это уже не просто техническая мелочь, а прямые потери. Особенно если у вас интернет-магазин или портал с каталогом. Тогда 404-мониторинг нужно завязывать на редиректы и SEO-логику. Тут очень кстати статья Как настроить 301 и 302 редиректы без петель и 404.

Варианты реализации: PHP, Nginx, Apache и готовые сервисы

Если говорить без лишней теории, вариантов четыре. Первый — ловить 404 в коде CMS или фреймворка. Второй — анализировать логи по cron. Третий — использовать готовый внешний сервис мониторинга. Четвёртый — комбинировать всё это. Я чаще всего выбираю именно комбинированный вариант, потому что он надёжнее.

На WordPress можно написать небольшой плагин или mu-plugin, который будет срабатывать на template_redirect и при отсутствии страницы отправлять запись в лог. В Bitrix это тоже делается, но там я обычно аккуратнее: не люблю плодить костыли в шаблонах, лучше вывести отдельную функцию или событие. В Laravel всё вообще довольно чисто, потому что маршрутные исключения и обработчик ошибок позволяют удобно перехватить 404 и отправить данные в очередь или напрямую в Telegram.

Но если нужно быстро и без разработки, я ставлю cron-скрипт, который каждые 5–10 минут парсит лог, группирует новые 404 и отправляет сводку в Telegram. Это хорошо работает на VPS под Ubuntu 22.04/24.04, PHP 8.1–8.3 и MySQL 8.0. Для небольших сайтов хватает даже MySQL 5.7, но если база старая и грязная, я бы уже подумал о модернизации. Кстати, если сайт стал тормозить или логика уведомлений тяжело грузит проект, иногда сначала нужна доработка под задачу, а потом уже мониторинг.

Пример PHP-скрипта для отправки 404 в Telegram

<?php

$botToken = '123456789:AAExampleTokenHere';
$chatId   = '-1001234567890';

function sendTelegramMessage(string $token, string $chatId, string $message): void
{
    $url = 'https://api.telegram.org/bot' . $token . '/sendMessage';

    $postFields = [
        'chat_id' => $chatId,
        'text' => $message,
        'parse_mode' => 'HTML',
        'disable_web_page_preview' => true,
    ];

    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_POST => true,
        CURLOPT_POSTFIELDS => http_build_query($postFields),
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT => 10,
    ]);

    $response = curl_exec($ch);
    curl_close($ch);

    if ($response === false) {
        error_log('Telegram send failed');
    }
}

$uri = $_SERVER['REQUEST_URI'] ?? '/';
$ip  = $_SERVER['REMOTE_ADDR'] ?? 'unknown';
$host = $_SERVER['HTTP_HOST'] ?? 'unknown';

$message = sprintf(
    "<b>404 на сайте</b>\nURL: %s\nHost: %s\nIP: %s\nTime: %s",
    htmlspecialchars($uri, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'),
    htmlspecialchars($host, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'),
    htmlspecialchars($ip, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'),
    date('Y-m-d H:i:s')
);

sendTelegramMessage($botToken, $chatId, $message);

Код выше — базовый. В бою я обязательно добавляю фильтры, чтобы не слать одно и то же по кругу. Например, сохраняю URL, IP и время последнего уведомления в Redis или в отдельную таблицу MySQL. Если у вас уже есть Redis, это вообще отличный вариант. Я часто подключаю его рядом с очередями задач и кешем, особенно на WordPress и Bitrix.

Пример Nginx для логирования 404 отдельно

server {
    listen 443 ssl http2;
    server_name example.ru www.example.ru;

    access_log /var/log/nginx/example.access.log main;
    error_log  /var/log/nginx/example.error.log warn;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    error_page 404 /404.html;

    location = /404.html {
        internal;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

В Nginx я люблю разделять access-логи по сайтам и потом уже вытаскивать 404 через grep, awk или отдельный парсер. Это проще обслуживать, чем пытаться лепить магию в одном огромном лог-файле. Если проект сложный, с CDN, reverse proxy и несколькими поддоменами, лучше сразу продумать схему логирования. Иначе потом всё это превращается в технический долг, который мешает не меньше, чем отсутствие мониторинга.

Как настроить Telegram-уведомления без лишнего шума

Telegram я выбираю почти всегда. Почта для таких задач — медленно, неудобно и часто теряется среди обычных писем. А push в браузере или на телефон — не всегда стабилен. Telegram же достаточно быстрый, бесплатный и легко интегрируется через Bot API.

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

Я обычно делаю два типа уведомлений: мгновенные и агрегированные. Мгновенные — для действительно важных страниц, например, если 404 получило больше 5 запросов за 10 минут или если URL из коммерческого раздела. Агрегированные — раз в час или раз в день, чтобы не засорять канал. Это особенно полезно, когда у проекта большая структура и трафик идёт из рекламы, поиска, email и социальных сетей.

Что должно быть в уведомлении

• адрес страницы, которая вернула 404;
• количество повторов за период;
• реферер, если он есть;
• тип устройства или user-agent;
• сайт, поддомен, дата и время;
• ссылка на админку или лог для быстрой проверки.

Если проект на WordPress, я часто добавляю уведомления в отдельный Telegram-чат для разработчиков и ещё один — для контент-менеджеров. Первым нужны технические детали, вторым — человеческий список страниц, которые надо восстановить или редиректнуть. На Bitrix иногда вообще удобно подключить это как часть Настройки кеширования в Битрикс: полное руководство, если сайт большой и нагрузка высокая.

Дедупликация, фильтры и правильная агрегация

Без дедупликации 404-мониторинг превращается в спам-машину. И это, честно говоря, самая частая ошибка у тех, кто впервые пытается всё автоматизировать. Они ловят каждый запрос, не группируют его и не ставят таймауты на повторные сообщения.

Я обычно применяю простое правило: один и тот же URL с одного и того же хоста не должен тревожить Telegram чаще, чем раз в 30–60 минут, если только он не стал резко массовым. Это нормальная граница, которая защищает от шума. Если URL сломанный, вы и так о нём узнаете. Если он новый и опасный — увидите рост количества обращений.

Ещё очень полезно разделять уведомления по шаблонам. Например, 404 по /favicon.ico, /apple-touch-icon.png и типовым ботным путям — в отдельный поток или в ежедневный отчёт. А вот 404 по /catalog/iphone-15-pro-max/ или /services/seo-audit/ — уже в быстрый алерт. Такой подход реально спасает, когда проект на проде и в логах постоянно мусорят сканеры.

Пример SQL-таблицы для хранения 404

CREATE TABLE site_404_log (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    url VARCHAR(1024) NOT NULL,
    host VARCHAR(255) NOT NULL,
    referer VARCHAR(1024) NULL,
    user_agent VARCHAR(1024) NULL,
    ip VARCHAR(45) NULL,
    hit_count INT UNSIGNED NOT NULL DEFAULT 1,
    first_seen DATETIME NOT NULL,
    last_seen DATETIME NOT NULL,
    notified_at DATETIME NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uniq_url_host (url(255), host)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Такую таблицу удобно использовать и для отчётов, и для Telegram-алертов, и для последующего анализа. Я часто держу её в MySQL 8.0, потому что там нормальная работа с индексами и JSON, если хочется дополнительно сохранять метаданные. На старом MySQL 5.7 тоже можно жить, но для новых проектов я уже почти не беру его всерьёз.

Как это обычно делаю на WordPress, Bitrix и Laravel

На WordPress я чаще всего ставлю небольшой mu-plugin, который перехватывает 404 и пишет их в таблицу. Если сайт на хорошем хостинге, можно ещё повесить cron и раз в 10 минут отправлять сводку в Telegram. Если проект большой, лучше сразу подключить отдельный сервис логирования или отправку в Sentry, а Telegram оставить как канал оповещения. Кстати, про ошибки в приложении полезно прочитать Как настроить Sentry для сайта и ловить ошибки в 2026 году.

В Bitrix я чаще работаю через события, агент или отдельный компонент логирования. Там важно не перегрузить сайт лишней логикой, потому что у клиентов нередко уже стоят композит, Redis, сложное кеширование и свои доработки. И если ещё сверху навесить тяжёлый мониторинг, можно получить тормоза. Поэтому я обычно делаю всё максимально тонко: записал факт 404, склеил повтор, отправил уведомление, вышел.

В Laravel схема чище всего: можно использовать middleware, кастомный handler и очередь. Если у вас уже работает Horizon или просто очереди через database/Redis, Telegram-уведомления лучше отправлять асинхронно. Это правильно. Иначе вы будете добавлять задержку на каждый 404-запрос, а это совсем не то, чего хочется от мониторинга.

Что проверить после настройки

После внедрения мониторинга я всегда делаю тестовый прогон. Открываю несколько заведомо несуществующих URL, проверяю, что они попадают в лог, что дедупликация работает, что Telegram получает корректное сообщение и что в уведомлении нет мусора вроде HTML-экранов или пустых полей. Если хоть один из этих пунктов провален, в бою всё быстро развалится.

Дальше я проверяю, не ловит ли система лишнее. Например, на одном проекте уведомления сыпались из-за служебного пути /wp-content/uploads/2024/01/preview.jpg, который генерировался внешним модулем и иногда запрашивался без файла. С точки зрения логики это был шум. Пришлось добавить исключение. Это нормальная история. Мониторинг почти никогда не настраивается идеально с первого раза.

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

Как связать 404-мониторинг с SEO и поддержкой сайта

Сам по себе 404-мониторинг — это только половина дела. Вторая половина начинается тогда, когда вы связываете его с SEO, контентом и регулярной поддержкой. Я обычно сразу смотрю: есть ли у URL внешний трафик, есть ли на него внутренние ссылки, есть ли он в sitemap, есть ли упоминания в рекламных кампаниях, письмах и документах. И только потом решаю — чинить контент, ставить 301 или удалять всё окончательно.

Если 404-страница получает трафик, а на сайте есть похожий или новый раздел, тогда почти всегда нужен редирект. Если URL мусорный и не имеет ценности, можно оставить 404 или отдать 410. Но это уже зависит от структуры проекта. Для SEO это не мелочь. Особенно если речь о крупном каталоге, новостном сайте или сервисе с сотнями тысяч URL. Про общую структуру ошибок и их влияние на SEO у меня есть ещё материал Как настроить страницы 403, 404, 410 и 500 для SEO в 2026.

На деле 404-мониторинг — это часть нормальной технической поддержки. Он помогает не только «ловить ошибки», но и быстро реагировать после релизов, миграций, обновления CMS и правок шаблонов. Если подходить к этому системно, то сайт становится заметно спокойнее. Меньше хаоса, меньше сюрпризов, меньше срочных ночных сообщений в стиле «у нас всё сломалось». И вот за это, честно говоря, я такие настройки люблю.

Если вам нужно не просто «поставить уведомления», а собрать рабочую систему мониторинга, логирования и уведомлений под WordPress, Bitrix или Laravel, я бы не тянул. Сначала делается база, потом на неё уже навешиваются алерты, отчёты и автоматические действия. И если задача выходит за рамки стандартной установки, это уже полноценная доработка сайта под бизнес-процесс.