
Nos ganamos la vida haciendo webs a medida. Y aun así, hay reuniones en las que recomendamos WordPress. No es generosidad: recetar la misma tecnología a todos los proyectos es la forma más rápida de equivocarse con la mitad.
WordPress y una web a medida resuelven necesidades distintas y pueden ser buenas decisiones si el alcance, el equipo y el mantenimiento encajan. WordPress no es una chapuza por definición. Una web a medida tampoco es mejor por llevar más código. Elegir bien exige comparar el coste total y la capacidad necesaria, no solo el precio inicial.
WordPress ofrece un sistema de gestión y un ecosistema preparado. Una web a medida construye la experiencia y la lógica alrededor de requisitos concretos. Y entre ambas existe una tercera opción: un CMS headless con un frontend desarrollado a medida.
| Criterio | WordPress | CMS headless + frontend | Desarrollo específico |
|---|---|---|---|
| Lanzamiento | Rápido con tema y alcance estándar | Requiere integración | Depende de la lógica |
| Edición | Familiar y amplia | Adaptable al modelo de contenido | Hay que construirla o integrarla |
| Diseño | Flexible dentro del tema y desarrollo | Control completo del frontend | Control completo |
| Extensiones | Gran ecosistema | Integraciones por API | Integraciones propias |
| Mantenimiento | Núcleo, tema y plugins | CMS, frontend y despliegue | Código, infraestructura y dependencias |
| Escalado | Viable con arquitectura y hosting adecuados | Bueno para contenido multicanal | Diseñado según requisitos |
La tabla no decide por ti. Hace visibles las responsabilidades que suelen desaparecer del presupuesto.
Cuando la web sigue patrones conocidos y el equipo necesita autonomía dentro de un ecosistema maduro. Una web corporativa sencilla, un blog o una primera versión pueden lanzarse rápido sin desarrollar cada función desde cero.
Lo elegiríamos cuando:
El problema no es usar plugins. Es instalar diez para resolver cinco veces el mismo problema y no saber cuál controla cada comportamiento.
Cuando la experiencia, los datos o las integraciones forman parte de la ventaja del negocio. El código específico se justifica porque resuelve una necesidad que una plataforma estándar fuerza o no cubre.
Tiene sentido cuando hay configuradores, catálogos complejos, áreas privadas, flujos comerciales propios, varios mercados o integraciones profundas. También cuando rendimiento, accesibilidad y control editorial tienen requisitos que deben verificarse desde el inicio.
En nuestra página de desarrollo de webs a medida explicamos cómo conectamos contenido, diseño, analítica y evolución del producto.
Cuando el equipo necesita editar contenido, pero el frontend no debe depender de las plantillas del CMS. Separa la gestión editorial de la experiencia pública.
No sustituye al desarrollo. Lo organiza de otra manera. El equipo construye el frontend y conecta el CMS mediante API. Esto facilita reutilizar contenido, pero añade integración y mantenimiento. La guía sobre qué es un CMS headless explica sus ventajas y límites sin convertirlo en respuesta universal.
Ninguna por el nombre. La velocidad depende de la implementación. Un WordPress con buen hosting, pocas dependencias y caché puede rendir bien. Un frontend a medida con imágenes enormes y JavaScript innecesario puede rendir mal.
Para comparar propuestas, pide mediciones sobre plantillas reales y en móvil. Google evalúa LCP, INP y CLS con datos de usuarios reales, y los umbrales «buenos» se miden en el percentil 75. Documentación oficial de Core Web Vitals
La que alguien mantiene. La seguridad depende de actualizaciones, permisos, superficie expuesta, copias y respuesta ante incidentes. WordPress exige vigilar núcleo, temas y plugins. Un desarrollo específico exige mantener dependencias y código propio. Headless separa capas, pero la API y el panel siguen necesitando control.
Desconfía de cualquier propuesta que prometa «seguridad total». Pide quién actualiza, cuánto tarda en actuar, qué se registra y cómo se restaura el servicio.
Sumando construcción, licencias, hosting, mantenimiento, cambios y coste de sustitución. Una cifra inicial baja puede ser correcta si el proyecto es simple. También puede esconder trabajo recurrente.
Compara las ofertas con la misma lista:
La guía sobre cuánto cuesta una web profesional separa partidas y riesgos sin presentar una tarifa universal.
Cinco preguntas sobre complejidad y operación. Marca la opción que responde mejor a cada una:
| Pregunta | Señal hacia WordPress | Señal hacia headless o medida |
|---|---|---|
| ¿La funcionalidad es estándar? | Sí | No, existe lógica propia |
| ¿El diseño puede adaptarse a un sistema existente? | Sí | No, la experiencia es diferencial |
| ¿El contenido vive solo en la web? | Sí | No, se reutiliza en otros canales |
| ¿Hay integraciones críticas? | Pocas y estándar | Varias o específicas |
| ¿Quién mantendrá la solución? | Equipo WordPress disponible | Equipo técnico estable |
¿El resultado queda dividido? No pasa nada. La arquitectura puede combinar piezas. Lo que no haríamos nunca es comprar una plataforma por afinidad de la agencia y descubrir después que el negocio tenía que adaptarse a ella. Si tienes dos propuestas encima de la mesa y no entiendes por qué una dobla a la otra, escríbenos y te decimos qué está comprando cada una.
También te puede gustar