La pregunta real no es técnica
Cuando un cliente nos pregunta "¿PHP o WordPress?", la respuesta correcta no empieza por el lenguaje. Empieza por tres preguntas más importantes: ¿cuánto cuesta mantenerlo en el tiempo? ¿quién lo va a operar? ¿cuáles son los objetivos reales del proyecto?
El error más común es comparar tecnologías cuando en realidad se está comparando modelos de negocio. WordPress es una plataforma de gestión de contenidos con una comunidad enorme. PHP vanilla es un lenguaje de programación con el que construís exactamente lo que necesitás. Son herramientas con filosofías distintas, no alternativas equivalentes.
Lo que WordPress gestiona bien
WordPress tiene sentido en escenarios específicos y bien definidos:
- Blogs y sitios de contenido simple donde el cliente necesita publicar artículos frecuentemente sin depender de un desarrollador.
- Clientes no técnicos que requieren editar páginas, imágenes y textos con una interfaz gráfica accesible (el editor de bloques de Gutenberg cumple bien ese rol).
- Presupuestos ajustados para sitios de 5 páginas estáticas donde el tiempo de desarrollo importa más que la calidad a largo plazo del código.
En estos contextos, WordPress es una decisión razonable. El problema aparece cuando se aplica esa misma herramienta a proyectos que exceden esos límites.
Donde WordPress empieza a costar caro
Performance. Una instalación de WordPress con 15 plugins activos puede generar 80-120 queries SQL por página. Un sitio PHP bien escrito hace 3-5. La diferencia en TTFB y LCP es medible y se traduce directamente en conversiones y posicionamiento.
Seguridad. WordPress es el CMS más atacado del mundo, no porque sea inseguro de base, sino porque su popularidad lo convierte en el blanco más rentable para los atacantes. Mantener un sitio WordPress seguro implica actualizar el core, los plugins y los temas con frecuencia — y cada actualización puede romper algo. Es una carga operativa permanente.
TCO real. El costo total de ownership suele subestimarse. Hosting compartido saturado por otros sitios WP, plugins premium con licencias anuales, un developer especializado en el ecosistema WordPress (distinto de un PHP developer generalista) y tiempo dedicado a resolver conflictos entre plugins suman más de lo que se presupuesta al inicio.
Lock-in. Migrar un sitio WordPress maduro es costoso. La base de datos tiene shortcodes propietarios, el contenido está entrelazado con la lógica del tema, y los plugins crean dependencias difíciles de romper. Salir de WordPress requiere un proyecto de migración serio, no solo exportar el contenido.
El caso para PHP a medida
Cuando el proyecto lo justifica, PHP vanilla tiene ventajas estructurales que ningún CMS puede ofrecer:
- Control total del stack. Cada línea de código tiene un propósito claro. No hay plugins que ejecuten lógica que nadie entiende.
- Performance nativa. Sin capa de abstracción, sin autoload de clases que nunca se usan, sin queries generadas por el ORM que nadie pidió.
- Seguridad activa, no reactiva. En vez de esperar que el ecosistema de plugins parchee vulnerabilidades, la superficie de ataque está definida por el código que se escribió — nada más.
- Escalabilidad sin dependencias. Agregar funcionalidad no significa buscar un plugin compatible y rezar para que no conflictúe con los otros diez instalados.
- Un developer que conoce cada línea del código. En un proyecto PHP a medida, el mantenimiento no depende de que el autor original del plugin siga activo en la comunidad de WordPress.
La regla que usamos en INTEA
En la práctica, nuestra decisión sigue una heurística simple:
WordPress si: el sitio es esencialmente un blog o landing page, el cliente necesita editar contenido frecuentemente sin asistencia técnica, y el presupuesto no justifica el desarrollo a medida de una interfaz de administración propia.
PHP si: el proyecto incluye un panel administrativo, integraciones con APIs externas, flujos de usuario complejos, performance crítica, o es un proyecto que necesita vivir y evolucionar durante varios años. En esos casos, la inversión inicial en desarrollo a medida se amortiza rápidamente frente al costo operativo de mantener WordPress.
La mayoría de los proyectos que recibimos de empresas medianas caen en la segunda categoría — aunque el cliente inicialmente haya pensado en WordPress.