Updating one outdated statistic usually beats writing a new article when the page already ranks and the fact is simply wrong. A refresh keeps the URL, the backlinks and the crawl history. A new post starts from zero and competes with your own older page. A content refresh means editing an existing URL to fix facts, add missing detail or improve structure, while keeping the same address.
After that edit, you can watch crawl activity, index status and query-level impressions. You can't see the ranking weight a search engine gives to freshness, or how an AI answer engine weighs a corrected number. This article splits those two groups apart, because most update-vs-new decisions get made on the wrong side of that line.
Check the crawl log first. It tells you whether the search engine has even seen the change. Everything else is a guess until that happens.
Updating one statistic beats a new article because it keeps the URL, the links and the crawl history
A refresh keeps three assets that a new post has to rebuild: the URL, the inbound links and the crawl history. Search engines treat each URL as a separate document. The sitemaps.org protocol treats a URL as the unit of discovery, so a new URL is a new discovery job. Your old URL already has that job done.
Backlinks are the clearest example. If another site linked to your 2021 figure, that link points to the old URL. Publish a new article and the link stays on the old page while the new page gets nothing. Update the statistic and the link and the corrected number sit on the same address.
A new article also competes with the old one. Two pages on the same query can split impressions and clicks, and search engines may pick one and ignore the other. Google's documentation on canonicalization explains that when duplicate or near-duplicate pages exist, the search engine picks one representative URL. Updating avoids creating the duplicate in the first place.
There's a cost side too. A new 1,500-word article needs research, drafting, editing, internal linking and a fresh index cycle. A statistic update needs a source check, a short edit and a re-crawl request. The table below compares the two paths.
| Factor | Update one statistic | Write a new article |
|---|---|---|
| URL and backlinks | Kept on the same address | New address, links stay on the old page |
| Editing effort | Source check plus a short edit | Research, draft, edit, internal links |
| Index cycle | Existing page re-crawled after the edit | New page must be discovered and indexed |
| Duplicate risk | Low, one URL per query | Higher, two URLs may compete |
| Observable signals | Crawl log, index status, query impressions | Same, but with no history to compare against |
| Strong fit | Ranking page with a wrong or stale fact | New intent, new audience or no existing page |
You can observe three signals after a refresh, and nothing more
Three signals are directly observable, and you should check them in this order. First, the server log: it records every request to your URL, including the search engine crawler's user agent and timestamp. Second, the index status: Google Search Console's URL Inspection tool reports whether the URL is indexed and when it was last crawled. Third, query-level impressions: Search Console's Performance report shows impressions and clicks per query.
What you can't observe is the weight a search engine gives to a corrected figure, or whether an AI answer engine has re-read the page. No public documentation from Google, Bing, OpenAI or Anthropic exposes those weights. Any claim that a specific edit produces a specific ranking lift isn't backed by public platform documentation.
That's why a refresh report should describe what changed and what you saw, not what you promised. For example: "The statistic was corrected on 12 March 2026; the URL was re-crawled on 14 March; impressions for the query rose from X to Y over the following 28 days." That's traceable. "The update boosted rankings by 30%" isn't, unless you can name the tool and the window.
If you run a demo or test environment, say so. Any internal test of a refresh workflow only shows the principle. It isn't laboratory testing, and results apply only under demo conditions and sample parameters.
Pick pages that already rank but carry a fact you know is wrong
Start with pages that already rank but carry a fact you now know is wrong. A page in positions 4-20 for a query with steady impressions is a strong candidate, because it has demand and some trust, and a correction is low-risk. A page ranking in position 1-3 with a wrong fact is also a candidate, but treat it more carefully.
Then check the date. A statistic about market size, adoption rate or regulation goes stale after one to two years in most B2B sectors. A definition or a protocol rule changes only when the standard changes. If you cite GB/T 7106-2019, for example, the year matters and the current in-force version prevails.
Use this checklist before you edit:
- The page has at least one query with recorded impressions in Search Console.
- The outdated fact is cited to a source you can name and check.
- The URL has inbound links or a crawl history worth keeping.
- The page isn't already a duplicate of a newer article on the same query.
- You can describe the change in one sentence for the changelog.
If two or more posts cover the same query, consolidate instead of updating one. Merge the content into the stronger URL, redirect the weaker one with a 301, and keep the canonical tag pointing to the survivor. Google's documentation on redirects and canonicalization covers both mechanisms. A 301 is a permanent redirect, and a canonical tag is a hint that names the preferred URL.
Five refresh mistakes that can cost you rankings
The first mistake is changing the URL. A refresh should keep the address. If you must move it, use a 301 redirect and update internal links. The second is rewriting the page so heavily that the original intent disappears. Search engines map a URL to a topic, and a full rewrite can look like a new page on a different topic.
The third mistake is dropping internal links or structured data during the edit. If the page carried Article or FAQPage schema, keep it and update the fields that changed. Schema.org's Article type and FAQPage type are public vocabularies. Dropping them removes machine-readable context you already had.
The fourth mistake is not telling anyone. Record the change in a changelog with the date, the old value, the new value and the source. That record is what lets you measure the result later, and it's what an auditor will ask for.
A fifth mistake is editing a page that is mid-crawl. If the log shows a crawl in progress, wait a day. The edit will be picked up on the next pass anyway.
Measure with a 28-day window on each side of the edit
Pick a 28-day window before the edit and a 28-day window after, and compare the same query set. Search Console's Performance report exports to CSV, so you can keep both windows side by side. Record impressions, clicks, average position and the number of queries the page appears for.
Then check the crawl log for the first re-crawl after the edit. A re-crawl confirms the search engine has seen the change. It doesn't confirm a ranking effect. Treat the two as separate events. There's no public figure for how long a re-crawl takes; it depends on crawl budget and site authority, so record what you see rather than assuming a number.
For AI answer engines, the observable signal is a citation or a mention in a generated answer, which you can check by hand for a fixed set of queries. There's no public dashboard for this. Don't claim a re-read rate unless you can name a public source that publishes one.
Keep the measurement honest. A refresh that fixes a wrong number is a correctness win even if rankings don't move. Say that in the report.
Write new when the intent is new, and update for everything else
Write new when the intent is new. If the query is about a different audience, a different stage of the buying process or a different product line, a separate URL is correct. Updating a page about one topic to cover a second topic usually weakens both.
Write new when no page exists. A refresh needs a page to refresh. If the query has no matching URL, there's nothing to update.
Write new when the old page is thin and unsalvageable. If the page has no links, no impressions and no useful content, a rewrite is effectively a new article on an old URL. In that case, either rebuild it fully or retire it with a 410 or a 301 to a relevant page.
For everything else, the default is update. The decision rule: if the page ranks and the fact is wrong, update. If the intent is new, publish. If both pages cover the same query, consolidate.
Key Facts at a Glance
- Update one statistic when the page already ranks and the fact is wrong; the URL and links stay put.
- Observable signals after a refresh: crawl log entries, index status, query-level impressions.
- Not observable: the weight a search engine gives to freshness, or how an AI engine re-reads a page.
- Keep the URL, keep the schema, record the change in a changelog with date and source.
- Merge duplicate posts with a 301 redirect and a canonical tag pointing to the survivor.
- Measure with a 28-day before-and-after window in Search Console.
Should I update an old blog post or write a new one?
Update when the page already ranks and the fact is wrong. Write new when the intent, audience or product line is new. If two posts cover the same query, merge them into the stronger URL.
How often should I refresh old content?
Check statistics that change yearly, such as market size or regulation, once a year. Check definitions and protocol rules only when the standard changes, and cite the year, for example GB/T 7106-2019, noting that the current in-force version prevails.
Does updating old content hurt rankings?
It can if you change the URL, rewrite the topic or drop internal links and schema. A focused edit that keeps the address and the structure is lower risk. Any ranking effect isn't publicly documented, so measure it rather than assume it.
How do I know which posts to update?
Start with pages that have recorded impressions in Search Console and carry a fact you can no longer source. Pages in positions 4-20 are usually strong candidates because they have demand and some trust.
Can updating a post count as new content?
For readers, yes, if the change is substantive. For search engines, it's the same URL with an updated body. The crawl log and index status will show the re-crawl, but there's no public signal that labels it as new.
Sources: sitemaps.org protocol (URL as the unit of discovery); Google Search Central documentation on canonicalization and on redirects; Google Search Console URL Inspection and Performance reports; schema.org Article and FAQPage types; GB/T 7106-2019.