Після зміни домену сайт може відкриватися без помилок, але звернення з форм більше не доходять до команди. Не варто одразу робити висновок, що зник попит: спершу потрібно перевірити шлях тестової заявки. Важливо встановити, на якому саме етапі вона губиться, а не навмання змінювати всі налаштування. Зафіксуйте дату перенесення, перелік змінених сервісів і останній відомий успішний контакт.
Як перевірити форми, поштові адреси та зовнішні інтеграції
Складіть перелік усіх місць, де відвідувач залишає дані: сторінка контактів, форми послуг, спливні вікна, мобільна версія. Перевіряйте їх окремо. Дві схожі форми можуть мати різних отримувачів або різні маршрути передачі даних. Для кожного тесту використовуйте впізнаваний текст і час відправлення, щоб знайти його в повідомленнях та журналах.
Далі звірте адресу отримувача, адресу відправника й адресу для відповіді. Після перенесення в налаштуваннях можуть залишитися старі значення. Переконайтеся, що потрібна скринька існує, доступна й перевіряється відповідальною людиною. Якщо змінився також поштовий сервіс, попросіть адміністратора перевірити його налаштування за документацією провайдера. Не замінюйте DNS-записи навмання.
- Перевірте, чи форма передає дані саме з нового домену.
- Звірте отримувачів повідомлень у кожній формі.
- Перевірте налаштування поштового підключення, якщо воно використовується.
- Перегляньте адреси зовнішніх інтеграцій і дозволені домени в їхніх кабінетах.
- Знайдіть тестове звернення у CRM або іншій кінцевій системі.
Зміна адреси сайту не означає, що всі зовнішні сервіси автоматично оновили свої налаштування. Перевірку слід виконувати для конкретного підключення, не вимикаючи захист усього сайту. Якщо підозра саме на маршрутизацію пошти, скористайтеся матеріалом Повідомлення з сайту потрапляють не на ту пошту: що перевірити.
Чому успішне натискання кнопки ще не означає доставку
Напис «Дякуємо за звернення» показує відповідь інтерфейсу, але сам по собі не доводить, що менеджер отримав дані. Окремими етапами є приймання форми, обробка на сайті, передача повідомлення та його отримання. Помилка може виникнути після того, як користувач уже побачив підтвердження.
Тому попросіть виконавця показати не лише екран успіху, а й конкретний тест у кінцевій скриньці або CRM. Якщо повідомлення відсутнє, перевірте доступні журнали, папку спаму, правила пересилання та відповіді зовнішнього сервісу. Запис про спробу відправлення не слід називати доказом доставки.
Паралельно відокремте технічну несправність від зміни кількості відвідувачів. Якщо контрольна заявка доходить, це ще не пояснює зменшення реальних звернень: потрібно окремо аналізувати відвідуваність і поведінку людей. І навпаки, наявність трафіку не підтверджує працездатність форми.
Як прийняти виправлення і перевірити результат ремонту
Приймайте ремонт за відтворюваним сценарієм. Відкрийте публічну сторінку як звичайний відвідувач, заповніть форму тестовими даними й переконайтеся, що вони надійшли потрібному отримувачу без втрати полів. Повторіть перевірку на телефоні та для інших форм, яких стосувалися зміни. Узгодьте перевірку з командою, щоб тест не сприйняли як справжнє замовлення.
У короткому звіті мають бути причина збою, змінені налаштування, час перевірки й підтверджений результат. Не просіть надсилати паролі чи ключі доступу у звичайному звіті. Для подальшого контролю домовтеся, хто та коли повторно перевірятиме форми; орієнтиром може бути пояснення, що входить у технічну підтримку сайту.
Завершений ремонт — це не лише відсутність повідомлення про помилку, а підтверджене проходження заявки до відповідального працівника. Ширший порядок перевірок наведено в статті Не працює форма заявки на сайті WordPress: діагностика без втрати лідів. Збережіть результати тестів, щоб під час наступного перенесення мати зрозумілу контрольну точку.