WordPress to Next.js, a migration checklist that preserves rankings

RankSmith has moved a number of South African businesses off WordPress onto Next.js in the last two years. Every engagement starts with the same question from the client. "Will I lose my Google rankings?" The short answer is no if you follow the checklist, yes if you do not. The longer answer is below.

How long does a WordPress to Next.js migration take without losing rankings?

Every RankSmith migration runs in four phases. Audit, rebuild, parity, cutover. Week one is the content and schema audit. Weeks two through four rebuild the design system in Next.js and port the content. Weeks five through seven are the slowest and most important, the parity checks and redirect map. Week eight is cutover, sitemap ping, and monitoring.

The phases are not equal. Rebuild feels like the most work and is. Parity is the part nobody sees and the phase that determines whether rankings survive. We budget three full weeks for parity because the spreadsheet is long and the tolerance is zero.

What breaks rankings when you migrate?

Five things break rankings on a migration. In order of frequency on the sites we have audited before and after.

First, broken or missing 301 redirects. Every old URL that is not redirected to a new URL returns a 404 the first time Google crawls it. A few 404s are tolerable. Thousands are a signal that the site is gone. Google responds by dropping all thousands from its index.

Second, lost schema markup. WordPress sites typically rely on Yoast or Rank Math to inject Article, BreadcrumbList, and Organization schema. If the new Next.js site does not emit the same schema on equivalent pages, rich results disappear, AI engines stop citing the brand, and ranking signals weaken for a rolling month.

Third, URL pattern changes without canonical merge. If /?p=123 and /services-seo/ both used to point to the same SEO page and only one gets redirected, the unmapped one bleeds authority.

Fourth, sitemap churn. A new sitemap that lists all the new URLs without the old sitemap being replaced tells Google the site changed overnight. Paired with missing redirects this triggers a reshuffle that takes weeks to settle.

Fifth, soft 404s. Pages that return 200 but no meaningful content, typically a migration placeholder or an empty template. Google treats these worse than a hard 404.

The 40 step RankSmith migration checklist.

We run the checklist in order, one sheet per phase, one owner per item. The full list is below.

Audit, week 1

1. Export every URL on the live WordPress site via a crawl (Screaming Frog, Sitebulb, or the WordPress sitemap).
2. Record each URL's HTTP status, title tag, meta description, canonical, and word count.
3. Export the current sitemap.xml and robots.txt. Screenshot both as a baseline.
4. Export schema from the homepage, service pages, and blog posts. Save the JSON LD.
5. Pull the top fifty ranking queries from Google Search Console. Note which URLs rank for each.
6. Pull the top fifty inbound backlinks (via Ahrefs, SEMrush, or Google Search Console's links report).
7. Write a one page migration risk memo listing the highest value URLs and the queries they must retain.

Rebuild, weeks 2 to 4

1. Scaffold the Next.js 15 project. App Router, TypeScript strict, Tailwind.
2. Port the design system. Typography, colour tokens, radii, shadows.
3. Build every page type in the new system. Home, service, article, case study, pricing, contact.
4. Port content page by page. Copy exact H1, H2, H3 structure. Preserve word count within 10 percent.
5. Configure Organization, LocalBusiness, WebSite, Article, and FAQPage schema with per page helpers.
6. Emit breadcrumb schema on every non home page.
7. Implement internal linking equivalent to the old site. Every old cross link gets a new cross link.
8. Set up the Next.js sitemap.xml route. Dynamic if the site has a blog, static otherwise.
9. Set up robots.txt with the same allow and disallow rules as WordPress.
10. Write llms.txt and llms-full.txt (see our llms.txt 2026 field guide).
11. Configure OG images per page via generateMetadata or file conventions.
12. Deploy to a staging URL gated behind basic auth.

Parity, weeks 5 to 7

1. URL parity sheet. Every old URL in column A, new URL in column B, status in column C (map, merge, kill).
2. Build the redirect map. One to one or many to one. Never many to many, never chained.
3. Implement redirects in next.config.ts via the redirects() function or via middleware.
4. Title and meta parity. Paste old title and description next to new. Approve or revise each.
5. Schema parity. Run each staging page through the Schema.org Validator and Google Rich Results test.
6. Internal link parity. Crawl staging, confirm no broken internal links.
7. Image parity. Every image on the old site exists on the new site, optimised, with alt text.
8. 404 handling. Dedicated 404 page, server returns correct status, no soft 404s.
9. Canonical parity. Every new page has a self referencing canonical matching the production URL.
10. Hreflang if multilingual. Match the old pattern exactly.
11. Speed Insights or Lighthouse pass on every key template. LCP under 1.5s, INP under 100 ms.
12. Test the redirect map with a URL list (curl -I or a small script) against the staging domain.
13. Submit the new sitemap in Google Search Console in the new property (temporarily).
14. Ask two reviewers outside the build team to click every nav link and search for three queries.
15. Sign off by the client on parity.

Cutover, week 8

1. Lower DNS TTL on the WordPress domain to 60 seconds, 24 hours in advance.
2. At cutover, point DNS to the Next.js production host (Vercel, Cloudflare Pages, or equivalent).
3. Replace the old sitemap.xml with the new one at the same URL. Ping Google Search Console.
4. Verify 200 status on the top fifty URLs from the risk memo using a crawl tool.
5. Spot check the top ten ranking URLs in an incognito browser. Confirm content loads.
6. Monitor Google Search Console daily for the next fourteen days. Watch the coverage report, the URL inspection tool, and the performance report.

How do we build the 301 redirect map?

The redirect map is a spreadsheet with three source lists, then one union.

Source one is the live crawl. Every URL Screaming Frog finds walking the current site. This catches the pages that still exist.

Source two is the indexed list from Google Search Console. Every URL Google has in its index. This catches the pages that Google still thinks exist, even if they are hard to find on the site. These are the URLs that bleed rankings if you forget them.

Source three is the backlink list. Every URL with inbound links from third party sites. These are the highest value URLs and the ones where a 404 hurts most.

Union the three sets, deduplicate, and map each old URL to a new URL in the same column. Two rules we never break. Every redirect is a 301, not a 302. No redirect chain is allowed, which means an old URL must point directly to the final new URL, not to another old URL that itself redirects.

Where two old URLs legitimately map to the same new URL, that is a canonical merge. Document it in a third column. It is a common pattern after a content cleanup and Google accepts it without penalty.

We implement the map in next.config.ts:

async redirects() {
  return [
    { source: "/services-seo", destination: "/services/seo", permanent: true },
    { source: "/portfolio", destination: "/work", permanent: true },
    { source: "/category/news", destination: "/blog", permanent: true },
    { source: "/about-us", destination: "/about", permanent: true },
  ];
}

For dynamic redirects (thousands of blog posts, for instance) we use middleware with a lookup map. Same rule: 301, direct, no chain.

What do we ship the day of cutover?

Cutover is a six hour window, usually late Sunday evening South African time when traffic is low.

The sequence is fixed.

First, we lower DNS TTL to 60 seconds 24 hours before. This shortens the switch and guarantees no stale cache on cutover.

Second, at the cutover moment, we flip the A or CNAME record to point at the Next.js production host. Vercel by default for sites we ship.

Third, we verify the new site responds at the production domain with the full redirect set active. We curl ten of the highest value redirects and confirm each returns a 301 to the correct new URL.

Fourth, we ensure the sitemap at the production URL is the new sitemap. If WordPress was serving /sitemap.xml and we are now serving a Next.js sitemap.xml at the same URL, no change is visible to Google. If the path changed, we submit the new path in Search Console and keep the old path 301 redirecting.

Fifth, we ping Google Search Console. "Request indexing" on the top ten URLs. This accelerates the recrawl. We do not ping every URL, only the ones where the rankings are the highest commercial value.

Sixth, we start the watch. Daily check of the coverage report, weekly review of the performance report comparing queries and URLs to the pre migration baseline.

How do we prove rankings are preserved after launch?

Before cutover, we export a baseline. Top fifty queries and their positions. Top twenty URLs and their impressions. CrUX data on Core Web Vitals. CrUX lags by 28 days, so pre migration numbers are the ones we capture now.

Within the first forty eight hours we expect Google to recrawl most redirected URLs. Coverage in Search Console should show the new URLs indexed within three to seven days.

Between day seven and day fourteen is the dip. Rankings drop by one to three positions on average queries, sometimes more on head terms. This is normal.

By week four, rankings are back to baseline or better on a well executed migration. If they are not, the failure is almost always in the 301 map. Export the URL parity sheet, find the old URLs that still 404 or soft 404, and fix those redirects. Rankings catch up inside another two weeks.

If the dip is severe (more than ten positions on head terms) and does not recover by week six, something bigger is wrong. The most common causes we have seen, in order: schema removed entirely, a canonical misfire pointing all pages at the homepage, and a robots.txt that blocks the new site. All three are fixable in under an hour if you catch them quickly.

What does this cost?

Our pricing page lists the full setup plus monthly retainer for each tier. A typical migration for a South African service business falls into the Studio tier (ZAR 75,000 setup plus ZAR 3,500 per month), which covers the eight week build, the parity audit, the cutover, and the first thirty days of ranking watch. Larger sites with WooCommerce or membership logic move up to the Flagship tier.

If you are thinking about moving off WordPress, the cheapest move is the one that does the redirect map properly. Start with our free audit or book a strategy call. We will review your current URLs, schema, and ranking profile and give you a realistic migration window before either of us commits.