Vue to WordPress: The Complete Migration Playbook

Vue is a joy to build in. It compiles cleanly, keeps templates readable, and has one of the friendliest learning curves in the framework world. What it does not solve is the operational side of running a real website: giving marketing a place to publish blog posts without touching Git, giving support a plugin ecosystem for chat and email, and giving finance a hosting bill that stays below the price of coffee. WordPress solves all three by default. Migrating a Vue app to WordPress lets you keep the design and interactivity Vue is good at, while offloading everything Vue was never trying to be to a platform that has been perfecting it for two decades. The second reason is discoverability. A Vue SPA renders an almost-empty div on the initial request and depends on client-side JavaScript to fill it in. Search engines can execute JavaScript, but they queue those pages behind cheaper HTML pages and often index them days later. Converting to WordPress pre-renders every route into complete HTML at build time, which is the same architecture that ranks the largest documentation sites on the planet. Teams typically see indexation catch up within two crawl cycles. The third reason is control. Vue apps hosted on a PaaS die the moment your build minutes run out or the platform pivots. WordPress runs on any Linux box with PHP, from a $4 shared plan to your own Kubernetes cluster. That optionality is what vendor-independence looks like in practice.

Every Tailwind, UnoCSS, or plain SFC style your Vite build emits carries into the WordPress theme byte-for-byte. Every `<script setup>` block, every reactive ref, every watcher runs after hydration exactly as it did before, because the compiled JavaScript is unchanged. Vue Router's history mode is translated into WordPress pages so URLs like /pricing, /about, /docs/getting-started keep resolving and keep their inbound backlinks. Assets in `public/` are copied verbatim, and everything imported from `src/assets` gets fingerprinted and rewritten to the theme's assets directory. What changes is the shell. Instead of a bare index.html served from a CDN, your app now lives inside header.php and footer.php, which means wp_head() and wp_footer() can inject their own tags — Yoast SEO, analytics, cookie banners, whatever plugin you install later. For visitors the transition is invisible: same layout, same fonts, same animations. For editors it is transformative: they get wp-admin instead of asking a developer to change a hero title. What does not carry over automatically is anything that lived outside your Vue source — Netlify functions, Vercel edge middleware, hosting-specific redirects. Those get flagged in the audit step so you can decide whether to replace them with a WordPress plugin or a small serverless endpoint.

Ten minutes of prep in your Vue repo pays off across every step that follows. First, run `npm run build` locally and make sure it succeeds without warnings. A warning-free Vite build is the strongest single predictor that the migration will finish cleanly. If Vite complains about dynamic imports or unresolved assets, fix those before you upload. Second, click through every route in your dev server and confirm the URL bar changes for anything a search engine should be able to reach. If a page depends on a query parameter or an in-memory store to render its content, the pre-renderer will only capture the empty state, which is fine for authenticated dashboards but bad for SEO pages. Convert those to real URL segments. Third, tidy the `public/` folder. Delete images you no longer reference and confirm the ones you keep are imported through the standard `import img from '@/assets/hero.jpg'` syntax so Vite can bundle them. Dynamically constructed asset paths (built from string concatenation) escape the bundler and land in the manifest as missing, which then shows up as broken images in the WordPress preview. Finally, decide how you are going to hand the project over. Pushing to GitHub is the recommended default because it captures your branch history and avoids partial uploads. A ZIP works fine for smaller projects.

Upload your ZIP or paste your GitHub URL on the homepage. The converter runs npm install, executes `npm run build`, and inspects the output directory. It detects Vue 3 through the `vue` dependency in package.json and picks the Vite adapter, which knows how Vite lays out its `dist/` folder and where the manifest lives. Headless Chrome then visits every route your router declared and captures the fully hydrated HTML. Because we run against the real production build, the HTML you get is identical to what a user with JavaScript enabled would see. That HTML becomes the body of each WordPress template. The compiler then rewrites every asset URL from the Vite hashed convention (`/assets/hero.abc123.jpg`) into the WordPress theme convention (`<?php echo get_template_directory_uri(); ?>/assets/images/hero.abc123.jpg`) so the theme is portable across hostnames. Fonts follow the same rewrite. Anything the compiler cannot resolve gets flagged in the diagnostics panel with a clickable link so you can decide whether to ignore or re-upload. The last step is packaging. You get a downloadable ZIP that installs into wp-admin like any other theme. First activation triggers a small setup routine that creates matching WordPress pages for each pre-rendered route and assigns the correct templates.

Install a caching plugin (WP Rocket, W3 Total Cache, or LiteSpeed if your host supports it) before you announce the migration. Cached HTML on a good host serves faster than most SPAs on a bad one. Add Yoast SEO or Rank Math to manage per-page meta and give editors a way to change titles without asking a developer. If you were using a headless CMS with Vue, decide whether to keep it (WordPress can still render pages that hit an external API) or switch to WordPress native content, which is usually the point of the migration. Set up 301 redirects for every route whose URL structure changed. The Redirection plugin is free and does everything you need. If the URLs stayed identical, skip this step but still submit the new sitemap in Search Console so Google recrawls quickly. Add the WordPress domain to your API's allowed origins, whether that API is Supabase, Firebase, your own Node service, or a third-party SaaS. This is the single most common post-migration bug — the site loads, but every fetch fails with a CORS error until you allowlist the new domain.

The mistake we see weekly is uploading a partial export. If your ZIP is missing `package.json` or the `public/` folder, the build cannot run and the pipeline stalls. Always export from the repo root, not from a subfolder. The second mistake is skipping the free preview. The preview exists specifically so you can eyeball the WordPress render before you pay. Ninety percent of support tickets come from people who bought first and looked second. Third, teams often forget that Vue transitions require JavaScript to execute. If a critical route depends on a `<Transition>` for content to appear (rather than for decoration), that content will be invisible until hydration completes on slow connections. Keep transitions decorative — never gate real content behind them. Fourth, custom directives that manipulate the DOM at render time (v-scroll, v-intersect, v-longpress from libraries like VueUse) sometimes need a hydration guard. Wrap them in `onMounted` if they are firing too early. Finally, do not forget to install an SMTP plugin. Fresh WordPress sends email through the server's mail() function, which is blocked on most modern hosts. WP Mail SMTP with a SendGrid or Postmark account solves this in five minutes.

For a marketing site with 5 to 20 routes, the whole migration finishes in about an hour end to end. Fifteen minutes of prep in Vue, five minutes to upload and wait for the build, fifteen minutes to install the theme on your WordPress host, and about twenty minutes to configure the essentials (permalinks, SMTP, cache, redirects, sitemap). Add another hour for content polishing and a second for the DNS switch, and you are done in an afternoon. That timeline collapses to twenty minutes if you are only converting a single landing page, and stretches to a day for sites with dozens of blog posts you want to migrate into real WordPress posts rather than leaving as pre-rendered pages. Either way, the initial conversion is the fast part; the polish is where you spend the real time.

Upload your Vue project on the homepage or connect your GitHub repo. The free preview lets you inspect the WordPress render before you buy, so you can verify every route, every image, and every animation before spending a cent. Conversion takes about five minutes, download is instant, and the theme installs on any WordPress host running PHP 7.4 or newer.