En 2017, una cliente me llamó presa del pánico. Había construido el sitio de su tienda de flores en el constructor de sitios web de GoDaddy — le tomó un fin de semana, se veía bastante bien en móvil, y estaba orgullosa de él. Luego quiso agregar un calendario de eventos simple. Solo un calendario. GoDaddy no podía hacerlo. No sin un workaround tan desagradable que hubiera avergonzado a un desarrollador junior. Terminó pagándome para migrar todo a WordPress, y recuerdo haber pensado: ¿por qué la gente comienza aquí en absoluto?why do people start here at all?
Lo entiendo, honestamente. El argumento de venta de GoDaddy es seductor. Regístrate, elige una plantilla, escribe el nombre de tu negocio, ve en vivo 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 5,000 sitios en Seahawk, he perdido la cuenta de cuántas migraciones de GoDaddy he hecho para clientes que crecieron más rápido de lo que esperaban.Seahawk, I've now lost count of how many GoDaddy migrations I've done for clients who grew out of it faster than they expected.
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 de implementar. No pretenderé lo contrario. GoDaddy Airo, su capa de IA, puede construir un sitio de marca con un logo y plantillas de campañas de correo electrónico 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.The editor is clean, intuitive, and non-threateningfor people who don't know what adivis and don't want to learn.
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 revisión exhaustiva del constructor de manera directa — la conveniencia de la configuración es real, pero en el momento en que quieres algo más allá de lo básico del diseño, te topas con una pared.one thorough review of the builderputs it bluntly — the convenience of setup is real, but the moment you want anything beyond the basics of design, you hit a wall.
Esa pared es el problema. No el constructor en sí.
Tenía un cliente — una clínica de fisioterapia en Bristol — que había estado en GoDaddy durante tres años. Un sitio bien presentado. Luego querían reservas en línea con formularios de admisión, integración con su software de gestión de prácticas, y un área de miembros para bibliotecas de videos de ejercicios. Pasamos dos horas auditando qué podía soportar GoDaddy de forma nativa. 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ándose en qué tan rápido puedes comenzar en lugar de qué tan lejos puedes llegar.startrather than how far you cango.
---
WordPress: Aún la Opción Sensata para la Mayoría
Las personas han estado declarando a WordPress muerto durante la mejor parte de una década. Sigue alimentando alrededor del 40% de la web entera. Eso no es inercia — es efecto de red a una escala que nada ha logrado desalojar.around 40% of the entire web. That's not inertia — that's network effect at a scale that nothing has managed to dislodge.
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 comenzó a recibir más briefs que tenían "rendimiento" como un requisito duro, no algo deseable. Tiempos de carga rápidos. Puntuaciones altas de Core Web Vitals. Contenido servido en múltiples superficies: web, app, quizás una pantalla de quiosco en un entorno minorista. 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)
Headless WordPress significa que mantienes WordPress como backend — el repositorio de contenido, la interfaz administrativa donde tu cliente inicia sesión — pero desacoplas completamente el frontend. La "cabeza" (lo que ven los usuarios) se construye en un framework JavaScript como Next.js o Astro. WordPress sirve contenido a través de su REST API o GraphQL. El frontend obtiene esos datos y los renderiza como quiera.means you keep WordPress as the backend — the content repository, the admin interface your client logs into — but you decouple the frontend entirely. The "head" (what users see) is built in a JavaScript framework like Next.js or Astro. WordPress serves content via its REST API or GraphQL. The frontend fetches that data and renders it however it likes.
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 vas completamente Jamstack, ni siquiera necesitas usar WordPress como backend. Hay un campo sólido y creciente de opciones de CMS headless construidas específicamente para esta arquitectura. Algunos que he usado en producción:headless CMS options built specifically for this architecture. A few I've used in production:
- Contentful — maduro, bien documentado, un poco caro a escala pero sólido como una roca— mature, well-documented, slightly expensive at scale but rock-solid
- Sanity — modelado de contenido extremadamente flexible, excelente DX, colaboración en tiempo real para equipos editoriales— extremely flexible content modelling, great DX, real-time collaboration for editorial teams
- Storyblok — el editor visual es genuinamente impresionante para clientes no técnicos que quieren ver cambios en tiempo real— the visual editor is genuinely impressive for non-technical clients who want to see changes in real-time
- Strapi — código abierto, auto-alojable, basado en Node.js, bueno si quieres mantener los costos de infraestructura bajos— open-source, self-hostable, Node.js-based, good if you want to keep infrastructure costs down
- Directus — subestimado, especialmente para proyectos con mucho volumen de datos que necesitan una capa de abstracción de base de datos adecuada— underrated, especially for data-heavy projects that need a proper database abstraction layer
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 surgió en abril de 2026. EmDash es un nuevo CMS respaldado por Cloudflare, posicionándose como 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.EmDashis a new CMS backed by Cloudflare, positioning itself as a spiritual successor to WordPress — built on modern web technologies, with plugin isolation via Cloudflare Workers, and content stored as structured data that's natively readable by AI tools.
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 característica de aislamiento de plugins solo funciona en el runtime de Cloudflare — lo cual está bien si estás comprometido con esa infraestructura, limitante si no lo estás.
- 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 revisitar en 12-18 meses. Haré exactamente eso.honest consensusfrom people who've tested it is: technically impressive, practically incomplete. Worth revisiting in 12-18 months. I'll be doing exactly that.
---
Cómo elegir realmente entre estas opciones
Aquí está el asunto — la mayoría del contenido "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 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 gestionado probablemente está bien. Si es una startup respaldada por VC que espera un crecimiento de tráfico 10x, arquitectúralo para eso ahora.If they're a solo florist, WordPress on managed hosting is probably fine. If they're a VC-backed startup expecting 10x traffic growth, architect for that now.
- 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 entrada de blog. Entonces es un ticket de soporte esperando suceder. Adapta la complejidad técnica al equipo.A headless Jamstack setup is brilliant until the client's 58-year-old marketing manager has to update a blog post. Then it's a support ticket waiting to happen. Match the technical complexity to the team.
- Pregunta si el contenido va a más de un lugar. Múltiples frontends (web + app + lo que sea) casi siempre apuntan a headless.Multiple frontends (web + app + whatever) almost always points toward headless.
- Pregunta sobre integraciones. CRM, sistemas de reservas, procesadores de pagos, análisis — mapéalos antes de comprometerte con una plataforma, no después.CRM, booking systems, payment processors, analytics — map these before you commit to a platform, not after.
- Pregunta sobre presupuesto para mantenimiento continuo. Una instancia Strapi autohospedada necesita a alguien manteniendo la versión de Node.js actualizada. Eso cuesta tiempo o dinero. Considéralo.A self-hosted Strapi instance needs someone keeping the Node.js version updated. That costs time or money. Factor it in.
---
La realidad de migración de la que nadie habla
Salirse de GoDaddy (o cualquier constructor propietario) no es trivial. El contenido generalmente es exportable de alguna forma, pero la estructura a menudo no lo es. GoDaddy no te proporciona exportaciones de base de datos limpias ni APIs de contenido. Típicamente estás scrapeando, copiando y pegando, o usando herramientas de migración de terceros que hacen aproximadamente el 70% del trabajo y te dejan limpiando el resto manualmente.structureoften isn't. GoDaddy doesn't give you clean database exports or content APIs. You're typically scraping, copy-pasting, or using third-party migration tools that do about 70% of the job and leave you cleaning up the rest manually.
He migrado suficientes de estos para tener un proceso, pero no pretenderé que sea elegante. Presupuesta tiempo real para esto. Y absolutamente verifica que tu transferencia de dominio fuera de GoDaddy se maneje cuidadosamente — tienen un historial de hacer ese proceso más engorroso de lo que necesita 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 comerciante 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 en vivo dentro de horas y nunca necesitará cambiar significativamente. Para esos casos, la velocidad de configuración es una verdadera ventaja. Para cualquier cosa con ambiciones de crecimiento, se queda sin opciones 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, para ser honesto. Ahora está en WordPress, con un plugin de reserva adecuado y un calendario de eventos que realmente funciona. No me ha llamado en pánico desde entonces. Ese es el objetivo, realmente — construir algo que deje de ser un problema para que las personas puedan seguir con su trabajo real.
Elige lo aburrido. Elige lo flexible. Elige la cosa que puedas entregar.