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

Hosting Dns Containment

Cloudflare sigue sirviendo una página infectada después de limpiarla

Distingue caché y origen, conserva evidencias y purga variantes concretas solo después de limpiar reglas, Workers y servidor.

Los archivos del origen están limpios, pero algunos visitantes todavía ven una redirección, script o página spam. Cloudflare puede conservar una respuesta HTML infectada, un Worker puede alterar el tráfico o un nodo de origen puede seguir comprometido.

Purgarlo todo de inmediato elimina evidencia útil y puede saturar el origen con peticiones sin caché.

Compara las respuestas pública y de origen

Registra cabeceras, hash del cuerpo, estado de caché, Age, centro de datos y hora de la página pública. Usa un método seguro y autorizado para consultar el origen con el host correcto.

No publiques la IP del origen ni evites controles de acceso sin necesidad. La prueba debe respetar la arquitectura del sitio.

Si la respuesta pública está infectada y el origen limpio es consistente, la caché o una transformación se vuelven causas probables.

Comprueba variantes de URL y clave de caché

Prueba URL canónica, barra final, ruta de idioma, condiciones móviles y parámetros de seguimiento inocuos conocidos. Cookies, query strings, reglas de dispositivo y país pueden crear objetos distintos.

Purgar una URL puede dejar una variante envenenada. No configures Cloudflare para ignorar todos los parámetros: búsquedas, idiomas y ecommerce pueden depender de ellos.

Registra exactamente qué condiciones reproducen el problema.

Conserva evidencias antes de purgar

Guarda HTML infectado, cabeceras y URL de recursos externos como evidencia restringida. No ejecutes los scripts copiados.

Exporta reglas de caché, Workers, redirecciones y aplicaciones, además del historial de auditoría reciente de Cloudflare.

Un Worker o regla desconocidos pueden regenerar la respuesta después de vaciar la caché.

Revisa el acceso a Cloudflare

Audita usuarios, tokens API, sesiones, rutas de Workers, Transform Rules, Redirect Rules y aplicaciones. Revoca accesos desconocidos y rota tokens afectados desde un dispositivo limpio.

Usa tokens de privilegio mínimo en lugar de una clave global compartida. Protege el correo del propietario y activa MFA fuerte.

No borres reglas legítimas de seguridad o DNS sin exportarlas y obtener la revisión del responsable.

Purga objetos específicos

Después de limpiar origen y configuración, purga las URL exactas y sus variantes conocidas. Si el HTML infectado es generalizado, puede justificarse una purga amplia planificando la capacidad del origen.

Precarga solo páginas públicas importantes y revisa sus nuevas cabeceras y cuerpo. Excluye carrito, checkout y cuenta de una caché completa inadecuada.

No almacenes indefinidamente páginas de mantenimiento o incidente.

Comprueba otras capas de caché

El hosting, un plugin WordPress, proxy inverso, service worker del navegador y varios orígenes pueden servir contenido antiguo. Traza la respuesta por cada capa.

Vacía recursos generados por constructores o minificación después de limpiar sus fuentes de base y archivos.

Si un origen balanceado continúa infectado, Cloudflare puede alternar respuestas aunque su caché funcione correctamente.

Considera el almacenamiento del navegador

Un visitante previo puede conservar scripts o un service worker infectado aunque Cloudflare ya esté limpio. Prueba con un perfil desechable y revisa workers registrados, Cache Storage y almacenamiento local.

Elimina el worker malicioso de cada origen y caché y publica una actualización limpia o una ruta de desregistro adecuada. No presentes «borrar todos los datos del navegador» como reparación: el servidor debe impedir que el worker antiguo controle nuevas navegaciones.

Verifica el ciclo de actualización para visitantes recurrentes y nuevos.

Verifica globalmente

Prueba regiones representativas, perfiles limpios y las condiciones originales de móvil o referencia. Confirma que no aparece ningún dominio o script antiguo.

Monitoriza cambios de caché, despliegues de Workers y hashes del origen. Revisa por separado Search Console y las alertas de reputación, que no desaparecen inmediatamente.

Cuándo se necesita ayuda especializada

Solicita ayuda si edge y origen discrepan, las reglas no tienen propietario o solo fallan regiones o dispositivos concretos. Envía URL y cabeceras públicas sin tokens.

Una respuesta completa conserva evidencias, limpia origen y configuración y demuestra que cada variante relevante sirve contenido de confianza.

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↗