Traffic Dropped After a WordPress to Next.js Migration: What to Check First

A traffic drop after a WordPress to Next.js migration usually has a specific shape.

The new site is faster. The templates look cleaner. The CMS or build pipeline feels more modern. The launch was signed off. Then organic traffic softens, index coverage changes, rankings slip on long‑tail pages, or old WordPress URLs start appearing in crawl reports.

That does not mean the move to Next.js was wrong. It means the migration needs to be debugged as a migration, not defended as a framework decision.

WordPress sites carry a lot of search behaviour in small places: archive URLs, media pages, category paths, plugin‑generated metadata, redirect rules, sitemaps, breadcrumbs, and internal links. If those signals change without a plan, search engines have to rediscover the site.

Prove Which Traffic Dropped

Start with segmentation.

Compare before and after launch for:

• posts
• pages
• category archives
• tag archives
• custom post types
• author pages
• media attachment URLs
• homepage
• service or commercial pages
• branded and non‑branded queries
• mobile and desktop traffic
• countries or markets

A drop on old blog posts points somewhere different from a drop on commercial landing pages. A fall in impressions suggests discovery, indexing, relevance, or ranking. A fall in clicks with stable impressions may be title, snippet, intent, or layout.

Google's guide to debugging Search traffic drops is useful here because it pushes the work towards patterns rather than panic.

Check Old WordPress URLs Directly

Do not only crawl the new site.

Take the old URL list and check what each URL now does:

• 200 retained
• 301 to direct equivalent
• 301 to weak replacement
• 302 or 307 when permanent was intended
• redirect chain
• 404
• soft 404
• canonical to a different URL
• blocked or noindexed

WordPress migrations often lose traffic when many useful URLs are redirected to broad parents. A detailed article goes to the blog index. A category page goes to the homepage. A product support page goes to a generic service page. The redirect technically works, but relevance is gone.

The difference between 301 and 307 redirects matters, but status code alone is not enough. The destination needs to satisfy the same intent.

Audit WordPress Archives and Taxonomies

WordPress creates a lot of indexable surfaces.

Some are useful:

• topic categories
• commercial resource hubs
• custom post type archives
• author pages on editorial sites

Some are often accidental:

• thin tag pages
• date archives
• media attachment pages
• duplicate category/tag combinations
• search result pages

During a migration, these surfaces are often removed, noindexed, or redirected without a traffic check. That may be correct, but it should be deliberate.

If an old category archive had useful rankings, internal links, and article discovery value, replacing it with nothing can weaken the whole cluster. If thin tag pages were indexed accidentally, retiring them may be fine. The distinction matters.

Compare Metadata and Rendered Content

WordPress SEO plugins can generate a lot of metadata. Some of it is good. Some of it is stale. Some of it is invisible until you migrate and notice it is gone.

For affected templates, compare:

• title
• meta description
• canonical
• robots directives
• Open Graph tags
• structured data
• breadcrumbs
• publication and update dates
• author details
• internal links
• visible body copy

Then inspect the rendered HTML on the new Next.js page. A page can look visually similar while having weaker headings, missing metadata, fewer internal links, or thinner article content.

Optimising HTML markup for SEO covers the base principle: rendered structure is part of the product, not a detail for crawlers alone.

Check Sitemap and Robots Changes

WordPress usually has sitemap behaviour from core or plugins. Next.js usually has custom or generated sitemap behaviour. That change is easy to underestimate.

Check:

• old sitemap URLs versus new sitemap URLs
• sitemap index files
• post and page inclusion
• category and custom post type inclusion
• excluded noindex pages
• canonical URLs only
• correct production host
• old sitemap URLs redirecting cleanly
• robots.txt pointing to the new sitemap

Also check that staging or preview rules have not leaked into production. A disallow rule or noindex header copied from a deployment environment can cause serious damage quickly.

Look for Media and Attachment URL Fallout

WordPress media attachment pages are a strange source of migration trouble.

Some sites had attachment pages indexed accidentally. Some had image URLs earning traffic. Some had galleries, downloads, PDFs, or documents linked from articles and campaigns.

After the migration, check:

• old media URLs still resolve or redirect
• important PDFs and downloads still exist
• image alt text was preserved where useful
• attachment pages were intentionally handled
• image dimensions and lazy‑loading behaviour are sensible
• Open Graph images are still valid

Do not preserve every bad attachment URL just because it existed. But do not delete useful media routes without knowing whether they were linked or indexed.

Re‑Check Internal Links After Launch

Internal links often change more than teams realise during a redesign.

WordPress themes may have produced related posts, breadcrumbs, category links, tag links, author links, previous and next article links, and menu links. A cleaner Next.js build may remove some of that.

Check whether important pages still receive internal links from:

• navigation
• breadcrumbs
• article bodies
• related content modules
• category pages
• service pages
• footer links
• XML and HTML sitemaps

If traffic dropped on a cluster, do not only inspect the affected page. Inspect the pages that used to link to it.

Decide Whether to Roll Back, Patch, or Wait

Waiting is sometimes right after a migration. It is wrong when technical signals are broken.

Patch quickly if you find:

• important 404s
• missing direct redirects
• production noindex
• wrong canonical host
• missing sitemap sections
• broken internal links
• missing content on key pages
• severe structured data mismatch

Wait and monitor if:

• redirects are correct
• content is equivalent or stronger
• sitemap is clean
• metadata is stable
• affected pages are being crawled
• Search Console changes match expected site move behaviour

The difference is evidence. Without crawl data, Search Console, rendered HTML checks, and redirect mapping, waiting is just hoping.

Wrapping Up

A WordPress to Next.js traffic drop is usually recoverable if it is treated as a system problem.

The framework is only one part of the change. The real signals live in URLs, redirects, archives, metadata, rendered content, internal links, sitemap behaviour, and WordPress‑specific legacy surfaces.

Find the template or route family that changed, fix the signal, then give search engines a cleaner path through the new site.

Key Takeaways

• Segment the drop by page type, query group, and route family.
• Check old WordPress URLs directly, not just the new Next.js site.
• Audit category, tag, author, date, media, and custom post type URLs.
• Compare metadata and rendered HTML before and after migration.
• Validate sitemap and robots changes carefully.
• Patch broken technical signals before deciding to wait.