Migrate Your Webflow Site to GitHub

If you have ever tried to answer the question “what changed on the website last Tuesday?” in Webflow, you know the pain. Webflow has a backup system that lets you restore snapshots, but you cannot compare two snapshots. You cannot see a diff of what changed. You cannot branch off to try an experimental redesign without affecting the live site. And if two people edit simultaneously and both publish, the last one wins — silently overwriting the other person’s work.

Git and GitHub solve all of these problems, and they have been solving them for software teams for over fifteen years. Moving your website from Webflow to a GitHub repository is not just a hosting change — it is a fundamental upgrade to how you manage, collaborate on, and deploy your site.

This guide explains what that workflow looks like in practice, how it compares to Webflow’s built-in tools, and every realistic way to get there.

What version control actually means

If you have not worked with Git before, here is the core idea: every change to your website is recorded as a “commit” with a timestamp, an author, and a message explaining what was done. The complete history of every commit is preserved forever. You can go back to any point in time, see exactly what changed, and undo specific changes without affecting anything else.

But the real power is in the workflows Git enables:

Branching

A branch is a parallel version of your site. You create a branch called redesign-pricing-page, make your changes there, and the live site is completely unaffected. You can have ten branches active simultaneously — one for each experiment, feature, or team member’s work — and none of them interfere with each other or with the live site.

In Webflow, every edit happens on the live site (or on a staging environment that costs extra and has limited functionality). There is no way to isolate experimental work.

Pull requests

A pull request (PR) is a proposal to merge a branch into the main site. It shows every change in a clean, reviewable diff format: lines added in green, lines removed in red. Team members can leave comments on specific lines, request modifications, and approve the changes. Only after approval does the change go live.

This is the standard workflow for every software team in the world. It exists because “come look at my screen” does not scale, and because publishing changes without review leads to broken sites.

Deploy previews

When you open a pull request, most hosting platforms (Vercel, Netlify, Cloudflare Pages) automatically build and deploy a preview of that branch at a unique URL. Your team can visit the preview, test it on mobile, share it with stakeholders, and verify everything works before merging.

Webflow offers staging as a paid add-on. Git-based deploy previews are free and automatic for every branch and every pull request.

Surgical rollback

In Webflow, “rollback” means restoring a backup. If three people made changes since that backup, all three sets of changes are lost. You cannot undo just one specific change.

In Git, git revert <commit> undoes a single specific change while preserving everything else. If someone accidentally deleted the pricing section on Wednesday but three other changes were made on Thursday and Friday, you can undo just the Wednesday deletion. Everything else stays.

How a GitHub-based website works

Your website is a folder of files stored in a GitHub repository:

my-site/                          # Git repository root
  src/
    pages/
      index.astro                 # Homepage
      about.astro                 # About page
      pricing.astro               # Pricing page
      blog/
        [slug].astro              # Blog post template
    content/
      blog/
        launching-v2.md           # Blog posts are Markdown files
        year-in-review.md         # Each file = one post
      team/
        jane-smith.md             # Team members as structured data
    components/
      Header.astro                # Reusable header
      Footer.astro                # Reusable footer
      PricingTable.astro          # Component for pricing section
    layouts/
      BaseLayout.astro            # Shared page wrapper
    styles/
      global.css                  # Your styles
  public/
    images/                       # Static assets
    favicon.svg
  astro.config.mjs                # Project config
  package.json                    # Dependencies

Every file is plain text. Every change is tracked. The entire history is searchable. An AI agent can read every file and understand the whole site structure.

The deployment pipeline

The connection between GitHub and your live site is a deployment pipeline, and it runs automatically:

1. You push a commit to the main branch (or merge a pull request)
2. Your hosting platform (Cloudflare Pages, Vercel, Netlify) detects the change
3. It builds your site (compiles Astro/Next.js into static HTML)
4. It deploys the built files to a global CDN
5. Your site is live, typically within 30-90 seconds

You set this up once. After that, deploying is just pushing code. No FTP, no manual uploads, no “publish” button to forget.

Webflow’s workflow vs GitHub’s workflow

Let me walk through common website tasks in both systems so the difference is concrete.

Adding a new blog post

Webflow:

1. Open Webflow Designer
2. Navigate to CMS Collections
3. Click “New Item” on your blog collection
4. Fill in fields: title, slug, body (rich text editor), featured image (upload), category (select reference), author (select reference)
5. Set to “Published”
6. Click “Publish” in the top right to push to production

GitHub:

1. Create a new file: src/content/blog/my-new-post.md
2. Write the frontmatter (title, date, author, image) and body in Markdown
3. Commit with message: “Add blog post: My New Post”
4. Push to main (or open a PR for review)
5. Auto-deploy triggers; post is live in 60 seconds

Or, with an AI agent: “Write a blog post about our Q1 product updates. Use the same format as our other posts.” The agent creates the file, you review, commit, done.

Making a design change

Webflow:

1. Open Designer
2. Find the element on the canvas
3. Edit styles in the style panel
4. Publish — change is immediately live
5. If something breaks, restore a backup (lose all other recent changes)

GitHub:

1. Create a branch: git checkout -b update-hero-section
2. Edit the component file, adjust CSS
3. Commit and push the branch
4. A deploy preview URL is generated automatically
5. Share the preview URL with your team for review
6. Open a PR; team reviews the visual diff
7. Merge when approved; auto-deploy to production

The GitHub workflow has more steps, but each step adds a safety net. You never ship a broken change to production because someone clicked “publish” too quickly.

Handling a broken change

Webflow:

1. Someone publishes a change that breaks the mobile layout
2. You find out from a customer screenshot
3. You go to Webflow Designer and try to fix it manually
4. Or you restore a backup from before the change — but this also undoes other recent work

GitHub:

1. Someone merges a PR that breaks the mobile layout
2. You can see exactly what changed in the PR diff
3. git revert <commit-hash> undoes that specific change in seconds
4. Push the revert; auto-deploy restores the working version
5. Fix the original change in a new branch, test with deploy preview, then merge again

Collaborating with multiple editors

Webflow:

1. Two people open the Designer simultaneously
2. Both make changes to the site
3. Person A publishes their changes
4. Person B publishes their changes — Person A’s work may be partially overwritten
5. No record of who changed what or when

GitHub:

1. Person A creates branch update-pricing
2. Person B creates branch add-case-study
3. Both work independently without interference
4. Both open PRs; each is reviewed separately
5. Both merge independently; Git handles any file conflicts automatically
6. Complete audit trail of who changed what, when, and why

How to migrate your Webflow site to a GitHub repo

1. AI coding agents (recommended for most teams)

This is the most common approach and produces the best results for the effort involved. You use an AI coding agent to crawl your published Webflow site and rebuild it as a clean codebase in a GitHub repo.

Step by step:

1. Create a new private repository on GitHub
2. Clone it locally and scaffold a project: npm create astro@latest
3. Open the project in Cursor, Windsurf, or your preferred AI editor
4. Instruct the agent: “Crawl [your-site.webflow.io], extract all content and images, and rebuild the pages as Astro components using Tailwind CSS. Create content collections for the blog and team sections.”
5. The agent crawls, extracts, and builds. It creates commits as it works, so you can see the progress.
6. Review the output, iterate with the agent to fix styling issues
7. Push to GitHub, connect to Cloudflare Pages or Vercel, and your deployment pipeline is set up

Real-world examples: cursor.com was migrated from a CMS to code in 3 days ($260 in tokens). Prefect.io rebuilt their site in about a week, estimated at 6 weeks with traditional development.

Cost: $0-$500 in AI tokens. Timeline: 1-5 days.

2. AI app builders

Tools like Bolt.new, v0.dev, Lovable, and Replit Agent can generate a codebase from screenshots and conversation. They typically offer direct GitHub integration — you can export the generated project to a new repo.

Best for: Non-developers who want a GitHub repo without managing the technical process. The generated code is standard and can be refined later by a developer or AI agent.

3. Hire a developer

A freelance developer ($1,000-$5,000) or agency ($5,000-$25,000) can handle the migration and set up the GitHub workflow, deployment pipeline, and hosting for you. Many developers now use AI tools internally, so timelines are shorter than they used to be.

Best for: Teams that want a polished result with a proper deployment pipeline set up by someone experienced.

4. Automated migration services

Tools like BrowserCat Migrate and other automated migration services can extract your Webflow site and produce a GitHub repo with deployable code. These handle the initial extraction and scaffolding, giving you a starting point you can refine.

Best for: Getting a quick starting point without spending time on extraction.

5. Webflow API + manual build

If you have a lot of CMS content, use the Webflow API to extract collection items programmatically into Markdown files, then build the design manually or with an AI agent.

// Extract CMS content and write to files for your repo
const items = await fetchWebflowCollectionItems(collectionId);
for (const item of items) {
  const markdown = convertToMarkdown(item);
  fs.writeFileSync(`src/content/blog/${item.slug}.md`, markdown);
}
// git add, commit, push

6. Manual rebuild

Create a GitHub repo, screenshot your Webflow pages for reference, scaffold a project, and rebuild from scratch. Maximum control, most time-intensive. 2-6 weeks typical.

Setting up the GitHub workflow

Once your code is in a GitHub repo, here is how to configure the full workflow:

Connect to a hosting platform

Cloudflare Pages (recommended for static sites):

1. Go to Cloudflare Dashboard > Pages
2. Click “Create a project” > “Connect to Git”
3. Select your GitHub repo
4. Set build command: npm run build
5. Set output directory: dist
6. Deploy

Every push to main auto-deploys. Every PR gets a deploy preview.

Vercel or Netlify follow a similar process — connect GitHub repo, configure build settings, done.

Set up branch protection

Go to your repo’s Settings > Branches > Add branch protection rule for main:

• Require pull request reviews before merging
• Require status checks to pass (build must succeed)
• Do not allow force pushes

This ensures nobody can push directly to main without a PR and review. It is a safety net that Webflow has no equivalent for.

Configure deploy previews

Most hosting platforms create deploy preview URLs automatically for pull requests. A bot comments on the PR with the preview URL. Your team clicks the link, sees the proposed changes live on a real URL, and approves or requests changes.

This replaces Webflow’s staging feature (which costs extra) with something that is free and works for every branch, not just one staging environment.

GitHub features that enhance your website workflow

GitHub Actions (CI/CD)

Automated workflows that run on events. Examples:

• Link checking: On every PR, automatically check that all internal and external links are valid
• Lighthouse audits: Run a performance audit on every deploy preview and comment the results on the PR
• Image optimization: Automatically compress new images added to the repo
• Spell checking: Catch typos in blog post content before they go live

GitHub Issues and Projects

Track website tasks: “Update pricing page,” “Add Q1 case study,” “Fix mobile nav.” Assign to team members, set due dates, link to PRs. This is project management for your website that lives next to the code.

GitHub Copilot and AI agents

GitHub Copilot works directly in the GitHub UI, suggesting edits to files. Claude Code can clone your repo, make changes, and open PRs. Cursor and Windsurf edit files in your local clone. All of these tools work through Git — they create branches, make commits, and open pull requests just like a human developer would.

None of these tools can interact with Webflow’s visual editor. Git is the universal interface.

Dependabot

Automatically creates PRs to update your project dependencies. If a library you depend on releases a security patch, Dependabot opens a PR, the build runs, and if it passes, you merge it. One click to stay up to date.

When Webflow’s approach is better

Git and GitHub add complexity. For some teams, that complexity is not worth it:

• Solo non-technical users who just need to update text and images on a simple site. Webflow’s CMS editor is simpler than committing Markdown files.
• Design teams that think visually and iterate on layout constantly. The Webflow canvas is faster for visual iteration than editing CSS in a text editor.
• Client handoff projects where the client needs a visual editor and will never work with code. Webflow’s CMS and Editor modes are built for this.
• Rapid prototyping where version control overhead slows you down. Sometimes you just need to ship something today.

Webflow’s simplicity is genuine, and for the right team it is worth the trade-off. The GitHub workflow is better for teams that value safety, collaboration, AI integration, and long-term maintainability.

What the daily workflow looks like

For a marketing team using GitHub

A typical content update workflow after migration:

1. Writer creates a branch: new-case-study
2. Writer adds src/content/case-studies/acme-corp.md with the content
3. Writer opens a PR with the title “Add Acme Corp case study”
4. Deploy preview URL is generated; writer shares with the team
5. Marketing lead reviews content on the preview URL, leaves comments on the PR
6. Writer makes revisions, pushes another commit
7. Marketing lead approves; writer merges the PR
8. Site auto-deploys with the new case study live

The entire process happens in GitHub’s web interface or a code editor. No Webflow Designer needed.

For a developer maintaining the site

1. Task comes in: “Add a testimonial carousel to the homepage”
2. Developer creates branch: add-testimonials
3. Developer builds the component (or asks an AI agent to build it)
4. Commits, pushes, opens PR
5. Deploy preview shows the new carousel on the homepage
6. Team reviews; developer merges
7. Live in 60 seconds

If the carousel causes a performance regression, the Lighthouse CI action catches it on the PR and blocks the merge until it is fixed.

Getting started

1. Create a GitHub account (free) and a new private repository.
2. Choose your migration approach. AI coding agents for most teams; hire a developer for hands-off execution.
3. Connect hosting. Cloudflare Pages, Vercel, or Netlify — all free for static sites, all support auto-deploy from GitHub.
4. Set up branch protection. Require PR reviews for the main branch.
5. Document the workflow. Write a short CONTRIBUTING.md explaining how your team should create branches, open PRs, and deploy changes.

The setup is a one-time effort. Once your site is in a GitHub repo with auto-deployment, you have a workflow that scales from a solo developer to a 50-person team, with full history, review, and rollback at every step.