Back to Article List

Migration Won't Index? Google May Be Judging Quality

Migration wird nicht indexiert? Google prüft die Qualität - Migration Won't Index? Google May Be Judging Quality

If you've moved a site, your 301s all return the right status, your canonicals point home, and Google still won't index the new URLs — the problem probably isn't your redirects. It's that Google is re-evaluating whether your pages deserve to rank at all, and a migration is the moment it re-opens that question.

This is the uncomfortable reading Marie Haynes has been pushing: some migration indexing failures are a site-quality signal wearing a technical costume. The move didn't break anything. It just forced a fresh judgement on content that was already borderline, and this time the pages lost.

Here's how to tell the difference, and the content moves that actually break the logjam.

Why a clean migration can still refuse to index

A migration resets Google's trust in your URLs, and if the underlying content is thin or unoriginal, the new pages can fail the quality bar even when every redirect is perfect.

On an established domain, pages coast on history. Google has crawled them for years, they've earned a few links, and the signals are settled. Move that content to a new domain or restructure it, and you hand Google a reason to re-assess from something closer to zero. The redirect tells Google where the content went. It doesn't vouch for whether the content was worth keeping.

So when thin pages that limped along for years suddenly won't index after a move, nothing broke. The migration removed the inertia that was propping them up. Google took a fresh look and decided these URLs don't add enough to warrant a spot in the index.

This is why two identical-looking migrations go differently. A site of genuinely useful pages reindexes in days. A site padded with near-duplicate category pages, spun product descriptions, or AI-generated filler stalls for weeks, and no amount of redirect auditing fixes it.

First, rule out the real technical culprits

Before you blame quality, confirm the boring causes are actually clean — because most stalled migrations really are technical, and you don't want to rewrite content to solve a robots.txt typo.

Run this checklist on the new site before assuming anything deeper:

  • robots.txt — is it accidentally still blocking crawl from the staging config? Fetch yourdomain.com/robots.txt and read it line by line.
  • Redirect chains — each old URL should hit the new one in a single 301, not a chain of three. Test with curl -sIL https://old-url and count the hops.
  • Canonicals — new pages should self-canonicalise, not point back to the old domain. View source and check the rel=canonical tag.
  • noindex leftovers — staging sites ship with noindex. Grep your templates for it before launch and after.
  • Internal links — do your menus and body links point to new URLs, or are they still firing through redirects? Update them to the final destination.
  • Sitemap — submit a fresh XML sitemap of new URLs in Search Console and watch the coverage report.

Give it two to four weeks after a correct migration. If pages are still sitting in "Crawled – currently not indexed" or "Discovered – currently not indexed" with every box above ticked, you've moved past a technical problem.

How to test whether originality is the real blocker

Use Search Console's Page Indexing report as a quality thermometer: the pattern of which pages index and which don't usually points straight at the content, not the server.

Look at which URLs are stuck. If your cornerstone articles and genuinely unique product pages index fine while thin tag archives, boilerplate location pages, and lightly-reworded blog posts stay out, Google isn't confused — it's choosing. "Crawled – currently not indexed" in particular is Google saying it saw the page, understood it, and decided to skip it. That's a verdict, not a bug.

Three quick tests to confirm:

  • The paste test. Take a distinctive sentence from a stalled page and search it in quotes. If a dozen other sites rank for the same phrasing, your page adds nothing new.
  • The "what do I know" test. Read the page and ask what first-hand fact, number, screenshot, or opinion appears here that isn't on the first page of results already. If the answer is nothing, that's your blocker.
  • The ratio test. Count your indexed pages against your total. A site where 40% of URLs won't index has a content problem, not a redirect problem.

If the stuck pages are the weak ones and the strong ones sailed through, stop auditing redirects. You've found it.

The content moves that break the logjam

The fix is subtraction before addition: cut the pages Google already rejected, then make the survivors demonstrably more useful than what already ranks.

Start by pruning. Pages that were thin before the move won't magically earn indexing after it. For each stalled low-value URL, pick one:

  • Merge several thin posts into one substantial guide and 301 the old ones into it.
  • Rewrite the page to add something that isn't already everywhere — your own data, a worked example, a screenshot series, a clear position.
  • Remove it entirely and redirect to the closest strong page, or let it 410 if nothing fits.

Then strengthen what's left. Originality to Google isn't just "not plagiarised" — it's "information gain," the stuff a reader can't get from the ten pages already ranking. On a product page that means real specs, real photos you took, honest trade-offs. On a blog post it means a step you actually ran, a result you actually measured. Replace any paragraph that could appear verbatim on a competitor's site.

Finally, concentrate your internal links on the handful of pages you want indexed first. A tidy site of 40 strong pages indexes faster and ranks better than a sprawling 400-page site that's mostly filler, and the migration is your excuse to become the former.

Why migrations are the moment this surfaces

A migration doesn't create a quality problem — it exposes one that was already there, because the move strips away the historical trust that was quietly carrying your weak pages.

Think of it as a forced audit. Day to day, Google rarely re-judges settled URLs. Change the domain, consolidate the structure, or swap the platform, and you volunteer every page for re-inspection at once. That's genuinely useful information: the pages that don't come back were living on borrowed time anyway.

The practical takeaway is to treat a migration as a content exercise with a technical component, not the reverse. Audit and prune before you move, so you're not redirecting dead weight across to a fresh domain and asking Google to re-approve it. A smaller, honest site migrates cleaner every time.

If you're planning a move and want the plumbing handled while you focus on the content, TPC Hosting does free migrations for you, so you're not firefighting redirects and DNS at the same time as rewriting pages. Everything stays EU-hosted and GDPR-friendly, and if the new setup isn't right you've got 30 days to back out. When something looks off mid-move, our AI on chat answers at any hour and real engineers follow up in business hours — handy when a sitemap won't submit at 11pm.

A simple before-and-after to aim for

The goal is to arrive on the new domain with fewer, stronger pages — here's the shape of a healthy migration versus a stalled one.

SignalStalls in the indexIndexes fast
Page countEverything moved, including fillerPruned to pages that earn their place
ContentReworded from what already ranksFirst-hand facts, data, real images
RedirectsDead pages redirected "just in case"Weak pages merged or 410'd
Internal linksSpread thin across 400 URLsFocused on the pages that matter

If your move is stuck right now, don't start by re-auditing redirects for the fifth time. Open Search Console, sort by which pages won't index, and ask honestly whether those pages deserve to. Usually they tell you exactly what to do next.

Planning a move or untangling one that stalled? See how a done-for-you migration works at tpc-hosting.com and get the technical side off your plate while you fix the content.

FAQ

How long should I wait before assuming my migration has an indexing problem?

Give a correctly configured migration two to four weeks before worrying. Google needs time to recrawl and reprocess the new URLs, so pages sitting in "Discovered" early on is normal — persistent "Crawled – currently not indexed" after a month is the real warning sign.

Does "Crawled – currently not indexed" mean a technical error?

No — it usually means Google saw the page fine and chose not to index it. That status is a quality judgement, not a crawl failure, so the fix is almost always making the page more useful or removing it, not editing your server config.

Will deleting pages hurt my rankings after a migration?

Pruning thin pages that weren't ranking anyway helps far more than it hurts. Merge or redirect them into stronger pages so any residual value flows on, and concentrate Google's attention on the URLs you actually want in the index.

Can I avoid this problem by auditing content before I migrate?

Yes, and that's the smartest approach. Prune and strengthen weak pages on the old domain first, so you only migrate content worth re-approving — it's far easier than fixing an indexing stall after the move.