How to Use Apify for Website Change Detection with Scheduled Screenshots

Direct answer: Use an Apify Actor or saved task that captures a webpage and compares each capture with a baseline, then schedule recurring runs in Apify. Apify schedules launch Actors or tasks; the selected Actor implements screenshot capture, baseline storage, and comparison. Those capabilities and outputs vary by Actor, so check its current documentation and run it against your target page before relying on alerts.

This guide walks through choosing an Actor, establishing a baseline, scheduling captures, interpreting results, and diagnosing failures. For recurring monitoring, keep the capture settings and baseline storage consistent between runs.

1. Choose an Actor that captures and compares pages

Apify’s schedule feature runs an Actor or task on a timetable. It does not, by itself, take screenshots or detect page changes. Select an Actor that explicitly supports both the capture type you need and comparison against a prior run.

Apify Store listings include community-maintained examples such as Website Screenshot API & Visual Change Monitor, Website Visual Monitor, and Website Change Monitor & Alert System. Their listed features are specific to those Actors and can change. Open the current listing and verify its input schema, output schema, storage behavior, maintenance status, pricing, and limits before using it in production.

Compare candidates on these points:

Capture scope: full page, viewport, or a selected element. Use a selector only if the Actor supports it and the selector matches the intended region.
Comparison output: whether it reports a change percentage, applies a threshold, or produces a highlighted diff image. Confirm the exact method and output fields in the Actor’s current documentation.
Baseline persistence: where the reference screenshot or page snapshot is stored and whether it remains available to scheduled runs. Some listings describe named key-value storage or stored screenshot references; these are implementation choices, not platform-wide behavior.
Noise controls: whether the Actor can ignore regions or tune a threshold. Dynamic ads, clocks, rotating content, and personalized elements can create visual changes without a meaningful page update.
Cost and upkeep: check the current Store price, usage limits, and update history. Store listings and commercial terms can change.

Use a focused element capture when the Actor supports it and you only care about one stable section, such as a product price or release-notes panel. Whole-page capture is more appropriate when layout, navigation, or broad visual changes matter. Do not assume every Actor supports every capture mode.

2. Run once to establish the baseline

The first successful run is commonly used to save the reference snapshot. It is setup, not evidence that the page stayed unchanged. Later runs compare against that reference, but the exact first-run behavior depends on the selected Actor.

Open the Actor or create a task from it in Apify Console.
Enter the target URL and any Actor-specific capture settings, such as a CSS selector, device, viewport, or comparison threshold.
Run it manually and wait for the run to finish successfully.
Inspect the run output and logs. Confirm that a screenshot was produced and that the Actor says a baseline was created or saved.
Check the Actor’s instructions to find where that baseline is stored and how later runs retrieve it. Verify that the storage survives between runs.
Run it again after a suitable interval or controlled page change. Confirm that the output distinguishes a comparison from an initial baseline run.

Keep viewport, device, selector, URL, and other state-affecting settings consistent. Changing those between runs can produce differences unrelated to the page content. This is practical guidance based on how capture settings affect an image, not a special Apify scheduling requirement.

3. Schedule the Actor or task

Apify’s official documentation describes schedules as a way to run Actors and tasks at selected times. Schedule configuration uses cron expressions and supports a timezone; the Console offers a visual setup tool. The scheduling guide says an Actor should have been run at least once before scheduling it.

In Apify Console, open the schedules area and create a schedule.
Choose the Actor or saved task that passed your manual baseline check.
Set the recurrence with the Console’s schedule interface or a cron expression, and select the timezone that should govern it.
Review the action and schedule settings, then save and enable the schedule.
After the next scheduled run, inspect its status, output, and comparison result.

Pick a cadence based on how quickly you need to notice changes and the Actor’s current resource use and price. Hourly or daily schedules are examples found in some individual Actor descriptions, not universal recommendations.

Schedules usually start near their configured time, but do not treat the schedule as a precise alert-latency guarantee. Apify’s scheduling documentation says scheduled events are generally fired within one second of their scheduled time, while also explaining that system overload or a server shutdown can delay runs. Plan your response window around that caveat.

For automation, Apify’s API supports creating schedules with schedule configuration and actions. Consult the current Create schedule API documentation for required fields, authentication, and request format. The schedule API creates the launch schedule; you still need an Actor that implements capture, comparison, and persistent baselines.

4. Read screenshots, diffs, and run status

Output formats differ by Actor. The cited Store listings describe outputs such as current screenshots, percentage-of-page changes, diff images, screenshot and diff keys, and a flag indicating whether a baseline exists. Treat these as listing-specific examples. Read the selected Actor’s output schema and use its actual field names.

Interpret results in this order:

Check the run status. A failed or unfinished run cannot show that the website was unchanged.
Confirm the capture exists. A missing screenshot or stale result may point to a capture or storage problem.
Check whether the result is a baseline. An initial snapshot is not a comparison with a previous run.
Review the reported change and diff. Look for dynamic regions or capture-setting differences before treating a visual difference as a meaningful site change.
Open the current and baseline images. A percentage or threshold is a signal to review, not necessarily a complete explanation of what changed.

Monitor Actor and task health separately from website changes. Apify’s monitoring documentation covers run status, performance metrics, and alerts. Configure or review those signals so a failed run is not mistaken for a quiet website.

5. Troubleshoot common problems

Symptom	Likely cause	What to check or fix
No comparison on the first run	The Actor is establishing its baseline.	Confirm the baseline was saved. Run it again and verify that storage is available to the next run.
Every run looks changed	Dynamic page content, unstable capture settings, or an overly sensitive comparison.	Compare the images, keep viewport and selector fixed, and use the Actor’s supported threshold or ignored-region controls if appropriate.
Baseline disappears between runs	Baseline storage may be temporary, run-scoped, or configured differently than expected.	Read the Actor’s persistence instructions and configure storage that survives scheduled runs. Do not assume one Actor’s storage setup applies to another.
Screenshot is missing or blank	The capture may have failed, the page may not have loaded, or the Actor may have returned an error.	Inspect run status and logs, verify the URL is reachable from the Actor, and follow the Actor’s documented wait or access settings.
Scheduled run did not start at the expected second	Schedules can be delayed under system conditions.	Check the schedule timezone, enabled state, and run history. Allow for delays described in Apify’s scheduling documentation.
Schedule runs, but outputs are hard to locate	The Actor may store images in a dataset, key-value store, or another location.	Use the Actor’s output schema and instructions to locate screenshot, diff, and baseline fields.
Run failed and there is no change result	Capture or Actor execution failed before comparison completed.	Use run status and logs to diagnose the failure. Do not interpret a missing result as “unchanged.”

6. Performance, reliability, and cost

Each scheduled run consumes whatever compute, storage, and other resources the selected Actor requires. Actual costs and limits depend on the Actor, its configuration, and current Apify terms; check the live listing and your usage rather than relying on an old estimate.

Reduce unnecessary work: monitor only the pages and page regions that matter, at a cadence appropriate to the expected change rate.
Keep comparisons repeatable: use consistent viewport, device, URL, and selector settings. Page personalization or rotating content can increase noise.
Plan for missed or delayed runs: inspect run history and health alerts. A schedule is not proof that each capture succeeded on time.
Protect useful history: confirm baseline and output retention behavior before depending on a long-running monitor.
Review access constraints: check the target site’s access rules and your applicable obligations. This workflow does not establish universal permission to capture any site.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. A GET request captures a URL as PNG, JPEG, WebP, or PDF. Its clean-shot flow accepts cookie or consent banners as a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and responses include X-Page-Verdict and X-Billed headers. ScreenshotNeo does not provide the Apify schedule and screenshot-diff workflow described above, so use it when you want straightforward captures or to build capture into your own monitoring process.

For this example, replace YOUR_API_KEY with your key and change the target URL as needed. See the ScreenshotNeo API documentation for request options.

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

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo also has an MCP server for Claude, Cursor, and other MCP clients, with take_screenshot, get_page_info, and capture_pdf tools. It includes 63 options such as full-page capture with lazy images loaded, CSS element capture, device presets and custom viewports, custom CSS or JavaScript, wait conditions, request blocking, cookies and headers, caching, async jobs, and bulk capture. Every feature is available on every plan. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Frequently asked questions

How do I schedule website screenshots with Apify?

Choose an Actor or task that captures and compares screenshots, run it once to establish its baseline, then create a schedule in Apify Console with the desired recurrence and timezone.

Can Apify compare screenshots from one run to the next?

A selected Actor can do this if it implements screenshot comparison and stores a baseline across runs. Scheduling alone does not compare pages.

Will every visual difference mean the website’s content changed?

No. Dynamic content, personalized pages, and changes to capture settings can all affect screenshots. Review the diff and the Actor’s comparison controls before deciding what a result means.

Can I use a schedule without creating a saved task?

Apify’s schedule documentation supports actions that launch an Actor or a saved task. Use whichever configuration suits your workflow and verify its inputs before enabling recurring runs.