Page with Redirect and Redirect Error: What They Mean and How to Fix Them

Two statuses, two meanings

Page with redirect

Google crawled the URL, received a redirect and did not index this address, because the content lives at the destination. That is how redirects are meant to work. After a migration, a change of domain or a move to https, you should expect a large number of URLs here, and the count fades slowly as Google stops revisiting them.

Redirect error

Google's documentation lists four causes: 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 redirect chain. Googlebot follows up to ten redirect hops; if it has not reached content by then, the URL is reported as an error. In practice most errors are loops, often between http and https or between www and non-www, and a browser shows them as ERR_TOO_MANY_REDIRECTS.

For other reasons in the same report, see Search Console errors explained.

When page with redirect does need attention

Page with redirect is a report, not an error, but a few situations deserve a closer look:

• A page you want indexed is listed. If your live service page appears here, it is redirecting when it should not. Check the trailing slash, the host and any plugin redirect rules.
• The count keeps rising long after a migration. Something on your site is still linking to old URLs: the menu, footer, in-content links, canonical tags, hreflang or the sitemap.
• The sitemap lists redirecting URLs. Search Console shows sitemap filters in the report. A sitemap should list only final addresses that return 200.
• Redirects go to the wrong place. Many old URLs pointing to the home page are often treated as soft 404s, and Google drops them anyway.

Crawl your site with our redirect checker or any crawler and list internal links that hit a redirect. Replace each one with the final URL. Visitors arrive faster and Google stops rediscovering the old addresses. The migration redirects guide covers mapping old URLs to new ones after a site move.

How to trace a redirect chain

Use curl rather than a browser. Browsers cache 301 redirects, so after you fix a rule your own browser can keep showing the old behaviour. This command prints the status line and destination of every hop:

curl -sIL http://example.com/old-page | grep -iE '^(HTTP|location)'

A healthy result has one redirect and then a 200:

HTTP/1.1 301 Moved Permanently
location: https://www.example.com/new-page/
HTTP/2 200

A chain looks like this, with four hops before the page is reached:

HTTP/1.1 301 Moved Permanently
location: https://example.com/old-page
HTTP/2 301
location: https://www.example.com/old-page
HTTP/2 301
location: https://www.example.com/old-page/
HTTP/2 301
location: https://www.example.com/new-page/
HTTP/2 200

To count the hops and see the final address in one line:

curl -sL -o /dev/null -w '%{num_redirects} hops, final %{http_code} %{url_effective}\n' http://example.com/old-page

A loop makes curl stop with an error such as Maximum (30) redirects followed. Add --max-redirs 10 to match Googlebot's limit. In the output, look for the same two URLs alternating; that pair shows you which two rules disagree.

Remember that redirects can also be made with a meta refresh or JavaScript. If curl shows a 200 but the browser moves to another page, view the source and search for http-equiv="refresh" or window.location. Server-side 301s are clearer for Google and should be used wherever you can.

Common causes of redirect errors

Each of these has a dedicated guide: redirect loops, redirect chains and https redirects.

One-hop rules by platform

The goal is that any old variant reaches the final https address in a single 301.

nginx

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

Put page-level moves in the main server block as location = /old-page { return 301 https://www.example.com/new-page/; }, then run sudo nginx -t and reload.

Apache and .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

Redirect 301 /old-page https://www.example.com/new-page/

Place host and protocol rules before other rewrites, and list specific page redirects with the final address, not an intermediate one. More detail is in the Apache redirects guide.

WordPress

Under Settings, then General, both the WordPress Address and Site Address must use the same https host as your server rules. If you use a redirect plugin, keep page moves there and host rules on the server, not both.

Cloudflare and Plesk

In Cloudflare, use SSL mode Full (strict) and check Redirect Rules and Page Rules for duplicates of server rules. In Plesk, the hosting settings include a preferred domain option and a permanent https redirect; if you use those, remove matching rules from .htaccess. The Cloudflare redirects guide and Plesk redirects guide go into each panel.

A worked example

A consultancy moved to https, then to www, then renamed a section. Search Console shows 31 redirect errors and 400 pages with redirect. Running curl on one error URL shows it bouncing between https://example.com/insights/ and https://www.example.com/insights/: an .htaccess rule sends non-www to www, while a Cloudflare Redirect Rule left from an earlier test sends www back to non-www.

The Cloudflare rule is deleted. Next, an older URL is traced: http://example.com/blog/pricing goes to https, then to www, then adds a slash, then moves to /insights/pricing/, which is four hops. The page redirect is rewritten to send /blog/pricing straight to https://www.example.com/insights/pricing/, and the host and protocol rules are merged into one. Every old URL now resolves in one hop.

The menu still linked to /blog/ addresses, so those links are updated, and the sitemap is regenerated with final URLs only. Validate fix is started on the Redirect error issue, which passes within three weeks, and the page with redirect count begins to fall.

The fix, step by step

Edge cases worth knowing

• 301 or 302. Google follows both. A 302 suggests the move is temporary, so Google may keep the old URL as canonical for longer. Use 301 or 308 for permanent moves; see 302 vs 301.
• Loops only for bots. Some firewalls redirect suspected bots to a challenge page that redirects again. Test with a Googlebot user agent and check your server logs.
• Geo and language redirects that send visitors by IP address can trap Googlebot, which mostly crawls from the United States. Offer a choice instead of forcing a redirect.
• Redirects to removed pages. If the destination returns 404, the URL moves to Not found instead.

Keeping it fixed

Keep a single list of redirects in one place, and when you add a new one, check whether any existing rule points at the URL you are moving. If it does, update that rule to the new final address so chains never form. After any change to SSL, CDN, host or plugin settings, run the curl check on the home page with both http and https and with and without www. Crawl the site monthly for internal links that hit a redirect, and keep the sitemap generated from live, final URLs only.