Redirect or 404 on a Submitted URL: Find and Fix It

If a URL you submitted for indexing redirects or returns 404, Google will not index that URL. With a redirect, Google may index the destination instead; with a 404, it indexes nothing and removes the URL if it was indexed before. The fix is to see what the URL returns to Googlebot, then either submit the final URL that answers 200 OK or repair the page so it does.

What Google does with each status code

Response	What Google does	What to submit
200 OK	The page can be indexed if it qualifies	This URL
301 / 308 permanent redirect	Strong signal that the target should be canonical; the redirecting URL itself is not indexed	The final target URL
302 / 307 temporary redirect	Weak signal; the original URL may stay in results	Make it permanent if the move is permanent, then submit the target
404 / 410	Not indexed; URLs already in the index are removed	Nothing until the page is restored or redirected to a real replacement
Soft 404 (200 with an error-like page)	Reported as Soft 404 in Search Console	Fix the content, or return a real 404
5xx server error	Crawling slows down; URLs that keep failing are dropped	Fix the server first

Google's documentation on how HTTP status codes affect its crawlers says the crawlers follow up to 10 redirect hops by default. Don't plan around that limit: each hop is another request and another place for a mistake. One hop from the old URL to the final page is the goal.

How it shows up in Search Console

In the Page indexing report these URLs appear under Not indexed, usually with one of these reasons:

Page with redirect – a non-canonical URL that redirects to another page. Not an error by itself.
Redirect error – something went wrong in the redirect itself, such as a loop or a chain that is too long.
Not found (404) – the page returned 404 when Google requested it.
Soft 404 and Server error (5xx) – the page answered, but not with usable content.

Open the URL Inspection tool for any of them to see the last crawl, whether the page fetch succeeded and which canonical Google selected.

Step 1: check what the URL returns to Googlebot

Don't trust the browser. It follows redirects silently and may use cookies or a logged-in session. Request the URL the way a crawler does and read only the headers:

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/

The first line shows the status code; a Location header shows where a redirect points. For a list of URLs, a bulk 404 and status code checker that sends a Googlebot user agent is quicker. The SpeedyIndex checker takes up to 10 URLs per run.

Step 2: follow the redirect to the end

If the answer is 301, 302, 307 or 308, follow the chain until you reach a 200 or an error. Typical findings:

three hops for one address: http → https → www → trailing slash;
an old slug redirected to a category page or the homepage instead of the new article;
two URLs redirecting to each other (a loop);
a chain that ends in a 404.

A redirect chain checker shows every hop and the final status in one view, without installing anything.

Step 3: fix redirects

Submit the final URL, not the one that redirects. An indexing request for a redirecting URL only sends Google to the target anyway.
Collapse chains. Point the old URL straight at the final page in a single hop.
Use a permanent redirect for permanent moves. Google's redirects guide says permanent redirects are a signal that the target should be canonical; temporary redirects are not used that way.
Update internal links and the XML sitemap to the final URL, so Google stops discovering the old address.
Prefer server-side redirects. Google treats JavaScript redirects as a last resort because rendering can fail.

Step 4: fix 404s

First decide whether the page should exist at all.

Deleted by mistake, or broken by a slug change: restore the page, or add a 301 from the old URL to the current one.
Replaced by a close equivalent: 301 to that page.
Gone for good: keep the 404 (or return 410), remove the URL from the sitemap and internal links, and don't submit it for indexing.

Don't send every 404 to the homepage. A homepage is not a replacement for a specific page: visitors don't get what they came for, and the old URL has nothing relevant to pass on.

Before you resubmit

The URL returns 200 OK with no redirect.
Its canonical tag points to itself.
There is no noindex in the HTML or in an X-Robots-Tag header.
It is listed in the sitemap and has at least one internal link.
The live test in URL Inspection says the URL is available to Google.

Then request indexing in Search Console or send the URL to your indexing service. If the page later lands in Crawled – currently not indexed, the problem is no longer technical; see our guide on why pages are crawled but not indexed.

FAQ

Should I submit the old URL or the new one after a redirect?

The new one: the final URL that returns 200 OK. The old URL redirects, so Search Console reports it as Page with redirect and Google does not index it as a separate page.

Will Google remove a page that now returns 404?

Yes. Google's documentation says URLs that return a 4xx status code are not indexed, and URLs already in the index are removed. If the 404 is a mistake, restore the page or redirect it to its replacement quickly.

Is 'Page with redirect' in Search Console an error?

Not by itself. It means the URL redirects and Google looks at the target instead. It needs attention only if the redirecting URL is in your sitemap or internal links, or if the target page is not indexed.

Redirect or 404 on a URL You Submitted for Indexing: How to Find and Fix It