XML Sitemap Best Practices

On this page: Quick jump links to help you

• What an XML sitemap is — and what it is not
• Why XML sitemaps matter for SEO
• Structure, format and the limits that bind
• What to include in your sitemap
• What to exclude from your sitemap
• Sitemap index files for large sites
• Image sitemaps, video sitemaps and extensions
• How to optimize an XML sitemap
• Submitting a sitemap to Google
• Submitting a sitemap to Bing and other engines
• Common mistakes and sitemap errors
• How to validate an XML sitemap
• XML sitemaps and AI crawlers
• XML sitemap best practices: FAQs

Most sitemap advice fails in the same way: it describes every element the protocol allows and implies each one is worth tuning. Two of them are not. Google ignores <priority> and <changefreq>, and has said so in its own documentation for years — yet guides still recommend adjusting them. This page follows the sitemaps protocol and Google's current published guidance, and says explicitly where the two diverge.

An XML sitemap is a machine-readable list of the URLs you want indexed. It is a discovery aid and nothing more. It will not make a weak page rank, and submitting one is, in Google's own words, "merely a hint". What a good sitemap does is remove ambiguity — and give you a measurement you would not otherwise have.

What an XML Sitemap Is — and What It Is Not

An XML sitemap is a file, usually at /sitemap.xml, that lists URLs from your site along with optional metadata. It follows the format defined by the sitemaps protocol. Google also accepts RSS, mRSS and Atom 1.0 feeds, and plain-text files containing one URL per line, and states no preference between formats. XML is the most capable of them because it is the only format that can also carry image, video, news and localized-version data.

A minimal, correct XML sitemap looks like this:

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

Note what is absent. There is no <priority> and no <changefreq>, and the file is not worse for it.

The four elements, and the two Google ignores

Each <url> entry may contain four child elements. Only one matters unconditionally:

• <loc> — required. The fully-qualified, absolute URL, correctly entity-escaped. Google crawls the URL exactly as listed, so a relative path such as /page.html is not valid.
• <lastmod> — optional, and the one worth getting right. W3C datetime format. Google uses it if the value is consistently and verifiably accurate — it can check the date against the page. It should reflect the last significant update: a change to the main content, the structured data or the links. Bumping a copyright year does not count.
• <changefreq> — ignored by Google.
• <priority> — ignored by Google.

The last two are worth being blunt about, because acting on them wastes real time. <priority> was meant to rank your own URLs against each other, and <changefreq> to hint at update cadence. Both were abused so widely — most sites simply set every page to 1.0 — that the signal became worthless. If your generator emits them, leaving the defaults is harmless. Tuning them buys nothing, and any guide telling you to raise priority for pages you care about is describing a system that no longer exists.

What a sitemap cannot do

A sitemap does not force indexing. It does not override robots.txt or a noindex directive — where they conflict, the directive wins and the sitemap entry is simply noise. It carries no ranking weight. And it is not a substitute for internal links: a URL reachable only from your sitemap is a URL you have told Google matters while structurally signalling that it does not. Sitemaps are also optional. A small, well-linked site can be crawled perfectly well without one.

Why XML Sitemaps Matter for SEO

The honest case for XML sitemap SEO is narrower than most guides claim, but it is real, and it is strongest in four situations. None of them is a ranking mechanism: a sitemap is one of the smaller levers in technical SEO, and if you want the wider picture of where crawling and indexing sit, start with what SEO actually is.

Discovery on large or poorly linked sites

Googlebot finds pages primarily by following links. Where your internal linking is thin — deep archives, orphaned landing pages, content buried under faceted navigation — a sitemap is the only reliable way for a URL to be discovered. This is why sitemaps matter far more on a 50,000-URL store than on a 40-page brochure site. It is also why fixing internal linking usually beats fixing the sitemap.

Faster discovery of new and updated content

A trustworthy <lastmod> tells Google which URLs changed since it last looked. On a site that publishes daily, that is the difference between recrawl within hours and recrawl whenever Google gets round to it. The value comes entirely from the timestamp being honest — which is why faking it is self-defeating rather than clever.

Crawl budget efficiency

Google allocates finite crawling to any site. A sitemap listing 200,000 URLs of which 60,000 redirect or 404 spends that allocation on dead ends. A clean list spends it on pages that can actually rank. Crawl budget only becomes a live constraint at scale — see our guide to crawl budget for when it genuinely applies to you.

Media and localized versions

XML is the only sitemap format that can carry extension data. Image, video and news namespaces let you declare media that regular crawling might miss — video loaded by JavaScript, for example. You can also declare localized versions using xhtml:link rel="alternate" hreflang="…" elements inside each <url> entry, which is often easier to maintain than page-level hreflang tags across a large multilingual site.

XML Sitemap Structure, Format and the Limits That Bind

Four constraints do real work. Everything else is detail.

Size limits: 50,000 URLs and 50 MB

Every sitemap format is limited to 50,000 URLs or 50 MB uncompressed, whichever you hit first. Note that the size limit binds independently — a sitemap carrying long URLs and extensive image data can exceed 50 MB well before 50,000 entries. Past either limit you must split the file. Gzip compression is permitted and reduces transfer size, but the 50 MB limit applies to the uncompressed file.

Encoding, escaping and absolute URLs

The file must be UTF-8 encoded. All tag values must be entity-escaped — an unescaped ampersand in a URL is the single most common cause of a sitemap that fails to parse, and Google will report a processing error rather than indexing part of the file. Use absolute URLs including the protocol, and use the same protocol and hostname your canonical tags use. A sitemap listing http:// URLs on an HTTPS site, or bare-domain URLs on a www site, is describing pages that redirect.

Where to host your sitemap

This constraint is widely missed. A sitemap only affects URLs that are descendants of its own parent directory. A sitemap at /blog/sitemap.xml can therefore only vouch for URLs under /blog/. Hosting at the site root is what lets a sitemap cover the whole site, which is why /sitemap.xml is the recommended location. Submitting through Search Console lifts this restriction, but root-hosting costs nothing and removes the trap.

One sitemap or several

Splitting is not only for sites over the limit. Search Console reports indexing per submitted sitemap, so a site that splits by content type — products, collections, articles, static pages — can read the indexed-versus-submitted ratio for each section separately. A single 30,000-URL file gives you one number. Five segmented files give you five, and the one that is underperforming tells you where the problem is.

What to Include in Your Sitemap

The rule is one sentence: include the canonical URL of every page you want to appear in search results, and nothing else.

In practice, that means your indexable content pages — service and product pages, category and collection pages, articles, documentation, key landing pages — each listed once, in its canonical form. Where the same content is reachable at several URLs, pick the one you want ranked and list only that. If you maintain separate mobile and desktop URLs, point to one version.

Two categories deserve particular attention because they are the ones that benefit most. First, deep pages with few internal links: these are the URLs a sitemap genuinely rescues. Second, recently and substantially updated pages, where an accurate <lastmod> prompts a recrawl. Pages that are already well-linked from your homepage and hub pages will be found regardless — including them is correct, but it is not what the sitemap is doing for you.

What to Exclude from Your Sitemap

Exclusion is where most of the value sits. Every URL in the list that you are not actually asking Google to index weakens the file as a signal.

Anything blocked or noindexed

Pages disallowed in robots.txt and pages carrying a noindex directive should never appear. Both create a direct contradiction: you are submitting a URL as index-worthy while separately instructing Google not to index it. The directive wins, so nothing breaks — but the contradiction is a reliable marker of an unmaintained sitemap. Our guide to robots.txt vs meta robots covers which directive applies where.

Redirects, 404s and non-canonical duplicates

A 3xx URL makes Googlebot take an unnecessary hop. A 404 or 410 wastes the crawl entirely. A non-canonical duplicate asks Google to resolve a conflict you could have resolved yourself. Remove all three, and use canonical tags to designate the preferred version of anything genuinely duplicated.

Parameter, session and sort variants

URLs carrying session IDs, tracking parameters, or filter and sort parameters generate near-infinite duplicates. List the clean canonical URL only. Where filtered or re-sorted views need suppressing at scale, Google's guidance is to noindex them or discourage crawling of the pattern in robots.txt — not to manage the problem through the sitemap.

Pagination — and a correction worth noting

Paginated URLs generally do not belong in a sitemap: they are not landing pages and rarely earn links. But the surrounding advice has aged badly, and two claims still in wide circulation are now wrong.

The first is rel="next" and rel="prev". Google used these to identify sequence relationships and no longer uses them. Other search engines may, so they are not harmful — but they will not do anything for you at Google, and any guide presenting them as a current requirement is out of date.

The second is the idea that infinite scroll is the modern replacement for pagination. Google's own guidance lists infinite scroll's drawbacks — unclear result size, poor handling of very large sets — and is explicit that its crawlers do not click buttons or trigger user-driven JavaScript. If content only appears on scroll and has no crawlable URL, Google will not see it. Where you do paginate, Google's current recommendations are to give each page its own unique URL, link pages sequentially with real <a href> elements, give each page its own canonical rather than canonicalising everything to page one, and avoid using URL fragments for page numbers.

Utility and private pages

Thank-you pages, cart and checkout steps, password resets, internal search results, admin areas and anything behind authentication should all be left out. None are meant for search visibility, and pages Google cannot reach only add noise.

Sitemap Index Files for Large Sites

When a single file would exceed 50,000 URLs or 50 MB, you must split it. A sitemap index is the optional — and almost always sensible — way to manage the result: one file that references the others, so you submit a single URL and Google follows the references.

<?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.xml</loc>
    <lastmod>2026-08-11</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap-articles.xml</loc>
    <lastmod>2026-08-09</lastmod>
  </sitemap>
</sitemapindex>

A sitemap index may itself reference up to 50,000 sitemaps, a ceiling no real site approaches. You can also submit several sitemaps or several index files rather than one — useful precisely because it splits the Search Console reporting.

Segment along lines that mean something operationally: content type, publication date, language, or site section. A sitemap index organised by content type turns an abstract indexing problem into a specific one — "our product sitemap is at 40% indexed and our article sitemap is at 95%" is an actionable sentence in a way that a single site-wide percentage never is.

Image Sitemaps, Video Sitemaps and Other Extensions

The Sitemap protocol has extensions, and they are the part of the standard most sites never use. An image sitemap and a video sitemap are not separate file formats — they are extra namespaced elements you add inside the ordinary <url> entries you already have.

The image sitemap extension

An image sitemap declares images Google might not otherwise find — the common case being images loaded by JavaScript, or served from a separate host your HTML does not expose as a plain link. Google's documentation defines the <image:image> element with <image:loc> for the image URL, and allows up to 1,000 images per <url> entry. You can add these elements to your existing file or publish a dedicated image sitemap; both are supported.

The video sitemap extension

A video sitemap carries the metadata a video result needs — thumbnail, title, description, duration, and the player or content location. Google documents it as an extension to the Sitemap protocol and names mRSS feeds as the supported alternative. The practical case for a video sitemap is the same as for images: content that ordinary crawling will miss, such as video injected by a script or embedded through a player.

Combining extensions in one file

Extensions are not mutually exclusive. A single <url> entry may carry image, video and news elements at once, which is the normal shape for an article page with a lead image and an embedded clip. Splitting them into separate files is a reporting decision, not a requirement — the same argument as splitting any sitemap: keep each file narrow enough that its indexing numbers mean something.

One caution worth stating plainly, because the extensions invite the opposite reading: they describe content, they do not promote it. Declaring a video does not make it rank. It makes the video discoverable, which is a precondition for ranking and nothing more. Extensions sit alongside the core XML sitemap best practices rather than substituting for any of them — an image sitemap over a file full of redirects still describes a mess.

How to Optimize an XML Sitemap

Three moves optimize XML sitemap performance, and they are worth more than every other adjustment combined. This is effectively the whole of practical XML sitemap SEO — the rest of the protocol is description, not leverage.

Trim it to canonical, indexable URLs

Export the full URL list, check every entry's status code and canonical, and remove anything that is not a self-canonical 200. On a neglected site this alone commonly removes 10–30% of entries. The point is not tidiness: a list Google can trust is a list Google will keep coming back to.

Make lastmod trustworthy

Pull the value from a genuine content-modified timestamp in your CMS, not from the current date and not from a template rebuild. Google verifies lastmod against the page, and it may disregard values it judges unreliable — which means a generator that stamps today's date on every URL costs you the signal for the whole site, not just for the pages it lied about. This is the most commonly self-inflicted sitemap problem we see.

Split it so the data is readable

Segment by content type or date even when you are nowhere near the size limit, purely for the reporting. Diagnosis is the sitemap's underrated function, and segmentation is what makes it possible. If you only ever optimize XML sitemap structure in one way, make it this one — it costs an afternoon and it changes what you can see.

Notice what is not on this list: adjusting priority values, tuning change frequencies, or adding every URL you can find. None of those do anything.

Static versus dynamic sitemap generation

Everything above assumes the file reflects the site as it is today, and that assumption is what dynamic sitemap generation buys you. A static sitemap is a file someone produced once, usually with a desktop crawler, usually months ago. A dynamically generated sitemap is built from the same content model as the site itself, so a page published, unpublished or redirected at 09:00 is correct in the file by 09:01.

Most platforms already do this: Shopify, WordPress and the mainstream frameworks emit a sitemap from live content rather than a stored copy — our guide to Shopify SEO covers the platform-specific case. The failure mode is nearly always a hand-maintained file, or a crawler-generated one running on a slower schedule than the publishing cadence. If you cannot say when your sitemap was last built and from what, treat it as static whatever produced it.

Dynamic generation is also the only practical way to keep <lastmod> honest, because the timestamp then comes from a real content-change event instead of a build step. That is the same discipline described in content freshness, applied to a machine-readable file.

Submitting a Sitemap to Google

Submitting sitemap to Google can be done four ways, and they are complementary rather than alternatives.

Search Console

The Sitemaps report under Indexing is the primary route. Enter the path — sitemap.xml or your index file — and submit. You will then see when Googlebot last fetched it, any processing errors, and the number of discovered URLs. This is also the only route that lifts the parent-directory restriction described above.

robots.txt

Add a Sitemap: directive anywhere in the file, using an absolute URL:

User-agent: *
Disallow: /admin/

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

The directive applies to all crawlers regardless of which User-agent block it sits in, and you can list as many sitemap lines as you need. This is passive discovery and works for search engines and other crawlers alike.

The Search Console API and WebSub

The Search Console API lets you submit sitemaps programmatically, which is worth wiring into a deployment pipeline. If you publish an RSS or Atom feed, WebSub can broadcast changes to subscribing search engines including Google.

Cross-submitting for multiple sites

If you run several verified properties, you can host one sitemap covering URLs across multiple domains, or keep per-site sitemaps in one central location. Both work provided ownership of every site is verified in Search Console, or each site's own robots.txt references its sitemap. This turns sitemap maintenance for a portfolio into a single job.

What to monitor afterwards

Submission is a hint, not a command — Google does not guarantee it will fetch or use the file. So read the report rather than assuming. Status should be Success. Then compare submitted URLs against indexed URLs in the Pages report, filtered by "Submitted in sitemap". A persistent gap is rarely a sitemap fault: it usually points at thin or duplicated content, canonical conflicts, or weak internal linking. Our guide to Google Search Console indexing statuses explains how to read each state, and indexation covers the underlying mechanics.

Submitting a Sitemap to Bing and Other Search Engines

Google is not the only crawler reading the file, and submitting a sitemap to Bing takes about the same minute that submitting to Google does. It matters more than it once did: Bing's index also feeds several AI assistants, so a file Bing cannot see is content those assistants cannot cite. The XML sitemap best practices in this guide are engine-agnostic: one clean, canonical, current file serves every crawler that reads it, and only the submission step differs.

Bing Webmaster Tools

Submit through the Sitemaps section of Bing Webmaster Tools, exactly as you would in Search Console. Documented, versus widely believed: the anonymous submission endpoint no longer exists. Bing removed anonymous sitemap submission in 2022, so a verified account is now required. Guidance telling you to ping a URL to notify an engine is out of date on both sides — Google announced the deprecation of its own sitemap ping endpoint in June 2023, and requests to it now return 404.

One robots.txt line covers every crawler

The Sitemap: directive in robots.txt is engine-agnostic. One absolute URL there is discoverable by Bing, by Yandex, and by any AI crawler that reads the file — which is why it belongs in the setup even when you have submitted through both consoles. It costs one line, it needs no account, and it does not go stale.

IndexNow for immediate notification

Where a sitemap says here is everything, IndexNow says this specific URL just changed. It is an open protocol supported by Bing and several other engines: you host a key file and issue one HTTP request per changed URL. It complements a sitemap rather than replacing it — IndexNow for speed on individual changes, the sitemap for completeness — and Google has not adopted it, so it is an addition to your Google setup rather than a substitute for anything in it.

Common XML Sitemap Mistakes and Sitemap Errors

Nearly every sitemap problem we encounter is one of these nine. The first group produces visible sitemap errors in Search Console; the second group produces no error at all, which is what makes them expensive.

1. Invalid XML. An unescaped ampersand, a byte-order mark, an unclosed tag. The file fails to parse and Google indexes nothing from it. This is the most abrupt of the sitemap errors, and the easiest to catch.
2. An inaccessible sitemap URL. A 403, 404 or 500 on the sitemap itself, or a Disallow rule blocking it. Blocking your own sitemap in robots.txt is a genuinely common configuration mistake, usually inherited from a staging environment.
3. Redirected URLs in the list. Every entry costs a hop and signals that the file is stale.
4. 404 and 410 URLs in the list. Straight crawl-budget waste, and at volume it erodes trust in the file.
5. Noindexed or robots-blocked URLs in the list. A contradiction Google resolves against you.
6. Fake or static lastmod dates. The silent one. Nothing errors; the timestamp is simply disregarded, and you lose a signal you thought you had.
7. Relative or protocol-mismatched URLs. Relative paths are invalid. http:// entries on an HTTPS site, or non-www entries on a www site, describe redirects.
8. Paginated, filtered and parameterised URLs. These inflate the file with pages that were never going to rank.
9. A sitemap nobody regenerates. Every one of the above is really a symptom of this. A hand-maintained sitemap is stale within days.

How to Validate an XML Sitemap

Every rule above fails quietly. Validation is what turns XML sitemap best practices from intentions into something you can evidence, and it belongs on a schedule rather than only after a migration.

The Search Console Sitemaps report

The authoritative check, because it reports what Google did with the file rather than what the file contains. Read the processing status, the discovered-URL count, and the submitted-versus-indexed gap. Anything other than Success needs investigating before you look anywhere else.

Status-code and canonical checks

Pull the URL list and check every entry's HTTP status and canonical in bulk. A crawler such as Screaming Frog will cross-reference the sitemap against a live crawl and surface mismatches directly, including orphan URLs — entries nothing on the site links to. See crawlability for why those matter.

XML syntax validation

Run the file through an XML validator after any change to the generator, and confirm the sitemap URL is reachable while logged out and not disallowed in robots.txt.

Put it on a schedule

Sitemaps rot the way redirects rot: gradually, then all at once during a migration. A quarterly pass over status codes, canonicals and the indexed gap catches drift before it compounds. If you would rather that sweep ran continuously against a documented checklist, that is the work our technical SEO service performs.

XML Sitemaps and AI Crawlers

Sitemap conventions were written for search crawlers, but the same file is now read by the crawlers behind AI answers and assistants. OpenAI's GPTBot, Anthropic's ClaudeBot, PerplexityBot, Google-Extended and CCBot discover content the same way Googlebot does — robots.txt and the sitemap it points to — which makes XML sitemap best practices part of your generative engine optimization surface too.

What AI crawlers take from a sitemap

The same two things a search crawler takes: which URLs you consider canonical, and which changed recently. There is no separate AI sitemap to build. A file padded with redirects and parameter variants gives an AI crawler exactly the confused picture it gives Google, and the clean-list discipline above is the entire intervention.

Controlling AI crawler access

Access is governed by user-agent in robots.txt, not by the sitemap. You can allow search indexing while disallowing individual AI user-agents, or allow everything — both are defensible. What is not defensible is blocking them by accident: a leftover Disallow: /, or a rule catching the sitemap URL, removes you from AI citations and from search at the same time, with no error anywhere to tell you.

Why freshness carries more weight here

AI answer systems lean hard on recency when choosing what to cite. An honest <lastmod> is the cheapest freshness signal you own — and a generator that stamps today's date on everything destroys it for both audiences at once.

XML Sitemap Best Practices: FAQs

How many URLs can one XML sitemap contain?

A single sitemap file may contain a maximum of 50,000 URLs and must not exceed 50 MB uncompressed, whichever limit you reach first. Beyond either, split the URLs across multiple files. A sitemap index can then bundle them so you submit one URL, though the index is optional — you may also submit several sitemaps directly. The index itself may reference up to 50,000 sitemaps, a ceiling no real site approaches.

Does Google use the priority and changefreq tags?

No. Google's documentation states directly that it ignores <priority> and <changefreq> values. Both were abused so widely that the signals became meaningless — most sites set every page to the maximum. Leaving whatever your generator emits is harmless, but tuning them achieves nothing, and advice to raise priority on important pages is simply out of date. Put the effort into <lastmod>, which Google does use when it can verify the value is accurate.

What should never appear in an XML sitemap?

Anything you are not asking Google to index: redirected URLs, 404 and 410 URLs, pages carrying a noindex directive, non-canonical duplicates, parameter and session-ID variants, and pages blocked in robots.txt. Each sends a contradictory instruction. Beyond wasting crawl budget, a file with a high proportion of dead entries becomes a less trusted signal overall.

How do you optimize XML sitemap performance?

Three moves, in order. Trim the file to canonical, indexable, 200-status URLs. Make <lastmod> reflect genuine content changes rather than build timestamps. Then segment the file by content type or date so Search Console reports indexing per section instead of as one undifferentiated number. Adjusting priority values and change frequencies is not on the list, because Google ignores both.

How often should you update your sitemap?

Automatically, on every publish. An active blog or store should regenerate on every add, update and delete; a static site can regenerate on deployment. Manual maintenance is the failure mode — a hand-edited sitemap is usually stale within days, and nobody notices until indexing drops.

What is the best way of submitting a sitemap to Google?

Use Search Console and robots.txt together. Search Console gives you fetch dates, processing errors and per-sitemap indexing data, and it removes the parent-directory restriction that otherwise limits a sitemap to URLs beneath its own folder. The robots.txt Sitemap: directive costs one line and lets any crawler find the file. For automated pipelines, the Search Console API can submit programmatically.

Do XML sitemap best practices guarantee indexing?

No, and any guide implying otherwise is overselling. Google describes sitemap submission as a hint, not an instruction — it does not guarantee the file will even be fetched. Whether a URL is indexed depends on content quality, duplication, internal linking and site-level trust. The real payoff from following XML sitemap best practices is diagnostic: a clean file turns the submitted-versus-indexed gap into a reliable measurement of what Google is choosing to leave out.

HTML sitemap vs XML sitemap: what is the difference?

An XML sitemap is a machine-readable file for crawlers; an HTML sitemap is an ordinary page of links for people. The html sitemap vs xml sitemap comparison therefore comes down to audience, and audience decides purpose: the XML file lists canonical URLs with metadata a parser can use, while the HTML page offers navigation a reader can follow. Search engines can discover URLs from either, but only the XML file carries <lastmod> and the image and video extensions. If your internal linking is sound, an HTML sitemap adds little for search and something for usability; if part of your site is genuinely hard to reach, the fix is navigation, not a list page bolted on beside it.

Last updated: 19 August 2026 — added the sitemap extension section (image and video sitemaps), submission to Bing and IndexNow, static versus dynamic generation, and an HTML-versus-XML FAQ. Previously updated 11 August 2026 — rewritten against Google Search Central's current sitemap and pagination documentation. Corrected guidance on <priority> and <changefreq>, which Google ignores, and on rel="next"/rel="prev", which Google no longer uses.