I've been using Webflow for years for all my projects. It had a real impact on iteration speed and worked nicely with automation workflows. And yet, since generative AI came into play, things have changed.
Today I have a reasons to think that the web builders era comes to the end, at least in their current form. AI Agents has became too capable, so the visual building is much slower than iterating over the actual code with natural language. But what's even more important is the environment in which agents can navigate easier, bringing value way beyond the building the web, but also morph into the various business areas.
Below is an overview of the migration process for my product's website, easy.tools, so you can learn from my mistakes.
#Overview
The website had 924 pages in two languages. To be exact:
- 415 documentation pages
- 129 feature pages
- 110 blog posts
- 53 changelog entries
- 25 product pages
- and others
Most of the pages were CMS-based (21 collections), and we had ~40 page templates. There were also ~6,000 assets, mostly blog images. Beyond the content itself, SEO was critically important, especially since we had started to see real results after months of work.
The goal was to move from the Webflow to the Markdown-based static website for which I picked astro.build framework.
#Documentation & Blog only
The main driver behind the migration was the documentation and blog posts. We struggled with managing the content, especially because of the need for internal links and interdependencies between documentation pages. Our team is just a couple of people, and some of us had to spend way too much time navigating the CMS, yet we still felt blocked in many ways.
The initial idea was to migrate the documentation and maybe the blog, leaving everything else in Webflow. But we were afraid of the SEO impact, and increasingly capable agents also made us consider a redesign of the entire website, which would be much easier to do outside of Webflow.
#Content Migration
I had to get the content out of Webflow, so I picked three different data sources:
- Webflow Code Export: that brought 85 files (21 CMS, 64 pages) and 762 images.
- Webflow Docs CSV export: that brought two files, one for each of the PL and EN versions of the content.
- Live-site crawl: I asked an AI agent to understand the page and write a script to crawl the entire website. Beyond the content, I asked for a JSON object that gave me URLs, metadata, headers and Webflow metadata. The crawler didn't download the assets though, that was done later.
All three sources became the foundation for the migration, but for the actual cloning I also needed the styles and computed properties, which were probed from the browser. In fact, the agent used the dev-browser CLI to autonomously compare the Webflow website with the migrated version.
#Migration Waves
The migration started with setting up the Astro project, where the agent knew the big picture: that we were migrating from Webflow, that an exact, possibly pixel-perfect clone was needed, and that keeping SEO intact was the top priority.
Once the project scaffold was roughly done, I focused on making the structure mirror the original website. Styles and page structures weren't really important at that stage, but file organization was, along with their settings and the core areas such as landing pages, blog, resources and documentation.
Up to this point everything went smoothly, as the agent (powered by Opus 4.8 and GPT-5.5 back then) handled almost all of it autonomously. The much harder part was getting the styling right. Here the most important thing was to connect the agent to the browser through the dev-browser CLI and let it go page by page to clone all the details.
There was an issue with that. Every page was cloned separately, and since most pages share similar components and styles, at some point the agent couldn't manage changes across all the page types and the styling drifted a lot.
I took a step back here and asked the agent to scan the various types of pages we had and, looking from a broader perspective, to identify the similarities and sketch out the common components. The second part of the task was to probe the design system settings related to typography, color palette and general rules such as spacing.
With that in place, the agent worked on the details of all the identified components, and when that was finished, it went back through the pages it had worked on before and wired up the components along with the styling.
At this point most of the migration was done, but since SEO mattered so much to me, I asked the agent to list all the things that often go wrong during a website migration. That knowledge was then used to prepare dedicated reports and statistics covering URL structure, metadata, headers and details such as alt text for images.
The final stage was a deployment. I've decided to go with Cloudflare Pages, and since I wanted a full automation, I asked it to setup a connection with GitHub repository. This made a new website available on a temporary domain, where me and our team went through a few iterations that focused mainly on the layout drifts and some visual inconsistencies.
Meanwhile, since I wanted to move away from Webflow entirely, I asked an AI agent to find all the assets based on their URLs and download them to my Mac. It was a few gigabytes of content, which was then optimized and uploaded to Cloudflare R2. The agent handled nearly all of this zero-shot.
Lastly, I needed to wire up the actual domain. Since DNS changes can sometimes take a while, I asked AI for help. First, I had it scan the existing domains to understand the setup, providing screenshots of the domain configuration when needed. This led us to a rewiring plan, so I simply followed the model's instructions. Everything went smoothly, with zero downtime.
#Unlocks
Since the entire easy.tools platform lives at app.easy.tools, the website itself is kept in a separate repository. This makes deployment straightforward, and because the site consists mostly of static pages, there aren't many scenarios where something can go wrong. Given the capabilities of current AI agents, even non-programmers can make edits simply by asking for changes.
And this is where the fun begins.
#Chatbot
The fact that all the documentation and resources are now just text files makes them a natural source of knowledge for our online chatbot. It can answer product-related questions, and because the documentation is now more detailed and stays up to date, the chatbot is actually useful. If something falls outside its scope, the user is quickly redirected to our support team.
#Daily Updates
Our team writes daily updates on Slack. One of the agents scans them, connects them with Linear issue descriptions and GitHub releases, and suggests documentation changes that we can either accept directly or prepare together with the agent.
#Communication
We work asynchronously and have one online meeting every two weeks, focused on exchanging knowledge and shaping future sprints. The meeting is recorded, and its transcription becomes another source of suggestions for our documentation and resources.
Similarly, we often use Loom-like recordings in our daily communication to explain what we've done. Some of these videos describe functionality shortly before or after its release. The agent watches them and extracts descriptions and screenshots for the documentation.
#Newsletter
We send a monthly product newsletter to our users. Until now, it was prepared mostly manually, with some automation helping us gather insights. The process is still human-driven, but its source of knowledge is becoming nearly autonomous.
Moreover, we no longer just tell users what we've built. Everything is properly documented, so anyone interested in the details doesn't have to wait for us to update the documentation.
#Announcements
Most features get announced on social media. This creates another opportunity to easily gather information about what we've shipped and understand each feature more deeply, allowing us to communicate its value more effectively.
We can also better understand how a given feature relates to things we've built in the past, because the agent can quickly find and grasp whatever context it needs.
#SEO
Adding a blog post was extremely time-consuming, especially when handling SEO details such as alt text, internal links and shortlinks. Much of that time went into managing the Webflow CMS, as publishing wasn't just about updating a single article. It also meant adding links across many existing pages.
Despite the priority we placed on SEO, properly connecting all the existing content was nearly impossible. Now, the agent handles the entire process. We give it the raw article we've written, and it prepares and publishes it properly.
#Takeaway
You can see the results at easy.tools. If you have a website built with Webflow or WordPress and see value in moving it to a Markdown-based framework such as Astro or Next.js, below you'll find a list of steps designed with an AI agent in mind.
These steps will help the agent guide you through the process. Still, you need to remain involved, especially during fragile stages such as SEO and DNS migration, as well as when refining the website's details.
-
Goal. Define what is being migrated, the target stack, the expected level of visual parity and what must remain unchanged.
-
Data Sources. Gather platform exports, CMS or API data, sitemaps, SEO reports, analytics and any existing code or asset archives.
-
Crawling. Crawl the live website to capture its URLs, content, metadata, headings, links, language versions and assets.
-
Mapping. Group the pages into collections, recurring templates, custom experiences and shared sections.
-
Structure. Plan how content, layouts, components, localization, styling and deployment will work in the new stack.
-
Route Mapping. Connect every existing URL to its new route, an approved redirect or an intentional removal.
-
Design System. Extract the typography, colors, spacing, grids, breakpoints, effects and interaction patterns from the existing website.
-
Shared Components. Identify recurring sections and turn them into reusable components before page-by-page implementation starts to drift.
-
Migrate in Waves. Complete one representative page from each family, validate it and then apply the pattern to related pages.
-
Assets and Integrations. Move images, fonts and downloads while rebuilding forms, search, analytics, embeds and third-party scripts.
-
Validate as You Go. Compare content, layout, responsive behavior, interactions, accessibility and performance throughout the migration.
-
Audit SEO. Check routes, redirects, metadata, canonicals, hreflang, headings, internal links, structured data and sitemaps separately.
-
Deploy to Staging. Publish the new website to a temporary environment where the team can review real pages and critical user journeys.
-
Plan the Cutover. Prepare the DNS changes, final production checks and a rollback path before switching traffic.
-
Monitor the Launch. Crawl the production website and monitor indexing, traffic, errors, performance and conversions after the switch.
And that's pretty much it. As you can see, the process isn't straightforward, but it's also much simpler than it seems because almost everything can be handled autonomously by the agent. It is time-consuming, but it unlocks so many possibilities that it's simply worth it.
