Search Console Says “Page with Redirect”—Is It a Problem or Expected?
Search Console’s “Page with redirect” label often triggers the wrong reaction. Site owners see a growing number of excluded URLs and assume Google has found a technical failure. In many cases, the report is simply describing a redirect that works exactly as intended.
The useful question is not “How do I remove every redirected URL from the report?” It is “Does this old URL reach the correct final page, and do the rest of my website signals point directly to that destination?” That distinction prevents unnecessary changes to healthy redirects while exposing the ones that waste crawls, confuse visitors, or send Google to the wrong content.
What “Page with redirect” actually means
Google defines this status as a non-canonical URL that redirects to another page. The source URL is therefore not indexed; the destination may or may not be indexed, depending on the target and Google’s evaluation of it. That is different from a “Redirect error,” which can indicate a loop, an excessively long chain, an invalid destination, or another broken path.
A redirected source URL does not need to rank. Its job is to transfer visitors and search engines to the preferred destination. If /old-service permanently redirects to /services/new-service, the new URL—not the old one—should be indexable, internally linked, canonical, and present in the sitemap.
When the status is normal
Leave a redirect alone when the source is obsolete, the destination is the closest true replacement, and the move is intentional. Common healthy cases include:
HTTP automatically redirecting to HTTPS;
the non-www hostname resolving to the preferred www version, or the reverse;
an old page slug redirecting after a careful URL change;
a discontinued service page redirecting to its direct successor;
duplicate trailing-slash or capitalization variants resolving to one preferred URL;
a migrated domain or redesigned page mapping to its equivalent new address.
Google’s current redirect guidance says permanent server-side redirects such as 301 and 308 are the clearest signal when a move will not be reversed. Temporary 302, 303, and 307 responses are more appropriate when the source URL is expected to return.
Do not remove a correct redirect merely to make an exclusion count smaller. Search Console explicitly warns that not every known URL should be indexed; the goal is to index the canonical version of each important page.
When “Page with redirect” reveals a real problem
The destination is irrelevant
A removed product redirected to the homepage does not satisfy the original intent. The same applies when every expired blog post, city page, or service is sent to a generic category. Map each source to a genuinely equivalent replacement. If no replacement exists, a real 404 or 410 is often more honest than an unrelated redirect.
This is closely related to Google’s soft-404 interpretation. If a redirect lands on a page that behaves like “not found,” use Webcurry’s soft 404 diagnostic before creating more redirect rules.
The redirect forms a chain
A common migration leaves a path such as old URL → first redesign URL → HTTPS variant → final URL. Browsers may still load the page, but each extra hop creates another failure point and obscures which address the site actually prefers. Update the first rule so the original source goes directly to the final 200 URL.
If rankings changed after a redesign, the website redesign recovery guide explains how to audit URL mapping, internal links, canonicals, and migration signals together.
The redirect loops
A loop occurs when URL A redirects to URL B and B sends the request back to A, or when several rules eventually return to the starting point. The browser may show “too many redirects,” while Search Console reports a redirect error rather than a routine redirected page. Conflicting HTTPS, www, language, cookie, CDN, and plugin rules are common causes.
Test in a private session and clear only the relevant cache after changing the rules. If different visitors still receive different routes, work through the browser, CDN, service-worker, and server cache diagnostic.
The redirect is temporary but the move is permanent
A temporary redirect is not automatically wrong, but it sends a different canonicalization signal from a permanent move. If the old URL is never coming back, use the platform’s permanent redirect option. If a maintenance page or short-lived campaign substitution will end, retain a temporary response.
The destination cannot be indexed
A perfect 301 does not make a blocked, noindexed, empty, or duplicate destination eligible for search. Inspect the final URL, not just the source. Confirm it returns 200, renders useful content to an anonymous visitor, is not blocked by robots directives, and declares a sensible canonical.
If Google chooses another canonical, use Webcurry’s canonical troubleshooting workflow. If the destination is crawlable but still excluded, continue with the crawled-but-not-indexed diagnostic.
Diagnose one URL from source to destination
Copy the exact source URL from Search Console, including protocol, hostname, path, parameters, and trailing slash.
Open it in a clean browser session and note the final address.
Check every response hop with browser developer tools, an HTTP header checker, or a command-line request that follows redirects.
Record the status of each hop. A clean permanent move normally needs one 301 or 308 followed by a 200 response.
Inspect the final URL in Search Console. The live inspection follows redirects, so verify that you are evaluating the final destination.
Compare canonical signals. The destination should normally self-canonicalize and should not redirect again.
Check discovery sources. Internal links, navigation, structured data, hreflang, and XML sitemaps should reference the final URL directly.
Do not request indexing for the old redirecting URL. Request it for the final URL only when that page should appear in search.
Fix the sources that keep feeding old URLs to Google
A redirect can remain in place for users and external links, but your own site should stop sending visitors through it. Search for the old address in:
menus, buttons, breadcrumbs, and footer links;
blog posts and product descriptions;
XML sitemaps and image sitemaps;
canonical and hreflang tags;
structured data;
email templates, downloadable files, and campaign landing pages;
CMS fields that store full URLs;
alternate-language or market selectors.
Point these sources directly to the final page. This does not guarantee indexing, but it removes conflicting signals and prevents every internal click from paying the cost of an avoidable redirect.
Platform-specific checks
Wix
Open the URL Redirect Manager and confirm the old path maps to the intended current path. Test the rule on the published domain. Watch for automatic redirects created after a slug change as well as manually added rules that duplicate or conflict with them.
Wix notes that a “Page with redirect” exclusion can be expected when an old URL correctly forwards to a new one. Keep the new URL in internal links and the sitemap. Use the Wix SEO checklist to review the destination’s indexability, canonical, metadata, and discoverability.
WordPress
Check redirect plugins, SEO plugins, caching layers, the web server configuration, and CDN rules. Two plugins can independently redirect the same path, or WordPress can normalize a URL after the server has already changed it. Export the redirect list, remove duplicates, and test while logged out.
After a migration, update database-stored internal URLs and clear server and CDN caches. Do not use a catch-all rule that sends every missing path to the homepage.
Shopify
Review URL redirects under Navigation and test old product, collection, blog, and page handles. Shopify prevents redirects from certain fixed platform paths, and redirects only work from broken URLs; an existing live path can take precedence. When importing redirects, confirm the “Redirect from” and “Redirect to” columns are mapped correctly.
For discontinued products, choose between a useful live product page, a one-to-one replacement redirect, or a true 404. Do not redirect an unavailable item to an unrelated collection simply to avoid a missing-page response.
A practical pass-or-fix decision
Leave it: the source is obsolete, the redirect is intentional and direct, and the final page is the right indexable destination.
Clean it up: the redirect works, but internal links, canonicals, hreflang, or the sitemap still reference the source.
Repair it: the path loops, chains through multiple hops, uses the wrong redirect type, lands on an irrelevant page, or ends at a blocked, noindexed, soft-404, or broken destination.
Remove it: the source has no meaningful replacement and a real 404 or 410 would describe the resource more accurately.
Verify the final state
Retest the source and final URL after publishing the change. The source should take the intended single path, and the destination should return 200 with complete public content. Confirm the final address is used in the sitemap and internal links, then inspect that destination in Search Console.
Search Console may continue showing historical examples until Google recrawls them. Validation is useful only after the underlying pattern has been corrected; it is not a substitute for correcting the route.
Make every URL tell one consistent story
“Page with redirect” is often an observation, not an emergency. A healthy source URL disappears from the index because the destination is the page that deserves to be indexed. Problems begin when the redirect path, destination content, canonical, sitemap, and internal links disagree.
Trace one example end to end, fix the rule or the signals behind the whole pattern, and leave correct redirects in place for old links and visitors. If the route still behaves differently across devices, locations, or crawlers, ask Webcurry for a focused technical SEO review of the affected URLs.
Comments