How Does Keeping Your Website Updated Affect SEO? A Content Freshness Strategy

Content freshness is one of the SEO topics my clients misread most often. Some change the date on every blog post each month. Others ask why pages they have not touched in five years keep sliding. In this guide I explain how Google actually treats freshness, which pages need regular updates and which ones can stay as they are. I also cover content pruning, honest update dates and the lastmod field in your XML sitemap, with each point tied to Google's own documentation.
What is content freshness and how does it affect SEO?
Content freshness is how current and accurate the information on a page is compared with what searchers expect today. Google does not reward every new date. Freshness matters most for queries where recent information is clearly expected. For other queries, an update helps only when it makes the page more accurate and more useful.
In other words, the act of updating is not a ranking signal by itself. What counts is what the update gives the reader. A service page with an old price, a tutorial that describes a menu that no longer exists, or a guide built on a method that stopped working will mislead people. Over time, pages like these lose clicks and trust. On the other hand, a basic definition page can perform well for years as long as it stays correct.
Here is the pattern I see in the field: most older pages that lose rankings do not drop because they are old. They drop because they became outdated. A competitor publishes a clearer, more accurate and better structured answer, and the older page simply stays where it was. That is why I treat updates as quality maintenance, not as a calendar habit. The sections below show how to plan that maintenance step by step.
How does Google evaluate freshness?
Google gives freshness its own entry in the official overview of its ranking systems. According to the ranking systems guide, Google uses various "query deserves freshness" systems to show fresher content for queries where people would expect it. The examples in the guide help. When someone searches for a newly released movie, recent reviews tend to appear ahead of older articles about the production.
In other words, the key phrase is "where it would be expected". So Google does not apply freshness as a general score to every search. For an earthquake, an election or a new software release, recency becomes decisive. However, for a query like "how to brew tea", yesterday's article has no automatic edge over one from five years ago.
This distinction decides where your update budget should go. If you try to refresh every page at the same pace, you will spend most of your effort on pages where freshness barely matters. Instead, first identify which of your pages answer time sensitive queries. Then set the update frequency to match that sensitivity. As a result, you focus a small amount of effort on the pages that can actually move in search results.
For which queries does content freshness really matter?
To judge how much content freshness weighs for a page, I sort queries into a few practical groups. The table below reflects my own field experience. It is not an official Google list. Still, it gives you a solid starting point when you decide how often to review each page.
| Query type | Example | Freshness weight | Suggested review |
|---|---|---|---|
| Events and news | New regulation, product announcement | Very high | Whenever something changes |
| Regularly changing facts | Prices, rules, software steps | High | Every 3 to 6 months |
| Comparisons and lists | Best tools, roundup guides | Medium | Every 6 to 12 months |
| Evergreen knowledge | Definitions, core concepts | Low | Yearly check |
| Company pages | About, contact | Low, but accuracy is critical | Whenever details change |
The intervals in the table are a starting range from field experience, not a guarantee. For example, comparison content in a fast moving industry can go stale within three months. Meanwhile, company pages carry little freshness weight, yet a wrong phone number or an old address costs you customers directly. So your yardstick should not be rankings alone. It should be whether the reader finds correct information on that page.
Which content stays evergreen and can be left alone?
For content freshness, evergreen content is the easy case: it covers topics that do not change much over time. A definition, a basic calculation or a general decision framework belongs in this group. You do not need to rework these pages just to put a new date on them. That said, "evergreen" does not mean "never checked".
Even a solid evergreen article decays in a few predictable places:
- External links break or start pointing somewhere else.
- Screenshots show interfaces that no longer exist.
- Tools you mention shut down or change their names.
- Internal links miss the better pages you wrote later.
- Search intent shifts, and readers now expect a different answer.
Therefore a short yearly check is enough for evergreen pages. During that check you do not rewrite the text. You only repair the parts that broke. A repair like this usually does not justify a new lastmod value or a new visible update date, because the core content stayed the same. I explain that line in more detail in the next section on date honesty.
What is the difference between a real update and a date change?
A real update changes the answer the reader gets. You add new information, fix a wrong step or rewrite a section that no longer holds up. A date change keeps the content as it was and only moves the date at the top of the page to today. The second one aims to mislead both readers and search engines.
Google is very direct about this. In its guide to creating helpful content, one of the self assessment questions asks whether you change the date of pages to make them seem fresh when the content has not substantially changed. The same guide also says that adding lots of new content or removing lots of older content just to make a site seem fresh will not help your rankings overall.
In practice I usually find this problem in plugins and themes. Some themes refresh the "updated" date every time someone saves a post, even for a fixed comma. Some teams also schedule a monthly "date refresh" task. Both cost time and earn no trust. Worse, a reader who sees "updated" above outdated information stops trusting the whole site. In short, change the date only when you make a change the reader would notice.
How should you show the update date honestly?
Google's documentation on publication dates gives practical guidance here. First, it recommends a user visible date that you feature prominently, with a clear label such as "Published" or "Last updated". Second, it recommends structured data from a CreativeWork type such as Article or BlogPosting, with the datePublished and dateModified fields filled in.
Third, it asks for consistency. The visible date and the structured date should match, including time and time zone when you use them. The documentation also stresses that dates must describe when the page itself went live or changed, not the events the page talks about. It also advises against future publication dates and against extra dates that compete for attention on the page.
Here is the setup I recommend to clients:
- Show both the publication date and the last updated date near the top.
- Change the "last updated" date only after a substantial edit.
- Keep dateModified in your structured data identical to the visible date.
- For large updates, add a short "what changed" note at the end.
If you would rather not write structured data by hand, you can build your Article markup with the schema generator and check the dates there.
What does lastmod in your sitemap actually do?
Lastmod is the field in an XML sitemap that states when a URL last changed in a meaningful way. Search engines can use it to decide which pages to crawl again. However, Google does not trust the field blindly. According to its sitemap documentation, Google uses the lastmod value if it is consistently and verifiably accurate, for example when it matches the last modification of the page.
The same page adds two useful details. First, Google ignores the priority and changefreq values. Writing "this page changes daily" in your sitemap will not speed up crawling. Second, lastmod should reflect significant updates to the main content, the structured data or the links on the page. The documentation specifically excludes small edits such as a new copyright year.
So the conclusion is clear. A setup that stamps today's date into lastmod every night wastes the signal. Once Google sees that your values do not match reality, it can stop relying on them. Then, when you do ship an important update, you lose the benefit of that channel. If you are building a sitemap from scratch, the XML sitemap generator gives you a clean base to start from.
Which changes should trigger a new lastmod value?
For content freshness signals, teams often get stuck on where "significant" begins. I turn Google's wording into a simple rule set on my own projects. Update both lastmod and the visible date in these cases:
- New information or a new section changes the main answer.
- A wrong fact, price or step gets corrected.
- Structured data changes, for example FAQ or product details.
- Important internal links on the page change.
In contrast, leave the date alone in these cases:
- A typo or punctuation fix.
- A new copyright year in the footer or a shared component.
- Image compression or a CSS adjustment.
- A broken external link swapped for the new address of the same source.
You can automate this rule in your CMS. For instance, add a "substantial update" checkbox to the editor screen, and let the date change only when an editor ticks it. That way, honesty depends on the system rather than on anyone's memory. It also gives you a clean record of real updates for later analysis.
Which pages should you update first?
First, build your update list from data, not from guesses. The most useful source is the Performance report in Google Search Console. Compare the last three months with the same period a year earlier, and list the pages whose clicks and impressions dropped clearly. I prefer year over year comparisons because they keep seasonality from fooling you.
Next, rank that list by business value. This is the order I use:
- Service and product pages that bring revenue or leads directly.
- Pages with high impressions and an average position between 5 and 15.
- Guides that answer time sensitive queries and show a clear decline.
- Hub articles that feed internal links to many other pages.
- Low traffic pages whose accuracy still affects your brand's reputation.
The range in the second item is a starting point from field experience, not a guarantee. The logic is simple: a page in the lower half of page one or on page two can gain visibly from a good update. On the other hand, rewriting a page that already ranks first carries real risk. For those pages I only run an accuracy check. If your keyword to page assignment is still fuzzy, the table from my keyword mapping guide will make this step much easier.
What exactly should you change when you update a page?
In practice, a good update does not rewrite the page from scratch. Instead, it answers today's version of the reader's question. I start every update in the same order, because this order gives fast and consistent results.
- Search the target query today and see which question the top results answer.
- Check every fact on your page and confirm it still holds.
- Identify missing sub questions and add them as short sections.
- Replace stale examples, screenshots and external sources.
- Tighten the introduction and the first answer paragraph.
- Review the title tag and meta description against the new content.
- Add internal links to related pages you published later.
Take care with step six. A drastic title change on a page that ranks well can cut its click through rate in ways you did not expect. Before you ship a new title, preview it in the Google SERP preview tool. Also, keep the URL. The updated content should stay at the same address. Otherwise you hand your accumulated link equity and history to a redirect and hope nothing gets lost.
What is content pruning and when does it help?
Content pruning means reviewing weak, duplicate or obsolete pages and deciding whether to improve, merge or remove each one. The goal is not a smaller page count. The goal is a higher overall quality level across the site. Still, pruning is one of the most misapplied SEO practices I come across.
Google's documentation on core updates applies the brakes here. It says deleting content is a last resort, to consider only if you think the content cannot be salvaged. It also warns that if you are thinking about deleting entire sections of your site, that is likely a sign those sections served search engines first rather than people.
My own approach stays close to that line. I only put pruning on the table in three situations: several weak posts on the same topic compete with each other, a page describes a product or service that no longer exists, or the content has nothing to do with the site's expertise. In every other case I try to improve the page first. After all, even a low traffic page can answer a real niche question, and deleting it removes that value for good.
Should you delete, merge or improve a page?
To decide, I ask each page the same three questions. Does it still answer a real question? Also, is there another page on the site that answers the same question better? Finally, does it have external links or meaningful traffic? The decision table below turns those answers into a concrete action.
| Situation | Action | Technical step |
|---|---|---|
| Topic still valid, content outdated | Improve | Same URL, substantial update, new date |
| Two weak pages on one topic | Merge | Move content to the stronger page, 301 the other |
| Product or service gone, close alternative exists | Redirect | 301 to the closest relevant page |
| Product gone, no relevant alternative | Remove | Return 404 or 410 |
| Off topic, no traffic, no links | Remove | Return 404 or 410 and clean up internal links |
Of all the rows, the second one matters most. Two very similar posts can compete for the same query and hold each other back. A merge ends that contest and gathers the strength of both pages at one address. If your site has many of these overlaps, the root cause often lies in the category structure. I cover that in detail in my article on category structure for large websites.
How do you handle 404, 410 and 301 for removed pages?
Once you decide to remove a page, the technical execution matters as much as the decision. Google's documentation on HTTP status codes says that Google handles all 4xx errors except 429 the same way. The crawler tells the next system that the content does not exist, and indexing drops the URL if it was in the index before. So you should not expect a practical ranking difference between 404 and 410.
A redirect is a separate decision. Use a 301 only when you send readers to a page that is genuinely related. Pointing every removed page at the home page is a common mistake. In my experience, Search Console often reports these irrelevant redirects as soft 404s. The same Google page describes a soft 404 as a URL that returns a success code while showing an empty page or an error message.
After any pruning round, run three checks. First, confirm your redirects do not form chains; the redirect checker speeds this up. Then remove internal links that still point at the deleted URLs. Finally, take the removed URLs out of your sitemap. If you plan a larger URL change, the checklist in how to protect SEO during a website redesign will help as well.
How do you build an update schedule by page type?
Instead of applying one rhythm to every page, set a separate schedule for each page type. This way even a small team can keep a site with hundreds of pages under control. The rhythms below are starting ranges from field experience, not a guarantee. Tighten or loosen them to match the pace of your industry.
- Service and product pages: immediately when price, scope or process changes, plus a quarterly accuracy pass.
- Time sensitive guides: every three to six months, search the target query again and compare.
- Comparisons and lists: every six to twelve months, check tools, prices and features.
- Evergreen content: once a year, maintain links, images and internal links.
- Company pages: the moment your team, address, contact details or documents change.
In practice, keep the schedule in a simple sheet: URL, page type, date of the last substantial update and date of the next check. I track this sheet next to my clients' CRM records, so it is easy to see when each page last got attention. The important part is that the whole team agrees on one thing. The schedule exists to trigger a check, not to refresh a date. If a check shows no change is needed, you leave the page and its date alone.
Why does technical upkeep matter as much as content?
Content freshness is not only about text. Even a great page suffers when it runs on an old theme, has a broken form or sits on a slow server. Outdated structured data can also change how your page appears in results. For that reason I treat technical upkeep as part of content upkeep.
These are the technical items I check regularly: CMS, theme and plugin updates; SSL certificate expiry; whether forms really create an email or a CRM entry; whether structured data throws errors; and whether the sitemap lists only indexable URLs that return a 200 status. Do not underestimate the form check. More than once in my work I have found a contact form that had silently failed for months.
If your platform has aged past the point where maintenance makes sense, a planned rebuild can cost less than endless patching. I describe how I run that process on my web design service page. For the wider scope of technical SEO in the age of AI search, see my article on technical SEO after AI.
How do you measure whether content freshness work paid off?
To know whether an update worked, start with a baseline. Note the clicks, impressions, average position and click through rate from Search Console for the four weeks before the update. Then record the update date somewhere safe. I log it in the "last substantial update" column of the schedule sheet.
Also, patience matters when you judge the result. Google's core updates documentation notes that some changes can take effect within a few days. However, it can take several months for Google's systems to learn and confirm that a site as a whole now produces helpful, reliable content. The same page also states plainly that there is no guarantee your changes will lead to a noticeable impact in search results.
For a single page I use a comparison window of four to eight weeks. This is a starting range from field experience, not a guarantee. Also look beyond traffic at business results such as form submissions, calls or sales that the page drives. More traffic alone means little. If the update brought the right readers, conversions should rise with it.
Why does content freshness matter in AI search answers?
AI powered search experiences can cite web pages as sources for the answers they generate. That creates a new risk: outdated information can resurface inside an answer. A wrong price about your brand, or a service you no longer offer, can travel further than your own site. So the accuracy of brand, product and pricing pages matters more today than it did a few years ago.
Still, it is important not to overstate this. Nobody has a proven formula for which pages AI answers will cite, and I do not promise one. Still, it is a reasonable assumption that accurate, clear and well structured content has an advantage in both classic search and these newer surfaces. Moreover, that assumption lines up exactly with what classic SEO already recommends.
In practice the steps are simple: give a clear, current answer in the first paragraph, keep dates honest and do not let outdated facts linger. If you want a framework for structuring content for AI summaries, read my guide on how to write content for AI Overviews.
Common mistakes in a content update strategy
Over the years I have seen the same mistakes on sites of every size. Most do not come from bad intent. They come from stretching the idea that "fresh is good" too far. These are the ones I meet most often:
- Moving the publication date to today without touching the content.
- Rewriting lastmod automatically every night.
- Deleting a strong niche article only because its traffic looks low.
- Redirecting every removed page to the home page.
- Changing a URL during an update and forgetting the redirect.
- Putting a year in the title and changing only the year every January.
- Rewriting a page that already ranks first without a clear reason.
The sixth mistake deserves a closer look. A year in the title can lift clicks for a while. Yet when the content does not match that year, readers feel misled. For that reason I do not put years in titles on my own site. Instead, I show freshness in the content itself and in a visible update date.
Where should you start with content freshness on your site?
You do not need a big project to get content freshness under control. Four steps in the first week give you a solid base. First, list the twenty pages with the steepest year over year decline in Search Console. Next, tag each one by page type. Then check how your CMS handles dates and lastmod, and fix any automatic date refresh on save. Finally, ship a substantial update on your three most valuable pages.
These four steps form the skeleton of the rhythm you will keep in the months that follow. What matters is not a one time clean up but a maintenance habit you can sustain. Put simply, you stop touching everything at once and start touching the right pages at the right time, guided by data.
If you would rather plan this together than run it alone, my SEO consulting work includes a content inventory, an update schedule and clear pruning decisions. To talk about your current site, reach me through the contact page. In the first call we can pin down which parts of your site truly need an update and which can wait.




