How to fix 404 errors reported in Search Console

A 404 for a page that should not exist is fine. Leave it as is. Do not spend time on ghosts no one visits or links.

• Matters: deleted pages that still have internal links, are in your sitemap, or had clicks and backlinks.
• Matters: URLs users can still reach from your UI, such as a menu item to /blog/page-2 that is gone.
• Does not matter: a typo URL like /pritcing that no page links to and that never had traffic.

Start with impact. If a 404 could cost a sale or an earned link, fix it. If it is an orphan typo with no visits, let it return 404 or 410 forever.

Open Search Console. Go to Indexing, then Page indexing. This report lists every URL Google knows for the property as Indexed or Not indexed with a reason.

Filter to Not indexed. Click the reason Not found (404). You will see example URLs, up to 1,000. Export the list if you prefer to work in a sheet.

Also check Soft 404. These are pages that return 200 but look like an error or are empty, so Google treats them as not found. They need a different fix, covered below.

You fix the 404s that carry value. Use three places in Search Console to judge that value per URL.

1. 1

   Performance report on the URL

   Open Search results. Add a page filter for the 404 URL. Set the date to the last 28 days, then a longer range. If you see impressions or clicks before it broke, it is worth a fix or redirect.

2. 2

   Links report

   Open Links. Under Top linked pages, search for the 404 URL. If it has external links, plan a redirect to the nearest equivalent.

3. 3

   URL Inspection referring page

   Inspect the 404 URL. In Discovery, look for Referring page and Sitemaps. This tells you where Google found it. Fix the source link or the sitemap too.

Example: /guides/getting-started returns 404. Performance shows it once ranked for "yourproduct getting started". Links show referring domains. Redirect it to /guides/new-user-setup, not to /.

Choose one action per broken URL. Redirect to the nearest equivalent. Restore the content. Or leave it gone and return 410. Here is how to decide fast.

Do not redirect to a URL with a different intent. Sending /blog/how-to-export-data to /pricing will not help users or rankings. Find the closest match or return 410.

Use 301 for permanent moves. Use 410 when you retire a page with no replacement. Keep 404 for true mistakes and typos you will never create links to.

• Add rules at the web server or CDN level. Avoid JavaScript redirects.
• Match the full path. Include trailing slash variants if your site uses both.
• Keep regex specific. A broad rule like ^/blog to / can wreck a section.

1. 1

   Test the HTTP status

   Request the old URL and confirm 301 or 410. Confirm the target returns 200.

2. 2

   Check for chains and loops

   Follow the redirect once and make sure it ends at the final page. Fix chains created by old rules.

3. 3

   Confirm with URL Inspection

   Inspect the old URL. You should see Page with redirect as the reason. Inspect the target. It should be indexable and show the last crawl date once fetched.

Example: old doc at /docs/api-legacy is retired. Add a 410 rule for /docs/api-legacy. Update /docs and any in-app links to point to /docs/api-latest or the overview page. Inspect both URLs to see Google’s view.

Fix the source of the 404. This stops new visits to broken pages and lets Google drop the old URL cleanly.

• Find and fix internal links. Search your codebase and CMS for the old slug. Update nav, footers and any CTAs.
• Update the XML sitemap. Remove dead URLs. Add new targets. Submit the sitemap again in the Sitemaps report.
• Remove broken URLs from any HTML sitemaps and hub pages.
• Check marketing assets. Update PDFs, emails, docs and help widgets that still point to the old URL.

Example: the /pricing/enterprise page was merged into /pricing. Remove /pricing/enterprise from the sitemap. Update the nav and any /pricing/enterprise links in /blog posts. Keep the 301 in place for users with old bookmarks.

Sending every 404 to / is not a fix. Users land on an unrelated page. Google can treat this as a Soft 404. You lose the chance to pass relevance.

If you have no clear equivalent, return 410. If you have a close match, redirect to that page. Do the work per URL. Batch home redirects only hide the problem.

The URL Inspection tool works for URLs in your verified property only. Use it to see how Google discovered a URL and whether crawling and indexing are allowed.

1. 1

   Inspect the broken URL

   Check Discovery for the referring page and sitemap. Fix those sources. Note the last crawl date and the crawler used.

2. 2

   Test live URL

   Fetch the page now. View tested page to see the HTTP response, rendered HTML and any blocked resources. Confirm the server returns 301, 404 or 410 as intended.

3. 3

   Request indexing

   Queue a crawl after you fix the page and its sources. The quota is small per property per day. It does not guarantee indexing.

Example: /changelog/old-release returns 404. Inspection shows a link from /changelog. Fix that index page to remove or retitle the link. Add a 410 or a redirect to /changelog. Request indexing on both URLs when done.

After you fix a batch, return to the Page indexing report and click Validate fix on Not found (404) and Soft 404. Expect the re-check to take about two weeks.

• Set a habit. Check the report weekly for spikes.
• Before a release that changes URLs, write a redirect map. Example: export old /blog/* slugs to a CSV and map each to its new slug.
• Keep the sitemap fresh. Automate it in your CMS. Only include canonical, indexable URLs that return 200.
• Avoid internal links that go through redirects. Update the source to the final URL.
• Audit backlinks after large restructures. If a good link points to a retired guide, keep the redirect live long term.

If the report shows Page with redirect as Not indexed, that is normal. The target is what gets indexed. Fix it only if your sitemap or internal links still use the old URL and send users through the hop.

Some 404s are symptoms of other issues. Check these before you chase ghosts around your logs and reports.

• Case-sensitive paths: /Pricing and /pricing. Pick one style and redirect the other.
• Trailing slashes: /docs and /docs/. Be consistent and redirect one to the other.
• HTTP to HTTPS: always redirect to HTTPS. Do not let old HTTP endpoints 404.
• Locale and case in file names: /Images/logo.png on Linux may 404 while /images/logo.png exists.
• Campaign parameters: keep the base URL indexable. Add rel=canonical to the clean URL.
• Blocked crawl: Blocked by robots.txt can still be indexed by URL. That is separate from 404. Unblock if you want content indexed.

Example: your blog moved from /blog to /articles. A lazy rule from ^/blog to / causes Soft 404s for tag pages. Replace with precise rules per type: /blog/{slug} to /articles/{slug}, /blog/tags/{tag} to /tags/{tag}. Test each pattern on a sample of real URLs before deploy.