En 2017 una cliente me llamó en pánico. Había construido el sitio de su floristería en el constructor de sitios web de GoDaddy, le tomó un fin de semana, se veía decente en móvil, y estaba orgullosa de él. Luego quiso agregar un simple calendario de eventos. Solo un calendario. GoDaddy no podía hacerlo. No sin un workaround tan feo que habría avergonzado a un desarrollador junior. Terminó pagándome para migrar todo a WordPress, y recuerdo haber pensado: ¿por qué la gente empieza aquí en absoluto?
Punto clave: el constructor de GoDaddy sacrifica flexibilidad por simplicidad más que sus competidores; WordPress, Webflow y Squarespace ofrecen más margen de maniobra a costo comparable.
Lo entiendo, en serio. El argumento de GoDaddy es seductor. Regístrate, elige una plantilla, escribe el nombre de tu negocio, publica antes del almuerzo. Para alguien que nunca ha tocado un CMS, esa velocidad se siente como un superpoder. Pero es tiempo prestado. Y habiendo construido más de 12,000 sitios en Seahawk, ya he perdido la cuenta de cuántas migraciones de GoDaddy he hecho para clientes que crecieron más rápido de lo que esperaban.
Así que déjame decirte a qué cambié realmente a los clientes (y a mí mismo), y por qué.
---
El Problema del Constructor de GoDaddy No es Velocidad, Son los Límites
El constructor de sitios web de GoDaddy es genuinamente rápido para ponerlo en marcha. No voy a pretender lo contrario. GoDaddy Airo, su capa de IA, puede armar un sitio con marca, logo y plantillas de campañas de email antes de que termines tu café. El editor es limpio, intuitivo, y no intimidante para personas que no saben qué es un div y no quieren aprender.
Pero.
No puedes mover secciones libremente. No puedes editar HTML o CSS. No puedes cambiar diseños más allá de las opciones preestablecidas. Y ciertamente no puedes instalar un plugin que no existe en su ecosistema cerrado. Como dice una reseña exhaustiva del constructor de forma clara, la conveniencia de la configuración es real, pero en el momento en que quieres algo más allá de los conceptos básicos del diseño, chocas contra una pared.
Esa pared es el problema. No el constructor en sí.
Tenía una cliente, una clínica de fisioterapia en Bristol, que había estado en GoDaddy durante tres años. Sitio de buen aspecto. Luego querían reservas en línea con formularios de intake, integración con su software de gestión de práctica, y un área de miembros para bibliotecas de videos de ejercicios. Pasamos dos horas auditando lo que GoDaddy podía soportar nativamente. La respuesta fue esencialmente nada en esa lista. Tres años de contenido, y tuvieron que empezar de nuevo arquitectónicamente.
No es una historia de advertencia sobre GoDaddy específicamente. Es una historia de advertencia sobre elegir plataformas basándote en qué tan rápido puedes empezar en lugar de qué tan lejos puedes llegar.
---
WordPress: Aún la Opción Sensata para la Mayoría
La gente ha estado declarando a WordPress muerto durante casi una década. Aún alimenta alrededor del 40% de toda la web. Eso no es inercia, es efecto de red a una escala que nada ha logrado desalojar.
Por Qué Aún lo Recomiendo
El ecosistema de plugins por sí solo vale el precio de admisión (que, para ser justos, es gratis). 60,000+ plugins significa que prácticamente cualquier función que puedas imaginar ya ha sido construida por alguien, probada en producción por miles de sitios, y documentada a muerte en YouTube. WooCommerce para ecommerce. ACF para campos personalizados. Yoast o Rank Math para SEO. El stack es aburrido y eso es genuinamente un cumplido.
Para agencias, el grupo de talentos también importa. Puedo contratar un desarrollador de WordPress en Londres, Lagos o Ljubljana y tener una confianza razonable de que saben qué es un custom post type. Intenta eso con un constructor propietario.
Las Advertencias de WordPress de las que Soy Honesto
No es perfecto. Los conflictos de plugins son reales. Mantener 40 plugins actualizados sin romper algo es, como lo expresó un comentarista de Hacker News, "cuidar MySQL." La seguridad es una preocupación genuina cuando ejecutas una versión antigua de un plugin mal mantenido. Y el editor de bloques (Gutenberg) aún divide opiniones de maneras que se sienten casi teológicas.
Pero para un cliente que necesita flexibilidad genuina, propiedad del contenido y un sitio que pueda crecer con ellos, WordPress sigue siendo mi primera recomendación a menos que el brief apunte específicamente a otro lado.
---
WordPress Headless y Jamstack: Cuando el Brief Apunta a Otro Lado
Hace unos tres años Seahawk empezó a recibir más briefs que tenían "performance" como un requisito firme, no algo opcional. Tiempos de carga rápidos. Puntuaciones altas de Core Web Vitals. Contenido servido en múltiples superficies, web, app, quizás una pantalla kiosk en un entorno retail. El hosting tradicional de WordPress no iba a funcionar.
Fue entonces cuando nos enfocamos más en arquitectura headless.
Lo Que Headless Realmente Significa (Sin la Jerga)
WordPress headless significa que mantienes WordPress como el backend, el repositorio de contenido, la interfaz de administración en la que tu cliente inicia sesión, pero desacloplas el frontend completamente. La "cabeza" (lo que ven los usuarios) se construye en un framework de JavaScript como Next.js o Astro. WordPress sirve contenido a través de su API REST o GraphQL. El frontend obtiene esos datos y los renderiza como quiera.
El resultado: cargas de página increíblemente rápidas, sin cuello de botella de renderizado PHP, y total libertad sobre tu arquitectura frontend. La seguridad también mejora porque el administrador de WordPress no se expone públicamente de la misma manera.
El panorama de CMS Jamstack
Si estás yendo full Jamstack, ni siquiera necesitas usar WordPress como tu backend. Hay un campo sólido y creciente de opciones de CMS headless construidas específicamente para esta arquitectura. Algunas que he usado en producción:
- Contentful, maduro, bien documentado, ligeramente caro a escala pero sólido como una roca
- Sanity, modelado de contenido extremadamente flexible, excelente DX, colaboración en tiempo real para equipos editoriales
- Storyblok, el editor visual es genuinamente impresionante para clientes no técnicos que quieren ver los cambios en tiempo real
- Strapi, de código abierto, auto-hospedable, basado en Node.js, bueno si quieres mantener bajos los costos de infraestructura
- Directus, subestimado, especialmente para proyectos con mucho volumen de datos que necesitan una capa de abstracción de base de datos adecuada
Ninguno de estos es perfecto para cada proyecto. El editor visual de Storyblok es una delicia para editores pero añade complejidad en el lado del desarrollador. El lenguaje de consultas GROQ de Sanity tiene una curva de aprendizaje. Elige según el proyecto real, no según la tendencia.
---
EmDash: El Recién Llegado Que Vale la Pena Observar (Con Salvedades)
Algo interesante se lanzó en abril de 2026. EmDash es un nuevo CMS respaldado por Cloudflare, posicionándose como el sucesor espiritual de WordPress, construido con tecnologías web modernas, con aislamiento de plugins a través de Cloudflare Workers, y contenido almacenado como datos estructurados que son nativamente legibles por herramientas de IA.
La propuesta es genuinamente interesante. WordPress se ejecuta en PHP, que funciona pero no es exactamente lo que diseñarías desde cero en 2026. EmDash está construido para implementación nativa en el edge, contenido estructurado, y un mundo donde los asistentes de IA son cada vez más cómo las personas descubren información.
Aún no he desplegado EmDash en producción. Se lanzó en beta y lo estoy observando. Hay algunas preocupaciones reales que vale la pena señalar:
- El ecosistema es completamente nuevo. 60,000 plugins de WordPress versus... no tanto. Aún.
- La función de aislamiento de plugins solo funciona en el runtime de Cloudflare, lo que está bien si te comprometes con esa infraestructura, limitante si no lo haces.
- Es un producto beta. Riesgo inherente. No pongo betas frente a clientes que necesitan estabilidad.
El consenso honesto de personas que lo han probado es: técnicamente impresionante, prácticamente incompleto. Vale la pena revisarlo en 12-18 meses. Haré exactamente eso.
---
Cómo elegir realmente entre estas opciones
Aquí está el punto: la mayoría del contenido de "cuál CMS es mejor" en línea trata esto como una comparación de especificaciones. Casillas de verificación. Matrices de características. Así no es como se elige una plataforma para un proyecto real.
Así es como realmente lo hago:
- Pregunta qué necesitará el cliente en 18 meses, no hoy. Si es una florista independiente, WordPress en hosting administrado probablemente está bien. Si es una startup respaldada por capital de riesgo esperando un crecimiento de 10x en tráfico, diseña para eso ahora.
- Pregunta quién lo mantendrá después del lanzamiento. Una configuración headless Jamstack es brillante hasta que el gerente de marketing de 58 años del cliente tiene que actualizar una publicación de blog. Entonces es un ticket de soporte esperando a pasar. Adapta la complejidad técnica al equipo.
- Pregunta si el contenido va a más de un lugar. Múltiples frontends (web + app + lo que sea) casi siempre apunta hacia headless.
- Pregunta sobre integraciones. CRM, sistemas de reservas, procesadores de pago, analítica, mapea esto antes de comprometerte con una plataforma, no después.
- Pregunta sobre presupuesto para mantenimiento continuo. Una instancia de Strapi autohospedada necesita a alguien manteniéndola versión de Node.js actualizada. Eso cuesta tiempo o dinero. Inclúyelo en la cuenta.
---
La realidad de migración de la que nadie habla
Migrar de GoDaddy (o cualquier constructor propietario) no es trivial. El contenido generalmente es exportable en alguna forma, pero la estructura a menudo no. GoDaddy no te da exportaciones limpias de base de datos o APIs de contenido. Típicamente estás raspando, copiando y pegando, o usando herramientas de migración de terceros que hacen alrededor del 70% del trabajo y te dejan limpiando el resto manualmente.
He migrado suficientes de estas como para tener un proceso, pero no pretenderé que sea elegante. Presupuesta tiempo real para ello. Y absolutamente verifica que tu transferencia de dominio desde GoDaddy se maneje cuidadosamente, tienen un historial de hacer ese proceso más problemático de lo que debería ser.
Las buenas noticias: una vez que salgas, saliste. Los clientes que se mudan a WordPress o a un CMS headless casi nunca vuelven atrás.
---
FAQ
¿Es bueno el constructor de sitios web de GoDaddy para algo?
Honestamente, sí, para casos de uso muy específicos. Un sitio de una sola página para un trabajador autónomo local que solo necesita una presencia en línea y un número de teléfono. Una página de destino temporal. Algo que una persona no técnica necesita activo en cuestión de horas y nunca necesitará cambiar significativamente. Para esos casos, la velocidad de configuración es una ventaja real. Para cualquier cosa con ambiciones de crecimiento, se queda corto rápidamente.
¿Necesito saber programar para pasar a WordPress?
No necesariamente. El hosting WordPress gestionado de proveedores como Kinsta, WP Engine, o incluso Hostinger hace que el lado operativo sea mucho más accesible. Aún querrás cierta comodidad con la interfaz de administración e idealmente a alguien a quien llamar cuando las cosas se rompan. Pero muchos propietarios de pequeños negocios ejecutan sitios WordPress sin tocar una línea de código.
¿Cuál es la diferencia entre un CMS headless y un CMS regular?
Un CMS tradicional (como WordPress clásico) maneja tanto el almacenamiento de contenido como la representación de la página, es un sistema acoplado. Un CMS headless solo maneja el almacenamiento de contenido y lo expone a través de una API. Tu frontend, construido en el framework que prefieras, obtiene ese contenido y decide cómo mostrarlo. La ventaja es flexibilidad y rendimiento. La desventaja es que necesitas un desarrollador frontend, no solo un constructor de sitios.
¿Está EmDash listo para uso en producción?
No para la mayoría de negocios, en mi opinión. Se lanzó en beta en abril de 2026 y el ecosistema es genuinamente incipiente. La arquitectura subyacente es interesante y el respaldo de Cloudflare le da credibilidad. Pero no pondría el sitio de marketing principal de un cliente en un CMS beta cuando WordPress y alternativas headless probadas existen. Mantente atento a esto en 2027.
¿Puedo usar WordPress como un CMS headless?
Sí, y es en realidad un término medio muy pragmático. WordPress tiene una REST API incorporada y WPGraphQL es un plugin maduro que expone tu contenido a través de GraphQL. Entonces obtienes la interfaz de administración familiar que tus clientes ya conocen, el ecosistema masivo de plugins, pero construyes tu frontend en Next.js o Astro y obtienes los beneficios de rendimiento de una configuración Jamstack moderna. Hemos completado varios proyectos de esta manera en Seahawk y funciona bien.
---
La florista de 2017 sigue siendo cliente, por lo que vale. Está en WordPress ahora, con un plugin de reservas decente y un calendario de eventos que funciona de verdad. No me ha llamado presa del pánico desde entonces. Ese es el objetivo, realmente: construir algo que deje de ser un problema para que la gente pueda enfocarse en su trabajo real.
Elige lo aburrido. Elige lo flexible. Elige la cosa que puedas entregar.