How to Fix Redirect Errors in Google Search Console After a Site Migration

To fix a redirect error in Google Search Console after a site migration, trace every affected old URL to its final destination, remove loops and unnecessary hops, and make sure the first response is a server-side 301 or 308 that points directly to a working, relevant new URL. Then update internal links, canonicals, and the sitemap before asking Search Console to validate the fix.

Do not confuse Redirect error with Page with redirect. “Page with redirect” normally means Google found an old or alternate URL that correctly forwards elsewhere, so that source URL is not indexed. “Redirect error” means Google could not successfully reach or process the destination.

What “Redirect error” means in Search Console

Google’s Page indexing report documentation lists four common causes:

• A redirect chain is too long.
• The redirects form a loop.
• A redirect eventually produces a URL that exceeds the maximum supported length.
• A step in the chain contains a bad or empty destination URL.

These problems often appear immediately after a domain change, CMS migration, URL-structure redesign, or HTTP-to-HTTPS move. A single rewrite rule can affect thousands of pages, so start by diagnosing the pattern rather than requesting indexing repeatedly.

1. Export the affected URLs and classify the problem

Open Search Console → Indexing → Pages, select Redirect error, and export the examples. The table is a sample rather than a complete inventory, but it usually reveals whether one template or rule is responsible.

Separate the URLs into groups such as:

• Old-domain pages that should permanently move to a matching new page.
• HTTP, www, non-www, or trailing-slash variants.
• Deleted pages with no genuine replacement.
• URLs containing parameters, encoded characters, or duplicated path segments.
• Images, PDFs, and other files moved with the site.

Inspect at least one URL from each pattern. Use Search Console’s URL Inspection tool and a header checker, or run a command such as:

curl -I https://old.example.com/example-page
curl -IL --max-redirs 10 https://old.example.com/example-page

The first command shows the initial response. The second follows the path so you can see every hop. Test the mobile and desktop versions if your server, CDN, or application treats user agents differently.

2. Make every old URL redirect directly to the final page

For a permanent migration, Google recommends server-side permanent redirects such as HTTP 301 or 308. Its redirect guidance explains that these responses signal that the target should become canonical.

A clean route looks like this:

https://old.example.com/guides/router-security
301 → https://new.example.com/security/router-security

A weak route may bounce through protocol, hostname, locale, and CMS changes:

http://old.example.com/page
301 → https://old.example.com/page
301 → https://www.old.example.com/page
302 → https://new.example.com/page/
301 → https://new.example.com/guides/page

Googlebot can follow multiple hops, but Google’s site-migration documentation advises redirecting directly to the final destination. If a chain cannot be eliminated, keep it as short as possible—ideally no more than three hops and fewer than five.

Fix loops at the rule level

A loop occurs when URL A points to URL B and another rule sends B back to A. It can also happen when your origin server forces one hostname while a proxy or CDN forces the opposite hostname.

Choose one canonical combination—typically HTTPS plus either www or non-www—and make every variation converge on it once. Check redirects at all layers:

• CDN or edge rules
• Web-server configuration
• CMS redirect plugins
• Application middleware
• Load balancer or hosting control panel

Avoid maintaining the same redirect in several places. Overlapping rules are harder to audit and can behave differently after a cache change.

Correct empty or malformed destinations

Look for a missing hostname, doubled protocol, unescaped space, duplicated query string, or unresolved variable. Common bad destinations include https://, https://new.example.com/undefined, and paths that repeatedly append themselves.

Also test URLs with non-English characters, uppercase letters, parameters, and encoded slashes. Migration scripts often work for simple paths but fail on edge cases.

3. Map old pages to relevant new pages

Create a one-to-one spreadsheet or database mapping of old URLs to new URLs. Each old page should normally redirect to the closest equivalent page, not the new homepage.

Google warns that redirecting many unrelated URLs to one destination can confuse visitors and may be treated as a soft 404. If a page was removed and there is no useful replacement, return a real 404 or 410. If several old pages were legitimately merged into one stronger resource, redirecting all of them to that consolidated page is reasonable.

Do not redirect solely because an old URL appears in Search Console. Some historical URLs were never valid. Fix URLs that you publish in links or sitemaps, and let genuinely nonexistent addresses return the appropriate error.

4. Align canonicals, internal links, and the sitemap

Redirects are only one migration signal. Conflicting signals can make Google keep testing old URLs or select an unexpected canonical.

On every indexable new page:

• Use a self-referencing canonical that contains the final new URL.
• Update navigation, breadcrumbs, related-post links, hreflang annotations, structured data, and image references.
• Remove old URLs from the new XML sitemap.
• Submit a sitemap containing only canonical, indexable URLs that return 200.
• Remove any migration-time noindex directive and confirm robots.txt does not block the new content.

A redirecting URL does not belong in the new sitemap. Linking internally through redirects also wastes crawl time and slows visitors. If you are diagnosing pages that return 200 but remain excluded, use our separate guide to fix “Crawled – currently not indexed” in Google Search Console.

5. Use Change of Address only for the right migration

If you moved from one domain or subdomain to another, verify both the old and new properties in Search Console and submit the Change of Address from the old property. Google says the tool is not needed for:

• HTTP-to-HTTPS migrations
• www-to-non-www changes on the same domain
• moving pages between paths on the same domain

The tool supports the redirect setup; it does not replace it. Old URLs must still forward to their corresponding new URLs.

Keep the old domain, certificates, DNS, and redirects working for as long as possible. Google recommends keeping redirects for at least one year so it can recrawl the old URLs and transfer signals. Keeping useful redirects indefinitely is often better for people following old bookmarks and backlinks.

6. Test before asking Google to validate

After deploying the fix, clear relevant CDN and application caches. Test a representative sample that includes:

• HTTP and HTTPS
• www and non-www
• URLs with and without trailing slashes
• Old high-traffic pages
• Deep paths, parameters, images, and PDFs
• Random nonexistent paths that should return 404

For each migrated page, the desired sequence is usually one permanent redirect followed by a 200 response on the final URL. The destination should be indexable, relevant, and declared canonical.

In Search Console, inspect the old URL and run Test live URL. The live test follows redirects and evaluates the final page, so also check the response chain independently. Inspect the destination URL separately to confirm that Google can index it.

Once the underlying rule is fixed across the site, return to the Redirect error report and click Validate fix. Google says validation commonly takes up to about two weeks, and sometimes longer. A live test can pass before the historical Page indexing report refreshes because the two views may reflect different crawl times.

Migration checks that prevent the error from returning

Do not combine several major changes at once

Changing the domain, CMS, site design, content, and URL structure simultaneously makes failures difficult to isolate. Google recommends changing one major element at a time where practical.

Preserve server capacity

During migration, Google must revisit old and new URLs. Keep both hosts responsive, watch 5xx errors, and avoid rate limits that block Googlebot. A technically correct redirect is not useful if the old server frequently times out.

Monitor both properties

Track crawling, indexed-page counts, sitemap processing, and search traffic for both domains. On a healthy move, activity gradually declines on the old site and rises on the new one. Temporary ranking fluctuations are normal while Google recrawls and reindexes the URLs; Google notes that small and medium migrations can take several weeks, while larger sites may take longer.

Do not use the Removals tool as a migration shortcut

Search Console’s temporary removal feature hides URLs; it does not forward visitors or consolidate migration signals. Use permanent redirects for moved content. Reserve removal requests for cases where a URL must be hidden urgently while you implement a lasting response such as authentication, noindex, 404, or 410.

Quick troubleshooting checklist

• Loop: Make hostname, HTTPS, locale, and slash rules converge in one direction.
• Long chain: Rewrite the original old URL directly to the final new URL.
• Bad destination: Repair variables, encoding, protocol, hostname, and query-string handling.
• Soft 404: Stop sending unrelated pages to the homepage; map them properly or return 404/410.
• Wrong canonical: Make the new page self-canonical and update all internal signals.
• Destination blocked: Remove unintended robots.txt blocks, noindex directives, authentication, and firewall restrictions.
• Validation fails: Export the new examples, find the shared rule, fix every instance, and restart validation.

Bottom line

A successful site migration creates one clear path from every valuable old URL to its matching new URL. Use a direct 301 or 308, remove loops and malformed destinations, align canonicals and internal links, submit the new sitemap, and keep the redirects live for at least a year. Search Console validation should come last—after the redirect behavior is correct for users and crawlers.

Once indexing stabilizes, review your broader search-quality risks too. For example, AllYourTech’s guide to Google’s site reputation abuse policy explains why technically indexable third-party sections can still create organic-search problems.