Before you fix anything: a lot of what Search Console reports is not a problem. Several of the scariest looking entries describe Google doing exactly what you told it to do, and "fixing" those undoes decisions you made on purpose.
Ask one question of every entry in the Pages report: did I want this page in Google? If the answer is no, there is nothing to fix, no matter how much the wording sounds like a fault.
"Excluded by noindex tag" on a page you deliberately noindexed is correct behaviour. "Alternate page with proper canonical tag" is correct behaviour. "Duplicate, Google chose a different canonical" is usually fine. "Page with redirect" is what a redirect is for.
The entries worth your time are the ones that contradict your intent: a page you want indexed that is excluded, a server error, a soft 404 on a real page, or a security issue. Everything else is reporting, not an alarm.
Search Console describes what happened. It does not know what you intended, so it reports your deliberate choices in the same tone as your mistakes.
noindex tag, on a page you noindexed on purposenoindexIn plain English, with the honest verdict on each.
Google found the page and found a noindex instruction, so it left it out. That is the tag doing its job. On a thank you page, a cart, an internal search result or a staging path, this is correct and you should do nothing. It is only a problem if you did not intend the tag, which happens when a build time noindex survives launch. If the excluded page is one you want found, that is your bug.
You pointed at one page as the canonical; Google looked at the signals and chose another. This sounds like a rejection and usually is not. If the page Google chose is a reasonable representative and it is indexed, your visitors get there. Look into it when the choice is genuinely wrong, such as a filtered URL beating your real product page, and then fix it by making your intent consistent rather than by adding more tags.
The ambiguous one. Google read the page and passed on it for now, giving no reason. There is no error to fix, which is exactly why it frustrates people. Read it as a quality and demand signal: the page may be thin, may duplicate another of your pages in substance, or may just be new. On a few low value pages, ignore it. On your main service pages, it is telling you something about the pages themselves.
Google knows the URL exists but has not fetched it yet. Common on large sites and new sites. Often it resolves on its own. Where it persists across many pages it can indicate crawl budget being spent badly, or a site that is not giving Google enough reason to come back.
Correct behaviour when you blocked it deliberately. Worth knowing the nuance: this blocks crawling, not indexing. A blocked URL can still appear as a bare listing with no description, because Google knows it exists but was never allowed to read it. If you genuinely want a page out of search, noindex is the tool, and Google must be allowed to crawl the page to see it.
This one is a real contradiction and deserves attention. You put the URL in your sitemap, telling Google you want it indexed, and then blocked it. Two instructions, opposite directions. Decide which you meant.
The page returned a success status but looks empty or like an error page to Google. Common on genuinely thin pages and on custom "not found" pages that forget to return a 404 status. If the page has real content, it is a hint that it reads as empty.
Always worth attention. Your server failed while Google was there. If it is intermittent, it may be load, a timeout or a host problem. Repeated failures make Google crawl less, which affects everything else.
The URL redirects, so it is not indexed under that address. This is what redirects are for. Normal after any redesign with a proper URL migration.
Open the indexed list. Are the pages that make you money in there? If yes, most of what follows is housekeeping rather than an emergency.
For each one, ask the only question that matters: did I want these pages in Google? Say it out loud. Most rows die here.
The reason label means nothing without the sample list. Two hundred excluded URLs that are all tag archives and cart pages is not the same finding as two hundred service pages.
URL Inspection tells you exactly what Google did with that page, why, and when. One inspection on a real page is worth more than an hour of theorising about the summary.
A page in your sitemap that you also blocked is a contradiction: fix that. A page you noindexed that Google did not index is a decision being honoured: leave it.
These are short reports and they are almost always empty. When they are not, they outrank everything else on this page. See website security problems.
Use the Validate Fix button after you have actually changed something. It is a request for re-checking, not a fix in itself, and it takes days to complete.
noindex removes the page entirely, which is rarely what you meant.noindex on a page it is not allowed to crawl.www only, on a site that also serves the bare domain, will show a confusing partial picture. A domain property covers everything.Reading this report is a skill and it is learnable. Bring someone in when:
We read these reports against what you actually intended, which is the piece the tool cannot know. Frequently the honest answer is that nothing is wrong and the report is describing your own decisions back to you.
No, and this is the most useful thing on this page. Many entries in the Pages report describe Google correctly following instructions you gave it. A page excluded by a noindex tag you deliberately added is the system working. A thank you page, a login page, a tag archive nobody should land on: all correctly excluded.
Ask one question for every entry: did I mean for this page to be in Google? If the answer is no, there is nothing to fix. Chasing a green tick on every row usually means undoing decisions you made on purpose.
This is the genuinely ambiguous one. Google fetched the page, looked at it, and chose not to index it for now. No error was thrown and no reason is given.
It usually means the page did not clear the bar: thin content, near duplicate of another page, or one of hundreds of similar pages with little to distinguish them. Sometimes it is just a new page in a queue and it resolves by itself. If it applies to a handful of low value pages, ignore it. If it applies to the pages you actually care about, that is a content quality signal worth listening to.
Usually not. It means Google found several pages it considers the same and picked one to represent them. If the one it picked is a reasonable choice and it is indexed, your traffic is going somewhere sensible and nothing is lost.
It matters when the choice is wrong: Google picked a filtered or parameter version over your real page, or picked a page on another domain. Then the fix is making your intent unambiguous with clear canonical tags, internal links and redirects, which is technical SEO work.
Check the obvious things first: is the URL exactly right, does it load in your browser, is it returning a 200 rather than an error, and is robots.txt allowing it. This status is also sometimes shown for a sitemap that has not been processed yet, so a fresh submission reporting a fetch failure for a day is not necessarily broken.
If it loads fine for you and Google still cannot fetch it, something is treating Google differently to you, such as a firewall rule or a security plugin blocking crawlers.
A drop is not automatically bad. Removing hundreds of thin auto generated pages, or noindexing archives that should never have been in there, will drop the count and improve the site. What matters is which pages left. If the pages that bring in enquiries are still indexed and impressions are steady, the count itself is not the story. If your main pages dropped out, that is worth investigating properly. Start at not showing on Google.
See how Google actually crawls, indexes and ranks your pages.
The crawling, indexing and structure work search engines depend on.
Work out whether it is not indexed, not ranking, or not there at all.
Measure what happens on your site, without collecting personal data.
Rebuild an existing site without losing the rankings you already have.
The steps that matter for getting found locally.
Tell us what your Pages report is showing. We will tell you which entries deserve attention and which ones are the system working correctly.