Recuperación SEO tras un hackeo en WordPress
El sitio ya está limpio. Pagaste la limpieza, cambiaste las contraseñas, actualizaste todo. Y cuando buscas tu marca en Google siguen apareciendo cuarenta páginas de tu dominio con texto en japonés, o con nombres de medicamentos, o con cadenas de caracteres que no significan nada.
Eso no es que la limpieza fallara. Es que limpiar el sitio y limpiar el índice de Google son dos trabajos distintos, y el segundo casi nunca se incluye en el primero.
Cuando entraron, Google ya había rastreado lo que inyectaron. Esas URLs están en su índice, y van a seguir ahí hasta que Google las vuelva a visitar y encuentre que ya no existen. Si nadie le da prisa, eso tarda semanas o meses. Y mientras tarda, tu marca sale en los resultados asociada a spam, el aviso de Safe Browsing puede seguir activo en Chrome, y las posiciones que tenías no vuelven solas.
Qué tipo de hackeo SEO tienes
Hay media docena de patrones y cada uno se limpia distinto. Busca tu caso:
| Lo que ves en Google | Qué es | Cómo se confirma |
|---|---|---|
| Páginas con texto sin sentido, palabras amontonadas, URLs en carpetas de caracteres aleatorios, a veces en varios idiomas | Hackeo de galimatías. Genera cientos o miles de páginas rellenas de palabras clave; quien entra se va redirigido a otro sitio | site:tudominio.com y recorrer varias páginas de resultados. No confíes en un 404: usan encubrimiento, así que hay que comprobar con Inspección de URL para ver lo que ve Google |
| Páginas en japonés con nombres de productos de marca | Hackeo de palabras clave japonesas. Variante de lo mismo, orientada a tiendas falsas | Igual: site: más Inspección de URL. Suele añadirse una cuenta de usuario propia en Search Console |
| El sitio se ve bien para ti y mal para Google | Encubrimiento. El código detecta al rastreador y le sirve otro contenido | Inspección de URL → ver página rastreada. Es la única forma: tu navegador te va a mentir |
| Los visitantes que llegan desde Google acaban en otro sitio, pero si escribes la URL a mano funciona | Redirección condicional. Se activa según el referente, el dispositivo o la geolocalización | Probar desde móvil con ? en la URL, y revisar .htaccess y los archivos del tema |
| Tus artículos de siempre tienen enlaces a sitios que no pusiste | Inyección de enlaces en contenido legítimo. El más dañino a largo plazo y el que menos se detecta | Búsqueda en la base de datos por dominios externos en post_content |
| Miles de comentarios o usuarios nuevos con perfiles que enlazan fuera | Spam de registro. Suele ser la puerta por la que volverán | Tabla de usuarios por fecha de registro; comentarios pendientes |
| Chrome avisa "sitio engañoso" o "contiene software malicioso" | Safe Browsing te marcó. Esto es lo más urgente: el navegador bloquea antes de que nadie te vea | Search Console → Problemas de seguridad |
Si tienes dos o tres de estos a la vez, es lo normal. Quien entra rara vez hace una sola cosa.
Mándame tu dominio por WhatsApp. Hago el site: y la Inspección de URL yo, y te digo cuál de estos siete casos es el tuyo antes de que contrates nada.
Lo que cambió en seguridad de WordPress en 2026
Estos números explican por qué esto te pasó a ti aunque tuvieras el sitio actualizado, y por qué la prevención de siempre ya no basta. En 2025 se reportaron 11,334 vulnerabilidades nuevas en el ecosistema de WordPress, un 42 % más que el año anterior. De ellas:
Y dos tendencias que cambian directamente cómo se limpia:
Cada vez más sigiloso: muestra contenido limpio a los escáneres y usa código residente en memoria para volver a infectar archivos ya limpiados. Esa es la razón por la que un escaneo que sale "sin amenazas" no demuestra nada, y la razón por la que un sitio se puede reinfectar tres días después de la limpieza.
Los scripts de subida de archivos crecieron desde mediados de 2025: primero se planta un cargador discreto, y la carga real llega después. Las subidas maliciosas se concentran en el último trimestre del año, cuando hay menos gente de sistemas trabajando.
Nada de esto es un argumento de venta: es el motivo por el que la fase de contención va antes que la de limpieza en el procedimiento de abajo.
Por qué limpiar el sitio no limpia Google
En el momento en que se borra el archivo inyectado, esa URL deja de existir. Para ti, el problema terminó hoy.
Para que se actualice tiene que volver a pasar. Google no sabe que borraste nada hasta que vuelve a pedir esa URL, y el orden en que decide volver depende de cuánta importancia le dé a cada página. Las miles de URLs de spam que te inyectaron están, por definición, al final de esa cola.
Por eso el trabajo de limpieza de índice consiste en tres cosas que no tienen nada que ver con borrar archivos:
Responder lo correcto
Que esas URLs devuelvan un código que diga "esto se fue y no vuelve" —un 410— en lugar de un 404 genérico o, peor, de un 200 con una página de "no encontrado" maquetada, que Google lee como contenido real.
Darle la lista
Un sitemap temporal con las URLs inyectadas suena contraintuitivo y es la forma más eficaz de que las rastree pronto y las descarte. Se publica, se usa y se retira.
Pedir la revisión de seguridad, una vez y bien
Y esto tiene reglas, que van abajo.
El procedimiento
| Fase | Qué se hace | Qué recibes |
|---|---|---|
| 1 · Contención | Cerrar la puerta antes de limpiar nada: identificar el vector, revocar accesos, revisar usuarios añadidos en Search Console y en WordPress, cambiar claves de base de datos y sal de cifrado | Confirmación de que dejó de entrar y de que no hay cuentas ajenas con permisos |
| 2 · Inventario de daño indexado | site: exhaustivo, cobertura de Search Console, Inspección de URL en muestra, búsqueda en base de datos de enlaces inyectados en contenido legítimo | Lista completa de URLs inyectadas indexadas, con número exacto, y lista de artículos legítimos contaminados |
| 3 · Limpieza con verificación | Reinstalación de núcleo, tema y plugins; revisión de .htaccess; búsqueda de PHP sospechoso por fecha, tamaño y funciones de ofuscación; limpieza de enlaces inyectados en la base de datos | Registro de lo que se encontró y se quitó, archivo por archivo |
| 4 · Limpieza del índice | Códigos 410 en lo inyectado, sitemap temporal de desindexación, eliminaciones puntuales de Search Console donde urja, solicitud de revisión de seguridad | Calendario de desindexación y la solicitud de revisión documentada |
| 5 · Recuperación de posiciones | Reindexación priorizada de las URLs que sí tenían tráfico, revisión de qué posiciones volvieron y cuáles no, análisis del perfil de enlaces si hubo inyección masiva | Comparativa de posiciones contra el periodo previo al incidente |
| 6 · Vigilancia de tres meses | Monitoreo de reinfección, cobertura, estado de seguridad y posiciones. Es la fase que detecta el malware residente que sobrevivió | Informe mensual con desviaciones |
La fase 6 no es un añadido comercial. Con malware que reinfecta desde memoria y ataques en varias etapas, un sitio que lleva tres días limpio no está limpio: está sin síntomas.
No sabes si tu sitio sigue infectado. Pide el diagnóstico técnico: sales con el inventario de URLs inyectadas indexadas, el estado real del servidor y la lista de artículos legítimos contaminados. Por escrito y es tuyo, lo repares con quien lo repares.
Lo que no funciona, y se intenta siempre
Bloquear las URLs de spam en robots.txt
Es el error más común y es exactamente al revés: si Google no puede rastrearlas, no puede ver que desaparecieron, así que se quedan en el índice más tiempo. Google recomienda expresamente no usar robots.txt para quitar una página de los resultados.
Usar la herramienta de Eliminaciones como solución
Oculta una URL de los resultados en aproximadamente un día, y la ocultación dura unos seis meses. Es un parche excelente para ganar tiempo con las diez URLs que más te avergüenzan. No desindexa nada de forma permanente, y si se usa como único remedio, medio año después vuelve todo.
Pedir la revisión de seguridad con el sitio a medio limpiar
Google dice que hay que arreglar el problema en todo el sitio, y que arreglar solo algunas páginas no devuelve una parte proporcional de los resultados. Una revisión rechazada cuesta más que esperar dos días a tenerlo todo listo.
Reenviar la solicitud porque tarda
La documentación de Google avisa literalmente de esto: la revisión tarda de unos días a unas semanas, y reenviar antes de tener respuesta puede alargar el proceso y marcarte como reincidente. Hay que aguantarse.
Limpiar una sola instalación de un servidor que aloja varias
Entre sitios que comparten servidor, el malware se mueve. Limpiar uno y dejar los vecinos es ponerle fecha a la reinfección, no evitarla, y por eso no acepto el trabajo a medias: o entran todas las instalaciones del servidor, o no puedo responder por ninguna. No es una condición comercial —es que no puedo garantizar algo que el vecino va a deshacer el jueves—. Es el mismo criterio de admisión de soporte y mantenimiento.
Confiar en un escaneo que sale limpio
Con el encubrimiento que usa el malware actual, un escáner puede ver contenido limpio donde el rastreador de Google ve spam. La verificación válida es la Inspección de URL, que muestra lo que ve Google, no lo que ve tu navegador.
Cuánto tarda y de qué depende
No doy plazos de recuperación porque no los decido yo. Lo que sí puedo decirte con honestidad es de qué depende:
Depende de cuántas URLs sean y de con qué frecuencia Google rastrea tu dominio. Decenas se resuelven en días. Miles, en semanas. Decenas de miles, en meses, y ahí el trabajo consiste en priorizar para que lo que desaparezca primero sea lo que más daño hace a tu marca.
Se quita cuando Google aprueba la revisión: de unos días a unas semanas según su propia documentación. Esta es la parte más urgente, porque mientras está activo, Chrome bloquea a tus visitantes antes de que vean tu sitio.
Son lo último y lo menos predecible. Si tus páginas legítimas conservaron su autoridad, suelen volver conforme el spam desaparece. Si hubo inyección masiva de enlaces salientes durante meses, la recuperación es más lenta y puede ser parcial.
Contención, limpieza, inventario, códigos de respuesta, sitemap y solicitud: sí lleva plazo, y lo doy por escrito antes de empezar.
Aquí va el caso del periódico digital con miles de entradas, por el número de URLs inyectadas y el tiempo real de desindexación. Si no se autoriza el nombre, va en anónimo con la cifra y el sector.
Lo que viene en 2027
Los atacantes van a usar IA para encontrar y explotar vulnerabilidades de forma más autónoma. Con una mediana de cinco horas hasta la explotación masiva en 2025, la ventana entre que se publica un fallo y se ataca en serie ya es más corta que el ciclo de actualización de la mayoría de los sitios. La conclusión práctica no es alarmista, es aritmética: la respuesta tiene que estar preparada antes del incidente, porque reaccionar en cinco horas no es realista para nadie.
La superficie de ataque se amplía más allá del núcleo, los plugins y los temas. Se espera que incluya plugins de código propio y paquetes de JavaScript y PHP, impulsado por el desarrollo asistido por IA. Es decir: el código a medida que antes era la zona segura —porque nadie lo conocía— deja de serlo cuando una máquina puede leerlo y buscarle el hueco. Si tienes desarrollo a medida, esto te toca directamente.
Y hay un cambio normativo en camino: se espera que la regulación europea obligue a los plugins comerciales de WordPress a tener un programa de divulgación de vulnerabilidades. Si se cumple, eso mejora la información disponible para todos, incluidos los sitios mexicanos que usan esos plugins. No hay fecha pública confirmada, así que lo digo como lo que es: una expectativa, no un calendario.
Preguntas frecuentes
Porque el índice de Google no se limpió con él. Si al buscar tu marca siguen apareciendo URLs que no escribiste, ese es el trabajo pendiente, y no se resuelve solo en un plazo razonable.
No con un botón, y quien te diga que sí está vendiendo algo que no existe. Lo que escala es el código de respuesta correcto, un sitemap temporal de desindexación y tiempo. La herramienta de Eliminaciones es URL por URL y es temporal.
Las dos cosas, en ese orden, porque no sirve de nada limpiar el índice de un sitio que sigue generando spam. Si ya pagaste la limpieza a otro proveedor, lo verifico antes de empezar: si está bien hecha, no la cobro dos veces y arrancamos en la fase 2.
Eso es lo primero de todo, porque bloquea a tus visitantes antes de que lleguen. Hay que limpiar el sitio completo, verificarlo y pedir la revisión en Problemas de seguridad. Tarda de unos días a unas semanas y no se puede acelerar reenviando la solicitud.
Es posible, pero en 2025 el 91 % de las vulnerabilidades nuevas estaban en plugins y el 46 % no tenían parche el día en que se publicaron. Así que estadísticamente lo más probable es que entraran por un plugin, no por tu contraseña. Parte de la fase 1 es averiguar cuál, porque si no se identifica, vuelven.
Se puede recuperar, con dos diferencias: hay más URLs acumuladas en el índice y es más probable que haya enlaces inyectados en artículos legítimos, que es el daño que más tarda en revertirse. El diagnóstico dice cuánto es recuperable antes de que decidas gastar.
Casi nunca. Hace falta si el vector fue el propio servidor o si el proveedor no da logs ni aislamiento entre sitios. Lo digo en el diagnóstico, con el motivo, y no vendo el hosting: te digo qué necesitas y lo contratas donde quieras.
Elige por dónde entrar
Google muestra páginas que no escribiste y necesitas saber el alcance. Mándame el dominio por WhatsApp. Hago el site: y la Inspección de URL y te digo cuántas URLs inyectadas hay indexadas ahora mismo.
No sabes si el sitio sigue infectado ni cuánto daño quedó. El diagnóstico técnico se paga y se entrega: inventario de URLs inyectadas, estado real del servidor, artículos legítimos contaminados y qué parte del tráfico es recuperable.
Pedir el diagnóstico técnicoYa está limpio y quieres el presupuesto de la recuperación. Dime cuántas URLs hay en el índice, de qué fecha es el incidente y qué se hizo ya. Te mando propuesta con fases y plazos de la parte que depende de mí.
Solicitar propuestaÚltima revisión: octubre de 2026.