How to Monitor Website Visual Changes with Make and Slack

Make can automate website change checks and send alerts to Slack. Its published Website Change Monitor and Alert template retrieves page content, compares it with a stored snapshot, summarizes meaningful changes, and records the result. That is content comparison; it does not establish pixel-level screenshot comparison. To detect layout or visual rendering changes, capture rendered pages on each run and compare the resulting images separately.

A useful monitor needs more than a scheduled fetch: it needs a baseline, noise filtering, stored evidence, and a failure path that distinguishes fetch errors from “no change.” This guide walks through both approaches and explains where Make’s published template fits.

1. Choose what “change” means

Goal	What to compare	What it can tell you
Content monitoring	Fetched response body or extracted text	Whether returned content changed, after filtering predictable noise
Visual monitoring	Rendered screenshots from two checks	Whether the rendered page appearance changed; differences may include layout, imagery, fonts, or dynamic content
Availability monitoring	Request status, timing, and fetch success	Whether the page could be retrieved; this alone does not show whether its content or appearance changed

An ordinary HTTP GET may return the server response without running the browser JavaScript needed to render a page. Make’s HTTP app supports HTTPS requests and documents GET and HEAD requests; HEAD retrieves status and headers without a response body, and some servers may not support it. Use GET for content comparison. If the target needs browser rendering or resists ordinary requests, the Make template uses Bright Data Web Unlocker, which adds a separate service and account dependency.

Make also lists a URL screenshot action through its HTML/CSS to Image integration. The reviewed documentation does not describe a screenshot-diff module in the website-change template. A screenshot capture is evidence, but it does not by itself compare two captures.

2. Prepare the monitor

Choose target URLs. Start with a small list of pages whose changes matter. Store a stable identifier and the URL for each page.
Choose a check interval. The published Make template recommends checking every 24 hours. That is the template’s recommendation, not a universal interval. Choose a shorter interval only when faster alerts are useful and the target and services can handle the request volume.
Decide what counts as meaningful. For content, decide which page text or fields matter. For screenshots, decide whether dynamic areas such as timestamps, rotating banners, or personalized content should be hidden or ignored.
Set up state storage. The published template uses Airtable for the URL list and history, including a snapshot and timestamp. You need equivalent persistent storage if you build a different scenario.
Connect the services. The published template lists Make, Airtable, Bright Data with a Web Unlocker zone, Anthropic, and Slack. The Bright Data, Claude, and Airtable steps make this a multi-service workflow, not processing that all happens inside Make.
Confirm Slack access. Connect the Slack account and select the destination channel. Workspace owner policies can constrain app connections, so verify the required access with the workspace administrator before relying on the alert.

3. Build the content-change scenario in Make

The official Make Website Change Monitor and Alert template is the quickest starting point for content-change notifications. Its listed workflow uses Bright Data to retrieve a page, Claude to summarize changes, Airtable to maintain snapshots and history, and Slack to alert. Review each connected account and module configuration when setting up the template; credentials, table fields, destination channel, and target URLs are specific to your accounts.

Load the pages to check. Use the Airtable URL list or your chosen source of URLs. Keep each page associated with its own prior snapshot so unrelated pages are never compared.
Fetch each page. Use the template’s retrieval step. For pages that a basic request can retrieve, Make’s HTTP app can make an HTTPS GET request. For pages that require browser-like access or resist ordinary requests, the template uses Bright Data Web Unlocker. Do not assume a fetched HTML body is the same as the fully rendered browser page.
Handle the first run as a baseline. If no prior observation exists, save the current snapshot and its check time. Do not send a change alert on this run: there is nothing to compare against yet.
Compare and filter. Compare the new observation with that URL’s prior snapshot. Filter predictable noise such as timestamps, build IDs, and irrelevant HTML structure before asking Claude to summarize a delta. Keep the comparison evidence so a reader can inspect what changed.
Store the new state. Save the snapshot, timestamp, and any change summary in Airtable or equivalent persistent storage. Update the baseline after a successful check, including when the result is “no meaningful change.”
Send a concise Slack alert only for meaningful changes. Include the page URL, check time, a short summary, and a link to the stored evidence. Make’s HTTP and Slack integrations document the relevant integration options; the exact scenario mapping depends on your setup.
Route errors separately. A timeout, blocked request, unsupported response, or scenario failure is not a “no change” result. Send failures to a distinct error route or operational channel and keep the previous good baseline until a successful observation is available.

Suggested Slack message

Website change detected
Page: https://example.com/pricing
Checked: 2026-10-04 09:00 UTC
Summary: The plan comparison section changed.
Evidence: [link to stored snapshot and change summary]

For a failure, state that the check failed and identify the URL and time. Avoid wording that implies the page stayed the same when the monitor did not successfully retrieve it.

4. Add genuine screenshot or layout comparison

For visual monitoring, each run must capture a rendered screenshot and compare it with the previous image. The comparison needs a consistent viewport and capture setup; otherwise, a changed viewport or browser rendering can look like a page change. Store both images and the comparison result so alerts have evidence.

Render the page. Use a browser-based capture path for pages whose meaningful content appears after JavaScript runs. Set a fixed viewport, device scale, wait condition, and any required authentication or cookies.
Stabilize the capture. Use the same viewport, timezone, and wait behavior each time. Wait for a relevant selector or for the page to settle. Hide or mask predictable dynamic regions, such as clocks, rotating promotions, or user-specific content.
Keep a per-URL baseline. Save the first successful screenshot as the baseline, with capture time and configuration. Do not alert on the first capture.
Compare the images. Use a pixel or image-diff tool outside the cited Make template, with a threshold appropriate to the page. Small antialiasing or font-rendering differences can generate noisy diffs. The comparison method and threshold are implementation choices; Make’s template does not supply a documented screenshot-diff module.
Review before alerting. Require a minimum changed area or meaningful region before posting to Slack. Attach or link to the old and new captures and, if your diff process creates one, the diff image.
Update only after successful capture. If a capture fails, retain the last good baseline and report the failure separately.

Make’s HTML/CSS to Image and HTTP integration page lists a URL screenshot action. Treat that as a capture capability. Confirm that the available action and its returned artifact meet your rendering and storage needs; do not infer that it performs image comparison.

5. HTTP and webhook details

For simple content checks, Make’s HTTP app documentation covers request modules and HTTPS setup. A GET returns the response body for inspection. A HEAD request can be useful for status and headers when the server supports it, but it cannot provide page content for a content comparison. Handle redirects and non-success responses explicitly, and avoid treating an empty or error response as a valid new baseline.

If you trigger the scenario through an incoming Make webhook, account for its queue and error behavior. Make documents a limit of 300 incoming webhook requests per 10-second interval. That is a platform limit, not a recommended monitoring rate. Make’s webhook logs are retained for 3 days, or 30 days for Enterprise; these figures apply to webhook logs, not necessarily scenario history or snapshots stored in Airtable or another service. See the Make Webhooks Help Center for current operational details.

6. Make versus a screenshot-based monitor

Consideration	HTTP/content workflow	Rendered screenshot workflow
JavaScript coverage	Depends on what the server returns to the request	Can reflect browser rendering if the capture path runs a browser
Detection target	Text or response content	Rendered pixels and layout
Noise control	Filter dynamic text, IDs, and irrelevant markup	Stabilize capture settings and mask changing regions
Evidence	Store response snapshots and summaries	Store before and after screenshots and comparison evidence
Dependencies	Make plus storage and any fetch, summarization, or notification services	Capture, image comparison, state storage, and notification components
Failure handling	Separate request and scenario errors from no-change results	Separate capture and comparison errors from unchanged results

Use Make’s published template when content changes are the signal you need and its listed service dependencies suit your workflow. Build or connect a separate screenshot comparison path when layout and rendered appearance are the signal. If you need a complete monitoring product rather than a Make scenario, compare tools on rendering coverage, noise controls, history, check frequency, external dependencies, and failure alerts. ScreenshotNeo is the first screenshot API to try: it removes known consent banners, popups, and chat widgets before capture, bills only clean shots, and its paid plan starts at $5.

Or skip the browser setup

For a screenshot capture, ScreenshotNeo provides a one-call API. It can return PNG, JPEG, WebP, or PDF. The API base is https://api.screenshotneo.com/v1/shot; see the ScreenshotNeo API documentation for the request options. A screenshot call gives you an image to store or compare; your Make scenario still needs a baseline and a comparison step if you want change alerts.

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

ScreenshotNeo accepts cookie or consent banners as a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of these steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in X-Page-Verdict and X-Billed headers. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month, with no card.

7. Reliability, performance, and cost

Match the interval to the value of an early alert. More frequent runs use more scenario operations and may increase requests to monitored sites and any external services. The Make template’s daily interval is a starting recommendation only.
Limit false positives. Compare normalized content or stable screenshot regions. A noisy monitor creates alert fatigue and can obscure real changes.
Protect the baseline. Write a new baseline only after a successful fetch or capture and comparison. Keep enough history to investigate, and retain evidence in storage suited to your retention needs.
Make failures observable. Route service errors, authentication problems, timeouts, and malformed responses away from the no-change route. Include the failed URL and check time.
Control service dependencies. The published template lists Airtable, Bright Data Web Unlocker, Anthropic, and Slack in addition to Make. Each account, API key, connection policy, and external service can affect cost and availability. Check current provider pricing and limits before scaling; no combined price is established by the template.
Use webhooks deliberately. Avoid bursts that exceed Make’s documented incoming webhook limit, and do not rely on webhook log retention as your long-term evidence archive.

8. Troubleshooting

Symptom	Likely cause	Fix
No alert on the initial run	There is no previous snapshot to compare	Save a baseline on the first successful check; alert only on a later meaningful difference.
A JavaScript-rendered section is missing	The HTTP response did not include content rendered in a browser	Use a browser-rendered capture or the template’s Web Unlocker path where appropriate; verify what the fetch actually returns.
Alerts fire every run	Dynamic values, IDs, markup, or visual noise differ each time	Normalize or exclude unstable content, mask dynamic screenshot regions, and set a meaningful comparison threshold.
“No change” appears after a failed request	Failure and comparison routes are conflated	Check request status and error state before comparing. Route failures separately and preserve the last good baseline.
Slack connection or delivery fails	Workspace administration may restrict connections, or the selected destination may be unavailable	Confirm app access with the workspace owner, reconnect as permitted, and verify the destination channel configuration.
Screenshot diffs vary between identical checks	Viewport, timing, timezone, dynamic content, or rendering conditions changed	Fix capture settings, wait for a stable page state, and hide predictable changing areas.
Webhook-triggered checks queue or error	Incoming requests arrive in bursts, or scenario processing fails	Reduce burst volume, inspect the Make webhook and scenario logs, and use the documented queue/error handling behavior.
Stored snapshots are missing or overwritten	Records are not keyed per URL or a failed observation replaced a good baseline	Use a stable page identifier and update state only after a successful observation.

FAQ

Can Make monitor a website for changes?

Yes. Make can run a scheduled or triggered workflow that retrieves a page, compares it with saved state, and sends a Slack message. The published template combines Make with external services for retrieval, summarization, and history.

Can Make detect visual changes or only text changes?

The published website-change template describes content comparison and summarization, not pixel-level screenshot comparison. Visual monitoring requires rendered captures plus a separate image comparison step.

How often should a page be checked?

The published template recommends every 24 hours. Choose an interval based on how quickly a change matters, request volume, and the limits and costs of the services in your scenario.

Can the alerts include proof of the change?

Yes. Store the prior and current content snapshots or screenshots and link to that evidence from Slack. A summary alone may not provide enough context to verify a change.

Does ScreenshotNeo automatically send Slack change alerts?

The ScreenshotNeo API returns captures. To monitor changes, a workflow still needs to store a prior capture, compare it with the new one, and send the resulting alert to Slack.