Because a sitemap is a suggestion, not a boundary. Google Search Console reports every URL Google knows about on your property, however it found them, and most sites have far more discoverable URLs than published pages.
Does the sitemap control what appears in the report?
No. It adds URLs to the set Google considers and never subtracts any. Submitting a sitemap tells Google what you would like crawled; it does not tell Google to forget what it already found, and it does not prevent discovery of anything you left out.
The report has two views for this reason, and mixing them up causes most of the confusion. The sitemap view is scoped to URLs in a specific sitemap. The main page indexing view is scoped to the whole property. If the second is much larger than the first, nothing is wrong with the report; you are seeing the difference between what you declared and what exists.
Where do the extra URLs come from?
Five sources cover nearly all of them, and each needs a different response.
| Source | What it looks like | Usually |
|---|---|---|
| Parameters appended to real URLs | Filters, sort orders, tracking codes, session ids | Noise, unless it is crawled heavily |
| Internal search results | A search path with a query string | Worth closing off |
| Old URLs from a past site | Paths matching a structure you retired | Fine if they redirect, a problem if they 404 with links |
| External links, including mistyped ones | Paths nobody ever published | Noise; Google tried and found nothing |
| Feeds, pagination and generated endpoints | Machine-shaped paths from the CMS or plugins | Expected; check nothing valuable is trapped there |
A domain-level property widens all of this further, because it reports every subdomain and protocol variant, including staging hosts somebody forgot to protect.
What does Discovered, currently not indexed actually tell you?
That Google knows the URL exists and has chosen not to crawl it yet. The URL was found, queued, and deprioritized against everything else Google could spend a crawl on for your site.
In small numbers it means nothing. In large numbers against pages you care about, it is a signal about how Google is rationing attention on your site, and the usual cause is a sprawl of low-value URLs competing with the ones that matter. The adjacent state, crawled but not indexed, is a different message: Google looked and decided the page was not worth keeping. How Google decides what to index first covers the ordering.
Robots.txt and noindex cannot be used together. Blocking a URL in robots.txt stops Google crawling it, which means the noindex tag on that page is never read, so a URL already in the index can stay there indefinitely. Pick one: noindex to remove a page from the index, robots.txt to stop crawling a pattern that was never indexed in the first place.
Which of these are worth your time?
Only the ones that either waste crawling at scale or can be landed on by a real visitor. Everything else is reporting, not a task.
A URL that can receive traffic is the first priority. An internal search path that ranks and lands someone on an empty result page is a conversion rate problem before it is an indexing one, and it is the clearest case for closing a pattern off entirely.
Scale is the second. Thousands of parameter combinations being crawled on a large site pull attention away from pages that earn money, and a thin index of near-duplicates works against the topical authority you are trying to build on the pages that count. The practical steps are in preventing index bloat.
What does not deserve a sprint: a handful of 404s from mistyped external links, a few retired URLs that already redirect, and anything appearing in single digits. Those lines will always be there.
How do you get a URL out once it is in?
Work in this order, because the steps undo each other if you do not. Stop generating the URL first, so the pattern does not refill while you clean it up.
Then choose by what the URL is. A page with a real equivalent should redirect to it. A page that should never have existed and has nothing to replace it should return 410 or 404. A page that must stay reachable for people but not appear in search takes a noindex tag, left crawlable so the tag is read, until it drops out. Only after a URL is gone from the index does a robots.txt rule make sense, as a way to stop the crawling from starting again.
The removals tool in Search Console is not part of this. It hides a URL for about six months and nothing more, which is useful for something urgent and leaked and useless as a cleanup method, because everything comes back when the clock runs out.
Reading the total as a health score and trying to drive it down. A large count of known URLs is normal on any site with filters, pagination and history. The number that matters is whether the pages you want indexed are indexed, which is a different query against the same report and the only one tied to organic search revenue.
What do you actually fix this week?
Sort the report by pattern rather than by URL, take the largest pattern that a visitor could land on, and close it at the source. One pattern closed properly removes thousands of lines; one URL fixed by hand removes one, and the generator that made it is still running. Everything else on that list can wait for a month when there is nothing better to do, which there usually is. More on the report's blind spots in what Search Console cannot tell you.