XML Sitemaps: Best Practices for Small and Large Sites

Is Google slow to find your new pages? Does Search Console keep flagging sitemap errors you don’t understand? The fix usually starts with the file itself. A few XML sitemap best practices cover most of it. List only canonical, indexable URLs that return a 200 status. Keep each file under 50,000 URLs and 50MB. Keep lastmod honest. And submit the file in Search Console and robots.txt.

In this guide, I explain what a sitemap can and can’t do for you, what to put in it, and how to read the Sitemaps report. I also cover what changes once a site grows past a few thousand pages.

What an XML Sitemap Does (and What It Doesn’t)

An XML sitemap is a list of URLs you want search engines to know about. It can also include details such as when each page last changed. Its job is discovery. It helps Googlebot find pages it might miss, or find them sooner.

It is not a ranking factor, and it doesn’t force anything into the index. Google says clearly that a sitemap doesn’t guarantee every listed URL will be crawled or indexed. It’s a hint, and Google weighs it with everything else it knows about your site.

A sitemap also can’t make up for weak internal linking. Pages that sit in the sitemap but have no links pointing to them tend to be treated as low priority. Links are still the main way Google finds and values pages. So your sitemap and your internal linking structure should point at the same important URLs.

Do You Even Need One?

Google’s own guidance says you may not need a sitemap if your site is small (around 500 pages or fewer that you want in search), well linked inside, and light on video, image or news content.

You probably do need one if:

• Your site is large, so some pages are several clicks deep.
• Your site is new and has few links from other sites.
• You publish a lot of video, images or news articles.
• You add or update content often and want changes picked up quickly.

In practice, almost every CMS creates a sitemap for you, and there’s no downside to having a clean one. The real question is whether yours is clean. In my experience, most aren’t, and that’s where I’d spend your time.

Google’s Sitemap Limits and the Sitemap Index

A single sitemap file can hold up to 50,000 URLs or 50MB uncompressed, whichever comes first. You can gzip (compress) the file to save bandwidth, but the 50MB limit applies to the uncompressed size.

When you need more, you split the URLs across several sitemaps. Then you list those files in a sitemap index. An index can list up to 50,000 sitemaps, and you can submit up to 500 index files per site in Search Console.

A few rules that trip people up:

• An index lists sitemaps, not pages. You can’t put an index inside another index.
• Child sitemaps should sit in the same folder as the index or deeper, and on the same site.
• Use full, absolute URLs everywhere, including https and the correct www or non-www version.
• The file must be UTF-8 encoded, and special characters such as & must be escaped.

A Minimal Sitemap Example

Here is what a small, valid sitemap looks like. It only needs the urlset, url and loc tags. lastmod is optional but useful when it’s accurate.

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

<url><loc>https://www.example.com/services/seo-audit/</loc><lastmod>2026-04-10</lastmod></url>

<url><loc>https://www.example.com/blog/local-seo-checklist/</loc><lastmod>2026-03-28T14:05:00+00:00</lastmod></url>

</urlset>

A sitemap index uses the same idea with different tags. It has a sitemapindex root, then one sitemap entry per file, each with its own loc and optional lastmod.

XML Sitemap Best Practices: Which URLs to Include

The most common sitemap problem isn’t syntax. It’s listing URLs that shouldn’t be there. Every URL in your sitemap should pass three checks.

1. It returns a 200 status. No redirects, no 404s, no server errors. If a URL redirects, list the final destination instead.
2. It is indexable. No noindex tag or header, and not blocked by robots.txt.
3. It is the canonical version. The URL in the sitemap should match the canonical tag on the page, including protocol, www and trailing slash.

Listing a URL in your sitemap tells Google you see it as the preferred version. If the sitemap says one thing and the canonical tag says another, you’re sending mixed signals, and Google has to pick.

What to Leave Out

• URLs with tracking parameters, session IDs or sort and filter parameters.
• Internal search results pages.
• Paginated archives, tag pages and author pages you have set to noindex.
• Thin utility pages such as cart, checkout, login and thank-you pages.
• Staging or test URLs, which sometimes leak in after a migration.
• Duplicate versions, such as both http and https, or both www and non-www.

Here’s the simple test I use. Your sitemap is the list of pages you’d be happy to see in search results. If you wouldn’t want someone landing on a page from Google, it doesn’t belong.

lastmod, Priority and changefreq

According to Google’s sitemap documentation, Google ignores <priority> and <changefreq>. You can leave them in if your plugin adds them. But they do nothing for Google, so don’t spend time tuning them.

<lastmod> is different. Google uses it, but only if it’s consistently and provably accurate. If your lastmod values don’t match reality, Google learns to distrust them for your site.

“Accurate” means the date shows the last significant change to the page. Google gives examples: changes to the main content, the structured data or the links. Updating a copyright year in the footer, or rebuilding the page without changes, doesn’t count.

Common ways lastmod goes wrong:

• Every URL shows today’s date because the sitemap is rebuilt on each request.
• A sidebar widget or “related posts” block changes, and the CMS updates every post’s date.
• Dates are written in a non-standard format. Use W3C Datetime, such as 2026-04-10 or 2026-04-10T09:30:00+00:00.

If you can’t make lastmod accurate, I’d leave it out. That’s better than filling it with noise.

Image, Video and News Sitemaps

Google supports extensions to the standard format. You can add these tags to your existing sitemap or keep them in separate files.

Image Sitemaps

Image entries help Google find images it might otherwise miss, especially images loaded with JavaScript. Each image needs an <image:image> wrapper and an <image:loc> URL. A single page entry can list up to 1,000 images.

Older guides still mention caption, title, geo-location and license tags. Google deprecated those, so you can drop them. Image context now comes from the page itself: alt text, nearby text and filenames.

Video Sitemaps

If video is central to your pages, a video sitemap helps Google find and understand it. Each video needs a thumbnail URL, a title, a description, and either a content URL (the video file) or a player URL. Google prefers the content URL where you can provide it. For ranking the videos themselves, see my YouTube SEO guide.

Only list videos that are the main content of the page, not small side embeds. Video structured data can carry similar information on the page itself. My schema markup guide covers how that fits together.

News Sitemaps

News sitemaps are for publishers whose content appears in Google News. They work differently from regular sitemaps:

• Include only articles published in the last two days. After that, remove the URL or its news tags.
• Keep each news sitemap to 1,000 news entries or fewer, and split it if you need more.
• Each entry needs a publication name and language, the original publication date, and the article title.

Your regular sitemap should still list those articles long term. The news sitemap is just a short-lived fast lane for fresh stories. News publishers can also ask readers to pick them in Google Preferred Sources for Top Stories.

WordPress Built-In Sitemaps vs SEO Plugins

Since version 5.5, WordPress creates a basic sitemap by itself at /wp-sitemap.xml. It’s an index that links to separate sitemaps for posts, pages, categories, tags and users. Each file holds up to 2,000 URLs by default.

The core sitemap works, but it’s basic. For example, it doesn’t add image entries. It also lists every public post type and taxonomy unless a developer filters them out. That often means thin tag archives and author pages end up listed, even if you don’t want them indexed.

Popular SEO plugins such as Yoast SEO, Rank Math and All in One SEO replace the core sitemap with their own. It usually lives at /sitemap_index.xml or /sitemap.xml. Their main advantages are practical:

• Pages you set to noindex in the plugin are removed from the sitemap automatically.
• You can turn whole post types or taxonomies on and off with a setting.
• They can add image entries and, with extra modules, video or news sitemaps.

Whichever you use, make sure only one sitemap system is active. Two systems running side by side, or an old static sitemap.xml file left in the root, leads to duplicate or outdated URLs being submitted. I see this a lot after a plugin switch. After installing or switching plugins, open each sitemap in your browser and confirm it loads and lists what you expect.

How to Submit Your Sitemap

There are two main ways to tell Google about your sitemap. I always use both.

Submit It in Search Console

Open the Sitemaps report under Indexing. Paste the sitemap URL into “Add a new sitemap” and click Submit. If you use a sitemap index, submitting the index is enough, because Google reads the child sitemaps from it. You need owner permissions on the property to submit.

Think about submitting separate sitemaps for different sections, such as products, categories and blog posts, even on medium-sized sites. It lets you see indexing for each section on its own.

Reference It in robots.txt

Add a line like this anywhere in your robots.txt file:

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

This lets Google, Bing and other crawlers find the sitemap without a manual submission. You can also submit sitemaps directly in Bing Webmaster Tools. You can list several Sitemap lines. Use the full URL, and make sure robots.txt doesn’t block the sitemap file itself. My guide to robots.txt and AI crawlers covers the rest of the file.

One thing you no longer need is the old habit of “pinging” Google with a sitemap URL. Google announced in 2023 that it was retiring its sitemap ping endpoint. Search Console, robots.txt and the Search Console API are the supported routes now.

Reading the Sitemaps Report and Fixing Errors

Each submitted sitemap shows one of three statuses in the Search Console Sitemaps report:

• Success: the file was fetched and processed without errors.
• Has errors: the file was read, but some parts couldn’t be parsed. URLs that parsed correctly are still used.
• Couldn’t fetch: Google couldn’t get the file at all.

The “Discovered pages” number is how many URLs Google read from the file. It’s not the number indexed. To see that, open the sitemap and use the option to view index coverage. Or filter the Page indexing report by sitemap. That view is where sitemaps really earn their keep. It shows exactly which of your chosen pages Google has and hasn’t indexed, and why. It’s the first place I look when I check a sitemap.

Common Errors and Fixes

• Couldn’t fetch: check the URL loads in a browser and returns a 200. Use the URL Inspection tool’s live test to confirm Googlebot can reach it.
• Sitemap is blocked by robots.txt: remove the Disallow rule that covers the sitemap path.
• URL not allowed: the sitemap lists URLs from a different domain, a different www version, or a folder above the sitemap’s location. Make the URLs match the site.
• Invalid date: fix the lastmod format to W3C Datetime.
• Unsupported format or parsing errors: usually a missing namespace, an unescaped ampersand, or a PHP warning printed at the top of the file. Open the raw file and look at the first lines.
• Sitemap too large: split it into smaller files and list them in an index.
• Nested indexes: an index pointing to another index isn’t allowed. Point it at regular sitemaps only.

Indexing Issues for Sitemap URLs

Once the file itself is clean, check the Page indexing report filtered to your sitemap. Watch for these patterns:

• Excluded by noindex or Page with redirect: these URLs shouldn’t be in the sitemap. Fix the tool that builds it.
• Alternate page with proper canonical tag: you’re listing non-canonical URLs. Swap in the canonical versions.
• Crawled – currently not indexed or Discovered – currently not indexed: the sitemap did its job, but Google chose not to index yet. That’s a content quality, duplication or internal linking issue, not a sitemap issue. My explainer on how Google Search works covers the crawl and index stages in more detail.

Removing a sitemap in Search Console only removes it from the report. Google still remembers the URLs. To stop Google crawling them, you need to change the pages themselves. If you only need a URL hidden from results quickly, see my guide to the Search Console Removals tool.

What Large Sites Should Do Differently

On a site with tens of thousands or millions of URLs, the sitemap stops being a single file. It becomes a monitoring tool. A few things matter more at that size.

Split Sitemaps by Page Type

Group URLs by template: product pages, category pages, articles, location pages. Then submit each group, or one index that lists them. When one template has an indexing problem, it shows up clearly in its own sitemap instead of being hidden in a total.

Generate Sitemaps From the Database, Not by Crawling

Build sitemaps from the source of truth, such as your product catalogue or CMS. Filter it to live, indexable, canonical pages. Sitemaps built by crawling big sites tend to miss orphaned pages (pages with no internal links) and include junk parameter URLs.

Keep Files Well Under the Limits

You don’t have to fill each file to 50,000 URLs. Smaller files are quicker to rebuild and easier to diagnose. Gzip them to cut transfer size, and remember the 50MB limit still applies uncompressed.

Use lastmod in the Index Too

Each sitemap entry in an index can carry its own lastmod. If only one child file changed, its date changes and the others stay the same. That gives Google a cleaner signal about where to look.

Remove Dead URLs Quickly

Discontinued products, expired listings and merged pages should leave the sitemap as soon as they stop returning 200. A large sitemap full of redirects and 404s wastes crawling and makes the report harder to read. My guide to 404s, soft 404s and redirects covers what to do with those URLs.

Watch the Ratio, Not Just the Count

Track the share of submitted URLs that are indexed for each sitemap over time. A sudden drop in one section is often the first sign of a template bug, a robots.txt mistake or a canonical tag change after a release. On big sites, this is the number I’d watch most closely.

Conclusion

The XML sitemap best practices that matter most are simple. List only canonical, indexable 200 URLs. Keep files within Google’s limits. Keep lastmod honest. Submit through Search Console and robots.txt. Then use the Sitemaps and Page indexing reports to spot problems early.

A good next step is to open your sitemap and spot-check twenty URLs against those three checks. Then compare the sitemap with your internal links. Pages that matter should appear in both, and my guide to building topic clusters with internal links shows how to close that gap and finish the job these XML sitemap best practices start.