From WordPress to Nuxt, GitHub and Netlify: why I am moving and how to migrate a site

Let me say it upfront: I love WordPress. I have worked with it for years, built sites I am proud of with it, and for many projects it remains the most sensible choice. But in recent years the way it is used has changed, and not for the better. Themes that do everything, a plugin for every need, sites where everything depends on everything else. Meanwhile automated attacks have become a constant. That is why I increasingly propose a different architecture: Nuxt for the site, GitHub for code and content, Netlify for publishing. The site you are reading is built this way.

A structural problem, not a cosmetic one

WordPress is a PHP application that, on every request not served from cache, loads core, the theme and every active plugin, reads autoloaded options from the database and runs the hook chain before producing a page. It is a powerful model, and for a site with few dependencies it works well.

The trouble is accumulation. A typical site I see today has a multipurpose theme with a page builder, twenty or thirty plugins, add-ons that depend on other plugins and a cache layered on top to hide response times. In that situation:

• every update is a gamble, because theme, builder, plugin and PHP versions all have to be compatible;
• the attack surface grows with every component: the vast majority of WordPress vulnerabilities are in plugins, not in core;
• speed becomes a job of its own, made of caches, optimisers and plugins fixing the problems of other plugins.

That is what I mean when I say everything is too tightly bound: you cannot touch one piece without worrying about the others.

What changes with Nuxt, GitHub and Netlify

The idea is to separate what WordPress keeps bundled together.

• Nuxt generates pages at build time (or renders on the server only where needed). There is no database queried on every visit and no public admin panel to protect. The code is only the project's own: Vue components, TypeScript, Tailwind.
• GitHub holds the code and, often, the content in Markdown. Every change is a commit, so it has an author, a date and can be reverted.
• Netlify builds the site and publishes it to a CDN. Every proposed change gets an online preview to review before going live, and releases are atomic: either the whole new version is online, or the old one stays.

The practical result: static pages served from the CDN, very few runtime dependencies, no wp-login.php to hammer and a full history of every change. I cover this in Publishing a site with GitHub and Netlify too.

Where the content goes

This decision determines how whoever updates the site will work.

• Markdown in the repository, with Nuxt Content: texts are files versioned with the code, with typed frontmatter validated against a schema. It is how this site works, ideal when the writer is comfortable with an editor and Git.
• Headless CMS: editors work in a panel and the site rebuilds on every publish. It can be a CMS built for this or even WordPress itself, used only as a content store via API.

If the writers are non-technical and publish often, the panel is necessary. Pretending otherwise is the fastest way to make a migration fail.

When WordPress is still the right choice

I do not migrate everything, and I do not recommend doing so.

• Complex e-commerce with WooCommerce, subscriptions, customer-group price lists: rebuilding it costs more than it rarely returns.
• Large editorial teams publishing daily and making full use of roles, revisions and approval workflows.
• Sites that depend on plugins with no simple equivalent, such as complex bookings or memberships.
• Minimal budgets on sites that work: if the site is fast, secure and up to date, there is no reason to touch it.

In those cases the way forward is a lean WordPress: custom theme, few carefully chosen plugins, own code where it matters. I cover it in Custom or ready-made WordPress themes and plugins. At Altura Vela, for example, the school's website stayed on WordPress, while I built the management app from scratch in Nuxt: two different tools for two different needs.

How the migration is done

1. Inventory: URLs, content types, taxonomies, custom fields, forms, features that depend on plugins.
2. Content model: decide the schema (collections, fields, relations) before writing a line of code.
3. Export: content leaves via the REST API or WXR, is converted to Markdown or imported into the CMS, and cleaned of shortcodes and page-builder markup.
4. Components: the design becomes Nuxt components, with attention to LCP, CLS and accessibility from the start.
5. Features: forms, search, languages, maps, RSS feed, sitemap. Each becomes a small piece of code instead of a plugin.
6. SEO: titles, descriptions, canonicals, hreflang, structured data and a one-to-one 301 redirect map.
7. Testing on the preview: every template, every redirect, every form, on mobile and desktop.
8. Launch and monitoring: DNS switch at a quiet moment, then Search Console, 404 logs and real-user speed data for a few weeks.

The full SEO checklist is in Rebuilding your site without losing rankings.

My take

It is not about fashion. With WordPress I spent too many hours updating components I had not written, cleaning up sites compromised through abandoned plugins and optimising pages weighed down by features nobody used. With Nuxt I spend those hours building: the code is what is needed, every change has a preview and a history, and security does not depend on how fast I update thirty plugins.

I still do WordPress when it is the right tool. But if you ask me for a new site and you do not need a complex admin panel, today I will almost always suggest starting here.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work with about 30 agencies as an external developer. I know WordPress from the inside, which is exactly why I can tell when it pays to stay and when to leave. I work with Nuxt, Vue, TypeScript and Tailwind, and publish with GitHub and Netlify, from Rome and remotely.

If you are considering a migration, get in touch: in a call of about 20 minutes we look at your current site and I will tell you plainly whether moving makes sense. The service is in Website development.