Why Does a Website Screenshot Show an Old Cached Page?
An old screenshot can come from browser, CDN, proxy, history, or screenshot-tool caching. Trace the layer before trying to refresh it.
A website screenshot can show an old page because some layer reused a stored response or capture: the browser, a proxy or CDN, browser history, or the screenshot service itself. Start by opening the exact URL in a fresh private window and comparing it with the screenshot. Where the stale version appears—and for whom—usually tells you which layer to investigate.
These caches are independent. Clearing your browser cache does not purge a CDN, and refreshing a page does not necessarily tell a screenshot service to discard an older capture. The steps below help identify the responsible layer before you change settings.
1. Identify where the old version appears
- Check the exact URL. Compare the hostname, path, query string, and any redirect destination. Confirm whether the screenshot shows a logged-in or personalized page.
- Open it in a fresh private window. Load the URL directly rather than using Back or Forward. Compare the result with the screenshot.
- Try another browser or network. If only one device or session is stale, a local browser or session issue is more likely. If several users or locations see the same old content, investigate a shared cache.
- If only the screenshot is stale, inspect the capture. Check its URL, capture time, session, and refresh or recapture controls. The screenshot provider is not specified here, so the exact control name depends on that product.
| What you observe | Likely place to investigate | Next step |
|---|---|---|
| Only one browser is old | Browser cache, session, or history restoration | Load the exact URL in a private window; compare another browser. |
| It appears after Back or Forward | Back/forward cache (bfcache) | Navigate directly to the URL and compare with a reload. |
| Several users see the same old page | Proxy, reverse proxy, or CDN | Ask the site operator to inspect cache rules and the affected URL. |
| Browser is current, screenshot is old | Screenshot tool, capture URL, or session | Verify capture details and request a new capture. |
2. Understand the caching layers
Browser HTTP cache
Browsers can store responses and reuse them according to HTTP caching rules. The response’s Cache-Control directives govern freshness and revalidation. When a stored response needs validation, a browser can use a validator such as ETag to ask whether the representation changed. See MDN’s references for Cache-Control and HTTP caching.
no-cache generally means a stored response must be revalidated before reuse; it does not mean “never store.” no-store is the directive associated with not storing a response. They are not interchangeable, and changing a response directive affects only caches that honor it and requests to which it applies. A meta tag is not a universal fix for HTTP response caching.
Browser history and bfcache
When you navigate Back or Forward, a browser may restore a page snapshot from its back/forward cache (bfcache), rather than fetching and rendering a new response. An old-looking page after history navigation therefore does not, by itself, prove that a normal URL load is using a stale HTTP cache entry. Compare direct navigation with history navigation. MDN discusses this distinction in its Cache-Control reference.
Proxy, reverse-proxy, or CDN cache
A shared intermediary can store a response separately from each visitor’s browser. A browser cache clear cannot remove that copy. If multiple users or regions see the same stale page, the site operator should inspect the cache rules for the affected URL and use the provider’s purge controls when evidence points to that cache. See Cloudflare’s guidance on common CDN issues and fixes.
Screenshot-service cache or capture state
A screenshot service could reuse a stored capture, or the capture could use a different URL, session, or point in time from your current browser visit. Treat this as a diagnostic possibility, not a confirmed cause: the screenshot product and its caching behavior are unknown. Compare the exact URL and capture timestamp, then use that product’s refresh or recapture control.
3. Fix the layer you have evidence for
If one browser is stale
- Load the full URL directly in a private window.
- Try a reload that revalidates or bypasses local cached resources. The exact behavior depends on browser, request, and server details; no shortcut guarantees a fresh fetch of every resource.
- Compare response headers, especially
Cache-ControlandETag, if you can inspect the network response in developer tools. - If another browser or network is current, investigate local cache, cookies, or session state rather than purging a site-wide cache.
If only the screenshot is stale
- Confirm the capture’s hostname, path, query string, and any authentication or session context.
- Check when the screenshot was captured and whether it represents the page state you expect.
- Request a fresh capture using the screenshot tool’s documented refresh or recapture option.
- If a fresh capture is still old while direct visits are current, consult that provider’s documentation or support with the URL and capture time.
If several visitors see stale content
The site operator should inspect the response and cache rules for the affected URL, then identify whether the stale copy is at an origin-side proxy or CDN. Purge the identified layer using its provider controls, and verify the result from more than one location. Cloudflare documents purging cached content; its controls apply to site operators with access to the zone, not ordinary visitors.
Be careful with personalized pages. A cache rule that stores dynamic HTML can interact badly with login responses and cookies. Cloudflare documents a configuration example involving dynamic content and login issues. This is a risk to investigate when relevant, not proof that it caused a particular stale screenshot.
4. Troubleshooting common cases
| Symptom | Possible cause | What to do |
|---|---|---|
| Hard reload seems to change nothing | The stale copy is at a shared cache, or the page is being restored through history. | Open the exact URL directly; compare another browser or network. Ask the site operator to investigate a CDN only if evidence suggests a shared stale copy. |
| Private window is current but normal window is old | Local cached state, cookies, or personalized session. | Compare with another browser and inspect whether login or cookies change the response. Clear only the relevant local site data if needed. |
| Browser is current but a generated image is old | Old capture, different URL/session, or screenshot-tool reuse. | Check the capture timestamp and URL; request a recapture through the tool. |
| Some locations are current and others are old | Different intermediary cache state or cache rules. | Have the site operator compare responses by location and inspect the provider’s cache behavior. |
| Login disappears or personalized content is wrong | Cache rules may be storing dynamic HTML or handling cookies unexpectedly. | Review rules for authenticated and cookie-bearing requests; follow the CDN provider’s guidance for dynamic content. |
| Only Back/Forward shows the old page | History snapshot restored from bfcache. | Compare direct navigation and a reload before concluding the HTTP cache is stale. |
5. Capture a fresh screenshot in code
If you control the capture workflow, make the URL explicit and trigger a new capture using your tool’s documented API. A fresh browser request alone does not guarantee that a screenshot service discarded a prior stored image. The example below shows one API request with ScreenshotNeo; the ScreenshotNeo API documentation covers its request options.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://example.com/page \
-o page.webpPython
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page"},
timeout=90,
)
r.raise_for_status()
with open("page.webp", "wb") as image_file:
image_file.write(r.content)Node.js
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://example.com/page',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(({ writeFile }) => writeFile('page.webp', image));6. Make repeated captures more reliable
- Use the exact target. Include the intended path and query parameters; account for redirects and authentication.
- Separate page freshness from image freshness. A current page and an old saved screenshot are different problems. Record the capture time alongside the image.
- Check dynamic state. Cookies, login state, geolocation, and page timing can make two valid captures look different.
- Use response evidence. Compare
Cache-Control,ETag, and observed content across sessions or locations before changing cache rules. - Change one layer at a time. A browser reload, screenshot recapture, and CDN purge affect different systems. Retest after each targeted action.
7. Performance, reliability, and cost
Cache reuse can reduce repeat work, but it can also make an image lag behind the live page. When freshness matters, distinguish a cached page response from a cached screenshot and make the capture time visible in your workflow. Avoid repeatedly purging shared caches without evidence: a purge is a site-operator action and can affect more than the one browser where the problem was noticed.
For ScreenshotNeo, caching is an option with a TTL you choose. Its response headers identify the page verdict and whether the request was billed; cache hits cost nothing. Failed loads, blank pages, bot checks, and CAPTCHAs also cost nothing. Review the response’s X-Page-Verdict and X-Billed headers when diagnosing a capture. The available plans are Free (1,000 shots/month, no card), Starter ($5 for 3,000), Growth ($15 for 15,000), Pro ($39 for 60,000), Scale ($99 for 250,000), and Business ($249 for 1,000,000); yearly billing gives two months free, and every feature is on every plan.
Or skip the browser setup
ScreenshotNeo returns an image or PDF from one API request. Cookie banners are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each of those steps can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers say what happened. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://example.com/page \
-o page.webpSee the API documentation for request options, then sign up for 1,000 free screenshots a month, with no card.
FAQ
Does “clear cache” fix every old screenshot?
No. It can help with local browser state, but it does not purge a CDN or force a screenshot service to create a new capture.
Does no-cache mean the browser never stores the page?
No. It generally requires revalidation before a stored response is reused. no-store is the directive associated with not storing it.
Is a screenshot necessarily from a search-engine cache?
No. The screenshot source is unknown; browser, intermediary, history, and screenshot-tool behavior are all possible explanations.
Can I purge a CDN as a visitor?
Usually the provider’s purge controls are available to the site operator, who must have access to manage the site. Visitors can report the stale URL and evidence to that operator.
