What the sitemaps report shows
This is where you tell Google the address of your XML sitemap and where it reports back on what it found. Each submitted file gets a row: its address, its type, when Google last read it, whether that read succeeded, and how many addresses were discovered inside it.
Status is the part worth reading closely. Success means the file was fetched and parsed. Could not fetch means Google asked for it and got an error, a timeout or nothing at all. Has errors means the file was readable but something inside it broke the format — a malformed date, an address that sits outside this property, or a file that exceeds the published size and address limits.
Each row also links through to the indexing report filtered to that sitemap, which is the genuinely useful part: it shows what happened to the addresses you submitted, rather than merely that you submitted them.
Why the sitemaps report matters
A sitemap speeds up discovery. It does not force anything into the index, but for a new site, a large site, or one where pages are poorly linked internally, it is the difference between Google finding a page soon and finding it eventually.
The report matters most around change. After a migration, a platform switch or a bulk publishing run, it is the quickest confirmation that your new addresses are being handed over correctly and that the old sitemap has not been left in place, quietly offering Google a list of dead URLs.
Common mistakes with the sitemaps report
Reading the discovered count as an indexed count is the classic error. It counts the addresses inside the file. Whether Google keeps them is decided elsewhere, and the gap between the two numbers is often where the real problem sits.
Filling the sitemap with the wrong addresses is the other one. A sitemap is a statement that these pages are your canonical, indexable, current pages. Listing redirects, missing pages, noindexed pages, tag archives and paginated duplicates contradicts that statement and makes the whole file less trustworthy.
Then there is the abandoned file. Many sites still submit a sitemap left behind by a plugin that has since been replaced, so two files describe the site differently and neither is right.
How to act on it
Submit one sitemap index that points at your section files, rather than a long list of individual submissions, so there is a single thing to maintain. Make sure the file is generated automatically as content changes; a hand-built sitemap goes stale within weeks.
Then use the report as a diagnostic route rather than a checkbox. Click into the indexing view for a sitemap, look at which of your submitted addresses were excluded and why, and treat repeated exclusions as a content or technical SEO question. Remove any old sitemap you no longer generate, and after any migration check the last read date to confirm Google has actually come back for the new one.