How I Moved Polyform Off Webflow and Built a Safer AI Website Workflow

If you are a startup founder or operator who still owns the marketing site, this is the migration I wish someone had shown me. I overcomplicated it the first time I explained it. The actual first pass was simpler: I downloaded Polyform's Webflow ZIP and CMS CSVs, gave them to Codex, and asked it to keep working until the site ran as a static Astro project in GitHub.

For Polyform, that first static migration took less than a day. Cloudflare Pages currently bills our level of static-site usage at $0, instead of the couple hundred dollars a month we were spending on Webflow. That is one founder's experience, not a universal cost or timing promise. Your result depends on the site, hosted features, traffic, and services you choose.

This guide is for a basic marketing site: pages, blog posts, images, styles, and ordinary browser interactions. Webflow does not include working forms, site search, ecommerce, user accounts, or other hosted features in a code export. Get the static site looking and navigating correctly first. Move those dynamic features separately after you know which ones you actually need.

Download the Webflow ZIP and CMS CSVs

Webflow's official code-export guide says code export is available on paid Workspace plans. In the Designer, open the main menu, choose Code export (or press Shift + E), select Prepare ZIP, and download the archive.

That ZIP contains the visible site: HTML, CSS, JavaScript, and assets. Leave it zipped or unzip it into a folder Codex can access.

Next, export each CMS Collection. Webflow's CMS import and export guide describes the path: open the CMS panel, select a Collection, and choose Export. Do this once for every Collection and every locale you need.

Put the ZIP and all the CSVs in one folder. The CSVs may point to images and files still hosted by Webflow, so ask Codex to download those assets into the new project before you cancel Webflow.

Do not cancel Webflow yet. Keep the old site live while the new one is being built and reviewed.

Give the files to Codex and let it build

If you already use GitHub, make sure Codex can access it. If you do not, create a GitHub account. In a terminal, run gh auth login and follow the browser sign-in. Once GitHub is connected, open the folder containing the export in Codex and paste this:

I exported my marketing site from Webflow. The Webflow ZIP and all CMS CSV files are in this folder.

Create a new Astro project from these files and put it in a new GitHub repository. If GitHub is not authenticated, stop and show me how to authenticate it. Ask me whether the repository should be public or private before creating it.

For the first version, preserve the current site's design, copy, page URLs, navigation, responsive behavior, metadata, images, fonts, and working browser interactions as closely as possible. Convert the CMS CSV content into files the Astro project owns. Download any images or files still referenced from Webflow into the repository and update the links.

This first version should be a static site. Identify forms, search, ecommerce, user accounts, localization, or other hosted features that the Webflow export cannot reproduce. Do not invent replacements or pretend they work. Put them in a short follow-up list.

Keep iterating until:
- the project installs and builds from a clean checkout
- every exported page has a matching route
- internal links and local assets work
- the site looks like the Webflow version on desktop and mobile
- there are no obvious browser-console errors
- the repository includes a short README with the commands to run it

Do not redesign the site or change my live domain yet. When the static site is working, push it to GitHub and give me the repository link, the preview instructions, what you tested, and the list of dynamic features that still need decisions.

That is enough for the first pass. Let Codex inspect the files, write the project, run it, compare the result, and fix problems until the static site works. You do not need to decide the final component system before you can see the new site.

Publish the site and connect your domain

Once the Astro site works, choose where to host it. GitHub Pages and Cloudflare Pages are two common static paths, but they do not have the same usage boundary. In both cases, GitHub remains the source of the site.

Option A: GitHub Pages

GitHub says Pages is not intended or allowed as free hosting for an online business, ecommerce site, or SaaS. For a commercial startup marketing site, use a host whose terms fit that purpose unless you have confirmed that your GitHub Pages use qualifies. If the site does qualify, Astro has an official GitHub Pages setup, and GitHub documents how to attach a custom domain. On GitHub Free, Pages is available for public repositories; private repositories require a paid plan. Review GitHub's current usage limits before proceeding:

Set this Astro repository up for GitHub Pages using Astro's official GitHub Pages workflow. Configure the Astro site and base settings for my repository, make the main branch the production source, and confirm a clean build succeeds.

First deploy to the GitHub Pages URL. Do not change DNS until that URL works and I approve it. Then help me attach [YOUR_DOMAIN] and give me the exact DNS records to add. Verify the custom domain and HTTPS after the DNS change.

Option B: GitHub and Cloudflare Pages

Cloudflare's Astro guide uses npm run build and the dist output directory. Its Git integration can deploy every push and create preview deployments, and its custom-domain guide covers the final domain connection. Codex can run npx wrangler login, which opens Cloudflare's browser authorization. Then paste this into Codex:

Set this Astro repository up on Cloudflare Pages. If Cloudflare is not authenticated, run npx wrangler login and let me complete the browser authorization. If GitHub is not authenticated, walk me through that browser authorization too, then continue.

Connect this GitHub repository to a new Cloudflare Pages project. Use main as the production branch, npm run build as the build command, dist as the output directory, and Node.js 22. Enable branch and pull-request preview deployments. Deploy the current site and give me its pages.dev preview URL.

After I approve the preview, attach [YOUR_DOMAIN]. Inspect the existing Cloudflare DNS records, show me the exact DNS changes you propose, and ask before applying them. Do not modify unrelated DNS records or domains. After approval, apply the minimum changes and verify the production URL and HTTPS work.

With either option, open the temporary URL before mapping the domain. Check the homepage, navigation, a few inner pages, a CMS page, images, and mobile layout. Keep Webflow available until the new production domain works.

Clean up the exported code after production works

The first version should look right, build, and serve the correct pages. It does not need to be elegant. Webflow exports often contain repeated markup, generated class names, and JavaScript you may no longer need. Once the new production site is stable, ask the AI to simplify the implementation without redesigning it:

This Astro site was migrated from Webflow and is now working in production. Clean up the underlying code while preserving the current design, copy, URLs, metadata, responsive behavior, and working interactions exactly.

Find repeated page markup, styles, scripts, navigation, footers, metadata, and content patterns. Replace them with the smallest useful Astro layouts, components, content collections, data objects, or helper functions. Prefer simple functions and data structures; only introduce classes when they clearly improve the design. Remove unused Webflow code and dependencies in small, testable steps.

Before changing anything, capture the current behavior and representative desktop and mobile screenshots. Work in a new branch. After each cleanup group, run the build and compare the affected pages. Do not combine this with a visual redesign. Finish with a pull request that explains what was consolidated, what was removed, the checks that passed, a preview URL, and anything intentionally left alone.

Teach the repository how you want AI to work

Now make the setup durable. Write down your voice and design rules. Add an AGENTS.md file so Codex sees the repository's commands and expectations before it starts. Add previews so every change can be reviewed at a URL before it reaches production.

Our Polyform repository uses two Cloudflare workflows. A push to main installs dependencies with Node.js 22, runs the complete validation command, and deploys dist. The preview workflow validates a reviewed branch, refuses to run as a production deployment, includes the source branch and commit in the preview name, and publishes the immutable deployment URL. That last detail came directly from reviewing our setup: a reusable branch alias can change later, while an immutable URL keeps showing the exact commit you approved.

Productionize this repository so I can safely manage the website with Codex.

1. Create a short voice-and-style guide from the existing site. Describe the audience, tone, words we use and avoid, page structure, design rules, and examples. Do not invent new positioning.
2. Create AGENTS.md using OpenAI's official guidance. Explain the project structure, how to run it, the content model, required checks, visual-review sizes, branch and pull-request workflow, and the rule that production changes only after review.
3. Add GitHub Actions for Cloudflare Pages like this site's setup:
   - production: on pushes to main, use Node.js 22, run npm ci, run the complete validation command, and deploy dist with Wrangler
   - previews: validate the reviewed branch, never deploy main through the preview workflow, use a preview name containing the branch and commit, and publish the immutable Cloudflare deployment URL
4. Document the required CLOUDFLARE_ACCOUNT_ID repository variable and CLOUDFLARE_API_TOKEN secret. Never print or commit secret values.
5. Update the README with the complete change loop: ask Codex for a change, work on a branch, run checks, open the preview, review it, then merge.

Implement this on a new branch, run the checks, open a pull request, and give me the immutable preview URL. Do not merge or deploy production for me.

The deeper lesson is accountability, not automation

That is the payoff. The website becomes a normal project you own. You can ask Codex to add a page, rewrite copy, fix mobile spacing, publish an article, or clean up a component; it can make the change, run the checks, and hand you a preview.

But the useful part is not that AI can edit files. It is that the source, instructions, tests, visual review, preview, and deployment path are connected, and a person still decides whether the result is correct. That is the same operating principle we use at Polyform: give AI trustworthy context and a bounded path to complete work, then keep an accountable human in the validation and ownership loop.

References and further reading

• Webflow: Export your site's HTML, CSS, JavaScript, and assets
• Webflow: Export CMS Collection items as CSV
• GitHub: Create an account
• GitHub CLI: Authenticate with GitHub
• Astro: Deploy to GitHub Pages
• GitHub: Manage a Pages custom domain
• GitHub: Pages limits
• Cloudflare: Deploy an Astro site to Pages
• Cloudflare: Git integration and preview deployments
• Cloudflare: Pages custom domains
• Cloudflare: Pages limits
• Cloudflare: Authenticate Wrangler in your browser
• OpenAI: Give Codex repository instructions with AGENTS.md