Redirect and 404 errors in Search Console

Google's crawlers follow up to 10 redirect hops by default, though different tools handle redirects differently; inspect the final URL directly. A redirect error usually means a loop, a chain that is too long, a redirect URL that grows past the maximum length, or a bad or empty URL in the chain. If the final target returns 4xx or 5xx, fix the target as well.

Use a permanent server-side redirect (301 or 308) when the move is permanent, and a temporary redirect (302, 303 or 307) when it is not. Send the old URL directly to the final live URL in one hop, keep the same protocol and host conventions as your canonical, and update internal links and the sitemap. Do not redirect every missing page to the homepage; that creates soft 404s and hides the real structure.

Meta refresh and JavaScript redirects are fallbacks, not the first choice. Google may not render JavaScript, and a delayed meta refresh is treated as temporary.

A 404 is not automatically an SEO problem. If a page was removed and has no replacement, returning 404 or 410 is the correct response; Google treats them the same and the URL drops out over time. If the page moved, use a 301 to the closest relevant page. If the URL was submitted in a sitemap, either restore it, redirect it, or remove it from the sitemap.

The Page indexing report shows 404s from the past month, so old noise disappears. Do not create fake content, redirect everything to the homepage, or block 404s with robots.txt. Those moves make the site harder to understand. A removal request does not clear a 404 from the report.

A soft 404 returns a success status but behaves like a missing page: an empty template, a no results screen, or a thin placeholder. Google may treat it as a 404 and keep it out of the index. Decide what the URL should do. If the content is gone, return a real 404 or 410. If the page should exist, add the missing content and make the page useful. Do not use noindex as a substitute for a correct status code.

Run a live URL inspection and view the tested page screenshot to see what Google renders. Then validate the fix after the status code or content changes.

Run a live test on the final URL: it should return 200, be indexable, and be the canonical you expect. Request indexing for important pages, and let normal crawling handle the rest. If you changed a group of URLs, use Validate fix on the issue and expect validation to take days or weeks. Keep one canonical version in the sitemap and internal links so the old URL does not keep reappearing.