Не приходят заявки с сайта на почту: как проверить форму и доставку
Если не приходят письма с сайта, сначала выясните, сохранилось ли само обращение. Заявка в CRM без уведомления и форма, которая ничего не записала, требуют разных действий. В первом случае менеджер может продолжить работу с клиентом. Во втором нужно остановить потерю новых обращений и проверить, остались ли данные для восстановления.
Надпись «Спасибо, сообщение отправлено» подтверждает только тот этап, с которым разработчик связал этот ответ. Она не доказывает, что письмо оказалось во входящих. Ниже — последовательная диагностика: от кнопки и обработчика до очереди, почтового сервера и ящика получателя, с отдельными проверками для WordPress, Contact Form 7 и 1С-Битрикс.
Что делать, если перестали приходить заявки
Зафиксируйте время последнего подтверждённого обращения и первого обнаруженного сбоя. Укажите часовой пояс: журналы сайта, CRM и почтового сервиса могут показывать разное время. Затем определите масштаб: перестала работать одна форма, все формы, только вложения, отдельный адрес получателя или конкретная языковая версия сайта.
- Откройте хранилище обращений. Проверьте CRM, результаты формы в CMS и подключённый модуль сохранения. Найденные заявки передайте ответственному сотруднику через принятый рабочий процесс.
- Проверьте действующий адрес отдела продаж. Ошибка в получателе, удалённый ящик или изменённый псевдоним могут объяснить отсутствие уведомлений без поломки формы.
- Обеспечьте доступный способ связи. Если приём действительно нарушен, разместите рядом с формой актуальный телефон или другой проверенный канал.
- Сохраните диагностические следы. Не очищайте очереди и журналы до определения проблемного периода и конкретных заявок.
Составьте список недавних изменений: перенос хостинга, обновление CMS, правка формы, смена пароля почты, подключение защиты, изменение получателей. Совпадение по времени помогает выбрать проверку, но само по себе не доказывает причину. Владелец бизнеса должен получить два ответа: принимаются ли новые обращения сейчас и кто обрабатывает заявки за период сбоя.
Как отличить потерю заявки от потери уведомления
Рекомендуемая схема приёма выглядит так: браузер передаёт данные, сервер проверяет их, обращение сохраняется, создаётся задание уведомления, письмо передаётся почтовому сервису, принимается сервером адресата и обрабатывается его правилами. Конкретная форма может объединять этапы или вообще не иметь хранилища. Поэтому сначала нарисуйте фактический маршрут вашего сайта.
Ищите последний подтверждённый шаг для одной заявки. Нельзя сопоставлять успешную отправку тестового письма из панели с другим обращением, которое посетитель оставил на посадочной странице.
| Что наблюдаете | Что это подтверждает | Следующая проверка |
|---|---|---|
| Кнопка нажата, запроса нет | Данные ещё не ушли из браузера | Валидация, ошибки JavaScript, подключение обработчика |
| Запрос получил HTTP 200 | Получен успешный HTTP-ответ | Содержимое ответа, статус операции, идентификатор заявки |
| Есть запись в CMS или CRM | Обращение сохранено в проверенном хранилище | Правило уведомления и создание задания |
| Есть задание в очереди | Уведомление запланировано | Возраст задания, обработчик очереди, результат попытки |
| Почтовый сервис принял сообщение | Сообщение передано этому сервису | Дальнейшая доставка, задержка или возврат |
| Сервер адресата принял письмо | Пройден следующий почтовый этап | Папки, карантин, правила и маршрутизация ящика |
| Письмо найдено менеджером | Уведомление доступно сотруднику | Наличие заявки в работе и отсутствие дубликатов |
По описанию HTTP-статусов MDN, смысл ответа 200 зависит от метода запроса; для POST тело ответа описывает результат действия. Практический вывод: HTTP 200 не является самостоятельным доказательством сохранения лида или доставки письма. Проверяйте смысл ответа приложения и запись на сервере.
Как провести проверку, которую можно проследить
Согласуйте проверку с ответственным сотрудником и используйте собственные тестовые контакты. Каждой попытке присвойте уникальную метку, например FORM-CHECK-20261031-01. Это учебный пример идентификатора: он не содержит телефон, адрес клиента или содержимое обращения. Метку удобно искать в записи, теме уведомления и технических событиях, если система поддерживает такую связь.
Начните с минимального допустимого заполнения без вложения. Укажите страницу, форму, браузер, время, метку и ожидаемый результат. Затем отдельно проверьте вариант, на котором возникает проблема: загрузку файла, мобильную форму, другой филиал или выбор услуги. Меняйте один фактор за попытку — иначе трудно понять, какое условие повлияло на результат.
На тестовом окружении отключите реальные коммерческие действия и направьте уведомления в согласованный тестовый ящик. Проверку рабочего сайта проводите с явной пометкой для менеджеров: тест не должен создавать оплачиваемый заказ или запускать рассылку клиентам. Не используйте случайные чужие адреса. После каждой попытки сначала найдите её результат, затем решайте, нужна ли следующая.
Учебный пример: уведомление застряло до почтового сервиса
Предположим, после переноса сайта менеджер перестал получать письма. Контрольное обращение с условной меткой TEST-042 получило ответ HTTP 200, а в хранилище появилась запись с заполненными контактами. Задание уведомления создано, но у него нет ни одной завершённой попытки. В журнале почтового провайдера этой метки нет.
Такой набор признаков направляет проверку к обработчику очереди. Допустим, в журнале планировщика обнаружена ошибка «файл не найден»: после переноса изменился путь запуска. Специалист сверяет конфигурацию с новым окружением, исправляет путь и проверяет одну ожидающую задачу. Затем сопоставляет идентификатор сообщения у провайдера с письмом в тестовом ящике.
В этом условном сценарии обращения сохранились, а уведомления задержались. Менеджер может обработать записи, пока техническая команда разбирает очередь. Перед повтором остальных уведомлений нужно учесть уже обработанные заявки, чтобы сотрудники не связались с клиентами дважды. Если бы запись TEST-042 отсутствовала, проверка начиналась бы раньше — с обработчика формы и сохранения, а настройка планировщика не закрывала бы проблему.
Браузер показывает успех, а сервер не получил обращение
Проверьте запрос и ответ
В инструментах разработчика откройте вкладку Network, выполните одну контрольную отправку и найдите запрос формы. Проверьте URL обработчика, метод, код ответа и структуру возвращённых данных. При редиректе убедитесь, что запрос попал в нужное приложение. HTML страницы авторизации или ошибки внутри ответа нельзя принимать за подтверждение приёма.
Если запрос отсутствует, начните с обязательных полей, сообщения валидации и ошибок консоли. Если сервер отвечает отказом, проверьте его журнал и события защитного сервиса по времени. CAPTCHA, ограничение частоты или проверка сессии могут остановить обращение до почтового этапа. Устранение такого отказа требует проверки конкретного правила, а не отключения всей защиты сайта.
Сверьте поведение интерфейса с обработчиком
Разработчик должен установить, после какого события появляется благодарность: после клика, любого ответа, сохранения записи или постановки уведомления в очередь. При ошибке сохранения интерфейс должен дать понятный результат и возможность исправить ввод. Если соединение оборвалось после сохранения, повторная отправка может создать дубликат: сначала проверьте идентификатор операции и журнал.
Экспорт запросов браузера может содержать cookie, токены и введённые данные. Перед передачей подрядчику удалите секреты и персональные поля либо воспроизведите сбой на учебном обращении. Для первичной диагностики обычно достаточно времени, URL, статуса, технической ошибки и метки.
Проверьте сохранение обращения отдельно от отправки письма
Спросите разработчика, какое хранилище считается основным: таблица заявок, результат веб-формы, карточка CRM или внешний сервис. Затем найдите конкретную запись по метке и времени. Одного счётчика целей в аналитике недостаточно: событие могло сработать при нажатии кнопки, а блокировщик — помешать учёту успешно сохранённой заявки.
При интеграции с CRM проверьте результат запроса к ней, идентификатор созданной или обновлённой карточки, сопоставление полей и выбранную воронку. Обращение может оказаться у другого ответственного, объединиться с существующим контактом или не пройти обязательное поле. Отсутствие новой карточки ещё не доказывает потерю: учитывайте правила обработки повторных обращений вашей CRM.
Для устойчивой схемы полезно сначала надёжно сохранить обращение и его идентификатор, затем выполнять уведомление с контролируемыми повторами. Если CRM временно недоступна, локально сохранённая заявка позволяет отложить передачу. Такое поведение нужно явно спроектировать и проверить: наличие CMS или подключённой интеграции не означает, что резервное сохранение уже работает.
Contact Form 7 не отправляет письма: что проверять в WordPress
Разделите отказ формы и результат почтовой функции
В официальном FAQ Contact Form 7 различаются ошибка отправки и подозрение на спам. При стандартном оформлении им соответствуют красная и оранжевая рамки. Тема или CSS могут изменить цвета, поэтому ориентируйтесь также на текст, статус ответа и серверную диагностику.
Если Contact Form 7 не отправляет письма только для некоторых заполнений, сравните результаты валидации, антиспама и наличие вложений. Успешный ответ формы тоже не завершает расследование: документация CF7 рекомендует смотреть почтовые журналы, когда форма сообщает об успехе, но письма нет.
В WordPress результат wp_mail() === true означает, что используемый способ отправки обработал запрос без ошибки, а не что получатель увидел сообщение. Это прямо оговорено в документации wp_mail(). Разработчик проверяет фактический транспорт, результат вызова и ошибки, учитывая влияние почтовых плагинов и обработчиков. Устанавливать одновременно несколько средств отправки ради проверки не следует: сначала определите, какое из них управляет почтой сейчас.
Проверьте шаблон и сохранение
Во вкладке Mail сверьте получателя, отправителя, подстановки полей, тему и вложения. После переименования поля его старый тег может остаться в шаблоне. Дополнительный шаблон Mail (2), часто используемый для автоответа, отправляется после успешной отправки основного Mail на уровне плагина; это правило описано в настройках почты CF7. Автоответ не доказывает чтение менеджером основного уведомления.
Сам Contact Form 7 не сохраняет отправленные сообщения. Для хранения нужно отдельно настроенное решение, например Flamingo. В инструкции по Flamingo также предусмотрен параметр do_not_store, отключающий запись для формы. Проверьте фактическую запись контрольной заявки. Установка хранилища после инцидента не вернёт прежние обращения, которых в нём никогда не было.
Если используемый плагин отправляет почту через отложенные задания, проверьте его очередь и механизм запуска. По умолчанию WP-Cron запускается при загрузках страниц, поэтому время выполнения зависит от обращений к сайту. Эта проверка относится к реально используемой отложенной обработке: обычный вызов wp_mail() сам по себе не означает наличие очереди WP-Cron.
Если проблема возникает только с вложениями
Сравните отправку без файла и с небольшим разрешённым тестовым файлом. В CF7 отдельно настраиваются поле загрузки и добавление файла в письмо: одного поля на странице недостаточно. Проверьте допустимый тип, размер, соответствующий тег в File attachments и ошибки временного каталога. Эти этапы описаны в инструкции по вложениям CF7.
Сохранённый текст заявки не гарантирует сохранение приложенного документа. CF7 использует временный каталог и удаляет загруженный файл после процедуры отправки. Поэтому отдельно выясните, предусмотрен ли архив вложений в вашем хранилище и как проверяется его запись. Не ищите гарантию восстановления в самом факте установки Flamingo. Для повторной проверки используйте обезличенный файл и сохраняйте ограничения загрузки.
Если в Битрикс не приходят письма с сайта
Определите продукт и механизм формы
Для сайта на «1С-Битрикс: Управление сайтом» выясните, используется ли модуль «Веб-формы», компонент обратной связи или собственный обработчик. Проверяйте сохранение там, куда пишет именно он. Документация модуля «Веб-формы» отмечает его недоступность в редакции «Старт». Поэтому отсутствие этого раздела не позволяет объявить форму сломанной; учитывайте редакцию, установленные модули и права администратора.
Облачные CRM-формы Битрикс24 — отдельный сценарий. Для них проверьте элемент CRM и настроенное уведомление сотруднику. В инструкции Битрикс24 сохранение данных в CRM и отправка письма роботом описаны как последовательные этапы; доступность функций зависит от тарифа. Инструкции по серверному cron коробочного сайта нельзя автоматически переносить на облако.
Сверьте событие и почтовый шаблон
Если обработчик использует стандартные почтовые события, проверьте код типа события, переданный идентификатор сайта, выбранный шаблон, его активность и язык. Сверьте реальные значения подстановок для получателя и отправителя. Пустой адрес после подстановки отличается от неверного SMTP-пароля и требует другого исправления. Назначение этих полей описано в документации почтового шаблона.
CEvent::Send создаёт почтовое событие и возвращает его идентификатор. В D7 Event::send возвращает объект результата. Успех создания события не подтверждает получение письма. Проверьте и пользовательские обработчики: например, OnBeforeEventAdd может менять данные, а начиная с версии ядра 11.0.16 при возврате false отменять добавление события.
Проверьте очередь и её фактический запуск
Для стандартной почтовой системы состояния SUCCESS_EXEC помогают локализовать проблему: N — событие ещё не обработано, 0 — шаблоны не найдены, F — отправка не удалась, P — результат частичный, Y — отправка успешна на уровне системы. Значения приведены в описании почтовой системы; Y не является подтверждением папки «Входящие».
Выясните, обрабатываются ли события на обращениях к сайту или через cron. Проверьте последний реальный запуск, путь, пользователя, версию PHP и ошибки задания. Официальный курс для хостеров описывает перенос агентов и системных событий на cron; применимость схемы зависит от версии и окружения. Не копируйте чужие пути и константы без проверки. Для прямого транспорта или немедленной отправки маршрут может отличаться от стандартной очереди.
Очередь, SMTP и ответ 250: что они доказывают
Разделяйте очередь приложения и очередь почтового сервиса. Первая показывает, запущено ли уведомление; вторая — что происходит после передачи письма. У застрявшего задания проверьте время создания, последнюю попытку и текст ошибки. У провайдера ищите сообщение по его идентификатору, получателю и времени, а не только по общему счётчику отправок.
Ответ SMTP 250 нужно связывать с этапом диалога. Согласно RFC 5321, успешный ответ после передачи данных сообщения означает, что сервер принял ответственность за доставку или дальнейшую передачу. Ответ 250 на более раннюю команду ещё не подтверждает принятие всего письма. Ни один из этих ответов сам по себе не доказывает попадание во входящие.
Названия статусов тоже читайте по документации сервиса. Например, у Amazon SES Send и Delivery обозначают разные этапы: принятие запроса на отправку и доставку серверу получателя. Задержка, постоянный отказ и ошибка формирования шаблона требуют разных действий. Сохраните точный ответ, затем исправляйте причину; повторять все письма подряд опасно из-за дублей и лимитов.
Проверьте отправителя без подмены адреса посетителя
В From используйте разрешённый почтовым сервисом адрес вашего домена с необходимым подтверждением отправителя. Адрес посетителя после проверки формата уместен в Reply-To. Такой принцип для CF7 описан в рекомендациях по настройке почты. Учебная схема: From — forms@example.com, Reply-To — проверенное поле email посетителя; example.com здесь обозначает пример, а не рабочий отправитель.
Письмо принято сервером, но менеджер его не видит
Проверьте нужный ящик через веб-интерфейс, включая спам, корзину, архив и корпоративный карантин. Сверьте адрес доставки, правила перенаправления, фильтры и свободное место. Например, справка Gmail по пропавшим письмам отдельно рассматривает заполненное хранилище, папки и действия почтовых клиентов.
Если уведомления идут в группу или на псевдоним, проверьте её участников и ограничения приёма. При пересылке появляется дополнительный этап доставки. Найденное письмо изучите по заголовкам и идентификатору: это помогает отличить исходное уведомление от пересланной копии. Если провайдер подтверждает принятие сервером адресата, дальнейшее расследование ведите вместе с администратором принимающей почты.
Можно ли восстановить заявки за период сбоя
Восстановление начинается с инвентаризации сохранившихся данных. Наличие визита, клика или записи о HTTP-запросе не означает, что текст обращения и контакты доступны. Не обещайте клиентам восстановить всё до проверки источников.
| Что сохранилось | Что можно сделать | Что проверить перед действием |
|---|---|---|
| Полная заявка в CMS или CRM | Передать её менеджеру, при необходимости повторить уведомление | Обрабатывалось ли обращение, актуален ли ответственный |
| Задание или письмо с нужными данными | После устранения причины выполнить контролируемый повтор | Нет ли успешной доставки и дубликата заявки |
| Подходящая резервная копия | Извлечь нужные записи в отдельном окружении | Попали ли обращения в копию, достаточно ли полей |
| Только счётчик или техническая метка | Уточнить период и масштаб сбоя | Не принимать технический след за восстановленное обращение |
Резервную копию сначала исследуйте отдельно от рабочего сайта, чтобы не затереть новые заявки восстановлением старой базы. После извлечения сопоставьте записи по идентификаторам и статусам. Для каждой восстановленной заявки назначьте ответственного и отметьте источник, время и результат обработки. Если форма отправляла только email, письмо потеряно и других копий нет, восстановить содержимое может оказаться невозможно.
По каким признакам считать проблему исправленной
Принимайте работу по полному сценарию, который прежде давал сбой. Одно тестовое письмо из панели проверяет только часть маршрута. Зафиксируйте результат контрольного обращения на реальной форме и проверьте его дальнейшую судьбу.
- Валидная заявка сохраняется с идентификатором и правильными полями.
- Уведомление адресовано нужному сотруднику, а ответ на него идёт по ожидаемому адресу.
- Получатель подтверждает доступность письма, включая корректную обработку вложений.
- Повторная попытка после сбоя не создаёт неконтролируемые дубликаты.
- Ошибки отображаются честно и попадают в доступную ответственному диагностику.
- Заявки проблемного периода сверены, незавершённые переданы в работу.
Отдельно проверяйте задержку, если проблема возникала только вечером, после переноса или при большой очереди. Закрытие инцидента должно включать установленную причину, сделанное исправление и доказательства восстановления. Формулировка «сейчас у меня работает» не объясняет, что произойдёт при повторении прежних условий.
Как контролировать реальные обращения без секретов в журналах
Сопоставляйте количество принятых валидных обращений, сохранённых записей, созданных уведомлений и окончательных ошибок. Эти показатели могут различаться из-за спама, повторов и правил CRM, поэтому расхождения нужно объяснять, а не автоматически считать потерями. Отдельно отслеживайте возраст самого старого необработанного задания и время последнего успешного запуска очереди.
Для диагностики сохраняйте технический идентификатор, форму, время, этап, статус и обезличенный код ошибки. Полные тексты заявок храните в предназначенной для них системе с ограниченным доступом. Не записывайте в общий журнал пароли SMTP, токены, cookie, заголовки авторизации и вложения клиентов. Ограничьте доступ к диагностике и установите разумный срок её хранения.
Контрольные отправки дополняйте проверкой реальных обращений: синтетический тест не покрывает все варианты заполнения. Назначьте сотрудника, который видит предупреждения и проверяет заявки без уведомлений. Периодичность и допустимую задержку определите по процессу продаж; это внутренние критерии бизнеса, а не универсальная гарантия почтовой доставки.
Частые вопросы
Почему не приходят заявки с сайта, хотя тестовое письмо доходит?
Тест мог обойти валидацию формы, её шаблон, интеграцию с CRM или отдельную очередь. Повторите проверку через проблемную форму и проследите одну метку по всем этапам. Рабочий транспорт не подтверждает корректность остальной цепочки.
Поможет ли просто сменить SMTP-плагин?
Только если причина связана с используемым транспортом и замена устраняет её. Ошибку JavaScript, неверного получателя, несохранённую заявку или отключённое правило уведомления такая замена не исправит. Сначала установите последний подтверждённый этап.
Можно ли повторно отправить всю очередь?
Сначала выделите действительно неотправленные сообщения и проверьте, не были ли они приняты после неоднозначного ответа. Массовый повтор способен создать дубли. Начните с контролируемой выборки после устранения причины и проверьте результат.
Что передать специалисту для диагностики?
Адрес формы, проблемный период, часовой пояс, перечень последних изменений, метку контрольной заявки и обезличенные результаты этапов. Пароли и полные обращения не нужны в описании задачи; необходимые доступы передают отдельно установленным безопасным способом.
Дополните диагностическую карточку: укажите, сохраняются ли обращения сейчас. Так проще определить место сбоя, согласовать объём проверки и критерии, по которым вы примете результат.
После восстановления приёма заявок включите сайт и формы в регулярный контроль. Оцените SiteGuard для мониторинга доступности сайта и работы форм, через которые посетители связываются с компанией.