El CMS de Webflow te limita a 2.000 ítems en el plan CMS, hasta 20.000 en Business, y a la medida en Enterprise. Si has chocado contra ese muro, tienes cuatro opciones reales: quedarte dentro de Webflow con automatización, mover el contenido público detrás de un reverse proxy, empujar el contenido privado a cliente con Wized + Xano, o reconstruir sobre un stack de código como Next.js + Supabase.
Las cuatro las he montado en proyectos de clientes, incluida la primera versión de una plataforma que después llegó a 400.000+ usuarios. Aquí explico cómo decido cuál usar, y la contrapartida que nadie te cuenta.
Límites del CMS de Webflow por Plan
| Plan | Ítems del CMS | Colecciones |
|---|---|---|
| Basic | 0 | 0 |
| CMS | 2,000 | 20 |
| Business | hasta 20,000 | 40 |
| Enterprise | Personalizado | Personalizado |
Soluciones amigables con el SEO
Si tu contenido necesita ser público y fácilmente indexable por los motores de búsqueda, pero has alcanzado o estás cerca del límite de 20,000 ítems en el CMS de Webflow, tienes dos opciones principales:
1. Automatización del CMS de Webflow (o Plan Enterprise)
Si quieres quedarte dentro de Webflow, el truco es mantener el CMS ligero. Monta una automatización que archive los ítems obsoletos en una base de datos externa cuando ya no necesitan ser públicos, por ejemplo después de X días. La alternativa es subir al plan Webflow Enterprise, que ronda entre $15k y $60k al año según el alcance.
La razón por la que existe esta restricción: el contenido SEO-friendly se tiene que generar en el backend, y en Webflow eso pasa obligatoriamente por su CMS.
2. Reverse Proxy (Proxy Inverso)
Un reverse proxy te permite alojar contenido en una plataforma externa (típicamente una app en Next.js) manteniéndolo bajo tu dominio Webflow. El visitante que entra en tusitio.com/blog no nota el corte, pero el contenido vive fuera de la infraestructura de Webflow. Resultado: el límite de ítems del CMS desaparece y la SEO no se toca.
La experiencia de edición de contenido
La preocupación habitual al sacar contenido de Webflow es perder el editor. En la práctica, conectas un Headless CMS (Payload, Sanity, Contentful) y el equipo editorial obtiene una interfaz tan buena como la de Webflow, a veces mejor. El frontend sigue cargando bajo tu dominio Webflow.
Hay dos formas principales de configurar esto:
El Reverse Proxy Clásico
Históricamente, configurar un proxy inverso era un proceso técnicamente complejo, requiriendo configuración de un servidor externo, gestión de DNS y mantenimiento continuo.
El principal inconveniente: estar alojado fuera de Webflow significaba perder acceso al Webflow Designer. Tu plataforma externa no compartiría los componentes de UI integrados y las plantillas de Webflow, por lo que necesitarías construir tu frontend por separado.
Proxy Inverso Nativo (Webflow Cloud)
Para resolver estos problemas, Webflow introdujo una solución nativa de proxy inverso a través de Webflow Cloud. Esto te permite alojar aplicaciones construidas con código tradicional (como Next.js) directamente dentro de la infraestructura de alojamiento de Webflow.
Con este enfoque, simplemente especificas qué ruta debe servir tu aplicación personalizada (por ejemplo, /blog), y Webflow maneja el proxy de forma nativa.
También intenta resolver el problema de UI. Con Webflow DevLink, diseñas los componentes dentro de Webflow (Navbar, Footer, todo lo reutilizable) y los importas a tu proyecto Next.js como componentes React. Sobre el papel mantienes el Webflow Designer para lo visual y ganas un CMS sin límite vía código.
En la práctica todavía no lo he llevado a producción. Webflow Cloud es reciente, la superficie está en movimiento y prefiero no asumir esos bordes ásperos en un producto cliente. Cuando el CMS sin límite es realmente crítico, mi default es alojar la app Next.js en Vercel y apuntar el reverse proxy desde tu dominio Webflow. La UI se construye directamente en Next.js (sin importar componentes vía DevLink), así la capa que más impacta en performance, accesibilidad y SEO queda totalmente bajo tu control. Volveré a evaluar Webflow Cloud cuando tenga más recorrido.
No SEO-friendly: El Stack WWX
Si tu contenido no necesita ser indexado, por ejemplo, todo lo que se encuentra dentro de un área restringida o solo para miembros, y quieres quedarte en Webflow, puedes combinarlo con Wized (lógica client-side) y Xano (backend y base de datos), comúnmente conocido como el stack WWX.
Wized te permite obtener datos de Xano e inyectarlos en tus componentes de Webflow, evitando el CMS por completo. Dado que el contenido se carga en el lado del cliente mediante JavaScript, no estará disponible de inmediato para los crawlers de los motores de búsqueda1, pero esto no es un problema para dashboards, portales de miembros y herramientas internas.
Por mi experiencia este stack solo tiene sentido para pequeños añadidos dinámicos sobre un sitio Webflow: un formulario a medida, renderizar datos de una API, una sección gated ligera. Para algo más custom (auth real, lógica multi-rol, varias integraciones que dialogan entre sí) las contrapartidas se acumulan rápido: los tests se quedan en verificación manual, la arquitectura está estrechamente acoplada al layer de renderizado de Webflow, y las apps complejas se vuelven más difíciles de mantener al crecer. Para productos que apuntan a ese nivel de complejidad, defaulteo a un stack de código desde el día uno.
Enfoque Custom: Arquitectura Basada en Código
Un stack de código (Next.js + Supabase es a lo que defaulteo) elimina la restricción de plataforma del todo. Tienes contenido sin límite, modelos de datos a medida, control de versiones, tests automatizados y un pipeline de deploy que pilla bugs antes que los usuarios. Lógica multi-rol, integraciones con cualquier API, renderizado SEO en el servidor: todo bajo tu control, sin pelearte con el techo del visual builder.
Por qué un stack de código compensa a largo plazo
SEO listo de serie
Las páginas se renderizan en el servidor, así que Google las recibe listas para indexar en cada visita.
Tests automatizados
El código se verifica antes de cada release y detecta regresiones antes de que los usuarios las vean.
Acceso por roles granular
Cada usuario ve solo lo que su rol permite, con permisos aplicados directamente en la base de datos.
Cualquier integración, sin intermediarios
Conecta directamente con cualquier API, con lógica de retries y sync en tiempo real, sin Zapier ni pegamento de terceros.
Revisión de código y rollback
Un flujo Git con revisión de PR y rollback inmediato te da una red de seguridad para cada release.
Sin techo de plataforma
Registros sin límite y modelos de datos a medida permiten que contenido, campos y lógica crezcan con el producto.
El coste es real: experiencia en desarrollo, timeline inicial más largo, y un cambio de mentalidad de "edito contenido en un CMS" a "publico features en releases". En la primera plataforma de Unobravo fuimos por esta vía desde el día uno. Algunas partes se han reescrito desde entonces, pero esa arquitectura inicial demostró ser una base sólida sobre la que siguieron construyendo a medida que el producto se convertía en lo que es hoy.
Preguntas Frecuentes
¿Cuál es el límite del CMS de Webflow?
El límite de ítems del CMS de Webflow depende de tu plan: 2,000 ítems en el plan CMS, hasta 20,000 en Business y límites a medida en Enterprise. El plan Básico no incluye acceso al CMS.
¿Cuáles son los límites de colecciones y de campos?
En el plan CMS obtienes 20 colecciones, en Business 40. Cada colección soporta hasta 60 campos sin importar el plan.
¿Puedo aumentar el límite sin actualizar al plan Enterprise?
Sí. Si tu contenido no necesita ser indexado por SEO, puedes eludir el límite por completo moviendo tus datos a una base de datos externa y cargándolos en el cliente (ej. Webflow + Wized + Xano) o construyendo una aplicación completamente custom (ej. Next.js + Supabase). Si es necesario el SEO, puedes automatizar la eliminación de ítems antiguos para mantenerte por debajo del límite o utilizar un Proxy inverso nativo (Webflow Cloud) con un Headless CMS para mostrar páginas ilimitadas en tu dominio de Webflow.
¿Qué pasa cuando llego al límite de ítems de Webflow?
Webflow te impedirá añadir nuevos ítems a cualquier colección hasta que borres ítems, mejores tu plan, o saques el contenido a una base de datos externa.
¿Es bueno el CMS de Webflow para una web grande?
Para proyectos con hasta 20,000 elementos indexados por SEO, funciona bien. Para cifras superiores, necesitarás el plan Enterprise, un proxy inverso nativo de Webflow Cloud con un CMS Headless, o una arquitectura completamente custom basada en código que elimina las restricciones de plataforma.
Cómo elegiría yo, en un minuto
- Bajo 20k ítems, SEO importa, baja complejidad de producto → quédate en el CMS de Webflow. Añade automatización si te acercas al tope.
- Contenido público, SEO obligatorio, escalando más allá de 20k → el reverse proxy nativo de Webflow Cloud + headless CMS es el camino oficial, pero todavía es reciente. Mi default es alojar Next.js en Vercel y hacer reverse proxy desde tu dominio Webflow, con la UI construida directamente en Next.js (sin imports vía DevLink), hasta que Webflow Cloud acumule más kilómetros en producción.
- Contenido privado o de dashboard, sin SEO → Wized + Xano. Rápido de montar, válido para áreas para miembros.
- Actualizaciones frecuentes, lógica multi-rol, integraciones complejas → Next.js + Supabase. Mayor coste inicial, el techo más alto a largo plazo.
Si dudas entre dos de estas opciones, la pregunta rara vez es sobre el CMS. Es sobre lo complejo que será tu producto dentro de 12 meses. Si no lo tienes claro, encantado de mirar tu caso: reserva una llamada estratégica gratuita.
Footnotes
-
Para ser exactos, desde 2014, Google ha afirmado ser bastante hábil leyendo contenido JavaScript, pero ha aconsejado mantener cierta precaución ya que la lectura precisa no siempre está garantizada. Si tienes problemas en tu JS o da errores, Google será incapaz de revisar e indexar tu sitio web. Por esta razón la mejor manera siempre debe ser utilizar un generador desde el servidor porque siempre presentarán las páginas y sus partes con los motores limpios y finalizados sin la necesidad de tener ninguna implicación extra de JavaScript. ↩
