Caso tercero: WordPress + Elementor

Caso tercero: WordPress + Elementor

Y otra vez la mañana de este maldito lunes. Esta vez noté el hackeo tarde: entro en Google Console y veo un aumento de 30,000 páginas, y en sitemap.xml — enlaces a páginas con redirecciones.

Al mismo tiempo, el sitio en sí está disponible, y Direct sigue trayendo solicitudes. Como la vez anterior, para los usuarios comunes el hecho del hackeo simplemente no era visible.

Cuál fue la dificultad:

Si en el caso de Django podía cerrar del índice una carpeta entera, aquí no había opciones — las rutas de las páginas hackeadas comenzaban justo después de la raíz del sitio (site.ru/…)

Mis acciones:

Encontré un programador para la limpieza.

Mientras él trabajaba, a través de functions.php configuré para que todas las páginas 404 dieran una respuesta 410 (señal al buscador de que la página ha sido eliminada permanentemente).

A través de bots de indexación envié a rastrear las páginas reales del sitio (en ese momento todo el sitio ya había caído del índice de Google).

Resultado:

El sitio recuperó posiciones bastante rápido. Queda mucho trabajo por hacer, pero para las principales consultas el resultado ya es bueno.

Qué más planeaba (pero pospuse):

Pensaba hacer un mapa .xml separado con las páginas hackeadas y enviarlo para un nuevo rastreo, para que los bots vieran más rápido la respuesta 410 y eliminaran la basura del índice. Pero como el esquema no es el más seguro, y las posiciones ya se están recuperando, decidí posponerlo.

Esencia: Todos los sitios tarde o temprano serán hackeados a través de módulos o vulnerabilidades, si alguien lo necesita. Lo principal es tener al menos alguna idea de qué hacer y entender que cualquier problema es solucionable.