Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Navegador Javascript Spam Privacidad

La protección honeypot bloquea envíos legítimos del formulario

Diagnostica falsos positivos por autocompletado, gestores de contraseñas, accesibilidad, caché, campos duplicados y tiempo mínimo.

Un honeypot es un campo que una persona debería ignorar y un bot sencillo suele rellenar. Sin embargo, el autocompletado, los gestores de contraseñas, las ayudas técnicas o un fallo de estilos pueden exponer o completar la trampa para un visitante real.

Identifica el motivo exacto antes de desactivar toda la protección contra spam.

Confirma de dónde procede el rechazo

Envía datos sintéticos y anota hora, ID del formulario, navegador y respuesta. Consulta en el plugin el motivo protegido de spam o su registro para confirmar que intervino el honeypot.

Un estado genérico también puede proceder de CAPTCHA, Akismet o un filtro propio. No atribuyas el rechazo al campo trampa sin un evento o una comparación controlada.

No registres todos los campos enviados solo para averiguar el estado de un indicador.

Inspecciona el campo renderizado

Busca el campo señuelo en el HTML final mediante las herramientas del navegador. No debería ser visible, recibir foco ni anunciarse como una entrada que la persona deba completar.

Comprueba si la ausencia de CSS, una política CSP o la optimización hacen que aparezca en móvil o durante la carga inicial. Los identificadores duplicados también pueden asociar al honeypot la etiqueta de un campo real.

Verifica que no se haya ocultado por error un campo obligatorio auténtico.

Prueba el autocompletado del navegador

Los navegadores deducen la finalidad de un campo por nombre, etiqueta y marcado cercano. Un señuelo llamado email, teléfono o dirección puede rellenarse incluso cuando no se ve.

Prueba perfiles de dirección guardados y gestores de contraseñas en los navegadores habituales. Actualiza la implementación mantenida por el plugin y usa nombres neutros generados cuando exista esa opción.

No pidas al visitante que desactive permanentemente el autocompletado.

Repite el ensayo en cada idioma: la traducción modifica etiquetas, orden y pistas utilizadas por el motor de autocompletado.

Revisa el comportamiento accesible

Recorre el formulario con teclado e inspecciona el árbol de accesibilidad. El señuelo no debe recibir foco ni anunciarse como un campo significativo.

Comprueba alto contraste y, cuando proceda, la página sin estilos. Una técnica basada únicamente en desplazar el campo fuera de pantalla aún puede exponerlo a tecnologías de asistencia.

Mantén mensajes claros y accesibles para los controles reales.

Examina las trampas por tiempo

Algunas implementaciones rechazan formularios completados “demasiado rápido”. El autocompletado, un cliente recurrente o un formulario corto pueden ser realmente rápidos; un bot avanzado, en cambio, puede esperar.

Mide tiempos normales y configura un mínimo conservador. Combina esta señal con otras y no la trates como prueba definitiva.

No rechaces a alguien únicamente porque su navegador restauró todos los campos al instante.

Busca caché y formularios duplicados

La caché puede servir un nombre antiguo del honeypot mientras el servidor espera el nuevo. Un constructor visual también puede renderizar dos formularios y hacer que el script limpie solo uno de los señuelos.

Inspecciona el HTML público sin sesión y compara las claves enviadas con la definición actual. Corrige primero la discrepancia y purga después únicamente la caché afectada.

Siempre que sea posible, usa una sola instancia responsive del formulario.

Ajusta solo el control confirmado

Actualiza el plugin y su complemento antispam mediante una ruta compatible y con copia de seguridad. Cambia únicamente el campo, el límite temporal o la integración que provocó el falso positivo.

Mantén activos CAPTCHA, rate limits y validación del servidor cuando no sean responsables. Una defensa por capas permite debilitar una señal dudosa sin abrir la puerta a toda la automatización.

Durante una caída crítica de captación, ofrece una alternativa de contacto monitorizada.

Verifica por separado personas y bots

Después de reparar, prueba escritura manual, autocompletado, gestor de contraseñas, navegación por teclado y un móvil real. Confirma una sola entrada, la notificación prevista y la entrega final.

Luego usa un envío sintético autorizado que rellene la trampa. Debe quedar marcado o rechazado sin activar emails, webhooks ni otras acciones costosas.

Solicita reparación urgente cuando el falso positivo afecta a la accesibilidad o el sistema no facilita un motivo verificable. Comparte claves sintéticas y resultados anonimizados, nunca contenido de visitantes, cookies ni secretos.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia