Page With Redirect: What It Means + How to Fix It

This is one of the least alarming statuses in the whole Page Indexing report, and it gets flagged as a "problem" more often than it should. It simply means: this URL redirects somewhere else, Google followed it, and it's indexing the destination instead of this address. That's not a failure — that's a redirect doing its job.

The only real work here is confirming the redirect is going where you intended. If it is, there's nothing to fix.

What's actually happening

When Googlebot requests a URL and gets a 301 or 302 response, it doesn't index that URL's content — there isn't any to index, it's just a routing instruction. Google follows the redirect, evaluates and indexes the destination URL on its own terms, and logs the original URL's status as "Page with redirect" to explain why it's excluded from the index under its own address. This is universal, expected behavior for every properly functioning redirect on the internet — old product pages after a re-platform, http to https upgrades, www to non-www normalization, retired blog posts pointing at their replacement.

Confirm it's actually fine

Open Pages → Why pages aren't indexed, click into "Page with redirect," and pull a sample of affected URLs. For each one worth checking, run URL Inspection — it shows the redirect target Google followed.

Ask two questions about each redirect:

Does the destination match what you intended? If you redirected an old product page to its replacement, or http:// to https://, and that's exactly where GSC shows it landing — this is working correctly. Nothing to do.

Is the redirect type correct for the situation? A permanent move (old page gone for good) should be a 301. A temporary redirect (302 or 307) tells Google the change isn't permanent, so it may keep the original URL around longer and revisit it — which is correct if the situation really is temporary, but a common mistake if someone used 302 out of habit for what's actually a permanent change.

If both check out, you're done — this status doesn't need a "fix" the way an error status does.

When it's actually a problem

A small number of cases genuinely need attention:

The redirect target is wrong

The URL redirects, but not to the page you'd expect — a stale rule left over from an old migration, or a bulk redirect rule that's too broad and catches URLs it shouldn't.

Fix: correct the redirect rule to point at the right destination. Check your redirect source (CMS plugin, .htaccess, next.config.js redirects, hosting-level rules — see platform notes below) for the specific rule and update it.

The redirect is unintentional

Sometimes a URL redirects that shouldn't redirect at all — a page that should be live and indexable on its own got accidentally swept into a broad redirect rule (a wildcard pattern, a "redirect everything under this old path" rule that's too greedy).

Fix: narrow the redirect rule so it only matches the URLs that genuinely need to redirect, and let the rest resolve normally.

A temporary redirect has become permanent in practice

If a 302/307 has been in place for months with no plan to reverse it, it's functioning as a permanent redirect but signaling "temporary" to Google — which can leave ranking signal split between the two URLs longer than necessary.

Fix: change the status code to 301 once you're certain the change is permanent.

The old URL is still in your sitemap

Sitemaps should only list live, final destination URLs — not URLs that just redirect. A redirected URL in your sitemap is a minor, low-priority signal conflict.

Fix: remove the redirecting URL from your sitemap and confirm the destination URL is listed instead.

Platform notes

• WordPress — check redirect plugins (Redirection, Yoast, Rank Math) for the rule table, and cross-check .htaccess if the site has legacy server-level redirects too — the two can overlap or be set by different people at different times.
• Shopify — auto-managed redirects (from renaming a product/collection handle) live under Settings → Apps and sales channels → URL Redirects. Bulk theme migrations sometimes leave broad redirect rules behind; review the list periodically rather than assuming it's all still relevant.
• Next.js (React) — check the redirects() array in next.config.js and any middleware-based redirect logic. A wildcard source pattern (/blog/:path*) is the usual cause of an over-broad rule catching URLs it shouldn't.
• Webflow — 301 redirects are managed under Project Settings → SEO → 301 Redirects; there's no built-in support for temporary (302) redirects in the standard UI, so if you need one, it typically comes from a third-party integration — check there first if a redirect type looks unexpected.

How to verify it's fixed

If you changed a redirect target or rule:

1. curl -IL or a redirect checker — confirm the URL now redirects to the correct destination with the right status code (301 for permanent).
2. URL Inspection — re-inspect the source URL to see Google's own read of the redirect target.
3. Performance report — check the destination URL for impressions once Google has re-crawled; this confirms the redirect is passing traffic-relevant signal correctly, not just resolving technically.

Re-crawling and reprocessing isn't instant — expect days to weeks before GSC's report reflects a changed redirect target, and Google doesn't guarantee an exact timeline.

When to ignore it

Nearly always. If the redirect target is correct and intentional — which is true for the overwhelming majority of URLs under this status — there is nothing to fix. Don't spend time "resolving" a status that represents a redirect working exactly as designed.