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

Visible Symptoms Initial Triage

Google muestra páginas de spam que no existen en WordPress

Rastrea URLs de spam ausentes de WordPress mediante cloaking, reescrituras, inyecciones en base, cachés y payloads eliminados.

Los resultados muestran casino, farmacia o productos falsos bajo tu dominio, pero no hay nada parecido en Entradas o Páginas. El contenido puede generarse solo para rastreadores, salir de reglas de reescritura, vivir fuera de los tipos normales o haber sido eliminado mientras el índice sigue desactualizado.

Distingue una infección activa de un resultado histórico antes de pedir retiradas masivas.

Conserva ejemplos de búsqueda

Registra varias URLs exactas, títulos, snippets y fecha. Usa exportaciones de Search Console cuando existan en vez de abrir cada resultado.

No tomes el recuento aproximado de site:example.com como inventario completo. Sirve para descubrir, pero varía. Evita abrir los destinos en un navegador con sesiones activas; usa un entorno controlado.

Solicita cada URL bajo distintas condiciones

Comprueba estado HTTP y cuerpo como visitante limpio. Después compara una petición autorizada con agente y referrer similares a un buscador.

Puedes encontrar:

  • spam que todavía devuelve 200;
  • portada normal para cualquier ruta;
  • redirección selectiva;
  • payload eliminado con 404 o 410;
  • una respuesta infectada antigua desde CDN.

Cada resultado exige una actuación distinta.

Compara también las cabeceras de caché y el identificador de respuesta entre CDN y origen. Si solo una capa entrega el spam, conserva su clave de caché y hora antes de purgarla; de lo contrario perderás la prueba de por qué Google y el administrador veían contenidos distintos.

Inspecciona reescrituras y rutas

Una petición puede transformarse antes de que WordPress busque una entrada. Revisa .htaccess, Nginx si tienes acceso, redirecciones del hosting, reglas de Cloudflare y archivos PHP inesperados en la raíz.

Busca condiciones basadas en agente, referrer, parámetros o ruta. Conserva las reglas sospechosas antes de retirarlas. No reemplaces .htaccess sin registrar redirecciones legítimas, seguridad e idiomas.

Busca más allá de las entradas

Inspecciona tipos personalizados, papelera, opciones, widgets, menús y tablas de plugins. Revisa administradores inesperados y cambios recientes en la base.

Un plugin inyectado o wp-config.php puede generar la respuesta sin crear una entrada. Compara el núcleo con la versión oficial e investiga mu-plugins desconocidos.

No ejecutes un borrado masivo por palabras como “casino”: podrían aparecer legítimamente en artículos, notas o traducciones.

Determina si la infección es histórica

Si todas las URLs devuelven 404 o 410 limpio, quizá el payload ya no esté activo. Eso no demuestra que la web sea segura. Revisa archivos, base, usuarios, tareas y logs para identificar entrada y persistencia.

Consulta Problemas de seguridad, Acciones manuales, páginas indexadas y rastreo en Search Console. Una infección eliminada puede seguir visible hasta que Google vuelva a rastrear.

No crees páginas vacías para cada URL; convertirías rutas inválidas en más respuestas 200.

Devuelve estados honestos

Una URL de spam eliminada y sin sustituto debe responder normalmente 404 o 410, no redirigir a portada. Un soft 404 global confunde a buscadores y personas.

Conserva rutas legítimas y traducciones. Si una regla maliciosa capturaba un prefijo amplio, prueba páginas válidas bajo ese prefijo antes de retirarla.

Envía sitemaps limpios y utiliza validación o retirada temporal según el caso. Una retirada temporal no limpia malware.

Verifica contenido y recuperación del índice

Después de limpiar payloads y cerrar la entrada, repite las URLs como visitante y rastreador. Confirma que no aparecen patrones nuevos en logs o Search Console.

Monitoriza la indexación durante los siguientes rastreos. La recuperación tarda; evita cambiar repetidamente estados y redirecciones.

Cuándo conviene una limpieza especializada

Solicita evaluación si el spam solo aparece a rastreadores, se crean URLs sin entradas o el índice sigue creciendo. Facilita ejemplos públicos y capturas de Search Console, nunca contraseñas.

El trabajo debe demostrar si el contenido sigue activo, eliminar persistencia en código y base, devolver estados correctos y recuperar búsqueda sin borrar material legítimo.

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