Il CMS di Webflow ti blocca a 2.000 elementi nel piano CMS, fino a 20.000 nel Business e a misura nell'Enterprise. Se hai sbattuto contro quel muro, hai quattro opzioni reali: restare dentro Webflow con automazione, spostare i contenuti pubblici dietro un reverse proxy, gestire i contenuti privati lato client con Wized + Xano, o ricostruire su uno stack di codice come Next.js + Supabase.
Tutte e quattro le ho montate in progetti reali, inclusa la prima versione di una piattaforma che è poi arrivata a oltre 400.000 utenti. Qui ti spiego come decido quale usare, e il trade-off di cui nessuno parla.
Limiti del CMS Webflow per Piano
| Piano | Elementi CMS | Collezioni |
|---|---|---|
| Basic | 0 | 0 |
| CMS | 2.000 | 20 |
| Business | fino a 20.000 | 40 |
| Enterprise | Personalizzati | Personalizzate |
Soluzioni SEO-friendly
Se i tuoi contenuti devono essere pubblici e facilmente indicizzati dai motori di ricerca, ma hai raggiunto o sei vicino al limite di 20.000 elementi nel CMS Webflow, hai due opzioni principali:
1. Automazione del CMS Webflow (o Piano Enterprise)
Se vuoi rimanere dentro Webflow, il trucco è tenere il CMS leggero. Costruisci un'automazione che archivi gli elementi vecchi su un database esterno quando non hanno più bisogno di essere pubblici, ad esempio dopo X giorni. L'alternativa è passare al piano Webflow Enterprise, che si colloca tra i 15.000 e i 60.000 dollari l'anno a seconda del perimetro.
Il motivo per cui questo vincolo esiste: il contenuto SEO-friendly deve essere generato sul backend, e su Webflow questo passa per forza dal loro CMS.
2. Reverse Proxy
Un reverse proxy ti permette di ospitare contenuti su una piattaforma esterna (tipicamente una app Next.js) tenendoli sotto il tuo dominio Webflow. Il visitatore che apre il-tuo-sito.com/blog non vede il confine, ma il contenuto vive fuori dall'infrastruttura di Webflow. Risultato: il limite di elementi del CMS sparisce, la SEO resta intatta.
L'esperienza di editing
La preoccupazione tipica quando sposti i contenuti fuori da Webflow è perdere l'editor. Nella pratica colleghi un Headless CMS (Payload, Sanity, Contentful) e il team editoriale ottiene un'interfaccia all'altezza di quella di Webflow, a volte migliore. Il frontend continua a caricarsi sotto il tuo dominio Webflow.
Ci sono due modi principali per impostare tutto questo:
Il Reverse Proxy Classico
Storicamente, l'impostazione di un reverse proxy era un processo tecnicamente complesso, richiedeva la configurazione di server esterni, la gestione dei DNS e la manutenzione continua.
Il principale svantaggio: essere ospitati all'esterno di Webflow significava perdere l'accesso al Webflow Designer. La tua piattaforma esterna non condivideva i componenti dell'interfaccia utente nativi di Webflow e i template, quindi dovevi ricostruire il tuo frontend separatamente.
Reverse Proxy Nativo (Webflow Cloud)
Per risolvere questi problemi, Webflow ha introdotto una soluzione di reverse proxy nativa attraverso Webflow Cloud. Questo ti consente di ospitare app basate su codice tradizionale (come Next.js) direttamente all'interno dell'infrastruttura di hosting di Webflow.
Con questo approccio, ti basta semplicemente specificare da quale percorso la tua app personalizzata dovrebbe essere servita (ad esempio, /blog), e Webflow gestisce il proxying nativamente.
Prova a risolvere anche il trade-off lato UI. Con Webflow DevLink, progetti i componenti dentro Webflow (Navbar, Footer, qualsiasi cosa riusabile) e li importi nel tuo progetto Next.js come componenti React. Sulla carta tieni il Webflow Designer per il visivo e ottieni un CMS senza limite via codice.
Nella pratica non l'ho ancora portato in produzione. Webflow Cloud è recente, la superficie si sta ancora muovendo, e preferisco non assorbire quegli spigoli su un prodotto cliente. Quando il CMS senza limite serve davvero, il mio default è ospitare l'app Next.js su Vercel e puntare il reverse proxy dal tuo dominio Webflow. La UI viene costruita direttamente in Next.js (senza import di componenti via DevLink), così il layer che più impatta su performance, accessibilità e SEO rimane completamente sotto il tuo controllo. Riconsidererò Webflow Cloud quando avrà più chilometri in produzione.
Non SEO-friendly: Lo Stack WWX
Se i tuoi contenuti non devono essere indicizzati, per esempio tutto ciò che si trova all'interno di un'area ristretta o riservata agli iscritti, e vuoi restare su Webflow, puoi abbinarlo a Wized (logica client-side) e Xano (backend e database), comunemente noto come stack WWX.
Wized ti permette di recuperare dati da Xano e iniettarli nei componenti Webflow, bypassando completamente il CMS. Dato che il contenuto viene caricato lato client tramite JavaScript, non sarà immediatamente disponibile ai crawler dei motori di ricerca1, ma questo non è un problema per dashboard, portali riservati e strumenti interni.
Nella mia esperienza questo stack ha senso solo per piccole aggiunte di dinamicità sopra un sito Webflow: un form custom, renderizzare dati da un'API, una sezione gated leggera. Per qualcosa di più custom (auth vera, logica multi-ruolo, più integrazioni che parlano tra loro) i compromessi si accumulano in fretta: i test restano manuali, l'architettura è strettamente accoppiata al layer di rendering di Webflow, e le app complesse diventano più difficili da mantenere mentre crescono. Per prodotti che puntano a quel livello di complessità, di default vado su uno stack di codice fin dal primo giorno.
Approccio Custom: Architettura Basata su Codice
Uno stack di codice (Next.js + Supabase è il mio default) rimuove del tutto il vincolo della piattaforma. Hai contenuti illimitati, modelli dati su misura, version control, test automatizzati, e una pipeline di deploy che intercetta i bug prima che arrivino agli utenti. La logica multi-ruolo, le integrazioni con qualsiasi API, il rendering SEO sul server: tutto sotto il tuo controllo, senza dover combattere contro il soffitto del visual builder.
Perché uno stack di codice ripaga sul lungo termine
SEO pronto da subito
Le pagine sono renderizzate sul server, così Google le riceve pronte per essere indicizzate ad ogni visita.
Test automatizzati
Il codice si verifica prima di ogni rilascio e intercetta le regressioni prima che le veda l'utente.
Accessi per ruolo granulari
Ogni utente vede solo ciò che il suo ruolo permette, con i permessi applicati direttamente a livello database.
Qualsiasi integrazione, senza intermediari
Collegamento diretto con qualsiasi API, con logica di retry e sync in tempo reale, senza Zapier o colle di terzi.
Code review e rollback
Un workflow Git con review delle PR e rollback immediato ti dà una rete di sicurezza per ogni rilascio.
Nessun limite di piattaforma
Record illimitati e modelli dati custom fanno crescere contenuti, campi e logica insieme al prodotto.
Il costo è reale: serve esperienza di sviluppo, la timeline iniziale è più lunga, e cambia la testa: da "edito contenuti in un CMS" a "rilascio feature in release". Sulla prima piattaforma di Unobravo abbiamo seguito questa strada dal giorno uno. Alcune parti sono state riscritte nel tempo, ma quell'architettura iniziale si è rivelata una base solida su cui hanno continuato a costruire mentre il prodotto diventava quello che è oggi.
Domande Frequenti
Qual è il limite degli elementi nel CMS di Webflow?
Il limite degli elementi del CMS Webflow dipende dal piano: 2.000 elementi nel piano CMS, fino a 20.000 nel Business e limiti personalizzati nell'Enterprise. Il piano Basic non include l'accesso al CMS.
Quali sono i limiti di campi e delle collezioni su Webflow?
Nel piano CMS hai a disposizione 20 collezioni, nel Business 40. Ogni collezione supporta fino a 60 campi indipendentemente dal piano.
È possibile superare tali limiti senza l'obbligo dei piani Webflow Enterprise?
Sì. Se i tuoi contenuti non devono essere indicizzati dai motori di ricerca, puoi bypassare il limite completamente spostando i dati su un database esterno e caricandoli lato client (es. Webflow + Wized + Xano) oppure costruendo un'applicazione completamente custom (es. Next.js + Supabase). Se la SEO è necessaria, puoi automatizzare la rimozione degli elementi più vecchi per rimanere sotto il limite, oppure usare un Reverse Proxy Nativo (Webflow Cloud) con un Headless CMS per servire pagine illimitate sotto il tuo dominio Webflow esistente.
Cosa accadrà al raggiungimento totale del limite cap Webflow CMS?
Webflow ti impedirà di aggiungere nuovi elementi a qualsiasi collezione finché non elimini elementi esistenti, aggiorni il tuo piano o sposti i contenuti in un database esterno.
È scalabile Webflow verso piattaforme contenuti estese globalmente?
Fino a 20.000 elementi indicizzati funziona bene. Oltre quel limite avrai bisogno del piano Enterprise, di un reverse proxy nativo di Webflow Cloud con un Headless CMS, oppure di un’architettura completamente custom basata su codice che elimina i vincoli della piattaforma.
Come sceglierei io, in un minuto
- Sotto i 20k elementi, SEO conta, bassa complessità di prodotto → resta sul CMS Webflow. Aggiungi un'automazione se ti stai avvicinando al tetto.
- Contenuti pubblici, SEO obbligatoria, scaling oltre i 20k → il reverse proxy nativo di Webflow Cloud + headless CMS è la strada ufficiale, ma è ancora recente. Il mio default è ospitare Next.js su Vercel e fare reverse proxy dal tuo dominio Webflow, con la UI costruita direttamente in Next.js (senza import via DevLink), finché Webflow Cloud non avrà più chilometri in produzione.
- Contenuti privati o di dashboard, SEO non rilevante → Wized + Xano. Veloce da costruire, ok per aree riservate.
- Aggiornamenti frequenti, logica multi-ruolo, integrazioni complesse → Next.js + Supabase. Costo iniziale più alto, soffitto più alto nel lungo periodo.
Se sei indeciso tra due di queste, la domanda raramente è sul CMS. È su quanto sarà complesso il tuo prodotto fra 12 mesi. Se non sei sicuro, sono volentieri disponibile a guardare il tuo caso: prenota una strategy call gratuita.
Footnotes
-
Per essere precisi, dal 2014 Google sostiene di essere piuttosto efficiente nel renderizzare siti JavaScript, ma ha sempre raccomandato cautela su questo tema perché il rendering non è sempre garantito. Se il codice JavaScript contiene errori o genera eccezioni, Google potrebbe non riuscire a renderizzare la pagina correttamente. Pertanto, se vuoi garantire che i crawler possano leggere i tuoi contenuti in modo affidabile, l'opzione migliore e più sicura rimane il rendering lato server. In questo modo, il contenuto viene generato sul server e consegnato già completo ai crawler, senza richiedere l'esecuzione di JavaScript. ↩
