Pages Not Indexed After Site Migration: A 4-Month Forensic Fix Plan

A migration reporting 64 indexed URLs and roughly 2,000 not indexed URLs after four months is not a routine “wait a little longer” situation. If you have pages not indexed after site migration, this guide gives you a practical way to separate normal old-to-new consolidation from a redirect, canonical, crawl, or indexability problem that needs fixing.

A recent SEO community case described a move from drivly.ro to sofer24.ro in June 2026. The owner had implemented permanent redirects, submitted a Google Search Console Change of Address request and a new XML sitemap, updated canonical tags and internal links, and checked robots.txt—yet, by October 2026, about 1,000 URLs were marked “Crawled – currently not indexed” and another 1,000 were “Discovered – currently not indexed.” That is the point where we stop treating the migration as a black box and start collecting evidence.

Four months is an escalation threshold, not a deadline

Google does not publish a universal number of days in which every migrated URL must be indexed. Site size, URL changes, rendering requirements, server reliability, crawl demand, and how closely the new pages match their old equivalents all affect the pace.

However, Google’s Change of Address process is associated with a 180-day period, and Google recommends using it only after moving the site and implementing redirects. Four months is therefore still within a broad migration window, but it is late enough to audit aggressively when a large share of valuable pages remain absent from the new domain.

Some old URLs continuing to appear in results is not automatically a failure. Google may retain old-domain URLs while it repeatedly processes redirects and consolidates signals. The real concern is a pattern such as this:

• Legacy pages had impressions, clicks, links, or strong rankings before the move.
• Their intended replacements are indexable and included in the new sitemap.
• The old URLs redirect correctly, but the new URLs remain excluded for weeks or months.
• The affected pages are clustered in important templates, folders, languages, or page types.

Treat four months as an escalation threshold. Do not launch a redesign, rewrite thousands of pages, or submit every URL manually before you know why Google is excluding them. A migration combines several signals at once; changing everything again makes the real cause harder to identify.

First, verify that the new URLs are truly missing

Before diagnosing an indexing failure, distinguish “not ranking as expected” from “not indexed.” A new page can be indexed but have little visibility, while an old result may still rank temporarily and redirect visitors to the new domain.

Start with a representative sample of 25 to 50 URLs, not a random export of thousands. Include the homepage, top landing pages, high-traffic articles or products, deep category pages, a few pages marked indexed, and pages from each Page indexing exclusion bucket.

For every sampled new URL, use Google Search Console’s URL Inspection tool and record:

1. Whether Google says the URL is on Google.
2. The last crawl date and crawl status.
3. The user-declared canonical.
4. The Google-selected canonical.
5. Whether indexing is allowed.
6. Whether the page appears in a submitted sitemap.

Also search for the exact URL using a site: query, but do not treat that as the final authority. Search Console’s URL Inspection result is more useful for a specific page because it can show canonical selection and indexing status.

Create a spreadsheet with five columns at minimum: old URL, expected new URL, redirect result, URL Inspection result, and Page indexing reason. This is the foundation of the forensic audit. Without it, “most pages are not indexed” is too broad to fix.

Identify the Page indexing reason before changing anything

The Page indexing report is an inventory of Google’s crawl and index decisions, not a single error list. Export the affected URL examples from each reason bucket and compare them by template, directory, content type, and priority.

Crawled – currently not indexed after migration

“Crawled – currently not indexed” means Google fetched the page but has not selected it for the index at that time. It does not, by itself, prove a robots.txt or server-access problem.

After a migration, common explanations include a mismatch between the new page and its old equivalent, duplicate or near-duplicate signals, weak internal linking, thin template variations, or Google selecting another canonical. It can also occur when the rendered page differs materially from the HTML Google first receives.

Check whether the affected URLs share one pattern. For example, if 800 of 1,000 excluded pages are paginated listings, filter pages, city pages, or lightly differentiated service pages, a sitewide template or quality issue is more likely than an individual URL problem. For a focused remediation workflow, see our guide to fixing Discovered – currently not indexed URLs.

Discovered – currently not indexed after migration

“Discovered – currently not indexed” generally means Google knows the URL but has not crawled it yet. This often points toward discovery and crawl prioritization rather than a page-level indexability block.

Check that the URL is present in the correct new-domain XML sitemap, receives internal links from crawlable pages, returns a fast and stable 200 response, and is not buried behind a massive number of low-value URLs. Google can discover pages outside a sitemap, but sitemaps help communicate which URLs you consider important.

Other exclusion reasons to sort immediately

Do not lump these reasons together with the two statuses above:

• Excluded by noindex tag: Check both HTML meta robots and the X-Robots-Tag HTTP header.
• Blocked by robots.txt: A migration may leave staging, legacy, or CDN rules in place.
• Duplicate without user-selected canonical: Google found duplicates but lacks a clear preferred version.
• Google chose different canonical than user: Your declared canonical conflicts with other signals.
• Page with redirect: This is expected for old URLs, but unexpected for URLs you intended to index on the new domain.
• Soft 404: A migrated page may technically return 200 but look empty, unavailable, or substantially unhelpful.

The goal is not to get every URL into the index. The goal is to identify which valuable canonical URLs should be indexed and why Google is currently declining or delaying them.

Audit old-to-new redirect-map coverage

For a domain migration, redirect mapping is the central evidence trail. Google’s site-move guidance recommends preparing a map of old URLs to new URLs and using permanent server-side redirects. A homepage-wide redirect or “send everything to the new homepage” rule is not a substitute for page-level mapping.

Build a redirect inventory from your pre-migration sitemap, analytics landing-page reports, Search Console performance exports, CMS URLs, and backlink data. Then test each old URL against its expected destination.

What a useful redirect audit checks

For every important old URL, confirm that it:

• Returns one clean server-side permanent redirect, preferably HTTP 301 or 308.
• Lands on the closest equivalent new URL, not merely a category page or homepage.
• Avoids chains such as old URL → HTTP URL → www URL → final new URL.
• Avoids loops, 404s, 5xx responses, JavaScript-only redirects, and irrelevant destinations.
• Preserves meaningful parameters only where those parameters create a legitimate canonical page.

A 308 redirect can communicate permanence, as in the source case, but the status code alone does not solve poor mapping. If an old high-ranking page redirects to a generic page, Google has less evidence that the destination is its equivalent.

Prioritize legacy URLs with the greatest opportunity cost. We usually score them using four signals: organic clicks before migration, impressions before migration, referring domains or links, and conversion value. Start with the top 50 to 200 URLs rather than trying to perfect 2,000 low-priority URLs first.

Check canonical, robots, and noindex signals as one system

Canonicalization is not determined by a single rel=canonical element. Google can use redirects, canonicals, sitemap inclusion, internal links, HTTPS preference, and content similarity as signals when selecting a representative URL.

For each sampled new URL, the strongest expected pattern is straightforward:

• The old URL returns a permanent redirect to the new URL.
• The new URL returns HTTP 200.
• The new URL has a self-referencing canonical.
• The XML sitemap lists the new canonical URL only.
• Internal links point directly to the new canonical URL.
• The page is not blocked by robots.txt and carries no noindex directive.

Use URL Inspection to compare the user-declared canonical with Google’s selected canonical. If Google selects the old URL, another parameterized URL, a non-www host, or an unrelated page, do not just request indexing again. Find the contradicting signal.

Typical migration mistakes include a canonical tag still referencing the old domain, a CMS environment setting outputting noindex, or a CDN rule attaching an X-Robots-Tag: noindex header. Header-level noindex directives are easy to miss because the visible page source may look correct.

Canonical mismatch is especially relevant when content is largely unchanged. Keeping content similar is normal during a domain move; the issue is whether all technical signals consistently establish the new URL as the preferred version. If Google is choosing www unexpectedly, our guide to diagnosing Google’s www canonical choice can help isolate host-level conflicts.

Prove sitemap discovery and internal-link support

A clean XML sitemap does not force indexing, but it is still a key migration signal. It tells search engines which current URLs you want crawled and considered as canonical. The sitemap should contain only indexable, canonical, HTTP 200 URLs on the new domain.

In Search Console’s Sitemaps report, inspect the submitted sitemap for processing errors and compare the discovered URL count with your expected inventory. Google allows a single sitemap file to contain up to 50,000 URLs or 50 MB uncompressed; larger sites should split their sitemap files and use a sitemap index.

For a migration with about 2,000 new URLs, the file-size limit is unlikely to be the problem. More likely issues are stale URLs, mixed old and new hosts, accidentally omitted folders, sitemap URLs that redirect, or URLs that carry noindex tags.

Then inspect internal links. Important migrated pages should not rely solely on old-domain redirects or sitemap discovery. They need direct crawl paths from the new homepage, primary navigation, hub pages, relevant category pages, and contextual links.

A useful test is to ask: if the old domain disappeared tomorrow, could Googlebot still discover the high-value new page through ordinary new-domain links? If the answer is no, strengthen the internal architecture before expecting fast consolidation.

Use Crawl Stats and server logs to separate crawling from indexing

Google Search Console’s Crawl Stats report provides the macro view: Googlebot requests, response codes, host availability, and crawling history. The URL Inspection tool provides the page-level view. Use both, because a site can appear healthy at a URL level while a server or rendering pattern affects a whole folder.

Look for these concrete signals during the migration period:

• Increased 5xx responses, timeouts, or host-availability warnings.
• Large volumes of redirects rather than 200 responses on the new domain.
• Googlebot spending disproportionate requests on parameter URLs, filters, or old URLs.
• Important new folders receiving few or no Googlebot requests.
• A sudden drop in crawling after a deployment, firewall change, CDN change, or robots.txt update.

If you have access to server logs, filter requests by verified Googlebot and compare the log data with the affected URL sample. Did Googlebot request the URL? What status code did your server actually return? Did the response time spike? Did the rendered content require scripts or resources that were blocked?

Google recommends using Crawl Stats when investigating availability issues. A page can be crawlable in an occasional browser test but still be unreliable under bot traffic because of rate limiting, WAF rules, unstable origin servers, or conditional responses.

Make focused fixes, then request recrawls selectively

Once the audit identifies a cause, fix the pattern rather than applying random page-by-page changes. For example, correct one canonical template, redirect rule, robots rule, sitemap generator, or internal-link module, then validate a sample before expanding the change.

Use Search Console’s request-indexing option for a small group of high-value URLs after a material correction. Google says recrawling can take days to weeks, and a request does not guarantee indexing. It is useful for confirming that Google has seen a genuine fix; it is not an efficient replacement for making thousands of URLs discoverable and indexable.

Do not submit every migrated URL one by one. A better sequence is:

1. Fix the technical or architectural blocker.
2. Resubmit or update the XML sitemap if needed.
3. Request indexing for 10 to 20 representative, high-value URLs.
4. Monitor canonical choice, crawl dates, and Page indexing reason changes.
5. Expand only when the sample moves in the right direction.

We also should not position Google’s Indexing API as a shortcut for ordinary migrated pages. Google documents that API for JobPosting pages and livestream video pages using BroadcastEvent markup, not as a general indexing-submission route for standard site-move URLs.

Monitor the migration inventory for at least 90 days after the fix

A migration is not complete when the Change of Address request is submitted. It is complete operationally when your priority URLs redirect correctly, the new canonical URLs are consistently discoverable, and trends in indexing and traffic stabilize.

Maintain a weekly migration dashboard with these four comparisons:

1. Old redirect inventory vs. new sitemap: Every priority old URL should map to an intended new canonical URL, and every expected new canonical should be in the sitemap.
2. Sitemap vs. Page indexing exports: Flag important sitemap URLs that are excluded or have not been crawled.
3. URL Inspection sample vs. canonical expectations: Watch for Google-selected canonicals that differ from the intended new URLs.
4. Server logs/Crawl Stats vs. deployment changes: Watch for availability, redirect, and crawl-pattern regressions after releases.

This is where automated sitemap monitoring becomes useful. At Indexa, we use sitemap-change monitoring to surface new or updated URLs so site owners and agencies can see what changed rather than discovering a missing sitemap entry weeks later. For ordinary pages, the value is reliable discovery monitoring and search-engine notification where supported—not pretending that an API call overrides Google’s indexing decisions.

If Bing is also part of the migration, monitor it independently. A URL indexed in Google is not automatically indexed in Bing, and the causes can differ across engines. Our guide to diagnosing pages indexed on Google but not Bing covers that gap.

What to do this week if the migration is stuck

For the drivly.ro to sofer24.ro scenario, we would not recommend a wholesale content rewrite as the first move. The site already preserved core content, set redirects, updated links and canonicals, and submitted a sitemap; the next move is to validate whether those signals are consistent across the actual affected URLs.

Use this seven-day plan:

• Day 1: Export Page indexing examples for every major exclusion reason and select a 25-to-50 URL representative sample.
• Day 2: Test the old-to-new redirect mapping for all high-value legacy URLs and identify chains, irrelevant destinations, and failures.
• Day 3: Inspect canonicals, meta robots, HTTP headers, robots.txt access, and sitemap inclusion for the sample.
• Day 4: Review internal links and crawl paths to the most valuable excluded pages.
• Day 5: Check Crawl Stats, server availability, and Googlebot logs if available.
• Day 6: Fix the dominant technical pattern and validate it on a small sample.
• Day 7: Request recrawls for a limited number of corrected priority pages and document the baseline for weekly monitoring.

If URLs are technically sound but remain “Crawled – currently not indexed,” investigate template quality and duplication at the page-set level. The right question is not whether you can add more words to every page; it is whether each page has a distinct user purpose, useful primary content, and a credible place in the site’s internal architecture. For a broader comparison of manual Search Console work and automation, read Google indexing automation software vs. Search Console and IndexNow.

FAQ

How long does Google take to index a new domain after a migration?

There is no fixed timeline. Google Search Console’s Change of Address process has a 180-day window, but individual URLs can move sooner or later depending on redirects, crawl demand, site scale, canonical consistency, and server health. At four months, some lag can be normal, but many important URLs still excluded should trigger a structured audit.

Why are my old URLs still indexed while the new domain pages are not?

Old URLs can remain visible while Google processes permanent redirects and consolidates signals. This is not automatically a problem. It becomes concerning when the old URL maps cleanly to a new equivalent, the new page is crawlable and canonicalized correctly, yet the new page is persistently excluded or Google selects the old URL as canonical.

Do I need a 301 redirect for every old URL after changing domains?

You should use a permanent server-side redirect for every valuable old canonical URL that has a relevant replacement. Google recommends mapping old URLs to their new counterparts. Avoid sending everything to the homepage: one-to-one or closest-equivalent redirects provide much clearer continuity for users and search engines. A 308 can also express permanence, but relevance of the destination matters most.

What does “Crawled – currently not indexed” mean after a site migration?

It means Google fetched the URL but has not included it in the index at present. It does not automatically mean robots.txt is blocking the page. After a migration, inspect canonical selection, page similarity, internal links, sitemap inclusion, rendering, response quality, and whether the affected URLs share a low-value or duplicated template pattern.

Should I submit every migrated URL for indexing in Google Search Console?

No. Request indexing for a small sample of high-priority URLs after you have fixed a verified issue. Google says requests do not guarantee indexing and can take days or weeks. For thousands of migrated pages, clean redirects, accurate sitemaps, internal links, canonical signals, and reliable server responses are more scalable and more meaningful than repeated manual requests.

How long should I keep 301 redirects live after a domain migration?

Keep them for the long term—ideally as long as you control the old domain. The Change of Address request is time-limited, but links, bookmarks, old search results, and crawlers can continue to reach old URLs long after the initial migration. Removing redirects early creates avoidable 404s and interrupts the old-to-new signal path.