WordPress conviene cuando el equipo publica contenido con frecuencia y el presupuesto de mantenimiento es acotado; un desarrollo a medida conviene cuando la velocidad, la seguridad y el control del código hacen parte del negocio. La decisión correcta se toma con el costo total a cinco años, no con el precio de la primera factura.
Casi todo lo que se lee sobre este tema está escrito por alguien que vende una sola de las dos opciones. Este artículo no. Trabajo con WordPress desde hace más de una década para clientes que lo necesitan, y el sitio que usted está leyendo en este momento no corre en WordPress: es HTML estático generado con Astro. Abajo están los bytes reales de este build, la comparación criterio por criterio, el costo a cinco años en pesos y —lo importante— el punto exacto donde cada opción deja de tener sentido.
Qué se está comparando exactamente
Antes de la tabla hay que limpiar el vocabulario, porque buena parte de la confusión viene de comparar cosas distintas y de que cada proveedor use las mismas palabras para nombrar arquitecturas que no se parecen en nada.
WordPress autoalojado
Un gestor de contenido en PHP que vive en un servidor con base de datos MySQL. Cada visita dispara consultas a la base de datos, ejecuta el núcleo, el tema y los plugins activos, arma el HTML y lo devuelve. La caché existe justamente para evitar repetir ese trabajo en cada petición. Su fortaleza real es el ecosistema y la propiedad del activo frente a las plataformas cerradas: usted es dueño del código y de los datos, y puede llevarse el sitio a otro proveedor cuando quiera.
Desarrollo a medida
Aquí caben tres cosas muy distintas que la gente mete en la misma bolsa:
- Sitio estático generado (Astro, Eleventy, Hugo): el HTML se construye una vez, en el momento del despliegue, y el servidor solo entrega archivos. Es la opción natural para sitios corporativos, de servicios y de contenido.
- Aplicación con renderizado en servidor (Next.js, Nuxt, Laravel): hay lógica ejecutándose en cada petición. Se justifica con áreas privadas, catálogos enormes o personalización por usuario.
- Headless: un CMS aparte —incluido WordPress— entrega contenido por API y otro sistema arma el front. Es el punto medio del que casi nadie habla y al que vuelvo más adelante.
Cuando en Colombia se cotiza “página web a medida” para una empresa de servicios, en la gran mayoría de los casos lo que corresponde técnicamente es la primera: un sitio estático. Y ahí la diferencia de rendimiento contra un WordPress con constructor visual no es de matiz.
Velocidad: los datos de este sitio, medidos en el build
En lugar de repetir promesas, estos son los números que arroja la compilación de alejandroverjel.com. Se pueden verificar abriendo el inspector del navegador en esta misma página, en la pestaña de red.
| Métrica del sitio (Astro estático) | Valor medido |
|---|---|
| Archivos JavaScript en todo el sitio | 3 |
| Peso total del JavaScript (comprimido) | ≈ 5,8 KB |
| Portada: HTML servido (comprimido) | ≈ 28 KB |
| Página de servicio (comprimido) | ≈ 27 KB |
| Artículo de blog largo como este (comprimido) | ≈ 32 KB |
| Consultas a base de datos por visita | 0 |
| Plugins ejecutándose en cada carga | 0 |
Para dimensionarlo: el JavaScript completo de este sitio pesa menos que un ícono mal exportado. Un sitio corporativo con constructor visual y una decena de plugins se mueve, según los rangos de referencia que se observan habitualmente en auditorías del mercado colombiano, entre 1,5 y 4 MB por página, con 60 a 120 peticiones y entre 300 y 800 KB solo de JavaScript. La diferencia no está en el logo del CMS: está en cuántas capas se ejecutan entre el clic y el pixel.
Por qué el estático gana en las métricas que Google mide
El navegador del visitante recibe HTML terminado desde el borde de la red. No hay PHP, no hay base de datos, no hay hoja de estilos de un constructor que carga 200 KB de reglas para usar 12. Eso ataca directamente los tres frentes de los Core Web Vitals e INP:
- LCP: el TTFB tiende al mínimo porque el archivo ya existe y viaja desde la caché del CDN, sin esperar a que un servidor lo arme.
- INP: sin JavaScript pesado no hay hilo principal bloqueado; las interacciones responden porque no hay cola de tareas esperando turno.
- CLS: el layout no se recalcula cuando entran scripts de terceros que inyectan sus propios estilos después de la primera pintura.
La parte honesta
El estático no compra Core Web Vitals en verde por decreto. Si usted sube una imagen de 3 MB sin comprimir en el hero, el LCP se cae igual, sea Astro o WordPress. La arquitectura elimina un conjunto de causas de lentitud; el resto —imágenes, fuentes, scripts de terceros, píxeles de publicidad— sigue siendo responsabilidad de quien construye. Ese detalle está desarrollado en el artículo sobre la velocidad de carga y su impacto en las ventas.
Y al revés: un WordPress con tema ligero, caché a nivel de servidor, CDN e imágenes en WebP compite perfectamente. Lo que casi nunca compite es el WordPress real que tienen la mayoría de las empresas: tema comprado en un marketplace, constructor visual, treinta plugins y hosting compartido del rango más económico del mercado. La tecnología no es el problema; la acumulación sin criterio sí.
Comparativa criterio por criterio
Esta es la tabla que sirve en un comité, porque compara por riesgo y por costo marginal, no por gustos. Los tiempos y multiplicadores son rangos de referencia del mercado colombiano.
| Criterio de decisión | WordPress autoalojado | Desarrollo a medida (estático) |
|---|---|---|
| Costo inicial | Menor | Mayor (1,5 a 3 veces) |
| Costo de mantenimiento mensual | Permanente y obligatorio | Bajo o casi nulo |
| Velocidad de entrega del proyecto | 3 a 6 semanas | 5 a 10 semanas |
| Rendimiento por defecto | Depende del stack elegido | Muy alto de entrada |
| Superficie de ataque | Amplia (núcleo, plugins, temas, PHP) | Mínima (archivos estáticos) |
| Autogestión de contenido | Excelente, sin curva técnica | Requiere CMS headless o edición en repositorio |
| Cambios de diseño puntuales | Inmediatos desde el panel | Requieren despliegue |
| Talento disponible en Colombia | Muy alto | Medio, perfil más senior |
| Techo de crecimiento | Alto, con costo creciente | Muy alto |
| Riesgo de romperse solo | Real (actualizaciones, incompatibilidades) | Prácticamente cero |
| Mejor para | Contenido frecuente y equipos internos | Sitios de servicio, alto tráfico y marca |
La lectura importante: WordPress traslada el costo al futuro y el desarrollo a medida lo concentra al principio. No hay una opción barata; hay dos formas distintas de pagar.
Costo total de propiedad a cinco años
Estos son rangos de referencia del mercado colombiano para un sitio corporativo de 8 a 20 páginas, no tarifas de un proveedor en particular. El ejercicio vale más que cualquier argumento técnico, porque obliga a poner en la misma hoja lo que se paga hoy y lo que se paga durante los sesenta meses siguientes.
| Concepto (acumulado a 5 años) | WordPress autoalojado | Desarrollo a medida (estático) |
|---|---|---|
| Diseño e implementación inicial | $2.500.000 – $8.000.000 COP | $6.000.000 – $25.000.000 COP |
| Licencias de tema y plugins premium | $2.000.000 – $6.000.000 COP | $0 – $1.500.000 COP |
| Hosting, CDN y copias de seguridad | $3.000.000 – $12.000.000 COP | $0 – $3.000.000 COP |
| Actualizaciones, pruebas y parches | $9.000.000 – $36.000.000 COP | $1.500.000 – $9.000.000 COP |
| Evolución funcional y cambios | $1.000.000 – $6.000.000 COP | $2.000.000 – $10.000.000 COP |
| Total orientativo a 5 años | $17.500.000 – $68.000.000 COP | $9.500.000 – $48.500.000 COP |
Los rangos se solapan a propósito, porque el resultado depende de dos decisiones: cuántos plugins acepta en WordPress y cuánta complejidad mete en el desarrollo a medida. Un WordPress disciplinado sale más barato que un desarrollo a medida sobredimensionado, y un desarrollo a medida bien acotado sale más barato que un WordPress con constructor visual y mantenimiento mensual de agencia.
El detalle mensual, que es donde se va la plata
| Rubro mensual | WordPress | Sitio a medida (estático) |
|---|---|---|
| Hosting y CDN | $50.000 – $350.000 COP | $0 – $120.000 COP |
| Actualizaciones de núcleo, tema y plugins | $150.000 – $600.000 COP | No aplica |
| Monitoreo de seguridad y WAF | $40.000 – $200.000 COP | $0 – $80.000 COP |
| Soporte y cambios menores | $150.000 – $500.000 COP | $150.000 – $700.000 COP |
La línea de actualizaciones es la que decide la comparación. En WordPress no es opcional: es la póliza que evita el incidente. En un sitio estático simplemente no existe ese rubro, porque no hay software ejecutándose en el servidor que se pueda desactualizar. Si al cotizar le presentan un WordPress sin partida mensual de mantenimiento, no le están ahorrando plata: le están trasladando un riesgo que aparecerá facturado más adelante, casi siempre en el peor momento.
Autogestión de contenido: el miedo número uno
“Si no es WordPress, ¿quedo dependiendo del programador para cambiar un teléfono?” Es la objeción más frecuente y, en 2026, ya no es cierta. Hay tres formas de resolverlo en un sitio a medida:
- CMS headless con panel visual (Sanity, Strapi, Decap, Storyblok): el cliente entra a una interfaz web, edita textos e imágenes, guarda, y el sitio se reconstruye y publica solo en uno o dos minutos. La experiencia de edición es equivalente a la de WordPress.
- WordPress como back-end headless: el equipo sigue publicando en el panel de WordPress de toda la vida, pero el sitio público se sirve estático. Mantiene la comodidad y elimina el riesgo de rendimiento.
- Contenido en archivos versionados (Markdown en el repositorio): es lo que uso en este sitio. Excelente para quien escribe con frecuencia y disciplina; menos amable para un equipo administrativo sin perfil técnico.
Ahora, la contraparte honesta: lo que un sitio estático no le da es rediseñar una sección arrastrando bloques un martes a las 3 p.m. Los cambios estructurales pasan por desarrollo. Si su empresa arma landings nuevas cada semana y quiere autonomía total sobre la maquetación, WordPress con un constructor sigue siendo la herramienta correcta y no hay que forzarlo.
Seguridad y mantenimiento
WordPress mueve, según los conteos públicos de uso de gestores de contenido, cerca de cuatro de cada diez sitios de internet, y esa popularidad es exactamente lo que lo convierte en objetivo. La gran mayoría de los incidentes no son fallas del núcleo: son plugins desactualizados, temas nulos y contraseñas débiles. Un WordPress bien mantenido es seguro; un WordPress abandonado dos años es una brecha esperando fecha.
Un sitio estático tiene una superficie de ataque radicalmente menor: no hay panel de administración público, no hay base de datos que inyectar, no hay PHP que explotar. En el peor escenario, el atacante tendría que comprometer el repositorio o el hosting. No es invulnerable, pero se eliminan las tres vías de entrada más comunes.
Traducido a operación: en WordPress alguien tiene que probar cada actualización en un entorno de pruebas antes de aplicarla en producción, y ese alguien cuesta plata todos los meses. En estático, un sitio que no se toca durante tres años funciona exactamente igual el día 1.096.
Tienda en línea: el caso donde WordPress suele ganar
Si el proyecto es comercio electrónico con catálogo administrable, variaciones de producto, cupones, inventario y pasarelas locales, la conversación cambia. Reconstruir a mano lo que WooCommerce ya trae resuelto rara vez se paga solo: hay meses de desarrollo para llegar a un punto donde el ecosistema ya está maduro y probado por miles de tiendas.
La excepción son los catálogos grandes con mucho tráfico, donde el rendimiento pesa en la facturación. Ahí se justifica un front estático o híbrido consumiendo el catálogo por API, con el back-end de la tienda intacto. Es más costoso, pero se decide con números de conversión, no con preferencias técnicas.
Cuándo conviene quedarse en WordPress
- El equipo interno publica contenido varias veces por semana y necesita autonomía total.
- Hay tienda en línea con catálogo administrable y variaciones de producto.
- Se requieren funciones de ecosistema listas: membresías, reservas, foros, formación en línea, multiidioma.
- El presupuesto inicial es la restricción dura y sí existe partida de mantenimiento.
- La empresa quiere poder cambiar de proveedor con facilidad: hay mucho más talento WordPress disponible en el país.
- El sitio ya está en WordPress, funciona, carga bien y no hay un problema real que resolver. No se migra por moda.
Cuándo conviene un desarrollo a medida
- El sitio es la cara comercial de un negocio de servicios: 10 a 40 páginas, contenido estable, mucho tráfico de búsqueda.
- La velocidad es diferencial competitivo real (comparadores, medios, captación por pauta con costo por clic alto).
- Hay requisitos de seguridad o de auditoría que hacen incómodo un panel administrativo expuesto a internet.
- El proyecto necesita una interfaz que no existe en ninguna plantilla y forzarla en un constructor cuesta más que programarla.
- Se busca predecibilidad: costo de mantenimiento cercano a cero durante años.
- Existe una aplicación o producto propio detrás. Aquí hablo desde la práctica: Chately, Rankiamos y VialKy son productos propios, y ese tipo de lógica no se resuelve con plugins.
El camino intermedio que casi nadie propone
No hay que elegir entre los dos extremos. WordPress headless —panel de WordPress, front estático— resuelve la mayoría de las tensiones: el equipo conserva la interfaz que ya conoce, el visitante recibe HTML servido desde CDN y la superficie de ataque pública desaparece. El costo es una capa más de infraestructura y un proveedor con criterio para sostenerla.
Y si la decisión es cambiar de stack, el riesgo no es técnico, es de SEO: mapa de redirecciones 301, estructura de URLs idéntica, schema replicado y monitoreo posterior durante al menos ocho semanas. Cómo se hace sin perder tráfico está detallado en la guía para migrar desde WordPress sin perder posicionamiento.
Qué preguntarle a quien le cotice
Una cotización se evalúa mejor con preguntas incómodas que con comparación de precios. Estas cinco separan al proveedor que sabe del que improvisa:
- ¿Quién es el dueño del código y del dominio al terminar? La respuesta correcta es siempre el cliente, con acceso al repositorio y al panel de dominio.
- ¿Qué incluye exactamente el mantenimiento mensual y qué no? Actualizaciones, copias de seguridad, monitoreo y horas de cambios deben estar discriminados.
- ¿Con qué números se entrega el sitio? Pida compromiso sobre Core Web Vitals medidos en datos de campo, no una captura de una herramienta de laboratorio.
- ¿Cómo se edita el contenido sin depender de usted? Si no hay respuesta clara, el ahorro inicial se convierte en dependencia.
- ¿Qué pasa si mañana quiero cambiar de proveedor? Un stack sano se entrega documentado y se migra; uno amarrado, no.
Cómo decidir en veinte minutos
Responda estas cinco preguntas y la respuesta se arma sola:
- ¿Cuántas veces al mes cambia contenido su equipo? Más de ocho, WordPress o headless con panel. Menos de dos, estático sin discusión.
- ¿Tiene presupuesto mensual asegurado de mantenimiento? Si la respuesta es no, WordPress es la opción cara, no la barata.
- ¿La velocidad afecta su facturación? Si compra tráfico pagado, cada segundo de carga es dinero perdido antes de la primera línea del formulario.
- ¿Necesita funciones de ecosistema ya construidas? Tienda, reservas, membresías: WordPress ahorra meses.
- ¿Cuánto duele que el sitio se caiga o lo comprometan? Si duele mucho, la arquitectura con menos piezas móviles gana.
Si tres o más respuestas apuntan hacia el mismo lado, ya tiene la decisión. Si quedan empatadas, empiece por WordPress bien hecho: siempre se puede pasar a estático después, y al revés también.
Cómo trabajo estos proyectos
Llevo desde 2009 —más de 16 años— construyendo sitios en ambos mundos, soy Google Partner certificado y trabajo con empresas de Bogotá, Medellín, Cali, Barranquilla, Bucaramanga y Cúcuta, además de proyectos remotos en toda Colombia, con 4.9★ sobre 30 reseñas en Google. La recomendación que le voy a dar depende de su operación, no de lo que me quede más cómodo cotizar: si su equipo necesita publicar todas las semanas, le voy a montar WordPress bien hecho y se lo voy a decir de frente.
Si quiere que revisemos su caso con números sobre la mesa, puede ver el detalle del servicio de diseño de páginas web o escribirme directo al WhatsApp +57 300 208 1105 con el enlace de su sitio actual.
