Content Refresh vs New Article: How to Decide With Git-Diff Style Updates for AI Search (2026)

Key takeaways

• Refresh pages that already have URL history, links, and citations. Publish new when the topic, intent, or format has changed enough that the old page can't carry it.
• Content type decides a lot. In Promptwatch Data, landing pages and docs stayed cited longest in ChatGPT, while news lost half its pages within 36 days.
• A git-diff style update (small, line-level changes you can review, approve, and revert) beats a wholesale rewrite because you can tell which edit moved the needle.
• Updating the date is not a refresh. AI systems judge facts, statistics, and examples, not the timestamp.
• Measure every refresh: crawled, cited, clicked. If none of those move, the edit did nothing.

The question behind the question

Most teams ask "should we refresh or write something new?" as if it were an editorial preference. It's closer to an accounting decision. An existing URL carries history: backlinks, impressions, internal links, and in AI search, a record of being retrieved and cited. A new URL carries none of that, but it also carries none of the baggage.

Refreshing is usually faster and cheaper. As Surfer's refresh guide puts it, the URL already has history, links, and impressions. But "usually" hides plenty of cases where a refresh is the wrong call. Let's sort those out.

Why AI search changes the math

Classic SEO treated freshness as a ranking nudge. AI search treats it as a trust check. Siteimprove makes the point well: AI systems read your page and decide whether it's reliable enough to cite, and a page can drop out of AI answers simply because the data it references is two years old. There's no notification. The page just stops getting retrieved.

That has a practical consequence. Swapping a publish date does nothing. What counts is whether the claims, numbers, screenshots, and examples on the page still match reality. Uriel Bitton's framing on Medium is a good test: could a returning reader point to what is better now? If the only visible change is the date, the refresh has nothing to show for itself.

What content half-life tells you

Here's where it gets interesting, and where I think most refresh advice is too generic. Different content types decay at very different speeds in ChatGPT.

Promptwatch Data tracked every page ChatGPT cited on July 6, 2026 for 90 days, through October 4, 2026, split by content type. The findings:

One caveat from the report: landing pages, docs, comparisons, and listicles only cross 50% in the last week of the window, which is an artifact of the window ending. Their real half-life is probably close to or beyond 90 days.

My read of this (an inference, not something the report claims): evergreen assets are worth refreshing in place because they keep their citations, so editing protects something that already works. News-type content is closer to disposable. If it decays in about five weeks, refreshing it is mostly wasted effort. Publish the next piece instead.

Promptwatch's own recommendations point the same way: treat landing, docs, and pricing pages as long-term citation assets with accurate prices, features, and positioning, and use news for short bursts of visibility.

A decision framework: refresh, rewrite, new, consolidate, or prune

Quattr's 1-2-3 model (refresh, consolidate, prune) is a useful skeleton. I'd add two more branches, because "write new" and "rewrite" are real options too.

Refresh in place when

• The page still answers the right question, but some facts, prices, screenshots, or statistics are out of date.
• It already earns impressions, links, or AI citations. You're protecting an asset.
• The content type is durable: docs, landing pages, comparisons, listicles, pricing.
• Search intent hasn't changed. The same person asking the same thing would be satisfied by the page with updated details.

Rewrite the page (same URL) when

• The URL is worth keeping, but the structure no longer fits. For example, the SERP now rewards a comparison and your page is an essay.
• Competing pages cover subtopics yours never touches, and the gap is more than a section or two.
• Most of the page would show as changed in a diff. At that point you're writing something new under an old address, which is fine if the topic is the same.

Publish a new article when

• The intent is different. A new angle, a new persona, or a new question your tracked prompts surface that the old page can't answer without bloating.
• The content is news-like or tied to a moment. Don't refresh it, replace it.
• The old page is thin but its topic is adjacent, and merging would muddle both.

Consolidate when

• You have several thin pages on the same topic competing with each other. Merge them into one authoritative page, set canonical signals, and 301 redirect the rest. Siteimprove notes this concentrates freshness signals rather than diluting them.

Prune when

• The page is low-intent, outdated, and nobody searches for it or cites it. Delete it and redirect to the nearest relevant page.

One quick gut-check table

What "git-diff style" actually means for content

Developers don't rewrite a file when one function is wrong. They change the lines that matter, review the diff, and can revert if something breaks. Content teams almost never work like this. A refresh arrives as a fully rewritten document, and nobody can tell what changed or why traffic moved afterward.

A git-diff style content update borrows three habits:

1. Small, line-level changes. Edit the stale statistic, the outdated step, the wrong plan name. Leave paragraphs that still hold.
2. A reviewable diff. Someone approves what was removed and what was added, with the old text visible beside it.
3. Revertibility. If a change hurts, you roll it back without losing everything else.

The discipline matters more for AI search than for classic SEO. AI systems evaluate claims at the passage level, so a surgical fix to one claim can change whether a page gets cited, while a full rewrite changes forty things at once and teaches you nothing.

A practical review note format

Bitton suggests keeping a small review note for each risky passage. I'd standardize it so each diff hunk carries its reason:

- Plan X includes scheduled exports.
+ Scheduled exports are available on Plan Y and above.
# Reason: fact changed (vendor pricing page, checked 2026-11-07)
# Owner: content lead
# Downstream: price comparison table, recommended-buyer paragraph, setup steps

Three checks per change: did a fact change, did the task change, did the reader's choice change? If the answer to all three is no, the edit probably doesn't belong in the diff.

Don't forget the downstream edits

Replacing a plan name is rarely the whole job. The price table, the recommendation, and the setup steps usually depend on it. Then check internal links pointing at the page (anchor text may describe the old version) and the other articles in the cluster. An updated hub page that contradicts an older sibling article creates exactly the inconsistency AI systems penalize.

Step-by-step workflow

1. Find candidates with data, not hunches

Start with declining impressions and click-through rates, pages ranking in Google but never cited by AI, and shifts in how people phrase related queries. Google Search Console is the baseline for the search side.

For crawling and spotting orphan pages, broken links, and duplicate content, a crawler like Sitebulb does the audit work.

2. Check AI visibility on the page and its prompts

This is the step most refresh workflows skip. Before editing, find out which prompts the page should win, whether AI crawlers can read it, and whether it's being cited at all. Promptwatch ties citations, AI crawler logs, and content gaps together, so you can tell an access problem (bots can't read the page) from a content problem (they read it and cite someone else). That distinction decides whether you refresh or fix your robots and CDN setup first.

If you want to compare other options, the GEO software directory at bestgeosoftware.com lists the field.

3. Classify each page

Run it through the framework above. Be honest about content type. A pricing page and a news post should never get the same treatment.

4. Draft the diff

Make the smallest set of edits that fixes the problem. Replace stale claims, link to current sources, update screenshots, and fix definitions that shifted meaning. Content Refresh in Promptwatch produces updates in a git-diff style, which makes review practical for a team that doesn't want to re-read an entire article to approve a change. Pair it with the Content Agent when the gap is bigger than a diff and a new article is the right answer.

5. Review, then ship

A human should approve each hunk. Add an honest on-page recency cue, like a review date plus a short note about what changed. Siteimprove warns that a fresh date on a page that still has old statistics sends contradictory signals.

6. Measure whether it worked

Three questions, in order:

1. Did AI bots crawl the updated page?
2. Did the page get cited for the prompts you targeted?
3. Did it send traffic and conversions?

Sites like Crisp and TreeHouse have written up this kind of loop. TreeHouse grew AI search to about 25% of organic conversions by fixing crawler access and publishing proprietary data, per the TreeHouse case study. Pages that underperform go back in the queue.

Tools worth knowing for each job

Content scoring tools like Surfer or Clearscope help you see what competitors cover that you don't, which is useful for deciding whether a gap is a section (refresh) or a whole topic (new article). For a wider view of the tool space, surferstack.com has reviews and comparisons.

Common mistakes

Refreshing everything. Quattr calls this the hidden cost of universal refreshes: effort spent in the wrong places, updates that leave content feeling generic. Prioritize by business value, answer potential, and decay risk.

Ignoring intent shift. If a query no longer drives clicks or decisions, updating the page won't bring them back. Some queries get fully resolved inside AI answers. Those are low-ROI refresh targets.

Refreshing news. Based on the half-life data, a news piece is mostly spent after five weeks. Write the next one.

Cosmetic dates. An updated timestamp with the same stale stats is worse than no update.

No measurement. If you can't say whether the refreshed page got crawled, cited, and clicked, you're guessing. And if traffic drops after a refresh, check whether a core update landed around the same time before blaming the edit.

A quick example

Say you have a comparison page on two reporting tools, published 14 months ago. Impressions are down 30%, and AI answers cite a competitor's page instead.

Audit: one plan changed names, two prices are stale, and two screenshots show an old interface. Comparisons are a durable content type, intent is unchanged, and the page has backlinks. Decision: refresh in place.

The diff touches the plan table, two price lines, the recommended-buyer paragraph, and the screenshots. It leaves the methodology section alone. You add a review note and fix the internal links from three related posts. Then you watch crawler hits, citations for the target prompts, and conversions for four to six weeks.

Now say the same audit shows people now ask "which reporting tool works for agencies with white-label clients?" and your page never mentions it. That's a new intent. Write a new article, link it both ways with the old page, and leave the comparison alone.

Bottom line

Refresh when the page is a durable asset whose facts drifted. Write new when the intent, topic, or time window changed. Consolidate duplicates, prune dead weight, and keep every edit small enough to review as a diff. Then check whether AI crawled, cited, and sent traffic to the result. If you want to see where your own pages stand first, the free AI visibility report is a no-login place to start.