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

Errors & Diagnosis

Pharma hack en WordPress: eliminar páginas ocultas de spam farmacéutico y cloaking

Pharma spam generalmente combina páginas generadas, camuflaje y persistencia. Limpie el generador y la huella del índice, no solo el texto visible.

Qué importa primero: Un hack farmacéutico inyecta o genera páginas sobre medicamentos, a menudo mostrando diferentes contenidos para buscar a los rastreadores y visitantes normales.El incidente incluye la carga útil, persistencia, punto de entrada y URLs indexado.

Qué indica realmente este síntoma

Los resultados de búsqueda pueden permanecer contaminados después de que el sitio visible se vea normal. Es necesario mapear dónde se genera el spam, qué lo recrea y qué URLs Google ha descubierto.

Recopila pruebas antes de cambiar nada

  • La exportación afectó a URLs y los patrones de consulta de la consola de búsqueda.
  • Compara las respuestas del rastreador y del navegador normal para URLs representativo.
  • Busca archivos, opciones de base de datos, publicaciones, reglas de reescritura, mu-plugins y cron.
  • Registrar usuarios inesperados, archivos modificados y componentes vulnerables.

Causas más habituales

  • Inyección de la base de datos: Los títulos, enlaces o plantillas Spam se almacenan en publicaciones u opciones.
  • Encapsulado dinámico: PHP genera contenido farmacológico solo para referres de búsqueda o agentes de usuario de rastreadores.
  • Generador de reescritura: Las reglas convierten las rutas de palabras clave arbitrarias en respuestas indexables.
  • puerta trasera persistente: Una tarea programada o un cargador oculto restaura spam eliminado.

Secuencia segura de diagnóstico y reparación

  1. Preservar una base de datos y una instantánea de archivo antes de limpiar.
  2. Retire el generador y la persistencia, luego reemplace el código comprometido con paquetes limpios.
  3. Cierre el punto de entrada y gire WordPress, servidoring, SFTP y credenciales de la base de datos.
  4. Devuelve las respuestas correctas 404 o 410 para spam URLs y limpia el sitemap.

Cómo distinguir entre las causas probables

No trates Inyección de la base de datos y Encapsulado dinámico como causas equivalentes. Los títulos, enlaces o plantillas Spam se almacenan en publicaciones u opciones. En cambio, pHP genera contenido farmacológico solo para referres de búsqueda o agentes de usuario de rastreadores. Para distinguirlas, usa estas dos comprobaciones: La exportación afectó a URLs y los patrones de consulta de la consola de búsqueda; y compara las respuestas del rastreador y del navegador normal para URLs representativo. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Preservar una base de datos y una instantánea de archivo antes de limpiar— o si debes conservar el estado actual y ampliar la investigación.

En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.

Qué no debes hacer

No Solicita una revisión de búsqueda hasta que la inspección en vivo esté limpia bajo las mismas condiciones de rastreo que revelaron el spam.

Cómo verificar la reparación

  • No se generan nuevos fármacos URLs.
  • El representante spam URLs devuelve el estado previsto y está ausente de los mapas de sitio.
  • La integridad del archivo, los usuarios y cron permanecen establas a través de varios ciclos.

Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.

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