Let’s talk about the conclusion first: the priority field in XML sitemap has no effect on ranking. Google has publicly stated that it will not read it. The same is true for changefreq. The only column that is actually read and directly affects the crawling efficiency of the AI crawler is lastmod. If you set the lastmod of all URLs to the current day every time your sitemap is generated, you are not helping the crawler, you are training it to no longer trust this list. This article is going to talk about how to set the XML sitemap as a change record that crawlers are willing to accept, so that GPTBot, ClaudeBot, and PerplexityBot can crawl your latest page with the minimum number of crawls.
The job of sitemap is not ranking, but crawling and indexing efficiency
Sitemap will not push any page up in the ranking. It is a list of "these URLs exist and these have recently changed." For small sites with less than a few hundred pages and clean internal links, it actually doesn’t make much difference whether they have a sitemap or not. Google can find them all in just one search. The scenarios where it is really valuable are concentrated: the website is large, there are deep or orphan pages that no one can connect to, the content is updated frequently, or you want the crawler to notice a certain change as soon as possible. AI crawlers are particularly sensitive to this list because their crawl budget is smaller than Google's, and they don't have a backend like Search Console to submit, so they can rely on fewer leads than you think.
lastmod: The only field that is still read and the most easily messed up.
Google is consistent here: it will refer to lastmod, but only if the value is honest. Once the system discovers that every time you regenerate the sitemap, it will write the lastmod of the entire site as today, and it will directly reduce the credibility of this field to zero. After that, even if you really change important content, the signal will not be transmitted. Therefore, lastmod should reflect the moment when the content substantively changes, not the template adjustment, nor the timestamp of a site-wide redeployment. In this regard, the default settings of most CMSs are wrong.
- Use W3C Datetime format with time zone, for example 2026-07-02T14:30:00+08:00, don’t just write a date.
- Only update when the content substantively changes: fixing typos, changing a decorative image, or fine-tuning CSS does not count.
- Don’t use the website build time or the updated_at of the database directly as lastmod, as this will falsely report the entire site’s updates every time it is deployed.
- Each sub-file in the sitemap index must also have its own lastmod, which points to the last real change in the group.
- If it is technically impossible to do an honest lastmod, it would be better to leave the entire field blank than to report "today" to the whole site every day.
priority and changefreq: no one is looking at it after filling it out
Google engineers have made it very clear in public: priority is not considered at all, and the same is true for changefreq. Bing's attitude is similar. If your CMS auto-populates these two fields, it’s fine to leave them in, but don’t send an engineer to figure out whether a page should be given a 0.8 or a 0.6, that number won’t change any crawling or ranking results. The only place where priority is somewhat useful is to force you to figure out which pages are the most important, and that's for you, not the algorithm.
How does AI crawler find and use your sitemap?
AI crawlers such as GPTBot, ClaudeBot, PerplexityBot, CCBot, and Google-Extended do not have Search Console that allows you to submit URLs. Their most stable discovery channel is only one: the Sitemap directive in robots.txt. Without this line, you can only expect them to creep in along the links. Once declared, the correct lastmod will cause them to skip unchanged pages and spend the limited number of crawls on new content, which is exactly what you want, because the goal of GEO is to be referenced, not to be crawled to the server.
How to dismantle the sitemap of a large website to maximize indexing efficiency
There is a hard limit on a single sitemap file: up to 50,000 URLs, or 50MB uncompressed, whichever comes first. If it exceeds the limit, it must be split, and then a sitemap index will be used to unify them, and the index itself can accommodate up to 50,000 sub-sitemaps. In practice, the better approach is not to wait until the files are exploded before splitting them, but to group them according to content types from the beginning. In this way, you can see the index coverage of each group in Search Console, and which content group has indexing problems can be seen at a glance.
- Grouped according to content type: sitemap-blog.xml, sitemap-docs.xml, sitemap-product.xml, each reporting coverage independently.
- Each file should keep the upper limit of 50,000 URLs or 50MB uncompressed. If it exceeds the limit, it will be split and consolidated using sitemap index.
- Use gzip to compress large files into sitemap.xml.gz, which is allowed by the protocol and saves bandwidth.
- Concentrate high-value pages that are most likely to be referenced by AI, such as pricing, comparisons, FAQs, and cases, into those pages that are updated frequently and have the most accurate lastmod.
- Don't include URLs that are noindexed, canonically pointed to other pages, or return 4xx/5xx, as this will dilute the credibility of the entire list.
Stop pinging: What to do about change notifications after 2023
Google has disabled the ping endpoint of sitemap in 2023, and Bing has followed suit. Now making requests to /ping?sitemap= will have no effect. There are three levels of alternatives: maintain an accurate lastmod so that crawlers can judge whether to re-crawl when returning at their own pace; submit the sitemap once in Search Console without sending it repeatedly; and for Bing and Yandex, use IndexNow to push change notifications at the URL level in real time. It should be reminded that Google does not eat IndexNow, and most AI crawlers only rely on their own return visit schedule plus your lastmod, so the real lever that affects all crawlers at once is the discipline of lastmod.
Pre-go-live sitemap checklist
- robots.txt has a Sitemap directive that points to a publicly accessible sitemap URL.
- lastmod reflects real content changes, the format is time zone, and there is no situation where the entire site is on the same day.
- Sitemap only retrieves 200 indexable pages, excluding noindex and canonical URLs.
- A single file does not exceed 50,000 URLs or 50MB. Large sites use sitemap index to group them by content type.
- Submit it once in Search Console and check whether the "explored" number matches the actual number of pages.
Get these few things right, and your sitemap will go from a routine file that no one trusts to a source of changes that crawlers and AI engines are willing to adopt. The problem for most teams is not that there is a missing page, but that the whole site is lying in lastmod and a bunch of non-indexable URLs are mixed into the sitemap. These will be revealed when you scan them with tools from the outside. If you want to know where your sitemap and overall technical AEO settings are missing, you can schedule a 30-minute GEO diagnosis (/contact), and we will directly point out the most important points to fix first.
