Updating an Old Post? Decide What Happens to Its Images First
Content refreshes rewrite the text and leave the images untouched, which is how a 2021 hero ends up on a 2026 article. When to replace, when to keep the URL, when to redirect, and the caching trap that serves the old file anyway.
Content refreshes follow a predictable shape. Somebody pulls a list of declining pages, rewrites the opening, updates the statistics, adds a section, changes the date, and republishes.
The images do not come up. They were there before, they are there after, and nobody looks at them.
Which is how you end up with an article confidently marked as updated this month, sitting above a screenshot of an interface that was redesigned twice since, or a hero photograph in a visual style the rest of the site abandoned years ago. Of everything on a refreshed page, the images are the most likely to contradict the claim that it is current, because staleness in an image is immediately visible in a way a slightly dated sentence is not.
The decision for each image
Refreshing a page does not mean replacing every image on it. Each one is a separate call, and there are really only four outcomes.
Keep it. It is accurate, it looks like it belongs, it still supports the point. Most decorative and conceptual photographs fall here. A photograph of a workbench is not less true than it was in 2021.
Replace it in place, same URL. The image needs updating but the file is essentially playing the same role. Overwriting preserves whatever history the URL has, which is the main argument for it. The caching problem below is the main argument against.
Replace it at a new URL and redirect the old one. The image is genuinely different, or the filename was bad, or you want the change to propagate immediately. This is the cleanest option and the most work.
Remove it. Some images were only ever there because a template wanted one. A refresh is a good moment to notice that an image adds nothing and drop it rather than replacing it with a different nothing.
| Situation | Action | Redirect needed |
|---|---|---|
| Screenshot of a changed interface | Replace, new URL | Yes |
| Chart covering an ended period | Replace, new URL | Yes |
| Photograph still accurate, looks dated | Usually keep | No |
| Filename is IMG_4021 on a page that matters | Replace, new URL | Yes |
| Minor visual refresh of the same subject | Replace in place | No |
| Decorative image serving no purpose | Remove | Yes if published |
The caching trap
Replacing a file in place feels like the tidy option and frequently does not work the way people expect.
Images are typically served with long cache lifetimes, often measured in months, because that is the correct configuration for a static asset. When you overwrite the bytes at a URL, every cache holding the old version keeps serving it until the lifetime expires. Returning visitors see the old image. Intermediate caches serve the old image. You clear your own browser cache, see the new one, and conclude it worked.
This is why a short version token in the filename is worth having in any convention: bench-vise-workshop-v2.webp is a new URL by definition, so nothing can serve stale bytes. Building a version component into your naming convention solves this at the pipeline level instead of one image at a time, which is the only place it stays solved.
Query-string cache-busting is the quicker workaround and a weaker one, since caching behaviour around query parameters varies and you end up with a URL that looks provisional. For a genuine replacement, a new path is cleaner.
What has to change alongside the file
Swapping the image is the visible part. Four things travel with it and are routinely forgotten.
Alt text. It describes a specific image. Leave the old description on a new file and you have written something false, for exactly the audience that depends on it being true. This is the most commonly skipped step in the entire operation.
The filename. If you are replacing anyway, this is free. An image that has been sitting there as header-final-2.png can become descriptive at no additional cost.
Metadata. New file, new embedded data. And worth confirming it survives the trip, because optimisation and derivative generation routinely strip image metadata without telling anyone, so a carefully prepared replacement can arrive on the page with nothing in it.
The sitemap entry. If image URLs are in your sitemap, the new path needs to be there and the old one gone.
Redirects, and what happens if you skip them
A published image URL is not a private implementation detail. It gets hotlinked, embedded in aggregators, cited in documentation, saved, and indexed. Deleting it without a redirect breaks all of that, silently, in places you have no visibility into.
So: permanent redirect from old path to new, same as you would for a page. The image equivalent of a 404 is not a visible error most of the time, which is precisely why it goes unnoticed.
If you are replacing images across many pages at once, the discipline is identical to a migration, and the failure modes are the same ones. Keeping image visibility through a redesign or migration covers the batch version of this, and a large refresh programme is a migration in all but name.
There is a duplication angle too. Refreshes sometimes produce a new image while the old one stays published and unreferenced, and doing that across fifty pages leaves a library full of near-identical orphans. Why duplicate and near-duplicate images cause indexing trouble explains what that costs, and the fix is simply to archive the originals rather than leaving them served.
Fitting it into the refresh itself
The practical trick is making the image pass part of the refresh rather than a separate project nobody schedules.
- List every image on the page before touching the text. Including ones in the body that the template did not put there.
- Mark each: keep, replace, remove. Two minutes. Do it before rewriting, because the rewrite will change what the images need to support.
- Handle the replacements as a small batch. Generate or source them together, name them together, write the alt text together. Batching is faster and produces more consistent results than doing one per page across a refresh programme.
- Run the standard checks. A refreshed image is a new image and deserves the same pre-publish quality pass as any other, particularly if it was generated.
- Update the modified date honestly. If images were the only change and they were cosmetic, that is not an update worth claiming.
For a refresh programme covering many pages, doing an inventory first pays for itself several times over. A full-site image audit tells you which pages have genuinely dated imagery rather than which ones merely have old files, and those are different lists.
Which pages deserve the image work
Not every refresh justifies touching the images, and spreading the effort evenly across a refresh programme is how it stops happening at all.
The pages where image work pays are reasonably easy to identify:
Pages whose images are demonstrably wrong. Screenshots of redesigned interfaces, charts of concluded periods, photographs of premises you have left. These are not merely dated, they are inaccurate, and inaccuracy on a page claiming to be current is the most damaging version of the problem.
Pages that get a lot of traffic. Obvious, but worth stating because refresh lists are usually sorted by decline rather than by volume, and a page with substantial traffic and a bad hero is a better investment than a page with none.
Pages that are close to competing. A page sitting just off the first page of results is one where marginal improvements are worth making, and a genuinely better image affects how the page is judged by readers who do arrive.
Pages representing the business. Service pages, pricing, about. These are seen by people deciding whether to buy, where a dated stock photograph does measurable harm in a way it does not on an archive post.
The pages where image work rarely pays are equally identifiable: old posts with little traffic, pages whose images are decorative and timeless, and anything scheduled for consolidation or removal, where replacing an image is work you are about to discard.
A sensible split is to handle images on the top slice properly and leave the long tail alone until something makes it worth revisiting. The alternative — a rule that every refreshed page gets new images — sounds rigorous and reliably collapses under its own weight by the second week.
Expectations afterwards
Image recrawling is slow. Several weeks between publishing a replacement and seeing it reflected in image results is normal, and there is no lever that reliably speeds it up for a specific file.
This is worth knowing mainly so you do not conclude something is broken. If an image has genuinely vanished rather than merely being slow to update, that is a different problem with different causes, and the diagnostic path for images that do not appear in Google Images starts with crawlability rather than recency.
The broader point: a content refresh is the one moment when someone is already looking at an old page with permission to change it. Spending an extra ten minutes on the images while you are there is far cheaper than the separate image project that never gets scheduled. And if the replacements need to be produced rather than sourced, SEOpix writes the filename, alt text and metadata as each image is generated, which removes most of the per-image overhead from exactly this kind of batch. See how it works, or try ten free.
Frequently asked questions
Should I replace images when I update an old blog post?+
Replace them when they are inaccurate, visibly dated or were never good, and leave them when they are still true and still serving. The reason to be selective is that a published image URL accumulates image-search history and inbound references, so replacing one has a real cost. Age alone is not a reason, since a photograph of a hand tool from 2019 may be entirely current.
Can I upload a new image to the same URL?+
You can, and it preserves whatever history the URL has accrued, but caching makes it unreliable. Long cache lifetimes mean visitors and intermediaries keep serving the old bytes until the cache expires, which can be months. Overwriting in place works best when the replacement is close enough that briefly serving either version is acceptable.
Do I need to redirect an old image URL?+
Yes, if you delete or rename a file that has been published for a while. Image URLs get linked, embedded and indexed just like pages, and removing one without a redirect produces broken references in places you cannot see. A permanent redirect from old path to new preserves the connection.
Does updating an image change the page's updated date?+
It should if the change is substantive, since the modified date is a claim about the content and images are part of that. Swapping a decorative background does not warrant it, while replacing a screenshot that was showing outdated information plainly does. Bumping the date for cosmetic changes erodes the signal's usefulness.
How long does it take for a new image to appear in image search?+
Image recrawling is noticeably slower than page recrawling, and several weeks is normal rather than a problem. There is no reliable way to accelerate it for a specific file, so the practical approach is to make the change, ensure the sitemap reflects it, and stop checking. Chasing it produces anxiety and no benefit.
Should I keep the old image file after replacing it?+
Keep it in your archive and stop serving it from the page. Deleting the file outright breaks any external reference pointing at it, while leaving it in place but unreferenced clutters the library and confuses later audits. Archive the original, redirect the URL if it was published, and remove it from the page.
What is the most common mistake in a content refresh?+
Rewriting the text thoroughly and not looking at the images at all. The result is an article claiming to be current above a screenshot of an interface that has since been redesigned, which contradicts the update more visibly than any stale sentence would. Images tend to be the most obviously dated part of a refreshed page.
Do I need to update alt text when I replace an image?+
Always. Alt text describes a specific image, so leaving the old description on a new file produces a statement that is simply false, and it is false precisely for the readers who depend on it. This is the single most frequently skipped step in an image swap.
Let SEOpix handle the metadata
Filenames, alt text, EXIF fields and GPS coordinates written automatically as each image is generated. Start with 10 free images a month — no credit card required.
