TL;DR
- Google's John Mueller said in Search Off the Record episode 114 (1 October 2026) that the priority and changefreq sitemap fields were dropped.
- Mueller said lastmod is used only when dates in a file look reasonable; stamping every URL with today's date is ignored but not treated as spam.
- A 'Couldn't fetch' status for a valid sitemap can come from host load or low crawl demand, which Mueller said is very often based on perceived site quality.
- Mueller said llms.txt cannot be used as a sitemap in Google's systems, while RSS feeds can be submitted in Search Console as sitemaps.
Yes, XML sitemaps still matter, according to Google's John Mueller, but only some of what goes into them is used. In episode 114 of Google's Search Off the Record podcast, "Do sitemaps still matter?", published on 1 October 2026, Mueller told Martin Splitt, his colleague on the Search Relations team, that Google has dropped the priority and change frequency fields, uses lastmod only when the dates look believable, and treats a "Couldn't fetch" status in Search Console as something that can reflect site quality, not only a broken file. Mueller also said llms.txt cannot stand in for a sitemap in Google's systems today.
What the episode covered
The episode runs about 26 minutes and is published with chapter markers and a link to the full transcript on the Search Off the Record podcast page. Splitt framed it around the emails he receives from site owners who see something in Search Console about their sitemaps and worry. Mueller added some history: he said sitemaps are roughly 20 years old, that the idea was shared with Microsoft and Yahoo at the time and became a semi-standard that, in his words, "at least like three companies agreed upon", and that a Windows-based sitemap generator he built was how he ended up at Google.
Mueller said the original goal was simple discovery. Websites were messy and hard to crawl, so a list of URLs with change dates and priorities from the site owner helped a search engine decide where to focus, while still crawling to avoid missing anything. The rest of the episode explains which parts of that idea still hold.
Which sitemap fields Google still uses
Mueller was direct about the two fields Google no longer relies on. On priority, he said that when SEOs are asked to rank their own pages, "every URL is a maximum priority", so the field "ended up not being very useful". On change frequency, he said sites tend to mark everything as always fresh, partly because a server-side dynamic page is technically regenerated on every request, which is correct in theory but not useful. "I think those were the two fields that we dropped," he said.
Google's Search Central guide to building a sitemap already says the same in writing: Google ignores priority and changefreq values, and uses lastmod if it is consistently and verifiably accurate, for example when compared with the page's last modification.
What Google primarily focuses on, in Mueller's words, is the URL and the change date. He said the change date should be when the page last had major changes. Mueller described a "love-hate relationship" with lastmod: Google wants to use it, but many sites get it wrong. If the dates within a sitemap file look reasonable, Google will try to take them into account; if they do not, it focuses more on the individual URLs and processes new ones as they appear.
He also addressed the common shortcut of stamping every URL with today's date. Google will realise that it does not make sense to focus on those dates, he said, but "this is not like a spam thing" where spam systems would mark the site as bad. The episode description puts it the same way: Google evaluates date reliability and ignores lastmod if it is inaccurate or abused.
The table below summarises what Google's Search Relations team said about each sitemap element in the episode.
| Sitemap element | What Google said in episode 114 |
|---|---|
| priority | Dropped; sites marked every URL as maximum priority, so it was not useful |
| changefreq | Dropped; dynamic sites reported pages as always fresh |
| lastmod | Used when the dates in a file look reasonable, ignored when inaccurate; no spam penalty |
| URLs listed | List the canonical versions, without tracking or timestamp parameters |
| Size limits | 50,000 URLs and 50 MB uncompressed per file; index files can be nested once |
Does a small site need a sitemap?
Mueller said smaller websites "probably don't need a sitemap" because Google can simply crawl them. He then conceded that the threshold is hard for a site owner to judge, whether a site has 10 pages or 50, and gave a practical recommendation: keep the sitemap turned on. Almost all content management systems and even static hosting systems generate sitemap files by default, he said, and there is no harm in having one on a small site, whether it grows or stays small.
The sites that clearly benefit, in his account, are those with a non-trivial amount of content that changes regularly. He singled out news websites, noting that there is a separate news sitemap where, as he recalled it, publishers are only supposed to list the last 1,000 pages that changed. He also gave an e-commerce example: if a product price changes, normal crawling may notice late, whereas a sitemap that flags the changed product page lets Google go there directly.
Canonical URLs, size limits and file names
Splitt asked whether adding timestamps to URLs in a sitemap would force fresh versions to be used. Mueller said no. The sitemap should contain the URLs a site wants as canonical, in the form it wants them indexed, not with internal tracking tags or date stamps. If a static-looking URL has a date stamp appended, Google will try to index the version without it as canonical anyway. He added that Google also uses sitemap files when choosing canonicals: if several similar URLs are discovered and one of them is listed in a sitemap, "it's a little bit more likely that we will pick that as canonical."
On limits, Mueller gave 50,000 URLs and 50 MB per file, with the 50 MB measured uncompressed even if the file is gzipped. The episode description lists the same figures. Site owners can submit as many sitemap files as they want in Search Console, reference them in robots.txt, and use sitemap index files that link to other sitemaps, which can only be nested one level deep. Near the end, Splitt noted that hreflang can also be handled in sitemaps, and Mueller added that image and video sitemap extensions are still supported, although he questioned how important they are now that Google recognises images and videos on pages more easily.
File names are flexible. Mueller said a sitemap does not have to be called sitemap.xml and joked that it could be named after Splitt's cat. Some owners prefer an unusual name and leave it out of robots.txt so others cannot find it, which he called "perfectly fine", with a trade-off: the file then has to be submitted to Google directly through Search Console, and to Bing separately.
RSS feeds, AI crawlers and llms.txt
Mueller said an RSS feed can be used as a sitemap and can be submitted in Search Console as one. The difference is scope. A feed often caps the list at roughly the last 10 or 20 changed URLs with dates, so a system can see recent changes without working through every sitemap file of a large site. He said both are useful for finding new and updated pages.
The same naming trade-off applies to AI crawlers. Mueller said that AI training crawlers usually have no console where a site owner can submit a sitemap, so owners who want their content picked up should either keep the generic sitemap.xml name or rely on RSS feeds. He said he has seen AI crawlers access both his sitemap file and his RSS files in his own server logs, while noting he does not know whether those crawlers document this anywhere. He did not name the crawlers. For sites that care about visibility in AI systems, this is one of the few concrete, low-effort points in the episode, and it fits into broader generative engine optimisation work.
On llms.txt, Splitt asked whether it could replace the XML sitemap. Mueller's answer was "No." He described llms.txt as a markdown file that sometimes includes links, closer to an HTML sitemap than an XML one, and said "the hope is bigger than the reality". Google's systems cannot use it as a sitemap file because it lacks the strict format, and he said "currently none of this happens", though search systems might process markdown files in future. His advice was to focus on what works and is documented now, and not to rely on or prioritise llms.txt, even if a CMS generates one automatically.
HTML sitemaps got similar treatment. Mueller said they are maps for users, can be crawled like any other page of links, but cannot be submitted or processed as a sitemap file, and usually list categories instead of every product.
Why Search Console shows "Couldn't fetch" for a valid sitemap
The question that opened the episode came last. Splitt described a sitemap that validates, is publicly accessible and is listed in robots.txt, yet Search Console reports that it could not be fetched. Mueller said Google sees this a lot in its forums and gave two main reasons.
- Host load. Google's systems may not have time to fetch the sitemap because they are busy with other things, and that is reported as "Couldn't fetch".
- Crawl demand. If Google's systems decide they do not need to crawl much from a site, they may skip the sitemap because they already have enough. Mueller said crawl demand "is very often based on the perceived quality of a website", and that this can have a large impact on how much Google crawls and indexes.
"So it's not purely a technical thing," he said. Sometimes Google's systems assume the overall quality of a website is not fantastic and will not spend much time crawling it or bother with the sitemap. If the quality improves significantly over time, Google will go back to using the file. The episode description summarises this as host load throttling or low crawl demand linked to perceived site quality.
For practitioners, this changes the order of troubleshooting. A persistent "Couldn't fetch" on a valid, reachable file is a reason to look at crawl stats and content quality, not only to re-validate the XML. A structured SEO audit that covers indexing, crawl stats and thin or duplicate content is the natural next step when the file itself checks out.
What this means for Thai marketers
This section is analysis applied to the Thai market; nothing in the episode was specific to Thailand. Mueller's guidance is global, and it applies to Thai sites in a few direct ways. Mueller said almost all CMSs generate sitemaps by default, so for Thai sites on such a CMS the first check is whether lastmod values reflect real edits or simply the date the file was generated. Bilingual Thai and English sites that manage hreflang in sitemaps can keep doing so; Splitt noted in the episode that hreflang can be handled in sitemaps.
Thai e-commerce sites changing prices around 11.11 and 12.12 sales fit Mueller's e-commerce example exactly: accurate lastmod on changed product pages is the signal he described. Thai news publishers should check that their news sitemap holds only recently changed articles. And Thai site owners who see "Couldn't fetch" in Search Console should treat it, per Mueller, as a possible quality signal before rebuilding the file. Teams working on SEO in Thailand can fold these checks into their regular technical reviews.
What the episode did not say
- No new Google documentation or Search Console feature was announced; this was a podcast discussion.
- Mueller gave no threshold for how many pages make a site "small".
- He did not say how Google measures whether lastmod dates in a file are reasonable.
- He did not name the AI crawlers he saw in his logs or say how they use sitemap data.
FAQ: Google on XML sitemaps
Does Google still use the priority and changefreq tags in sitemaps?
No, John Mueller said in Search Off the Record episode 114 on 1 October 2026 that priority and change frequency were the two fields Google dropped. Google primarily uses the URL and the lastmod date.
Does Google penalise wrong lastmod dates?
No, Mueller said setting every URL to today's date is "not like a spam thing", but Google will stop relying on those dates. lastmod is used only when the dates in a file look reasonable.
Why does Search Console say "Couldn't fetch" when my sitemap is valid?
Mueller gave two main reasons: Google may be too busy with host load to fetch it, or crawl demand for the site may be low, which he said is very often based on the perceived quality of the website. If quality improves significantly, Google will use the sitemap again.
Can llms.txt replace an XML sitemap?
No, Mueller said Google's systems cannot use llms.txt as a sitemap because it lacks the strict format, and that "currently none of this happens". He advised against relying on or prioritising it.
Do small websites need a sitemap?
Probably not, Mueller said, because Google can crawl small sites, but he recommended keeping the CMS-generated sitemap turned on because there is no harm in having one.
Next step
A short checklist comes out of the episode: confirm the sitemap lists canonical URLs only, check that lastmod reflects real changes, consider submitting an RSS feed for recent updates, leave llms.txt as an experiment at most, and read a persistent "Couldn't fetch" as a prompt to review site quality. Teams that want a second pair of eyes on these checks can start with a technical review of indexing and crawl data.
