How to Handle ‘Page with Redirect’ in Google Search Console

“Page with redirect” usually means Google found a URL that forwards to another address and excluded that source URL from indexing. Start by checking where it goes and whether that is the page you want visitors to reach.

An old article forwarding to its replacement can be working correctly. A current product page forwarding to your homepage may need attention. The same report label can appear in both situations.

The useful question is whether the redirect matches your intention and leads to the right content. You can answer that by recording the source, each redirect hop, and the final destination before changing anything.

What the ‘Page with redirect’ status means

In Google Search Console, open Indexing > Pages, find Page with redirect, and select an example URL. Make sure you have selected the property that covers the address you are investigating.

Google's Page indexing documentation^[1]Source 1Page indexing documentationView source ↗ defines this state as a noncanonical URL that redirects to another page. The source is not indexed in this state. The destination might be indexed, but the redirect alone does not establish that.

For example, suppose http://example.com/guide forwards to https://example.com/guide/. The first address is the source; the HTTPS address with the final slash is the destination. If that normalization is intentional, the excluded source may be exactly what you expect.

Keep Redirect error separate. That label indicates a problem following the redirect, such as a loop, an overly long chain, a bad destination URL, or an empty redirect location. “Page with redirect” does not by itself establish any of those faults.

The report also describes Google's recorded processing, rather than an immediate view of your server configuration. Check the inspection dates before comparing it with a change made today.

Decide whether the redirect needs a fix

Start with one URL you recognize. Write down whether it should remain a standalone page, permanently move, or temporarily send visitors elsewhere. That intended outcome controls the repair.

What you find	Likely decision	What to verify
HTTP forwards to the matching HTTPS page	Keep the redirect	Correct host, path, content and final response
An old URL forwards to its relevant replacement	Keep the redirect	Replacement is accessible and suitable for indexing
A valuable current page forwards accidentally	Repair the responsible rule	Original page returns its intended content again
A redirect lands on an unrelated homepage	Review the mapping	A genuinely equivalent replacement exists
A chain reaches the right page through several steps	Simplify where practical	Source points directly to the final destination
A loop never reaches content	Fix the conflicting rules	Repeated trace terminates successfully
The source redirects correctly but the target is excluded	Investigate the target	Its own indexing reason, content and canonical

Do not remove useful redirects just to reduce the report count. Bookmarks, old external links and visitors may still depend on them. For a permanent site move, Google recommends keeping redirects for at least one year^[2]Source 2At least one yearView source ↗, and retaining them longer can help users following old links.

If a page has been removed with no suitable replacement, returning a genuine 404 or 410 may be appropriate. Sending every missing page to the homepage can create a poor destination and may be treated as a soft 404. Match the response to the actual content situation.

Trace the redirect chain from the exact URL

Copy the address directly from Search Console. Preserve the protocol, hostname, path, slash and query parameters. Typing a “cleaned up” version can skip the behavior Google reported.

Use a redirect checker or your browser's Network panel to follow the request. In Chrome, open developer tools, select Network, enable Preserve log, and navigate to the source URL. Inspect the document requests and their response headers. Cached redirects can affect a browser check; disable cache while developer tools is open when you need a fresh trace.

Redirect trace workflow

1. Record the source URL and the time of the check.
2. Capture each response status and its destination.
3. Continue until you reach content or identify a repeated address.
4. Compare the final page with the intended replacement.
5. Repeat the same trace after changing the responsible rule.

Read each status and Location header

A server redirect normally supplies a 3xx response with a Location header identifying the next address. The final address bar hides the intermediate responses, so it cannot tell you how many steps occurred.

In a local HTTP demonstration for this guide, a direct route returned 308 and then 200. A second route returned 301, then 302, then 200. A third alternated between two URLs until the trace detected a loop. These are controlled examples of response behavior, not measurements of Google's indexing.

A 200 at the end still needs a content check. Confirm that the page displays the intended article, product or service, rather than a login screen, empty template or error message.

If the URL changes after a 200 response without a server redirect, inspect the page for meta refresh or JavaScript navigation. Google's redirect documentation^[3]Source 3Redirect documentationView source ↗ describes these methods and recommends server-side redirects when possible.

Choose the right 301, 302, 307 or 308 redirect

Choose a status based on whether the move is permanent or temporary. A temporary redirect is legitimate when you expect the original address to resume serving its content.

Status	Meaning	Google Search implication	Request-method behavior
301	Permanent move	Signal that the target should be canonical	A client may change POST to GET
308	Permanent move	Signal that the target should be canonical	Preserves the request method
302	Temporary redirect	Does not supply the same target-canonical signal	A client may change POST to GET
307	Temporary redirect	Does not supply the same target-canonical signal	Preserves the request method

The method distinction comes from HTTP semantics in RFC 9110^[4]Source 4HTTP semantics in RFC 9110View source ↗. It matters for forms, APIs and other requests that send data. An ordinary page visit generally uses GET, but a site-wide rule can affect other traffic too.

Google can use other signals when choosing a canonical URL. Do not assume every temporary redirect is wrong, or that a 302 automatically becomes a 301 after a fixed number of days. Use a permanent status when the move is permanent, then align the rest of your site with that destination.

Inspect the redirect destination separately

Copy the final destination into the URL Inspection tool. Check that exact address rather than relying on the source URL's report.

For a destination you want indexed, inspect:

• Whether it returns the intended page successfully.
• Whether Google can crawl its content.
• Whether an indexing directive excludes it.
• Whether its declared canonical and Google's selected canonical match your intention.
• Whether Search Console records it as indexed or gives another exclusion reason.

Google's canonicalization guidance^[5]Source 5Canonicalization guidanceView source ↗ explains how redirects, canonical annotations and sitemap entries contribute signals. A redirect is part of that picture; it cannot make an inaccessible or unsuitable target a useful search result.

If the destination is unknown to Google, check discovery and access for that destination. Repeatedly inspecting the old source will not answer why the new page has not entered the index.

Understand what the live URL test follows

There is a subtle difference between the two inspection views. Google says the indexed inspection information concerns the tested source URL, while the live test follows redirects and tests the final URL without indicating that it followed a redirect.

That means a successful live test of the old address can reflect an accessible destination. It does not prove that the old address now serves content directly or that either address is indexed.

Keep two records: the source's response path and the destination's own inspection result. Together they explain much more than a green live-test result alone.

Fix unwanted rules and update discovery paths

Find the layer responsible for the unexpected behavior before adding another rule. Redirects can come from a CMS, a plugin, the web server, hosting controls or a content delivery network (CDN).

A header such as X-Redirect-By: WordPress can offer a clue, but it is not a complete inventory of every layer involved. Compare the rules that handle the same path, protocol and hostname. A common loop occurs when one layer adds a slash or changes the host and another reverses it.

For a permanent move, point the old URL directly to the relevant final page where practical. Update internal links to that final address, and include the preferred destination in your normal current sitemap. Google's sitemap guidance^[6]Source 6Sitemap guidanceView source ↗ recommends listing URLs you want represented in search results.

Repair and retest workflow

1. Identify the intended URL and the rule that changes it.
2. Correct that rule or its conflicting counterpart.
3. Clear relevant caches so the updated response can be checked.
4. Retest the exact source and destination.
5. Check another affected URL and an unaffected page for regressions.

Avoid using Search Console's Removals tool as a redirect repair. Hiding a search result does not correct a server rule, restore missing content or resolve a loop.

Verify the outcome of a ‘Page with redirect’ change

For an intentional move, success means the source reaches the correct destination and the destination's own content and indexing signals are sound. The old source can continue to appear under “Page with redirect.”

For an accidental redirect, success means the affected URL once again delivers the content you intended. Compare a fresh trace with your original record, then inspect the corrected URL and check the crawl date as Google's data updates.

Use a validation control when applicable to the faulty pattern you actually repaired. If a destination needs recrawling, follow Google's recrawl request guidance^[7]Source 7Recrawl request guidanceView source ↗. Requests do not guarantee indexing, and repeated submissions do not make processing faster.

Choose one reported URL now. Record its intended role, follow its actual path, and inspect the final page separately. Make the smallest change that brings those observations into agreement.

Sources

1. Google Search Console Help. Page indexing documentation.

2. Google Search Central. At least one year.

3. Google Search Central. Redirect documentation.

4. IETF. HTTP semantics in RFC 9110.

5. Google Search Central. Canonicalization guidance.

6. Google Search Central. Sitemap guidance.

7. Google Search Central. Recrawl request guidance.