reCAPTCHA té una part al navegador, que obté un token, i una altra al servidor, que el verifica. L’script pot no carregar, la clau pot no correspondre al hostname, el token pot caducar o un llindar massa exigent pot rebutjar trànsit legítim.
Determina en quin costat es produeix l’error abans de substituir o desactivar la protecció.
Reprodueix el context del visitant
Anota la pàgina, el hostname, l’hora, el dispositiu, el navegador i el tipus de xarxa. Utilitza dades sintètiques i inspecciona la consola i l’activitat de xarxa.
Comprova si es carrega l’API, si es demana un token i què retorna l’endpoint final. No copiïs el token: és una credencial de seguretat temporal.
Fes la prova sense sessió iniciada i seguint el flux de consentiment que veu una visita normal.
Relaciona la petició amb els codis de verificació: secret incorrecte, token absent, duplicat o caducat. Conserva només el nom de l’error i l’hora. Aquesta dada permet diferenciar una configuració incorrecta, un bloqueig al navegador o la reutilització del token sense exposar-lo.
Verifica el tipus de clau i el hostname
Confirma que la site key i el secret pertanyen al mateix projecte i a la mateixa versió. Una clau v2 checkbox no substitueix una clau v3, i les variants invisibles tenen requisits diferents.
Revisa els dominis autoritzats per al domini canònic, amb www i sense, i per al subdomini de producció. Després d’una migració és habitual que només hi consti el domini anterior.
Mantén credencials separades per a staging i producció. El secret no ha d’aparèixer mai al codi HTML.
Revisa el consentiment i els bloquejos
Un gestor de galetes pot bloquejar els scripts de Google fins que l’usuari consenteixi. Acorda amb el responsable de privacitat si el CAPTCHA és seguretat necessària o un servei subjecte a consentiment, i aplica la classificació de manera coherent.
Si l’script no es pot carregar, el formulari no ha de quedar inutilitzat sense explicació. Mostra un missatge accessible i ofereix una alternativa de contacte aprovada.
Inspecciona també la política CSP i els errors de protecció de privacitat del navegador. Demanar a l’usuari que desactivi les seves proteccions no és una reparació.
Comprova l’optimització i l’ordre de càrrega
Les opcions de delay, defer o combinació poden executar el formulari abans que l’API estigui disponible. Cerca callbacks inexistents, càrregues duplicades i condicions de carrera.
Exclou només els handles que hagis demostrat que entren en conflicte i regenera els recursos. No cal desactivar tota l’optimització.
Revisa widgets duplicats, finestres emergents o formularis injectats tard que intentin inicialitzar reCAPTCHA més d’una vegada.
Diagnostica la caducitat del token
Els tokens duren poc i normalment són d’un sol ús. Un formulari llarg pot arribar al final amb un token que ja no és vàlid.
Compara un enviament ràpid amb un altre després del retard que descriu l’usuari. Renova el token amb el flux compatible just abans d’enviar; no ampliïs indefinidament el període d’acceptació.
Evita que un doble clic reutilitzi el mateix token. Si la validació falla i el formulari permet tornar-ho a provar, genera’n un de nou. Restaurar l’aspecte del formulari sense renovar reCAPTCHA provocarà un segon rebuig encara que els camps ja siguin correctes.
Revisa la puntuació i l’acció de v3
En reCAPTCHA amb score, inspecciona al servidor el resultat, el nom de l’acció i la puntuació de proves controlades. L’acció esperada ha de coincidir amb la que ha sol·licitat el navegador.
Ajusta el llindar basant-te en trànsit legítim i complementa’l amb honeypot o limitació de freqüència. No publiquis detalls que facilitin eludir el control.
Ofereix revisió manual o una alternativa per a consultes pròximes al llindar. Prova també teclat, zoom i avisos del lector de pantalla.
Verifica la comunicació del servidor
WordPress ha de poder arribar al servei de verificació i validar-ne la resposta. Revisa DNS, connexions HTTPS sortints, certificats CA, hora del sistema i errors PHP.
No desactivis la comprovació TLS. La resposta només s’ha d’acceptar després de validar success, hostname, action i qualsevol altre camp necessari.
Registra el resultat mínim imprescindible, mai tokens ni respostes completes.
Demostra tant l’èxit com el rebuig
Després de reparar-ho, prova un ordinador i un mòbil reals amb l’estat normal de consentiment. Confirma una sola entrada, la notificació i l’arribada final.
Prova també la caducitat i un token invàlid controlat. El visitant ha de rebre un missatge útil i la protecció ha de continuar funcionant.
Demana reparació urgent si es desconeix el propietari de les claus, les puntuacions legítimes són molt inestables o hi ha un conflicte de privacitat. Comparteix el hostname i errors anonimitzats, mai secrets, tokens ni dades personals.