XML Sitemap Best Practices: What to Include and Leave Out

Short answer: an XML sitemap should list only the canonical, indexable URLs you want in search results, each returning a 200 status. Leave out redirects, error pages, noindex pages and parameter duplicates, keep each file under 50,000 URLs and 50 MB uncompressed, and update lastmod only when the content really changes. A clean sitemap helps discovery; a messy one teaches search engines to trust it less.

What an XML sitemap does and does not do

An XML sitemap is a machine-readable list of URLs on your site. Search engines use it as one of their discovery sources, next to links. It is especially useful for new sites with few external links, large sites where some pages sit deep in the structure, and sites that publish or update content often.

A sitemap does not force indexing. It does not raise rankings by itself, and it does not replace internal links. If a page is only reachable through the sitemap and nothing links to it, search engines will still treat it as less important than well-linked pages. Think of the sitemap as your official list of pages that matter, and make sure the rest of the site agrees with it.

The basic format

A minimal 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/services/seo-audit/</loc>
    <lastmod>2026-07-14</lastmod>
  </url>
</urlset>

Only loc is required. lastmod is useful when it is accurate. The optional changefreq and priority fields are ignored by Google, so there is no need to tune them. URLs must be absolute, use the same protocol and host as the live site, and be properly escaped, for example & instead of a bare ampersand.

Which URLs belong in the sitemap

The rule is simple: include a URL only if you would be happy to see it as a search result. In practice that means pages that:

• return a 200 status code directly, without redirecting;
• have a self-referencing canonical, so the sitemap URL and the canonical are identical;
• are indexable: no noindex meta tag, no X-Robots-Tag: noindex header, not blocked in robots.txt;
• have real content for searchers: services, products, categories, articles, guides, location pages.

Typically that includes your home page, main service or product pages, category pages that you want to rank, blog posts and important landing pages.

What to leave out

Most sitemap problems come from including URLs that contradict other signals. Leave out:

• Redirecting URLs. List the final destination instead.
• 404, 410 and 5xx pages. Deleted content should disappear from the sitemap when it is deleted.
• Noindex pages, such as thank-you pages, internal search, login and account pages.
• Non-canonical URLs: parameter variants, sort orders, tracking URLs and duplicates that point to another canonical.
• Thin archive pages you do not want to rank, such as WordPress author archives on single-author blogs, date archives, or tag pages without useful content.
• Attachment and media pages that WordPress and some plugins generate for every uploaded image.
• Staging, test or development URLs that leaked into production data.

Each of these sends a mixed message: “please index this” from the sitemap, “do not index this” from the page itself. When a large share of a sitemap is contradictory, search engines tend to rely on it less.

Size limits, sitemap indexes and compression

The sitemaps protocol sets two limits per file: 50,000 URLs and 50 MB uncompressed. Larger sites split their URLs into several files and list those files in a sitemap index:

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://www.example.com/sitemap-products-1.xml</loc></sitemap>
  <sitemap><loc>https://www.example.com/sitemap-posts.xml</loc></sitemap>
</sitemapindex>

Splitting by content type is useful even below the limits. Separate sitemaps for products, categories, posts and pages let you see in Search Console which type has indexing problems. Files can be gzip-compressed to save bandwidth; the size limit applies to the uncompressed file.

Getting lastmod right

The lastmod date tells search engines when a page last changed meaningfully. Google has said it uses lastmod when it is consistently accurate. The common mistakes are:

• Setting every URL to today’s date on each sitemap generation. The field becomes noise and is ignored.
• Updating lastmod for trivial changes, such as a new copyright year in the footer or a changed sidebar widget.
• Never updating it when a page is rewritten.

Use the date the main content was last edited. Most CMS platforms, including WordPress, already store a modified date per post, and good sitemap generators use it.

Image, video and news sitemaps

Besides the standard URL sitemap, search engines support extensions for specific content types. They are optional, and most small sites do not need them, but they help in a few situations:

• Image sitemaps list the images on each page. They are useful when images are loaded in ways crawlers may miss, for example through JavaScript galleries, or when image search is an important traffic source, as it often is for shops, recipes and interior design sites.
• Video sitemaps describe videos hosted on your own pages, including title, description, thumbnail and duration. They help when video is a key part of the page and you want it considered for video results.
• News sitemaps are for publishers that appear in news surfaces. They should only contain articles published in the last two days.

You can add image and video entries inside your normal sitemap or keep them in separate files. Either way, the same rules apply: only list content on canonical, indexable pages, and keep the entries in sync with what is actually on the page.

Multilingual sites can also declare language alternates inside the sitemap instead of in each page’s HTML. That is a valid approach for large sites, but it must be kept complete and consistent, because a missing return link breaks the pair.

Sitemaps for large and fast-changing sites

For a site with a few hundred pages, one sitemap generated by the CMS is enough. Larger sites, especially shops with tens of thousands of products, need a bit more thought:

• Generate sitemaps from the database, not from a crawl. The database knows every published item and its last modification date. A crawl only knows what it can reach.
• Exclude out-of-stock or discontinued items consistently with how the product pages behave. If discontinued products redirect or return 410, they must leave the sitemap at the same moment.
• Keep a separate file for recently added or changed URLs. It makes it easy to see in Search Console how quickly new content is discovered.
• Cache the generated files and regenerate on a schedule or on publish. Building a huge sitemap on every request can slow the server and time out for crawlers.

How to submit and find your sitemap

There are two standard ways to tell search engines where your sitemap is, and it is worth using both:

1. Add a Sitemap: line to robots.txt with the full absolute URL of the sitemap or sitemap index. Any crawler that reads robots.txt will find it.
2. Submit it in Search Console (and Bing Webmaster Tools). This gives you a report on how many URLs were discovered and any fetch or parsing errors.

On WordPress, core has generated a basic sitemap at /wp-sitemap.xml since version 5.5. SEO plugins usually replace it with their own, often at /sitemap_index.xml. Make sure only one of them is active and that the one you submit is the one that exists.

Finding sitemap errors on a real site

Sitemaps drift out of date quietly. Pages are deleted, URLs change, plugins add new content types. A periodic check catches the drift:

1. Download every sitemap file and collect all listed URLs.
2. Fetch every URL and record status code, canonical and robots directives.
3. Flag contradictions: redirects, errors, noindex pages and URLs whose canonical points elsewhere.
4. Compare with a crawl. Indexable pages found by crawling links but missing from the sitemap are gaps. Sitemap URLs that no internal link points to are orphan pages that need links.
5. Check Search Console’s page indexing report filtered by sitemap to see which submitted URLs are not indexed and why.

A healthy sitemap on a well-maintained site should have close to zero contradictions. If a noticeable share of listed URLs redirect or return errors, fix the generator, not just the individual URLs.

How Site SEO AI Audit checks your sitemap

SEOAuditBot reads both your pages and your sitemap, like a search engine. The crawl and index area of the audit reports sitemap URLs that redirect, return errors or are set to noindex, and pages that exist in the sitemap but are not linked from anywhere on the site, as well as orphan and deep pages. Each issue comes with the list of affected URLs and, on WordPress, the steps to fix it in your SEO plugin. You can start with a free audit to see how clean your sitemap is.

Related reading

• Robots.txt for SEO: what to block and what to leave open
• Canonical tags explained: how to set them and fix errors

The bottom line

Treat your sitemap as the official list of pages you want in search. Include only canonical, indexable URLs that return 200, keep lastmod honest, split large sites into several files, and check regularly that the sitemap still agrees with your live pages.

BUJ

Does every website need an XML sitemap?

Small, well-linked sites can be crawled fine without one, but a sitemap costs little and helps discovery of new and deep pages. For large sites, new sites and sites that update content often, it is strongly recommended.

Should noindex pages be in the sitemap?

No. A sitemap says “please index these URLs”, so listing noindex pages sends a contradictory signal. The only common exception is temporarily listing pages you want recrawled quickly so the noindex is seen, then removing them.

Do changefreq and priority matter?

Google ignores both fields. You can leave them out. An accurate lastmod date is far more useful.

How many URLs can one sitemap contain?

Up to 50,000 URLs and 50 MB uncompressed per file. Larger sites split their URLs into several sitemaps and list them in a sitemap index file.

Why are submitted URLs not indexed?

Being in a sitemap does not guarantee indexing. Common reasons are thin or duplicate content, a canonical pointing elsewhere, weak internal linking or quality signals. Search Console’s page indexing report shows the reason for each URL.