Si alguna vez te has preguntado por qué tu WordPress va lento sin que el servidor tenga la culpa, la respuesta probablemente vive en la base de datos. Concretamente, en una tabla llamada wp_options que, con el tiempo, se convierte en el mayor vertedero digital de tu instalación. No hace falta ser administrador de sistemas para intuir que algo no funciona bien cuando una web que debería cargar en un segundo tarda tres. El problema rara vez está donde el usuario mira.
La wp_options es la tabla donde WordPress guarda su configuración esencial: la URL del sitio, el nombre, los ajustes del tema activo, las opciones de cada plugin instalado. Hasta aquí, todo tiene sentido. El problema es que también guarda, silenciosamente, los datos de todos los plugins que alguna vez estuvieron instalados. Y cuando digo todos, digo todos. El plugin de contacto que probaste en 2021, el de analíticas que desactivaste a los tres días, el de caché que reemplazaste por otro mejor. Todos dejaron su huella. Casi ninguno la borró.
Los transients son otro actor en este drama. Son datos temporales que WordPress y los plugins almacenan en wp_options para cachear resultados y evitar consultas repetidas. Tienen fecha de caducidad, en teoría. En la práctica, caducan, pero no desaparecen: se quedan ahí como cadáveres que nadie recoge, acumulándose fila a fila hasta que la tabla empieza a pesar de forma absurda. Una instalación medianamente activa puede tener miles de transients caducados sin que nadie lo haya notado jamás.
Y luego están las tablas huérfanas. Porque el problema no se queda en wp_options. Muchos plugins crean sus propias tablas al instalarse: wp_migraciones_log, wp_contactform_submissions, wp_analytics_events. Cuando el plugin se desinstala, esas tablas se quedan. Nadie las reclama, nadie las borra. Pueden contener desde cientos hasta decenas de miles de registros que llevan años sin tocarse. Es espacio que ocupa, es tiempo que se pierde en los backups, son consultas que el motor de base de datos tiene que ignorar cada vez que hace su trabajo.
El usuario no tiene la culpa. Hace clic en «eliminar plugin» y confía en que WordPress y el plugin han llegado a algún acuerdo para dejar las cosas como estaban. Es una confianza razonable. Pero no siempre se cumple. La cultura de desarrollo de plugins ha priorizado históricamente que la instalación sea sencilla y rápida. La desinstalación limpia es, con demasiada frecuencia, una reflexión tardía o directamente inexistente. El resultado es que el usuario paga el precio de una decisión que nunca fue suya.
Desde el punto de vista técnico, hay dos hooks en WordPress que deberían ser los protagonistas de cualquier desinstalación responsable: register_uninstall_hook y el archivo uninstall.php. Ambos permiten ejecutar código específico cuando el usuario elimina un plugin desde el panel de administración. Borrar opciones, eliminar tablas propias, limpiar transients: todo eso es perfectamente posible y está documentado. El problema no es falta de herramientas. Es falta de voluntad, o de tiempo, o de que nadie se ha puesto firme al respecto.
En ROBOTSTXT decidimos desde el principio que nuestros plugins tendrían que irse bien. Cada plugin que publicamos incluye una opción en su configuración: ¿quieres que al desinstalar se eliminen todos los datos de la base de datos? Por defecto, viene desactivada. Si estás probando, si solo quieres desactivarlo temporalmente, no pasa nada: tus datos siguen ahí para cuando vuelvas. Pero si ya sabes que es un adiós definitivo, activas esa casilla y el plugin se encarga de dejarlo todo limpio antes de irse. Sin rastros, sin tablas huérfanas, sin opciones abandonadas.
Esta decisión no es espectacular. No es el tipo de funcionalidad que aparece en la lista de características del plugin ni la que convence a nadie en una comparativa. Pero es honesta. Le devuelve al administrador el control sobre su propia base de datos. No le imponemos una limpieza automática que podría borrar datos que quería conservar, pero tampoco le condenamos a arrastrar basura de por vida. Le damos la elección, que es exactamente lo que debería haber hecho el ecosistema de plugins desde el principio.
Si administras WordPress, ya sea el tuyo propio o el de tus clientes, date una vuelta de vez en cuando por la base de datos. Abre el cliente SQL que prefieras, filtra wp_options por autoload = yes y observa cuántas de esas filas corresponden a plugins que llevan meses sin estar instalados. Busca tablas que no reconoces. Cuenta los transients caducados. Lo que vas a encontrar probablemente te va a sorprender, y no para bien. La buena noticia es que, una vez identificado el problema, limpiar es técnicamente sencillo.
La lentitud de un WordPress no siempre viene del servidor. A veces viene de años de instalaciones y desinstalaciones que nadie gestionó con cuidado. La base de datos es la memoria de tu sitio, y como cualquier memoria, necesita que de vez en cuando alguien decida qué merece quedarse y qué ya cumplió su función. Los plugins deberían nacer con esa responsabilidad incorporada. Mientras eso no sea la norma, los que administramos sistemas tenemos que compensar con criterio y, de vez en cuando, con una buena sesión de limpieza.
Deja una respuesta