Every site over two years old has them: posts that still bring people in, written in a style the business has outgrown, saying things that were true in 2024. The instinct is to delete them or to start again on a new URL. Both throw away the one thing that cannot be rebuilt — the history attached to the address.
This is the method I use, in the order I use it, on my own site and on clients’. It matters most for the posts nobody is proud of any more, because those are usually the ones quietly holding a position in search.
Find out what each page earns before you touch it
Open Search Console, set the range to the last twelve months, and list the pages by impressions rather than clicks. Impressions tell you what Google thinks the page is about and is willing to show. Clicks tell you whether the result was appealing. The two problems have completely different fixes, and pages get deleted every week because somebody looked only at the second number.
For each candidate, write down three things: total impressions, the three queries it appears for, and its average position on those queries. Ten minutes for twenty pages, and it converts an argument about taste into a decision about assets.
A page with impressions and no clicks does not need rewriting. It needs a better title and description, which is an afternoon rather than a week. A page with neither is where the rewriting decision actually lives.
Measure the title and description by pixel width rather than character count while you are there, because that is what a search result is laid out by. A title that reads perfectly in a spreadsheet can be cut mid-word on the page, and the cut usually lands on the part that would have earned the click.
Three outcomes, and the evidence that picks one
Rewrite in place. The page holds a query cluster, or it covers ground nothing newer covers. The URL stays, the argument is replaced, and the history carries. My own SEO, AEO and GEO post is the example I point at: same address since 2025, an argument that has been replaced completely.
Merge and redirect. Something newer already answers the question better. Take whatever is worth keeping out of the old post, put it in the newer one, and 301 the old URL to it. Google’s own documentation is clear that a permanent redirect is the correct signal here, and that it passes the page’s standing to the target.
Leave it alone. The bar for touching a page at all is that you can say what will improve. “It is old” is not a reason. “It is embarrassing” is a reason to rewrite, not to delete.
Deleting outright is the fourth option and it is almost always wrong. A URL that 404s throws away every link anyone ever made to it. If the content genuinely should not exist — a page about a product you no longer sell, a claim you cannot support any more, markup that is no longer eligible — redirect it to the nearest useful page instead.
Never change the URL
This is the single most expensive mistake in the whole exercise, and it is usually made for tidiness. The slug is where the history lives. Renaming it to something neater and redirecting the old one works, but it spends a redirect and a recrawl to buy nothing a reader will ever notice.
The same applies to a post whose title names something you no longer want in a title. Change the visible title and the SERP title; leave the slug exactly as it is, even when it now reads oddly. I have posts whose slugs mention cities I removed from the headline years ago, and they still rank.
What a rewrite actually replaces
Not the topic. If you change what the page is about, you have not rewritten it, you have published a new post on an address that ranks for something else — and the position you were protecting goes anyway, slowly and confusingly.
A rewrite keeps the question the page answers and replaces everything else: the structure, the examples, the sources, and anything that has since become untrue. In practice the old post’s H2 list is the thing to argue with. If half of it is still the right skeleton, you are refreshing. If none of it survives, ask honestly whether this is a merge.
Bring it to the same standard as a new post — the same length, the same structure, the same live-checked links — because a half-updated page reads worse than an old one and Google’s guidance on helpful content is about the page in front of the reader, not about how recently it was edited.
Dates, and the thing people do wrong with them
Changing the publication date to today so the post looks fresh is the common move, and it is the one Google’s documentation on publication dates warns against: the date should reflect when the content was actually published or meaningfully updated, and artificially bumping it is treated as misleading.
The honest arrangement is two dates — published then, updated now — shown plainly, with the structured data matching what the page shows. If you have genuinely replaced the argument, an updated date is accurate. If you fixed two links, it is not.
Check the pair before you touch either one
On a bilingual site there is a second question nobody asks: does this post have a twin, and is the twin the same argument? Rewriting the English half of a pair and leaving the Arabic saying something else produces two pages that contradict each other and one translation link that is now a lie.
Three possibilities. The pair exists and both need the same treatment. The pair exists but the other language was already better, in which case the rewrite is a translation job. Or there is no twin at all, and the rewrite is the cheapest moment you will ever get to add one, because the argument is already settled and only has to be written once more.
Publish, then prove it actually registered
Two checks, and the second one is the one everybody skips.
First, the page: open it, read it as a reader, click the links. Second, the sitemap. An edit made through an API or a bulk tool can change the post’s modified date in the database while leaving its lastmod in the sitemap at the old value, which means a crawler has no reason to come back. Open the sitemap and look at the entry for the page you just changed. If the date has not moved, open that post in the editor and press Update, which rebuilds the file.
Then request indexing for the URL in Search Console, once. It is not a queue-jumping trick — it is a signal that the page changed, and it is the only manual lever there is.
What to watch afterwards, and for how long
Give it four weeks before drawing conclusions, and compare like with like: the same twenty-eight days against the previous twenty-eight, for that URL only, on the queries it already held.
Impressions moving before clicks is normal and is the signal that Google has re-understood the page. Clicks moving without impressions means the title and description did the work. Both falling means the rewrite changed what the page is about, which is recoverable if you notice in month one and much harder later. Google publishes a guide to debugging traffic drops that is worth reading before you panic at week two.
Doing it in batches without breaking things
Five to ten pages at a time, and never a whole site in one week. Batches let you attribute a change to a decision; a site-wide sweep gives you one uninterpretable graph, and if something goes wrong you will not know which of forty edits caused it.
Order the batches by what they protect rather than by how bad they look. The page with three hundred impressions and an embarrassing structure comes before the page with none and a perfect one, every time, because the first is an asset being wasted and the second is only a tidiness problem.
Keep a one-line record per page: what it was, which of the three outcomes you chose, the evidence, and the date. Six months later that record is what stops somebody rewriting the same page again for the same reason, and it is the same discipline that makes any supplier’s work reviewable rather than a matter of trust.
Where a site has fifty of these and no in-house time to work through them, that is a defined piece of work rather than an open-ended retainer, and Tothiq takes on exactly that kind of content and visibility programme across the GCC.
Frequently asked questions
Is it better to rewrite an old post or publish a new one?
If the old post holds impressions on the queries you want, rewrite it: you are inheriting a position that a new URL starts without. If it holds nothing and the ground is genuinely different, publish new. The mistake is publishing a near-duplicate on a fresh URL, because then the two compete and the older one usually wins the wrong half.
We have a hundred old posts. Where do we start?
With the twenty by impressions, not the hundred by age. Most sites find that a handful of pages carry nearly all the visibility, and that several of them are ones nobody would have chosen to keep. Fix those, in batches of five, and only then decide whether the tail is worth the time.
Will a 301 redirect lose us traffic?
A correctly implemented permanent redirect passes the page’s standing to the target, and Google documents it as the right tool for content that has moved. What loses traffic is redirecting to something that answers a different question, because the target does not deserve the queries and will not hold them. Redirect to the page that genuinely replaces it, or do not redirect at all.
Should we update the date on a refreshed post?
Only if the content genuinely changed in a meaningful way, and then show both dates rather than replacing the original. Bumping dates on unchanged content is explicitly discouraged, and readers notice the mismatch anyway when the examples inside are years old.
How long before we know whether it worked?
Four weeks for a first read, eight for a settled one, and compare the same URL against its own previous period rather than against the site total. Anything faster than that is noise, and anything you conclude in week one will usually be reversed by week three.