Does Changing the Date on a Page Help SEO? We Re-Dated 60

Q: Does changing the date on a page help SEO?

Not in any way we could measure. A commit hook moved the date on 60 list pages on game-scout.app with no edit to their copy. Over the next 12 days, 26 clean re-dated pages grew impressions 28.4% and clicks 25.6%, against 27.0% and 32.0% for 38 pages whose date did not move. The sample is one site, and the hook chose by template, not at random.

Q: Does Google recrawl a page when its lastmod date changes?

Not reliably, on what we saw. Two weeks after the change, 11 of 24 re-dated pages had been crawled since, against 22 of 35 pages with no new date, and 10 re-dated pages still showed a last crawl from before October. Google downloaded the sitemap on 27 October. Google says it uses lastmod only when the date is consistently and verifiably accurate.

Q: Will Google penalize me for changing dates without changing content?

We saw no drop we could tie to it: 26 re-dated pages grew about as fast as the pages left alone. That does not make it safe. Google's helpful content guidance lists changing dates to seem fresh as a warning sign, and a sitemap date that keeps proving wrong gives Google a reason to stop using it. We cannot see that trust from outside.

Q: How do I know if my site is changing dates by accident?

Count the dates in your sitemap. Fetch it, pull out every lastmod, and count how many URLs share each day. If a large share of pages carry one date and you did not edit them that day, a build step or a hook is writing it. Then read the commit from that day and check whether any reader-visible text changed.

By Ugur Saritepe · November 2, 2026

Changing the date on a page did not help on our site. A commit hook moved the date on 60 game-scout.app list pages on 19 October with no edit to their copy. Against 38 pages it skipped, impressions grew at the same pace, clicks grew slower, and a smaller share got recrawled.

We did not plan this test

game-scout.app is my other site, a catalogue of curated game lists. On 31 August we added a pre-commit hook that sets lastUpdated to today on any list file using our newer templates, in place of typing the date by hand. That one date feeds three things: the sitemap's lastmod, the dateModifiedin the page's markup, and the updated date a reader sees.

On 19 October a code change added one required field to 128 list files. It was live that night. The hook saw 60 of those files on a newer template and did its job:

   slug: 'best-hunting-games',
+  platform: 'playstation',
   template: 'v2',
...
-  lastUpdated: '2026-08-31',
+  lastUpdated: '2026-10-19',

The hook skipped the 68 lists on the old template, so one commit split the catalogue in two. I did not choose the pages by how they were doing, which is what spoils most before and after reads. The same commit also added store prices to every list card, on both sides of the split, so the prices cannot explain a gap between them.

To keep the read clean I took out any list with another commit since 1 October, any list with a date already in October, and any list published after 20 September. That leaves 26 re-dated lists, whose old dates ran from 31 August to 17 September, and 38 lists whose date did not move.

Did Google come back for the new date?

Not in a way that shows up. Crawling is what a new date should move first, since a sitemap date is a hint about what to fetch. The latest crawl for every list, read two weeks after the change:

              crawled on or after 10-20    last crawled before October
re-dated      11 of 24                     10
not re-dated  22 of 35                      4

Two of the lists behind those counts, asked one at a time:

get_index_status

game-scout.app/best/best-star-wars-games, then best-horror-games

result

best-star-wars-games  Submitted and indexed  lastCrawlTime 2026-09-13
best-horror-games     Submitted and indexed  lastCrawlTime 2026-09-01

2026-11-02

Google downloaded the sitemap on 27 October, so it had the chance to see those dates. Our horror list had told it for over a week that the page changed on 19 October, and the last fetch was still 1 September. Two lists in the first group and three in the second have no crawl date at all.

This does not show that the new date put Google off. The lists left alone earned about 9 clicks a page in the window before the commit, against about 5, and they are older, so more crawling there is not surprising. It shows a narrower thing: 60 new dates did not produce a visible rush of crawling.

Did clicks or impressions move?

Both groups rose by about the same amount. These are three windows of 12 days with the same weekdays, untruncated, from Search Console:

              09-21..10-02   10-05..10-16   10-19..10-30   change
re-dated (26)
  clicks           102            125            157       +25.6%
  impressions    6,674          7,311          9,385       +28.4%
not re-dated (38)
  clicks           373            334            441       +32.0%
  impressions   21,451         20,151         25,595       +27.0%

Average position on the re-dated lists went from 9.18 to 9.94, and on the others from 8.58 to 8.47. Impressions differ by 1.4 points, and 26 pages with 157 clicks cannot separate a gap that small from noise. The re-dated group was also already rising before the commit, up 22.5% in clicks, while the other group fell 10.5%, so the two were not moving together to begin with.

On our site, moving the date on 60 pages with no new content bought nothing we could tell apart from the pages left alone.

The jump that looked like proof

Five days after the commit, the whole site stepped up. List clicks went from 93 on 23 October to 151 on 24 October. Read by itself, that looks like the date working. Split by group, it does not:

clicks a day          10-19..10-23   10-24..10-30
re-dated (26)                 12.6           13.4
not re-dated (38)             30.6           41.1

The pages with no new date took most of the jump. Impressions a day rose in both, 704 to 838 and 1,965 to 2,253. If I had only re-dated pages to look at, I would have credited the date with whatever Google did that week. We still do not know what caused the step. It is the same trap as telling whether an SEO change worked with no group to compare against.

What it did cost: our own routine stopped

The commit had a real cost, on our side rather than Google's. We run a routine that refreshes one stale list at a time, and it will not touch a list edited in the last 30 days. It read that commit as an edit to all 128 lists. From about 23 October its pool was empty, and the scheduled runs ended with nothing to do. It surfaced when I asked for more of them:

lets change our scheduled task/skills for refreshing lists. Lets increase daily refresh to 3 instead of 1 list

The session found the cause in about a minute: tripling the runs would have produced three empty runs a day until around 18 November. The fix went in on 1 November and the routine picked a list that morning. The routine was reading the commit, not the date field, but it is the same mistake the hook made: treating a change to a file as a change to the page.

What the ranked pages say

The articles I read for this question on 2 November agree that a new date on unchanged content does not help. Reddit holds position 1, one Squarespace post near the top says by its snippet that a new date may help, and the articles from LockedownSEO (2021), CMSWire (2021) and Digital Applied (October 2026), argue it from Google's statements. None of those three reports a measurement. Our result agrees with them; what it adds is a group of re-dated pages next to a group left alone.

Google's own lines are short. Its sitemap documentation (updated July 2026) says it uses lastmod only when the date is consistently and verifiably accurate, and that it should mark a significant update, which a copyright year is not. Its helpful content guidance (updated October 2026) lists "changing the date of pages to make them seem fresh" as a warning sign. There is more on how sitemaps work in what an XML sitemap is, and the same no-visible-effect result for a markup change in our schema test.

What we have not done

We have not put the dates back. 59 of the 60 lists still say they were updated on 19 October, in the sitemap, in the markup and on the page, though the only change they got that day was the store prices every list got. We have not changed the hook either: it still stamps today's date on any staged list file, so the next bulk commit will do this again. The 1 November fix only taught the refresh routine to ignore this one commit.

There are also two things this read cannot tell you. Twelve days is short. And if Google stopped trusting our sitemap dates because of this, nothing in these numbers would show it.

How to check this on your own site

Count the dates in your sitemap. This prints how many URLs share each date:
```
curl -s https://example.com/sitemap.xml \
  | grep -o '<lastmod>[^<]*' | cut -c10-19 \
  | sort | uniq -c | sort -rn | head -5
```
Good: counts spread over many days, each matching work you remember. Bad: one date carrying a large share of the site, or today's date on everything, which usually means the build writes it.
Read the commit from that date. If no reader-visible text changed on those pages, the date is wrong. Look for a hook, a build step or a CMS setting that writes it.
Stamp from the content, not the file. Move the date only when the title, body or list of items changed. A new config field, a dependency bump or a link re-cut should leave it alone.
Read the last crawl before you credit a date. Compare the last crawl date against your lastmod. Good: the crawl is later and the page really did change. Bad: months-old crawl under a fresh date. Then compare clicks against pages whose date did not move.

If you want to confirm your sitemap itself is being read, the free triage report checks it from the URL alone. The rest of these measured reads are in the AI-assistant SEO series.

FAQ