Creating and Submitting sitemap.xml to Speed Up Indexing

A sitemap.xml file is a machine-readable list of the URLs on your site. Before writing one, get its role straight: a sitemap is a discovery aid, nothing more. It is not a ranking signal, and submitting one does not guarantee that anything gets indexed. A small site with solid internal linking will usually be crawled fine without one. Where a sitemap genuinely earns its keep is on new sites with no inbound links yet, large sites with thousands of pages, and sites with pages that are hard to reach through navigation — deep archives, detail pages behind filters, and so on.

This guide walks through the whole lifecycle: writing a minimal sitemap by hand, using lastmod in a way Google will actually trust, the 50,000-URL limit and sitemap index files, deciding which URLs belong in the file, and submitting to Google Search Console, Naver Search Advisor, and Bing — then reading the reports afterwards. Before you submit anything, run the file through the sitemap validator to catch XML errors and dead URLs first.

The minimal format: urlset, url, loc — that’s it

A sitemap is a UTF-8 XML file with exactly three required parts: a <urlset> root with the namespace declaration, one <url> entry per page, and a <loc> inside each. For a five-page site, this is a complete, valid sitemap:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-15</lastmod>
  </url>
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2026-03-02</lastmod>
  </url>
  <url>
    <loc>https://example.com/pricing</loc>
    <lastmod>2026-06-28</lastmod>
  </url>
</urlset>

• Every <loc> must be an absolute URL including the protocol. Relative paths like /about are invalid.
• Host the file at the root (https://example.com/sitemap.xml). Per the spec, a sitemap may only list URLs at or below its own directory, so the root is the safe choice.
• Escape XML special characters — an & in a URL must be written as &.
• Skip <priority> and <changefreq>. Google’s documentation states plainly that it ignores both. They don’t hurt, but they’re maintenance weight with zero payoff.

lastmod: real dates or no dates

<lastmod> is the one optional element Google actually uses — as a hint for recrawl prioritization — but only under one condition: it has to be consistently accurate. Google has said outright that when a site’s lastmod values repeatedly contradict what actually changed on the pages, it stops trusting the field for that site entirely.

• Same date on every URL: the classic mistake of stamping the sitemap generation time onto everything. That claims every page changed today, and the trust is gone immediately.
• Current time on every request: dynamically generated sitemaps that emit now() are the fastest way to get lastmod ignored.
• The right value: the date the page’s meaningful content last changed — wire it to your CMS’s modified date or the file’s real update time. Fixing a typo doesn’t need to bump it.
• If you can’t produce truthful dates, omit lastmod entirely. A missing date is better than a wrong one.

The format is W3C Datetime: a bare date (2026-07-15) is fine, or include a time with an explicit timezone, e.g. 2026-07-15T09:30:00+09:00.

What goes in, what stays out, and the 50k limit

One rule covers it all: list only canonical, indexable URLs that return 200and that you want in search results. A sitemap is your declaration of “these are my site’s real pages” — pollute it and you waste crawl budget and turn your Search Console reports into noise.

The limits are 50,000 URLs or 50MB uncompressed per file. Past that, split into multiple sitemaps and tie them together with a sitemap index — then submit only the index. You can gzip the files (sitemap.xml.gz) to save bandwidth, but the 50MB cap applies to the uncompressed size.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>

How you generate the file depends on scale. Most frameworks and CMSs — Next.js, Astro, WordPress via Yoast or RankMath — produce sitemaps automatically; your only job there is verifying that lastmod tracks real modification dates. A hand-written file like the one above is perfectly fine for a static site with a few dozen pages, or you can emit one from a build script. Either way, once it’s live, point the sitemap validator at it to check XML parsing, absolute URLs, and whether any listed URLs redirect or 404.

Submitting: Search Console, Naver, Bing, plus one robots.txt line

1. Google Search Console: pick your property, go to Indexing → Sitemaps, enter the sitemap URL, submit. Expect hours to days before the status flips to “Success” and a discovered-pages count appears.
2. Naver Search Advisor: Webmaster Tools → Requests → Submit sitemap. Essential if you want Korean search traffic; Naver typically processes sitemaps more slowly than Google, so check back weekly.
3. Bing Webmaster Tools: submit under the Sitemaps section. If you import your property from Search Console, Bing often picks the sitemap up along with it.
4. Declare it in robots.txt: the single line below lets every crawler find your sitemap without any manual submission. The value must be an absolute URL.

Sitemap: https://example.com/sitemap.xml

If you don’t have a robots.txt yet, the robots.txt generator will build one with the Sitemap line included. After deploying, use the robots.txt checker to make sure none of the paths in your sitemap are accidentally caught by a Disallow rule — a URL that appears in the sitemap but is blocked by robots.txt is a self-contradiction Search Console will flag as an error.

Worked example: an 8-page site, one week after submission

Take a portfolio site with 8 pages. You write sitemap.xml by hand using the minimal format above, upload it to the root, add the Sitemap line to robots.txt, and submit in Search Console. A week later the report reads:

The question is whether the 8-discovered vs 5-indexed gapis healthy. Open the Page indexing report, filter by your sitemap, and read the exclusion reasons. “Crawled — currently not indexed” is a quality/duplication judgment call — common for thin pages, and fixed by strengthening content and internal links, not by resubmitting the sitemap. But if you see “Page with redirect” or “Excluded by noindex”, those URLs never belonged in the sitemap and you should remove or replace them. The gap always mixes two causes — Google’s editorial judgment and defects in your own sitemap — and the second kind is entirely yours to eliminate.