Gemin
Get in touch

Gatsby to Webflow

Migrate from Gatsby to Webflow

Gatsby sites are often fast but hard for marketing teams to own. If every edit needs a developer, build and deploy, the website stops moving at the speed of the team writing it.

Start a project

A migration like this usually takes 3–4 weeks

What the migration covers

What moves, and what we figure out first.

What moves

  • Marketing pages and templates rebuilt in Webflow
  • Markdown, headless CMS or sourced content moved into Webflow CMS where that is the better home
  • Images re-hosted and optimized
  • Routes, metadata, redirects and tracking

What we figure out first

  • The data source decides the migration. Gatsby pulled content from somewhere: Markdown, a CMS, an API or a mix. We decide what stays and what moves.
  • React components do not translate. Components are rebuilt as Webflow structure, interactions or custom code where needed.
  • App-like surfaces stay outside Webflow. If part of the Gatsby site is really an application, it keeps its own build.

The first question is what Gatsby is assembling. If it only turns marketing content into pages, Webflow can usually replace the build entirely. If Gatsby is joining several APIs or supporting application behavior, those systems need their own destination before the frontend moves.

Why people move

What changes when you move from Gatsby to Webflow.

What is being compared Gatsby Webflow
Build model Gatsby Static build, plugins, GraphQL Webflow Publish
Changing a page's structure Gatsby Code, then a build and a deploy Webflow Visually, inside the design system
Data sources Gatsby Any number, joined in GraphQL at build time Webflow One CMS, plus whatever the page calls at runtime The row that decides whether this is a migration at all. A frontend over four APIs is not a CMS move.
What you give up Gatsby Full control of the output Webflow Some of it Honest, and for a marketing site usually worth it.

What actually changes

Remove Gatsby, not necessarily the systems behind it.

Now

As it stands

  1. Markdown, a CMS, an API
  2. Gatsby
  3. The site

Then one of these two

Option A

Consolidate into Webflow

  1. Webflow CMS
  2. Webflow

Right when Gatsby is rendering marketing content and nothing else reads those sources. The build, the deploy and the GraphQL layer all stop existing.

or

Option B

Keep the sources, render in Webflow

  1. Your existing CMS
  2. A sync
  3. Webflow

Right when Something other than this site consumes the content, or there are several sources worth keeping separate. Webflow becomes the front, not the store.

If Gatsby is rendering marketing content from one source, the stack gets smaller. If it is sitting over several sources with logic in it, moving the pages does not move the problem.

Once you have decided

What actually migrates.

What you have What happens Why
Pages Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. React components do not transfer.
Markdown content Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Frontmatter maps into collection fields. The body is transformed into rich text Webflow accepts, and any custom component sitting inside it is handled on its own.
Headless CMS content Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. Entries move as data, which is the easy half. References, rich text and localization are mapped during the content model, and how much work that is depends on the model rather than on it having been a CMS.
GraphQL layer Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. Not rebuilt so much as removed. It existed to assemble several sources at build time, so where the content lands in Webflow it stops being needed, and where a source stays put it becomes an integration instead.
URLs and redirects Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. Usually straightforward, since the paths were generated deliberately.

Before you budget it

Where this migration gets complicated.

  1. 01

    The data layer may have several sources behind it

    GraphQL in a Gatsby build often pulls from a CMS, a filesystem, an API and a spreadsheet at once. Every source needs its own answer, and some of them are not going into a Webflow collection.

  2. 02

    Anything computed at build time has to happen somewhere else

    Gatsby does work during the build: generating pages, transforming images, deriving fields. Webflow publishes rather than builds, so that work moves into the content or into a service.

  3. 03

    The redirects may not be in the site at all

    A Gatsby project's rules often live in the host's config or in gatsby-node rather than anywhere a crawl would find them, so reading the repository is the only way to know what is currently redirected. Trailing slashes get checked in the same pass, because the site may have been generating /page/ while the new one resolves /page, and that turns a preserved address into a redirect nobody planned. Missing the file loses rules nobody remembers writing.

The part quotes leave out

How I move it without losing the search footprint.

  1. The search footprint is inventoried before anything moves

    A crawl shows what the current Gatsby site links to now. Analytics and Search Console show which addresses people and search engines are still reaching, including ones nothing on the site points at any more, so the list is the union of all three. The traffic, the top pages and the queries earning impressions get written down at the same time: without a baseline, a change in how you count and a change in what you get are the same graph.

  2. What can stay where it is, stays

    Addresses first, then the titles and descriptions attached to them, then the canonicals. Metadata is the easiest thing to lose in a rebuild, because the new site will happily generate something plausible for every page and nothing will report a problem.

  3. Everything that changes gets one rule, not a chain

    A redirect pointing at a redirect still arrives, so nothing looks broken. Each address gets an intentional destination rather than an inherited one: individual rules where the destinations differ, a pattern where a whole route family changes predictably. The new sitemap goes in at cutover carrying the canonical addresses and nothing else.

  4. Every old address is requested after launch and the response recorded

    The whole list, not a sample. Looking for anything returning 404 that should not, anything returning 200 that should have moved, and anything taking more than one hop. Then indexing and traffic by landing page for the week after cutover, which is the window included, and longer by arrangement where the site is large enough to warrant it.

None of this guarantees a ranking, and search results can move during a migration for reasons nobody controls. The goal is to change platforms without unnecessarily changing what search engines already understand about the site, and to notice quickly when something did change. Afterwards I watch indexing, what the old addresses return and traffic by landing page, so normal recrawling can be told apart from an implementation problem.

How it runs

Six stages, and what each one looks like.

Gatsby

Other migrations

Coming from somewhere else?

Reach out and see if we are a good fit.

Start a conversation

Currently booking two to four weeks out.