You have a library of published pages and a nagging feeling that some of them are slipping. If you have ever typed how often refresh content into a search box and hoped for a single number, you already know the answer never comes back clean. This guide gives you something better than a number: a content refresh cadence you can set page by page, so your best pages keep their rankings and their AI citations, and your stable pages stop eating editorial time they do not need.
Take a breath. You are probably closer to a working schedule than you think.
The short answer on how often refresh content
There is no universal rule that every page gets updated every 30, 60, or 90 days. Here is a defensible place to start:
- Review much of your active blog content every three to six months.
- Give high-value evergreen pages a light quarterly review and a deeper annual refresh.
- Review ordinary evergreen pages every six to 12 months, or annually if they are lower priority.
- Update news, seasonal, data-heavy, comparison, and fact-sensitive pages when the facts, the search intent, or the competition change, not when a date arrives.
Now the part most teams miss when they set a content maintenance frequency. A review is not an edit. A quarterly review means you look at the page and decide whether a meaningful change is needed. If the page is still accurate, still answers the question, and still holds up against what ranks now, you leave it alone and write down the next review date. That single distinction is what keeps a refresh schedule from turning into four pointless rewrites a year.
Here is the starting cadence by page type. Pick the row that matches the page's job, not its folder.
| Page type | Starting review rule | What makes it due |
|---|---|---|
| News and fast-moving topics | As the story evolves, sometimes weekly or daily | New facts, corrections, an active news cycle |
| Trending content | Constant while the trend is live, then retire it | New developments or a loss of relevance |
| Seasonal guides | Annually, before the season or decision window | New dates, offers, rules, products |
| Statistics and data-heavy pages | Check sources every six to 12 months | A new figure, a revised method, a dead source |
| Comparisons, reviews, "best" pages | Start at six months, sooner in fast categories | Pricing, features, new rivals, a changed SERP |
| High-value evergreen pages | Quarterly light review, annual deep refresh | The scheduled review, or any decay signal |
| Ordinary evergreen blog and how-to pages | Six to 12 months | Changed facts, intent, rankings, or citations |
| Stable "what is" explanations | No fixed interval, review when something changes | Wrong information, a better format winning |
| Calculators and tools | No content interval, check that it still works | Broken logic, stale inputs, poor experience |
| Product, pricing, and policy pages | Event-driven, before the fact becomes wrong | A material change to the offer or the terms |
Set your update content frequency from the row, then adjust. Use the short end of a range when the topic moves fast, the page matters commercially, or you can see it losing ground. Use the long end when the page is stable and low risk.
Ready? Here is the seven-step way to turn that table into a real refresh schedule.
Step 1: Build your page inventory
What to do: Make one row per page. Record the title, the topic, the primary query or buyer question it answers, the page type, its funnel job, the publish date, the last date it substantively changed, the owner, and what it does for the business.
Then classify each page by how fast its answer changes: fast-moving, seasonal, data-heavy, comparison, high-value evergreen, ordinary evergreen, stable explainer, interactive tool, or fact-sensitive service page.
If you can, add the page's traffic peak, current traffic, conversions, rankings, backlinks, source list, and whether AI engines cite it for the prompts you care about. That is the raw material for every decision after this one.
How to tell it is done: Every page has one dominant type, one owner, one primary job, and enough data to sort into a priority tier. Nothing valuable is missing because it lives outside the blog folder.
Where people go wrong: They inventory only old blog posts. Your comparison pages, docs, resource hubs, and product pages all decay too, and some of them carry more revenue than the blog. Age is a clue, not a decision.
This is also where a tool earns its keep, because building the inventory by hand is the part that stalls. DeepSmith's Content Map crawls your site, classifies every page onto a topic and a funnel stage, and maps your competitors onto the same taxonomy so comparisons are like for like. Sitemaps get re-checked every 24 hours, so recently published pages fold in without a manual re-import. It gives you a current inventory and a coverage view. It does not tell you a page is stale.
Step 2: Measure volatility and search intent
What to do: For each page, ask how often its underlying facts actually change, how time-sensitive the query is, how fast competitors improve, and how much damage an outdated answer would do.
Then go look at the live search results for the target query. Compare what ranks now against what your page was built to be.
Watch for:
- new or changed products, prices, rules, definitions, or data
- results that now favor a comparison, a tool, a video, or a list instead of your format
- competitors answering questions your page skips
- a shifted audience need or funnel stage
- source pages that were revised or pulled down
Google's own guidance is query-dependent here. Its freshness systems are meant for searches where people expect fresher information, not for every query on the internet. That is exactly why a news page and a stable explainer should never share a refresh schedule.
How to tell it is done: Every page carries a volatility label (fast, seasonal, moderate, or stable) plus a note on the intent and the specific event that could change it.
Where people go wrong: They assume an old page has decayed and a new page is safe. Both assumptions fail. A page published last month can miss intent on day one, and a four-year-old explainer can still be the best answer on the internet.
Step 3: Score business value and AI visibility separately
What to do: Combine two kinds of evidence. First the business side: historical and current traffic, impressions, clicks, CTR, rankings, conversions, backlinks, and the page's role in your strategy. Then the visibility side: do AI answers mention your brand, cite this page, cite a competitor instead, or ignore the topic entirely?
Keep those two scores apart. A page can hold its Google position while an answer interface quietly absorbs the click. A page can stay strong in traditional search and vanish from AI answers. Those are different problems with different fixes, and one blended score hides both.
Sort what you have into three tiers:
- Protect and improve. High traffic, valuable rankings, real conversions, quality backlinks, a topic that still matters, or a page AI cites for your tracked questions. Start these on quarterly light and annual deep.
- Maintain selectively. Steady but moderate value, a relevant topic, a plausible chance to improve. Six to 12 months, and change the page when evidence says so.
- Triage first. Low relevance, little traffic, weak rankings, few links, no clear opportunity. Do not refresh these by default. Decide whether to consolidate, redirect, noindex, or delete them.
That third tier is where most wasted effort lives. A low-value page costs the same research and review hours as a valuable one and returns almost nothing.
How to tell it is done: Every page has a tier plus a separate AI note: cited and stable, cited and declining, not cited but strategically important, or not relevant to your prompts.
Where people go wrong: They chase every AI answer they happen to see, treat one answer as a stable benchmark, or rank pages by current traffic alone and forget historical value, backlinks, and winnability.
Checking AI visibility by hand does not scale past a handful of pages. DeepSmith's AI Visibility module tracks the prompts you define and reports mention rate, citation rate, share of voice, and the trend over time, broken out by platform. The Pages view shows which of your pages actually earn citations. Competitor citations shows whose page is winning the answer instead of yours. That evidence informs the priority call. It does not promise that a refresh will earn the citation back.
Step 4: Assign a content refresh cadence and a pull-forward trigger
What to do: Take the starting interval from the page-type table, then adjust that content maintenance frequency for the tier and the volatility label. Write down two things for every page: the planned review date, and the exception that would move it forward.
A simple operating rule:
- Tier 1, fast-moving: event-driven review, with a quarterly light and annual deep rhythm underneath when the topic also has evergreen value.
- Tier 1, stable evergreen: quarterly light review, annual deep refresh.
- Tier 2: six to 12 months, shortened the moment a signal or a source changes.
- Tier 3: annual triage, or no scheduled edit until the page proves it deserves one.
Now the triggers. These are starting thresholds from industry operating guidance, not rules Google publishes. Tune them to what normal looks like for your pages.
| Signal | Starting trigger | What to do |
|---|---|---|
| Organic traffic | More than a 20% drop over 90 days | Check relevance, rankings, intent, technical issues, competitors |
| Rankings | A loss of more than five positions | Review the live SERP, competitor improvements, authority, intent |
| CTR | CTR falls while impressions hold steady | Look at the title, the snippet, and whether a feature ate the click |
| AI visibility | Citation or mention rate drops below the page's baseline | Check freshness, answer structure, and who is cited instead |
| Engagement | Bounce rate climbs above the page's own baseline | Check intent match, the opening answer, and task completion |
| Backlinks | No new referring domains for six months or more | Treat as a clue about priority, not proof a rewrite will fix it |
| A fact changes | A source, stat, rule, price, or feature goes stale | Pull the review forward now, whatever the calendar says |
| Intent shifts | The dominant format or audience need changes | Consider a rewrite or a consolidation, not a light touch |
One signal crossing a threshold is worth a look. Two or more crossing together is a genuine priority, as long as the page is still worth saving.
Pro tip: Store two dates per page, not one. The next planned review date, and the event that would trigger an earlier one. This one habit is what stops a quarterly check from becoming four unnecessary rewrites a year.
How to tell it is done: Your calendar holds a next review date, a planned depth, an owner, and at least one pull-forward trigger per page. A page that needs no meaningful change is allowed to keep the version it has.
Where people go wrong: They let "quarterly" quietly mean "rewrite every quarter," or they build a calendar of dates with no reason attached to any of them.
Once you know what gets worked on and when, the scheduling itself should be boring. In DeepSmith, Planned Content holds the dated work queue, and Autowrite generates configured articles on their scheduled dates so the pipeline keeps moving during weeks when nobody has time to open the app. That is workflow support, not a cadence recommendation. The interval still comes from the page's volatility, its priority, and your evidence.
Step 5: Choose refresh, rewrite, consolidate, or prune
What to do: Before anyone opens the draft, decide what the page actually needs. These are not interchangeable.
- Refresh when the keyword is still relevant, the page has real authority, and the structure is basically sound.
- Rewrite when the intent or the dominant format has shifted substantially.
- Consolidate when several thin pages fight over similar terms. Merge the strongest material into one page and redirect the weaker URLs.
- Redirect when the keyword no longer fits your strategy but the page has meaningful backlinks.
- Prune when traffic, rankings, links, and business value are all minimal and nothing suggests that will change. Check dependencies before you delete or noindex.
- Restore when the decline started right after an edit and a before-and-after comparison says the edit is what hurt.
For diagnosis, compare the last three months against the same period a year earlier in Search Console, and read impressions and CTR together. For a wider decay view, pull a 12-month traffic range, sort for the biggest negative change, and screen with a keyword-difficulty filter so you do not mistake a link-authority gap for a content problem. One published workflow uses a difficulty filter under 40 as a practical screen. Treat that as a setting, not a law.
How to tell it is done: Every page has a documented action and a reason. A refresh brief says what will change and why. A consolidation brief names the surviving page, the material worth keeping, and the redirect plan.
Where people go wrong: They refresh a page whose real problem is cannibalization, changed intent, a technical failure, or simply not enough authority to compete. Editing prose cannot fix any of those.
Step 6: Make the update meaningful and citation-ready
What to do: Start from the page's promise and the query it has to satisfy. Replace outdated statistics, screenshots, examples, and tool references. Find current studies. Repair broken links and internal links. Cut claims you can no longer support. Improve the title, H1, meta description, heading order, and alt text where it genuinely helps clarity or click appeal.
For a deep refresh, go further:
- compare your page against the ones that overtook it
- close the subtopics and questions you never answered
- rewrite weak sections instead of bolting a paragraph onto the end
- add first-hand experience, original analysis, or a real point of view
- update the framework, the examples, and the decision criteria
- ask whether this content still belongs on this URL
For AI search, structure matters as much as substance, because answer engines read your page in passages. Put a crisp direct answer near the top. Use descriptive headings and self-contained answer paragraphs. Number your steps. Define a term before you use it. Use a table where a comparison genuinely helps. Add FAQ or HowTo structured data only when the page really contains that content.
None of that guarantees a citation. It does make your page easy to scan and easy to interpret, which is the part you control.
One rule on dates. Change the visible update date only when the content materially changed. Google explicitly warns against changing dates to make an unchanged page look fresh, and against adding or removing large amounts of content mainly to create a fresh impression.
Common mistake: Putting every page on the same quarterly schedule. It creates busywork on stable pages and still misses the fast-moving ones in between reviews. Page type, priority, volatility, and triggers do the job that a blanket calendar cannot.
How to tell it is done: A reviewer can list the material changes, verify every time-sensitive claim, confirm the page still answers the query, and say plainly why this version is more useful than the last one.
Where people go wrong: They add a date, swap a few synonyms, insert a thin paragraph, or copy the structure of whoever ranks first. That is not a refresh. That is motion.
When the honest answer is that the page needs a substantial rewrite, production is the slow part, not the decision. DeepSmith's Content Studio Writer produces a finished, brand-grounded article with research, SEO and AEO structure, internal and external links, a cover image, and publish-ready metadata. Deep IQ supplies your positioning, products, personas, brand voice, visual guidelines, and content types, so output sounds like you without a re-brief. It cuts the production and rework, after you have made the editorial call.
Step 7: Republish, verify, and reset the next review date
What to do: Before you publish, check the facts, the source dates, the links, the redirects, the metadata, the structured data, the headings, the images, and the canonical destination. Keep the URL when the topic and the accumulated authority still match it. If you merged pages, verify the redirects and the surviving page. If the revision was material, record the new update date and a change log of what actually changed.
After it goes live, compare the page against its own baseline. Look at rankings, impressions, clicks, CTR, conversions, and the AI mention and citation results for the prompts it should serve. Do not call it a win from one answer or one good week. Use what you learn to lengthen or shorten the cadence for that page type next time.
How to tell it is done: The live page matches the approved version, the action and date are recorded, and the next review rule is clear. Anyone on the team can say what changed, why, and what evidence would pull the next review forward.
Where people go wrong: They publish without checking redirects, treat the timestamp as the work, or assume a ranking recovery means AI visibility recovered too. It often has not.
What to do next
You do not need to schedule your whole library this week. Start with your top ten or twenty pages, the ones a decline would actually hurt. Give each one a tier, a starting content refresh cadence, and one pull-forward trigger. Then let two or three cycles happen before you touch the intervals again, because your own pages will tell you more about the right update content frequency than any benchmark will.
Momentum matters more than completeness here. Ten pages with real review dates beat a spreadsheet of two hundred that nobody opens.
If the part that keeps stalling is the evidence (which pages AI cites, where competitors are winning, what your coverage actually looks like) and then the production work after the decision, that is the loop DeepSmith is built for. You can start a free trial and see your own data before you commit to anything.
