You open the Page indexing report, filter by your sitemap, and find a batch of URLs under Redirect error. Every one of them loads fine when you click it. That gap between “works for me” and “fails for Google” is the whole problem, and it is why so many fixes for this error miss the mark.
A redirect error means Googlebot started following a redirect and could not reach a final page. It is not the same as a page that redirects successfully. This guide covers how to tell the two apart, how to trace redirects the way Googlebot sees them, and the fixes for each pattern, including the sitemap settings that usually cause the problem in the first place.
- Redirect Error vs Page With Redirect: Which One Do You Have?
- Step 1: Confirm the Error Against Your Sitemap
- Step 2: Trace the Redirects the Way Googlebot Sees Them
- Step 3: Match the Pattern to the Cause
- Step 4: Fix the Redirect Rules
- Step 5: Clean Up the Sitemap Itself
- Step 6: Validate the Fix and Watch the Report
- FAQs
Redirect Error vs Page With Redirect: Which One Do You Have?
Search Console shows two redirect statuses in the Page indexing report, plus a third problem that lives in the Sitemaps report. They need very different fixes.
Table 1: The Three Redirect Problems Tied to Sitemaps
| Status | Where You See It | What It Means | Severity |
| Redirect error | Page indexing report | Googlebot followed a redirect and never reached a final page | High: neither the URL nor its target gets indexed through this path |
| Page with redirect | Page indexing report | The URL redirects successfully to another page | Low: expected for old URLs, but a sitemap should not list them |
| Sitemap file redirects | Sitemaps report | The sitemap URL you submitted redirects to another sitemap URL | Medium: submit the final sitemap URL instead |
Google lists four causes for a redirect error: a redirect chain that was too long, a redirect loop, a redirect URL that eventually exceeded the maximum URL length, and a bad or empty URL in the chain. Google’s crawlers follow up to 10 redirect hops by default, so a chain of 11 fails even if every single hop is valid.
The four redirect patterns behind a Search Console redirect error
Step 1: Confirm the Error Against Your Sitemap
- In Search Console, open Indexing > Pages.
- Use the dropdown at the top to switch from All known pages to All submitted pages, or pick a single sitemap.
- Click Redirect error under Why pages aren’t indexed and export the example URLs.
- Run one URL through URL Inspection and click Test live URL. If the live test passes, the issue may be intermittent or already fixed; click Validate fix after you confirm.
Look at the exported list for a pattern before testing anything else. If every URL is http://, or every URL lacks a trailing slash, or every URL sits under one folder, you have already found the rule that is breaking.
Step 2: Trace the Redirects the Way Googlebot Sees Them
A browser hides the problem. It keeps cookies, remembers HTTPS from earlier visits (HSTS), sends your language and often caches old redirects. Googlebot does none of that: every request comes in fresh, with no cookies and from Google’s own IP addresses. To see what Google sees, trace each hop with curl, with no cookies and a Googlebot user agent:
curl -sI -L –max-redirs 15 \
-A “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” \
http://example.com/page | grep -iE “^HTTP|^location”
Each HTTP line is a hop and each location line shows where it points. A healthy result has at most one or two redirects ending in 200. To check every URL in a sitemap at once, this Python script reports any URL that redirects, loops or exceeds the hop limit:
import requests, xml.etree.ElementTree as ET
from urllib.parse import urljoin
SITEMAP = “https://example.com/sitemap.xml”
UA = {“User-Agent”: “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”}
NS = {“s”: “http://www.sitemaps.org/schemas/sitemap/0.9”}
def urls_from(sitemap):
root = ET.fromstring(requests.get(sitemap, headers=UA, timeout=20).content)
if root.tag.endswith(“sitemapindex”):
for loc in root.findall(“s:sitemap/s:loc”, NS):
yield from urls_from(loc.text.strip())
else:
for loc in root.findall(“s:url/s:loc”, NS):
yield loc.text.strip()
def trace(url, limit=10):
hops, seen = [], set()
while len(hops) <= limit:
r = requests.get(url, headers=UA, allow_redirects=False, timeout=20)
hops.append((r.status_code, url))
if r.status_code not in (301, 302, 303, 307, 308):
return hops, “ok” if len(hops) == 1 else “redirects”
loc = r.headers.get(“Location”, “”).strip()
if not loc:
return hops, “EMPTY LOCATION”
url = urljoin(url, loc)
if url in seen:
return hops, “LOOP”
seen.add(url)
return hops, “TOO MANY HOPS”
for u in urls_from(SITEMAP):
hops, verdict = trace(u)
if verdict != “ok”:
print(verdict, len(hops) – 1, “hops:”, ” -> “.join(h[1] for h in hops))
Each request starts without cookies, so the script catches cookie-based loops a browser would hide. Anything it flags as redirects should not be in your sitemap at all, and anything flagged LOOP, EMPTY LOCATION or TOO MANY HOPS is a redirect error waiting to happen.
Step 3: Match the Pattern to the Cause
Table 2: What the Trace Shows and What Causes It
| Trace Pattern | Likely Cause | Where to Fix It |
| http to https to http, repeating | CDN set to Flexible SSL while the server forces HTTPS | CDN SSL mode (use Full or Full Strict) |
| www to non-www to www | CMS site address and server or host rule disagree | WordPress Settings > General, plus .htaccess, Nginx or host panel |
| /page to /page/ to /page | Plugin adds a trailing slash, server rule removes it | Permalink settings and server rewrite rules |
| Five or more hops before a 200 | Redirects stacked from several migrations | Redirect map: point every old URL straight at the final URL |
| URL grows longer each hop | Rule appends a parameter or path segment every time | The rewrite rule’s pattern and flags |
| 301 with no Location header | Broken plugin rule or empty target | Redirect plugin or server config |
| Loops only without cookies | Consent, session or A/B test redirect that sets a cookie | Exclude bots or set the default without a redirect |
| Redirects to a country or language page | Geo or Accept-Language redirect | Serve a default page and use hreflang instead |
| Redirects to a login or challenge page | Firewall or bot protection treating Googlebot as a threat | WAF allowlist for verified Googlebot |
Step 4: Fix the Redirect Rules
Collapse Everything Into One Hop
The cleanest setup sends any variant of a URL (http, non-www, missing slash) to the final canonical version in a single hop. On Apache, one combined rule handles protocol and host together:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
On Nginx, give the non-canonical hosts their own server block that returns one 301:
server {
listen 80;
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
Behind Cloudflare or another proxy, the server may only ever see HTTP from the CDN, so a rule like %{HTTPS} off fires on every request and creates a loop. Either set the CDN’s SSL mode to Full (strict) so it connects to your server over HTTPS, or check the X-Forwarded-Proto header instead.
Flatten Old Redirect Chains
After two or three migrations, a single old URL can bounce through a long trail of redirects. Export your redirect list, follow each chain to its end, and rewrite every entry to point directly at the final URL. Keep the old redirects, just shorten them. This is also the moment to remove redirects that point to pages which now 404.
Stop Redirecting Googlebot Based on Cookies, Location or Language
Googlebot crawls mostly from US IP addresses and never stores cookies. A redirect that depends on either will treat it differently from your visitors. Serve a usable default page with a 200 status, offer country or language choices as links, and use hreflang to point Google at alternate versions. For cookie consent and A/B tests, set defaults in the page rather than with a redirect.
Step 5: Clean Up the Sitemap Itself
Most sitemap-related redirect errors start with the sitemap listing the wrong version of each URL. Google’s sitemap guidelines say to list the fully qualified, canonical URLs you want in search results, so every URL in a sitemap should return 200 directly, with no redirect at all.
Table 3: Sitemap Fixes by Platform
| Platform | Common Cause | Fix |
| WordPress (Yoast, Rank Math, core sitemaps) | WordPress Address and Site Address still set to http or the wrong host | Update both in Settings > General, then clear caches and regenerate the sitemap |
| Shopify | Old domain or myshopify.com URLs in a custom or app sitemap | Set the primary domain and use the built-in /sitemap.xml |
| Custom or headless sites | Sitemap builder uses a base URL from an environment variable | Set the production base URL and match the canonical host exactly |
| Any site after a migration | Old sitemap still submitted in Search Console | Remove the old sitemap and submit the new one |
Then check the sitemap file itself. If you submitted /sitemap.xml and it redirects to /sitemap_index.xml or to another host, submit the final address in the Sitemaps report and remove the old entry. Update the Sitemap: line in robots.txt to the same final address.
Do Not Add Redirected URLs “Just in Case”
Some site owners list old URLs in the sitemap so Google will find their redirects. Google discovers redirects through links and its own crawl history, so this only fills the report with Page with redirect entries and dilutes the signal your sitemap sends about which pages matter.
Step 6: Validate the Fix and Watch the Report
- Rerun the Python script and confirm every sitemap URL returns 200 with no hops.
- Test a few affected URLs with URL Inspection > Test live URL.
- Resubmit the sitemap in Indexing > Sitemaps.
- Open the Redirect error issue and click Validate fix. Validation usually takes days to a few weeks, depending on how often Google crawls the site.
Redirect errors waste crawl requests, so fixing them also helps Google reach new pages faster. Our guide to getting Google to index a site faster covers the next steps, and the broader guide to fixing Google indexing issues handles the other statuses you may find in the same report. If loops keep coming back after server changes, it may be time to look at SEO-friendly hosting with cleaner redirect and SSL handling, and to add redirect checks to your regular technical SEO audits.
FAQs
What Does Redirect Error Mean in Google Search Console?
It means Googlebot followed a redirect from the URL but could not reach a final page, because of a loop, a chain longer than 10 hops, a URL that grew too long, or a broken or empty redirect target.
Why Does the Page Work in My Browser but Show a Redirect Error?
Your browser stores cookies, remembers HTTPS and sends your location and language. Googlebot sends none of these, so a redirect that depends on them can loop or fail only for Google.
Is Page With Redirect an Error?
No. Page with redirect means the URL redirects successfully and Google indexes the target instead. It only needs fixing when those URLs are listed in your sitemap or linked internally.
Should Redirected URLs Be in My Sitemap?
No. A sitemap should contain only canonical URLs that return a 200 status. Replace redirected URLs with their final destinations.
How Long Does Validation Take After Fixing Redirect Errors?
Usually from a few days to a few weeks. Google recrawls the affected URLs on its own schedule, and large sites take longer.
