El CMS de Webflow limita el número de ítems, colecciones y campos que puedes usar dependiendo de tu plan: 2,000 ítems en el plan CMS, hasta 20,000 en Business, y límites personalizados en Enterprise. Si has alcanzado — o te estás acercando — a uno de estos límites, aquí tienes todo lo que necesitas saber y las mejores formas de solucionarlo.
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)
La solución más sencilla que te mantiene dentro de Webflow es continuar utilizando el CMS de Webflow y crear una automatización para eliminar los ítems del CMS que ya no son necesarios y almacenarlos en una base de datos externa (por ejemplo, si un ítem no necesita ser público después de X días). Alternativamente, puedes actualizar al plan Enterprise de Webflow (que puede costar entre $15k y $60k al año). Esta limitación existe porque el contenido amigable con el SEO debe generarse en el backend, y dentro de Webflow, esto solo es posible usando su CMS integrado.
2. Reverse Proxy (Proxy Inverso)
Un proxy inverso te permite alojar tu contenido en una plataforma externa—como una aplicación en Next.js—mientras lo hace aparecer de manera perfecta bajo tu dominio principal de Webflow. Por ejemplo, podrías servir tusitio.com/blog desde un servidor completamente separado sin que tus visitantes noten la transición.
Dado que el contenido vive fuera de la infraestructura de Webflow, esto elimina de manera efectiva el límite de ítems del CMS mientras mantiene todo completamente amigable con el SEO.
La Experiencia de Edición de Contenido Una de las principales preocupaciones al alejarse del CMS de Webflow es perder su editor intuitivo. Afortunadamente, al usar un framework externo, puedes conectar fácilmente un Headless CMS (como Payload, Sanity o Contentful). Esto permite a tu equipo de contenido continuar gestionando artículos a través de una interfaz dedicada y fácil de usar que es igual de buena—si no mejor—que la de Webflow, mientras el frontend permanece completamente integrado bajo tu dominio de 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.
Aún mejor, resuelve el inconveniente de la interfaz de usuario. Al usar Webflow DevLink, puedes diseñar componentes visualmente dentro de Webflow (como tu Barra de navegación y Pie de página) e importarlos directamente a tu proyecto de Next.js como componentes de React. Esto te da lo mejor de ambos mundos: una escalabilidad infinita para el contenido de tu CMS a través de código, mientras mantienes tus componentes visuales perfectamente sincronizados con el Webflow Designer.
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.
Este enfoque funciona bien para muchos proyectos, pero tiene algunas limitaciones: los tests se limitan a verificaciones manuales, la arquitectura está estrechamente ligada a la capa de renderizado de Webflow, y gestionar una aplicación compleja puede volverse más difícil con el tiempo.
Enfoque Custom: Arquitectura Basada en Código
Para proyectos que necesitan una base más robusta y escalable — ya sea que el SEO sea necesario o no — un enfoque basado en código elimina las restricciones de plataforma por completo. Usando un framework como Next.js combinado con un backend como Supabase (o cualquier stack moderno), obtienes:
- Datos ilimitados — sin límites de ítems ni de colecciones
- SEO-friendly por defecto — a diferencia del stack WWX, Next.js soporta generación estática (SSG) y server-side rendering (SSR), así que tu contenido es completamente renderizado e indexable por los motores de búsqueda
- Tests automatizados — tests unitarios, tests de integración y pipelines de CI/CD para detectar errores antes de que lleguen a producción
- Control arquitectónico completo — API routes, estrategias de caché y funcionalidades en tiempo real
- Escalabilidad del equipo — control de versiones, code review y flujos de trabajo de desarrollo establecidos que crecen con tu equipo
Este camino requiere experiencia en desarrollo, pero el resultado es un producto que escala de forma predecible sin restricciones de plataforma. Si tu proyecto está creciendo más allá de lo que los constructores visuales pueden manejar — actualizaciones frecuentes, flujos de usuario complejos o múltiples integraciones — este es el enfoque que da mejores resultados a largo plazo.
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.
En resumen
Si tu objetivo es generar contenido SEO amigable y estás por debajo del límite de 20k ítems, la mejor opción es usar el CMS de Webflow. Si el SEO no es tu prioridad y quieres quedarte en Webflow, el stack WWX (Wized + Xano) te permite eludir el límite en el cliente. Si quieres seguir usando Webflow para el diseño pero necesitas contenido SEO ilimitado, un proxy inverso nativo vía Webflow Cloud combinado con DevLink y un Headless CMS te da lo mejor de ambos mundos. Y si necesitas una base completamente robusta, testeable y escalable — con o sin SEO — una arquitectura basada en código (como Next.js + Supabase) te da control total, tests automatizados y ninguna restricción de plataforma.
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. ↩
