Two unrelated John Mueller answers went out this week, three days apart, both covered by Search Engine Journal. One was about a sitemap trick. The other was about a link disavow. They don't look connected until you notice they're both answers to the same underlying question: what do you do when you're not sure your SEO signals are working, and the honest answer is "wait, and don't touch it."
The cache-busting sitemap trick
The first question came from a Bluesky user running a large, rigidly structured site, who'd noticed that appending a changing URL parameter to child sitemap URLs in a sitemap index (something like a Unix timestamp as ?v=) makes crawlers refetch those sitemaps daily, instead of relying on whatever cadence they'd otherwise choose. It works because it looks like a new resource each time rather than a cached one.
Mueller's answer was blunt: "I think that's a bad idea because you're signaling that the canonical URL for a piece of content should be constantly changing." He tied it back to the old REST principle that cool URIs don't change, and pointed out that the entire point of a sitemap's <lastmod> element is to tell a crawler when something actually changed, so it can prioritize freshness on its own. A cache-busting parameter fakes that signal on every single request whether or not anything changed, which is the opposite of what the field exists for.
This site's own sitemap config already does it the boring way, which is worth spelling out because I set it up that way before this story existed, not in reaction to it. The xmlsitemap module config in sync/ gives articles and pages priority: 0.5, turns on prefetch_aliases so the sitemap emits real URL aliases instead of internal node paths, and pings exactly one search engine, Google, with a minimum_lifetime of 86400 seconds so a burst of edits in one day produces at most one re-ping instead of one per save. None of that manufactures freshness. <lastmod> comes from each node's actual changed timestamp, and if nothing changed, the sitemap says so truthfully instead of pretending otherwise to get crawled more often. The cache-busting trick and this config are solving the same problem, crawl priority, but one of them is lying to get it and one isn't.
The disavow that "broke" rankings in two weeks
The second question was a panic post: someone had disavowed more than 800 links they considered toxic, including guest posts they'd bought on Fiverr, and watched rankings drop within two weeks. They wanted to know if the disavow caused it and how to undo the damage fast.
Mueller's response separated two different clocks. Fixes for "bigger algorithmic changes," his phrase, can take "quite some time, sometimes many months" before the effects show up at all. Technical mistakes, like accidentally blocking a page, resolve fast once corrected. A disavow file sits in the first category: he's previously said elsewhere that disavow submissions take three to six months to show any effect, incrementally, not all at once. So a ranking swing that shows up two weeks after filing one almost certainly has some other cause, and his actual advice was to double-check the disavow file matches what was intended and look for an unrelated technical problem, not to assume cause and effect from timing that doesn't fit the mechanism.
I don't have a recovery story of my own to compare this against, and I'm not going to manufacture one. This site added the drupal/redirect module a little over a week ago, specifically to retire duplicate article URLs that had accumulated, with 301s issued per-environment via drush rather than tracked in config. If that change moves anything in how this site gets crawled or ranked, on Mueller's stated timeline I wouldn't expect to see it for months, and checking search performance daily for a jump would just be running the same experiment as the disavow poster, on a fix that isn't even a disavow. The honest state of that change right now is: applied, unverified, too early to have an opinion about its effect either way.
The pattern under both
What connects a clever sitemap hack and a panicked disavow read is that both are attempts to get feedback faster than the actual system provides it. Google doesn't expose a live dashboard for "is my canonical signal healthy" or "did that disavow work yet," so people build proxies: force a daily refetch and treat that as a health signal, or watch rankings for two weeks and treat any movement as an answer. The proxy always breaks something else, either your canonical stability or your ability to reason about cause and effect, because it's optimizing for visibility into the system rather than for the system actually working.
The boring alternative in both cases is the same: use the field that already exists for the thing you're trying to signal, <lastmod> for freshness, a correct disavow file for link quality, and accept that the feedback loop is slow because the underlying process is slow, not because you're doing it wrong. That's a harder thing to sit with than a trick that produces a number to watch, but the trick's number isn't measuring the thing you actually care about either.