Websites

From WordPress to Nuxt, GitHub and Netlify: how to migrate a site step by step

How to move from WordPress to Nuxt, GitHub and Netlify: why do it, when not to, where content goes, the migration steps and how to protect your SEO.

Fabio Folgori6 min read

Flock of birds flying in a sky with white clouds
Photo by Julia Craice on Unsplash

WordPress is the most widespread tool for making websites, and for many projects it remains the right choice. But there are cases where, after a few years, you start wishing for something else: a faster site, fewer plugins to update, less surface for attacks, code you really control. That is when you look at a modern architecture: Nuxt for the site, GitHub for the code and content, Netlify to publish it.

In this guide I explain how it works, when it is worth it, when it is not and how to migrate without losing what you have earned on Google. The site you are reading is built this way: Nuxt, content in Markdown in the repository on GitHub, published on Netlify with a preview for every change.

What the three pieces are

  • Nuxt is a Vue-based framework for building sites and applications. It generates fast pages, handles languages, SEO and routing, and lets you write only the code you need.
  • GitHub is where the project lives: the code, and often the content too, with the full history of every change. You can always go back.
  • Netlify builds and publishes the site: at every change it repeats the build, and for every proposed change it creates an online preview (Deploy Preview) to check before publishing.

The flow is simple: you change, check the preview, approve, and the site updates.

Why people do it

  • Speed. Pages are already prepared and served from a distribution network, without querying a database on every visit.
  • Security. Without a public dashboard, database and dozens of plugins, the attack surface is much smaller.
  • Less maintenance. Fewer third-party components to update and fewer surprises after an update.
  • Control. The code is yours, readable and versioned; no theme or plugin changing under you.
  • Previews and order. Every change goes through a preview, and the history says who changed what.
  • Often low hosting costs, because a static or nearly static site weighs little.

When it is not worth it

Migration has a cost, and does not always pay back.

  • Whoever updates the content is used to the WordPress dashboard and uses many of its features: replacing it needs a comfortable alternative.
  • There is a complex shop (WooCommerce with many rules, subscriptions, private areas): rebuilding it is expensive.
  • Many plugins depend on WordPress and have no simple equivalent.
  • The site changes constantly by many non-technical people.
  • The budget is very limited and the current site works well.

If you are not sure a rebuild is needed, first read When it is worth rebuilding your site.

Where the content goes

It is the most important question, because it decides how whoever updates the site will work. The main routes:

  • Markdown files in the repository (with Nuxt Content). The text is plain files, versioned together with the code. Great for people comfortable with an editor and Git, and the way this site is made.
  • A CMS with an interface, connected to Nuxt. Editors write in a dashboard, and the site rebuilds itself. It can be a CMS designed for this use, or WordPress itself used only as a content store (headless).

The choice depends on who writes: if they are non-technical people, a dashboard is almost always needed.

The steps of the migration

  1. Inventory. A list of all pages, content types, forms and plugins that do something important.
  2. Decisions. What to keep, what to merge, what to delete, where the content will live.
  3. Exporting the content. Text, images, categories and metadata come out of WordPress and are converted to the chosen format, cleaned and checked.
  4. Rebuilding templates and components. The design is translated into Nuxt components, with attention to speed and accessibility.
  5. Features. Contact forms, search, languages, maps: rebuilt with suitable tools (for forms, for example, Netlify Forms).
  6. SEO. Titles, descriptions, heading structure, structured data and sitemap are kept, and the redirect map is prepared.
  7. Testing on preview. Every page, every redirect, every form, from several devices.
  8. Publication. The domain is pointed to the new site at a quiet moment, with a rollback plan.
  9. Checks after launch. Search Console, 404 errors, indexing, real speed.

SEO: where the risk is

The danger of every migration is losing positions. The rules are those of any rebuild: the same addresses or one-to-one 301 redirects, content preserved, no block to search engines left on by mistake. The full checklist is in Rebuilding your site without losing rankings. Every forgotten address becomes a 404 error: I talk about it in 404 errors: what they are, why they matter and how to handle them.

What changes for whoever updates the site

  • With Markdown and Git: you edit a file, propose the change, look at the preview and publish. More order and history, less immediacy than a dashboard.
  • With a CMS: the experience is similar to WordPress, but simpler and without plugins.
  • For small corrections: you need to decide who can make them and how, because the site is no longer edited "from the admin".

A short period of support should be planned, to explain the new way of working.

Costs and timing

There is no figure valid for everyone: it depends on site size, number of content types, features to rebuild and the choice for content. On the other hand, after the migration the recurring costs (hosting, maintenance, updates) are often lower. It is worth comparing total cost over time, not just the initial one. To get your bearings on the cost items of a site, read How much does a website cost in 2026.

How to decide, in six questions

  1. Who updates the content and how comfortable are they with a new tool?
  2. Does the site have complex features that depend on plugins?
  3. Are speed and security a problem today?
  4. How much do I spend today on maintenance and hosting?
  5. Do I want code that I control and can grow?
  6. Do I have budget and time for a migration done well?

Why entrust it to me

I have been programming since 1999, with more than 300 projects delivered and about 30 agencies as an external developer. I use modern technologies such as Nuxt, Vue and React, which produce very fast, secure sites with fewer plugins to update and fewer surprises; this very site is built with Nuxt, Netlify and GitHub. Before proposing a migration I tell you whether it is really worth it or whether fixing WordPress is enough. I work from Rome and remotely, with online previews every week.

If you are wondering whether to move to a modern architecture, write to me: a chat of about 20 minutes, no strings attached, then a written, free proposal. The service is in Website creation.

Frequently asked questions

No. It is worth it when speed, security and control of the code matter and content does not change every hour. If whoever updates the site needs a rich dashboard, many plugins or a complex shop, WordPress may remain the best choice.

It depends on where the content lives: Markdown files in the repository (like this site) or a CMS with an interface, connected to Nuxt. Whoever does not want to use Git needs the second route.

With addresses kept or redirected, content, titles and structured data preserved and checks after launch, the risk drops a lot. A well-done migration can also improve speed.

Yes: they can be handled with Netlify Forms or a small serverless function, with no plugins. They need to be tested properly before publication, though.

  • #wordpress
  • #nuxt
  • #netlify
  • #github
  • #site migration

More articles

Shall we talk about your project?

A 20-minute chat, no strings attached: we'll figure out together where to start.