Cuando la lista de plugins es más larga que el mapa del sitio
El exceso de plugins (plugin sprawl) ocurre cuando cada nuevo requisito recibe su propio plugin hasta que la pila domina el sitio y no al revés. En builds asistidos por IA el patrón se acelera: el asistente responde a «añade un carrusel de testimonios», «rastrea conversiones» y «arregla el menú móvil» con tres comandos de instalación separados, a menudo en una sola sesión, sin comprobar qué ya está activo. En wp-admin todo parece normal. El TTFB, el tiempo de carga del admin y la cola de actualizaciones de seguridad cuentan otra historia. Esta guía es un diagnóstico orientado al problema para propietarios y desarrolladores que miran una pantalla de plugins que se desplaza durante páginas, con cifras anonimizadas antes/después de un rescate reciente y un método de triaje que puedes ejecutar antes de escalar a un encargo completo.
Si el build también incluyó PHP personalizado de un asistente de IA, combina esta auditoría con la auditoría de código de plugins WordPress generado por IA. Cuando el exceso, el código personalizado y la pérdida de tráfico se suman, el trabajo encaja en el rescate de webs hechas por IA.
El caso anonimizado: 38 plugins, 1,47 s de TTFB
Un sitio de servicios B2B (formación y consultoría para industrias reguladas en el mercado español) llegó tras un stakeholder interno que ejecutó Lighthouse y preguntó por qué «WordPress iba lento». El sitio se montó en unas tres semanas con Cursor y ChatGPT: estructura de páginas, borradores de copy, flujos de formularios y elecciones típicas de «instala algo para eso» del directorio de plugins. Nadie era dueño de la lista de plugins.
| Métrica | Antes de consolidar | Tras consolidar |
|---|---|---|
| Plugins activos | 38 | 21 |
| Mediana TTFB sin caché (home) | 1,47 s | 0,68 s |
| Consultas a la base de datos (home, sin sesión) | 187 | 94 |
| Peticiones HTTP en el first paint | 43 | 28 |
| Plugins personalizados generados por IA | 3 | 1 (auditado, conservado) |
| Carga de la pantalla de plugins en wp-admin | 4,2 s | 1,8 s |
El hosting no cambió: un VPS de 2 vCPU con un proveedor ibérico, PHP 8.2, sin object cache al inicio. Añadimos Redis tras el pase de plugins, lo que recortó otros ~120 ms de TTFB, pero la mayor parte de la mejora vino de eliminar y fusionar plugins, no de upgrades de infraestructura.
La primera reacción del cliente fue predecible: «Solo añadimos lo que necesitábamos». Así se presenta el exceso. Cada instalación individual tenía un motivo plausible. El coste era acumulativo.
Cómo los builds con IA llegan a 40 plugins más rápido que los manuales
El exceso manual suele crecer durante meses: un freelance añade un slider, marketing un popup, alguien instala un segundo plugin SEO «solo para probar». El exceso asistido por IA comprime el mismo comportamiento en días porque el modelo optimiza la finalización plausible, no la coherencia de la pila.
Patrones recurrentes en intakes de rescate:
- Un prompt, un plugin. El asistente no dice «extiende tu plugin de formularios existente». Devuelve un slug.
- Sin memoria de inventario. La sesión dos no sabe que la sesión uno instaló Rank Math; la cuatro recomienda Yoast para «mejor schema».
- Apilamiento de tutoriales. Posts y transcripciones de YouTube con los que se entrenó el modelo recomiendan listas de «mejores plugins para X». El build hereda la lista entera.
- Código personalizado más exceso comercial. El mismo asistente que sugirió doce plugins también generó tres plugins personalizados pequeños como «arreglos rápidos», añadiendo PHP sin mantenimiento sobre dependencias sin mantenimiento.
- Plugins optimizadores como tiritas. Cuando sube el TTFB, el siguiente prompt es «instala un plugin de caché», a veces sin desactivar el primero.
Nada de esto requiere mala fe ni incompetencia. Requiere un hueco de proceso: nadie con responsabilidad de arquitectura WordPress revisó la pila antes del lanzamiento.
Ocho categorías que sobresalen en builds con IA
En el sitio anonimizado, estos ocho cubos representaban 31 de los 38 plugins. Tu lista variará, pero las categorías se repiten en rescates.
1. Herramientas SEO y schema duplicadas
Dos plugins SEO activos. Ambos emitían schema. Ambos enganchados a wp_head. Uno quedó de una migración del hosting anterior, otro de la semana del build con IA. Conserva uno. Fusiona ajustes manualmente; no confíes ciegamente en importadores automáticos.
2. Varios constructores de formularios
Contact Form 7, un constructor drag-and-drop de un prompt y un plugin ligero de formulario modal capturaban leads en bandejas distintas. La consolidación movió tres formularios a un solo constructor y eliminó el resto.
3. Plugins de caché y optimización en competencia
Un plugin de caché a nivel de hosting y un segundo «speed booster» minificaban scripts a la vez. Generaron JavaScript roto intermitente en la página de precios. Nunca ejecutes dos capas completas de caché HTML. Elige un sistema y configúralo.
4. Exceso de analítica y píxeles
Conector GA, plugin de píxel de Facebook, plugin de tag de LinkedIn Insight, prueba de heatmap y GTM insertado dos veces (una por plugin, otra por snippet en cabecera). La medición no mejoró. El peso de peticiones sí.
5. Page builder y paquetes de addons
Elementor más paquete comercial de addons más slider legacy dejado «por si acaso». La home usaba el builder; las páginas internas no. Exportamos secciones estáticas donde fue posible y eliminamos el slider por completo.
6. Duplicados de seguridad y mantenimiento
Dos limitadores de login, un plugin gestor de archivos (eliminado al instante) y un «limpiador de base de datos» que corría en cada carga del admin. La seguridad pertenece a una pila deliberada, no a tres plugins solapados.
7. Herramientas de contenido e imagen con IA
Un plugin escritor con IA y una herramienta de alt automático añadían cron jobs en admin y llamadas API salientes. Los flujos editoriales pasaron al proceso de redacción; los plugins salieron.
8. mu-plugins personalizados de IA
Tres archivos en mu-plugins/ de PHP pegado: un manejador de redirecciones, un «arreglo» de permisos REST y un ajuste de columna en admin. Un plugin de redirección duplicaba reglas de .htaccess. Un tweak REST desactivó una integración que marketing usaba a diario. Tras la revisión de seguridad, conservamos el ajuste de columna como código revisado en un único archivo mantenido y eliminamos los otros dos.
Autodiagnóstico: señales de que estás muy abajo en plugins
Ejecuta esto antes de instalar otro optimizador.
| Señal | Qué suele significar |
|---|---|
| La pantalla de plugins tarda más de 3 s en cargar | Cientos de hooks registrándose en admin_init |
| TTFB por encima de 1,2 s sin caché con contenido ligero | Exceso de consultas, opciones autoload, salida duplicada en head |
| Errores JavaScript solo en algunas páginas | Dos plugins minify/caché reescriben assets de forma distinta |
| El contador de actualizaciones se mantiene por encima de 20 | Plugins abandonados aún activos |
| Query Monitor muestra 150+ consultas en una página simple | Metadatos, entradas relacionadas y plugins de analítica consultando por vista |
| Un escaneo de seguridad marca plugins que no reconoces | Instalaciones de IA o subcontratistas sin documentar |
Instala Query Monitor en staging (no en producción si la política lo prohíbe), carga la home sin sesión y captura el stack de consultas. Esa sola vista a menudo avergüenza lo suficiente como para que alguien asuma responsabilidad de la pila.
Triaje: conservar, fusionar, sustituir, eliminar
Usamos un registro de cuatro columnas en cada rescate por exceso. Cada plugin activo recibe exactamente una etiqueta.
Conservar - único dueño de una función, mantenido, sin solapamiento. Ejemplo: el único plugin SEO tras fusionar ajustes.
Fusionar - dos plugins con trabajos adyacentes que una herramienta mantenida puede cubrir. Ejemplo: tres plugins de formularios en uno.
Sustituir - el trabajo del plugin es válido pero la implementación es pesada; sustituir por unas líneas en child theme o un patrón de bloque. Ejemplo: un plugin de entradas relacionadas con WP_Query en cada vista sustituido por un bloque curado.
Eliminar - abandonado, duplicado, peligroso o sin uso. Plugins gestor de archivos, pruebas SEO de hello-world y herramientas de debug «temporales» van aquí.
Trabaja en lotes de cinco a ocho plugins como máximo. Desactiva, prueba checkout y formularios, mide TTFB, luego borra. Los borrados masivos son cómo se rompe producción un viernes.
En el sitio anonimizado la división fue así:
- Conservar: 21 plugins tras consolidar (un SEO, unos formularios, una caché, una suite de seguridad)
- Fusionar: 9 plugins absorbidos por herramientas conservadas
- Sustituir: 4 trabajos de plugin movidos a código de tema o bloques
- Eliminar: 8 plugins borrados (incluidos 2 abandonados, 1 gestor de archivos, 1 caché duplicada)
Los plugins personalizados de IA siguen siendo plugins
Los equipos suelen contar solo plugins del directorio y olvidan mu-plugins o plugins de «code snippets» que inyectan PHP. Los asistentes de IA adoran generarlos porque parece más rápido que enseñar estructura correcta de plugin.
Trata cada archivo personalizado como código de terceros:
- Busca guards
ABSPATH, nonces y$wpdb->prepare() - Comprueba si la funcionalidad duplica un plugin existente
- Mueve el código que sobrevive a control de versiones, no a un pegamento en wp-admin
Si encuentras nonces ausentes y SQL concatenado, deja de desinstalar plugins comerciales hasta acotar el código personalizado. PHP personalizado malo más una pila comercial que se reduce puede exponer endpoints que nadie recordaba.
Flujo de consolidación en staging
- Congela nuevas instalaciones. Ninguna respuesta de plugin hasta que exista el registro.
- Exporta la lista activa a una hoja: slug, versión, fecha de última actualización, trabajo declarado, trabajo real.
- Marca solapamientos en SEO, caché, formularios, analítica y seguridad primero.
- Desactiva duplicados en staging, vacía todas las cachés, prueba rutas de conversión principales.
- Mide TTFB y recuento de consultas en home, landing más pesada y página de gracias de checkout/contacto.
- Borra en lotes pequeños, mide de nuevo tras cada lote.
- Documenta la pila final en el README del proyecto o entrega al cliente para que la próxima sesión de IA tenga inventario que leer.
El precio del trabajo de rescate es siempre individual porque el recuento de plugins es solo una variable. El hinchamiento de base de datos, el código personalizado de IA y el nivel de tráfico pesan igual que el número en wp-admin.
Qué no hacer
- No instales un plugin «gestor de plugins» para arreglar el exceso. Añades otro plugin.
- No actives dos cachés de página completa «por si acaso».
- No dejes que un asistente de IA genere un script de limpieza que borre filas en masa en
wp_optionssin copia de seguridad y revisión diff. - No asumas que los plugins desactivados son inofensivos. Algunos siguen cargando código en
initen estados raros; borra tras verificar. - No omitas pruebas de formularios y checkout porque «es solo un blog». En el caso anonimizado, el JavaScript roto estaba en la página de precios, no en el índice del blog.
Cuándo escalar a rescate
La limpieza incremental funciona cuando los solapamientos son obvios, el código personalizado es mínimo y alguien técnico controla staging. Escala a un rescate de webs hechas por IA formal cuando:
- Los plugins activos se mantienen por encima de la treintena media tras un primer pase
- Varios plugins personalizados de IA tocan autenticación, subidas o SQL
- El TTFB sin caché permanece por encima de ~1 s tras quitar caché y SEO duplicados
- El negocio no puede permitirse un formulario o flujo de pago roto durante borrados sin guía
- Escaneos de seguridad muestran CVE conocidos en plugins abandonados que nadie actualizará
Rescate no es un eufemismo de reconstrucción. En el caso anterior, 17 plugins abandonaron la pila y el sitio mantuvo el mismo tema y tier de hosting. La entrega es un registro medido, no un pitch de venta para una plataforma nueva.
Medir el éxito más allá del recuento de plugins
El recuento de plugins es un proxy. Rastrea métricas que reflejen la experiencia de usuario:
| Métrica | Cómo medimos | Dirección objetivo |
|---|---|---|
| Mediana TTFB sin caché | curl o WebPageTest, 5 ejecuciones, mediana | A la baja tras cada lote |
| Consultas a la base por vista | Query Monitor | Por debajo de ~120 en páginas de contenido |
| Tamaño de opciones autoload | wp option list --autoload=on o Query Monitor | Estable o a la baja |
| Pantalla de plugins en admin | Pestaña rendimiento del navegador | Por debajo de 2 s |
| Tiempo hasta parche de seguridad | Días desde publicación CVE hasta actualización | Un dueño, una cola |
Tras consolidar, establece un presupuesto de plugins: para esta clase de sitio, ningún plugin nuevo sin retirar o fusionar uno existente. Escribe esa regla en el archivo de instrucciones del proyecto para asistentes de IA y el siguiente prompt no deshará el rescate en una tarde.
Glosario
- Plugin sprawl / exceso de plugins - acumulación de plugins activos con trabajos solapados hasta que degradan rendimiento, seguridad y mantenibilidad.
- TTFB (Time to First Byte) - tiempo de respuesta del servidor antes de que el navegador renderice contenido; sensible al recuento de hooks PHP y consultas a la base.
- mu-plugin - plugin must-use cargado en cada petición desde
wp-content/mu-plugins/; a menudo usado para «arreglos rápidos» generados por IA. - Opciones autoload - opciones de WordPress cargadas en cada petición; hinchadas por plugins que guardan arrays grandes con
autoload=yes. - Exceso de consultas - consultas excesivas a la base por vista de página, habitual cuando muchos plugins obtienen metadatos de forma independiente.
Conclusión
Cuarenta plugins de profundidad no es un fallo moral. Es lo que ocurre cuando el montaje rápido asistido por IA supera la revisión de arquitectura. El sitio anonimizado de esta guía pasó de 38 a 21 plugins activos, mediana de TTFB sin caché de 1,47 s a 0,68 s, y consultas en la home de 187 a 94 sin cambiar de hosting ni reconstruir el tema. El trabajo fue tedioso, medible y en su mayoría desinstalaciones.
Empieza con el registro, elimina capas duplicadas de SEO y caché, audita archivos personalizados de IA antes de celebrar borrar plugins comerciales, y mide tras cada lote. Si la pila sigue resistiéndose, para eso está el rescate de webs hechas por IA: una división conservar-reescribir-eliminar con números adjuntos, no otra recomendación de plugin.
