Контактная форма не работает? Как на самом деле найти причину

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

1. Проверьте, что запрос сделал на самом деле

Откройте страницу, откройте devtools, переключитесь на вкладку Network и отправьте форму сами. Здесь постоянно ломаются две вещи:

• URL в action неверен - опечатка в API-ключе, URL, скопированный со старой формы и никогда не обновлённый, или (до неловкости часто) всё ещё указывающий на localhost из локальной разработки и так и не переключённый на продакшен.
• Запрос уходит, но возвращается со статусом ошибки. Необязательно знать точное значение каждого кода - ответа 4xx или 5xx достаточно, чтобы понять: проблема на стороне получателя, а не в вашем HTML.

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

2. Убедитесь, что отправка действительно идёт методом POST

<form> без явного method="POST" по умолчанию использует GET, который добавляет ваши поля к URL в виде строки запроса вместо отправки тела запроса - эндпоинт бэкенда форм обычно не примет это как настоящую отправку. Сначала проверьте сам тег.

Если форма отправляется через JavaScript, а не нативным POST браузера, более распространённая проблема - обработчик, который вызывает e.preventDefault(), чтобы остановить навигацию по умолчанию, а затем на самом деле ничего не отправляет - сломанный вызов fetch, опечатка в эндпоинте внутри обработчика или тихий преждевременный return. preventDefault() без работающего запроса за ним для посетителя неотличим от мёртвой формы: страница просто... ничего не делает.

3. Исключите консоль, а не только сеть

Для любой отправки на основе fetch откройте вкладку Console вместе с Network. Ошибка CORS, заблокированный запрос со смешанным контентом (отправка на http:// со страницы на https://) или необработанное исключение внутри обработчика отправки - каждое из этого полностью останавливает запрос, и ни одно не выдаёт видимой ошибки посетителю. Всё это выглядит как тишина - именно так снаружи и выглядит сломанная форма.

4. Проверьте, куда на самом деле попало уведомление

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

5. Учтите тихий отказ - ограничение частоты и сломанный honeypot

Легитимные отправки иногда воспринимаются как подозрительные. Повторное быстрое тестирование с одного и того же IP во время отладки - это ровно тот паттерн, который и должно ловить ограничение частоты запросов, и оно может сработать без какого-либо злого умысла с вашей стороны. Подождите несколько минут и попробуйте снова, прежде чем считать, что что-то сломано.

Более тонкий и действительно распространённый баг: поле honeypot. Большинство систем защиты от спама включает скрытое поле, которое настоящие посетители никогда не видят и не заполняют - если его заполняет бот, отправка тихо отбрасывается. CSS-регрессия (переименованный класс, не загрузившийся стиль, изменение вёрстки, «снимающее скрытие» не с того элемента) может сделать это поле видимым для реальных пользователей, которые либо путаются из-за лишнего поля, либо - что хуже - получают его автозаполненным менеджером паролей, что срабатывает тот же фильтр, задуманный для ботов. Если отправки начали проваливаться сразу после редизайна или изменения CSS, это стоит проверить в первую очередь.

Проверяйте дашборд, а не только почтовый ящик

Общий урок из всего вышеперечисленного: «пришло ли мне письмо» - это не тот же вопрос, что «дошла ли отправка», и их смешение - именно то, из-за чего подобный баг ищут днями вместо минут. В Formhook каждая отправка, которая реально дошла до бэкенда, появляется в дашборде независимо от того, доставлено ли письмо с уведомлением, - поэтому первая полезная проверка, ещё до всех перечисленных шагов, - это просто зайти и посмотреть. Если отправка там есть, проблема на стороне уведомлений (шаги 4-5). Если её там нет, проблема раньше по цепочке - запрос вообще не дошёл до бэкенда (шаги 1-3).

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