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

A WordPress‑to‑Next.js launch can look visually complete while still losing the signals that made the old site findable. The homepage loads, the templates look cleaner and the CMS work may even feel better. Then Search Console starts showing coverage changes, long‑tail traffic softens or old WordPress URLs appear in crawl reports.

That is not proof that Next.js damaged SEO. It is proof that the migration needs to be debugged as a migration. WordPress carries search behaviour in plugins, themes, URL patterns, taxonomies, media paths, archive templates and editorial assumptions. Some of that behaviour is useful. Some of it is accidental. Either way, it does not automatically survive a rebuild.

The mistake I try to avoid is deciding too early. Blaming the framework, content quality or an algorithm update before comparing old WordPress output with new rendered output wastes time. The first job is to find which route family, template or signal changed.

Separate Real Organic Loss from Reporting Noise

Not every post‑launch traffic drop is real organic loss. Tracking changes, consent behaviour, analytics configuration, brand demand, seasonality, query mix and reporting filters can all distort the picture.

Start by comparing 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 fall in clicks with stable impressions points somewhere different from a fall in impressions. A drop on old editorial URLs is not the same as a drop on commercial landing pages. Google's guide to debugging Search traffic drops is useful because it pushes the work towards patterns rather than panic.

If the affected URL families are not clear, I would use a structured triage pass such as the traffic drop checklist for redesigns and replatforms before choosing a fix.

Check Old WordPress URLs Directly

Do not only crawl the new site. Take the legacy WordPress URL inventory and check what each important URL now does.

Look for:

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

WordPress migrations often lose traffic when useful URLs are redirected to broad parents. A detailed article goes to the blog index. A category archive goes to the homepage. A custom post type URL goes to a generic service page. The redirect technically works, but the relevance has gone.

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

Compare Old Output with New Rendered HTML

The practical recovery work starts when you compare what WordPress used to emit with what Next.js now renders. A page can look equivalent in the browser while its crawlable output is weaker.

For affected templates, compare:

• raw HTML and rendered HTML
• title and meta description
• canonical URL
• robots directives
• headings
• visible body content
• structured data
• breadcrumbs
• publication and update dates
• author details
• internal links
• Open Graph tags

WordPress SEO plugins often generated metadata, canonicals, breadcrumbs, schema and sitemap entries from theme or plugin assumptions. Some of those assumptions may have been stale, but losing them without noticing can still change how search engines interpret the page.

The rendered HTML migration comparison worksheet is the kind of evidence I want before calling something a recovery plan. Optimising HTML markup for SEO covers the same base principle: rendered structure is part of the product, not a crawler‑only detail.

Audit Archives, Taxonomies and Content Models

WordPress creates a lot of indexable surfaces. Category archives, tag pages, author pages, custom post type archives, date archives and media attachment URLs may all have been present before launch.

Some should survive. Some should redirect. Some should be retired. The point is to make the decision deliberately.

If an old category archive had rankings, internal links and article discovery value, replacing it with nothing can weaken the whole cluster. If thin tag pages were indexed by accident, retiring them may be correct. A content model mismatch can also cause loss when old WordPress relationships are flattened into simpler Next.js templates.

This is where a migration becomes more than a front‑end rebuild. URL structure, editorial workflow, taxonomy meaning and search surfaces all need a migration decision. A broader website replatforming risk register helps catch those risks before launch, but it can still be useful during recovery.

Check Sitemap, Canonical and Internal‑Link Drift

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

Check:

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

Internal links often change at the same time. WordPress themes may have produced related posts, breadcrumbs, category links, tag links, author links and previous/next links. A cleaner Next.js build may remove some of that without anyone noticing.

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

Do Not Ignore Media and Attachment URLs

WordPress media attachment pages are an awkward source of migration trouble. Some sites had attachment pages indexed accidentally. Others had image URLs, PDFs, downloads or galleries earning visits or links.

After launch, check whether:

• old media URLs 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 remain valid

The caveat is that preserving every old media URL can keep bad legacy behaviour alive. The recovery decision should depend on whether the URL had value, links, traffic or a clear replacement.

Decide Whether This is Triage, Repair or a Wider Audit

Patch quickly when you find important 404s, missing direct redirects, production noindex, wrong canonical hosts, missing sitemap sections, broken internal links, missing body content or severe structured data drift.

Wait and monitor only when the technical evidence is clean: redirects are direct, content is equivalent or stronger, sitemap output is stable, metadata is intentional and affected pages are being crawled.

If the issue is specific to a WordPress‑to‑Next.js launch, the WordPress to Next.js SEO recovery service is the closest fit. If the symptoms are part of a wider redesign or replatform, the broader traffic drop after redesign or replatform service is usually a better starting point.

The useful recovery question is narrow: what changed between the old WordPress output and the new rendered output, and which of those changes removed a signal search engines or users were relying on?