When only some visitors see old content, check the browser, page, proxy, and edge caches in order. Website cache invalidation, the act of marking stored copies as outdated so systems fetch fresh content, has cleared one layer but missed another. The pattern often points to separate browser, plugin, server, and edge caches rather than a failed update. Checking each layer in order finds the stale copy fast and avoids clearing everything blindly.
Table of Contents
- Is the old page in the visitor's browser?
- Which site layer still holds the old copy?
- Did the update clear every copy?
- Why do logged-in visits differ from public visits?
- How do you prevent repeat stale-page reports?
Is the old page in the visitor's browser?
Ask the affected visitor to reload with cache bypass and then test the same address in a private window. If the private window shows the new page, the old copy lives in that browser alone. A browser keeps images, stylesheets, scripts, and sometimes full pages to load faster.
A hard refresh, a different browser, or adding a harmless query test such as ?check=2 can confirm the difference. Site owners cannot clear a visitor's browser from the server. They can shorten browser storage time for changing files and rename updated assets so browsers fetch the new file.
Which site layer still holds the old copy?
Many sites stack several caches. A WordPress plugin may store full pages. Drupal may store rendered blocks for anonymous traffic. The host may run a reverse proxy that holds copies in front of the site.
A delivery network may copy pages to edge servers near visitors. Each layer has its own lifetime and clear button. A fix in the content system does not clear the proxy or edge copy, so one region can stay stale while another looks fresh. Compare the affected address across a direct origin test, a bypass-cookie test, and the public address. When only the public address is stale, the edge or proxy layer is the likely holder.
Did the update clear every copy?
An edit often clears only one page address while related copies remain. Homepages, category listings, search pages, feeds, and accelerated-mobile variants can keep the old title, excerpt, or image.
Run these checks after each important change. Full-site purges fix stubborn cases but remove every stored copy at once. Use them sparingly on large or busy sites because the next wave of visits must rebuild each page and response can slow briefly.
- open the edited page, its listing pages, and one filtered address in private windows
- purge the exact addresses plus related listings rather than the whole site at first
- confirm the edge status header or plugin log shows a fresh fetch, not a hit
- repeat the check from a second network or mobile connection when reports vary by place
Why do logged-in visits differ from public visits?
Many sites serve separate copies for anonymous and signed-in traffic. Anonymous visitors often get a shared cached page, while signed-in editors, members, or shoppers bypass that cache and see fresh or personalized material. Cookies, cart contents, location, consent choice, and test variants can also split the cache.
One visitor may hold a cookie that routes to an older variant while a colleague without that cookie gets the new page. Check by comparing anonymous, signed-in, and fresh-cookie visits side by side. When only one group is stale, review the cache rules for cookies and personal blocks before clearing shared caches again.
How do you prevent repeat stale-page reports?
Give changing assets new filenames during each build so old stylesheets and scripts cannot linger. Common practice adds a content hash such as style.9f3a.css, which forces browsers and edge servers to fetch the changed file. Keep short storage times for fast-changing pages and longer times for stable images and fonts.
Set clear purge rules for publishing, so saving a post clears its page, listings, feeds, and related blocks together. Keep a one-page runbook near the deployment checklist. Record each cache layer, its lifetime, and its purge step with every release so the next report takes minutes to resolve.
You Might Also Like
- WordPress Maintenance: OAuth Tokens After Google Account Recovery: When to Check Reauthorization Requirements
- WordPress Maintenance: Contact Form Submissions During an Email Outage: How to Check Whether Entries Were Stored Locally
- Website Maintenance Schedule: How Often Should a WordPress Site Be Checked?
