Moving a business website from WordPress to Next.js can make it faster, more secure and easier to extend. It can also lose search traffic you spent years building if it is done carelessly. The difference is almost entirely in the preparation: knowing every page you have, deciding where content will live, and making sure every old address leads somewhere sensible on the new site.

This guide walks through the migration the way we approach it, step by step. If you are still deciding whether to move at all, our comparison of Next.js and WordPress for Vancouver businesses covers that question first.

Step 1: Take a full inventory of the current site

Before anything is built, list everything the current site contains:

  • Every URL. Use the XML sitemap your SEO plugin generates, and run a crawler over the site to catch pages the sitemap misses. Older sites often have forgotten landing pages, tag archives and attachment pages.
  • The pages that matter most. Export your top pages from Google Search Console and Google Analytics. These are the pages whose rankings and traffic you most need to protect.
  • Content and media. Posts, pages, custom post types, categories, images and downloadable files.
  • SEO settings. The titles, meta descriptions and canonical tags stored in plugins such as Yoast or Rank Math. These do not move automatically.
  • Functionality. Every plugin, and what it actually does for the business: forms, booking, search, galleries, ecommerce, memberships, popups, tracking.

This inventory becomes the checklist the new site is tested against.

Step 2: Decide where content will live

WordPress is both the website and the place you edit content. With Next.js, those can be separated, and there are three common options:

  1. Keep WordPress as a headless CMS. Your team keeps editing in the familiar WordPress dashboard, and Next.js pulls the content through the WordPress REST API or a GraphQL plugin. This is the gentlest change for editors.
  2. Move to a dedicated headless CMS. A purpose-built content system with a simpler editing interface and no public WordPress site to keep patched.
  3. Use file-based content. For small sites that rarely change, content can live in files alongside the code. It is simple and cheap, but edits usually go through a developer.

The right choice depends on who edits the site and how often. There is no reason to pick the most complex option for a ten-page site.

Step 3: Plan the URL structure and the redirect map

This is the step that protects your rankings. Wherever possible, keep the same URLs. If your service pages live at /services/roof-repair/ today, there is rarely a good reason to change that.

Where URLs do change, for example when moving away from date-based blog addresses or tidying up a messy structure, build a redirect map: a list of every old URL and the new URL it should point to. Then follow a few rules:

  • Use permanent (301) redirects. Next.js supports these directly in its configuration.
  • Redirect to the closest equivalent page, not to the homepage. Sending every old page to the homepage throws away the relevance those pages had.
  • Avoid redirect chains. An old URL should go straight to its final destination, not through two or three hops.
  • Be consistent about trailing slashes and capital letters, so the same page is not reachable at several addresses.

Step 4: Rebuild the templates and move the content

With the structure agreed, the site is rebuilt in Next.js: page templates, navigation, components and styling. Content is then imported through the WordPress export, the REST API or the new CMS's import tools.

Check the content as it moves. Imports often carry over old shortcodes, inline styles, broken embeds and images with missing alt text. It is a good moment to clean up outdated pages, merge thin ones and fix headings, rather than copying problems across.

Step 5: Carry the SEO details across

The new site needs everything that told search engines what each page was about:

  • Page titles and meta descriptions from your SEO plugin
  • Canonical tags and a single preferred address for each page
  • Structured data for your business, services, articles and FAQs
  • Image alt text, and images served at sensible sizes and formats
  • An XML sitemap and a robots.txt file
  • Open Graph tags, so links shared on social media still show the right title and image

Next.js handles metadata and image optimization well, but only for the information you give it.

Step 6: Replace what the plugins used to do

Plugins quietly handle a lot. Each one on your list needs a decision: rebuild it, replace it with a service, or drop it. Contact forms, search, analytics and cookie consent are usually straightforward. Booking systems and CRMs normally connect through their own embeds or APIs.

Some functions are harder. A large WooCommerce store, a membership site or a learning platform built on WordPress plugins can be expensive to rebuild. In those cases, staying on WordPress, or keeping WordPress for that part of the business, may be the sensible answer.

Step 7: Test on a staging site

Before launch, the new site runs at a private staging address that search engines cannot index. Test it against the inventory from Step 1:

  • Crawl the staging site and confirm every important page exists
  • Test every redirect in the map
  • Submit every form and check that the messages arrive
  • Check analytics and conversion tracking
  • Test on real phones and slower connections
  • Compare titles and descriptions against the old site

Step 8: Launch and watch closely

On launch day, the domain is pointed at the new site, the redirects go live and the new sitemap is submitted in Google Search Console. Keep the old site's hosting available until you are confident nothing is missing.

In the following weeks, watch Search Console's page indexing report for errors and unexpected 404s, check that redirected URLs are being replaced by the new ones, and compare traffic to your top pages with the baseline you exported in Step 1. Some movement in rankings for a few weeks after a migration is normal. A careful redirect map is what keeps it short.

How long a migration takes

A standard custom build typically takes us 3 to 4 weeks from kickoff to launch. Migrations with a lot of content, complex redirects, a second language or plugin features to rebuild take longer, often around 5 to 6 weeks. The inventory in Step 1 is what tells us which applies to your site.

Where we come in

Velora builds custom websites on Next.js, including migrations from WordPress, Wix and Squarespace, and we can build around systems you already run. If you are considering a move, send us your current site and we will tell you what a migration would involve, and whether staying on WordPress is the better choice for you.