A cached page may outlive a release
A visitor can receive an older HTML page after a new script has been deployed. If the old page expects behaviour that the replacement script no longer supports, the update can break a form or interaction. I have worked on script releases that change the filename with the content so old and new references remain distinguishable.
Publish assets before their references
The new script needs to exist before a page points to it. Existing versioned assets should remain available while cached pages can still reference them. The retention period depends on cache headers and deployment behaviour; deleting every old file immediately can undo the benefit of versioned names.
Purge deliberately and check real pages
In my WordPress work, I combine application caching with CDN cache purging and CSS cleanup. A purge is followed by checks of real routes, forms and the assets they load. I also check multilingual pages and PDF behaviour in Safari when those are part of the change. A successful upload alone does not establish that the published workflow works.
Keep a recoverable release
I retain the previous release or affected files outside the public document root, then verify after publishing. The release notes identify changed files and cache steps without containing credentials. Browser checks and isolated tests give a small, repeatable acceptance checklist. A rollback should restore the page and its matching assets together.