Fix Scheduled Website Screenshots That Capture an Outdated Cached Page

A scheduled website screenshot can show outdated content for four different reasons: the browser reused a cached response, a service worker returned an old page, the capture happened before updated content finished rendering, or the scheduler displayed an older saved image. First determine whether the page response itself is stale or only the image artifact is stale. Then change the setting for the layer that the evidence points to and verify the result in a fresh run.

This guide uses Puppeteer for the do-it-yourself browser controls. The scheduler is unspecified, so its interface may expose different settings or none of these controls. The underlying diagnostic steps still apply.

1. Identify which part is stale

1. Open the same URL in a normal browser and confirm what content is current.
2. Compare that content with the scheduled screenshot. Record the scheduled run time and image timestamp if available.
3. Run the capture again and inspect the page response or request log if your automation exposes it. Compare the response content with what the screenshot shows.

Evidence	Likely layer	Next check
The scheduled browser receives old page content	HTTP cache, service worker, or upstream response	Test browser cache and service-worker controls; inspect response headers and content.
The response contains current content, but the screenshot does not	Capture timing or page rendering	Wait for a site-specific ready condition before taking the screenshot.
The response and a newly downloaded screenshot are current, but the dashboard shows an old image	Saved artifact, run selection, or image delivery cache	Inspect run history and retrieve the image for the latest run.
Text and content are current, but pixels differ across runs	Rendering environment	Compare operating system, browser version, settings, hardware, and headless mode.

Do not assume every stale-looking image is a browser-cache problem. A scheduler may retain prior output, and the page may also update after navigation. Check the response, rendered page, and saved image as separate evidence.

2. Disable browser cache or bypass the service worker

Browser HTTP cache and service-worker behavior are separate controls. Puppeteer provides page.setCacheEnabled(false) to disable the page’s request cache and page.setBypassServiceWorker(true) to bypass service workers for requests. Apply the control supported by the evidence; bypassing both can help isolate the cause, but it may change normal site behavior.

import puppeteer from 'puppeteer';

const url = process.env.TARGET_URL ?? 'https://example.com';
const browser = await puppeteer.launch({ headless: true });

try {
  const page = await browser.newPage();
  await page.setViewport({ width: 1440, height: 1000 });

  // Use these when diagnosing a stale response from browser cache
  // or a service worker. Remove either line if it is not relevant.
  await page.setCacheEnabled(false);
  await page.setBypassServiceWorker(true);

  const response = await page.goto(url, {
    waitUntil: 'domcontentloaded',
    timeout: 60000,
  });

  console.log('HTTP status:', response?.status());
  console.log('Final URL:', page.url());

  // Replace this with a selector that represents the updated content
  // on your site. This is more reliable than a fixed sleep.
  await page.waitForSelector('[data-page-ready="true"]', {
    timeout: 30000,
  });

  await page.screenshot({ path: 'scheduled-shot.png', fullPage: true });
} finally {
  await browser.close();
}

Install Puppeteer with npm install puppeteer and run the script with TARGET_URL=https://your-site.example node capture.mjs. Replace the example URL and readiness selector with values from the page being monitored. If the site has no ready marker, wait for a specific updated heading or other stable element that proves the new content rendered.

These browser controls do not clear a CDN or server-side cache. If the response is old even with browser cache disabled and the service worker bypassed, inspect response headers, the response body, and the site’s own cache or publishing path.

3. Wait for updated content, not just navigation

A navigation event does not prove that the content you care about is ready. A page can commit its main response, load the document, run scripts, fetch data, and render later changes. Choose a readiness condition tied to the updated content: a selector, a known text value, or an application-owned marker. Playwright’s navigation documentation describes these distinct loading stages and why a capture workflow needs a suitable readiness point: Playwright navigation lifecycle.

For example, if a dashboard fills a table asynchronously, wait for a row or status element to appear. A generic network-idle wait may be unsuitable for pages with polling or persistent requests; a fixed delay can work as a diagnostic but is less reliable than waiting for the actual content.

4. Verify the saved screenshot and rendering environment

When the page response is current but the screenshot shown by the scheduler is old, check its run history, artifact selection, download link, or image delivery path. The scheduler is not identified here, so its retention behavior and controls cannot be prescribed. Download the output for the latest run and compare it with the page at that run time.

If the content is current but the pixels vary, compare the capture environments. Operating system, browser version, browser settings, hardware, and headless mode can affect visual rendering. Playwright’s visual comparison guidance discusses these environment-dependent differences: Playwright visual comparisons.

5. Troubleshooting common failures

Symptom	Possible cause	Fix
Disabling cache changes nothing	A service worker or upstream cache still supplies the content.	Test service-worker bypass separately and inspect the actual response. Check the site’s CDN or server cache if the response remains old.
Service-worker bypass changes the page unexpectedly	The site relies on its worker for offline support, routing, or application behavior.	Use bypass only to diagnose; decide whether the scheduled workflow should reproduce the visitor experience or force a fresh network response.
The screenshot is still old despite a successful navigation	The application updates after the document loads, or the chosen wait condition is too early.	Wait for a selector or value tied to the updated page state, then capture.
The readiness selector times out	The selector is wrong, appears only after interaction, or the page failed to load its data.	Inspect the rendered DOM and console/request errors; use a real stable marker and confirm the page can reach it.
The browser reports an HTTP error or redirects to an unexpected page	The target returned an error, authentication page, or redirect.	Log response status and final URL, then check authentication, permissions, and the target route.
The output is current when downloaded but old in the scheduler UI	The UI may be showing a prior run or cached artifact.	Select the latest run and compare artifact timestamps or download URLs.
Only layout or anti-aliasing differs	Browser or host rendering differs between runs.	Pin the browser and viewport where possible and keep the capture environment consistent; do not treat pixel variation alone as proof of stale content.

6. Reliability, performance, and cost considerations

• Use targeted waits. Waiting for a meaningful page condition avoids both premature screenshots and unnecessarily long fixed delays.
• Keep diagnostic controls deliberate. Disabling cache can increase network traffic and load time. Bypassing a service worker can change behavior. Enable only what addresses the observed failure in the scheduled workflow.
• Capture evidence per run. Store the run timestamp, final URL, response status, and screenshot artifact together so you can distinguish a page problem from an artifact-selection problem.
• Account for changing pages. Ads, rotating content, personalization, and delayed data can make captures differ even when caching is correct. Choose stable content and a consistent viewport for comparisons.
• There is no universal cache-busting URL parameter. Adding arbitrary query parameters can change routing or fail to bypass upstream caches. Use documented controls and verify the response instead.

For screenshot regression workflows, keep the browser and host environment consistent. Playwright notes that environment differences can affect screenshot comparisons; see its visual comparison documentation.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF, and its options include cache TTL, wait conditions, custom headers and cookies, and full-page capture. See the ScreenshotNeo API documentation for parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed; response headers identify the page verdict and billing status. An MCP server lets AI agents use the take_screenshot, get_page_info, and capture_pdf tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Create a free ScreenshotNeo account to start with 1,000 screenshots a month and no card.

FAQ

Does a new browser context guarantee a fresh page?

No. It can avoid state carried by a reused context, but a service worker, upstream cache, application data layer, or saved screenshot can still be involved. Inspect the response and artifact.

Should I always bypass service workers?

No. Bypass is a diagnostic and workflow choice. If the site’s normal visitor experience depends on its service worker, bypassing it may produce a different page.

Can screenshots vary even when the page is not stale?

Yes. Browser and host rendering differences can alter pixels while the underlying content remains current.

Which scheduler setting fixes this?

That depends on the scheduler and site. The scheduler name, browser lifecycle, service-worker use, and whether the latest run’s downloaded image is current determine which specific setting to change.