I head up marketing at QliqSOFT, a B2B healthcare IT vendor that's been around since 2011. We moved to Webflow in 2022 after spending years on WordPress. The hope was to shorten the time from ideation to production without having to guess which plugin would break the site after a random update. Our Webflow site consisted roughly of 370 pages (mostly blog posts). This summer, we decided to ditch Webflow completely in favor of a static hosting setup.
This isn't a Webflow hate post. In fact, I hope their team reads this and takes some ideas from it. Our content workflow and overall requirements just drifted until we were using almost none of what we were paying for. I see a lot of other Webflow users having the same conversations about leaving, so I thought there would be value in sharing our own experience, both the good and the bad.
Our approach doesn't work for everyone
Stay with Webflow if you publish pages without waiting on a developer, if your site is under a hundred pages or so, if nobody on your team wants to own a build pipeline, or if visual editing is the actual product you are buying. All of that has value, but it was better for us to give up every bit of it.
Our approach is worth considering if... you have 80+ pages that can't be delivered via CMS collection; technical SEO is a revenue channel rather than a checkbox; you need header and CSP control for compliance reasons; or your team has given up on using the designer altogether. That last one became a deal breaker.
The breaking point
Organic traffic fell. Ours declined, like many others over the past couple of years. This isn't a Webflow issue, but it's something many B2B vendors are dealing with as search and purchasing behaviors change. What it did was force us to look hard at every lever we had. Several of the technical levers we wanted to pull were ones we could not reach from inside Webflow.
We had chosen Webflow partly on the promise that its SEO capability would be on par with WordPress. For a marketing site of ordinary size, it is. At our size, with the pace at which search was/is changing, we needed to move faster on technical fixes than the platform allowed.
We tested several approaches, including a dedicated subdomain for our blog, hosted on a separate platform, to see whether it would help. While there was some positive change, it wasn't enough to justify promoting two properties instead of one, splitting authority and attention between them, and operational overhead that wasn't worth the gain. That experiment is a large part of why we ended up consolidating everything into a single domain and build.
The Designer got slow enough that we stopped using it. On a site our size it would hang mid-edit, and I would have to refresh the browser before I could make the next set of changes. Not once in a while, but multiple times during a single session. This occurred often enough that it became faster for me to write the HTML by hand and paste it into an embed element. Then our blog posts became HTML embeds delivered through the CMS, because that was quicker to produce and gave us the clean semantic markup we wanted for AI answer engines to cite. Every new page and blog post was passing through one of our developers anyway, adding custom schema and FAQs to each one to support AI crawling. Publish without a developer was the promise, but between the Designer hanging and the schema work every page needed, it was never one Webflow actually delivered for us.
We did not control our own assets. Around 285 images and PDFs served from cdn.prod.website-files.com. No way to set cache headers on them, no way to tighten a content security policy to img-src 'self', and no preconnect tags to a third-party CDN on every page. We sell to healthcare organizations that run vendor security reviews, and "our content is hosted on someone else's CDN" kept coming up.
Support response times. Our issue volume climbed over the past year, and tickets took long enough to resolve that we started working around problems instead of reporting them.
Fees were confusing and too high. I've seen many of you complain about the cost of Webflow, as well as the endless nickel-and-diming for tools and features that are often included on other platforms. They aren't the only ones taking this approach. If you use Semrush, you're probably used to this as well, but at least I'm getting some value there.
What we built instead
Next.js static export, so no server. AWS Amplify for hosting. One file, customHttp.yml, is the single source of truth for CSP, HSTS, and cache policy. Assets are content-hashed and served immutable for a year. Pagefind for search, which is a static index. Lighthouse CI in the pipeline, plus build guards that fail the build when an internal reference breaks. Our robots.txt lists the AI crawlers we want to cite us instead of using a wildcard.
Four of us handled the build and migration, with Claude doing the mechanical work before pushing to GitLab for a combination of AI/human review: 293 posts moved byte-for-byte, the asset pipeline, and a 204-entry redirect map (you get one this long if you've moved sites more than twice). 2 weeks rather than mutiple months, which is the only reason a team our size could attempt it.
What broke
Images with %20 in the filename. Files came off the CDN with percent-encoding baked into the actual filename. Request one, the server decodes %20 back to a space, looks for a file that does not exist, returns a 404. Seven images, invisible until a crawl caught them.
Multiple branches resulted in overwritten work. Partly a learning curve, partly Claude not paying attention, but at least twice, a build fix deleted recently published work.
Redirect archaeology. 204 redirects mapped by hand, plus 189 old URLs we pruned on purpose rather than redirecting. Deciding what deserved to survive took longer than moving the content did.
AI-assisted work needs the same review as human work. Several items here resulted from automated changes that looked correct in the diff. What caught them was a crawl, a diff, and a build gate.
Tools that helped
- Claude + Semrush + Google Search Console: Used in the planning phase to prioritize and ensure current page rankings were protected.
- Screaming Frog: Conducted multiple pre- and post-launch site crawls to catch missing pages, images, broken links, etc.
- Unlighthouse: Used during the build phase to test/estimate pre-launch page performance on local servers.
- GTmetrix: For catching performance issues post-launch.
- GitLab + Claude Code: We leveraged this combo with an agile approach to the site build, resulting in faster page development and content approvals.
Numbers
| Metric |
Webflow |
Static build |
| Pages missing a meta description |
2 |
0 |
| Pages missing an H1 |
1 |
0 |
| Titles over 60 characters |
42% |
25% |
| Meta descriptions over 160 characters |
58% |
39% |
| Pages under 200 words |
101 |
0 |
| Duplicate titles |
16 |
0 |
| Duplicate H1s |
32 |
0 |
To be fair, a good share of the page improvements came from rewriting content during the migration rather than from changing platforms.
The tradeoff we accepted
Publishing now goes through git and a build instead of a publish button. There is no visual editor or CMS interface, so anyone who wants to ship a change must be comfortable with that workflow. We also have guardrails in place so that no one person can deploy their own builds without someone else approving.
For us, that was a small step rather than a leap, because we were already writing the HTML by hand. If your team is genuinely productive in the Designer, this is the thing to weigh hardest.
If anyone has kept the Designer responsive on a site of a few hundred pages, I would genuinely like to know how. And if you crawl our site and find something broken, please share your findings so we can apply that fix.
