TL;DR
- Search Engine Journal reported on 2 September 2026 that a Bluesky user asked John Mueller about adding a daily ?v= unix timestamp to child sitemap URLs inside a sitemap index.
- Mueller replied that having clean, stable URLs is important and pointed the poster to Tim Berners-Lee's page Cool URIs don't change.
- He did not say whether the technique changes crawl frequency, and the report contains no comment from him on lastmod values or on what crawl rate depends on.
- The lastmod explanation in the article came from Search Engine Journal, along with author Roger Montti's own criticism of SEO influencer hacks.
On 2 September 2026, Search Engine Journal reported that Google's John Mueller called it "a bad idea" to add cache busting on sitemap URLs, a technique in which the child sitemap URLs inside a sitemap index are given a fresh version parameter every day so that search engines refetch them. Mueller's objection was about URL stability rather than crawling: he said the practice signals that the canonical URL for a piece of content should be constantly changing, which is bad for search engines and bad for the site's own tracking.
What the technique is
Cache busting is an old and legitimate front-end practice. As Search Engine Journal explained in its 2 September 2026 article, site owners append a question mark and a parameter to the end of a CSS, JavaScript or image file name so that a visitor's browser downloads the freshest version instead of serving a stale copy from cache. Changing the parameter changes the URL, and a changed URL forces a fresh download while everything else can still be cached. The site loads quickly and the visitor still gets the current file.
The SEO version reported by Search Engine Journal moves that trick somewhere it was never meant to go. A Bluesky user posting as @seoharbour asked Mueller about adding a ?v= unix timestamp to the end of a sitemap URL inside a sitemap index. Asked to elaborate, @seoharbour said they had observed the behaviour on a large, rigidly structured site where the child sitemap URLs inside the index get a fresh ?v=timestamp every day, and guessed that the intent was to force a refetch by presenting a new URL each day. Their own question was whether the practice causes harm, since it is the URL changing rather than the lastmod value.
What Mueller actually said, and what he did not
Mueller's first response, quoted by Search Engine Journal, was a question rather than a verdict: "Why would you use cache-busting in a sitemap file? Perhaps I'm misunderstanding what your goal is though, feel free to elaborate!" After the explanation, he gave his answer.
The full quote reported by Search Engine Journal is this: "I think that's a bad idea because you're signaling that the canonical URL for a piece of content should be constantly changing. That's not good for search engines, it's not good for your tracking. Having clean, stable URLs is important." He closed by pointing at Tim Berners-Lee's page "Cool URIs don't change."
It is worth being precise about the boundaries of that answer, because the boundaries are where most of the reporting on stories like this goes wrong. Mueller did not say whether the technique increases how often Google fetches those sitemap files. He did not say it fails. He did not comment on lastmod values, on crawl frequency, on crawl budget, or on what determines how often Googlebot visits a site. Search Engine Journal's article contains no Mueller quote on any of those points. The one objection he raised was about signalling instability in URLs, and about the effect that has on search engines and on the site owner's own measurement.
The explanation of the lastmod element in the Search Engine Journal article comes from the publication, not from Mueller. Search Engine Journal described lastmod as the element that communicates the last date a file was modified, telling a crawler whether a file has changed and letting the crawler concentrate on pages that have changed. That is the publication's framing of why a stable sitemap with accurate dates is the intended mechanism. The article also notes that the original poster had seen a reference to accurate lastmod values in Google's developer blog and was asking whether the same principle applied.
The reported exchange in one table
The rows below are limited to what Search Engine Journal reported on 2 September 2026, including the point where the source says nothing.
| Item | What Search Engine Journal reported |
|---|---|
| The technique | Appending a ?v= unix timestamp to child sitemap URLs inside a sitemap index, refreshed daily, to force a refetch |
| Who described it | A Bluesky user posting as @seoharbour, who said they had observed it on a large, rigidly structured site |
| Mueller's first reply | Asked why anyone would use cache busting in a sitemap file and invited the poster to elaborate |
| Mueller's verdict | "A bad idea" because it signals the canonical URL for a piece of content should be constantly changing, which is bad for search engines and for the site's tracking |
| Not covered in the report | Any statement from Mueller on whether the technique changes crawl frequency, on lastmod values, or on what crawl rate depends on |
Why the objection is about identity, not about crawling
This section is analysis. The reason Mueller's answer lands on canonicals rather than on crawl rate is that a URL is an identifier before it is an address. When the same sitemap file is served at sitemap-1.xml?v=1756771200 today and sitemap-1.xml?v=1756857600 tomorrow, a crawler is being told that these are two documents, not one document fetched twice. Multiply that by a daily cycle and by however many child sitemaps a large site has, and the crawler is being introduced to a permanently growing set of URLs that all resolve to the same content.
The second half of his objection is the part site owners underrate. He said it is not good for the site's own tracking, and that is immediately checkable. Log analysis, crawl-stats reporting and any internal dashboard that groups requests by URL will now scatter one sitemap's history across a new row every day. The site loses the ability to answer a basic question: how often is this sitemap being fetched, and is that rate changing.
There is also a plainer point. A parameter that changes daily guarantees a new URL. It does not guarantee that a crawler treats the new URL as urgent, and it certainly does not guarantee that anything inside the sitemap gets indexed. Fetching a sitemap and indexing the pages it lists are separate events, and no amount of activity in the first produces the second.
What actually influences crawling, framed as analysis
Nothing in this section is attributed to Mueller, because the Search Engine Journal report does not include him saying it. What follows is standard practice for diagnosing crawl problems.
- Server response time. A site that answers slowly gets fetched more cautiously, and this is one of the few crawl inputs a site owner directly controls. Crawl stats in Search Console show average response time next to request volume, which makes the relationship visible.
- Whether content genuinely changed. A sitemap that claims daily modification for pages whose content is identical trains a crawler to stop believing the file. Accurate lastmod dates are worth more than frequent ones.
- Error rates. A rising share of 5xx responses, timeouts, or soft 404s tends to reduce crawling long before anyone notices a ranking effect.
- URL stability and duplication. Parameters that create additional addresses for the same content spend crawling on documents the site does not need discovered, which is the exact pattern the cache-busting technique manufactures on purpose.
- Whether the pages deserve fetching at all. Thin, near-duplicate or orphaned pages get crawled less over time, and no sitemap signal reverses that.
The order matters for anyone chasing crawl problems. Sitemap syntax is the last place to look, not the first, and a technical audit that measures response times and error rates will explain a crawl pattern far more often than a sitemap tweak will change one.
The part of the article that is opinion
Search Engine Journal's article does not stop at reporting the exchange. Author Roger Montti added a section arguing that this kind of technique is what happens when an SEO influencer who does not actually know SEO invents hacks that sound good on paper and sound ridiculous to SEOs who understand how markup languages such as XML and HTML work. He pointed out that XML stands for Extensible Markup Language and has rules that a site owner can follow to communicate with a crawler without hacks.
That commentary is the publication's, not Google's, and the distinction is worth keeping because the two get quoted together. The Google position in this story is one sentence long: cache busting on a sitemap is a bad idea because it signals unstable canonical URLs.
What the report did not say
The article gives no evidence about outcomes. It does not say the large site described by @seoharbour lost rankings, gained rankings, was crawled more, or was crawled less. The original poster did not name the site, and Mueller did not review it. No before-and-after data appears anywhere in the report.
There is also no statement that Google penalises this practice, no timeline, no product change and no documentation update. Mueller was answering a question on social media, not announcing anything. Anyone repeating this story as "Google confirms sitemap cache busting kills crawling" is adding a claim the source does not contain.
What this means for marketers in Thailand
Large Thai sites have structural reasons to care about this one. Property listings, job boards, e-commerce catalogues and classified sites carry the deep sitemap indexes where a technique like this gets applied by a developer who read about cache busting in a front-end context and applied it where it does not belong. The check takes a minute: open the sitemap index, look at the child URLs, and see whether they carry a parameter that changes.
Bilingual sites have a second reason. When Thai and English versions of a page are tied together by canonical and hreflang declarations, anything that makes canonical URLs look unstable adds noise to an area that is already the most common source of indexing faults on Thai-English sites. Teams working on SEO for Thai and English versions of the same site should confirm that every URL in the sitemap is the same URL declared as canonical on the page, with no parameters attached.
There is a wider point about where effort goes. Stable URLs are also what AI answer engines cite, and a citation pointing at an address that changes daily is a citation that breaks. Sites investing in visibility inside AI answers have the same reason as search crawlers to want one durable address per document.
FAQ about sitemap cache busting and crawling
Does adding a timestamp parameter to a sitemap URL make Google crawl it daily?
The Search Engine Journal report of 2 September 2026 does not answer that, because John Mueller did not address crawl frequency in his reply. He said the practice is a bad idea because it signals that the canonical URL for a piece of content should be constantly changing, and gave no assessment of whether it changes how often the file is fetched.
What exactly did Mueller object to?
He objected to the signal about URL identity, saying "I think that's a bad idea because you're signaling that the canonical URL for a piece of content should be constantly changing. That's not good for search engines, it's not good for your tracking. Having clean, stable URLs is important." He referred the poster to Tim Berners-Lee's page "Cool URIs don't change."
Is cache busting itself bad practice?
No, and Search Engine Journal described it as a legitimate technique for CSS, JavaScript and image files, where a changed parameter makes a browser download the freshest version instead of a stale cached one. The problem reported in the article is applying it to sitemap URLs, which are meant to be stable addresses.
What does the lastmod element do?
Search Engine Journal described lastmod as the element that communicates the last date a file was modified, which tells a crawler whether a file has changed and lets it focus crawling on pages that have changed. That description comes from the publication; Mueller made no statement about lastmod values in the exchange the article reports.
How should a site owner diagnose slow crawling instead?
Start with Search Console crawl stats, server response times, error rates and whether the pages in question genuinely changed, none of which the source discusses but all of which are measurable on the site itself. Manipulating sitemap URLs addresses none of these, and it removes the ability to track a single sitemap's fetch history over time.
Where to go from here
The practical action from the 2 September 2026 report takes a few minutes. Open the sitemap index, confirm that every child sitemap URL is stable and parameter-free, confirm that the URLs listed inside match the canonical URLs on the pages themselves, and make sure the lastmod dates reflect real changes rather than a nightly script. If crawling still looks slow after that, the evidence lives in crawl stats and server logs rather than in the sitemap file. The full write-up is at Search Engine Journal.
