The question comes up in almost every conversation about an existing site: how often do I have to change something so that Google takes the site seriously? Behind it sits a sound worry and a crooked assumption. The worry is fair, because pages really do go stale. The assumption is that there is a frequency, a rhythm you can keep to. There is not, and that is not an opinion: Google answers the question in its own documentation, in brackets. This piece covers what happens when you set out to update your website, what actually counts, and how to tell which page is next.
What happens if you only change the date?
Nothing, and Google writes that down itself. Its guide "Creating helpful, reliable, people-first content" lists self-assessment questions for deciding whether you are writing for people or for search engines. Two belong here, verbatim: "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" And immediately after: "Are you adding a lot of new content or removing a lot of older content primarily because you believe it will help your search rankings overall by somehow making your site seem 'fresh?' (No, it won't)".
That bracket is the whole argument in three words. Both questions sit in a section headed "Avoid creating search engine-first content", and the document carries a last-updated stamp of 10 December 2025. The telling word is "substantially" in the first question. It reappears in the second place where Google discusses dates. The documentation on byline dates says: "A byline date is the date that Google estimates that the web page was updated or published." And further: "Google doesn't depend on a single date factor because all factors can be prone to issues. That's why our systems look at several factors to determine our best estimate of when a page was published or significantly updated."
So Google estimates when you last changed something substantially, and draws on several signals to do it. Your date field is one of them, not the source of truth. Change only the date and you have changed a statement about an edit that never happened.
How often does Google fetch your pages anyway?
That can be measured rather than guessed. On 5 September 2026 we ran all 55 posts on this blog through the Search Console URL Inspection API and asked when Google last fetched each one. For 52 of the 55 Google returns a date; three return none.
The interesting figure is not the median but the spread. If Google followed a rhythm we set, the age of the posts would show up in the intervals. It does the opposite.
The three oldest posts on the blog, 119 to 139 days old, were last fetched 9, 18 and 18 days ago, comfortably ahead of the median of 28 days. At the same time nine posts have not been fetched since the day they went live, the oldest of them for 56 days. Age tells you almost nothing about the crawl rhythm. Google's crawl budget documentation explains why: "Crawl demand varies based on a site's size, update frequency, page quality, and relevance", with "Popularity: URLs that are more popular on the Internet tend to be crawled more often" and "Staleness: Our systems want to recrawl documents frequently enough to pick up any changes" among the factors. That is a demand model, not an editorial calendar.
Is crawl budget your problem at all?
Almost certainly not, and that sits in the same document. Google states plainly who the guidance is for: "Large sites (1 million+ unique pages) with content that changes moderately often (once a week)" and "Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)".
On the day of this measurement our entire website sat at 440 URLs in the sitemap, across two languages, including all 131 glossary entries. That is 4.4 per cent of the lower threshold. A typical company site with fifteen subpages lands at half a per cent of it. Anyone at that scale can put crawl budget down entirely. There is no reserve to be conserved by restraint or topped up by diligence.
The same holds for the one button that does exist. Search Console lets you request indexing for a page. Google's guidance attaches two things worth knowing: "Crawling can take anywhere from a few days to a few weeks", and "requesting a recrawl multiple times for the same URL won't get it crawled any faster". Pressing it once after a meaningful change is sensible. Pressing it repeatedly is an occupation.
When does freshness genuinely count?
When the query demands it, not when the page claims it. Google explains this in "How Search works" with a very clear example: "For example, when searching for current news topics, content freshness plays a bigger role than dictionary definitions." Freshness is therefore a property of the query, not of your website. For "what does a website cost in 2026" a two-year-old piece is a problem. For "what is a legal notice" it is not.
In practice: sort your pages by that question rather than by publication date. Some pages have a built-in expiry because they contain a figure, a deadline or a legal position. Others do not, because they explain a term, a procedure or a judgement. In our own set every post carrying a statutory reference belongs to the first group and has to move when the provision moves. A post about the tone of a rejection belongs to the second and can sit for two years without losing anything.
How do you spot a page that needs an update?
By three signals, none of which is a date. First: the page contains a figure, a price, a deadline or a law that has changed. That is the one reason needing no debate. Second: the page keeps its impressions in Search Console while the average position slides over weeks. That is the classic case of content decay, and it shows up in the data before it shows up in traffic. Third: in client conversations you now answer a question the page does not cover. Then the page is missing a section, not a new date.
An honest sense of scale helps here. In December 2023 Ahrefs analysed roughly 14 billion pages from its own index and found that 96.55 per cent of all pages get zero organic search traffic from Google. Ahrefs names the caveats itself: the sample is smaller than the full index and skews towards higher-quality content, and the traffic figures are estimates drawn from around 651 million keywords, which miss very long-tail queries. Even with those caveats the direction holds: the vast majority of pages on the web are not overlooked because they are updated too rarely.
When you do update, change the substance first and the statement second. Google asks nothing complicated of the visible date, but it does ask for consistency: "Make your dates and times consistent. Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values", plus "Don't specify future dates" and the note to reduce other dates on the page if Google picks the wrong one. A visible "last updated" and a matching dateModified in the structured data block is the whole requirement. And those two fields earn the change only once the text says something it did not say before.
The three levers
One: keep a list of the pages with an expiry. Anything with a price, a deadline, a figure or a statutory reference goes on it. That list is shorter than the website and longer than you expect, and it replaces every editorial rhythm.
Two: use position, not traffic, as the early warning. A page whose impressions hold while its position slides reports itself months before the clicks disappear. In Search Console that is two tick boxes and three minutes.
Three: leave the pages without an expiry alone. The effort spent on an update with no cause is effort missing from the page that genuinely carries a wrong number. That is the real price of the calendar answer.
If you want to know which of your pages belong in which group, we are happy to go through it with you. There are usually fewer than everyone fears, and the right ones are rarely the ones that come to mind first. 🗓️