Nuxt to WordPress: Moving Universal Vue Apps to WP

Nuxt is the pragmatic middle ground between a pure SPA and a hand-rolled SSR setup: file-based routing, server routes, auto-imported composables, and a genuinely good developer experience. The gap it does not fill is editorial workflow. If your marketing team wants to change a hero title, they either edit a .vue file in Git or wait for a developer. If they want to add a landing page for a new campaign, that is a PR. If they want to schedule a blog post for next Tuesday morning, they are learning cron. WordPress solves all three by default. Migrating a Nuxt app to WordPress keeps everything Nuxt was good for (routing, components, animations, integrations that ran client-side) while giving editors a real CMS behind the same visitor experience. The second reason is cost. Nuxt hosted on Vercel, Netlify, or a Node platform scales with visitors in a way WordPress on shared hosting does not. For a marketing site, this often means WordPress runs the same content for a tenth of the monthly bill.

The pipeline uses `nuxt build` with the static preset (or an existing `.output/public/` folder if you built beforehand) as the source of truth. Every pre-rendered HTML page becomes a WordPress template or page. useAsyncData payloads are serialized into the initial HTML, so the browser sees fully-populated content instantly. Client-side JavaScript hydrates the page and takes over interactivity from there. All assets — images, fonts, generated CSS — copy into the theme's assets directory with the correct URL rewrites. Nuxt Image's srcset and modern format variants are preserved. Tailwind or your CSS framework of choice ships unchanged. Nitro server routes get inspected in the audit. If a route was just returning static JSON at build time, it folds into the theme. If it was reading query parameters and calling a database at request time, the audit flags it for reimplementation, usually as a WordPress REST endpoint (register_rest_route) which is the WordPress-native replacement for Nitro handlers.

Set `nitro.preset` to `'static'` in nuxt.config.ts (or add `nuxt generate` to your scripts). This forces Nuxt to pre-render every route it can discover, which is what the WordPress theme needs. If you rely on true SSR (dynamic per-request rendering), the pipeline can still pre-render the static portion and leave the dynamic pages for you to re-implement. Run `nuxt generate` locally and inspect `.output/public/` for the pages you expect. If a page is missing, add it to `nitro.prerender.routes` explicitly. This is more reliable than depending on Nuxt's auto-discovery for pages that only link from external sources. Check your Nuxt Image config. Providers like Cloudinary or ipx that fetch remotely at request time need to switch to build-time processing so the images end up in the theme rather than requiring a runtime service.

Upload your Nuxt project or connect your GitHub repo. The pipeline detects Nuxt through the `nuxt` dependency and runs `nuxt build` in static mode. Headless Chrome verifies each route hydrates correctly, then the compiler maps HTML pages to WordPress templates. Dynamic routes with parameters (`/blog/[slug].vue`, `/products/[id].vue`) become custom post type templates in WordPress. Each pre-rendered slug seeds a real WordPress post, so editors can add new entries through wp-admin without redeploying. Assets get fingerprinted URLs rewritten to `<?php echo get_template_directory_uri(); ?>/assets/...` so the theme is portable across domains. Total build time for a typical Nuxt marketing site is five to seven minutes.

Install a caching plugin, an SEO plugin (Yoast or Rank Math), and an SMTP plugin. That is the standard trio for a fresh WordPress install and doubly important for a converted Nuxt site whose editors are used to a build-time-optimized world. If you had Nitro handlers that talked to a database, decide whether to move that logic into a WordPress plugin (best for CRUD against WP tables), a REST endpoint (best for logic the frontend calls directly), or a serverless function (best for third-party API integrations that would slow down PHP requests). Set up 301 redirects for any URL that changed. Nuxt's trailing-slash behavior can differ from WordPress's default; if you had /about without a slash and WordPress serves /about/, add a redirect or configure permalinks to strip trailing slashes.

Do use the free preview to verify hydration. Nuxt apps sometimes have subtle bugs where a component renders differently on the server than on the client — those show up as flicker or content shift after hydration, and the preview is where you catch them. Do migrate content collections to WordPress CPTs, not to markdown files in the theme. Editors will thank you. Do not skip package.json cleanup. Old Nuxt 2 dependencies that never got removed will confuse the auto-detection. Ensure your dependencies reflect what your project actually uses. Do not leave your Nuxt server running on the old host indefinitely. Even a redirect at the DNS level is cleaner than two versions of the same site competing in Google's index.

Upload on the homepage or connect your GitHub repo. Preview the WordPress render before you buy, so you know every page and every island hydrates correctly. Conversion typically completes in about five to seven minutes.