Jika pengunjung sudah mengisi formulir tetapi selalu menerima pesan gagal, penurunan enquiry belum tentu berasal dari SEO. Salah satu titik yang perlu diperiksa adalah reCAPTCHA v3: apakah token dibuat pada waktu yang tepat, diverifikasi oleh backend, lalu diterjemahkan menjadi keputusan yang sesuai?
Saya menyarankan menelusuri satu permintaan uji dengan data sintetis. Tujuannya menemukan tahap yang gagal, sehingga perbaikan tidak sekadar menurunkan threshold atau mematikan perlindungan untuk seluruh website.
Gambar jalur permintaan yang sebenarnya
Pada implementasi v3, browser memperoleh token dan mengirimkannya bersama permintaan. Backend memverifikasi token, kemudian aplikasi memeriksa hasil dan menentukan tindakan. Score adalah salah satu masukan keputusan, bukan pengganti verifikasi.
Google menjelaskan bahwa respons v3 perlu diperiksa di backend, termasuk action yang diharapkan. Dokumentasi juga menyebut score staging atau implementasi baru dapat berbeda dari produksi. Karena itu, hasil lingkungan uji tidak langsung menjadi dasar threshold seluruh pengunjung. Dokumentasi reCAPTCHA v3.
Tuliskan siapa yang mengerjakan setiap tahap: plugin form, integrasi bawaan, middleware, atau kode khusus. Jika plugin sudah memverifikasi token, menambahkan verifikasi kedua pada token yang sama dapat membuat alur membingungkan.
Untuk pemilik website tanpa akses kode, minta developer mengembalikan bukti per tahap. Pesan integrasi sudah dipasang belum menjelaskan apakah pengiriman nyata dapat diterima.
Bedakan tiga jenis kegagalan
Pertama, browser gagal menghasilkan token. Penyebab yang perlu diperiksa meliputi script tidak dimuat, konfigurasi key/domain yang tidak sesuai, atau urutan eksekusi yang bermasalah.
Kedua, backend gagal memverifikasi token. Periksa respons layanan dan error yang dikembalikan, bukan hanya pesan umum di layar.
Ketiga, token berhasil diverifikasi tetapi aplikasi menolak berdasarkan kebijakan risiko. Ini memerlukan pemeriksaan keputusan score, action, hostname, dan aturan bisnis yang diterapkan.
Gunakan log terbatas yang mencatat ID permintaan uji, waktu, tahap, status, action yang diharapkan, hasil verifikasi, serta keputusan aplikasi. Jangan menulis secret atau isi lengkap data calon pelanggan ke log pemeriksaan.
Periksa umur dan penggunaan token
Token reCAPTCHA berlaku dua menit dan hanya dapat diverifikasi sekali. Backend menggunakan endpoint verifikasi dengan secret serta token respons. Error timeout-or-duplicate menunjukkan token terlalu lama atau sudah pernah digunakan. Verifikasi respons reCAPTCHA.
Untuk melindungi tindakan submit, panggil proses perolehan token ketika pengguna mengambil tindakan tersebut, lalu segera kirimkan ke backend. Membuat token saat halaman pertama dibuka dapat bermasalah ketika orang membutuhkan waktu lama mengisi formulir. Panduan v3.
Contoh ilustratif: token dibuat pukul 10.00, pengunjung selesai mengisi pukul 10.04, lalu pengiriman ditolak. Memperbaiki teks tombol tidak mengatasi token yang sudah kedaluwarsa. Perbaikan perlu dilakukan pada waktu perolehan token dan alur percobaan ulang.
Retry harus memperoleh token baru. Namun, token baru sendiri tidak mencegah permintaan bisnis yang sama tersimpan dua kali. Gunakan identitas permintaan dan aturan deduplikasi aplikasi untuk menangani tombol ganda atau koneksi terputus.
Pakai matriks diagnosis sebelum mengubah aturan
| Gejala | Pemeriksaan pembeda | Arah perbaikan |
|---|---|---|
| Semua pengiriman gagal setelah perubahan integrasi | Cocokkan jenis key, domain, secret server, dan respons verifikasi | Perbaiki pasangan konfigurasi yang salah |
| Form singkat berhasil, form lama gagal | Catat kapan token diperoleh dan kapan dikirim | Peroleh token dekat tindakan submit |
| Percobaan pertama berjalan, retry gagal | Cari token yang dipakai ulang atau diverifikasi dua kali | Tentukan satu pemilik verifikasi dan token baru |
| Token valid, action berbeda | Bandingkan action yang dikirim browser dengan yang diharapkan endpoint | Selaraskan kontrak action per fungsi |
| Score rendah memblokir banyak pengunjung yang valid | Tinjau sampel berizin serta kebijakan keputusan | Sesuaikan penanganan berdasarkan bukti |
| UI gagal tetapi data sudah tersimpan | Periksa penyimpanan dan tahap notifikasi | Hindari meminta ulang tanpa mengetahui status awal |
Action sebaiknya menggambarkan fungsi, misalnya enquiry_submit, bukan identitas orang. Cocokkan hostname hasil verifikasi dengan host yang memang diizinkan oleh implementasimu.
Jika backend tidak dapat mencapai layanan verifikasi, perlakukan sebagai kegagalan layanan yang teramati. Jangan diam-diam menganggap semua pengiriman valid maupun menuduh seluruh pengunjung sebagai bot.
Pisahkan score dari keputusan pelayanan
Tidak ada angka threshold yang membuktikan semua enquiry bersih dan semua spam tertolak. Tetapkan pilihan sesuai risiko serta kemampuan tim: diterima, membutuhkan langkah tambahan, masuk peninjauan, atau ditolak dengan cara mencoba kembali yang jelas.
Contoh kebijakan internal ilustratif: permintaan yang lolos verifikasi tetapi memerlukan peninjauan diberi status khusus dan ditangani petugas. Itu belum boleh dihitung sebagai lead qualified. Kebijakan tersebut harus dirancang bersama pengelola layanan, bukan diterapkan hanya karena terlihat mudah di kode.
Jika pembaca tidak bisa menyelesaikan form, sediakan jalur alternatif yang memang dikelola. Pesan kesalahan sebaiknya menjelaskan tindakan berikut tanpa membocorkan detail teknis sensitif.
Uji keberhasilan sampai permintaan ditemukan
Jalankan pengiriman cepat, pengisian yang lama, tombol ganda, token yang kedaluwarsa pada lingkungan uji, serta kegagalan notifikasi. Catat hasil yang diharapkan sebelum menjalankan setiap skenario.
Untuk kasus valid, pastikan permintaan tersimpan satu kali dan dapat ditemukan petugas. Untuk kasus yang ditolak, pastikan UI tidak menampilkan sukses. Untuk retry, pastikan pengguna tidak kehilangan seluruh isi tanpa alasan.
Lanjutkan dengan pemeriksaan jalur formulir sampai sales setelah lapisan reCAPTCHA terbukti berjalan. Event Analytics tentang form berhasil sebaiknya mengikuti keberhasilan yang memang telah didefinisikan, bukan sekadar klik tombol.
Simpan versi konfigurasi sebelum perbaikan dan hasil uji sesudahnya. Jika masalah muncul lagi, tim mempunyai bukti untuk membedakan perubahan traffic, kegagalan token, serta masalah penerimaan enquiry.
