How to Submit a Sitemap and Check Indexed Pages

A sitemap is a list of URLs you would like a search engine to know about, plus optional metadata about each one. That is the whole job. It's a discovery aid, and submitting it creates no obligation for anyone to crawl, store or rank a single line in it.

The value swings a lot by site. A new site with almost no external links, a large catalog where deep pages sit five clicks from the home page, or a section that nothing links to yet: those are cases where a sitemap genuinely changes what gets found. A twenty page site with a clean navigation and a footer that links everything is already fully discoverable, and the sitemap adds close to nothing for discovery.

It still earns its place on that small site for a different reason. Once the file exists and is submitted, Search Console will report indexing status scoped to exactly the URLs in it, which is the diagnostic covered further down and the real payoff of this whole exercise.

Every URL in a sitemap should be one you would be happy to see in search results tomorrow. That single rule resolves most of the arguments.

Run this checklist against your file before you submit it. A URL belongs only if all six are true.

1. It returns a 200 status, not a redirect and not a 404.
2. It is the canonical version, and its rel=canonical points at itself.
3. It is not blocked in robots.txt.
4. It carries no noindex directive.
5. It is on the same site as the sitemap file (or you have verified the other host).
6. It's a page you would want a searcher to land on.

Mixed signals are the common failure. A sitemap saying "here is a URL worth knowing about" while the page itself says noindex is a contradiction, and the page-level directive wins every time. You gain nothing and you spend credibility: an engine that repeatedly finds excluded and redirected URLs in your file has less reason to treat the rest of it as a considered list. If you are unsure which tool keeps a page out of results, robots.txt and noindex do different jobs and they are not interchangeable.

Formats and limits are worth knowing before you generate anything.

One sitemap file holds a maximum of 50,000 URLs and 50MB uncompressed. Gzip compression is allowed and the 50MB ceiling applies to the uncompressed size. A sitemap index file can reference up to 50,000 sitemaps, which puts the practical ceiling far beyond what most sites will ever need.

Eight steps, and the last two are the ones people get wrong.

1. Publish the file at a stable URL. Most platforms generate one automatically at the root, for example https://www.sparkcliks.com/sitemap.xml. Keep the path fixed. Moving it later means the history in the Sitemaps report starts over.
2. Open it in a private browser window. You are checking that it returns 200, that it's not behind authentication, and that it isn't returning an HTML error page with a 200 status. A sitemap that only loads while you're logged in is invisible to a crawler.
3. Add the pointer to robots.txt. One line, anywhere in the file: Sitemap: https://www.sparkcliks.com/sitemap.xml. Every major crawler reads this, including ones that have no submission interface at all. Thirty seconds of work, and it keeps paying out on engines you will never log into.
4. Pick the right property in Search Console. A Domain property covers every subdomain and both protocols. A URL-prefix property covers only the exact prefix, so a sitemap submitted under https://www.sparkcliks.com/ will not report on URLs at a bare sparkcliks.com. If your data looks empty, this mismatch is the first thing to check.
5. Go to Indexing, then Sitemaps in the left navigation.
6. Enter the path in the "Add a new sitemap" field. The field is relative to the property root, so you type sitemap.xml, not the full URL. Click Submit.
7. Wait for the status to change. It will read Couldn't fetch at first in many cases, which usually means "not read yet" rather than "broken". Give it a day before treating it as a fault. Success means the file was fetched and parsed, and nothing more than that.
8. Do not resubmit it on a schedule. Once a sitemap is registered, engines refetch it on their own. Resubmitting the same URL daily changes nothing and hides real status changes in a wall of activity.

Submit the sitemap index file if you have one, not each child file individually. Search Console will expand it and report on the children, and you keep a single row that summarizes the whole site.

Bing Webmaster Tools has the same feature under Sitemaps, and it also offers a direct import from Search Console that carries your verified properties and sitemaps across in one step. If you have never set it up, the import is the fastest route.

Beyond that, IndexNow is a separate mechanism worth knowing about. Instead of publishing a list and waiting for a fetch, you send a URL the moment it changes. Bing, Yandex, Naver and Seznam consume IndexNow submissions. Google has not adopted it for indexing, so it complements a sitemap rather than replacing one.

Older tutorials tell you to fetch google.com/ping?sitemap= after every deploy. Google deprecated that endpoint in 2023 and has since retired it, on the stated grounds that the pings were not producing useful signal. Some plugins and build scripts still call it. If yours does, it's a no-op, and it isn't hurting anything either.

Bing has likewise moved away from anonymous sitemap pings and points publishers to IndexNow. The current answer for both engines is the same: keep the Sitemap: line in robots.txt, submit once in each webmaster tool, and let the recrawl schedule do its job.

Three different numbers get conflated here, and the confusion sends people chasing problems that don't exist.

That middle row is the trap. The Sitemaps report's "Discovered pages" column is a parse count. It tells you the file was read and how many URLs came out of it. A row showing Success and 4,200 discovered pages is fully compatible with 300 of those pages being indexed and 3,900 not. Nothing on the Sitemaps screen answers the indexing question at all.

Status values you will see in that report:

The indexing answer lives one report over.

This is the walkthrough that most sitemap guides leave out, and it takes about five minutes.

Step one. In Search Console, open Indexing, then Pages. This is the Page indexing report, called Index Coverage in older documentation.

Step two. At the top of the report there is a dropdown that defaults to All known pages. Open it. You can switch to All submitted pages, or select one specific sitemap file by name. Choose your sitemap.

That single click is the whole trick. Every number below now describes only the URLs in that file, rather than every URL the engine has ever encountered on your host, which includes parameter junk, old URLs, and pages you never intended to submit. Site-wide indexing percentages are close to meaningless for that reason. Sitemap-scoped ones are actionable.

Step three. Read the two totals at the top: indexed, and not indexed. Then read the reason table underneath, which groups every unindexed URL by why it was excluded.

Step four. Export. The button is at the top right, and Google Sheets or CSV both work. You get the URL list per reason. Sort by reason, then by path prefix. Patterns show up immediately at that point, because indexing problems are almost always template problems rather than page problems.

Step five. Spot check individual URLs with the URL Inspection tool. Paste a URL into the search bar at the top of Search Console and read four fields:

That last row catches a failure mode people miss for months. A URL can be perfectly crawlable, perfectly submitted, and still never appear as itself because the engine folded it into a near-identical page. The sitemap is not the problem in that case and no amount of resubmitting will change it.

Here is what a healthy read looks like, using example figures for illustration rather than data from any particular site:

Because the Page indexing report can be filtered to a single sitemap file, the way you split your sitemaps decides which questions you're able to answer later. This reframes sitemap segmentation from housekeeping into measurement design, and it's the part almost no guide covers.

One monolithic sitemap.xml gives you exactly one number for the whole site. Split the same URLs by template into an index file with children, and each child becomes a cohort with its own indexing rate.

Example figures again, but the shape is one you will recognize. The blended site-wide rate across those four files is roughly 29%, a number that would send you on a site-wide technical hunt for nothing. The split version diagnoses itself in one glance: two templates are healthy, the location pages have a serious quality problem, and the tag archives should probably not be in a sitemap at all.

Rules for splitting that keep the data usable:

• Split by template or section, never alphabetically or by arbitrary chunk. A cohort is only meaningful if its members share the thing you might change.
• Keep the file names and boundaries stable. If a URL moves between sitemaps every build, week to week comparison is worthless.
• Give any template you suspect its own file, even a small one. That's how you get a rate for it.

Once the cohorts exist, you can run an actual before and after test on a template fix rather than guessing.

• Baseline: record indexed and submitted per sitemap once a week for four weeks before touching anything. You need to see the normal week to week wobble before you can recognize a real move.
• Change window: fix one template only. For the location pages above, that might mean adding genuinely unique content per location and cutting the near-duplicate boilerplate.
• Control: leave a comparable template completely untouched for the whole period. Products or blog would serve here.
• Metric: indexing rate for the changed sitemap, read against the control's rate over the same weeks.
• What counts as signal: the changed cohort moves by more than its own baseline wobble, the control does not move with it, and the move holds across two consecutive weekly readings. A handful of URLs flipping in either direction is normal churn, not a result.
• Timeline: allow weeks, not days. A thousand URL template does not get recrawled overnight, and the recrawl has to happen before the reindex decision can change.

Without split sitemaps none of that is measurable, because a site-wide number moves for a dozen reasons at once. This is the argument for splitting even on sites that are nowhere near the 50,000 URL limit.

Plenty of sitemap generators stamp every URL with the build timestamp. Deploy a CSS change on Tuesday, and the file now claims all 4,000 pages were modified on Tuesday. They were not.

Google has said it uses lastmod only where the value is consistently accurate, and a file that reports every page as freshly changed on every deploy fails that test. The field then gets ignored, and you have thrown away a genuinely useful recrawl hint on a template you could have fixed. Emit the content's real modified date, or leave the element out entirely. Omitting it is better than lying with it.

The last two rows save a recurring argument. Neither element influences anything at Google, and tuning priority values across a site is time with no return.

Group by reason from that export, then apply the response. Most reasons are not faults.

A large share of "not indexed" URLs in a typical report are correct decisions the engine made about pages you never wanted indexed in the first place. Chasing 100% is the wrong target. The right target is that every URL you deliberately submitted is either indexed or has a reason attached that you actively agree with.

A sitemap is a discovery mechanism. It doesn't make a page rank, doesn't compel indexing, doesn't repair thin content, and doesn't override a noindex tag or a robots.txt block. If your pages are being crawled and declined, the file is not where the problem is, and rebuilding it will not help. Broader crawl and index plumbing is covered in what technical SEO actually includes.

There's a limit worth being direct about here, because SparkCliks sells click and traffic services. A page that isn't indexed has no listing, so it collects no impressions and there's no result for anyone to click. Click work such as SERP Clicks applies to pages already ranking and already showing rows in the Performance report. Getting a URL indexed is upstream of all of it, and it's a content, architecture and crawlability job. SparkCliks' own FAQ says it plainly: there are no guarantees in SEO unless you happen to own the search engine, and most sites should get traditional SEO right before reaching for anything else.

Submit the file, scope the report to it, fix what the reasons tell you to fix. That sequence resolves more indexing questions than any amount of resubmitting.