Search Console: fix the Page with redirect indexing issue

When Google Search Console reports "Page with redirect" for URLs on your site, it indicates that Googlebot encountered an HTTP 3xx status code when…

When Google Search Console reports "Page with redirect" for URLs on your site, it indicates that Googlebot encountered an HTTP 3xx status code when attempting to crawl the URL. Instead of indexing the originally requested URL, it followed the redirect and potentially indexed the destination URL. While often benign, this status can mask deeper architectural issues, lead to inefficient crawling, or even indicate canonicalization problems that dilute link equity and search visibility. Understanding and rectifying the underlying causes is crucial for optimal SEO performance and crawl budget utilization.

Understanding "Page with Redirect" in Google Search Console

Google Search Console categorizes URLs under "Page with redirect" when Googlebot receives an HTTP status code in the 300 range (301, 302, 303, 307, 308) for a URL it tried to access. This means the server instructed Googlebot to go to a different URL. Googlebot typically follows these redirects and, if the destination URL returns a 200 OK status, it may index the destination instead of the original URL.

Common scenarios leading to this status include:

HTTP to HTTPS redirection: A site transitions from HTTP to HTTPS, and all HTTP requests are redirected to their HTTPS counterparts.
Non-www to www (or vice-versa) redirection: A site enforces a preferred domain (e.g., all example.com requests redirect to www.example.com).
Trailing slash enforcement: A site consistently redirects URLs with/without trailing slashes (e.g., example.com/page redirects to example.com/page/).
Moved content: A page's URL has changed, and a 301 (Permanent Redirect) is in place to direct users and search engines to the new location.
Temporary redirects: Less common for this report, but 302/307 redirects for maintenance or A/B testing can also trigger this.
Internal linking issues: Your own site's internal links point to an outdated or non-canonical version of a URL that then redirects.

While often intended behavior, particularly for HTTP to HTTPS or www/non-www consolidations, it's essential to ensure these redirects are efficient and don't obscure canonicalization problems or unnecessary redirect chains. Google's goal is to index the "final, canonical URL" that serves the content.

Diagnosing Redirect Issues

The first step is to identify the specific URLs reported in Search Console. Use the URL Inspection tool for individual URLs to see Google's perspective. It will show the "Crawled page" status, the canonical URL chosen by Google, and often the redirect chain if one exists.

Inspecting a URL with the URL Inspection Tool

In Search Console, navigate to "URL Inspection", enter a problematic URL (e.g., http://www.example.com/old-page). The tool will report something like:

Crawl: Page with redirect
User-declared canonical: N/A or a different URL
Google-selected canonical: https://www.example.com/new-page/

This tells you that Google followed a redirect to reach https://www.example.com/new-page/. You should then inspect https://www.example.com/new-page/ to confirm it is indeed the intended canonical version.

Using HTTP Header Checkers

To understand the redirect chain for a URL, use browser developer tools (Network tab) or online HTTP header checker tools (e.g., redirect-checker.org, httpstatus.io). For instance, checking http://example.com might reveal:


GET http://example.com
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

GET https://example.com/
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

GET https://www.example.com/
HTTP/1.1 200 OK
Content-Type: text/html

This shows a double redirect: HTTP to HTTPS, then non-www to www. While functional, it's less efficient than a single redirect.

Best Practices for Redirects and Canonicalization

Addressing "Page with redirect" involves ensuring that redirects are correctly configured and that internal linking, sitemaps, and canonical tags align with your preferred canonical URLs.

1. Consolidate to a Single Canonical URL

Every piece of content should ideally have one, and only one, canonical URL. This means deciding on:

HTTPS vs. HTTP: Always use HTTPS. Redirect all HTTP traffic to HTTPS.
WWW vs. non-WWW: Choose one (e.g., www.example.com) and consistently redirect the other.
Trailing Slashes: Decide whether URLs should end with a trailing slash (e.g., /page/) or not (e.g., /page) for directory-like URLs, and enforce it with redirects.
Index pages: Redirect /index.html or /default.aspx to the root / or its parent directory.

Example Apache .htaccess for consolidation:


# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force www (assuming HTTPS is already forced or handled)
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force trailing slash (or remove, depending on preference)
# To add trailing slash for directories (e.g., /page -> /page/)
# RewriteCond %{REQUEST_FILENAME} !-f
# RewriteCond %{REQUEST_URI} !(.*)/$
# RewriteRule ^(.*)$ $1/ [L,R=301]

# To remove trailing slash (e.g., /page/ -> /page)
# RewriteCond %{REQUEST_FILENAME} !-d
# # Only apply if not already root or file
# RewriteRule ^(.*)/$ $1 [L,R=301]

For Nginx, similar rules would be configured in the server block. Ensure your configuration uses return 301 for permanent changes.

2. Update Internal Links to Final URLs

This is a critical, yet often overlooked, step. If your internal links (e.g., in navigation, sidebar, content) point to URLs that redirect, Googlebot wastes crawl budget following these redirects. More importantly, it signals mixed messages about the canonical URL. Perform an internal link audit using a crawler like Screaming Frog SEO Spider or Sitebulb to identify and update all internal links to their final, 200-OK, canonical versions.

For example, if you moved from HTTP to HTTPS, ensure all internal links are https://.... If you consolidated to www.example.com, ensure internal links use www.

3. Correct Your Sitemaps

Your XML sitemaps should only contain canonical URLs that return a 200 OK status. If your sitemap lists URLs that redirect, Googlebot will fetch them, encounter the redirect, and then fetch the destination URL. This is inefficient. Regenerate your sitemaps to include only the final, preferred URLs.

4. Use 301 (Permanent) for Moved Content

For pages that have permanently moved, always use a 301 HTTP status code. This signals to search engines that the move is permanent and helps transfer link equity (PageRank) to the new URL. Avoid 302 (Found) for permanent moves, as it implies a temporary change and may not pass link equity effectively. The "Page with redirect" report in Search Console primarily focuses on 3xx redirects regardless of their type, but using the correct type is vital for SEO.

5. Implement `rel="canonical"` Tags Correctly

While redirects tell search engines where to find the content, the <link rel="canonical" href="..."> tag tells search engines which URL is the preferred, authoritative version of a page (especially useful for pages with identical or very similar content accessible via multiple URLs, like filter pages in e-commerce). Ensure that the URL specified in your canonical tag is the final, 200-OK URL you want indexed, and not one that itself redirects.


<!DOCTYPE html>
<html lang="en">
<head>
    ...
    <link rel="canonical" href="https://www.example.com/products/widgets/" />
    ...
</head>
<body>
    ...
</body>
</html>

Crucial interaction: If Googlebot requests http://example.com/page, it redirects to https://www.example.com/page/. The page at https://www.example.com/page/ should then have a rel="canonical" tag pointing to itself (https://www.example.com/page/). It should *not* point back to http://example.com/page or any other non-canonical version.

Re-indexing and Monitoring

Once you've implemented the fixes, you can expedite Google's re-crawling:

Validate Fix in Search Console: For URLs reported under "Page with redirect," click on the URL, then "Validate Fix." This prompts Google to re-crawl the affected URLs and verify the changes.
Request Indexing: For critical pages, use the URL Inspection tool, enter the *final, canonical URL*, and click "Request Indexing." This directly asks Google to crawl and consider the updated page. Do not request indexing for a URL that still redirects.
Submit Updated Sitemaps: If you've made extensive changes, resubmit your XML sitemaps in Search Console.
Monitor Search Console: Regularly check the "Pages" report and specifically the "Page with redirect" section to ensure the number of affected URLs decreases over time. Also, monitor the "Valid" section for an increase in indexed pages.

Common Pitfalls

Redirect Chains: Multiple redirects (e.g., A -> B -> C) significantly slow down page load times and waste crawl budget. Aim for direct redirects (A -> C). Tools like Ahrefs, SEMrush, or Screaming Frog can detect these.
Redirecting to 404s: Ensure that your redirects don't lead to pages that return a 404 "Not Found" status. This is a severe error, breaking the user experience and causing search engines to de-index content.
Incorrect Canonical Tags: Placing a rel="canonical" tag on a page that redirects, or having a canonical tag pointing to a URL that itself redirects or returns a 404.
Internal Links Pointing to Redirects: As mentioned, constantly review and update internal linking. It's often the most common source of persistent "Page with redirect" issues.
Using JavaScript Redirects: Client-side JavaScript redirects (e.g., window.location.replace()) are harder for search engines to process reliably compared to server-side HTTP 3xx redirects. Avoid them for canonicalization purposes.
Ignoring non-HTML Redirects: Images, CSS, and JavaScript files can also redirect. While not directly affecting "Page with redirect" for HTML pages, inefficient redirects for resources can slow down page rendering.