Заявки с сайта не приходят после Beget: проверяем форму, CRM и почту

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

Если после восстановления Beget не приходят заявки с сайта, проверьте всю цепочку: запрос браузера, ответ обработчика, сохранение, очередь и получателя в почте или CRM. Проведите согласованный контрольный сценарий, отдельно исследуйте ошибки и повторы. 404ai поможет восстановить маршрут; надпись об успехе, HTTP-ответ и цель аналитики сами по себе не подтверждают получение обращения компанией.

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

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

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

MDN описывает отправку форм через JavaScript как запрос к конкретному обработчику. После смены окружения этот адрес, его доступы или получатель могли измениться. Публичный HTML способен работать независимо от утраченного серверного процесса. Именно поэтому визуальная приёмка страницы не заменяет проверку доставки.

В 404ai можем помочь восстановить формы и путь заявки после сбоя сайта: разберём обработчик, подключение к почте или CRM, ответы и найденные пробелы. Если сайт пришлось пересобрать из веб-архива, настроим доступные функции заново по согласованному объёму. Сначала оценим состояние; обещать доставку в неизвестную систему без проверки не будем.

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

Найдите форму и её фактического получателя

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

Для каждой записи укажите страницу, назначение, адрес обработчика, место сохранения, способ доставки и ответственного. Если получатель известен только как «почта компании», выясните конкретный ящик и кто его проверяет. После аварии часть сотрудников может использовать старый адрес или ждать уведомления из другой системы. Технический запрос полезен тогда, когда у него есть понятный деловой выход.

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

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

Проверьте запрос в браузере

На разрешённом тесте откройте инструменты разработчика и посмотрите сетевой запрос после отправки. Нужны адрес, метод, HTTP-статус и ожидаемый формат ответа. Не сохраняйте клиентские контакты в общий скриншот. Для проверки используйте согласованные тестовые значения и маркировку, которую получатель сможет отличить от настоящего обращения.

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

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

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

HTTP-ответ: успех должен соответствовать приёмке

В документации Fetch отмечено, что HTTP-ошибка сама по себе не всегда отклоняет Promise. Код формы должен проверить статус и предусмотренное подтверждение в ответе. Иначе ошибка сервера может завершиться той же надписью «Готово», что и реальный приём заявки. При проверке нужен как успешный, так и неуспешный сценарий.

Ответ 200 не определяет бизнес-смысл автоматически. Он может содержать HTML страницы входа вместо ожидаемого JSON, сообщение о неверных данных или общую страницу сайта после неправильного перенаправления. Сопоставьте тип и структуру ответа с договорённостью обработчика. Не добавляйте успех по принципу «сервер что-то вернул». У приложения должно быть конкретное основание сообщить человеку о приёме.

Таблица не является автоматическим диагнозом: один статус может иметь несколько причин. Используйте журнал и фактическое поведение. Например, 403 способен прийти от приложения, прокси или защитного слоя. Многократная замена пароля SMTP не исправит запрос, который даже не дошёл до почтового обработчика.

Серверный обработчик и сохранение обращения

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

Проверьте, на каком этапе обращение считается принятым. Надёжная схема должна иметь понятное сохранённое основание до сообщения об успехе. Конкретный механизм зависит от приложения: запись, очередь или подтверждённая передача. Если используется только отправка письма без контролируемого результата, это ограничение нужно понимать и по возможности устранить в согласованном объёме.

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

Если база восстановлена из старой копии, проверьте совместимость структуры с текущим обработчиком. Он может ожидать поле или таблицу, которых в выбранном состоянии ещё нет. Для работы с копией используйте порядок восстановления MySQL. Не запускайте непроверенные изменения схемы на единственном рабочем экземпляре ради одной формы.

Доступы и внешняя CRM

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

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

Проверьте ошибки авторизации и ограничений отдельно от недоступности сети. Неверный токен, превышение лимита и неправильный URL требуют разных действий. Не запускайте бесконечные повторы на любой ответ: они могут ухудшить ситуацию и создать дубли после частичного успеха. Поведение повторения должно соответствовать контракту внешнего API и правилам вашего обработчика.

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

Письма с сайта: отправлено не всегда значит получено

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

После смены сервера уточните, какие системы вправе отправлять сообщения от домена. Например, Google описывает SPF как настройку разрешённых отправителей. Это один элемент почтовой конфигурации, а не универсальное средство доставки. Изменения записей согласуют с администратором почты, сохраняя действующие источники и другие необходимые настройки.

Не переписывайте всю DNS-зону ради одной формы. В ней могут находиться почтовые и проверочные записи, которые пережили первоначальный сбой. Исправление сайта не должно остановить оставшиеся рабочие ящики. Сохраните прежние значения, изменяйте только установленную причину и проверяйте результат. Домен, почта и веб-сервер связаны, но управляются разными параметрами.

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

CORS, HTTPS и прежний адрес обработчика

При смене домена или размещения браузер может иначе рассматривать запрос к API. Проверьте origin, перенаправления и правила доступа конкретного сервиса. MDN объясняет механизм CORS: разрешения задаются сервером, а не пожеланием JavaScript на странице. Отключение защиты в личном браузере инженера не исправляет маршрут настоящего посетителя.

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

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

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

Дубли, таймауты и потерянное подтверждение

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

Не очищайте поля до подтверждения принятия. При временной ошибке сохраните введённое и дайте понятный путь повторения или прямого контакта. Если сервер не подтвердил приём, так и напишите. Сообщение об успехе ради спокойствия посетителя создаёт противоположный результат: человек уверен, что компания получила запрос, а компания даже не знает о его существовании.

Для очереди повторной доставки храните состояние и назначение. При возвращении внешней системы не нужно отправлять весь накопленный набор без проверки уже принятых событий. Используйте идентификаторы и правила получателя. Перезапуск обработчика после сбоя не должен превращать один запрос клиента в несколько независимых задач разным менеджерам.

Сверьте обращения за время простоя

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

Аналитика помогает увидеть действия, но её событие не заменяет запись заявки. Метод reachGoal в Метрике фиксирует вызванную на странице цель. Бизнес-смысл зависит от места вызова. Цель на клике и цель после принятого ответа измеряют разные этапы; ни одна сама по себе не подтверждает, что менеджер обработал обращение.

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

Как принять восстановление форм

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

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