Website Sales Trigger Radar

Monitor business websites for changes that can affect customer enquiries, bookings, and sales. The Actor compares each website with a saved baseline and exports structured triggers with evidence, verification status, and a suggested human check.

Use it for agency client monitoring, account research, and evidence-based sales follow-up. A trigger is an observation to investigate; it is not proof of lost revenue or purchase intent.

What it monitors

• Booking and conversion links: added, removed, changed, broken, or recovered.
• Public contact details: phone numbers, email addresses, and contact-page changes.
• Website availability and recovery.
• Changes in detected booking, chat, ecommerce, and CMS technologies.
• Major homepage content changes.

The crawler uses HTTP checks with a bounded browser fallback. It can recognize links to external booking providers, but it does not complete bookings, submit forms, make purchases, log in, or solve CAPTCHAs.

Quick start

1. Enter your website domains or URLs.
2. Set a memorable historyKey for this portfolio.
3. Run with baselineMode: "AUTO" and saveHistory: true.
4. Run again with the same websites and history key to compare.
5. Save a Task and attach an Apify schedule for ongoing monitoring.

The first run creates a baseline and normally produces zero dataset items. An unchanged repeat run can also produce zero items. Open Output → Coverage, baseline and diagnostics to see which websites were checked and whether any checks were inconclusive.

An initial automation block or inconclusive proxy failure does not create a baseline. Retry with AUTO: the first usable visit establishes a baseline without inventing website recovery or newly added buttons. Existing healthy baselines are preserved through these inconclusive visits.

{
  "websites": [
    "https://www.rockawaydentalgroup.com/"
  ],
  "historyKey": "my-client-portfolio",
  "baselineMode": "AUTO",
  "saveHistory": true,
  "crawlMode": "CUSTOM_PATHS",
  "customCriticalPaths": ["/appointment-request/", "/contact/"],
  "maxPagesPerWebsite": 3,
  "maxDepth": 1,
  "maxConcurrency": 2,
  "pageTimeoutSecs": 15,
  "checkPerformance": false,
  "minimumSeverity": "LOW",
  "proxyConfiguration": {"useApifyProxy": true}
}

The sample business is a real website used for validation. Replace it with the websites you want to monitor.

Choose a crawl

Mode	Use
HOMEPAGE_ONLY	Small availability and homepage-content checks.
CONVERSION_FOCUSED	Discover relevant booking, contact, and conversion pages within your page/depth limits.
CUSTOM_PATHS	Prioritize known important pages using customCriticalPaths. These pages share the page budget with the homepage.

Start with a small portfolio and 2–5 pages per website. Larger page limits, slow destinations, verification retries, browser fallback, and proxies can increase runtime and cost.

Baselines and repeat monitoring

• AUTO creates a missing baseline and compares when one already exists.
• FORCE_BASELINE refreshes the baseline without emitting change triggers. Use deliberately when resetting your monitor.
• COMPARE_ONLY requires an existing usable baseline; inspect the run diagnostics if one is missing.

Keep the same historyKey for repeat runs. Use different keys for independent portfolios. Keep saveHistory enabled when you want the next run to compare against the latest saved observation.

Baselines persist in a named key-value store in the running account. Blocking and transport uncertainty preserve prior healthy information instead of creating artificial removal/recovery alerts.

Results and coverage

Default dataset: one row per emitted trigger, including:

Field	Meaning
domain, website	Website being monitored.
triggerType, severity	Type of change and its priority.
status, verification	How the finding was checked and how certain it is.
title, summary	Readable description.
before, after, evidence	Supporting observations, where applicable.
salesReason	Possible business relevance; human judgement is required.
recommendedHumanCheck	What to verify before acting on the finding.
isNew, isResolved, occurrenceCount	Issue lifecycle information.

Export the dataset as JSON, CSV, or Excel using Apify's dataset export options. The Sales triggers and verification table presents the key columns.

Output summary: OUTPUT and RUN_SUMMARY records in the run's default key-value store contain processed/failed website counts, baseline counts, request metrics, per-website diagnostics, and warnings.

A platform run marked SUCCEEDED can still have summary status PARTIAL. For example, the homepage and contact page may load while an external booking provider blocks automated verification. Always review coverage, not just the platform run status.

Interpret verification correctly

Status	Interpretation
CONFIRMED	The specific check's evidence/recheck conditions were met.
TARGET_LOADED	The target page loaded. A booking, enquiry, or checkout was not completed.
EXPECTED_FLOW_DETECTED	A form or expected interface was detected. Successful submission was not tested.
OBSERVED_ONLY	A change was observed; investigate its business significance.
INCONCLUSIVE_AUTOMATION_BLOCK	Automation was blocked. This is not a confirmed broken booking or outage.
INCONCLUSIVE	Evidence was insufficient for a confirmed finding.

Proxy/transport failures are also reported as uncertainty rather than proof that a business website is down.

Ready-made monitoring Tasks

Five example configurations are available: booking links and CTAs, contact details, homepage availability/content, external booking providers, and an agency website portfolio. Each uses AUTO baselines, a separate history key, small crawl limits, and performance checks disabled.

These are configuration examples, not scheduled alerts. Change the websites and important paths before using a Task for your own clients. External provider monitoring includes an example that can return an automation block, demonstrating how partial coverage is reported.

Optional performance checks

PageSpeed/Lighthouse comparisons require a PAGESPEED_API_KEY environment variable and checkPerformance: true. Without a configured key, no performance data is invented. These are lab measurements, not field Core Web Vitals; INP is unavailable from the lab response.

Performance checks were not part of the live-site validation described below. Leave them disabled unless you have configured and separately validated the provider.

Validation and limitations

The monitoring implementation was checked on Rockaway Dental Group (New York), Rockaway Beach Dental Group (Pacifica, California), and Arverne Dental (New York), with baseline and repeat comparisons. Unit/integration checks covered verification and change/recovery cases.

On the tested Arverne booking link, Zocdoc returned HTTP 403. The Actor reported an inconclusive automation block and partial coverage, not a broken booking claim. A Neurality booking destination loaded, but a completed booking was not tested.

This is a bounded monitor, not a full-site crawl or end-to-end transaction test. Dynamic content, anti-bot protection, changing layouts, and unsupported technology signatures can reduce coverage. Dedicated pricing-page, service-page, and conversion-section change detection is not currently implemented.

Pricing and automation

The live Pricing tab is the source of truth for current charges. Platform usage, proxy traffic, and any configured event fees can apply even when a run finds no changes.

Scheduling, webhooks, and downstream CRM/notification integrations are configured separately in Apify. The Actor exports observations; it does not send outreach or contact website owners.