XML sitemaps that actually help: format, size limits and common errors

An XML sitemap is a list of the URLs you want search engines to know about. It does not make pages rank and it does not force indexing, but it helps crawlers discover new and updated pages faster, especially on large sites, new sites with few links, and sites whose deep pages are hard to reach by clicking. A broken or misleading sitemap, on the other hand, wastes crawl effort and sends mixed signals. Here is what a sitemap that actually helps looks like.

The minimal valid file

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/</loc>
  </url>
  <url>
    <loc>https://www.example.com/guides/blue-widgets</loc>
    <lastmod>2026-10-28</lastmod>
  </url>
</urlset>

Only <loc> is required. Google has said it ignores <priority> and <changefreq>, so there is no benefit in fine-tuning them. <lastmod> is used, but only if it is trustworthy (more on that below).

Size limits and sitemap indexes

One sitemap file may contain at most 50,000 URLs and be at most 50 MB uncompressed. Gzip compression is allowed for transfer, but the 50 MB limit applies to the uncompressed size. Larger sites split the list into several files and publish a sitemap index:

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

Splitting by content type (products, categories, articles) has a practical bonus: Search Console reports indexing per submitted sitemap, so you can see at a glance that, say, 95% of articles are indexed but only 40% of products.

What belongs in the sitemap

List only URLs that you want indexed and that are indexable. In practice that means each URL:

• returns 200 directly, not a redirect and not a 404;
• is the canonical version, the same URL the page declares in its canonical tag (see canonical tags);
• is not blocked by robots.txt and does not carry noindex;
• uses the main protocol and host, for example https://www. if that is your choice.

Listing redirecting or non-canonical URLs is not fatal, but it contradicts your other signals and makes the Search Console sitemap report noisy. A common source of junk is a CMS that includes tag pages, author archives, attachment pages or internal search results by default. Decide whether those deserve to be indexed; if not, remove them from the sitemap and stop linking to them prominently.

lastmod: only if it is honest

Google has stated it uses <lastmod> when it is consistently accurate. "Accurate" means it changes when the main content of the page changes. Two common patterns ruin it:

• Every URL gets today's date because the sitemap is generated on the fly with the current time.
• The date changes when a sidebar widget, a footer year or a comment count changes.

Once a crawler learns that your lastmod values do not mean anything, it can ignore them. Use the real modification date of the content, in W3C format (2026-10-28 or 2026-10-28T14:05:00+00:00), or leave the tag out.

Making the sitemap discoverable

1. Declare it in robots.txt, on its own line, with an absolute URL:

   Sitemap: https://www.example.com/sitemap_index.xml

   This line is read by every major search engine, not only Google, and can appear anywhere in the file.
2. Submit it in Search Console under Sitemaps, then check the status a day later. "Couldn't fetch" usually means a wrong URL, a firewall blocking Googlebot, or a 5xx.
3. Keep it at a stable address. Moving the sitemap without updating robots.txt and Search Console leaves crawlers fetching a dead URL.

The errors that show up most

Not valid XML

The parser stops at the first error, so one bad character can invalidate a file of 40,000 URLs. Usual causes:

• An unescaped ampersand in a URL. Inside XML, ?color=red&size=9 must be written as ?color=red&size=9. The same applies to <, >, and quotes inside attribute values.
• Whitespace, a blank line or a byte-order mark (BOM) before <?xml. This often comes from a PHP file with a stray newline before the opening tag, or an editor saving "UTF-8 with BOM".
• A PHP warning or notice printed into the output by the generator.

Open the sitemap URL directly in a browser: most browsers point to the line and column of the first error.

Served as HTML

Some setups return the site's normal 404 page, or a login page, with status 200 at the sitemap URL. Check that the response Content-Type is application/xml or text/xml and that the body starts with the XML declaration.

URLs on the wrong host

Sitemap URLs should be on the same host as the sitemap (cross-host sitemaps are possible but need extra verification). Leftovers from a migration — http:// URLs, the old domain, a staging host — are common. Image sitemap entries count too: if your product images live on a separate CDN domain, <image:loc> entries pointing there are legitimate for images, but checkers that test host consistency, including DeskSEO's, will flag them, so read that warning in context.

Empty sitemap or broken child files

A sitemap index whose child files return 404, or an empty <urlset> after a plugin update, looks fine at the top level and silently lists nothing. Open at least one child file after every CMS or plugin upgrade.

How DeskSEO checks it

The SEO checker looks for a Sitemap line in robots.txt, then tries /sitemap.xml and /sitemap_index.xml. It parses the file, follows a sitemap index into its child files within a time budget, counts URLs, and reports: no sitemap found, invalid XML, no URLs, URLs on another host or on http, broken child sitemaps, and a robots.txt without a Sitemap line. Each item links to the fix. To see how these weigh in the score, read how scoring works.