An XML sitemap is a machine-readable file that lists the pages and other resources a site owner wants search engines to discover. It can also provide useful metadata, such as when a page was last meaningfully updated or which language variants belong together.
A sitemap helps crawlers find important URLs, especially when those URLs are new, deep in the site, or not well linked yet. It is a discovery aid, not a command: inclusion does not guarantee crawling, indexing, or higher rankings. A sitemap also does not replace clear navigation and ordinary crawlable internal links.
Most sites can benefit from an automatically maintained sitemap, but it is especially useful when:
A small site whose important pages are all reachable through normal links may not strictly need a sitemap. Even then, a reliable CMS-generated sitemap is usually inexpensive to provide and gives search consoles a useful source of diagnostics. Do not use it as an excuse to leave valuable pages orphaned.
XML sitemap and HTML sitemap are different tools. An XML sitemap is primarily for crawlers. An HTML sitemap is a normal web page that can help visitors navigate. One does not automatically replace the other.
Standard XML sitemap. This is the familiar sitemap.xml file. It contains page URLs and may include metadata defined by the Sitemaps protocol. It should list the canonical URLs that you want eligible for search results.
Sitemap index. An index lists other sitemap files instead of page URLs. It is useful when a site exceeds the limits of one sitemap or when separate files are easier to monitor, such as sitemap-products.xml, sitemap-pages.xml, and sitemap-blog.xml. Its root element is <sitemapindex>, and every child <sitemap> contains the sitemap location in <loc>.
Image sitemap. Image data can be added to a regular sitemap or placed in a separate one. It is most useful for images that a crawler might otherwise miss, including some images loaded with JavaScript. For Google, each page entry may contain up to 1,000 <image:image> elements. The image URL belongs in <image:loc>. An image may be hosted on a CDN or another domain if the image remains crawlable and ownership of both sites is verified in Search Console. Older image fields for captions, titles, geographic locations, and licenses are deprecated by Google and should not be treated as current indexing signals.
Video sitemap. A video extension can identify videos on a page and provide a thumbnail, title, description, and either the media file URL or player URL. The page, thumbnail, player, and video resources must be accessible to the crawler. A video sitemap can improve discovery and understanding, but it does not guarantee a video result.
News sitemap. Google News publishers can add news metadata to a regular sitemap or maintain a separate news sitemap. Only articles published during the previous two days should retain the <news:news> metadata, and one news sitemap may contain no more than 1,000 news entries. Older article URLs may remain in a normal sitemap after their news metadata is removed.
Localized-page sitemap. An XML sitemap can declare language and regional alternatives with <xhtml:link> elements. Every variant must list the complete set of alternates, including itself, just as it would with page-level hreflang annotations.
Search engines may also accept a UTF-8 text file containing exactly one absolute URL per line, or an RSS or Atom feed. A text sitemap has no per-URL metadata, while a feed usually exposes only recent additions. XML is the most versatile format because it can provide a complete inventory and support extensions.
The following minimal example contains one page URL and an accurate modification date:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.example.com/guides/sitemaps</loc>
<lastmod>2026-09-18</lastmod>
</url>
</urlset>
<urlset> is the root element for a URL sitemap. Its xmlns attribute declares the Sitemaps protocol namespace.<url> contains the information for one URL.<loc> is required and must contain a fully qualified absolute URL of fewer than 2,048 characters, including the scheme and host. Use https://www.example.com/page, not /page.<lastmod> records when the page itself was last meaningfully modified, not when the sitemap was generated. Use a W3C Datetime value such as 2026-09-18 or 2026-09-18T14:30:00+00:00. Search engines may use a consistently accurate value to schedule recrawling. A false date that changes on every build can cause the signal to be ignored.
<changefreq> accepts always, hourly, daily, weekly, monthly, yearly, or never. <priority> accepts a value from 0.0 to 1.0 and is relative only to other URLs on the same site. Both elements remain part of the protocol, but Google and Bing ignore them. Unless another consumer specifically needs them, omitting them is clearer than generating arbitrary values.
Sitemap files must use UTF-8 and valid XML. Entity-escape special characters in data values. For example, an ampersand in a query string must appear as &, so a URL may be written as <loc>https://example.com/products?color=red&size=m</loc>. URL encoding and XML entity escaping are separate steps; both may be necessary.
A sitemap can have any valid filename; sitemap.xml is only a convention. Under the standard location rules, a sitemap normally covers URLs using the same scheme and host and at or below the directory in which the sitemap is stored. A file at https://example.com/catalog/sitemap.xml should not be expected to cover https://example.com/blog/post. Placing the sitemap or its index at the site root avoids this limitation. Cross-site submission is possible in supported search engines when ownership has been established, but it should be configured deliberately rather than by casually mixing hosts.
.xml.gz name, but the uncompressed file must still remain within the limit.Split a file as soon as either limit would be exceeded. Organizing sitemaps by stable content type can also make errors and indexing patterns easier to investigate. URL order does not indicate importance to Google, so there is no SEO benefit in placing selected URLs first.
A sitemap index has a structure of its own:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://www.example.com/sitemap-pages.xml.gz</loc>
<lastmod>2026-09-18</lastmod>
</sitemap>
<sitemap>
<loc>https://www.example.com/sitemap-products.xml.gz</loc>
<lastmod>2026-09-17</lastmod>
</sitemap>
</sitemapindex>
In an index, <lastmod> describes when the referenced sitemap file changed, not when every page inside it changed. Under Google's standard location rules, child sitemaps belong on the same site and in the index's directory or a deeper one unless cross-site submission is configured. Very large sites can submit multiple index files separately, but sitemap indexes must not be nested. Do not put page URLs directly in an index or mix <urlset> and <sitemapindex> in one file.
Submit the sitemap or sitemap index in Google Search Console, Bing Webmaster Tools, and any other webmaster service relevant to the site's audience, such as Yandex Webmaster. Submission provides processing status and error reporting; it still does not guarantee that every listed URL will be indexed.
Add the absolute sitemap URL to the site's root robots.txt file. Multiple Sitemap lines are allowed, although one index is usually easier to manage.
Sitemap: https://example.com/sitemap.xml
The directive is independent of a particular User-agent group and may appear anywhere in the file. Make sure the URL is the public production URL, not a staging or local address.
Old tutorials may recommend requests such as https://www.google.com/ping?sitemap=.... Google deprecated its sitemap ping endpoint, which now returns 404, and Bing discontinued anonymous sitemap ping submissions. Use Search Console or Bing Webmaster Tools for submission and diagnostics, and use robots.txt for automatic discovery. For rapid URL-level notifications to Bing and other participating engines, IndexNow may complement a sitemap, but it is a separate protocol and does not replace the site's complete URL inventory.
After submission, check whether the file was fetched successfully, when it was last read, how many URLs were discovered, and whether parsing or access errors were reported. In Google Search Console, use the Page indexing report filtered by sitemap and the URL Inspection tool to investigate indexing; the Sitemaps report alone is not a promise that every discovered URL is indexed. Server logs can confirm when crawlers fetch the sitemap and its URLs.
Generate it from the source of truth. For more than a few dozen pages, generate the sitemap from the CMS, routing system, or database rather than crawling the public site and saving a permanent snapshot. Update it when indexable URLs are added, changed, or removed. Scheduled regeneration is useful as a safety net, but the schedule should match the site's actual publishing pattern.
List canonical, indexable URLs. A page sitemap should normally contain the preferred HTTPS URL that returns 200 OK, is not blocked from crawling, does not require authentication, and is not marked noindex. Exclude redirects, error pages, internal search results, duplicate filter combinations, tracking URLs, and noncanonical variants. Keep URL casing, trailing slashes, hostnames, and protocols consistent.
Keep lastmod honest. Update <lastmod> when the primary content, structured data, or important links change in a way that matters to users, such as an article revision, product availability change, or important specification update. Do not refresh it merely because the sitemap ran, a copyright year changed, or an unrelated site-wide component was rebuilt.
Keep files stable and easy to diagnose. Use predictable names, split large inventories into meaningful groups, and place them under an index. A stable URL lets search engines refetch the same file. Separate product, article, video, or locale sitemaps when that division reflects how the site is maintained or when separate reporting is useful; creating thousands of tiny files adds overhead without an indexing advantage.
Make every required resource fetchable. Return a successful response for the sitemap itself, do not put it behind a login, and avoid blocking it in robots.txt. Image and video sitemaps also depend on the referenced media, thumbnail, and player resources being available to the relevant crawlers.
Preserve internal discovery. Important pages should still receive normal links from navigation, category pages, related content, or other relevant pages. A sitemap can reveal an orphan URL, but internal links provide context and let both users and crawlers reach it naturally.
Handle migrations deliberately. After an HTTP-to-HTTPS move, domain change, or URL redesign, generate a sitemap containing the new canonical destinations, update the robots.txt reference, and keep server-side redirects from the old URLs. Remove obsolete URLs from the current sitemap instead of using the file as a redirect inventory.
Including URLs with conflicting signals. A URL listed for discovery but also marked noindex, blocked by robots.txt, redirected elsewhere, or canonicalized to another page sends an inconsistent message. The sitemap should describe the URLs you actually want indexed.
Fabricating modification dates. Setting every <lastmod> value to the current time on every run does not make pages look fresher. Search engines can compare the date with the page and may disregard an unreliable signal. If the real modification time is unavailable, omit the element until it can be generated correctly.
Publishing malformed XML. Unescaped ampersands, a missing closing tag, invalid nesting, the wrong namespace, or non-UTF-8 output can make part or all of a sitemap unreadable. A generator can also fail and return an HTML error page with a 200 status at the sitemap URL, so inspect the response body as well as the status code.
Exceeding a protocol limit. A search engine may reject an oversized file rather than silently process the first portion. Count both URLs and uncompressed bytes, split the file before either reaches its maximum, and verify every child sitemap in the index.
Leaving a stale sitemap after a migration. Old hosts, old protocols, deleted paths, and expired staging URLs are common after a redesign. Regenerate the inventory and test a representative sample of URLs after every significant routing or platform change.
Treating sitemap removal as deindexing. Removing a URL from a sitemap only removes one discovery signal; it does not remove a page that a search engine already knows about. Use the appropriate page response or directive, such as 404, 410, authentication, or noindex, according to whether the content was deleted or should remain available outside search.
Assuming a sitemap fixes poor site architecture. A sitemap can help discover a URL but cannot repair weak content, duplicate pages, broken canonicalization, blocked rendering, slow or unreliable servers, or the absence of useful internal links.
WordPress has included core XML sitemap support since version 5.5. By default, the sitemap index is available at /wp-sitemap.xml, references public and publicly queryable content types and taxonomies, and is added to WordPress's virtual robots.txt. Core child sitemaps contain up to 2,000 entries by default, and developers can change or filter the generated inventory.
Check the existing endpoint before installing anything. SEO plugins such as Yoast SEO, All in One SEO, or Rank Math may replace the core sitemap with their own index and provide additional exclusion controls or specialized image, video, and news features. Use one intentional generator, not several competing outputs. Confirm that private, duplicate, redirected, and noindex content is excluded, then submit the active index URL to the search engines you use.
1C-Bitrix: Site Management includes a sitemap generator under Marketing > Search Engine Optimization > Sitemap Settings. Its configuration can select static files, sections, information blocks, and forums; generated child files are connected to the main sitemap. Autogeneration can update selected information-block or forum data when content is created, changed, or removed.
The generator also offers an option to add the sitemap rule to robots.txt. After generation, open the public file, confirm that it refers to the correct site and protocol, and sample the included URLs. Product configuration and custom modules can still expose noncanonical or nonindexable paths, so the generated result needs review rather than blind submission.
MODX installations do not all expose one universal core sitemap endpoint. On MODX Revolution, an extra such as pdoSitemap can generate XML from published resources. Another option is a dedicated resource with an XML content type whose template or snippet reads the site's resource tree and emits the required elements.
Whichever approach you choose, exclude unpublished, deleted, redirected, private, and noncanonical resources; generate real modification dates if available; and use caching that still allows the file to update when content changes. Package names and compatibility differ between MODX releases and between Revolution and Evolution, so check the current package documentation before installing an older tutorial's recommendation.
Dynamic generation on every request is not inherently better than a static file. Choose the approach that produces accurate output reliably without placing unnecessary load on the application. In every case, make the final sitemap publicly reachable, reference it from robots.txt, and monitor it through the relevant webmaster tools.
200 OK.noindex URLs are excluded.<lastmod> value represents a real, meaningful change to the corresponding page.robots.txt and submitted to the webmaster tools that matter for the site.A well-maintained sitemap gives search engines a clean inventory of the URLs and resources you consider important. Keep it accurate, make its signals consistent with the pages themselves, and use it alongside sound internal linking, canonicalization, crawl controls, and server monitoring. That combination improves discovery and diagnosis without making promises that a sitemap cannot keep.