Мониторинг сайта: почему HTTP 200 не гарантирует приём заявок

Что вы получите из статьи:

• почему зелёный статус мониторинга (код 200) говорит только «страница открылась», со ссылками на MDN и стандарт HTTP RFC 9110
• карту из 6 звеньев заявки от кнопки до CRM и что может сломаться на каждом без единой ошибки на экране
• что проверить в Битрикс и Аспро - очередь почтовых событий, агенты и адрес получателя
• почему письмо с заявкой уходит в спам - SPF, DKIM и требования Gmail с 1 февраля 2024 года
• тестовую заявку по шагам, которую можно пройти самому, и что из этого видит кабинет ARTGK Code

Из практики: применить можно за около 30 минут (ориентир для первичной проверки, фактическое время зависит от почты и CRM), экономит недели тишины, пока заявки молча теряются.

Мониторинг сайта раз в 5 минут открывает страницу и получает код 200. По описанию MDN и по стандарту HTTP (RFC 9110, раздел 15.3.1) это значит одно: конкретный запрос выполнен. Заявка после этого проходит ещё шесть звеньев, и каждое может сломаться без ошибки на экране. Капча отклоняет токен старше 2 минут (reCAPTCHA) или 300 секунд (Turnstile). Форма на Битрикс может поставить письмо в очередь вместо немедленной отправки. Gmail с 1 февраля 2024 года требует SPF или DKIM от всех отправителей. А цель «Отправка формы» в Метрике по умолчанию может засчитаться и при неудачной отправке. Ниже - где это искать и как проверить форму по шагам без программиста.

До цепочки из шести звеньев стоит сам сайт: открывается ли он и как быстро отвечает. Это видно в кабинете ARTGK Code: первые 30 дней тарифа «Бизнес» без оплаты. Путь заявки после открытия страницы проверяют отдельно; ниже разбираем шесть звеньев.

Что на самом деле означает код 200 в мониторинге?

Код 200 означает, что сервер выполнил именно этот запрос. По описанию MDN, код 200 значит, что запрос выполнен, а сам ответ по умолчанию может кэшироваться. Для запроса GET это значит, что страницу отдали, для запроса POST - что действие выполнено. Про форму, письмо и менеджера код не говорит ничего.

Стандарт HTTP (RFC 9110, разделы 15.3 и 15.3.1) формулирует так же: класс ответов 2xx означает, что запрос клиента получен, понят и принят. Речь о запросе, а не о бизнесе. Содержимое ответа 200 зависит от метода запроса, и сервер не обязан сообщать, чем всё закончилось дальше.

Google идёт дальше. В справке для поиска сказано: код 2xx не гарантирует индексацию. Страницу с пустым содержимым или текстом ошибки при коде 200 Search Console может пометить как «soft 404». Для Google «200» и «всё в порядке» - разные вещи, и для вашего мониторинга тоже. Страница с надписью «Что-то пошло не так» и кодом 200 в отчёте выглядит зелёной.

Почему мониторинг доступности не замечает сломанную форму?

Мониторинг делает запрос GET к одной странице. Заявка уходит отдельным запросом POST на другой адрес и дальше превращается в письмо и запись в CRM. Робот мониторинга не нажимает кнопку, не заполняет поля и не заглядывает в почту, поэтому форма может быть мертва месяц при стабильных 100 % «аптайма».

Что именно проверяет пинг и как настроить его правильно, мы разбирали в статье про мониторинг доступности сайта. Здесь о том, что остаётся за его границей. Иногда предлагают научить робота отправлять тестовую заявку каждые несколько минут. У такой идеи три минуса: тестовые заявки засоряют CRM, ломают статистику и упираются в капчу, которая создана именно для того, чтобы робот форму не отправил.

Поэтому наша позиция такая: регулярная тестовая заявка руками по чек-листу, цель Метрики, которая срабатывает после успешного ответа сервера, и сверка числа целей с числом писем и лидов. Дальше по порядку, звено за звеном.

Где теряется заявка между кнопкой и менеджером?

Между кнопкой «Отправить» и менеджером шесть звеньев: скрипт формы, капча, обработчик на сайте, почтовый сервер, ящик получателя и CRM. Ломаться может любое. При сбоях в некоторых звеньях клиент может видеть сообщение об успехе, хотя заявка до менеджера не дошла. Таблица ниже показывает возможные сбои: что может увидеть клиент, что видите вы и чем проверить каждое звено. Реализации форм у сайтов разные, поэтому поведение конкретной формы проверяйте тестом.

Ни одно звено в таблице не обязано само предупреждать владельца сайта о сбое. Такие вопросы владельцы сайтов задают на Хабр Q&A годами. Там спрашивают, почему часть писем с сайта на Битриксе теряется и почему результат формы сохраняется, а почтовое событие не создаётся.

Посмотреть, как выглядит история проверок доступности, можно в демо-кабинете ARTGK Code без регистрации. В блоке «Требует внимания» на обзоре демо есть пример обращения «Не работает форма обратной связи» - так выглядит задача, которую владелец поручает инженерам.

Как скрипт и кэш ломают форму без единой ошибки на экране?

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

Форма в Аспро построена на инфоблоках, и правка полей идёт через админку, а не через код. Изменили поле, забыли сбросить кэш - часть посетителей видит старую форму, часть новую. Мониторинг при этом получает один и тот же код 200.

Вторая типовая причина - замена кнопки отправки. По MDN, кнопка внутри формы без атрибута type отправляет данные по умолчанию. Если верстальщик поменял её на кнопку с type="button" и повесил отправку на скрипт, а скрипт упал на другой странице, форма молчит. Метрика предупреждает: при такой кнопке цель «Отправка формы» достигаться не будет. Число целей упадёт сразу после замены кнопки, даже если форма работает. Поэтому падение целей - повод для тестовой заявки, но поломку оно не доказывает.

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

Может ли капча отсекать живых клиентов?

Да, может. reCAPTCHA v3 не показывает картинок и ставит посетителю оценку от 0,0 до 1,0. Порог по умолчанию в документации Google - 0,5. Всё, что ниже, сайт вправе молча отбросить, а человек об этом не узнает. Мониторинг этого не увидит: он открывает страницу и форму не отправляет.

Второй сценарий - просроченный токен. Токен reCAPTCHA живёт 2 минуты и проверяется один раз, токен Cloudflare Turnstile действует 300 секунд (5 минут) и тоже проверяется один раз. Клиент, который заполнял длинную анкету 6 минут, может получить отказ, если сайт не запрашивает токен заново перед отправкой. Это следствие из документации, а не статистика: проверьте на своей форме.

В Аспро с обновлений «Оптимус» 1.7.17 и «Маркет» 1.8.10 появилась ещё одна защита от спама и ботов - Яндекс SmartCaptcha. Ей нужны ключи клиента и сервера из Yandex Cloud. Сменился аккаунт или ключи - форма может перестать проходить проверку. Поэтому в чек-листе ниже есть пункт «подождать 3 минуты перед отправкой» и пункт про проверку с мобильного телефона.

Почему письмо с заявкой попадает в спам или не доходит?

Сайт отправляет уведомление о заявке от имени вашего домена. SPF и DKIM - записи в настройках домена, по которым почта получателя проверяет, что письмо отправлено с разрешения владельца домена. Если их нет, почта вправе счесть письмо подделкой. Gmail с 1 февраля 2024 года требует настроить SPF или DKIM от всех отправителей, и письма без аутентификации рискуют попасть в спам или быть отклонёнными.

У отправителей, которые шлют больше 5 000 писем в день на адреса Gmail, требования строже: нужны SPF, DKIM и DMARC вместе. Среди правил Google для всех отправителей: SPF или DKIM на домене и доля жалоб на спам ниже 0,3 % по данным Postmaster Tools. Google рекомендует для DKIM ключ 2048 бит. Чтобы DMARC прошёл, нужен успешный SPF или DKIM и согласование проверенного домена с доменом в поле «От кого». В строгом режиме домены совпадают полностью, в relaxed может совпадать их организационный домен (стандарт RFC 9989, заменивший RFC 7489). Результат DMARC не гарантирует доставку письма.

Отдельная ловушка SPF - лимит записей. По стандарту RFC 7208 в SPF допускается не больше 10 подзапросов к DNS (include, a, mx и подобные). Каждый сервис рассылки добавляет один или несколько таких подзапросов. Стало их больше 10 - и вся проверка превращается в ошибку permerror. Справка Mail.ru советует убедиться, что количество таких директив не превышает 10.

Проверить результат несложно. Временно добавьте ящик на Mail.ru в поле «Скрытая копия» почтового шаблона (письмо уходит на адрес из шаблона, а не из формы), отправьте тестовую заявку, откройте письмо в браузере, выберите «Служебные заголовки» и найдите строку Authentication-Results: в ней указаны результаты проверок spf, dkim и dmarc. По словам справки Mail.ru, «SPF-запись защищает от подделки вашего домена и позволяет предотвратить попадание в спам писем, отправленных с ваших адресов».

Что проверить в Битрикс и Аспро: очередь писем, агенты и адрес получателя?

Три вещи: очередь почтовых событий, запуск агентов и адрес, на который пишет шаблон письма. Форма может поставить письмо в очередь вместо немедленной отправки. Для стандартного метода CEvent::Send документация 1С-Битрикс говорит так: «Метод создает почтовое событие которое будет в дальнейшем отправлено в качестве E-Mail сообщения». Форма показала «Спасибо», а письмо может стоять в очереди.

Очередь разбирают агенты, а с версии 20.5.0 главного модуля - фоновые задания. У агентов своя особенность. Документация 1С-Битрикс поясняет, что агент запускается, когда кто-то заходит на страницу сайта, поэтому точность запуска зависит от посещаемости. Для запуска по расписанию 1С-Битрикс предлагает стандартную утилиту cron. Возможный сценарий: очередь писем переведена на cron, после переезда хостинга cron не настроили. Письма копятся, сайт отвечает 200.

Третий пункт самый неприятный. В документации Аспро: «По умолчанию почтовые уведомления с веб-форм приходят администратору сайта на email, указанный при создании сайта». Если сайт делал подрядчик, заявки могут годами уходить на его ящик. Откройте «Настройки - Настройки продукта - Почтовые события - Почтовые шаблоны» и проверьте поля «Кому», «Копия» и «Скрытая копия».

Типичный вопрос на Хабр Q&A звучит так: с одной формы на разных страницах часть писем приходит, а часть нет. Тестируйте форму на каждой странице, где она стоит, а не только на главной: у страниц могут быть разные шаблоны и разный кэш.

Если вы не нашли нужных разделов в админке, это нормально для владельца бизнеса. Такой вопрос можно поручить специалисту целиком, ниже о том, как это делается из кабинета.

Почему заявка пришла на почту, но не появилась в CRM?

Почта и CRM - разные дороги, и интеграция с Битрикс24 может сломаться при работающей почте. В облачном Битрикс24, по документации REST API, один запрос должен выполниться не дольше чем за 60 секунд, иначе он прерывается по таймауту. При превышении лимита запросов следующий блокируется со статусом 503 и кодом QUERY_LIMIT_EXCEEDED.

Для сайта это выглядит так: клиент получил «Спасибо», менеджер получил письмо, а карточки лида в CRM нет. На Хабр Q&A есть вопрос именно об этом: письмо приходит, а лид в Битрикс24 не создаётся. В другой ветке автор пишет, что из формы примерно в одном проценте отправок приходят пустые сделки без контакта. Это слова одного пользователя, а не общая статистика, но симптом знаком: CRM и почта расходятся.

Проверка простая. Для тестовой заявки найдите карточку в CRM и сверьте поля: имя, телефон, источник. Если лида нет, а письмо есть, ищите проблему в интеграции, а не в почте.

Как проверить форму заявки самому: тест по шагам?

Первичная проверка по этому плану занимает примерно полчаса (ориентир, мы время не замеряли) и не требует программиста. Идти нужно строго от клиента к менеджеру: сначала так, как заявку отправит посетитель, потом по каждому звену цепочки. Предупредите менеджеров, что придёт заявка с пометкой «ТЕСТ», чтобы её не обработали как настоящую.

1. Выключите Wi-Fi и откройте страницу с формой в режиме инкогнито с телефона по мобильному интернету. Это другая сеть, чистый кэш и никакой авторизации в админке.
2. Если в Метрике включена опция «Не учитывать мои визиты», по инструкции Метрики выполняйте проверку целей в приватном режиме браузера.
3. Добавьте к адресу страницы параметр _ym_debug=2 и загрузите страницу: так Метрика покажет в консоли, какие цели срабатывают.
4. Заполните форму как клиент, включая галочку согласия, и подождите 3 минуты перед отправкой. Так вы проверите, принимает ли форма заявку после истечения токена reCAPTCHA (он живёт 2 минуты). Если на сайте Cloudflare Turnstile, ждите 6 минут: его токен живёт 5.
5. Нажмите «Отправить» и запишите время. Должно появиться сообщение об успехе, а не пустая страница.
6. Проверьте ящик получателя и папку «Спам». Запишите, через сколько минут пришло письмо.
7. Откройте копию письма в ящике Mail.ru (его временно добавляют в «Скрытую копию» шаблона, после теста убирают) и посмотрите Authentication-Results: spf, dkim и dmarc должны проходить проверку.
8. Попросите админа сайта проверить, что по вашей заявке создано почтовое событие и оно помечено отправленным (хранится в таблице b_event).
9. Найдите лид в CRM и сверьте поля.
10. Через несколько минут проверьте, что цель в Метрике зафиксировалась ровно один раз.

Для тестовой заявки заполните поля так, чтобы её сразу узнавали:

• Имя: ТЕСТ, не обрабатывать
• Телефон: ваш номер
• Email: ваш тестовый ящик
• Сообщение: проверка формы, дата и время отправки

Можно ли считать заявки по целям Яндекс Метрики?

Как сигнал - да, как доказательство - нет. По справке Метрики, «по умолчанию цель считается достигнутой не только при успешной отправке формы, но и при безуспешной попытке ее отправить, например, когда данные из формы не прошли валидацию». Рост целей не доказывает, что заявки доходят.

Справка называет и другие ограничения. Если отправка реализована через кнопку button type="button", цель достигаться не будет. Если форма обрабатывается скриптом, цель работает только для стандартного события onSubmit. И ещё одно: «Любые изменения в HTML-верстке вашего сайта могут привести к некорректной работе цели».

Надёжнее передавать цель методом reachGoal из обработчика, который срабатывает после успешного ответа сервера. Попросите об этом программиста: это небольшая правка. А пока её нет, раз в неделю сверяйте три числа: цели в Метрике, письма в ящике и лиды в CRM. Расхождение больше пары заявок - повод запустить тест из предыдущего раздела.

Метрика фиксирует одну и ту же цель на счётчике не чаще, чем раз в секунду, а за один визит - до 400 онлайн-целей, и это стоит помнить при чтении отчётов.

Что вы увидите в кабинете ARTGK Code и чего он не проверяет?

Кабинет раз в 5 минут проверяет, открывается ли сайт, показывает код и время ответа, раз в час смотрит срок HTTPS-сертификата и хранит историю. Отправку формы, почту и CRM он не проверяет. Письма о сбоях, по FAQ на странице для компаний, сейчас не отправляются: статус смотрят в кабинете.

В демо-кабинете на примерных данных раздел «Мониторинг» выглядит так:

• Статус и доступность. Сайт «Работает», за 30 дней он работал 99,93 %. Каждая плашка в полосе - один день.
• Время ответа. Среднее за сутки в демо - 1147 мс, есть график по дням.
• Последние проверки. Список строк вида «02.11, 08:35 - 200 - 1092 мс». Именно так выглядит код 200 в истории: страница открылась, о форме тут ничего нет.
• Сертификат HTTPS. В демо осталось 13 дней, до 15.11.2026. Для истёкшего сертификата у нас есть отдельная статья про SSL.
• Настройки. Проверку можно выключить на время работ на сайте, чтобы не было ложных тревог.
• Обращения. В блоке «Требует внимания» на обзоре в демо стоит обращение «Не работает форма обратной связи» со статусом «в работе у команды». Если тестовая заявка не дошла, такую задачу можно завести в кабинете: по описанию на сайте специалист согласует смету, а вы подтверждаете.

Кроме мониторинга, проверка в кабинете смотрит SEO, видимость в AI-поиске и юридические риски. Как читать её отчёт, разобрано в статье про бесплатную проверку сайта. По публичной странице, первые 30 дней тарифа «Бизнес» идут без оплаты, а для начала нужен только email.

Как часто проверять форму и после каких изменений?

Тестовую заявку нужно проходить после каждого изменения, которое может задеть форму, и по расписанию. К таким изменениям относятся обновление Битрикса или Аспро, правка шаблона или самой формы, смена почты, DNS, хостинга, капчи или CRM. Метрика сама оговаривает, что правки вёрстки могут сломать цель.

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

Если ваша форма требует отметить согласие, проверьте доступность этой галочки на телефоне: скрытая или не нажимающаяся галочка может блокировать отправку. Это пункт проверки, а не статистика. Требования к согласию и основание обработки данных проверяются отдельно, а галочка сама по себе не подтверждает соблюдение закона. Что ещё требует закон от формы, смотрите в статье про 152-ФЗ.

Частые вопросы о проверке формы заявок

Проверяет ли мониторинг форму автоматически? Обычный мониторинг доступности - нет: он открывает страницу и проверяет код ответа. Кабинет ARTGK Code так же проверяет доступность, время ответа и сертификат, а отправку формы не проверяет. Форму тестируют руками по шагам выше.

Нужен ли программист для тестовой заявки? Шаги 1-6 и 10 проходятся с браузером, телефоном и доступом к почте. Скрытую копию в шаблоне письма (шаг 7), очередь писем в Битрикс и интеграцию с CRM настраивает и смотрит админ сайта или специалист.

Что делать, если тестовая заявка ушла в спам? Откройте заголовки письма и посмотрите spf, dkim и dmarc. Если проверки не проходят, настройте SPF и DKIM для домена отправителя и убедитесь, что в SPF не больше 10 DNS-подзапросов.

Может ли галочка согласия блокировать отправку? Да, если она скрыта, перекрыта другим элементом или не нажимается на телефоне. Проверьте её на мобильном: статистики по такому сбою у нас нет, это пункт чек-листа.

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

Источники

• Код ответа 200 OK в справочнике MDN - developer.mozilla.org
• Элемент button в справочнике MDN - developer.mozilla.org
• RFC 9110, HTTP Semantics, разделы 15.3 и 15.3.1 - rfc-editor.org
• Google Search Central, коды ответа HTTP и soft 404 - developers.google.com
• Цель «Отправка формы» в справке Яндекс Метрики - yandex.ru
• Как проверить достижение целей, справка Метрики - yandex.ru
• Целевое событие JavaScript, справка Метрики - yandex.ru
• Проверка токена в документации reCAPTCHA - developers.google.com
• Google reCAPTCHA v3 - developers.google.com
• Cloudflare Turnstile, серверная проверка - developers.cloudflare.com
• Google, требования к отправителям почты - support.google.com
• Стандарт DMARC RFC 9989 (согласование доменов, relaxed и strict) - rfc-editor.org
• RFC 7208, SPF - rfc-editor.org
• Mail.ru Постмастер, SPF - help.mail.ru
• Проверка отправителя в справке Mail.ru Постмастер - help.mail.ru
• 1С-Битрикс, метод CEvent::Send - dev.1c-bitrix.ru
• 1С-Битрикс, агенты - dev.1c-bitrix.ru
• 1С-Битрикс, запуск агентов из cron - dev.1c-bitrix.ru
• Аспро, почтовые уведомления с веб-форм - aspro.ru
• Формы обратной связи в документации Аспро - aspro.ru
• Аспро, Яндекс SmartCaptcha - aspro.ru
• Битрикс24 REST, ограничения - apidocs.bitrix24.ru
• Хабр Q&A, неполная доставка писем с сайта на Битриксе - qna.habr.com
• Хабр Q&A, почтовое событие не создаётся после заполнения веб-формы - qna.habr.com
• Хабр Q&A, письмо приходит, а лид в Битрикс24 нет - qna.habr.com
• Хабр Q&A, пустые сделки после заполнения формы - qna.habr.com

Тестовая заявка не дошла, и причина не находится? Заведите обращение в кабинете ARTGK Code: специалист посмотрит форму и согласует смету, а работа начнётся после вашего подтверждения.