Domain Migration SEO: 4 Months Later, Pages Still Aren’t Indexed

A site owner moved an established Romanian site in June 2026, set up permanent redirects and Change of Address, then reached October with only 64 indexed pages and roughly 2,000 not indexed. This domain migration SEO guide gives you a practical way to separate pages Google cannot index from pages Google has chosen not to index, so you can prioritize the fixes most likely to restore visibility.

Four months is not proof of a permanent penalty, a mythical “Sandbox,” or irreversible authority loss. It is, however, long enough to investigate the migration as a live diagnostic case instead of treating every missing URL as a reason to submit another sitemap.

Four months after a migration: investigate, do not panic

The case that prompted this guide involved a move from drivly.ro to sofer24.ro, beginning in June 2026. The owner reported 308 permanent redirects, updated canonicals and internal links, a new XML sitemap, robots.txt checks, and a submitted Google Search Console Change of Address request. Yet by October 2026, Search Console showed about 1,000 URLs as “Crawled – currently not indexed” and another 1,000 as “Discovered – currently not indexed.”

That pattern matters because these are not one problem. A URL Google has not crawled needs a different response from one Google crawled, rendered, and declined to include in the index.

Google’s site-move guidance does not publish a universal number of days for rankings or indexing to transfer. It recommends keeping the architecture as similar as possible, mapping old canonical URLs to their corresponding new URLs with permanent redirects, and avoiding an unnecessary redesign at the same time. A large site, weak URL mapping, changed templates, or thousands of low-value URLs can make consolidation less predictable.

We would treat month four as a threshold for a focused audit, especially when previously ranking commercial or editorial pages are absent on the new domain. Do not make sitewide content rewrites first. Start by proving what Google sees for a representative sample of valuable old-to-new pairs.

For a broader recovery sequence, see our four-month forensic migration fix plan.

Build an old URL to new URL evidence set

A migration is not validated by checking the homepage and a handful of category pages. Build a spreadsheet of at least 100 URLs: the old homepage, top landing pages by clicks, top linked pages, key categories, and a random sample of long-tail pages. If the website has only 2,000 migrated URLs, audit every URL with a crawl; if it has 100,000, begin with the URLs that historically generated organic value.

Use columns that let you identify patterns rather than isolated exceptions:

• Old URL and new intended URL
• Old URL HTTP status and final destination
• Redirect hop count
• New URL HTTP status
• User-declared canonical and Google-selected canonical
• Indexing status in the new Search Console property
• Last crawl date and sitemap status
• Internal-link count to the new URL
• Old-domain impressions/clicks versus new-domain impressions/clicks

A clean mapping should be one old canonical URL to one relevant new canonical URL. Sending 500 old vehicle-service pages to one new category page, for example, may be technically functional but is not a like-for-like migration. Google needs to understand the relationship between the old document and the replacement document.

Check redirect behavior with a crawler and with command-line or browser-header testing. The old URL should return one permanent redirect to the intended new URL, and the new URL should return 200 OK. Investigate chains such as old URL → http new URL → https new URL → trailing-slash variant. Also investigate loops, redirects to irrelevant pages, soft 404-like destinations, and URLs that vary by user agent, cookies, language, or IP address.

Google commonly documents 301 redirects in site-move instructions. A 308 status is also permanent in HTTP semantics, but we would not assume that a redirect is correct because its status code looks permanent. The decisive test is whether Googlebot consistently receives a single, accessible, relevant destination.

Use Google Search Console to classify the actual failure

Google Search Console’s Page Indexing report is useful for spotting sitewide patterns; the URL Inspection tool is the correct tool for diagnosing a specific important page. Inspect both sides of the relationship: the old URL in the old property and the new URL in the new property.

For each sample URL, capture these fields from URL Inspection:

1. Page indexing status — indexed, excluded, or not indexed.
2. Crawl allowed and indexing allowed — a failed result here is a technical blocker.
3. User-declared canonical and Google-selected canonical — a mismatch is evidence, not a cosmetic detail.
4. Last crawl and crawl status — useful for determining whether Google has revisited the URL since a fix.
5. Referring sitemap — confirms discovery, not acceptance into the index.

The four migration buckets

We group affected URLs into four practical buckets:

• Blocked: Google cannot access, render, or index the new URL because of robots.txt, a noindex directive, authentication, server errors, or a broken redirect.
• Redirected incorrectly: The old URL reaches the wrong new page, passes through chains, or lands on a page Google sees as a poor replacement.
• Discovered or crawled but not indexed: Google knows the new URL, but it has not made it searchable. This is often a prioritization, duplication, or page-value question rather than a crawl-access question.
• Indexed under the old URL: The old version remains in results while the new equivalent has not become Google’s preferred result.

Do not use the Page Indexing totals as a traffic forecast. A site can have many intentionally excluded filter pages and still perform well, while ten missing high-value landing pages can cause most of the migration’s traffic loss.

Diagnose “Crawled – currently not indexed” after a move

“Crawled – currently not indexed” means Google fetched the page but has not added it to the index at that point. It does not automatically mean robots.txt blocked it; Google had to crawl it to assign that status. It also does not guarantee that another sitemap submission will change the decision.

In the October 2026 example, around 1,000 URLs were in this status. We would compare 20 affected pages with 20 newly indexed pages in the same template or folder. Look for a shared explanation: thin location pages, near-identical service pages, empty product inventory, pagination variants, canonical conflicts, or pages that gained content but lost clear relevance during the rebuild.

Check the page Google actually rendered

Use URL Inspection’s live test and rendered-page information. Confirm that the main content is present without user interaction, that critical JavaScript files are available, and that the HTML or rendered output includes the title, headings, body copy, internal links, and canonical you expect.

Then ask whether the new document is materially the same page users and Google knew before the move. Adding 500 words after migration does not necessarily solve an indexing problem. If those additions make a focused page generic, repetitive, or less useful than the old URL, they can make consolidation harder rather than easier.

This is also where “duplicate content” needs precision. Reusing content from the old domain during a correctly redirected domain move is not automatically a problem. The risk appears when the old URL is still reachable with a 200 response, the new URL points canonically back to the old domain, several new URLs compete for the same content, or Google chooses a different canonical than the one you intended.

If this status affects priority pages, our guide to fixing Crawled – currently not indexed pages explains the content and consolidation side of the diagnosis.

Diagnose “Discovered – currently not indexed” separately

“Discovered – currently not indexed” means Google has learned about the URL, often through an XML sitemap or links, but has not yet crawled it. A sitemap is doing part of its job in this scenario: it is helping discovery. It is not a command that requires Google to crawl or index every listed URL immediately.

For a migration with roughly 2,000 unindexed URLs, the next checks should be structural:

• Is the URL linked from a crawlable category, navigation page, HTML sitemap, or relevant editorial page?
• Is it more than a few clicks deep from useful hub pages?
• Is the page in the current sitemap with its canonical HTTPS URL only?
• Does the server respond quickly and consistently with a 200 status?
• Are there thousands of parameter, faceted-navigation, tag, search-result, or duplicate URLs competing for crawl attention?

Google advises site owners with more than about 500 pages to use the Page Indexing report, because aggregate patterns become more valuable at that scale. In a migration, that means looking at folders and templates. If nearly every /city/ page is discovered but unindexed while /services/ pages are indexed, the issue is more likely to be template quality, internal linking, or duplication than a random delay.

Improve discoverability by linking important new URLs from their most relevant indexed parents, reducing wasteful crawl paths, and keeping only canonical, indexable URLs in the XML sitemap. Do not respond by submitting thousands of individual requests; that produces activity without proving the underlying pages deserve priority.

Check robots.txt, HTTP headers, canonicals, and duplicates

The fastest migration fixes are often hidden in directives rather than content. Audit both the response headers and rendered HTML for the new URL, plus the old domain’s behavior.

Technical checks that must pass

For every priority new URL, confirm all of the following:

• The final URL returns 200 OK, not 302, 403, 404, 429, 5xx, or a redirect to a different canonical.
• robots.txt allows Googlebot to crawl the page and required rendering assets.
• There is no <meta name="robots" content="noindex"> and no X-Robots-Tag: noindex HTTP header.
• The self-referencing canonical is the full preferred new-domain URL.
• Hreflang annotations, if used, point to live canonical alternates on the correct domain.
• The XML sitemap includes the new canonical URL, not old URLs, redirected URLs, parameters, or noindex pages.
• Internal links use the new canonical URLs directly rather than relying on redirects.

HTTP headers are easy to overlook during a platform or CDN migration. A staging rule, edge worker, security layer, or application middleware can deliver a different status or X-Robots-Tag to crawlers than the browser test your team performed.

Also check whether the old domain is still serving content at 200 rather than redirecting. If both old and new pages are fully available, Google has to choose between duplicate documents. That can explain why the old site is still ranking even after the new site has launched.

Restore consolidation signals beyond the redirect

A permanent redirect is the central migration signal, but it is not the only signal. We want every other signal to agree that the new domain is the permanent home.

First, keep the old domain registered, HTTPS-enabled, and redirecting. Removing the old site too early breaks the path for users, backlinks, Google recrawls, bookmarks, and old search results. Google’s Change of Address tool is helpful for a domain move, but it does not replace redirects or make old URLs disappear from results overnight.

Second, update the backlinks you control. That includes business profiles, social accounts, partner directories, paid placements, high-value editorial links you can request changes for, and links from your own other websites. You cannot update every historical backlink, but reducing dependence on redirects for your strongest links gives Google clearer new-domain signals.

Third, keep page purpose stable. If the old URL was a ranking guide to driving lessons in Bucharest, map it to the matching new guide—not a generic driving-school homepage. Preserving the same URL paths where feasible can simplify mapping, but it does not preserve Search Console data as though nothing changed: a new domain is a different property and needs its own monitoring.

Use the new domain’s Performance report to watch query and landing-page trends weekly, while keeping the old property verified. A declining old-domain click trend paired with a rising new-domain trend is healthier than a simple count of indexed pages.

For cases where Google has adopted the new site but Bing has not, use our separate Google-versus-Bing indexing gap checklist.

A 30-day recovery workflow for priority URLs

Do not change every affected page at once. That destroys your ability to learn which change resolved the issue. Start with priority URL groups and maintain an audit log with the date, issue, fix, and recrawl result.

Days 1–7: prove the migration mechanics

Crawl old URLs and validate the redirect map. Fix chains, loops, 200-status old pages, incorrect destinations, noindex directives, canonical mismatches, accidental robots blocks, and sitemap contamination. Resubmit the cleaned sitemap in Search Console after the fixes—not before.

Days 8–14: repair the most valuable page groups

Take the top 20 to 50 missing URLs by historical clicks, links, leads, or revenue. Verify that each has an equivalent destination, useful main content, internal links from an indexed hub, and no duplicate sibling that targets the same intent. Improve the document where it is genuinely weaker than the former page; do not add filler solely to increase word count.

Days 15–30: request, monitor, and expand by pattern

Use URL Inspection to request indexing for a small set of corrected, high-priority URLs. Then wait for Google to recrawl and monitor the indexed data rather than repeatedly requesting the same page. If one template group starts moving, apply the verified fix to the remaining matching URLs.

At Indexa, we use sitemap monitoring to make changed and newly discovered URLs visible promptly, so teams can act when meaningful pages change. That is useful operationally, but it does not override Google’s indexing decision or transfer authority by itself. Discovery signals and indexing requests can speed awareness; they cannot force Google to index a duplicate, blocked, irrelevant, or low-value destination.

What not to blame on a fixed timetable

Do not assume Google holds every migrated domain for exactly 60 days, 90 days, or six months. There is no public fixed waiting period that guarantees transferred rankings or index coverage. Google’s Change of Address request is associated with an approximately 180-day period, but that is not a promise that every URL will be indexed or that rankings will fully transfer on day 180.

Likewise, do not call every migration issue a domain-authority problem. Lost backlinks, changed internal architecture, blocked rendering, redirect errors, canonical conflicts, duplicate pages, and lower-value templates can each explain missing pages without requiring a theory that the new domain has no trust.

A useful decision rule is simple: if the same defect appears across many URLs, fix the template or migration rule. If only a handful of pages remain crawled but unindexed after the technical audit, compare their search intent and usefulness with the pages Google chose to retain. That keeps the work evidence-led rather than driven by a calendar.

FAQ

Why isn’t Google indexing the new domain four months after migration?

Four months is long enough to audit seriously, but it does not identify a single cause. Check URL Inspection for the exact status, then separate blocked URLs, incorrect redirects, canonical mismatches, “Discovered – currently not indexed” URLs, and “Crawled – currently not indexed” URLs. A sitemap can help discovery, but it cannot require Google to index every migrated page.

How long does it take Google to transfer rankings and authority after a 301 domain migration?

There is no reliable fixed timeline. Google’s Change of Address process is designed for domain moves and operates over an approximately 180-day period, while Google recrawls old and new URLs. Rankings can fluctuate for weeks or months, particularly on large sites. Keep permanent one-to-one redirects live long term and track query-level performance, not only index counts.

Why is the old domain still ranking after the new site launched?

Google can continue showing old URLs while it processes the relationship between the old and new versions. This becomes a concern when old pages still return 200 responses, redirects are broken or irrelevant, canonicals conflict, or the new URLs are not strong replacements. Keep the old domain redirecting; do not take it offline just because some old URLs remain visible.

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

It means Google successfully crawled the new URL but did not include it in the index at that time. Check Google-selected canonical, rendered content, duplicate page patterns, page usefulness, and whether the old URL remains available as a competing 200-status page. Repeated sitemap submissions do not solve a decision Google has already made after crawling.

Do I have to wait 60 days to transfer a domain, and will keeping the same URLs preserve Search Console data?

A registrar’s domain-transfer timing is separate from Google’s indexing and ranking consolidation. You do not need to wait a universal 60 days for Google to process a migration. Keeping path structures similar helps preserve page relationships, but a different domain is a different Search Console property; keep both properties verified so you can compare old and new performance during the transition.