Why Google Search Console Still Shows Old Errors After You Fix Them

Fixing the site and seeing the fix in Search Console are two different events.

That is the first thing I had to accept while cleaning up indexing issues on my Hugo and Netlify site.

I could deploy a fix, test the URL in the browser, confirm the sitemap was clean, and still see the same old error counts in Google Search Console. The Pages report would continue showing 404, page with redirect, redirect error, or crawled - currently not indexed even after the live site was already corrected.

That feels wrong when you are looking at the report as a real-time dashboard.

But Search Console is not a live uptime monitor. It is a reporting system built from Google’s crawling, indexing, and processing pipeline. Some views update quickly. Some examples remain stale for a while. Some issue counts take time to move even after the live URL is fixed.

The practical question is not:

Why has the chart not changed yet?

The practical question is:

What does the live URL show now?

The Report Can Lag Behind The Site

After a fix, there are usually two versions of reality:

1. The live site state
2. The Search Console report state

The live site state is what your server, CDN, sitemap, redirects, and pages return right now.

The Search Console report state is what Google has crawled, processed, and summarized so far.

Those two states do not always update at the same time.

For example, after fixing a stale post URL, I care about these live checks first:

old URL -> direct 301 or intentional 404
canonical URL -> 200
canonical URL -> present in sitemap
old URL -> absent from sitemap
internal links -> point to canonical URL

If those are correct, the site is in a good state even if Search Console still shows yesterday’s error count.

Search Console Is Not One Report

One confusing part is that Search Console has several views that feel related but answer different questions.

For indexing cleanup, I separate them like this:

Pages report
Shows grouped indexing issues and trends.

URL Inspection
Shows what Google knows about one specific URL.

Live URL Test
Fetches the current URL state from the live site.

Validation
Asks Google to re-check a fixed issue group.

Request Indexing
Asks Google to recrawl a specific canonical URL.

The mistake is expecting all of these to agree immediately.

They often will not.

A Pages report might still show an old issue. URL Inspection might show Google’s last indexed or crawled view. The live test might show the current page is fine. Validation might still be waiting. Request indexing might be available, but that does not mean the report will change immediately.

Start With Your Own Live Checks

Before opening Search Console, I want to know what the site currently serves.

For a Hugo site, I start with a clean build:

hugo --source "$SITE_ROOT" `
  --config "$SITE_ROOT\hugo.toml" `
  --cleanDestinationDir `
  --minify

Then I check that the intended page exists in the generated output:

Test-Path "$SITE_ROOT\public\post\my-current-post\index.html"

I also check that old URLs are not still being generated:

Test-Path "$SITE_ROOT\public\post\old-folder\old-post\index.html"

For sitemap checks:

rg -n "my-current-post|old-folder/old-post" "$SITE_ROOT\public\sitemap.xml"

The canonical URL should appear. The stale URL should not.

If the generated output is wrong, fix Hugo first. Search Console cannot correct a site that is still generating the wrong signals.

Test The Deployed URL, Not Just The Local Build

Local checks are necessary, but they are not enough.

After deployment, I test the real public URLs:

https://example.com/post/current-url/
https://example.com/post/old-url/
https://example.com/sitemap.xml

For article URLs, I want:

canonical article URL -> 200
old article URL with replacement -> 301 to canonical
old article URL with no replacement -> 404
sitemap.xml -> only canonical URLs

This is where Netlify redirects can be verified. A rule in netlify.toml or static/_redirects is only useful if the deployed site actually serves it.

If the live site is wrong, fix the deployment or redirect rule before touching Search Console validation.

Use URL Inspection For One URL At A Time

Once the live site looks correct, I use URL Inspection on the exact URL.

There are two different questions here.

First:

What does Google currently know about this URL?

Second:

What happens if Google tests this URL live now?

Those are not the same question.

The stored inspection result can reflect an earlier crawl. The live test checks the current URL state. When debugging a recent fix, the live test is usually more useful.

If the live test says the canonical page is available, indexable, and not blocked, that is a strong signal that the fix is technically correct.

If the live test still fails, Search Console is not lagging. The page is still broken from Google’s point of view.

Validate Fix Is For Issue Groups

The “Validate Fix” button is useful, but it is easy to misunderstand.

Validation is not the same as requesting one page to be indexed. It applies to an issue group in the report.

For example:

Not found (404)
Page with redirect
Server error (5xx)
Redirect error

When I click validation, I am asking Google to re-check that issue type across the affected examples. That process can take time.

Validation can also fail if Google finds a remaining example with the same issue.

That is why I do not start validation until I have done the source audit:

1. Search old slugs with rg.
2. Check front matter slug, url, and aliases.
3. Check internal links.
4. Check redirect rules.
5. Rebuild cleanly.
6. Check sitemap output.
7. Deploy.
8. Test live URLs.
9. Then validate the issue.

Validation should be the final confirmation step, not the debugging tool.

Request Indexing Is For Canonical URLs

Request indexing is useful for important pages, but I use it carefully.

I request indexing for the current canonical URL:

/post/current-article/

I do not request indexing for the old redirect source:

/post/old-article/

The old URL is supposed to disappear or settle as a redirect. Asking Google to index the old URL sends the wrong operational signal.

For a moved article, my flow is:

1. Old URL returns 301.
2. New canonical URL returns 200.
3. New canonical URL is in sitemap.
4. Old URL is not in sitemap.
5. Inspect the new canonical URL.
6. Run live test.
7. Request indexing for the new canonical URL if it matters.

Request indexing is not a guarantee of immediate indexing. It is a prompt for Google to crawl or consider the URL. The page still needs to be crawlable, indexable, canonical, and useful enough to include.

Do Not Panic When Counts Stay The Same

This is the part that feels uncomfortable.

You can fix the site and still see the same number in Search Console for a while.

That does not automatically mean the fix failed.

I look for these signals instead:

Live URL test passes.
Sitemap contains only current URLs.
Old URL redirects or 404s intentionally.
Internal links point to current URLs.
No stale generated files exist after a clean build.
Validation has started or is available.

If those signals are correct, I wait.

If the live test fails, I continue debugging.

When Old Errors Still Matter

Lag is normal, but it should not become an excuse.

Old Search Console errors still need attention when:

• the live test fails
• the canonical URL is missing from the sitemap
• the old URL still appears in the sitemap
• internal links still point to the stale URL
• a redirect chain exists
• a redirect points to the wrong page
• the page returns intermittent 5xx
• the page has accidental noindex
• the wrong canonical URL is declared

In those cases, the report is not just stale. It is pointing to a real signal problem.

A Practical Post-Fix Checklist

This is the checklist I use after deploying a fix:

1. Rebuild the site with a clean public output.
2. Confirm the canonical page exists in generated output.
3. Confirm stale generated pages do not exist.
4. Search sitemap.xml for old and current URLs.
5. Deploy the site.
6. Test the canonical URL publicly.
7. Test the old URL publicly.
8. Inspect the canonical URL in Search Console.
9. Run a live URL test.
10. Request indexing for the canonical URL if needed.
11. Start validation for the fixed issue group.
12. Wait for the Pages report to catch up.

That order matters.

If I request indexing before confirming the live page and sitemap, I may just ask Google to re-check a broken state.

How I Read The Result

After the fix, I treat Search Console like this:

Live test passes, report still old:
Probably normal lag.

Live test fails:
Fix is not complete.

Canonical URL indexed, old URL still listed as redirect:
Usually acceptable during cleanup.

Old URL still in sitemap:
Fix sitemap/source generation.

Validation failed quickly:
Inspect the examples Google shows and repeat the audit.

This makes the dashboard less stressful because each state has a next action.

Final Takeaway

Google Search Console can still show old errors after you fix them because its reports are not real-time mirrors of your deployment.

The correct response is not to keep changing redirects randomly.

The correct response is to separate live evidence from report lag:

• check the generated Hugo output
• check the deployed URL
• check the sitemap
• inspect the canonical URL
• use live URL testing
• validate the issue group
• request indexing only for the canonical URL

Once the live site is clean, Search Console can take time to catch up. That waiting period is normal. The important part is making sure Google sees a coherent site the next time it crawls.

References

• Google Search Console URL Inspection tool
• Google Search Console validation details
• Google Search Console Sitemaps report

• ← Previous Post