Payload CMS vs WordPress: costes y control para empresas

La mayoría de las comparativas de CMS ignoran la variable que más pesa en los procesos de compra de las empresas europeas: ¿de quién es el pipeline de datos y cuánto cuesta de verdad la soberanía cuando tienes en cuenta el esfuerzo de desarrollo, el hosting y la carga operativa que nadie calcula de antemano? Los planes gestionados de WordPress.com parecen baratos sobre el papel, pero en cuanto necesitas workflows de contenido controlados por API o una infraestructura en la UE que controlas tú, las cuentas cambian. Payload CMS promete una alternativa moderna, headless y nativa en TypeScript, pero «open source y autoalojado» no es lo mismo que «gratis de operar». Esta comparativa evalúa ambos caminos con honestidad, nombra los compromisos que asumimos al elegir uno u otro y deja claro cuándo WordPress sigue siendo la mejor opción.

Datos a julio de 2026. Precios verificados en las listas de precios oficiales; fuentes enlazadas en el texto.

La tesis que nadie quiere oír

WordPress no se está muriendo, y Payload no es un simple sustituto. La verdadera pregunta es si la web de tu empresa es un destino de contenido (WordPress sigue ganando) o una API de contenido que alimenta varios frontends, pipelines de automatización e integraciones de terceros (el foco de diseño de Payload). Si en tu encargo de compra aparecen «headless», «API-first» o «Content as a Service» y a tu equipo legal le importa dónde está la base de datos, Payload merece una línea en el pliego de requisitos. Si tu encargo dice «lanzar en seis semanas una web de marketing con un page builder visual y plugins SEO», WordPress autoalojado sigue siendo la respuesta aburrida pero correcta. Y aquí aburrida es un cumplido.

La realidad de los precios: lo que dice de verdad el dossier

WordPress.com ofrece una escala SaaS gestionada: el plan Personal empieza en 4 €/mes (contrato de 24 meses), el plan Premium en 8 €/mes, el plan Business en 25 €/mes y la tarifa Ecommerce en 45 €/mes (todos con facturación a 24 meses). Los límites de almacenamiento van de 6 GB (Personal) a 50 GB (Business), con 250 GB de almacenamiento dedicado para vídeo en el plan Business para VideoPress.

Payload CMS es open source; en el dossier de investigación, la lista de precios oficial no incluía tarifas SaaS ni planes de hosting publicados. Eso significa que lo alojas tú mismo: en tu propia infraestructura, en un VPS en una región de la UE o en una plataforma Node.js gestionada. El software es gratis; el coste es tu tiempo de DevOps, tu base de datos (MongoDB o Postgres), tu CDN, tu estrategia de copias de seguridad y tu documentación de cumplimiento. Para una pyme compradora europea, eso significa un sprint de ingeniería interno o un desarrollo con una agencia. Ambos tienen tarifa por hora.

Cuándo WordPress.com es la mejor opción

Si lo que buscas sobre todo es una web de marketing tradicional con construcción visual de páginas (Elementor, Divi, bloques de Gutenberg), un ecosistema consolidado de plugins SEO (Yoast, RankMath) y un equipo editorial no técnico que espera una interfaz WYSIWYG conocida, el plan Business de WordPress.com por 25 €/mes te lleva a producción antes que cualquier desarrollo headless. Tienes hosting gestionado, actualizaciones automáticas, una CDN incluida y un contrato de soporte, todo sin escribir una sola línea de código de infraestructura.

WordPress también gana cuando tu modelo de contenido es jerárquico, de páginas y entradas, en lugar de datos estructurados con relaciones complejas. Si «blog + landing pages + formulario de contacto» describe el 80 % de tu estrategia de contenido, la configuración en TypeScript de Payload y su enfoque API-first son sobreingeniería. La automatización de email para 500 suscriptores incluida en la tarifa Business (a través de MailPoet) y el paquete de 200 $ en crédito publicitario aportan un valor de activación inmediato que un CMS headless no puede ofrecer de serie.

Por último, si tu empresa no tiene DevOps interno ni un socio de desarrollo fijo, los costes operativos del autoalojamiento de Payload (gestión de la base de datos, parches de seguridad, monitorización del uptime, rotación de copias de seguridad) te quitarán más horas de sueño de lo que la suscripción SaaS te ahorra en presupuesto.

Cuándo Payload CMS se convierte en la respuesta correcta

El diseño de Payload tiene sentido cuando tu web es uno de varios consumidores de contenido dentro de un ecosistema digital más amplio: una web de marketing en Next.js, un portal de clientes basado en React, una app móvil y un pipeline de automatización en n8n, todos tirando de la misma API de contenido. WordPress puede exponer una API REST, pero no se diseñó para este caso de uso: le atornillas una API a un monolito. Payload es nativo de API: cada tipo de contenido que defines en TypeScript se convierte por defecto en un endpoint REST y GraphQL, con control de acceso granular, webhooks y permisos a nivel de campo ya integrados.

Para las empresas europeas en las que la soberanía de datos es un requisito de compra, y no un extra deseable, autoalojar Payload en un VPS de Hetzner en Falkenstein o en un proveedor cloud suizo elimina la cuestión del encargado del tratamiento externo: tú eres el responsable y el encargado del tratamiento. Tu acuerdo de tratamiento de datos lo firmas con tu proveedor de hosting (elige uno con ISO 27001 y condiciones conformes al RGPD), y tu base de datos nunca sale de la jurisdicción que tú definas. Esta simplicidad tiene valor en las compras: menos contratos con proveedores, menos evaluaciones de impacto de las transferencias de datos y una respuesta más clara cuando tu delegado de protección de datos pregunta «¿Dónde están los datos?»

Payload también gana cuando tu modelo de contenido incluye estructuras relacionales complejas: publicación multi-tenant, catálogos de productos versionados o contenidos que alimentan tanto la web pública como dashboards internos. Defines colecciones, campos y relaciones en código; versionas tu esquema; escribes hooks en TypeScript para validaciones personalizadas o efectos secundarios. Ese nivel de control es imposible en WordPress sin custom post types, Advanced Custom Fields y una pila de plugins que acaba convirtiéndose en una carga de mantenimiento.

RGPD y soberanía de datos en la UE: la mirada del cumplimiento normativo

Para los compradores austriacos, alemanes y suizos que operan bajo el RGPD y el incipiente Reglamento de IA de la UE, elegir CMS también es una decisión de tratamiento de datos. La tarifa Business de WordPress.com es un contrato SaaS con Automattic, una empresa estadounidense; aunque el servicio puede almacenar datos en regiones de la UE con determinados planes, la configuración por defecto no lo garantiza, y cualquier encargado del tratamiento con sede en EE. UU. conlleva un riesgo Schrems II que tu equipo legal tiene que documentar. Si tu contenido incluye datos de clientes, formularios de leads o entradas generadas por usuarios, ese riesgo no es teórico.

Payload CMS, autoalojado en infraestructura de la UE, elimina la cuestión del encargado del tratamiento externo: tú eres el responsable y el encargado del tratamiento. Tu contrato de tratamiento de datos lo firmas con tu proveedor de hosting (elige uno con ISO 27001 y condiciones conformes al RGPD), y tu base de datos nunca sale de la jurisdicción que tú definas. Esta simplicidad tiene valor en las compras:

La contrapartida es que la seguridad es responsabilidad tuya. El servicio gestionado de WordPress.com incluye parches automáticos, mitigación de DDoS y un equipo de seguridad pendiente de las vulnerabilidades. Con Payload, tú parcheas Node.js, configuras tu firewall, rotas las credenciales de tu base de datos y escribes tu propio plan de respuesta a incidentes. Para un equipo de pyme sin una persona dedicada a DevOps, ese esfuerzo operativo es un coste oculto que ninguna lista de precios revela.

Coste total de propiedad: la variable del esfuerzo de desarrollo

El atractivo de WordPress.com es la velocidad de lanzamiento: un usuario no técnico puede poner en marcha una web funcional en horas con un tema prediseñado y el editor de bloques. El atractivo de Payload es el control de la arquitectura, pero ese control tiene un precio que se mide en horas de desarrollo. Una implementación típica de Payload para la web de una empresa mediana (tipos de contenido personalizados, un frontend en Next.js, autenticación, búsqueda y un entorno de staging) requiere entre 40 y 60 horas de desarrollo. Con una tarifa de 150 €/hora, eso son entre 6.000 € y 9.000 € por adelantado, antes del hosting o de la migración de contenidos.

A eso se suma el hosting: una plataforma Node.js gestionada (Render, Railway, Heroku Europe) cuesta entre 20 y 50 €/mes por una instancia de producción; un VPS autogestionado (Hetzner CX31) cuesta entre 10 y 15 €/mes, pero requiere tu propia monitorización y tus propios scripts de copia de seguridad. El hosting de la base de datos (MongoDB Atlas en región UE o Postgres gestionado) cuesta otros 10–30 €/mes, según el volumen. La CDN y el almacenamiento de assets (Cloudflare R2, Bunny CDN) cuestan entre 5 y 15 €/mes. Coste recurrente total: 45–110 €/mes, más tu tiempo interno de mantenimiento.

Compáralo con WordPress.com Business por 25 €/mes, sin esfuerzo de desarrollo y con hosting, CDN y soporte incluidos. La pregunta del punto de equilibrio es si la inversión de 6.000–9.000 € en desarrollo y el sobrecoste operativo de 20–85 €/mes te dan algo que WordPress no puede ofrecer: flexibilidad de API, soberanía de datos o un modelo de contenido que el paradigma de entradas y páginas de WordPress no puede expresar. Si la respuesta es no, el caso de negocio de Payload se viene abajo.

La opinión de Blck Alpaca

Gestionamos internamente nuestros propios pipelines de automatización en n8n, y esos pipelines extraen contenido de APIs, no de paneles de administración de WordPress. Para este caso de uso, Payload sería la arquitectura que elegiríamos si hoy montáramos un hub de contenido, porque está diseñado para el acceso programático y preferimos ser dueños de la infraestructura antes que alquilar comodidad. Aun así, solo recomendaríamos Payload a un cliente si se cumplen tres condiciones: (1) tiene un desarrollador interno o externo capaz de mantener una aplicación Node.js, (2) su modelo de contenido requiere de verdad complejidad relacional o distribución multicanal, y (3) su equipo de compras o legal ha marcado la soberanía de datos como requisito, no como preferencia.

Para todos los demás (equipos de marketing que lanzan una web de campaña, pymes que sustituyen una instalación antigua de WordPress, agencias que crean webs de clientes con un presupuesto fijo), WordPress autoalojado (no WordPress.com, sino WordPress.org en un VPS de la UE) sigue siendo la respuesta aburrida pero correcta. Tienes el ecosistema de plugins, la experiencia de edición visual, la cantera de talento y la simplicidad operativa, y sigues pudiendo elegir tu proveedor de hosting y tu región de datos. El compromiso que aceptamos: WordPress no es nativo de API, y si tu estrategia de contenido evoluciona hacia headless u omnicanal, más adelante tendrás que hacer un replatforming. Es un coste conocido, y lo tenemos en cuenta en la decisión.

Lo único que desaconsejaríamos: elegir Payload porque «headless es moderno», sin un caso de uso concreto para la API ni la capacidad operativa para gestionarlo. Una arquitectura moderna que nadie mantiene es peor que una arquitectura aburrida que funciona.

Matriz de decisión: cómo evaluar los compromisos

Evalúa ambas opciones según estos criterios, ponderados por las prioridades de las pymes europeas:

• Soberanía de datos / encaje con el RGPD: Payload (autoalojado en la UE) puntúa más alto; WordPress.com necesita garantías del nivel Enterprise o autoalojamiento para estar a la altura.
• Profundidad de automatización vs. lock-in: el diseño API-first de Payload se integra sin fricciones con n8n, Zapier o scripts personalizados; WordPress necesita plugins o endpoints personalizados.
• Coste total incluido el esfuerzo de desarrollo: WordPress.com gana en velocidad de lanzamiento y en coste inicial bajo; Payload gana en flexibilidad a largo plazo si puedes absorber la prima de desarrollo.
• Encaje con pymes: WordPress encaja con equipos sin DevOps dedicado; Payload encaja con equipos con capacidad técnica y una estrategia de contenido multicanal.

Si la soberanía de datos y una arquitectura nativa de API no son negociables y tienes la capacidad técnica, Payload es la elección correcta. Si pesan más la rapidez, la simplicidad y un ecosistema probado, WordPress, autoalojado en infraestructura de la UE, sigue siendo la opción pragmática por defecto.

Última actualización: julio de 2026

Blck Alpaca es una agencia de automatización de marketing con IA con sede en Viena, especializada en marketing basado en datos, agentes de IA a medida y automatización de workflows empresariales para empresas de toda Europa.