Не приходят заявки с формы на сайте: восемь мест, где они теряются

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

Почему это вообще происходит незаметно

У формы обратной связи есть неприятное свойство: она сообщает об успехе посетителю, а не вам. Человек нажал кнопку, увидел «спасибо, мы свяжемся» и ушёл довольный. Запись в базу легла. А вот дошло ли уведомление до живого человека — не проверяет никто и никогда.

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

1. Письмо уходит, но попадает в спам

Самое частое. Сайт отправляет письмо от адреса вида noreply@вашдомен.ру, а у домена не настроены записи SPF, DKIM и DMARC. Почтовый сервер получателя видит письмо, которое утверждает, что оно от вашего домена, но подтвердить это не может — и кладёт в спам или отбрасывает совсем.

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

2. Хостинг закрыл исходящий SMTP

Массовая история последних лет: хостинг-провайдеры закрывают 25-й и 587-й порты, чтобы с их серверов не рассылали спам. Сайт при этом не падает — он честно пытается отправить письмо, получает отказ соединения и пишет ошибку в лог, который никто не читает.

У нас так было на проекте производителя: письма не уходили в принципе, хостер закрыл SMTP со всех машин. Починка — не «настроить почту», а сменить транспорт: отправлять уведомления через HTTP-API почтового сервиса или вообще в мессенджер, минуя SMTP.

Как проверить: с сервера сайта попробуйте открыть соединение с почтовым сервером. Если порт закрыт — вы нашли причину, и никакие настройки в админке не помогут.

3. Уведомления просто выключены

Звучит глупо, но это наш собственный случай. В CMS или в настройках плагина формы есть галочка «отправлять уведомление на почту», и она снята — после переезда, обновления или чужой правки. Форма работает, база наполняется, никто ничего не получает.

Как проверить: зайдите в настройки формы и найдите, куда именно она шлёт. Убедитесь, что адрес правильный и что он не остался от прошлого администратора.

4. Адрес есть, но его никто не читает

Уведомления идут на info@, который заводили при запуске и с тех пор не открывали. Или на почту сотрудника, который уволился. Или в общий ящик, где двенадцать тысяч непрочитанных и заявка тонет между рассылками.

Признак: заявки «приходят», но менеджер о них узнаёт из отчёта, а не из уведомления. Лечится не технически: уведомление должно приходить туда, куда человек смотрит по десять раз в день, — обычно это мессенджер на телефоне, а не почта.

5. Мессенджер, который не у всех открывается

С апреля 2026 года Telegram в России ограничен, и ссылка вида t.me/... открывается далеко не у каждого посетителя. Мы замеряли доступность прямого маршрута к серверам мессенджера из российских сетей: DNS часто не отвечает вовсе, а из тринадцати адресов живым оказывался один, и тот не с первой попытки.

Что это значит для сайта: если единственная кнопка связи ведёт в Telegram, часть посетителей нажимает её и не попадает никуда. Заявка не теряется по дороге — она просто не создаётся, и в статистике этого не видно.

Решение простое: рядом с любой кнопкой мессенджера должны стоять телефон и WhatsApp, а уведомления администратору дублироваться минимум по двум каналам.

6. Уведомление уходит, но сайт ждёт его синхронно

Отдельный неприятный случай, который выглядит не как потеря заявки, а как «сайт тормозит». Форма при отправке синхронно дёргает внешний API — мессенджер, CRM, почтовый сервис. Пока сервис отвечает, посетитель смотрит на крутящийся индикатор.

На одном из наших проектов оформление заказа занимало 46 секунд: сайт пытался достучаться до мессенджера, упирался в таймауты и повторные попытки. После того как отправку вынесли в фон, оформление стало занимать 0,42 секунды. Сколько человек ушло за те 46 секунд, посчитать уже нельзя.

Правило: любое обращение к внешнему сервису при отправке формы должно быть асинхронным и с коротким таймаутом. Посетитель не должен ждать вашу интеграцию.

7. Валидация тихо отбрасывает заявку

Поле телефона требует строгий формат, посетитель вводит номер с другими скобками, форма подсвечивает ошибку где-то ниже видимой области экрана. Человек считает, что отправил, и уходит. На мобильном это происходит чаще всего.

Сюда же — капча, которая не грузится на медленном соединении, и «защита от спама», которая режет заявки с реальными адресами. Мы ловили фильтр, отбрасывавший сообщения со словами «график» и «занятость»: он был написан против спама, а выбрасывал людей, спрашивавших про сроки.

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

8. Заявка дошла, но легла не туда

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

Общее правило для любой автоматики: после записи перечитайте объект и убедитесь, что данные там. Своему счётчику верить нельзя, верить можно только тому, что вернул источник.

Как проверить всю цепочку за десять минут

1. Откройте свой сайт как обычный посетитель, лучше с телефона и не из офисного Wi-Fi.
2. Заполните форму настоящими данными и отправьте.
3. Засеките, сколько секунд заняла отправка. Больше трёх — уже проблема.
4. Проверьте почту, куда должно прийти уведомление. Обязательно загляните в «Спам».
5. Проверьте мессенджер и CRM, если они подключены.
6. Проверьте, легла ли заявка в базу или админку сайта.
7. Повторите то же самое для каждой формы: на главной, в подвале, во всплывающем окне, на странице контактов. Ломается обычно одна из них, а проверяют всегда главную.

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

Чтобы не повторилось

Поставьте сторожа. Раз в сутки скрипт отправляет тестовую заявку через настоящую форму и проверяет, что она дошла до конца цепочки. Не «проверяет настройки» — а именно проходит весь путь, как человек. Не дошла — вам приходит сообщение.

Дублируйте канал. Уведомление должно уходить минимум в два места: то, куда вы смотрите постоянно, и то, что хранит историю. Один канал — одна точка отказа.

Проверяйте после каждого обновления. Обновление CMS, смена хостинга, установка плагина, переезд домена — четыре события, после которых уведомления ломаются чаще всего.

Смотрите на цифры, а не на ощущения. Если в аналитике видно посещения, а заявок нет неделю — это не «сезон». Это повод пройти чек-лист выше.

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