Images still look old after replacement: clear the cache or change the asset URL?

If replaced images remain old, avoid repeated cache clearing first. Unsaved references, wrong upload destinations, or browser and intermediary caches may explain it. Each needs different handling; mixed changes complicate investigation.

Start with the file actually requested by the page, then its contents. Only correct references and files justify cache investigation. New URLs also need version records and every usage location maintained.

Find actual references beyond CMS filenames

Identify the real page and position: cover, body, background, or separate mobile image. These may use different fields; cover replacement cannot update the body automatically. Narrow scope to one location.

Authorized implementers should inspect its actual asset URL. Editor names, local files, and final browser addresses may differ. Record the complete public path and compare the update list.

An old body reference with a new upload elsewhere cannot be fixed by browser clearing. Change the reference, save, and reopen to confirm the new URL.

Backgrounds and normal images may use different implementations. Editor changes do not affect unrelated backgrounds. Locate the module's real asset entry before operators repeatedly replace irrelevant fields.

Responsive images or services may supply separate mobile and desktop candidates. Inspect the current device's actual file beyond default URLs. Old mobile results may indicate unchanged candidates rather than necessarily caching. See How to optimize the images on the corporate website? It's not the case that the smaller the pressure, the better: clarity, loading speed, SEO and accessibility should all be addressed simultaneously for related checks.

A short record of page, position, current URL, and expected version is actionable and avoids same-name or multi-article confusion.

Check whether the URL's file changed

Compare actual returned imagery with the publication file. Old URL content may indicate upload destination, overwrite, derived files, or server processing; investigate rather than only ask visitors to refresh.

Same-URL upload success may identify a written path different from the page's reference. Directories, case, subdirectories, and duplicate names affect it. Check destinations rather than repeat uploads.

Tools may generate new paths, overwrite, or reject duplicates. Success alone cannot establish behavior. Controlled samples in isolated locations can establish rules before official asset operations.

Generated thumbnails and formats need update timing checks. Replaced originals do not establish regenerated files. Some systems rebuild manually or have independent version identities; follow actual processes.

Distinctive new-version features such as composition or subject placement help controlled comparisons. Changed file size alone cannot prove correct content.

Existence differs from usability. Wrong formats, encoding, or permissions may fail loading or trigger fallbacks. Open actual publication files before checking page results.

Distinguish browser and intermediary caches next

Local browsers, upstream caches, and image services may retain earlier versions. HTTP rules govern reuse and revalidation, but implementers need actual layers and policies rather than assumed common settings. See Corporate Website Launch Process and Checklist for related checks.

Compare ordinary loading with a controlled new session. New imagery only in fresh sessions suggests local caching; old imagery everywhere leads to intermediary and file checks. This narrows possibilities without proving final causes alone.

Developer tools can show URLs, responses, and cache reuse. Operators need not understand every header; ask implementers for evidence at the same location rather than conclude "Probably cache."

Keep one confirmed version fixed during investigation. Changing images between requests makes comparisons reflect new files rather than caches. Stable content and addresses keep evidence interpretable.

Clear by scope. For one image, identify resource-specific refresh or purge first. Whole-site clearing affects more pages and cannot fix wrong references or ungenerated versions.

Visitors manually clearing browsers is unsuitable as lasting update policy. Forced refresh proving new content establishes only that operation; ordinary updates need separate checks.

Same-URL overwrites and versioned paths suit different needs

Same-URL overwriting suits explicit update mechanisms and references meant to share the latest picture. Actual cache updates are required to avoid one URL retaining unstable contents.

Versioned addresses keep independent new paths and old files, aiding tracking and recovery. Follow existing version or content-identity workflows for creation and references rather than unexplained random filenames.

Neither strategy suits all websites. Shared logos and fixed references differ from article illustrations. Determine whether every location should change together before choosing.

Query parameters can sometimes version files, depending on cache-key rules. Random suffixes cannot guarantee universal refresh. Keep stable recorded versions rather than new values on every visit and meaningless requests.

List all references when shared resources change paths. Missed old URLs may explain old images rather than slow propagation. Same-URL overwrites instead change every shared use; confirm that scope before unrelated visuals change.

New addresses need actual usage locations and candidates updated. Upload alone leaves old references unchanged. Versioning covers generation, references, saving, and checking, beyond naming.

Verify normal displays under old and new access conditions

Retain old and new addresses or overwrite scope, target pages, purposes, and expected versions. Check against this list rather than memory of what looks new.

For multiple sizes, sample chosen candidates under relevant conditions and record coverage. Every pixel width needs no repeat test, but key crops, separate mobile images, and desktop files do.

Use previously visited devices and new contexts with ordinary loads. Check mobile and desktop candidates, lists, and articles rather than one device or module.

Test returning, reloading, and shared links under actual use. New paths need saved references; same-URL updates need normal visits without special actions.

For differences, record URL and access conditions before further overwrites. This distinguishes propagation, missed candidates, and incorrect references. Reuse samples after each adjustment so repeated replacements do not erase evidence.

Success means correct versions at every agreed location, loadable assets, normal updates, and traceable old files under maintenance rules. "I saw it after forced refresh" alone is insufficient.

Frequently asked questions

Does forced-refresh success complete the update?

No. Confirm ordinary visits on agreed devices retrieve expected versions. Special refresh helps diagnosis without replacing visitor-path acceptance.

Do old images on every device prove server caching?

No. References, destinations, or derived files may be wrong. Check URLs and files before intermediary caches rather than assume causes.

Does renaming solve every old-image issue?

Only some. New files need correct uploading and references and candidates updated. Unsaved URLs or unchanged locations are not fixed automatically.

Why can mobile remain old after replacing the original?

It may use separate crops or responsive candidates. Inspect actual loaded files and derived updates rather than require mobile cache clearing because desktop works.

Can old images be deleted immediately afterward?

Check shared references and recovery first. Old articles or history may still use versioned files. Cleanup follows actual relationships, beyond new-page appearances.