Casi ningún sitio de pyme lo ataca una persona: lo encuentra un programa que prueba fallas conocidas contra millones de direcciones. Y la falla casi siempre está en un plugin que se instaló hace dos años, que ya nadie mantiene y que sigue activo porque nadie recuerda para qué se puso.
Cuando a una pyme le hackean el sitio, casi nunca hay alguien del otro lado que la haya elegido. Lo que hay es un programa recorriendo internet, probando una lista de fallas ya publicadas contra millones de direcciones, y encontrando la tuya porque tiene la versión vieja de un plugin que alguien instaló hace dos años para poner un formulario. No es personal. Justamente por eso es tan frecuente.
Cada plugin es código ajeno con las llaves de tu casa
Un sitio en WordPress con doce plugins es un sitio con código de doce equipos distintos corriendo con los mismos permisos que el sitio: pueden leer la base de datos, escribir archivos y crear usuarios. Ninguno está encerrado en su propia caja. La seguridad del sitio no es entonces la del plugin mejor hecho, sino la del peor de los doce.
Y no hace falta que el plugin sea malo. Casi todos se escriben con buena intención; lo que pasa es que una galería, un formulario o un constructor visual son piezas de software grandes, y todo software grande tiene fallas que se descubren después de publicarlo. La diferencia entre un plugin sano y uno peligroso no es que tenga fallas: es que haya alguien arreglándolas.
El plugin abandonado es el problema real
El caso típico no es un plugin con un error. Es un plugin cuyo autor lo dejó de mantener hace tres años y que sigue instalado y activo porque nadie se acuerda para qué se puso. Cuando aparece la falla no hay actualización que instalar: no hay nadie del otro lado.
Revisarlo toma diez minutos. Entrá al listado de plugins y mirá, uno por uno, cuándo fue su última actualización y si dice haber sido probado con tu versión de WordPress. Cualquiera que lleve más de un año sin tocarse es candidato a salir. Y salir significa borrarlo, no desactivarlo: un plugin desactivado sigue siendo archivos en el servidor, y buena parte de las fallas conocidas se aprovechan igual sin que esté activo.
Desde afuera se ve lo que tenés instalado
Mucha gente asume que un sitio chico no le interesa a nadie, y es cierto, pero eso no lo protege: los programas que buscan no distinguen entre un sitio chico y uno grande, sólo entre uno vulnerable y uno que no. Y averiguar qué tenés instalado es trivial, porque los plugins dejan su nombre y su versión en el código que sirve la página, en la dirección de sus propios archivos de estilo y en los archivos de texto que traen dentro.
O sea que la lista de tus plugins con sus versiones es pública, y del otro lado hay una lista pública de fallas conocidas por plugin y versión. Cruzar las dos es lo único que hace el programa que te encuentra.
Un sitio comprometido casi nunca se ve comprometido
La pantalla negra que anuncia el hackeo es la minoría de los casos, porque avisar arruina el negocio del que entró. Lo común es mucho más silencioso: páginas nuevas de casinos o farmacias colgando de tu dominio, enlaces inyectados en tus artículos, o una redirección que sólo se dispara cuando la visita viene desde Google y desde un celular. Configurada así, el dueño entra a su sitio todos los días y lo ve perfecto.
Casi siempre te enterás por afuera: Search Console avisa que aparecieron páginas raras, el correo del negocio empieza a rebotar porque el servidor se usó para mandar spam, o Google pone la pantalla roja de sitio peligroso delante de tu dirección. Para cuando eso pasa, ya llevás semanas perdiendo posiciones que costaron meses.
Lo que cuesta de verdad
Limpiar suele ser la parte barata, siempre que haya copias. Lo caro es el resto: los días fuera de línea, el dominio en listas negras de correo —lo que significa que tus cotizaciones dejan de llegar—, el posicionamiento que se cae y tarda meses en volver, y la conversación incómoda si alguien dejó datos personales en un formulario.
Puesto en horas, prevenir esto es un par de horas al mes. No es un problema de presupuesto: es que esas horas no están asignadas a nadie.
Mantenimiento: qué es en concreto
Cuando alguien vende "mantenimiento" sin detallar, conviene pedir esta lista. Es corta y es casi todo lo que hay que hacer:
- Actualizar núcleo, tema y plugins una vez al mes, con copia previa y una revisión rápida del sitio después.
- Mantener al día la versión de PHP en el hosting: una versión sin soporte ya no recibe parches, por más actualizado que esté WordPress.
- Copias automáticas guardadas fuera del mismo servidor, y probar una restauración al menos una vez al año. Una copia que nunca se restauró no es una copia: es una suposición.
- Borrar lo que no se usa: plugins, temas viejos y usuarios de gente que ya no trabaja con vos.
- Un usuario por persona, sin cuenta "admin" compartida, contraseñas distintas y verificación en dos pasos para entrar al panel.
Actualizar rompe cosas, y por eso hay que hacerlo seguido
Acá está la trampa que explica por qué tantos sitios quedan viejos. Alguien actualiza, algo se rompe, y la conclusión que saca es "mejor no tocar nada". El sitio queda entonces cada vez más lejos de la versión actual, y cuanto más lejos queda, más grande es el salto y más probable es que la próxima actualización rompa algo. El miedo a actualizar se alimenta solo.
La salida no es actualizar menos: es actualizar seguido, con copia antes y —si el sitio es importante— con una copia de prueba donde ver el cambio antes de aplicarlo en el real. Saltos chicos y frecuentes fallan poco; saltos de dos años fallan casi siempre.
Menos piezas, menos superficie
La pregunta antes de instalar cualquier cosa es si eso no lo resuelve algo que ya tenés. Cada plugin nuevo es una dependencia que alguien va a tener que mantener durante años, y ese costo no aparece en el momento en que se instala, que es cuando parece gratis.
Es la razón de fondo por la que nosotros construimos a código, con Next.js, y publicamos el sitio como páginas ya armadas: no hay un panel de administración expuesto a internet ni una base de datos donde inyectar nada. Actualizaciones hay igual —el código de terceros existe en todas partes—, pero la superficie que queda expuesta al público es de otro orden. No es magia: son menos piezas.
Si ya pasó
El orden importa: poner el sitio en mantenimiento, cambiar todas las contraseñas —hosting, panel, base de datos y FTP, no sólo la de WordPress—, restaurar la copia anterior al incidente, actualizar todo antes de volver a publicar y recién entonces pedir la revisión en Search Console. Restaurar sin actualizar es dejar la puerta exactamente como estaba, y el mismo programa vuelve a encontrarte en cuestión de días.
Si no sabés cuándo fue la última vez que se actualizó tu sitio, ya tenés la respuesta de en qué estado está. Escribinos y lo revisamos: te decimos qué plugins sobran, qué está sin parche y cuánto trabajo real hay ahí. Es una conversación corta y no cuesta nada.
¿Querés que revisemos tu sitio o armemos uno nuevo?
