Introducción
Cuando ProSilicones64 me contactó, su web llevaba años acumulando parches. Era un WordPress con 23 plugins activos, cuatro vulnerabilidades de seguridad (dos de ellas críticas), y un tiempo de carga de 6.2 segundos que hacía que cualquier ingeniero de compras cerrara la pestaña antes de ver el catálogo.
El problema no era el diseño. El problema era que habían construido una casa encima de otra casa encima de otra casa, y ahora nadie sabía qué pasaba cuando tocabas algo.
Este caso explica cómo tiré todo y construí desde cero un sistema diseñado específicamente para un catálogo industrial técnico. Con código real, decisiones fundamentadas y resultados medibles.
El problema
Lo primero que hice fue conectarme por SSH y activar el log de consultas de MySQL. Abrí una ficha de producto cualquiera —un perfil de silicona para sellado ferroviario— y conté las queries.
45 consultas. Para mostrar una página con título, descripción, tres imágenes y una tabla de propiedades técnicas.
¿Por qué tantas? Porque cada plugin hacía lo suyo sin coordinarse con los demás. El plugin de SEO consultaba la base de datos. El de caché consultaba para ver si había caché. El de traducciones consultaba tres veces por cada campo. El tema consultaba opciones globales en cada carga. Y así hasta 45.
El TTFB (Time To First Byte) estaba en 890ms. Eso significa que el servidor tardaba casi un segundo en empezar a enviar datos, antes siquiera de que el navegador pudiera renderizar nada.
- 23 plugins activos sin control sobre dependencias
- Tiempo de carga: 6.2 segundos
- TTFB: 890ms (casi un segundo solo para empezar)
- 45 consultas MySQL por cada ficha de producto
- 4 vulnerabilidades activas, 2 de ellas críticas
- Catálogo estático imposible de escalar
- Ausencia total de Schema.org
Para una empresa industrial donde el comprador técnico tiene 15 pestañas abiertas comparando proveedores, eso es un suicidio comercial.
La decisión: tirar todo y construir desde cero
Había dos opciones. La primera era optimizar lo existente: desactivar plugins, instalar caché agresivo, rezar para que no se rompiera nada. La segunda era migrar a un sistema propio diseñado específicamente para lo que ProSilicones64 necesitaba.
Elegí la segunda. ProSilicones64 no es una tienda online ni un blog corporativo. Es un fabricante industrial con un catálogo técnico complejo: 30 productos, 19 series de silicona con propiedades diferentes, 10 sectores industriales, 127 normas y certificaciones.
WordPress no está pensado para esto. Puedes forzarlo con plugins de custom fields y taxonomías personalizadas, pero al final tienes un monstruo que nadie entiende y que se rompe cada vez que actualizas algo.
La arquitectura: PHP directo, MySQL relacional, cero dependencias
No usé Laravel ni Symfony. No porque sean malos —son frameworks excelentes— sino porque para este proyecto añadían complejidad sin beneficio real. ProSilicones64 no necesita un ORM que abstraiga la base de datos; necesita consultas SQL optimizadas que devuelvan exactamente lo que la página necesita mostrar.
Cada controlador hace exactamente una cosa. El controlador de ficha de producto llama al servicio de productos, que llama al repositorio, que ejecuta una única consulta SQL con los JOINs necesarios. Una petición, una consulta, una respuesta.
Arquitectura de carpetas
- /app/controllers → Reciben la petición, llaman al servicio, devuelven la vista
- /app/services → Lógica de negocio: qué series aplican a qué sectores
- /app/repositories → Consultas SQL puras, una función por cada necesidad
- /app/views → PHP plano con HTML, sin motor de plantillas
Base de datos relacional diseñada para el negocio
- productos → categorías: extrusión, moldeo, cauchos técnicos, láminas
- series_silicona → 19 series con temperatura (-60°C a +300°C) y dureza (30-90 Shore A)
- sectores → ferroviario, médico, alimentario, aeronáutico...
- normas_certificaciones → 127 registros: ISO, EN 45545-2, FDA, USP Class VI
- producto_serie_sector → tabla pivote que conecta todo
Sistema de caché en tres niveles
- Nivel 1: OPcache de PHP — bytecode compilado en memoria
- Nivel 2: Caché de consultas — resultado en JSON con timestamp, invalidación por trigger
- Nivel 3: Caché HTTP — cabeceras Cache-Control para navegador y CDN
SEO técnico real
- Schema.org Product en todas las fichas con propiedades técnicas
- URLs limpias: de /producto/?id=847&cat=3 a /productos/perfiles-silicona-ferroviario/
- Redirecciones 301 para no perder enlaces externos
- Sitemap XML dinámico generado desde la base de datos
Los resultados: números reales, no proyecciones
Después de tres meses con el nuevo sistema en producción, estos son los datos comparados. El último número es el que importa: de 8 solicitudes mensuales a 31. No porque el diseño sea más bonito —es prácticamente igual— sino porque la web carga rápido, los productos se encuentran fácilmente, y el formulario de contacto funciona sin errores de JavaScript.
Comparativa antes/después
| Métrica | WordPress (antes) | Sistema custom (después) |
|---|---|---|
| Tiempo de carga | 6.2s | 1.1s |
| TTFB | 890ms | 180ms |
| Consultas SQL por página | 45 | 8 |
| Vulnerabilidades activas | 4 | 0 |
| Plugins/dependencias | 23 | 0 |
| Páginas válidas en Search Console | 68% | 94% |
| Solicitudes de presupuesto/mes | 8 | 31 |
Conclusión
Este proyecto me confirmó algo que ya intuía: para empresas industriales con catálogos técnicos, WordPress es la opción incorrecta. No porque sea malo, sino porque está diseñado para otro tipo de contenido.
Un blog personal, una web corporativa con cinco páginas, una tienda online estándar... para eso WordPress funciona perfectamente. Pero cuando tienes relaciones complejas entre productos, series, sectores y normativas, necesitas una base de datos que refleje esa complejidad.
ProSilicones64 ahora tiene una web que puede crecer sin degradarse. Añadir una nueva serie de silicona es insertar filas en la base de datos, no instalar otro plugin. Añadir un nuevo sector es crear relaciones, no hackear shortcodes.
Y cuando dentro de cinco años quieran rediseñar la parte visual, podrán hacerlo sin tocar la lógica de negocio. Porque están separadas. Porque así se diseñan los sistemas que duran.
Si tu catálogo técnico está montado sobre WordPress y notas que cada vez va más lento, que cada actualización rompe algo, o que los técnicos de compras abandonan antes de llegar al formulario de contacto... probablemente estés en la misma situación que ProSilicones64 hace un año. Puedo hacer un diagnóstico técnico de tu web: medir tiempos reales, contar consultas, identificar cuellos de botella, evaluar vulnerabilidades. Sin compromiso, sin humo. Datos verificables sobre los que tomar decisiones.
Solicitar diagnóstico técnico →
