Guide

What does a Webflow to Astro migration actually involve?

For a 15-page marketing site it took one working week: a one-to-one port of every page into Astro, a redirect map for 33 old URLs, hashed assets with year-long caching, and a structured-data layer rebuilt from one data file. Nothing indexed was lost, because every old URL still answers.

We moved bshdo.co off its Webflow export in October 2026. The site had four marketing pages and eleven case studies, all static HTML pruned from a Webflow export, served by Cloudflare Pages. This is what the move involved, with the numbers, because the same shape applies to most marketing sites we are asked to migrate.

What a migration is, and is not

A migration is not a redesign. The pages, the copy, the URLs and the structured data all stay; what changes is where they live and how they are built. We ported each page one to one, then diffed every built page against the original after normalising whitespace and attribute order. Fifteen of seventeen pages were identical; the two that differed had deliberate fixes. The JSON-LD was compared as data and was identical on every page.

That parity check is the heart of the work. Without it, a migration quietly loses a meta description here, a breadcrumb there, and the ranking drop shows up a month later with no obvious cause.

The URL rules

Every indexed URL on the old site had no trailing slash and no extension: /services, not /services/ or /services.html. Astro’s default writes a directory per route, which would have changed every URL. One configuration choice, build.format: 'file', keeps a file per route and the URLs exactly as they were.

Old URLs that no longer exist get a redirect, never a 404. Our map had 33 entries: thirty-one images renamed from Webflow’s upload names, and two page paths that still received traffic. A build step now checks every URL that has ever been live against the build output and the redirect file, and fails the build if one would answer nothing.

Assets

Webflow exports hand-made image sizes: -p-500, -p-800, -p-1080 copies of every photograph. Astro generates sizes at build time from one source, so the copies went. The stylesheet shrank from 86 KB to 85 KB after bundling, scripts moved into hashed bundles, and every generated file is cached for a year because its name changes when its content does. The one exception is anything with a stable name, such as Open Graph images, which get a day.

The site’s animated collage art, thirty-one megabytes of video loops, stayed exactly where it was. Astro does not process video, and a build that copies thirty-one megabytes on every deploy is not something to optimise away.

Structured data

On the old site, a five-kilobyte Organization node was pasted into all fifteen pages. Now it lives in one data file and is spread into every page at build time, so a change to the company’s address happens once. Each page keeps its own nodes: WebPage, BreadcrumbList, a CreativeWork per case study, an ItemList on the work page.

What we would do again

Build the parity check first. Keep the URL format. Put every old URL in a list the build verifies. Move images into the build pipeline and leave video alone. Resubmit the sitemap on the day the new site goes live, and request indexing for the pages that matter most.

What we would not do again is treat the content as part of the migration. The repositioning of this site came after the move, as its own piece of work, which is why the move could be checked line by line.

Related offer: Migration to Astro. More guides →

Bring us the real thing.

Thirty minutes with a builder, not a salesperson. Bring the problem, not a polished brief.