How to Use Competitor Freshness Distance to Decide What to Refresh Next

Most agencies pick refresh targets by a calendar, or by whichever client emailed last. There's a more useful question to ask about a page, which is how old it is compared with the pages ranking above it. This guide walks you through measuring that gap, which we'll call freshness distance, for a client page, and then using it to decide what gets updated now and what can wait. By the end you'll have a repeatable audit row you can run for any client, and a clear way to explain the decision to them.

You'll need a client page you can assess, access to the client's Search Console data, and an hour or so for your first one. After that it gets quicker.

A quick note before we start. "Freshness distance" and "content freshness benchmarking" are names for a workflow in this guide, not established industry metrics. Google hasn't published a number of days or months that makes a page stale, and there's no standard score for this. Everything below is a plain analyst procedure you can adjust, so treat the sampling choices and queue labels as your own house rules.

What freshness distance actually measures

Freshness distance is the difference between how long ago your page was last substantively updated and how long ago the comparable pages above it were last substantively updated. You use one assessment date for every page, so the numbers line up.

The arithmetic has three parts:

• Target age is the assessment date minus the date your page was last verifiably, substantively updated.
• Competitor median age is the median of the same calculation across comparable pages ranking above yours.
• Freshness distance is the target age minus the competitor median age.

A positive number means your page is older than the middle of the comparison set by that many days. A number near zero means you're roughly level. A negative number means your page is newer. And if you can't verify enough competitor dates, the answer is unknown, and you should write it down as unknown. Don't swap in a first-published date, a guess, or a zero.

Here's a made-up example so the arithmetic is clear. Say your target page was last substantively updated 420 days before the assessment date. Five pages rank above it, and you can verify the updates on four of them, at 90, 150, 200 and 310 days old. The median of those four is 175 days. Your freshness distance is 420 minus 175, which is 245 days, based on four verified dates out of five pages. That last part belongs in the report too.

This is competitor update recency used as one signal in a queue. It isn't a ranking factor you can pull on, and a newer date doesn't cause a page to rank higher. It also isn't a replacement for a fixed schedule, which we cover elsewhere in how often you should refresh content. This is the competitor-relative check you run on top of that.

Step 1: Pick one client page and its main query

Start with a single existing page and the one organic query it's meant to answer. Use the topic the page was written for, not a broad category term that pulls up a different kind of result.

Search Console is where you find candidate pages and see how each one has been doing on its own. Keep in mind that it describes your client's page only. It won't tell you when a competitor's page was last updated, and its position number is an average across many searches, not the position a person saw in one search.

You're done with this step when the audit row names one target URL, one primary query, the market or location, the device if it matters, and the date you checked the results page.

Common mistake: Mixing several related queries into one comparison. A page that answers a current product comparison shouldn't be measured against pages that answer a general educational question. If a page serves two intents, make two audit rows.

Step 2: Capture the pages ranking above it

Run the query under the same conditions each time, and write down what you see: rank, URL, page title, the type of page, and the date you looked. A simple house rule is to look at the organic results on the first page and compare only the results above your target. If your target isn't on that page, use a fixed sample of the leading organic results instead. Either way, that's your own default, not a published standard, so say so in the report.

Leave out ads and result types that clearly aren't comparable, or log them on the side. Then check each remaining page against the target's intent. A page with a different audience, task or format isn't a fair comparison, even if it ranks well.

Search results shift, so keep the observation date with the list. One lookup is a snapshot and shouldn't be presented as a permanent ranking order.

This is also a good point to build the competitor inventory for the client if you don't have one. DeepSmith's Content Map turns your client's site and competitor sites into one map of topics and funnel stages, so you can see where competitors publish and where the client is thin. Its sitemaps are re-checked every 24 hours, so new pages fold in without a re-import. That helps you know which competitor pages to look at, but the freshness work itself still happens in the steps below, because Content Map doesn't verify update dates or track organic rank.

You're done when you have a dated list of the target and the comparable organic pages that sat above it.

Common mistake: Calling every high-ranking URL a competitor. If the page is there for a different reason than yours, drop it from the sample.

Step 3: Record each update date and where it came from

For every page, write down the original publication date and the last-updated date as two separate fields. Then look for evidence, roughly in this order of usefulness:

• A visible, clearly labelled "last updated" date on the page.
• The structured data values dateModified and datePublished. Google describes these as the most recent modification date and the first publication date. They're claims about dates, so they don't prove that a meaningful update happened.
• The lastmod value in the sitemap. Google says it should reflect the last significant update, and that it uses the value when it's consistently and verifiably accurate. A site having the field doesn't make it trustworthy.
• A public version history or dated editorial notes, if the publisher keeps them.
• Archived snapshots of the page, which you'll use in the next step.

It helps to know how Google treats dates. It estimates the byline date shown in search results using several factors, because any single one can be unreliable, and it doesn't guarantee a date will appear at all. It also recommends a prominent visible date with matching structured data. So a date in the results is a clue to follow up on, not proof of an update.

Give each date a confidence label. High means several reliable records agree and the content shows the change. Medium means one plausible signal backed by some evidence in the content. Low means a single date claim with nothing behind it. If you have no sound evidence, mark it unknown.

Common mistake: Treating datePublished as if it were dateModified, or assuming a recent date on screen means the core answer was recently revised.

Step 4: Check what actually changed

Now compare the current page with an earlier version. Use the publisher's version history if there is one. If not, the Internet Archive's Wayback Machine usually has snapshots, and its own tutorial on comparing two versions of a website covers the method: list the available snapshots, pick two timestamps, open both versions, and compare them with a diff tool.

Focus on the parts that serve the query, which means the answer itself, the guidance, the facts, the examples, the evidence and the relevant links. Ignore navigation, templates and footers unless they change the real information.

Two limits are worth keeping in mind. Snapshots are periodic captures, so they show what the page looked like at a given timestamp and usually can't tell you the exact day a change was made. And if you find no difference between snapshots, that doesn't prove the page never changed, because there may be gaps in what was captured. When two snapshots look identical, try others with different digests.

What counts as a substantive update

It helps to run two tests on any change you find.

1. Is it the kind of change Google treats as significant? Google's sitemap guidance gives changes to main content, structured data or links as examples, and a copyright date change as an example of something that isn't significant.
2. Does it change the answer the reader came for? Correcting an outdated claim, revising steps, adding relevant evidence or examples, updating time-sensitive product or policy facts, and materially changing coverage of the query's intent all pass this test.

A technical or structured-data change can be significant for maintenance without making the page more useful, so note that difference instead of calling every technical edit a content refresh. As a working rule for your audit, don't count a changed byline, a bumped year in a title, a new copyright footer, cosmetic formatting, typo fixes, a swapped CTA or a date-only edit, unless the body or answer also changed in a real way. That's an editorial rule for this guide and not something Google publishes.

You're done when the audit records the change itself, the snapshot or version dates that bound it, and whether it changes the page's answer for the query.

Pro tip: Keep two statements apart. "A modification is evidenced" supports a date estimate. "The reader-facing answer changed" supports a refresh decision. They often get blurred together, and the second one is the one that should move a page up your queue.

Step 5: Calculate the freshness distance

Use the same assessment date for the target and every competitor page. Work out each age, take the median of the verified competitor ages, and subtract it from the target age. Keep the numbers in days, or another unit you state clearly, and keep the original dates in the row so another strategist can reproduce your result.

Here's a layout for the evidence table that works well as a single audit row per page and query.

Show the range of competitor dates next to the median. One unusually new or old page can drag a story in a direction the rest of the set doesn't support, and the range makes that easy to see. Also say how many of the pages had usable evidence. In the earlier example that was four of five.

You're done when someone else could rebuild the result from the dates in your row, and they can see how many competitor dates were really verifiable.

Common mistake: Reporting a precise distance while hiding that the competitor dates are weakly supported. Careful arithmetic doesn't fix shaky inputs, so if most of the sample has no verifiable history, say that plainly in the report.

Step 6: Decide when to refresh based on competitors

This is where the number gets used, and the main idea is that it's a signal to weigh, not a verdict. Pair the distance with four other things: whether there's an actual content gap, how the page has been doing for its own query in Search Console, whether searchers need current information for this topic, and how much the page matters to the client's business or how risky an outdated fact would be.

There's no universal days threshold to lean on, so a plain matrix works better. These are the four outcomes.

• Refresh now. The target is clearly older than the comparable pages, there's a real factual or answer gap, and the competitor changes cover information the reader now needs. A weak query-level trend can add to the case, but it doesn't prove age was the cause.
• Validate and plan next. The target is older, but the visible differences aren't clearly useful, the date evidence is mixed, or your answer may still be complete and accurate. Check the facts and the intent before you spend time on a rewrite.
• Defer. The target is accurate and answers the query, the comparable pages aren't demonstrably newer or their changes are cosmetic, and nothing independent points to a content gap. Come back when a meaningful change or performance signal shows up, not because a calendar interval passed.
• Insufficient evidence. Most competitor dates can't be verified. Don't call the page stale from an unverified comparison. Decide from the page's accuracy, how well it covers the intent, and its own performance, and record the date gap as unknown.

It also helps to ask whether the query rewards new information at all. Google describes its freshness systems as applying where fresher content is expected, and gives recent reviews of a newly released movie as its example. Plenty of searches don't work that way, so don't assume this one does without looking.

You're done when the decision cites both the freshness comparison and a reader-facing reason to update, or not to update.

Common mistake: Turning a positive freshness distance into an automatic refresh order. A gap with no meaningful content difference is a reason to inspect the page, and changing it only to reset a date isn't a good reason. If you want to see how this fits with the rest of a decay review, a content audit for decaying pages covers the performance side.

Step 7: Turn it into a repeatable client workflow

Save the audit row and its evidence trail in the client's own account or reporting system, and give each row an owner and a next action. The action might be to update the page, validate a claim, collect better evidence, or defer. Across clients, standardize the fields and the decision wording, but keep each client's queries, markets, competitors and brand context separate so nothing bleeds between accounts. The same applies to how you handle content decay audits across multiple client sites.

Competitor update recency can change from one review to the next, so re-run the row when you revisit the page. When you write up the conclusion for a client, say "older than the verified competitor median by" only when the evidence supports it. Otherwise write "date not verified." That small habit keeps reports honest, and it saves you from defending a number you can't reproduce.

Your refresh queue then becomes a list of rows with a decision on each, and content freshness benchmarking is just one column in it. Rows marked refresh now go to the top. Rows marked validate and plan go into the next cycle, and the ones marked defer stay on a watch list until something changes. If a client's list is long, a framework for prioritizing which pages to refresh first can help you order the rest.

You're done when another strategist can repeat the check for the same client and see why the page was prioritized without relying on judgment nobody wrote down.

What to do next

Pick one client page that's already on your refresh list, run steps 1 to 6 for it this week, and write up the audit row. The first one is the slowest, and doing a real page will show you which of your date sources are usable in your clients' industries. Once you've done three or four, you'll know which pages to batch and how many competitor dates you can usually verify, and you'll have a feel for when to refresh based on competitors versus when to leave a page alone.

If you want a map of where each client's competitors publish before you start picking pages, you can start a free 7-day DeepSmith trial and set up Content Map for a client site and its competitors.