What Is XML Sitemap?

How XML Sitemap Works

An XML sitemap is a plain text file, written in XML, that a search engine reads to learn which pages on your site you consider worth crawling. When a crawler like Googlebot fetches the file, it parses each listed URL and adds it to the queue of pages it may visit. The sitemap does not push content into the index; it feeds the discovery stage that comes before crawling and indexation.

The file follows the sitemaps.org protocol, currently version 0.9, which both Google and Bing support. At its root is a <urlset> element declaring the namespace http://www.sitemaps.org/schemas/sitemap/0.9, and inside it sits one <url> block per page. Only the <loc> element — the fully qualified URL, beginning with the protocol — is required. Everything else is optional metadata.

A sitemap matters most in the cases where internal links alone are not enough. Google’s own guidance is that a large site, a brand-new site with few inbound links, or a site heavy with video, images, or news content benefits from a sitemap, because those pages are otherwise hard to find. For a small, well-linked site, Google is explicit that you may not need one at all.

Format and Size Limits

Each <url> entry can carry up to four child elements:

• <loc> — the page URL. Required. Must be absolute and properly entity-escaped.
• <lastmod> — the last modification date, in W3C datetime format (the YYYY-MM-DD shorthand is allowed). Google does use this when it is accurate and trustworthy.
• <changefreq> — a hint about update frequency (always through never). Google ignores it.
• <priority> — a relative importance value from 0.0 to 1.0, defaulting to 0.5. Google ignores it too.

The hard limits come from the protocol and are strict: a single sitemap file may list no more than 50,000 URLs and must be no larger than 50MB (52,428,800 bytes) uncompressed. Files may be gzip-compressed to save bandwidth, but the 50MB ceiling applies to the uncompressed size. When a site outgrows either limit, you break the URLs across multiple sitemap files and reference all of them from a sitemap index — itself a <sitemapindex> file that may point to at most 50,000 sitemaps under the same 50MB cap. All files must be UTF-8 encoded.

Example of XML Sitemap

Take the protocol’s own documented rules as the worked case, because they are the numbers every real sitemap is built against. Suppose an e-commerce site has 120,000 product URLs. A single sitemap cannot hold them — the sitemaps.org protocol caps one file at 50,000 URLs and 50MB. So the site generates three sitemap files (say 50,000 + 50,000 + 20,000 URLs) and a fourth file, a sitemap index, whose <sitemapindex> element lists the location and <lastmod> of each of the three.

Each product entry needs only its <loc>. If the team adds <lastmod> values, they must be truthful — a stale or auto-faked “modified today on every page” pattern trains Google to distrust the field, and Google has said it leans on <lastmod> only when it looks reliable. Adding <priority>0.9</priority> to the bestsellers does nothing: Google ignores <priority> and <changefreq> entirely, a point confirmed in its sitemap documentation and repeated by its search team for years.

The instructive part is what the sitemap does not do. If 8,000 of those 120,000 products are out of stock and return a noindex tag, leaving them in the sitemap is a mistake — the site is asking Google to crawl pages it has already told Google not to index. The correct sitemap lists only the roughly 112,000 canonical, indexable, 200-status product URLs. That is the difference between a sitemap that accelerates discovery and one that burns crawl budget on dead ends.

Submitting and Maintaining a Sitemap

Building the file is only half the job; a search engine still has to find it. There are three standard ways to make a sitemap discoverable. You can submit it directly in Google Search Console’s Sitemaps report, which also surfaces parsing errors and how many URLs Google read. You can reference it in your robots.txt with a Sitemap: line, which any crawler that reads robots.txt will pick up. And for very large or frequently changing catalogs, dynamic generation keeps the file in sync with the CMS so new URLs appear automatically and removed ones drop out.

Maintenance is where most sitemaps quietly rot. A sitemap generated once and never revised drifts out of alignment with the site — it keeps listing pages that now redirect, 404, or carry a noindex, and it misses pages added since. Because Google reads <lastmod> only when the dates look trustworthy, an automated feed that stamps every URL with today’s date teaches Google to disregard the field entirely. A healthy sitemap is regenerated as the site changes and contains only live, canonical, indexable URLs — the same discipline that makes it worth submitting in the first place.

XML Sitemap vs HTML Sitemap

Both are called “sitemaps,” but they solve different problems. An HTML sitemap is a page a person can click through and a secondary way for crawlers to find links; an XML sitemap is a structured feed built for machines. A large site often uses both — the XML file for efficient discovery, the HTML page for users and as backup internal linking.

Frequently Asked Questions

The Bottom Line

An XML sitemap is the curated address book you hand a search engine: a protocol-standard file naming the URLs worth crawling, with optional freshness hints attached. It speeds discovery on large or thinly linked sites, but it never overrides quality signals — so its value comes entirely from being accurate. List only the canonical, indexable pages you actually want found.