Blog · 7 listopada 2026 · 7 min czytania

Formularz kontaktowy nie działa? Jak to sprawdzić w 10 minut

To najczęstsza cicha awaria firmowej strony. Strona się ładuje, kłódka świeci, formularz pokazuje „Dziękujemy, wiadomość wysłana” – a zapytania od tygodni lądują w próżni. Nikt nie dzwoni z pretensją, bo klient myśli, że to Ty nie odpisujesz, i idzie do konkurencji. Poniżej osiem powodów, dla których tak się dzieje, test, który zrobisz sam w 10 minut, i tabela, która podpowie, kogo prosić o naprawę.

Dlaczego formularz psuje się po cichu

Formularz to łańcuch: przeglądarka klienta → skrypt na stronie → serwer → wysyłka e-maila → serwer pocztowy odbiorcy → folder w Twojej skrzynce. Każde ogniwo może pęknąć osobno, a komunikat „wysłano” zwykle potwierdza tylko pierwsze dwa.

1. Wiadomości trafiają do spamu albo są odrzucane. Wiele wtyczek wysyła e-mail „od klienta”, czyli z adresem klienta w polu nadawcy. Dla serwera pocztowego to podszywanie się pod cudzą domenę: Gmail i Outlook coraz częściej takie wiadomości odrzucają albo kierują do spamu. Do tego dochodzi brak rekordu SPF lub DKIM dla Twojej domeny – Google wymaga co najmniej jednego z nich od każdego nadawcy piszącego na Gmaila (od lutego 2024), bo bez nich odbiorca nie ma jak sprawdzić, że e-mail naprawdę pochodzi z Twojego serwera.
2. Serwer przestał wysyłać pocztę. Po przenosinach hostingu, zmianie wersji PHP albo zaostrzeniu polityki dostawcy funkcja wysyłki bywa wyłączona. Wtyczka nie dostaje błędu, więc nadal pokazuje „wysłano”.
3. Wygasł klucz albo hasło do SMTP. Jeśli formularz wysyła przez zewnętrzną usługę (Gmail, Brevo, SendGrid, Mailgun), zmiana hasła, wygaśnięcie klucza API albo włączenie weryfikacji dwuetapowej odcina wysyłkę z dnia na dzień.
4. Zmienił się adres odbiorcy. Pracownik odszedł, skrzynka została skasowana lub jest pełna, a w ustawieniach formularza nadal widnieje jego adres. Serwer wysyła, nikt nie czyta.
5. Ochrona przed spamem odrzuca ludzi. reCAPTCHA z za wysokim progiem, honeypot, który wypełnia autouzupełnianie przeglądarki, albo filtr słów blokujący „http” w treści – klient widzi niejasny błąd albo wcale go nie widzi.
6. Formularz nie działa na telefonie. Pole wymagane schowane pod klawiaturą, przycisk poza ekranem, lista rozwijana, której nie da się otworzyć dotykiem. Większość zapytań do lokalnych firm przychodzi z telefonów, więc błąd „tylko na komórce” to błąd dla większości.
7. Po aktualizacji skrypt się wysypał. Nowa wersja wtyczki, motywu albo narzędzia do zgód na cookies potrafi zablokować skrypt formularza. Przycisk „Wyślij” kręci się w nieskończoność albo nic nie robi. W konsoli przeglądarki jest czerwony błąd, którego nikt nie widzi.
8. Strona z podziękowaniem zniknęła. Formularz przekierowuje po wysłaniu na stronę „/dziekujemy”, którą ktoś skasował przy porządkach. Klient widzi błąd 404 i wysyła drugi raz albo rezygnuje; przy okazji analityka przestaje liczyć zapytania.

Test w 10 minut, krok po kroku

1. Wyślij zgłoszenie testowe tak, jak klient. Z telefonu, w sieci komórkowej (nie firmowe Wi-Fi), z prywatnego adresu spoza firmowej domeny, np. z Gmaila. W treści wpisz coś łatwego do odnalezienia: „TEST FORMULARZA, 7 listopada, 14:05”. Zanotuj godzinę i to, co pokazała strona po kliknięciu „Wyślij”.
2. Sprawdź wszystkie miejsca, do których mogła trafić. Skrzynka główna, Spam/Wiadomości-śmieci, Oferty/Powiadomienia (Gmail dzieli pocztę na karty), a jeśli wtyczka zapisuje zgłoszenia na stronie – także jej lista zgłoszeń. Daj jej 5 minut; e-mail, który nie dotarł w 5 minut, zwykle nie dotrze wcale.
3. Obejrzyj nagłówki wiadomości, jeśli dotarła. W Gmailu: trzy kropki → „Pokaż oryginał”. Szukaj linii SPF, DKIM i DMARC – powinny mieć wynik PASS. Jeśli widzisz FAIL albo SOFTFAIL, wiadomość przeszła tym razem, ale jest na granicy – następna może nie przejść. Sprawdź też pole „Od”: powinien tam być adres w Twojej domenie, a adres klienta w „Odpowiedz do”.
4. Wyślij celowo pusty formularz. Kliknij „Wyślij” bez wypełniania. Dobry formularz zaznacza puste pola i mówi, co poprawić. Zły – nie robi nic albo pokazuje „wystąpił błąd”. Przy okazji wypełnij pola błędnie (e-mail bez małpy, telefon literami) i sprawdź, czy komunikaty są zrozumiałe.
5. Zajrzyj do konsoli. Na komputerze otwórz stronę z formularzem, naciśnij F12, zakładka „Console”, i kliknij „Wyślij” jeszcze raz. Czerwone linie ze słowami 403, 500, blocked, Content Security Policy albo recaptcha to gotowa wskazówka dla wykonawcy – zrób zrzut ekranu.
6. Sprawdź, co widzi klient po wysłaniu. Czy strona z podziękowaniem istnieje? Czy klient dostaje automatyczne potwierdzenie (i czy to potwierdzenie nie trafia do spamu)? Czy jest na nim informacja, kiedy odpowiecie?
7. Sprawdź formalności. Przy polach na dane osobowe powinna być krótka informacja, kto i po co je przetwarza, z linkiem do polityki prywatności. To wymóg RODO, a dla klienta sygnał, że firma jest poukładana.
8. Zapisz wynik i powtórz za miesiąc. Test, który robi się raz, chroni raz. Wpisz go do kalendarza albo zleć komuś z zespołu na stałe – pierwszego dnia miesiąca, dwie minuty.

Objaw → przyczyna → kto naprawia

Jak nie wrócić do tego za pół roku

• Zapisuj zgłoszenia na stronie, nie tylko w e-mailu. Większość wtyczek formularzy ma moduł zapisujący każde zgłoszenie w bazie strony. Gdy poczta zawiedzie, zgłoszenia nadal są – i masz dowód, od kiedy coś nie działa.
• Wysyłaj z własnej domeny przez SMTP. Nadawcą powinien być adres w rodzaju formularz@twojafirma.pl, a adres klienta trafia do pola „Odpowiedz do”. Do tego rekordy SPF i DKIM dla domeny – ustawia się je raz, u dostawcy domeny lub poczty.
• Dwóch odbiorców. Kopia na drugą skrzynkę (np. właściciela) kosztuje nic, a chroni przed scenariuszem „pracownik odszedł, formularz pisał do niego jeszcze rok”.
• Kontakt awaryjny obok formularza. Numer telefonu jako link tel: i adres e-mail jako tekst. Jeśli formularz zawiedzie, klient ma drugą drogę, zamiast iść do konkurencji.
• Test raz w miesiącu według listy powyżej. Dwie minuty. Wpisz w kalendarz.

Co sprawdzamy w Webskanie, a czego nie

Uczciwie: nie wysyłamy zgłoszeń przez Twój formularz – nie chcemy zaśmiecać skrzynek klientów testami. Nasz audyt pogłębiony sprawdza natomiast wszystko, co widać bez wysyłki: czy pola mają etykiety i czytelne komunikaty błędów, czy formularz działa na telefonie, czy ma ochronę przed spamem i informację o przetwarzaniu danych, czy strona podziękowania istnieje, czy w konsoli nie ma błędów i czy skrypty formularza w ogóle się ładują. Krok „wyślij test z telefonu” zostaje Tobie – zajmuje dwie minuty i jest w tabeli powyżej. Jeśli po wdrożeniu nowej strony chcesz przejść szerszą listę, mamy checklistę 24 punktów.

Źródła i narzędzia

• Google, Wytyczne dla nadawców e-maili – od 1 lutego 2024 każdy nadawca musi mieć SPF lub DKIM, a wysyłający ponad 5000 wiadomości dziennie: SPF, DKIM i DMARC; „nie podszywaj się pod inne domeny ani nadawców”
• Google, Jak wyświetlić nagłówki wiadomości („Pokaż oryginał”)
• Cloudflare, Turnstile – ochrona przed spamem bez zagadek dla użytkownika