"Page with redirect" in Search Console: when it's fine, and when it isn't

If you've opened Search Console's Page indexing report and found URLs listed under "Page with redirect", the first thing to know is that this usually isn't an error. Google found a URL, followed its redirect, and indexed the destination instead. Nine times out of ten, that's exactly what you wanted.

The tenth time, it's a sign that something on your site is pointing at the wrong address. This post covers how to tell which case you're in, how to check it in about five minutes, and why clicking "Validate fix" on this report almost always ends in "Failed" even when nothing is wrong.

What "Page with redirect" actually means

The Page indexing report has two halves: pages that are indexed, and a list headed "Why pages aren't indexed". "Page with redirect" lives in the second list, which makes it look like a problem. It isn't a problem category, though. It's an explanation.

A URL that redirects can't be indexed itself, because there's no content at that address. There's only an instruction to go somewhere else. So Google records the URL, notes the redirect, and moves on to index the target. The report is simply telling you which URLs it saw that fall into that bucket.

On this site the list has exactly three entries:

Those are the three variants of the homepage that aren't the canonical one. Every site with HTTPS and a single preferred host (apex or www, not both) will have entries like these. If they weren't redirecting, you'd have four copies of your homepage competing with each other, which is the actual problem the redirects exist to prevent.

Why "Validate fix" always fails

Search Console offers a Validate fix button on this report, and it's tempting to click it. Here's what happens next: Google re-crawls the listed URLs to check whether they still redirect. They do, because they're supposed to. Validation ends with "Failed".

That "Failed" means "these URLs are still redirecting." It doesn't mean your site is broken. For host variants like the three above, validation will fail forever, and that's the correct outcome. The only way to make it pass would be to remove the redirects, which would make your SEO worse.

When it's fine

You can stop worrying about an entry in this report if all of these are true:

1. You meant the URL to redirect. Host variants, an old slug you renamed, a page you merged into another one, a trailing-slash variant your framework normalises.
2. The redirect is permanent. A 301 or 308, not a 302 or 307. Google can treat long-lived temporary redirects as permanent eventually, but a permanent status says what you mean.
3. It ends in one hop at a 200. Not a chain of three redirects, and not a redirect that lands on a 404.
4. The destination is actually indexed. This is the step people skip, and it's the one that matters.

When it's a real problem

The report is worth a closer look when the listed URLs include something you didn't expect. The common causes:

• A page you want indexed is redirecting. A misconfigured rule, such as a catch-all redirect added during a migration, can sweep up live pages. If you see a real article or product page in the list and you didn't move it, that's a bug.
• Your sitemap lists redirecting URLs. A sitemap should contain only final, canonical URLs that return 200. If it lists http:// addresses, www addresses when you've settled on the apex, or old slugs, Google keeps finding redirects you're actively advertising.
• Your internal links point at redirecting URLs. Every internal link to an old address costs a hop and keeps the old URL alive in Google's view. Update the links to the destination.
• Your canonical tag points at a URL that redirects. A <link rel="canonical"> should name the final address. A canonical that redirects is a contradictory signal: "index this one", followed by "actually, go over there".
• Redirect chains. http://www → https://www → https:// is two hops where one would do. Google follows chains, but each hop is a chance for something to go wrong, and it slows down real visitors too.

If none of those apply, you're in the "fine" case.

How to check it in five minutes

1. Trace each redirect with curl

For every URL in the report, follow the redirect chain and print each status code:

curl -sIL http://www.example.com/ | grep -iE "^(HTTP|location)"

On this site, the https://www variant produces:

HTTP/1.1 301 Moved Permanently
Location: https://anuphaldar.com/
HTTP/1.1 200 OK

That's the ideal shape: one permanent redirect, then a 200 at the canonical URL. If you see more than one Location line, you have a chain. If the last status isn't 200, the redirect lands somewhere broken.

For honesty's sake, here's the http://www variant on the same site:

HTTP/1.0 308 Permanent Redirect
Location: https://www.anuphaldar.com/
HTTP/1.0 301 Moved Permanently
Location: https://anuphaldar.com/
HTTP/1.0 200 OK

That's a two-hop chain: the host upgrades to HTTPS first, then sends www to the apex. Both hops are permanent and it ends at a 200, and it only affects a variant almost nobody types, so I've left it alone. On a URL that real links point at, I'd collapse it into a single hop.

2. Inspect the destination, not the source

Paste the destination URL into the URL Inspection bar at the top of Search Console. You want to see "URL is on Google". If the destination is indexed, the redirect has done its job and the source URL appearing in "Page with redirect" is just bookkeeping.

If the destination isn't indexed, that's the real issue to chase, and the redirect report was only a symptom of it.

3. Check your sitemap for redirecting URLs

Open your sitemap.xml and make sure every <loc> is a final URL: the right protocol, the right host, the current slug. If your sitemap is generated (a sitemap.ts in Next.js, a plugin elsewhere), check that it builds URLs from the same canonical origin your site uses rather than from the request host.

4. Search your codebase for old addresses

Look for hard-coded links to the non-canonical host or to old slugs:

grep -rn "www\.example\.com\|http://example\.com" src/

Anything that turns up should point at the canonical URL directly.

A note on which redirect actually runs

One thing I learned checking this on my own site: the www redirect I'd written in Next.js middleware never runs in production. Vercel's domain settings redirect www to the apex before the request reaches the app, so the live response is Vercel's 301, not my 308. The same goes for the HTTPS upgrade in the chain above, which comes from the host, not from any code in the repo. Both are permanent, so it makes no difference to Google, but it's a good reminder to check the real response with curl rather than assume your code produced it. Hosting platforms, CDNs and DNS providers can all add redirects of their own.

I wrote about the rest of this site's setup, including the middleware and the sitemap, in the SEO plumbing behind this blog.

Frequently asked questions