Migrate WordPress to Next.js Without Losing SEO: The Checklist That Protects Your Rankings

Search engines rank addresses, so start with every address

Google does not rank your business or your design. It ranks URLs, each with its own history of links, clicks and relevance. When a URL disappears without a forwarding address, that history goes with it. When it moves with a permanent redirect, most of it follows. That is the entire game of an SEO-safe migration: make sure no address that matters is left behind, and that each new page is at least as good an answer as the old one.

The good news is that Next.js gives you more control over the pieces that matter than WordPress plus an SEO plugin ever did. Redirects, metadata, canonicals, sitemaps and structured data are written in code, reviewed and tested before launch. The risk is not the platform. The risk is the inventory, so that is where we begin, on every WordPress to Next.js build and every Next.js rebuild we run.

Rankings are lost in the spreadsheet, long before launch day.

The URL inventory: four sources, because each one misses something

No single source lists every URL that matters. The XML sitemap shows what WordPress wants indexed, not what Google remembers. Analytics shows pages with visits, not pages with backlinks. So the inventory is built from several sources and merged.

• The sitemap and a full crawl of the live site, for every page, post, category, tag, author and pagination URL WordPress publishes.
• Search Console's Performance and Pages reports, exported, for every URL that earned impressions or is indexed, including ones the site no longer links to.
• Analytics landing pages over at least a year, so seasonal pages are not forgotten in the off season.
• Backlink data from Search Console's Links report or a backlink tool, for URLs other sites point at, however old.
• WordPress oddities: attachment pages, ?p= numeric links, feed URLs, old date-based permalinks and anything a redirect plugin already handles.

Each URL then gets a column for its traffic, its links and its fate: keep as is, redirect to a named new URL, or retire deliberately. The rules for deciding which structure the new site should use are in WordPress to Next.js URL structure. Our default is simple: if a URL earns traffic or links and its address makes sense, it stays exactly the same. We keep your URLs and redirect every old one that has to change.

Redirects: permanent, direct and kept for years

Google's site-move guidance asks for permanent redirects, such as 301 or 308, and says to keep them as long as possible, generally at least a year. In Next.js, redirects live in the project configuration; a redirect marked permanent returns a 308, which search engines treat as permanent. Very large maps can be checked in Proxy, the file Next.js 16 renamed from middleware. Either way, they are versioned with the code, not stored in a plugin someone might deactivate.

• One hop only. Old URL to final URL, never through a chain of older redirects left over from previous redesigns.
• Closest match, not the homepage. Sending every retired page to the homepage is treated much like a 404. Point each one at the page that answers the same question.
• Trailing slashes decided up front. WordPress permalinks usually end in a slash; Next.js does not add one by default. Pick one form, configure trailingSlash to match, and redirect the other.
• Tested in bulk. Every row of the inventory is requested against the preview site before launch, and the status code and destination are checked automatically.

The full redirect method, including how we handle query strings and archive pages, is on WordPress to Next.js redirects. If a previous move left you with broken links already, fixing 404 errors and broken links is a good place to start before migrating again.

Titles, descriptions and canonicals, carried over field by field

Your SEO plugin has been storing a custom title and description for many pages. Those are part of why some pages rank, and they should not be regenerated from scratch by accident. We export them from Yoast, Rank Math or whichever plugin you use, and load them into the matching fields of each page in Athena CMS, where your team can keep editing them.

In Next.js, each page type builds its metadata from those fields through the Metadata API: title, description, Open Graph and social images, robots directives and a canonical URL. Google's guidance is that each new URL should carry a self-referencing canonical, so we set one on every indexable page. Pages that were deliberately noindexed on WordPress, such as thank-you pages or thin archives, stay noindexed; pages that were indexed stay indexable.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Structured data, rewritten for each page type

WordPress SEO plugins generate structured data automatically, which is convenient and often generic: the same Organization and WebPage graph on every page, sometimes duplicated by the theme or a second plugin. A migration is a chance to do it properly. Each page type gets the JSON-LD it deserves: LocalBusiness with real hours and service areas for the home and contact pages, Service on service pages, Article on posts, Product on product pages, FAQPage only where the page genuinely answers questions.

Because the markup is generated from content fields, it stays accurate when your team edits a phone number or business hours. Every template is checked with Google's Rich Results Test before launch. Schema is one of the rows where Next.js pulls ahead, as WordPress vs Next.js for SEO explains in more detail.

One caution runs the other way. Structured data should describe what is visibly on the page, so a migration is not the moment to add review stars or FAQ markup the content does not support. If the old plugin output something the new page cannot back up, it is dropped rather than copied. Honest markup is cheaper to maintain and does not invite a manual action later.

Internal links, sitemaps and the Search Console handoff

Redirects catch visitors arriving from outside. Your own links should not need them. Google's guidance is to update internal links using the same URL mapping, so every link inside content, menus and footers points straight at the final address. Builder content is the usual hiding place for old links, since they sit inside widget settings rather than plain text; the Elementor to Next.js page explains where to look. After launch, Athena's Ariadne agent finds and inserts new internal links as the site grows, and Atlas flags orphan pages.

1. 1

   Generate the sitemap from content

   Next.js builds sitemap.xml from the CMS, so new pages appear automatically and retired ones drop out.

2. 2

   Confirm Search Console ownership

   Keep the existing property verified through the switch. A DNS verification survives a platform change; an HTML file or meta tag may not.

3. 3

   Submit the new sitemap

   Submit it in Search Console on launch day, and remove the old WordPress sitemap once it no longer resolves.

4. 4

   Skip Change of Address unless the domain changes

   Google says that tool is only for moving between domains or subdomains, not for a platform change on the same domain.

Images, alt text and image search traffic

Images carry SEO value of their own: alt text, file names and, for some businesses, real traffic from image search. WordPress stores alt text in the media library, but builder sites often store a second copy inside each image widget, and the two do not always match. We collect both, keep the more descriptive one, and fill gaps before launch. Athena's Picasso agent then keeps every new image described and sized.

Old image URLs under /wp-content/uploads/ are worth a look in the inventory. If any earn image search traffic or are linked from other sites, they get redirects like any other page. On the new site, next/image resizes each image for the device and serves modern formats, which helps Largest Contentful Paint. The details are in moving WordPress images to Next.js.

The watch after launch

Google says rankings may fluctuate while a moved site is recrawled and that they settle over time. The weeks after launch are when small mistakes are cheap to fix, so we watch rather than celebrate.

• Daily at first: Search Console's page indexing report for new 404s, redirect errors and pages blocked by robots rules.
• Weekly: clicks and impressions for the top pages in the inventory, compared with the same period before the move.
• Forms and calls: conversions tracked through the switch, because traffic that arrives but cannot convert is its own kind of loss.
• Speed in the field: Core Web Vitals data as it accumulates for the new pages; see WordPress vs Next.js Core Web Vitals.
• Ongoing: Argus watches for broken links, failing forms and slow pages, and Iris keeps titles and descriptions in order as content changes.

Theme-specific notes on what usually breaks are in each migration guide, for example Astra to Next.js, Kadence to Next.js, Divi to Next.js and WooCommerce to Next.js. The whole move is described on the WordPress to Next.js hub, and switching from WordPress covers what changes for your team. If visibility already dropped after an earlier move, SEO visibility recovery is the place to start.