What is Webflow?
If you're reading this article, it's very likely that you're already familiar with Webflow, but let's review to better understand if this is the right solution for you.
Webflow is a visual builder for creating web interfaces and websites. To achieve this, it offers various tools, including the Webflow CMS, which allows you to generate pages using the same page template and modifying the content. The most common example is a blog, where the page style remains the same while the content changes. The main purpose is to be read by search engine crawlers like Google for indexing.
Specifically, it is excellent for managing public content that needs to be SEO-friendly. So, the question we need to ask is whether the content of this collection needs to be public, easily discoverable by Google, or if it's not necessary.
Solution 1: SEO-friendly
If our content needs to be public and easily indexed by search engines, but we have reached or are close to the 10,000 items limit in Webflow CMS, the only way currently is to continue using Webflow CMS and create an automation to remove items from Webflow CMS that are no longer needed and store them in an external database. For example, if an item doesn't need to be public after x days. Alternatively, upgrade to the Enterprise plan of Webflow (which can cost from 15k to 60k per year) because the content needs to be generated on the backend, and if we use Webflow, we can only do it with their Webflow CMS.
Solution 2: Non SEO-friendly Content
If it's not necessary for the content to be indexed, for example, all the content in a restricted area, there are other solutions without the need to upgrade to the enterprise plan, saving a lot of money.
The best solution, in my opinion, is to use the WWX stack because it is scalable and robust. However, unlike the first solution, it is more advanced and may be more complex for those unfamiliar with web development. Let's first look at the individual tools and then see how they work together to solve the 10k limit problem.
WWX stands for Webflow, Wized, and Xano.
Wized
Wized is similar to Webflow but for creating front-end logic. It allows you to create requests, conditions, and many other features to add dynamism to your Webflow project. It should not be confused with Zapier, which works on the backend. Wized generates JavaScript and operates in the browser.
Xano
Xano is, in my opinion, the best no-code tool for building a backend. It includes backend logic similar to Zapier and a database. Xano was built with scalability and security in mind.
Webflow
The most powerful no-code tool for creating web interfaces and websites.
How it works
As you can see in the image, we use Webflow to create the site and its various components. We then convert these components into Wized elements to use them within Wized. On Wized, we can retrieve data from Xano or other databases or platforms and then insert that data into Webflow. This way, we can eliminate Webflow CMS and consequently the 10k item limit!
Unlike Webflow CMS, which generates content on the backend where Google finds the content ready, with Wized, the content is generated on the client side. This means that Google won't find the content ready because the Wized JavaScript script that retrieves the data needs to run first.* This is why it's excellent for creating web apps or dynamic websites. If we need to generate SEO-friendly content, it's better to use the Webflow CMS.
To Recap
If your goal is to generate SEO-friendly content, the best option today is to stick with Webflow CMS. If you don't need it, you can use Wized and Xano to generate the content client-side.
Bonus
The Wized team has server-side rendering in its roadmap. This way, we'll be able to generate SEO-friendly content with Wized as well, but for now, there's no information on when it will be released. To stay updated, subscribe to the NOCODEPRO newsletter
# To be exact, since 2014, Google has claimed to be quite skilled in rendering JavaScript websites but has always advised caution on this topic because it may not always be able to do so. If the JavaScript code is incorrect or generates errors, Google may not be able to render it. Therefore, if we want to ensure that crawlers can read the content, the best and safest option is still server-side rendering because the content is generated on the server side and arrives clear to the crawlers without them having to interpret it.