Why Are My Pages Crawled but Not Indexed After a WordPress-to-Next.js Migration?

Key Takeaways

• Crawled but not indexed means Google reached the URL but has not selected it for its searchable index. It does not automatically mean that Next.js is the problem.
• Start with the rendered response, status code, canonical, robots rules and redirect map before requesting indexing again.
• A migration can create thin, duplicate or disconnected pages even when every URL returns a successful response.
• Compare each new page with its former WordPress version. Preserve the search intent, useful content, internal links and relevant metadata rather than only the visual design.
• Fix patterns across templates first, then validate a small group of representative URLs in Search Console and monitor the wider section.

If Google reports that pages are crawled but not indexed after a WordPress-to-Next.js migration, it has discovered and fetched those URLs but has not chosen to store them in the index. The cause may be technical, such as conflicting canonical tags or content that only appears after a failed client-side request. It may also be editorial: the new pages could be too similar, too weak or poorly connected to the rest of the website.

Do not respond by repeatedly pressing Request indexing. That can be useful after a real fix, but it does not make a page eligible or valuable. Google's own explanation of how crawling and indexing work is clear that indexing is not guaranteed. The right job is to find out what Google received, what signals the page sends and whether the page deserves to be the canonical answer.

First, Confirm the Exact Indexing State

Open the Page indexing report in Google Search Console and separate the affected URLs by reason. Crawled - currently not indexed is different from Discovered - currently not indexed, Duplicate without user-selected canonical, Excluded by noindex, or Page with redirect. Combining them into one spreadsheet creates the wrong repair plan.

Inspect a few examples with URL Inspection. Record:

• whether Google can crawl the URL;
• the last crawl date and fetched status;
• the user-declared and Google-selected canonical;
• whether indexing is allowed;
• the referring page and sitemap discovery, where shown;
• a screenshot or copy of the tested live HTML;
• the old WordPress URL that previously served the same intent.

Test a mix, not only the homepage. Include a service page, a blog article, a category page, a paginated route and a page that uses data from WordPress. If all examples fail in the same way, the fault is probably in a shared layout, data-fetching function or metadata rule. If only one content group fails, examine that template and its content quality.

Our broader website migration SEO checklist explains the baseline evidence worth collecting before a rebuild. If that record was not made before launch, recreate it now from analytics, Search Console, the old sitemap, server records and a suitable web archive.

Check What the Server Returns Before Looking at the Screen

A browser can make a broken page look normal. JavaScript may recover after the initial response, a logged-in editor may receive different content, or a cached version may hide an intermittent fault. Search engines begin with the HTTP response.

For every sample URL, check:

1. The final response is a genuine 200 for a page that should exist.
2. Old URLs return one permanent redirect to the closest new equivalent.
3. Removed pages return a truthful 404 or 410 rather than a soft 404 page with a 200 response.
4. There is no redirect chain through HTTP, www variants, trailing-slash changes or old category paths.
5. The HTML response contains the main heading and useful page copy without needing a user action.

Next.js supports permanent redirects in several places. Its current redirecting guide distinguishes temporary and permanent responses and explains options for larger redirect sets. The implementation matters less than the outcome: each former WordPress URL needs a stable, server-visible destination.

Google's JavaScript SEO guidance describes crawling, rendering and indexing as separate stages. Server rendering or pre-rendering is still useful because users and crawlers receive meaningful content immediately. A client-only page is not automatically excluded, but it introduces more places for an API error, blocked resource or empty application shell to weaken the result.

If the migration needs a technical review, a WordPress-to-Next.js migration audit should examine the response and rendered DOM, not only run a visual comparison.

Audit Canonicals, Robots Rules and the Sitemap Together

Migration faults often come from signals that are individually valid but collectively contradictory. A page may return 200, name itself in the sitemap and still canonicalise to the old WordPress address. Another may have a correct canonical but inherit a staging noindex rule.

For each indexable URL, expect:

• one absolute canonical pointing to the preferred live URL;
• no noindex directive in the HTML or response headers;
• no robots.txt rule blocking resources needed to render the page;
• the same preferred URL in internal links and the XML sitemap;
• a consistent protocol, hostname, case and trailing-slash policy;
• language and alternate annotations that reference real, reciprocal pages where used.

Do not use robots.txt to hide a page while hoping Google will read its noindex instruction. Google needs to crawl a page to see a noindex directive. Also check for an X-Robots-Tag at CDN or server level, because it will not appear as a visible meta tag in the page template.

Next.js can generate metadata, robots and sitemap files, but the framework cannot decide the correct business rules for you. Its metadata documentation explains how page metadata enters the generated head. Inspect the live HTML rather than assuming a code object produced the intended output.

Use a website audit and consultation when several systems can set these signals. A CMS field, Next.js layout, deployment environment and CDN rule can each affect the same URL.

Compare the New Page with the Old WordPress Page

A technically valid page can still be a weaker search result. During a redesign, teams often shorten copy, merge specialist pages into a general services page, remove author information, drop FAQs or replace useful text with animation. The new site may look cleaner while answering fewer questions.

Compare old and new versions side by side:

Do not restore words merely to match an old word count. Restore the value that earned visits and links. If two former pages now answer the same question, choose one strong destination and redirect the weaker URL. If each served a distinct audience, rebuild that distinction clearly.

Our guide to WordPress-to-Next.js rebuilds for speed and SEO covers the wider platform decision. Faster delivery is useful, but a framework change cannot compensate for lost meaning.

Find Duplicate and Near-Duplicate Routes

WordPress and Next.js often express taxonomies differently. A migration can accidentally publish several versions of the same content through:

• old and new category routes;
• tag, author and date archives;
• preview or draft endpoints;
• pagination and filtering parameters;
• URLs with and without a trailing slash;
• CMS preview domains;
• copied landing pages with only a town name changed;
• API-driven routes where missing data produces the same generic page.

Crawl the new website and group pages by title, canonical, heading, word count and content similarity. A large set of successful URLs with almost identical copy gives Google little reason to index each one. A sitemap should list only the canonical pages you genuinely want in search results.

Also check that staging is not publicly indexable. A staging copy can compete with the production page if it has been crawled, especially when its canonical tags point to itself. Protect it with authentication and keep it out of public navigation and sitemaps.

Repair Internal Discovery and Site Structure

A sitemap helps discovery, but it does not replace navigation. A service page linked only from an XML file can look unimportant compared with one placed in a clear service hierarchy and supported by relevant articles.

Trace the route from the homepage or main service hub to each affected page. Use ordinary HTML links with descriptive anchor text. Avoid relying on buttons that trigger JavaScript without a real destination. Add links where they help a person continue their task, not in a site-wide block of hundreds of keywords.

For an established article, update links from related posts that already receive visits. For a commercial page, connect it to the parent service page, relevant case evidence and helpful guides. Make breadcrumbs accurate and keep the hierarchy consistent in URLs, navigation and structured data.

A technical SEO review should include orphan-page checks and internal-link depth. It should not stop at validating a sitemap file.

Test the WordPress Data Pipeline

In a headless setup, WordPress may still provide the content while Next.js controls delivery. Check the complete publishing path:

• Is the WordPress status genuinely published rather than private or scheduled in another timezone?
• Does the API return the complete content to an anonymous request?
• Are pagination limits hiding older posts?
• Do cache tags or revalidation rules update the front-end after an edit?
• Does a failed request produce a correct error response rather than an empty 200 page?
• Are media URLs public and stable?
• Does the production build include dynamic routes created after the last deployment?

Test a newly published item and an edited existing item. Confirm the CMS record, API response, Next.js HTML, sitemap entry, internal links and canonical URL. That evidence separates a publishing failure from an indexing decision.

Prioritise the Fixes by Pattern and Value

Do not treat hundreds of excluded URLs as hundreds of separate tickets. Group them by cause and template. Fix the rule that affects the most useful pages first.

A sensible order is:

1. accidental noindex, blocked rendering resources and incorrect status codes;
2. canonical and redirect conflicts;
3. empty or incomplete rendered content;
4. duplicate routes and old-domain signals;
5. missing internal links and sitemap errors;
6. pages that need a clearer purpose or better content;
7. low-value archive URLs that should remain excluded.

Not every excluded URL needs repair. Search results do not benefit from internal search pages, duplicate filters, empty archives or obsolete previews. Define the set of pages that should be indexed, then measure progress against that list.

Validate the Recovery Without Chasing Daily Noise

After fixing a pattern, retest the live URLs. Check the response, rendered HTML, canonical, robots rules and links before asking Google to recrawl a small representative set. Submit an accurate sitemap for the wider group.

Record the date of each change. Monitor Page indexing, impressions, clicks, server errors and organic landing pages over several weeks. Google says meaningful site moves can cause temporary ranking movement while pages are recrawled and reprocessed in its current site migration guidance. A clean technical result does not produce instant rankings, and repeated indexing requests do not accelerate a page that still has weak or conflicting signals.

Use the recovery period to confirm business outcomes as well. Forms, telephone links and booking journeys must work on the new pages. An indexed page that no longer records enquiries is not a successful migration.

Frequently Asked Questions

What does crawled but not indexed mean after a migration?

It means Google fetched the URL but has not selected it for its searchable index. Check the rendered content, canonical, robots directives, duplication, internal links and the page's usefulness before requesting indexing again.

Is Next.js bad for Google indexing?

No. Next.js can produce highly crawlable server-rendered or pre-rendered pages. Problems usually come from implementation details such as empty initial HTML, failed data requests, conflicting metadata, weak redirects or duplicate routes.

Should I request indexing for every affected page?

No. Fix the shared cause first, test representative URLs and submit an accurate sitemap. Requesting indexing repeatedly does not solve technical conflicts or make low-value pages more useful.

How long does reindexing take after a WordPress-to-Next.js migration?

There is no fixed timetable. Google may process individual URLs in days, while a wider migration can take weeks or longer depending on site size, server capacity, crawl demand and the scale of the changes.

Do I need to keep redirects from the old WordPress URLs?

Yes, where an old URL has a relevant replacement. Use a server-side permanent redirect to the closest equivalent page, avoid chains and keep redirects for at least a year; retaining useful redirects longer is often sensible.

Make the Indexing Decision Easy to Understand

The recovery goal is not to force every migrated URL into Google. It is to present one stable, useful and technically consistent version of each page that matters. Start with a small sample, prove the pattern, then repair the shared template or rule.

If the evidence spans WordPress, Next.js, hosting and Search Console, contact MattDarm with the affected URL list and migration date. A focused diagnosis is more useful than another blind indexing request.