Alternativas a Framer: elige más allá del canvas de diseño

Elige Webflow para un flujo de trabajo de CMS visual diferente. Elige WordPress auto hospedado para trabajo editorial y dirigido por plugins, y Astro con un CMS headless cuando tu equipo quiera ser dueño del frontend e infraestructura. Permanecer en Framer sigue siendo una opción válida cuando su flujo de trabajo de diseño y publicación ya encajan. Prueba la tarea de publicación recurrente antes de elegir un reemplazo. Si el alojamiento independiente es el requisito, valida la ruta de exportación también.

La lista corta, según lo que necesites cambiar

• Permanece en Framer cuando la libertad de diseño y la publicación administrada ya encajan en el trabajo.
• Webflow cuando el equipo quiere un flujo de trabajo de CMS visual diferente.
• WordPress auto hospedado cuando el proceso editorial y los plugins impulsan los requisitos.
• Astro más un CMS headless cuando serás dueño del frontend e infraestructura.

Cada ruta responde una pregunta diferente, y cada una le da a alguien un conjunto diferente de tareas. Juzga el reemplazo por el próximo año de publicación, no por la rapidez con que alguien pueda copiar la portada actual. Copiar una portada es la parte fácil, y la menos informativa.

Para contexto más amplio, este sitio tiene una guía de alternativas a WordPress y una descripción general de opciones de CMS headless.

La tabla de decisión

Usa el mismo cambio representativo en cada candidato: una página de caso de estudio nueva vinculada a un servicio relacionado y un autor, con su propio título y descripción, una redirección de una URL antigua y un formulario de consulta funcional. Si una ruta no puede hacer eso limpiamente en una prueba, has aprendido algo barato.

Un editor visual y la propiedad del código responden preguntas diferentes. Framer y Webflow proporcionan una superficie de edición mientras sus plataformas ejecutan el sitio. Astro le da al equipo control del código frontend, pero el equipo aún necesita elegir un CMS que enfrente editores e integración. Los CMS sin interfaz pueden proporcionar vistas previas visuales y edición cuando esa conexión se construye. La guía de edición visual de Sanity muestra un enfoque como ese.

Prueba el motivo real del cambio

Cuando la gente dice "Framer es limitante" se refiere a una cosa específica. Nombra esa cosa. Framer ya no es solo una herramienta de portafolio estático: su página de CMS lista referencias ilimitadas, localización integrada, borradores y publicación, y un editor de contenido visual. El contenido en etapas se puede ver antes de publicarse, e importación CSV, sincronización con Google Sheets y sincronización con Airtable también están listadas.

Entonces verifica tu motivo contra la lista real:

• Relaciones de contenido. ¿Necesitas más que colecciones vinculadas? Modela tu contenido real (servicios, autores, estudios de caso) antes de decidir que la herramienta no puede hacerlo.
• Permisos de colaboradores. ¿Quién puede editar, quién puede publicar, quién solo puede sugerir? Escribe esto por rol y compáralo con la documentación de cada plataforma.
• Revisión y vista previa. Framer lista borradores y vistas previas. Webflow lista vistas previas de borradores, ramificación, etapas y aprobaciones. En WordPress depende de lo que instales.
• Localización. Framer y Webflow ambos la listan. Prueba con tus idiomas reales y patrones de URL, no con una página de demostración.
• Integraciones. Nombra el sistema que debe recibir o enviar datos, y la dirección. Una sola integración faltante rara vez justifica una reconstrucción.
• Requisitos de alojamiento. Si una política dice que el tráfico debe pasar por infraestructura aprobada, esa es una conversación diferente, y es en la que la documentación propia de Framer es más cautelosa.

Una salvedad. Blogs de terceros publican límites de CMS por plan para Framer, pero no he verificado esos límites contra la documentación del plan actual de Framer, así que no voy a repetir las cifras. Verifica los límites exactos en las páginas de planes antes de que decidan algo.

Webflow, WordPress y Astro con un CMS

La idoneidad a continuación es juicio editorial. Los hechos sobre capacidades provienen de las propias páginas de los proveedores.

Webflow

Webflow describe su CMS como visual-first y componible, con vistas previas de borradores, publicación granular, campos de referencia e importación masiva CSV. También lista ramificación, etapas, aprobaciones y localización de extremo a extremo, además de APIs de CMS headless para servir contenido dentro y fuera.

Webflow es otra plataforma alojada. Cambiar de Framer a Webflow puede abordar un requisito de edición o integración, pero por sí solo no prueba la independencia de infraestructura. Entonces compara la política de alojamiento real con el servicio administrado de Webflow antes de asumir que un cambio de constructor lo cumple.

Buen ajuste: un equipo de marketing que le gusta la edición visual pero quiere diferentes herramientas de flujo de trabajo. Mal ajuste: un requisito de ejecutar el sitio en tu propia infraestructura.

WordPress autohospedado

WordPress trae un sistema de publicación y un ecosistema de extensiones, como se describe en la página de características de WordPress. Ese es el atractivo: estructura editorial, roles y un complemento para casi cualquier integración.

Alguien aún tiene que ejecutarlo. WP Engine (un proveedor de WordPress administrado, así que léelo teniendo eso en mente) dice que flujos de trabajo editoriales autogestionados y registros de auditoría requieren configuración o herramientas, y que el alojamiento y el rendimiento dependen del stack. El mismo artículo dice que las organizaciones mantienen control total sobre las decisiones de infraestructura y alojamiento. Ambos lados de esa moneda son verdaderos: el control y la responsabilidad llegan juntos.

Los complementos también definen la experiencia editorial. El complemento Editorial Workflow Manager, por ejemplo, agrega una lista de verificación previa a la publicación al editor de bloques, consultivo por defecto con un modo Block opcional, y no proporciona esa interfaz en el Editor Clásico. Pequeños detalles como ese deciden si tu proceso de aprobación realmente existe.

Buen ajuste: volumen editorial, tipos de entrada personalizados, características dirigidas por complementos y un equipo o proveedor asignado para parchear y monitorear la instalación. Mal ajuste: un proyecto donde nadie acepta responsabilidad por el alojamiento, actualizaciones y complementos.

Astro más un CMS headless

Astro es un framework frontend, no un constructor visual. Su documentación incluye una guía de CMS porque el contenido tiene que venir de algún lado. Si no desarrolladores van a publicar, necesitas una capa de edición de contenido, una ruta de vista previa para editores y un proceso de construcción o despliegue que se ejecute cuando presionan publicar.

Eso te da código fuente que posees y alojamiento que eliges. También te da un repositorio, un pipeline y una superficie de seguridad de la que preocuparte. Los desarrolladores se convierten en parte de cada cambio de diseño a menos que construyas bloques amigables para editores. Para la pregunta del framework, ver Astro vs Next.js.

Buen ajuste: un equipo con habilidades frontend, necesidades de rendimiento o integración específicas y una razón para ser dueño del stack. Mal ajuste: un equipo de marketing esperando arrastrar secciones el próximo mes.

Exportación y alojamiento, al 4 de noviembre de 2026

Aquí es donde la documentación propia de Framer no está de acuerdo consigo misma, y no voy a pretender lo contrario.

El artículo de exportación HTML dice que Framer no ofrece exportación HTML para auto-alojamiento. Su FAQ responde "No" a descargar archivos HTML o paquetes estáticos. Lista prerrenderización de páginas, cambio dinámico de tamaño de imagen, subsetting de fuentes, renderización del lado del servidor y entrega global como servicios administrados por la plataforma, y dice que si necesitas control completo de alojamiento o exportación de código fuente, Framer puede no ser la opción correcta.

El artículo sobre portabilidad de datos dice lo opuesto sobre el resultado: cada sitio se publica como HTML, CSS, JavaScript y activos estáticos que puedes descargar y mover a cualquier host. También dice que el contenido del CMS se puede exportar a través de plugins como CSV o JSON, y hace referencia a la Ley de Datos de la UE.

Ambos artículos aparecen en el índice de preguntas frecuentes de Framer como artículos actuales. Ninguno puede considerarse más reciente. Una revisión independiente también señaló la contradicción y dijo que no se había establecido una exportación de sitio funcional compatible y portable. La única posición honesta es esta: valida la ruta de exportación actual y su resultado para tu propio proyecto.

El proxy inverso es control de entrega, no independencia

Framer documenta una ruta de proxy inverso en la que tu servidor solicita páginas del sitio Framer y las sirve a los visitantes. Da control sobre encabezados, autenticación y entrega mientras mantiene a Framer como origen del contenido. Advanced Hosting es un complemento en Pro e incluido en Enterprise, con hasta 6 reescrituras.

Útil, si tu requisito es enrutamiento o encabezados. No es prueba de que puedas operar el sitio sin Framer. Algunos límites de la documentación:

• Cambiar el contenido de página gestionado por React no es compatible; agregar etiquetas sí lo es.
• No uses un dominio *.framer.app como origen.
• Establece la URL canónica, que requiere el complemento Advanced Hosting.
• Haz coincidir rutas cuando sirvas bajo una subruta y evita barras inclinadas finales.
• Un CSP personalizado requiere cuidado, incluyendo worker-src 'self' blob: para que las comprobaciones anti-bot de formularios puedan ejecutarse.

Herramientas de terceros como el plugin Full Site Export leen el sitio publicado y ofrecen resultados estáticos, Next.js y React legible. Su descripción dice que la exportación legible no es idéntica al píxel y el sitio debe estar publicado. Es una ruta de terceros, así que trátala como algo que evaluar, no como una respuesta oficial.

Ejecuta esta lista de verificación de validación de exportación antes de comprometerte

Una página renderizada exportada no es automáticamente un proyecto editable, ni es un reemplazo de CMS. Trata cualquier exportación como evidencia para inspeccionar.

1. Obtén una exportación representativa a través de una ruta documentada disponible, y registra exactamente cómo la obtuviste (ruta, herramienta, fecha, plan).
2. Implementa una copia en un host separado, no en tu dominio de producción.
3. Prueba cargas de URL directas, enlaces internos y menús, y páginas impulsadas por CMS.
4. Verifica imágenes, fuentes, localización, formularios e interacciones.
5. Lista cada solicitud externa y servicio que la copia aún necesita.
6. Confirma cómo se publicaría una actualización de contenido futura y por quién.
7. Compara URLs, canónicas, redirecciones y metadatos contra el sitio en vivo.
8. Si la ruta no se puede validar, define el alcance de la reconstrucción antes de prometer a nadie una migración.

El paso 6 es el que los equipos omiten. Una copia estática que funciona hoy pero no puede aceptar un cambio de contenido mañana es una captura de pantalla con pasos adicionales.

Si quieres una segunda opinión sobre esto, trae un modelo de contenido representativo y la tarea de publicación que Framer actualmente no puede hacer, y podemos ejecutar una evaluación práctica de CMS y frontend a través del desarrollo de CMS sin cabeza.

Mantenerse en el mismo lugar, y un siguiente paso medido

Quedarse en Framer es una opción real. Si su CMS cubre su modelo de contenido, los editores están cómodos y la única brecha es algo como enrutamiento, encabezados o una integración, compara ese cambio más pequeño con una reconstrucción. La ruta de proxy inverso anterior existe exactamente para esos requisitos de entrega, y la página de CMS enumera opciones de sincronización que pueden cubrir un requisito de datos.

Nada aquí dice que cada sitio de Framer tenga SEO deficiente, falle en Core Web Vitals o necesite reemplazo. No es así. Una elección de plataforma no es una garantía de SEO en ninguna dirección.

Una secuencia sensata:

• Anota el único requisito que Framer no cumple, en una oración.
• Ejecuta el cambio representativo en Framer primero, luego en una alternativa.
• Valida la ruta de exportación si la independencia importa.
• Solo entonces presupuesta una reconstrucción.

Si la oración del primer paso resulta ser vaga, ese es el hallazgo.

FAQ

¿Puedo mover el contenido del CMS de Framer a otra plataforma?

El artículo de portabilidad de Framer dice que el contenido del CMS puede exportarse a través de complementos como CSV o JSON, cubriendo texto, imágenes y colecciones. Reconstruye y verifica las relaciones entre colecciones en el destino, porque un archivo plano no lleva tus reglas editoriales.

¿Cambiar de plataforma afectará la visibilidad de búsqueda?

Puede hacerlo. Google dice que los cambios de sitio significativos pueden causar fluctuaciones de clasificación durante un traslado. Antes del lanzamiento, verifica URLs, redirecciones, contenido, enlaces internos, canónicas y acceso de rastreo, luego monitorea la indexación y el tráfico. Un cambio de plataforma por sí solo ni garantiza una mejora ni preserva las clasificaciones existentes.

¿Es editable un sitio de Framer exportado?

No automáticamente. Se genera una copia renderizada, no un archivo de proyecto. Una versión reconstruida en React o Next.js de una herramienta de terceros puede ser editable, pero su propio listado dice que no es idéntica al píxel.

¿Necesito Astro o Next.js para un frontend de propiedad del código?

Cualquiera puede funcionar. La elección depende de las necesidades de renderización, las habilidades del equipo y el alojamiento, que la comparación Astro vs Next.js cubre.

La advertencia más clara: las dos páginas de ayuda de Framer no están de acuerdo sobre exportación, así que prueba la ruta en tu propio proyecto antes de cualquier promesa de migración, y recuerda que un proxy inverso cambia la entrega mientras Framer sigue siendo el origen.