XML Sitemaps: Build, Submit, and Maintain a Clean Inventory

An XML sitemap is a machine-readable inventory of URLs you want search engines to discover. It is especially useful when a site is new, large, frequently updated, rich in media, or not perfectly connected through internal links.

A sitemap does not replace crawlable navigation. Search engines still evaluate canonical tags, robots directives, response codes, content quality, and internal links before deciding whether to index a URL. Treat the file as a clean feed of eligible pages rather than a complete export of your database.

Each URL belongs in a url element inside a urlset. The loc value must be an absolute URL using the canonical protocol and hostname. Optional lastmod values should use an ISO 8601 date or timestamp.

Include the preferred version of every useful public page. Exclude redirects, errors, duplicate parameter URLs, login areas, noindex pages, and URLs canonicalized somewhere else. Every sitemap URL should agree with the signals on the page itself.

A single sitemap is limited to 50,000 URLs and 50 MB when uncompressed. Sites that exceed either limit should create several sitemap files and list them in a sitemap index. Splitting by content type—products, articles, categories, videos, or locales—also makes coverage problems easier to diagnose.

Place the index at the root and child files alongside it or below it. Without Search Console submission, Google says a sitemap affects descendants of its parent directory. Cross-site hosting requires an explicit cross-submission setup; a different CDN hostname is not automatically authorized just because the file loads.

Generate sitemaps from the same canonical URL source used by your application. Remove deleted URLs promptly and update lastmod only after meaningful content changes. Search Console's Sitemaps report describes processing and discovered pages; use the Page indexing report filtered by sitemap and URL Inspection to investigate indexing decisions.

For SitemapKit, discover files first and extract their entries, then compare the returned inventory with the pages you actually want indexed. Extraction is not an indexability audit: check page responses, canonicals, and robots directives separately, and retain any partial-result flags.

Start with published content, not every route your router can serve. Join publication state, preferred URL, and indexing policy before serialization. A product draft, an account route, and a canonical article can all return 200; that alone does not qualify them for the search inventory.

Use an XML serializer and measure the resulting UTF-8 bytes, not source-string characters. Gzip reduces transfer size but does not raise the 52,428,800-byte uncompressed limit. Image, video, news, and localized-page extensions have additional rules; a basic loc export does not validate those annotations.

Fetch the deployed file without a logged-in browser session, validate it, and submit its exact URL under the matching Search Console property. Submission supplies a location; it does not upload a file to Google. Declare the absolute URL in robots.txt too. Google's old sitemap ping endpoint is deprecated, so do not add a ping request to the publishing job.

Successful processing does not mean every page was indexed. If processing fails, investigate the file's transport and syntax. If a page remains absent after processing succeeds, inspect its selected canonical, indexing reason, content, and internal links. Fix the evidence you find rather than repeatedly submitting the same file.