How to update an old post without losing its rankings

Before you open the editor: find out what the page already wins

The decision about whether to update this page at all is a separate question, and we argued it out in when to update old content instead of writing new. This page assumes you have decided, and covers the editing procedure — which is the part where the damage actually happens.

Ten minutes in Search Console first, because it is the only way to know what you are protecting. Open the Performance report, filter to the exact URL, set the range to the last six months, and open the Queries tab.

Write down four things and keep them beside you while you edit.

1. The query that sends the most clicks. Not the one you meant to target — the one that actually pays. They are different on maybe a third of older pages.
2. The next five to ten queries by impressions, especially the ones sitting at positions 8 to 20. These are the ones an edit can genuinely move, because Google already associates them with this page.
3. The current average position and click-through rate, so you have a before to compare against.
4. Anything ranking here that surprises you. A page frequently earns its traffic from a sub-topic mentioned in one paragraph. Delete that paragraph in a tidy-up and you delete the traffic with it.

The three things that stay fixed

Everything else on the page is fair game. These three are load-bearing, and the ranking is attached to them rather than to your prose.

The URL. Google has spent years associating this string with a topic, and every link pointing at your page points at this string. Keeping it costs you nothing and preserves all of it.

The primary query. The page won a specific question. It can answer that question better, at greater length, with a table and fresher numbers — but it must still, unmistakably, answer it. The failure mode is subtle: an article about "GST on digital marketing services" gets expanded into a general guide to GST for businesses, and it stops being the best result for the query that was sending the leads.

The promise in the H1. The heading is the clearest statement of what the page is for, to both readers and search engines. Rewriting it from a specific promise to a broader one is scope drift with a title on top. You can sharpen the wording; you should not widen the claim.

What the date field does, and what it does not

Changing a published date does not improve rankings. It never has, and it is not a grey area: Google's guidance on people-first content asks directly whether you are changing the date of pages to make them seem fresh when the content has not substantially changed, and lists it among the signals of content built for search engines rather than readers.

What a date does do is set an expectation. A reader who sees "Updated September 2026" and then finds a screenshot of an interface that was retired in 2023 has learned something about you, and it is not the thing you wanted them to learn. On queries where currency matters — tax rates, statutory limits, platform features — that mismatch costs you the reader in about four seconds.

So the rule is ordinary honesty, not tactics.

• Change the date when the content genuinely changed. A rewritten section, new numbers, a removed chapter. Not a swapped adjective.
• Show both dates when the page has real history — published, and last updated. It is more useful to a reader than either one alone.
• Keep your structured data and your visible date in agreement. A dateModified that disagrees with what the page says is a small credibility problem and an easy one to avoid.
• Update lastmod in your XML sitemap honestly. Google treats it as a hint, and it is worth more on sites whose dates have historically been accurate — which is an argument for never gaming it.
• Do not bulk-update dates across an archive. It is visible, it is pointless, and it destroys the only signal you had about what was actually revised.

When a slug change is worth a redirect, and when it is vandalism

The urge to tidy a slug is strong and usually wrong. A URL change means a 301 redirect, a period where Google is re-evaluating which URL is canonical, every internal link needing an update, and every external link now arriving one hop late. In exchange you get a keyword in a URL, which stopped being worth much a long time ago.

There are three cases where the change earns its cost, and they are all cases where the URL is actively wrong rather than merely inelegant.

• The URL contains a year that is now false — /seo-pricing-2019/ on a page about 2026 pricing. Readers see it in the result and skip you. This is the one clear-cut case.
• The URL describes a different product or a former company name. A URL that says acme-widgets on a page about something you no longer sell confuses everyone, including you.
• The URL is machine junk — /?p=4187 or a 140-character path of category slugs. Genuinely worth fixing, once, as part of a broader tidy-up rather than one page at a time.

1. If you do change it: 301 the old URL to the new one, permanently, and leave the redirect in place indefinitely rather than for a tidy 90 days.
2. Update every internal link that pointed at the old URL. Letting them hop through a redirect works and is sloppy; a search-and-replace takes minutes.
3. Update the sitemap so it lists the new URL and not the old one.
4. Change one thing at a time. A slug change on the same day as a rewrite means that when something moves, you will never know which change moved it.

What to do in Search Console afterwards, and what to skip

Short list, and shorter than most people expect. Two things are worth doing and several popular ones are theatre.

Worth doing: submit the URL through URL Inspection and request indexing. There is a daily quota, so spend it on pages that matter, and note that Google is explicit that a request does not guarantee anything. Then make sure your sitemap's lastmod for that URL is accurate.

Not worth doing: resubmitting your whole sitemap, requesting indexing three days running, pinging index services, or using the Removals tool to "clear the cache". None of these speed anything up, and the third one attracts the wrong sort of tooling.

Then set a calendar reminder for eight weeks out, on the same day you make the edit. That single habit is the difference between a refresh programme and a series of anxious Tuesdays.

How long to wait, and what a normal interim looks like

Nothing can happen until Googlebot recrawls the page, which takes days on a site it visits often and several weeks on a page four clicks deep on a site it visits rarely. After that, position movement typically appears over the following four to ten weeks — the spread is wide because it depends on how competitive the query is, how much genuinely changed, and whether a core update lands in the middle of your window.

In the interim, expect noise that looks like a verdict and is not.

A short dip in the first week or two is common and is not evidence of a mistake; a re-evaluated page can move in both directions before it settles. Impressions frequently move before position does, as Google tests the page against adjacent queries. And a page that gains three new ranking queries at position 30 will show a worse average position while being unambiguously better off — which is average position behaving exactly as designed.

Two rules keep this sane. Judge the batch, not the page: twenty refreshed pages compared against their own previous eight weeks survives seasonality and a core update in a way one page's chart never will. And if the primary query is genuinely worse at week eight, revert first and diagnose second — you kept the URL, so reverting is cheap. Then read the query list again and find out what you removed.