AIWebSignals Access Watch
Know when AI access to your important pages changes.
Choose what matters. See which observed changes need attention, give your team a practical next step, and verify recovery with new evidence. The recurring value is a decision and a resolution—not another score.
Access Watch works with your connected request evidence. In-app briefs are available; external delivery uses a signed HTTPS webhook that you must configure and verify. Email and push notifications are not included.
Illustrative alert · not a customer incident
AI search requests to your pricing page are now being denied
- Why it matters
- Your team marked /pricing as important and chose to allow AI search. The illustrated recent requests received 403 responses instead of content.
- Next action · Web team
- Review access rules and the origin response. A root cause has not been established.
- How resolution is verified
- After an authorized change, verify new non-test responses. A clicked confirmation is not resolution.
Open the supporting evidence model
An actual issue includes a bounded current window, comparison baseline, selected access goal, request counts, response statuses and observation limits. A candidate must persist with new non-test evidence before an alert is opened. This illustration does not fabricate those measurements.
No lost revenue, rankings, citations or root cause is asserted.
Watch the right pages
Select up to ten important paths or path groups per connected site. Tell us which AI uses you want to allow, restrict or simply observe. A deliberate restriction is not automatically an issue.
Receive a useful next step
Persistent response changes become prioritized issues with an affected surface, responsible team and verification instructions. Missing data stays a coverage concern, not a green status.
Verify what was resolved
Acknowledging an issue or recording a change does not resolve it. New, matching non-test requests after the change must support recovery.
Know what needs a decision
Open your decision brief for current issues, resolved work and coverage. Opt into a weekly brief to your verified webhook. Quiet and insufficient-evidence states are distinct.
First value, without guessing
Connect a supported source, choose your important surfaces, and review the initial brief. It shows what we can observe, which goals need investigation and what still needs a baseline. Low-volume sites may need time to collect enough evidence; we do not create traffic to make a report look busy.
Available to active Pro and Business workspaces using their existing connected-site limits. Prices are unchanged. A mostly static, low-activity site may only need the free check or an occasional review.
One verified notification channel
Your receiver verifies an HMAC signature and acknowledges each delivery. A connection test sends no customer evidence. Until it is acknowledged, external notifications stay off. Unknown delivery outcomes are held for review instead of silently resent.
The same verified receiver can accept access-change alerts, verified-resolution messages and an optional weekly decision brief. Acknowledgement confirms receipt by the endpoint—not that a person read it.
Download the Node.js receiver example. Run behind an HTTPS reverse proxy on infrastructure you control; it needs a signing secret shown once during setup. Plain email, Slack and Teams endpoints do not implement this contract by themselves.
Evidence boundaries remain visible
The first version analyzes connected, classified AI GET requests. Client labels are not cryptographic identity. We detect response-goal mismatches and changes, not page-content correctness, AI rankings, private model intent or lost revenue. Collection has a bounded window and source-specific coverage. Successful transport does not establish useful human or agent outcomes.
Why request totals and analytics differ · Privacy and retention · Ask about fit