An XML sitemap does not get your pages indexed.

What a sitemap is for

An XML sitemap is a list of URLs on your site, with optional hints about when each last changed. That is the whole thing. It helps Google find URLs it might otherwise take a long time to reach, particularly on a large site, a poorly linked one, or a new one with almost no external links pointing in. Google finds sites by following links, and a sitemap is a shortcut around that for pages the link graph does not reach well.

Three separate decisions sit downstream of that, and the sitemap has no say in any of them. Whether to crawl the URL. Whether, having crawled it, to index it. And where to rank it. Being listed in a sitemap is an invitation, and Google declines invitations constantly, on the same grounds it always uses: is this URL worth the request, and is there anything here worth storing.

Why resubmitting changes nothing

Resubmitting tells Google the same thing it was told last time. If the reason a URL is not indexed is that Google has judged it not worth crawling, or has crawled it and found nothing worth keeping, repeating the announcement does not touch either judgement. It is the sitemap version of pressing the lift button again.

The related habit is bulk Request Indexing in Search Console for a few hundred URLs. That tool exists for nudging a genuinely new or genuinely changed page into the queue, one at a time. Used at volume as a fix for a quality or crawl-allocation decision, it changes nothing and tells you nothing, and the pages come back with the same status a week later.

The lastmod problem

The one field in a sitemap that carries real information is lastmod, and it only works while it is true. Google has been explicit that it uses lastmod when it finds it reliable, and ignores it when it does not. That is a per-site judgement you can lose.

The fastest way to lose it is to stamp every URL with the build time on every deploy, so a hundred pages all claim to have changed the moment you pushed a CSS tweak. The second fastest is a future date, which cannot be true by definition. Once the dates read as machine noise rather than genuine change, the whole field stops being a signal for your domain, including on the pages where it would have been useful. A sitemap with honest per-page dates is worth more than one with fresh dates everywhere, and it is worth deliberately generating it that way.

What actually gets a page indexed

Internal links, first and mostly. A page linked from pages Google already crawls regularly is a page Google has a reason to fetch, and it inherits a sense of importance from where the links come from. A page reachable only from a sitemap is a page nothing on your site is voting for, and that is a signal in itself.

After that: fewer URLs competing for the same crawl allowance, so the budget reaches the pages that matter rather than filter permutations. An external link or two, particularly for a new domain with no signals yet. Removing accidental blocks, remembering that robots.txt controls crawling rather than indexing. And the unglamorous one: the page being worth indexing, which no amount of submitting substitutes for.

So should you have one

Yes. It is cheap, it genuinely helps discovery, and the coverage reporting in Search Console is useful for spotting what Google thinks of a set of URLs. Just hold the right expectation of it: a sitemap is a table of contents you are handing over, not a request, and certainly not a guarantee. When a page will not index, the answer is almost never in the sitemap, and the time spent resubmitting it is time not spent on the reason the page was declined.