Why Fix the Same Defect on Only One Site? Sitemap lastmod and Changes During an Experiment

This article was first published in Korean by Intrix Lab on August 10, 2026.

We found the same defect on two sites but fixed only one. The sitemap's lastmod contained the time a database batch ran rather than the time the content changed. We fixed our company site immediately, increasing the number of unique lastmod values from 21 to 86. On the dermatology information site we operate directly, we left it unchanged and started with 14 days of monitoring. That site is running a randomized controlled trial (as of 2026-08-11).

What was wrong?

A sitemap's lastmod value indicates "when this page last changed." On both sites, that field contained the database write time.

On our company site, there were only 31 unique values across 89 entries. Of those entries, 41 had 2026-08-06T02:13:11.569Z, identical down to the millisecond. A person cannot edit 41 articles in the same millisecond. The timestamp from a bulk update was being served unchanged.

The problem was more pronounced on the larger dermatology information site. All 3,584 sitemap entries had values from the most recent 8 days, with only 6 unique values. The system advanced the update timestamp whenever an internal process touched the data, even if no content changed.

Why is this a problem?

Only a tiny portion had actually changed. In one week, 17,792 of 17,820 entries were unchanged (99.84%), yet all received new update timestamps.

As a result, the sitemap repeatedly reported each week that "all 3,584 entries were modified within the past week." If search engines determine that lastmod is consistently inaccurate, they ignore the value entirely. Instead of providing a signal, the site was causing that signal to be discarded.

Why did we fix the company site immediately?

It was not part of an experiment. We changed it to serve the actual publication time rather than the bulk update time. The result was 21 → 86 unique lastmod values, with the number of pages sharing the same timestamp falling from 60 → 3. The remaining 3 articles were actually published at the same time.

There was also relevant context. At the same point, indexing stood at 65 indexed / 68 not indexed, or 48.9%. Of the 68 unindexed pages, 42 were marked "Discovered - currently not indexed," meaning their URLs were known but they had not even been crawled.

However, we will not claim that this defect caused those 42 pages to remain unindexed. A new domain's crawl budget or lack of external links may be larger factors. What we can establish now is only that "there was a fixable defect, and we fixed it." Its effect needs to be checked in the next indexing report.

Why did we leave the dermatology site unchanged?

That site is running a randomized controlled trial with 1,991 hospital pages divided into four groups (starting 2026-08-10, ending 10-05). Changing something else during the experiment would introduce a co-intervention.

The trade-off is unfavorable. The potential gain from the fix concerns search crawlers and indexing, while the risk concerns AI bot visits, the very outcome variable of this experiment. We would be putting a metric we are measuring at risk to gain something in a metric we are not measuring.

This would not introduce bias. The change would apply to every page regardless of group, so random assignment would account for it. The issue is statistical power. If removing the "updated every week" signal reduces total crawling, there will be fewer observations. In an experiment with a count-based outcome, fewer observations reduce statistical power.

What evidence will guide the decision?

There is one main unknown: do AI crawlers read sitemap lastmod values? Search engines have documented their use of lastmod for scheduling. Whether AI crawlers do the same has not been confirmed.

So, instead of applying the fix, we decided to first check whether AI crawlers actually fetch the sitemap. We also set and documented the decision criteria before starting the check. Setting criteria after seeing the results would be post hoc rationalization.

We set the decision date as 2026-08-25. If AI crawlers make 0 sitemap requests, we will apply the fix. If there is even 1 request, we will freeze changes until 10-05.

How far can this judgment be trusted?

This test supports a conclusion in only one direction. "0 requests" means there is no risk, but "1 or more requests" establishes only that the sitemap was fetched. It does not prove that lastmod is used for scheduling. That is why we committed to freezing changes, rather than conducting "further investigation," if there is 1 or more requests. We will not accept the risk while the answer remains unknown.

We will not overstate the scale, either. The number of unindexed pages on the dermatology site is an order of magnitude larger than the 3,584 clinic URLs. Most are automatically generated pages combining locations and procedures, and there is no evidence that this defect is the main cause of their lack of indexing. All we can say now is that it is a real defect worth fixing.

We do not guarantee rankings, citations, or indexing. This article answers only how we handled the same defect differently on two sites and what evidence informed that decision. We will publish the decision results on this Lab page regardless of statistical significance.

Frequently asked questions (FAQ)

Q. How can we check whether our site has the same problem?
Download the sitemap and count its unique lastmod values. If there are extremely few unique values relative to the number of URLs, or multiple pages share values identical down to the second or millisecond, batch write timestamps are likely being exposed.

Q. What about removing lastmod entirely?
That is better than inventing a value you do not know. We also chose to omit it for entries where the value was unknown. If you can provide an accurate value, however, including it is preferable.

Q. Does running an experiment mean we cannot fix anything?
No. The decision criterion is "does this change affect the outcome variable?" If there is evidence that it does not, you can apply the fix. If there is no evidence, you should gather it or wait. In this case, we chose to gather evidence.