Ultimate Guide to XML Sitemaps (2026)

An XML sitemap is a single machine-readable file that lists the URLs you want search engines to find, written in a format every major crawler parses the same way. This guide covers the whole system: the protocol limits, the tags Google actually reads, how to split a large site across a sitemap index, how to submit and validate, and how to read the Search Console report without guessing. It corrects three pieces of advice that most listicles still get wrong in 2026: pinging Google is dead, the priority and changefreq tags are ignored, and lastmod is a binary change signal rather than a freshness hack. Every claim here is tied to a primary source, and every check is one you can run yourself in a browser or a terminal.

What Is an XML Sitemap? The Definition, Protocol, and What Google Actually Reads

An XML sitemap is a text file that lists page URLs in a structured format, so that crawlers can discover them without having to walk every internal link first. The format is defined by the sitemaps.org protocol, published in 2005 and still the governing spec, which describes the <urlset> root element, the <url> entry, and the <loc> element that carries each address. sitemaps.org protocol (2005) The protocol is intentionally small. A valid sitemap is mostly a list of <loc> values, with a few optional fields bolted on for metadata.

The file exists because crawling is not guaranteed to find everything. Internal links are the primary discovery path, but they fail in predictable ways: deep pages with no inbound links, pagination that requires JavaScript, and content published faster than the crawler revisits your navigation. Google describes the sitemap as a hint for discovery, most useful for large sites, new sites, and sites rich in media whose pages are otherwise hard to find. Google Search Central (2025)

The protocol in one sentence

A sitemap is an XML document whose root element declares the sitemap namespace, and whose children are <url> blocks, each holding one <loc> and optional metadata. The namespace string, http://www.sitemaps.org/schemas/sitemap/0.9, is what tells a parser this is a sitemap and not some other XML document. If the namespace is missing or wrong, the file is not a sitemap as far as Google is concerned.

What Google reads from each entry

Google reads the <loc> value, which is the URL, and it reads <lastmod> when you provide it. That is the practical shortlist. Google has confirmed it ignores <priority> and <changefreq> entirely, so a file carrying those two tags is carrying dead weight. Google Search Central (2025) The URL is the whole point; lastmod is the only metadata that changes crawl behavior, and it does so in a way most people misunderstand.

What a sitemap is not

A sitemap is not a ranking signal, not a directive, and not a guarantee. Listing a URL does not force Google to crawl it or index it, and Google states that submitting a sitemap does not guarantee that every URL in it will be crawled or indexed. Google Search Central (2025) It is a suggestion about which URLs exist, handed to a crawler that is free to ignore the suggestion. Keep that distinction in mind and you will read every Search Console report correctly. To see exactly what a crawler extracts from your own file, run it through the sitemap checker and read the parsed URL list it returns. Sitemaps can also carry hreflang annotations for localized variants, which the hreflang guide covers from the annotation side.

XML Sitemap vs. HTML Sitemap vs. Sitemap Index File: When to Use Each

The word "sitemap" covers three different artifacts, and mixing them up causes real mistakes. An XML sitemap is for machines: it is a list of URLs a crawler reads. An HTML sitemap is for people: it is an ordinary web page that links to the main sections of your site so a visitor, or a crawler following links, can navigate. A sitemap index file is a container that points at multiple XML sitemaps so a very large site can stay under the per-file limits. All three can exist at once, and on a big site all three usually should.

The XML sitemap is the one Google's documentation calls "a sitemap." It is submitted in Search Console or referenced from robots.txt, and it is the artifact the rest of this guide is about. The HTML sitemap is a usability page, the kind you might link in the footer, and it has no special status in Google beyond being a set of crawlable links. The sitemap index is the XML sitemap's bigger sibling: a file that lists other sitemaps instead of listing pages. Google Search Central (2025)

When the XML sitemap is enough

If your site has fewer than 50,000 URLs and no media-heavy needs, a single XML sitemap is the entire job. Generate it, keep lastmod honest, submit it once, and stop. Most sites never need an index file, and building one anyway adds a layer of files that can break without adding any crawl benefit.

When you need an index file

You need an index file the moment one sitemap would exceed 50,000 URLs or 50 MB uncompressed, or the moment you want to report on one content type independently. A store with 300,000 products and 2,000 articles should split the catalog into several product sitemaps, put the articles in one, and tie them together under a single index. The index is the one file you submit, and it points at every child.

When the HTML sitemap still earns its keep

The HTML sitemap does almost nothing for a small site, but it helps on a large one as a crawlable hub that consolidates internal links. It is a page, not a protocol, so the rules that matter for it are the same rules that matter for any page: it should be reachable from the footer, its links should be plain anchors, and its content should be useful. If you are tightening the whole crawl surface, the on-page SEO guide covers internal linking and crawlable anchors in detail.

The Sitemap Limits That Never Change: The 50,000 URL and 50 MB Uncompressed Rules

Two limits have defined sitemaps since the protocol began, and neither has changed: a single sitemap can hold at most 50,000 URLs, and it must be no larger than 50 MB when uncompressed. Google Search Central (2025) The 50 MB figure is measured on the raw XML, not the gzipped file you might serve, which is the mistake that catches people. You can compress the file for transfer, and Google accepts gzip, but the limit applies to the uncompressed size, so a 12 MB gzip file that expands to 80 MB of XML is still a violation.

The same two limits apply one level up. A sitemap index file can reference up to 50,000 individual sitemaps, and it is subject to the same 50 MB uncompressed ceiling. Google Search Central (2025) In practice almost nobody hits 50,000 child sitemaps, because that would mean 2.5 billion URLs, but the 50 MB cap on the index is easy to brush against if you inline long child URLs or giant lastmod lists.

The same-host rule

Every URL in a sitemap must live on the same host as the sitemap file itself, meaning the same scheme and hostname. A sitemap hosted at https://example.com/sitemap.xml may only list https://example.com/... URLs. Google states this outright: cross-domain URLs are not allowed in a sitemap. Google Search Central (2025) This trips people who host a sitemap on a CDN or a central assets domain and try to list the marketing site from there.

Bing's larger limit, and why you should not rely on it

Bing announced in 2016 that it would accept sitemap files beyond the 50,000 URL baseline to accommodate larger sites. Bing Webmaster Blog (2016) Google has not announced the same relaxation, and a file that works on Bing but trips Google's cap is a problem, not a convenience. Treat 50,000 and 50 MB as the rules for everyone, and you never have to remember which engine relaxed what.

Which Sitemap Tags Still Matter in 2026: lastmod, priority, changefreq, and What Google Ignores

The sitemaps.org protocol defines three optional child elements for each <url>: <lastmod>, <changefreq>, and <priority>. sitemaps.org protocol (2005) Optional in the protocol does not mean used in practice. Google reads lastmod, and it ignores the other two. The gap between what the spec allows and what Google uses is where most sitemap advice goes stale.

lastmod is the only metadata that matters

<lastmod> is the date the page was last meaningfully changed, written in W3C datetime format such as 2026-08-01. Google reads it, but not as a ranking signal. It reads it as a change flag: either the page changed since the last time Google saw it, or it did not. That binary reading is the subject of a later section, and it is the reason the tag still deserves care.

priority and changefreq are dead bytes

Google ignores both <priority> and <changefreq>, so including them does not affect crawling or ranking. Google Search Central (2025) This has been Google's stated position for years, yet most sitemap plugins still emit both tags and most guides still explain how to tune them. On a site with a million URLs, those two fields are a million wasted calculations and a chunk of wasted file size.

What the protocol still requires

The only hard requirements are the XML structure, the namespace, and one <loc> per <url>. The protocol also requires UTF-8 encoding, entity escaping for reserved characters, and absolute URLs. sitemaps.org protocol (2005) Get those four things right and a parser will read your file; everything else is optional and mostly ignored.

How to Build an XML Sitemap from Scratch: A Complete Worked Example (sitemap.xml)

You do not need a plugin to build a correct sitemap. The format is short enough to write by hand for a small site, and reading one written by hand teaches you the escaping rules every generator must follow. Here is a complete, valid sitemap with lastmod values and entity-escaped absolute URLs.

<?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-08-01</lastmod>
  </url>
  <url>
    <loc>https://example.com/products/standing-desk</loc>
    <lastmod>2026-07-18</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/desk-setup?ref=sitemap&amp;campaign=guides</loc>
    <lastmod>2026-06-30</lastmod>
  </url>
</urlset>

Three details in that file do the real work. First, the namespace on the <urlset> element declares the 0.9 schema. Second, every URL is absolute, starting with https://, because a relative path cannot resolve from a file a crawler fetches in isolation. Third, the ampersand in the third URL's query string is written as &, which is the entity-escaped form of & that valid XML requires. If you write a raw & in a URL, the file is no longer well-formed XML and a parser rejects the whole document.

The declaration and namespace

The first line is the XML declaration, and the second sets the namespace. The encoding="UTF-8" attribute matters because the protocol requires UTF-8, and any non-ASCII character in a URL must be properly encoded or escaped or the parser will choke on it. sitemaps.org protocol (2005) Most generators handle this silently, which is exactly why reading the raw output once is worth your time.

One url block per page

Each page gets its own <url> block, and inside it a <loc> plus an optional <lastmod>. Do not list redirects, do not list pages that return 404, and do not list URLs you have deliberately kept out of the index. A sitemap should describe the set of pages you actually want crawled, not every address your site has ever produced. If you are unsure whether a URL still resolves, the redirect checker will follow it and tell you where it lands before you hand it to Google.

Entity escaping, the failure most generators hide

The characters &, <, >, ", and ' have to be escaped in XML attribute and text content. In practice only the ampersand shows up in URLs, and it is the one that silently corrupts files. A plugin that writes a raw ampersand produces an XML file that passes a quick visual check and fails a real parse. That is why validation, covered later, is not optional. Run your finished file through the sitemap checker to confirm it parses and that every URL is absolute and on the same host.

How to Submit a Sitemap in 2026: Search Console vs. robots.txt (and Why You Should Stop Pinging)

There are two supported ways to give Google your sitemap, and one dead way you should stop using. Google recommends submitting through Search Console or referencing the file in robots.txt. Google Search Central (2025) The old habit of pinging an HTTP endpoint is gone: Google deprecated the sitemap ping endpoint in June 2023, so those /ping?sitemap=... URLs no longer notify Google of anything. Google Search Central Blog (2023)

Search Console submission

Submitting in Search Console is the path that gives you the most signal back. Google fetches the file, parses it, and reports per-file status, discovered URLs, and errors in the Sitemaps report. Google Search Central (2025) That status tracking is the main reason to submit here rather than only in robots.txt: you can see whether the file fetched, whether it parsed, and how many URLs it yielded.

robots.txt reference

You can also point at the sitemap from robots.txt with a Sitemap: line, and the file becomes discoverable to any crawler that reads the robots file, not just Google. The tradeoff is reporting. Sitemaps referenced in robots.txt are handled differently from those submitted in Search Console, and they do not appear in the Sitemaps report with the same status tracking. Google Search Central (2025) A bare robots reference is fine for Bing and other engines, but you lose the per-file diagnostics Google gives you in Search Console. Here is the reference:

User-agent: *
Allow: /

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

Put the Sitemap: directive on its own line with an absolute URL, and keep it in the robots file that lives at the root of your domain. Test the file with the robots.txt tester before you ship it, because a misplaced directive or a typo in the URL silently breaks the reference.

The submission method at a glance

The practical answer is to do both. Submit in Search Console for the diagnostics, and put the Sitemap: line in robots.txt so every other engine finds the file too. The two are complementary, not competing.

Sitemap Index Files, Step by Step: Splitting a Large Site with a Worked Nested Example

A sitemap index is a sitemap whose entries are other sitemaps. Its root element is <sitemapindex> instead of <urlset>, and each child is a <sitemap> block holding a <loc> that points at one child sitemap. The index is what you submit, and it hands Google the whole list of files at once. Google Search Central (2025)

Here is a segmented index that references three child sitemaps by content type, the structure a real large site would use.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-08-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-articles.xml</loc>
    <lastmod>2026-07-28</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-images.xml</loc>
    <lastmod>2026-07-15</lastmod>
  </sitemap>
</sitemapindex>

The index obeys the same rules as a sitemap: UTF-8, entity escaping, absolute URLs, and the same-host rule. Each child sitemap must live on the same host as the index, and each child must itself stay under 50,000 URLs and 50 MB uncompressed. The <lastmod> inside a <sitemap> block is optional and records when that child file changed.

Why nest instead of listing everything flat

The index gives you three things a flat list cannot. First, it removes the 50,000 URL ceiling entirely by stacking files. Second, it lets you update one content type without regenerating every URL on the site. Third, it lets you watch one child sitemap in Search Console and see whether that segment is being discovered, rather than staring at one merged number.

The naming and structure that scale

Use descriptive, stable filenames such as sitemap-products.xml and sitemap-articles.xml so a reader, and a report, can tell them apart. Keep the index itself at a predictable path, commonly /sitemap-index.xml or /sitemap.xml, and reference it from robots.txt. When a child file grows close to its cap, split it into sitemap-products-1.xml and sitemap-products-2.xml and update the index, which keeps the whole structure stable as the site grows.

How to Segment a Large Site by Content Type: Product, Article, Image, and Video Sitemap Strategy

Splitting by content type is the highest-leverage organizational decision you make on a large sitemap, because different content types have different change patterns, different crawl economics, and different failure modes. A product catalog turns over on price and stock changes; an article archive barely changes at all; images and video have their own discovery rules. When everything is in one file, you cannot see any of that, and you cannot act on it. Google Search Central (2025)

Product sitemaps

Product URLs change when price, availability, or details change, so their lastmod values should move the most. Segment products separately because they are usually the largest group and the group where crawl budget decisions matter most. Keep the canonical product URL in the sitemap, not the variant or tracking URL, and make sure every entry resolves with a 200, which the redirect checker can confirm in bulk before you publish.

Article sitemaps

Articles are the quiet segment. Once published, most pages never change, so their lastmod should be the publication date and stay there. Grouping articles separately means you can regenerate the product file on every stock change without touching the article file, which saves processing and keeps each file's lastmod meaningful.

Image sitemaps

Image sitemaps are their own namespace and their own file, listing image URLs that belong to your pages. The 2022 spring cleaning retired much of the old image extension surface, so the surviving practice is leaner than most tutorials describe. Keep image entries in a dedicated file referenced from the index, and revisit the specifics in the media section later in this guide.

Video sitemaps

Video sitemaps are still documented by Google, but many of their legacy fields were retired in the same 2022 cleanup. Google Search Central (2025) If video is a meaningful part of the site, give it its own file so its dead fields can be pruned without disturbing your page URLs. For the page-level structure underneath these segments, the on-page SEO guide covers the canonical and indexability rules each segment must obey.

Crawl Budget Optimization with Sitemaps: Using lastmod as a Binary Change Signal

Crawl budget is the number of URLs Google is willing to fetch from your site in a given window, and it only really matters on large sites. The sitemap's job in that economy is to tell Google, cheaply, which URLs changed so the crawler can prioritize the changed pages over the unchanged ones. The signal that does that is lastmod, and it works in a way that is more primitive than most advice implies.

Google's Gary Illyes has described lastmod as a binary signal: Google only cares whether the page changed, not the exact date you wrote. Search Engine Journal (2023) The crawler reads the timestamp and reduces it to a yes or a no. Did this URL change since I last saw it? If yes, it is a candidate for a fresh crawl. If no, it drops down the priority list. The date's precision, whether you wrote 2026-08-01 or 2026-08-01T09:00:00+00:00, does not matter to Google.

Why binary matters for engineering

The binary reading changes how you build the file. You do not need to track edit history, revision counts, or "significant" versus "minor" changes. You need one field that updates whenever the page content changes and stays put otherwise. That is a much cheaper system to build correctly, and it is the only one Google rewards.

Where sitemaps stop helping

A sitemap cannot grant you more crawl budget, and it cannot make Google index a page it has decided not to index. It only helps Google spend the budget it was already going to spend, on the pages most likely to need it. If your robots.txt is blocking the crawler or your pages fail quality checks, no lastmod value fixes that. Before you tune lastmod for budget, confirm the crawler can actually reach the pages with the robots.txt tester, because a blocked crawl path makes every sitemap optimization pointless.

The Correct 2026 lastmod Strategy: Accuracy Over Fake Freshness

The wrong lastmod strategy is the one most tools still ship by default: write the current date on every URL every time the file regenerates. That makes the whole file look freshly changed, which looks impressive and accomplishes nothing. Google reads lastmod as a binary change signal, so if you stamp today's date on a page that last changed in 2021, you have told Google a falsehood it can detect by comparing against its own crawl history. Search Engine Journal (2023)

Fake freshness also destroys the one real use of the field. If every URL always shows today's date, then a genuinely changed page is indistinguishable from an unchanged one, and lastmod stops being a change flag at all. The signal you wanted collapses into noise, and you have done the work for nothing.

Update lastmod only when the page changes

The correct rule is mechanical: set lastmod to the date the page content last meaningfully changed, and update it only when the content changes again. A price edit updates it. A typo fix updates it. A rewritten intro updates it. A regenerated file that touched nothing does not. Keep the timestamp pinned to the content, not to the generation job.

When Google leans on lastmod anyway

Google has said it may rely on lastmod when it has no other signal about when a page changed, which is exactly the situation on a large site with millions of quiet URLs. Google Search Central Blog (2023) An accurate lastmod is worth the most precisely where you have the least other data: a deep archive page with no inbound links and no visible change on the homepage. Honesty there is the difference between Google knowing the page changed and Google guessing.

Where accuracy pays off

Keep lastmod accurate on the segments that change most: product pages, pricing pages, anything updated by an editorial or merchandising team. Those are the URLs whose recrawl actually moves business. For a product catalog, wire lastmod to the modified timestamp in your database and you get the whole strategy for free, one column, no manual work.

Video and Image Sitemaps After the 2022 Spring Cleaning: Which Tags Still Work

In May 2022 Google ran what it called a "spring cleaning" of sitemap extensions and deprecated a set of tags, including several image and video attributes, then stopped using them. Google Search Central Blog (2022) The result is that most image and video sitemap tutorials still circulating today teach fields that Google no longer reads. The safe practice is to ship the smallest valid media sitemap and let Google's on-page and structured-data signals carry the rest.

Google still documents video sitemaps and their alternatives, but many of the legacy video extension fields have been retired. Google Search Central (2025) The surviving, reliable fields are the ones that identify the asset and its location, while the descriptive metadata that used to ride in the sitemap now belongs in structured data and visible page content instead.

Image sitemaps: keep the location fields

An image sitemap still works as a way to point Google at image files it might not otherwise find, especially images loaded through JavaScript or hosted on a separate domain. The core fields are the image location and, where relevant, a caption and title. The elaborate attribute sets from the pre-2022 era are gone, so prune them and keep the file minimal.

Video sitemaps: a leaner format

For video, the fields that still matter are the video's location and title, with the richer metadata moved into structured data and the visible page. Google's video sitemap documentation describes the current format and its alternatives, and the honest summary is that a video sitemap is now a discovery aid, not a metadata dump. Google Search Central (2025)

The media decision in one line

Use a media sitemap when your images or videos are genuinely hard for Google to find, and keep the file to the location and identity fields. If your media is already in the visible HTML and marked up with structured data, a separate media sitemap adds little. Do not maintain retired fields out of habit; the 2022 cleanup means old generator output is carrying tags Google stopped reading. Validate whatever you ship with the sitemap checker so a stale field does not ship as an error you did not intend.

IndexNow vs. XML Sitemaps: When to Push URLs Instead of Waiting for a Crawl

IndexNow is a protocol, backed by Bing and Yandex, that lets a site push individual URL changes to participating engines the moment they happen, instead of waiting for a crawler to notice. It complements a sitemap; it does not replace it. IndexNow (2021) The two systems answer different questions: a sitemap answers "what URLs exist," and IndexNow answers "these specific URLs just changed, right now."

The mechanics are simple. You generate a key, host it at your domain root, and submit a URL or a list of URLs to an engine's IndexNow endpoint. The engines that support it fetch the changed URL promptly, which shortens the delay between a change and a recrawl. A sitemap cannot do that; it is a pull model where you wait for the next fetch, while IndexNow is a push model where you announce the change.

Where IndexNow wins

IndexNow wins on latency for individual changes: a price drop, a corrected article, a new product that needs to be seen today. On engines that support it, the push beats waiting for the crawler's schedule. It is also cheap, a single HTTP request per batch of changed URLs, which is exactly the kind of signal you can wire into your publish pipeline.

Where the sitemap still wins

The sitemap wins on coverage and on Google. IndexNow is not a Google protocol, so pushing to it does nothing for the engine that sends most sites most of their traffic, while the sitemap is read by Google, Bing, and everyone else. The sitemap is also the complete inventory: it lists everything, while IndexNow only announces the deltas you remember to push. Use both: the sitemap as the full, honest inventory, and IndexNow as the fast lane for the changes that cannot wait.

The compatibility rule

Before you push a URL through IndexNow, make sure it actually resolves where you think it does. A pushed URL that redirects, 404s, or is blocked wastes the push and teaches the engine to be cautious about your domain. Check the target with the redirect checker and confirm the crawl path with the robots.txt tester before you announce it, because a fast signal for a broken URL is worse than no signal at all.

How to Validate Your Sitemap Like an Engineer: XSD Schema, URL Counting, and Size Checks

A sitemap that looks right is not the same as a sitemap that is right. Validation is three checks, and each catches a different failure. The XSD schema check proves the XML is well-formed and matches the protocol. The URL count proves you are under 50,000 entries. The size check proves the uncompressed file is under 50 MB. Run all three and you have covered every mechanical way a sitemap breaks. Google Search Central (2025)

XSD schema validation

The sitemaps.org project publishes an XSD schema for the 0.9 namespace, and validating against it is the strictest correctness test available. You can run it locally with xmllint after downloading the schema:

curl -sO https://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd
xmllint --noout --schema sitemap.xsd sitemap.xml

A passing run prints a confirmation that the document validates; a failing run prints the exact line and the exact error, which is the fastest possible way to find a stray ampersand or a broken tag. For a sitemap index, validate against the same schema, since the index shares the namespace and the rules.

URL counting

Count the <url> elements and compare against 50,000. A quick grep-and-count works: grep -c "<url>" sitemap.xml approximates the count, though it counts the opening tags and can be fooled by whitespace. A real parser is safer on files near the cap. The point is not the exact number; it is knowing whether you are at 48,000 or 58,000 before Google tells you the hard way.

Uncompressed size checks

Measure the file's uncompressed byte size, not the size of the gzip you serve. If you gzip on upload, decompress and measure the raw XML. A 50 MB uncompressed file of 50,000 URLs is possible only with long URLs and heavy lastmod values, but the check is one command, so run it. If any file approaches either cap, split it rather than shaving bytes.

The one-stop version

The sitemap checker bundles all three checks. It validates against the sitemaps.org XSD, counts the URLs, flags anything over 50,000 or 50 MB uncompressed, and reports parse errors inline. Run it on every child sitemap and on the index itself after any regeneration, and treat a clean pass as the release gate for publishing the file.

Search Console Sitemap Report Troubleshooting: Couldn't Fetch, Noindex, and Discovered Errors

The Search Console Sitemaps report is the feedback loop for everything in this guide, and its statuses are precise if you read them literally. "Couldn't fetch" means Google could not retrieve the file at all. A URL error means the file was fetched but a specific entry failed. "Noindex" means a listed URL is explicitly blocked from indexing. Each maps to a specific fix, and none of them is a mystery once you stop reading the report as a verdict and start reading it as a checklist.

Couldn't fetch

This is a transport problem, not a content problem. The URL in the report is wrong, the file is missing, the server returns an error, or robots.txt blocks Googlebot from the file. Confirm the file exists at the submitted URL, returns a 200, and is not disallowed. A robots rule that blocks the crawler from /sitemap will produce exactly this status.

Noindex detected

Google is telling you the sitemap contradicts your own page directives. Somewhere a meta robots noindex, an HTTP header, or a robots rule is telling Google to keep the page out of the index while your sitemap asks it to crawl. Pick one. If the page should rank, remove the noindex; if it should stay out, remove it from the sitemap. The meta tags guide covers the noindex directive and where it hides.

Discovered errors

"Discovered, currently not indexed" is the most common non-error in the report, and it is usually not an error at all. It means Google found the URL, decided not to index it yet, and may index it later. The fix is rarely in the sitemap; it is usually in the page's quality, depth, and internal links, which is the subject of the next section. Re-validate the file first with the sitemap checker to rule out a mechanical cause, then look at the pages themselves.

Diagnosing the Discovered vs. Indexed Gap: Reconciling Search Console Against Your Sitemap Entries

The gap between what your sitemap lists and what Google has actually indexed is the most useful number in the whole system, and almost nobody reconciles it. You list 40,000 URLs. The Sitemaps report says 40,000 were discovered. The indexing report says 31,000 are indexed. The 9,000 in between are the gap, and each one is either a fixable problem or a signal that your site is carrying pages Google does not want.

The reconciliation is a three-way comparison. Take your sitemap's URL list, take the Sitemaps report's discovered count, and take the Page Indexing report's indexed and "Discovered - currently not indexed" lists, then diff them. A URL that is in your sitemap but absent from "Discovered" was never even seen, which points back at the file or at crawl access. A URL that is "Discovered - currently not indexed" was seen but not kept, which points at the page itself. Google Search Central (2025)

Discovered but never seen

If a URL is in your sitemap but never shows up as discovered, the problem is mechanical: the file was not fetched, the entry failed to parse, the URL is cross-domain, or the crawler could not reach it. Fix the file, confirm the crawl path, and resubmit. This bucket is the one your sitemap work actually controls.

Discovered but not indexed

If a URL is discovered but not indexed, Google saw it and passed. The causes are quality, depth, duplication, or crawl prioritization, and the fixes are page-level: strengthen the content, consolidate near-duplicates with a canonical, add internal links from pages that are already indexed, and remove thin pages you do not need. No sitemap edit will force these into the index, because the sitemap's job ended at discovery.

Reconciling in practice

Export your sitemap URLs, export the Search Console lists, and align them by URL. Work the "never seen" bucket as a sitemap and crawl problem, and the "not indexed" bucket as a content and links problem. The sitemap checker reconciles your sitemap entries against the Search Console Discovered-not-indexed status so you can see the two buckets side by side instead of pasting columns by hand, which turns a day of spreadsheet work into a list you can act on.

The 2026 Sitemap Checklist: Pre-Launch and Post-Launch Verification Steps

Here is the whole guide compressed into a checklist. Run the pre-launch half before you submit anything, and the post-launch half after Google has fetched the file, then re-run both on any major content change.

Pre-launch verification

• Every URL is absolute, on the same scheme and host as the sitemap file, and returns a 200.
• The file is UTF-8 and every ampersand is entity-escaped as &.
• No single file exceeds 50,000 URLs or 50 MB uncompressed; the index stays under the same caps.
• Redirects, 404s, noindex pages, and cross-domain URLs are removed.
• lastmod reflects the last real content change on each URL, not the generation date.
• priority and changefreq are removed or left at defaults, since Google ignores them.
• The file validates against the sitemaps.org XSD in the sitemap checker.
• robots.txt references the sitemap and does not block the crawler from fetching it, confirmed in the robots.txt tester.

Post-launch verification

• The Sitemaps report shows Success, not Couldn't fetch, and no parse errors.
• Discovered count roughly matches the URL count you exported, within the entries you actually submitted.
• Noindex warnings are resolved so the sitemap and the page directives agree.
• The Discovered-not-indexed bucket is triaged: mechanical fixes for unseen URLs, page fixes for seen-but-not-indexed URLs.
• On each new publish, only the changed URLs get a fresh lastmod, and the file is re-validated before it ships.

Work the list in order and the sitemap stops being a chore you regenerate and forget, and becomes a small, verifiable piece of infrastructure that quietly keeps Google pointed at the right pages. The checks are all free, and they take minutes, which is a better trade than a listicle that tells you to ping a dead endpoint.