XML Sitemaps: How to Create, Validate and Submit One

You migrate a site, publish forty new pages, and three weeks later a site: search turns up twelve of them. Nothing is broken. The pages load, they are linked from somewhere, they are not blocked. Google simply has not got around to them yet.

An XML sitemap is the fix for exactly that problem — and only that problem. Here is how to build one properly, what the fields really do, and where people quietly break theirs.

What a sitemap is (and what it is not)

An XML sitemap is a machine-readable list of the URLs on your site that you want search engines to know about, plus a little metadata about each one.

It is a discovery aid. It says “these pages exist, here they are in one place, and here is when they last changed.”

It is not:

• A ranking boost. Being in a sitemap does not make a page rank better.
• A guarantee of indexing. Search engines decide what to index; a sitemap only makes the candidate list easier to find.
• A substitute for internal linking. If a page is reachable only via the sitemap, that itself is a signal about how important the page is.

Who actually needs one most

Every site can have one, but the benefit varies enormously:

• Large sites. Thousands of URLs, deep hierarchies, pagination — crawlers will not exhaustively wander it all.
• Brand-new sites with few backlinks. Nobody is linking to you yet, so external discovery paths barely exist.
• Sites with weak internal linking. Orphan pages, JavaScript-driven navigation, or content only reachable through search forms.
• Sites with lots of media or fast-changing content. News, listings, large image or video libraries.

A tidy 15-page brochure site with a normal nav menu will do fine either way. Add one anyway — it costs nothing — but do not expect it to change much.

The structure

A sitemap is XML with a fixed shape. One <urlset> root, one <url> block per page, one <loc> inside each:

<?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-02</lastmod>
  </url>
  <url>
    <loc>https://example.com/tools/image-compressor</loc>
    <lastmod>2026-06-18</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

Only <loc> is required. The rest are optional — and they are not equally useful.

The optional fields, honestly

lastmod is the one worth getting right. Google has said it uses lastmod when the value is consistently accurate, and ignores it when it is not. Sites that stamp today’s date on every URL at every build train crawlers to distrust the field entirely. Emit the real last-modified date of the content, or leave it out.

changefreq is largely ignored by the major engines. It was always a hint, and it turned out that pages claiming hourly mostly did not change hourly.

priority is also largely ignored. Its value is relative within your own site, it never competed against other domains, and in practice most sites either set everything to 1.0 or forget about it.

The short version: spend your effort on an accurate URL list and honest lastmod values. The other two fields are harmless but not worth agonizing over.

The rules that break sitemaps most often

• Use absolute URLs. https://example.com/about, never /about.
• Stick to one host and protocol. All URLs must be on the same site as the sitemap, matching the exact scheme and subdomain (https://www. is a different host from https://).
• List canonical URLs only. No tracking parameters, no session IDs, no ?sort=price duplicates.
• No redirects, no noindex, no 404s. Every URL should return 200 and be indexable. Listing a page you have told Google not to index is a contradictory signal.
• Escape special characters. In XML, & must be written &, and <, >, ", ' have entities too. A raw ampersand in a query string is the single most common cause of a sitemap that will not parse.
• Use UTF-8.

Size limits and sitemap index files

A single sitemap file may contain at most 50,000 URLs and must be no larger than 50 MB uncompressed. Files may be gzipped (sitemap.xml.gz); the 50 MB limit applies to the uncompressed size.

Past either limit, split into multiple files and list them in a sitemap index:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-07-02</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-07-10</lastmod>
  </sitemap>
</sitemapindex>

Splitting by content type rather than arbitrarily is worth doing even well below the limit — it makes coverage reporting far easier to read when you can see that blog URLs are indexed and product URLs are not.

To build the file itself, the Sitemap Generator turns a list of URLs into valid XML without you hand-writing the boilerplate.

Tell crawlers where it is

Two steps, and you want both.

1. Reference it from robots.txt. Any crawler that reads your robots.txt then knows where to look — including engines you never signed up with:

User-agent: *
Allow: /

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

The Sitemap directive uses an absolute URL and is independent of the User-agent groups above it. If you do not have a robots.txt yet, the Robots.txt Generator will build one with the sitemap line included.

2. Submit it in Google Search Console. Open your property, go to the Sitemaps report, enter the path (sitemap.xml), and submit. Bing Webmaster Tools has an equivalent. The real payoff is the per-sitemap coverage reporting you get afterwards, which tells you how many of the URLs you declared actually got indexed.

Validate before you submit

Submitting a malformed sitemap wastes a crawl and can leave a persistent error in your reports. Check before you push:

• Does it parse as XML at all? One unescaped & will break the whole file.
• Are all URLs absolute, same-host, and returning 200?
• Is the URL count under 50,000 and the file under 50 MB?
• Do the lastmod values reflect reality?

Run the file through the Sitemap Validator to catch structural problems, then spot-check a handful of URLs by hand.

Quick answers

Will a sitemap improve my rankings? No. It helps pages get discovered; it does not affect how they rank once found.

Where should the file live? Conventionally at /sitemap.xml in the site root. A sitemap can only cover URLs at or below its own path, so the root is the safe place.

Do I need one if my site is small and well-linked? Not really, but it is cheap to add and gives you useful coverage reporting.

Should I include images and PDFs? Indexable PDFs, yes. Images have their own sitemap extension, worth it only for image-heavy sites.

How often should I regenerate it? Whenever content changes — ideally automatically as part of your build. A stale sitemap is worse than none if it lists URLs that no longer exist.

The takeaway

A sitemap is a directory, not a promotion. Keep it to canonical, live, indexable URLs, keep lastmod honest, split it once it gets large, reference it from robots.txt, and validate before submitting. Do that and discovery stops being a variable — which frees your attention for the things that actually move rankings.