Форма на сайті може виглядати повністю робочою: поля заповнюються, кнопка натискається, з’являється повідомлення “надіслано”. Але лист власнику не приходить. Для бізнесу це небезпечніше за видиму помилку. Коли форма показує червоне попередження, проблему хоча б помічають. Коли все виглядає успішно, заявки можуть губитися тижнями.
Проблема не завжди в самій формі. Частіше ламається ланцюг доставки: сайт прийняв дані, але лист не пройшов через сервер, SMTP, DNS, спам-фільтр чи поштову скриньку одержувача. Тому правильне питання не “чому форма не працює”, а “на якому етапі зникає заявка”.
Чому це стосується будь-якого сайту
Це не тільки проблема конкретної CMS, одного плагіна чи однієї платформи. Така ситуація може бути на сайті з саморобною формою, на старій CMS, на конструкторі, в інтернет-магазині, на лендингу чи у формі бронювання.
Різниця лише в тому, де саме знаходиться контроль. На одному сайті можна подивитися лог відправки, збережені заявки і налаштування SMTP. На іншому власник бачить тільки візуальний редактор і лист у пошті. Тому діагностика завжди починається з розуміння платформи: що сайт реально зберігає, як він відправляє листи і чи можна побачити технічний слід заявки.
Google у своїх матеріалах з Workspace окремо пише, що сама форма зазвичай не головна причина. Частіше проблема в тому, як повідомлення відправляється і підтверджується поштовою системою: SPF, SMTP relay, DKIM і налаштування відправника. Це важливий момент. Кнопка “Надіслати” може бути справною, але пошта все одно відхилить лист як підозрілий.
Де найчастіше ламається ланцюг
У заявки є кілька етапів.
- Клієнт заповнює форму.
- Сайт перевіряє поля і захист від спаму.
- Сайт формує лист.
- Сервер чи SMTP-сервіс намагається його відправити.
- DNS-записи домену підтверджують, що відправник має право надсилати лист.
- Gmail, Outlook чи інший поштовий сервіс перевіряє повідомлення.
- Лист потрапляє у вхідні, у спам чи відхиляється.
- Якщо на сайті увімкнено збереження заявок, запис залишається в адмінці, базі чи CRM.
На кожному етапі може бути своя помилка.
Найчастіші причини:
- форма відправляє лист через звичайний PHP mail без нормальної авторизації
- SMTP не налаштовано, або пароль SMTP змінився
- From вказано як e-mail клієнта, а не адресу домену сайту
- Reply-To не налаштовано, тому відповідь іде не клієнту
- SPF не включає сервер чи сервіс, який реально відправляє лист
- DKIM не увімкнено чи зламано після перенесення пошти
- DMARC занадто строгий для поточної схеми відправки
- лист схожий на spoofing, тобто підміну відправника
- поштова скринька переповнена, або фільтр складає листи в спам
- captcha чи антиспам блокує нормальних клієнтів
- кеш чи оптимізація заважають відправці форми
- після оновлення змінилися поля, шаблон листа чи endpoint форми
- на сайті немає збереження заявок, тому втрачений лист не можна відновити
Чому From і Reply-To так важливі
Одна з найчастіших помилок - відправляти лист так, ніби він прийшов напряму від клієнта.
Наприклад, клієнт вказав client@gmail.com, а сайт намагається відправити лист із сервера сайту із заголовком From: client@gmail.com. Для поштового сервісу це виглядає підозріло: лист іде не із серверів Gmail, але заявляє, що він від Gmail. Так з’являється ризик spoofing, потрапляння в спам чи відхилення.
Правильніше робити інакше:
- From: технічна адреса домену сайту, наприклад
no-reply@domain.frчиcontact@domain.fr - Reply-To: e-mail клієнта з форми
- To: робоча адреса власника чи відділу продажів
Тоді поштова система бачить зрозумілу картину: сайт відправляє службовий лист від свого домену, а власник може натиснути Reply і відповісти клієнту. Це не вирішує всі проблеми автоматично, але прибирає одну з найчастіших причин блокувань.
Чому SMTP зазвичай кращий за відправку з хостингу
Звичайний сайт не повинен бути повноцінною поштовою системою. Хостинг добре віддає сторінки, але не завжди добре відправляє листи. На спільному сервері можуть бути обмеження, погана репутація IP, блокування портів чи ліміти відправки.
SMTP вирішує частину цієї проблеми. Сайт підключається до поштового сервісу з логіном і паролем чи через API, а лист іде через систему, призначену для доставки e-mail. Це може бути пошта домену, Google Workspace, Microsoft 365, SendGrid, Mailgun, Brevo, Postmark чи інший сервіс.
Але SMTP теж потрібно налаштувати правильно:
- обрати правильний порт і тип шифрування
- перевірити логін і пароль
- налаштувати адресу відправника
- додати SPF, DKIM і за потреби DMARC
- відправити тестовий лист
- перевірити доставку на Gmail, Outlook і доменну пошту
- подивитися, чи не потрапляє лист у спам
Якщо просто поставити SMTP-плагін чи модуль і не перевірити результат, проблема може залишитися. Власник побачить “успішно відправлено”, а пошта продовжить фільтрувати повідомлення.
Добре, коли заявки фіксуються на сайті
Ідеальна ситуація: заявка не тільки відправляється листом, а й зберігається на сайті, у базі, CRM чи окремому журналі. Тоді, якщо лист потрапив у спам чи був відхилений, можна відкрити адмінку і побачити, що клієнт все-таки писав.
Це особливо важливо для бізнесу, який запускає рекламу, приймає бронювання чи отримує дорогі заявки. Якщо за клік уже заплачено, втрачена форма - це не технічна дрібниця, а прямі гроші.
Але важливо сказати чесно: далеко не на всіх сайтах це реалізовано і не всюди це легко увімкнути.
Обмеження бувають різні:
- закритий конструктор не дає нормального доступу до бази
- форма вбудована зовнішнім сервісом і зберігає дані тільки в себе
- старий сайт відправляє листи напряму і нічого не зберігає
- тариф платформи не включає історію заявок
- на сайті немає CRM, webhook чи модуля логування
- є юридичні вимоги щодо персональних даних і термінів зберігання
- після злому чи збою база могла бути очищена
Тому під час аудиту форми потрібно перевірити не тільки доставку листа, а й питання: де залишається запис про заявку. Якщо відповіді немає, бізнес залежить тільки від поштової скриньки.
Приклад з практики: заявки були, але власник їх не бачив
Сценарій типовий для сайту локальної послуги. Власник запустив рекламу, люди переходили на сторінку, форма показувала повідомлення про успішну відправку. У пошті було тихо. Перший висновок був простий: реклама не працює, попиту немає.
Під час перевірки з’ясувалося інше. Після зміни пошти домену стара схема відправки залишилася незмінною. Сайт намагався відправляти сповіщення з адреси клієнта з форми, а не з адреси домену сайту. Для Gmail і Outlook це виглядало як підозріла підміна відправника: лист технічно прийшов із сервера сайту, але заголовок стверджував, що він від зовнішньої адреси клієнта.
Частина листів ішла в спам, частина відхилялася без помітного сповіщення для власника. На комп’ютері форма виглядала робочою, бо користувач бачив “відправлено”. Проблема була не в дизайні форми, а в доставці.
У цьому випадку пощастило: заявки зберігалися в адмінці сайту. За журналом вдалося побачити кілька звернень за останні дні, перевірити час відправки, сторінку, телефон і e-mail клієнта. Частину клієнтів ще можна було наздогнати дзвінком чи листом. Якби збереження заявок не було, відновити їх було б майже неможливо. Залишилися б лише непрямі сліди: кліки в рекламі, відвідування сторінок, події аналітики, але не самі контакти клієнтів.
Рішення полягало не в тому, щоб “поставити іншу форму”. Спочатку виправили схему:
- From замінили на адресу домену сайту
- Reply-To прив’язали до e-mail клієнта
- відправку перевели через SMTP
- перевірили SPF і DKIM
- додали базовий DMARC у м’якому режимі
- увімкнули лог відправки
- відправили тести на кілька поштових скриньок
- перевірили mobile-сценарій
Після цього стало зрозуміло, що сайт приймає заявки, листи доходять, а власник може перевірити історію, якщо знову виникнуть сумніви.
Що можна перевірити самому
Базову перевірку можна зробити без доступу до коду.
- Відкрийте форму як клієнт, не з адмінки.
- Відправте тест з комп’ютера.
- Відправте тест з телефону.
- Використовуйте інший e-mail, не той, на який приходить заявка.
- Перевірте inbox, спам, промоакції, оновлення і “Усі листи”.
- Натисніть Reply в отриманому листі і подивіться, кому піде відповідь.
- Перевірте, чи приходить автовідповідь клієнту, якщо вона повинна приходити.
- Подивіться, чи зберігається заявка в адмінці, CRM чи таблиці.
- Запишіть точний час тесту, сторінку і e-mail відправника.
- Не змінюйте одразу п’ять налаштувань, інакше потім буде незрозуміло, що допомогло чи зламало.
Особливо важливо тестувати форму перед рекламною кампанією. Якщо реклама вже веде людей на сторінку, а форма мовчки губить листи, бюджет іде в порожнечу. Власник може помилково вирішити, що пропозиція погана, хоча проблема знаходиться в доставці заявок.
Коли проблема не в листах
Іноді лист узагалі не створюється. Тоді SMTP і DNS не допоможуть.
Так буває, якщо:
- кнопка не натискається на телефоні
- обов’язкове поле зламане
- captcha блокує всіх підряд
- після відправки відбувається помилка JavaScript
- форма знаходиться в popup, а скрипт popup конфліктує з кешем
- файл теми чи шаблону не передає дані форми
- endpoint форми заблоковано захистом чи firewall
- багатомовна версія відправляє заявку в неіснуючу форму
Тому діагностику не можна починати тільки з пошти. Потрібно пройти весь шлях клієнта: відкрити сторінку, заповнити форму, відправити, побачити результат, перевірити лист, перевірити лог і перевірити збереження заявки.
Коли краще звернутися до Zen Webmaster
Якщо форма важлива для заявок, бронювань, розрахунків чи продажів, її не можна вести за принципом “поставили і забули”. Потрібен контроль.
Zen Webmaster може перевірити:
- чи працює форма на desktop і mobile
- чи не заважають popup, кеш, captcha чи скрипти
- чи правильно налаштовані From і Reply-To
- чи є SMTP і коректні доступи
- чи проходять SPF, DKIM і DMARC
- чи потрапляють листи в спам
- чи зберігаються заявки в адмінці, CRM чи логах
- чи можна побачити пропущені звернення
- які форми є на сайті і чи всі вони працюють
- що варто тестувати регулярно після оновлень
Після перевірки можна залишити просту схему контролю: тестова заявка раз на місяць, перевірка після оновлень, контроль перед рекламою, лог відправки і збереження заявок там, де це можливо. Це нудна технічна рутина, але саме вона захищає бізнес від ситуації “клієнти писали, а ми нічого не отримали”.
Головна думка
Форма сайту - це не просто набір полів. Це вхід у бізнес. Якщо вона ламається, власник може втратити не тільки лист, а й клієнта, рекламний бюджет і довіру до сайту.
Хороше налаштування не обіцяє магії. Воно робить систему перевірюваною: видно, що клієнт відправив заявку, видно, чи пішов лист, зрозуміло, куди відповідати, і є шанс знайти пропущені звернення. Якщо цього немає, сайт може здаватися робочим, але мовчки втрачати гроші.
Останні статті
