Common Google Search Console Errors and How to Fix Them
Most of them are not urgent and several are not errors at all. This guide is about telling the difference, because a business treating every reported item as a fault will spend a great deal of time and money on nothing.
Most Of These Are Not Urgent
The tool reports everything it notices. A long list of items is the normal state of a working website rather than evidence that something is broken. Read that sentence twice if somebody has recently shown you a red number and quoted a price for fixing it.
Why the list is always long. It is thorough.
Every address it has ever encountered gets a status, including ones you retired years ago, ones generated by filters and ones that only ever existed in a link somebody typed wrongly.
What that produces. Alarming counts.
Thousands of items on a site with two hundred pages is entirely ordinary. The count describes how much the tool has seen rather than how much is wrong.
How the panic gets used. Commercially.
A red count is the easiest thing in this industry to sell against. We have seen quotes built entirely on screenshots of reporting that described a site working as intended.
What this page does instead. Sorts them.
A short list that deserves attention, a longer list that does not, plus the expectations to hold about how any of it behaves once you have acted.
The one exception to the calm. Two categories.
A security notice or a manual action is different in kind, announced with a reason and genuinely urgent. Those are the items to check first and rule out.
Errors, Warnings And Excluded
Three categories that get treated as one. Understanding what each actually means is the single most useful thing on this page. It takes about a minute.
An error. Something did not work.
Google tried to do something it expected to be able to do and could not. It was pointed at a page and the page was unreachable. Perhaps an instruction contradicted another one. This is the category worth reading.
A warning. Worth a look, not blocking.
Something Google noticed that is not preventing anything. Frequently a page that is stored despite an instruction suggesting it should not be. Sometimes markup that is present and imperfect.
Excluded. Not an error at all.
A page that is not stored. That is the whole meaning. Nothing in the word implies a fault. A substantial number of exclusions are the site behaving exactly as it should.
Why excluded alarms people. The number is large.
Shops, blogs with tags and anything generating filtered addresses will produce enormous excluded counts. Businesses read that as thousands of broken pages, which is not what it says.
The question to ask about it. Can you explain it.
A large count you can account for is fine. A count containing pages you want stored is worth investigating, which is what our indexing guides are for.
What Genuinely Needs Action
Four categories. Everything else on this page can wait for a monthly review. Most of it can wait indefinitely.
A security notice. Today.
This says the site may be compromised or serving something harmful. It is a business and customer safety matter before it is a search problem. our guide to that reporting covers why.
A manual action. Today.
Somebody reviewed the site and applied something, with a stated reason. Rare, definite and announced, which makes it the one category you can confirm or rule out in a minute.
Pages you care about that cannot be reached. This week.
Not every unreachable address matters. Ones you deliberately retired are fine. A page you rely on returning a failure is worth attention, particularly if something links to it.
Blocking that should not be there. This week.
Where instructions on the site are preventing pages from being stored that you want stored. Our technical material owns those instructions and how they conflict.
What to do with the rest. Read it monthly.
Look at whether a category is growing rather than whether it exists. Growth is information. A steady count is background.
What Usually Does Not
These turn up constantly, get quoted at businesses as problems and are nearly always the site working correctly. Recognising them saves more money than fixing anything.
Pages excluded deliberately. By your own instruction.
Anything you have told Google not to store appearing in a report saying it has not been stored is the system agreeing with you.
Duplicates handled correctly. One version chosen.
Where several addresses show the same thing and Google has picked one, that is the intended outcome. It is only worth investigating if it picked a different one from the one you wanted.
Redirects behaving as intended. Reported, not broken.
Old addresses pointing at new ones will be reported as redirected. That is a description rather than a complaint. Businesses regularly try to eliminate it.
Old addresses long since retired. Reported for years.
Google keeps checking things it once knew about. An address you deleted in 2021 can still appear, which is untidy rather than harmful.
Pages that were never real. Somebody mistyped a link.
An address that only ever existed because of a typo elsewhere on the web will be reported as unreachable, correctly, forever.
What all of these have in common. No action available.
There is nothing to fix, so effort spent on them produces a tidier report and no commercial change whatsoever.
Errors Appear Late And Clear Slowly
This reporting lags reality in both directions. Something that broke a fortnight ago may only be appearing now. Something you fixed yesterday will keep being listed for a while. Knowing that prevents the commonest waste of effort here.
Why it appears late. Nothing is instant.
Google has to revisit a page to notice a change. It revisits according to its own priorities rather than yours. A problem exists before it is reported.
Why it clears slowly. Same mechanism.
The listing persists until enough affected pages have been rechecked. That happens gradually, so counts fall in steps rather than dropping to zero.
What that causes. Fixing things twice.
A business fixes something, sees no change, assumes the fix failed and changes something else. Now two things have changed, neither can be evaluated and the report clears eventually for reasons nobody can attribute.
What to do instead. Change one thing and wait.
Make the fix, record the date, then leave it alone. Our measuring performance material makes the same argument about establishing whether a change worked.
We will not quote you a timescale. They vary.
How long a category takes to clear depends on the site, its size and how often it gets revisited. Anybody giving you a number of days is guessing.
Fix The Cause, Not The Report
There is a facility for telling Google you have dealt with something and asking it to look again. Using it without having changed anything is one of the more common pieces of theatre in this field. It achieves precisely nothing.
What validation actually does. Rechecks.
It asks Google to revisit the affected pages and confirm the problem has gone. If the problem has not gone, it comes back, having wasted a fortnight.
Why people press it anyway. It looks like action.
Something has been done, a process is running and a report can say so. This is why validation appears in monthly reporting more often than the changes that would justify it.
What a real fix looks like. Something changed on the site.
A page restored, an instruction corrected, a redirect put in place or content improved. If nobody touched the site, nothing was fixed.
The order that works. Cause, change, then validate.
Establish why the item is reported, change the thing responsible, then ask for the recheck. Skipping the middle step is the whole problem.
Where this comes from. The position across our work.
Reporting is not fixing. It applies here, on the indexing pages and everywhere else we discuss measurement, because the tool diagnoses and people do the work.
When It Is The Tool Rather Than The Site
Reporting glitches happen. Figures move for reasons that have nothing to do with your website. A business that responds immediately can spend a fortnight solving a problem that was never there.
What a glitch looks like. Everything at once.
Several unrelated figures changing sharply on the same day, with nothing having changed on the site, is the signature. Real problems are usually narrower than that.
What a real problem looks like. Traceable.
A change you can connect to something. A release, a redesign, a plugin update, a server move or a section of the site behaving differently from the rest.
What to do about a suspected glitch. Wait a week.
Note the date, change nothing and look again. Most of them correct themselves. The ones that do not have become a genuine finding by then.
How to tell quickly. Check the site yourself.
Look at the pages the report is complaining about. If they load correctly, the reporting is describing something that is not currently true.
Where to look next. The indexing guides.
Fixing indexing errors covers what to do about the items that genuinely matter. Everything sits on the Google Search Console guide.
A long list
is the normal
state of a
working site.
We have read quotes built entirely on screenshots of reporting that described a site working exactly as intended. Before anybody spends money here, the useful exercise is sorting what is reported into the handful of things that matter and the majority that do not.
What we actually check:
If the answer is that your reporting looks fine and the problem is elsewhere, we will tell you that.
Every guide.
One tool.
Getting set up and verified, using the reports properly, the performance and indexing data, finding what is broken, finding what is being passed over and turning any of it into work worth doing.
