Plugins y deuda técnica: el coste real de tener una tienda

Respuesta corta: una tienda tiene un precio de puesta en marcha y un coste de propiedad, y el segundo es fácil de pasar por alto. Lo componen plugins, licencias, actualizaciones, conflictos y las horas necesarias para que todo siga funcionando. Con el tiempo ese coste crece y la capacidad de introducir cambios disminuye.

Cómo se acumula

Un esquema frecuente consta de pasos que por separado parecen razonables. Hace falta una calculadora de envío: instalamos un plugin. Hacen falta reseñas: otro. Filtros, insignias de «más vendido», exportación a marketplaces, un pop-up de newsletter, chat, un constructor de landings: plugins, plugins, plugins. Cada decisión individual lleva una hora y cuesta poco.

Dos años después, la tienda tiene 40 plugins, de los cuales un tercio no se usa, la mitad del resto duplica funciones y dos han sido abandonados por sus autores. Nadie decidió nunca «compliquémoslo»; la complejidad creció sola, un paso razonable cada vez.

Con qué se paga

Con velocidad. Cada plugin añade consultas a la base de datos y su propio CSS y JS en cada página. Es una pérdida directa de conversión.

Con seguridad. Los plugins son el principal vector de ataque a las webs WordPress. Una vulnerabilidad en una extensión popular afecta a cientos de miles de sitios a la vez, y los atacantes las escanean en masa. Para una tienda, el precio de una intrusión no es solo la parada, sino también los datos de los clientes con todas las consecuencias legales.

Con la posibilidad de actualizar. Situación conocida: una actualización de WooCommerce rompe la compatibilidad con un plugin, el autor calla y la tienda se queda en la versión antigua. Luego no se puede actualizar PHP, luego WordPress, y un año después tiene una pila que nadie quiere tocar.

Con el ritmo de cambios. Una tarea sencilla del tipo «añadir un campo en el checkout» se convierte en una investigación: cuál de los cuatro plugins del checkout es responsable y qué se romperá. Es justo esa sensación de «por qué una tontería así lleva dos días».

Con dinero, directamente. Quince plugins premium a 60–100 € al año son 900–1.500 € anuales solo por el derecho a seguir usando lo que ya tiene.

Seis reglas de higiene

1. Auditoría de plugins dos veces al año. Para cada uno: ¿se usa? ¿se puede sustituir por una función en el tema? ¿ha publicado el autor una actualización en el último año? Todo lo que no pase se elimina. No se desactiva: se elimina, con sus tablas.

2. Nada se cambia directamente en producción. Una copia de staging no es un lujo, es una condición. Actualizar el plugin del carrito un viernes por la tarde en la tienda en vivo es apostar con sus propios ingresos.

3. Copias de seguridad comprobadas con una restauración. Una copia que nunca se ha restaurado no es una copia, es una esperanza. Una vez por trimestre conviene restaurarla en staging y comprobar que la tienda arranca.

4. Actualizaciones según calendario, no con pánico. Una vez al mes: staging → actualización → comprobación de los recorridos clave (pedido, pago, correos) → producción. Aburrido y predecible, es decir, exactamente como debe ser.

5. Minimalismo por defecto. Antes de instalar un plugin, la pregunta: ¿se puede hacer con veinte líneas en el tema? A menudo sí, y entonces es más barato de mantener durante años.

6. Documente lo que sea a medida. Un archivo que describa qué plugins son críticos, qué se configuró a mano y dónde hay código propio. Es lo que distingue una tienda que se puede entregar a otro proveedor de una tienda que le tiene a usted como rehén.

Tres escenarios de salida cuando la deuda ya es grande

1. Escenario 1: limpieza. Eliminar lo que no se usa, sustituir los plugins de un solo uso por código, restablecer el orden en las actualizaciones. Una o dos semanas; puede eliminar gran parte de los problemas y amortizarse. Se empieza por aquí: las demás variantes sin este paso simplemente trasladan el caos a otro sitio.

2. Escenario 2: reescritura de plantillas. Renunciar al tema-constructor y construir directamente las plantillas necesarias. Más difícil, pero elimina la principal fuente de peso y hace que la tienda sea predecible. Se justifica cuando el diseño está bien y la velocidad no.

3. Escenario 3: separar la web y el backend. WooCommerce sigue siendo el sistema de registro (productos, pedidos, pagos, el panel que el equipo ya conoce) y la web se construye aparte. La velocidad deja de depender de los plugins y los cambios en el frontend dejan de poner en riesgo los pedidos. Cuándo compensa y cuándo no lo describe la página WooCommerce y headless; una versión ya lista de ese paso es NextWoo.

Si la tienda está sobre una plataforma que de verdad se ha agotado, es otra conversación: migración de web o CMS.

Apunte para el programador

• Inventario a partir de hechos, no de memoria. Lista de plugins más fecha de la última actualización del autor más lugar de uso real. Un plugin sin llamadas en las plantillas es candidato a eliminar.
• Busque restos de plugins eliminados. Filas en wp_options con autoload='yes', campos meta huérfanos, tareas cron que apuntan a código inexistente.
• Separe el código propio del tema. La funcionalidad, a un plugin aparte; la presentación, al tema. De lo contrario, una actualización o un cambio de tema se llevará consigo la lógica de negocio.
• Fije las versiones y mantenga los entornos idénticos. Una diferencia de versión de PHP entre staging y producción invalida todas las pruebas.
• Siga las vulnerabilidades automáticamente. Suscribirse a una base de vulnerabilidades de plugins es más barato que enterarse del problema por los clientes. Las prácticas de seguridad se tratan en seguridad de aplicaciones web, y la guía básica de rendimiento está en la documentación de WordPress y en los WooCommerce Developer Docs.
• Registre los errores en producción. Una tienda en la que nadie mira los registros se entera del pago roto por el cliente: un día después y en una reseña.

Prueba práctica

• He listado todos los plugins con la fecha de la última actualización del autor
• He eliminado los que no se usan junto con sus datos
• Existe una copia de staging y los cambios pasan por ella
• La copia de seguridad se ha restaurado y comprobado en los últimos 3 meses
• Las actualizaciones siguen un calendario, y no «cuando algo se rompe»
• Conozco la suma anual de licencias
• Existe un documento que describe las modificaciones
• PHP y WordPress están en versiones con soporte

Plan conjunto a 90 días

Para cerrar toda la guía, el orden de trabajos que propondría a casi cualquier tienda:

Semanas 1–2. Medir. Reunir las cinco cifras del embudo, conciliar la analítica con el panel, sacar los Core Web Vitals, leer el informe de búsquedas vacías. Todavía no arreglar nada, solo averiguar dónde se rompe. Vea el diagnóstico del embudo y la analítica.

Semanas 3–5. Checkout. Compra sin cuenta, coste de envío honesto desde el principio, menos campos, un buen formulario móvil, métodos de pago. El retorno más rápido de la lista: carrito y checkout.

Semanas 6–8. Velocidad y ficha de producto. Imágenes, caché, fragmentos del carrito; en la ficha, plazo de entrega, disponibilidad, tabla de tallas, opiniones. Vea velocidad y ficha de producto.

Semanas 9–10. Visibilidad y confianza. Filtros fuera del índice, gestión de productos no disponibles, marcado, contactos y condiciones de devolución: errores de SEO y confianza.

Semanas 11–12. La segunda compra. Secuencia posventa, segmentos, reactivación: retención y LTV.

En paralelo, de fondo. Limpieza de plugins, staging, copias de seguridad, actualizaciones.

A los 90 días no tendrá una «web nueva». Tendrá una tienda de la que sabe exactamente dónde pierde dinero, y en la que se pierde claramente menos.

Si necesita a alguien que lleve este plan por usted: optimización de conversión, aceleración de la web o soporte y desarrollo del producto, según lo que haya mostrado la primera semana.