Change detection

Numative keeps a timeline of every change on your site so traffic movement can be attributed to something concrete: an edited title, a republished post, a new backlink, a Google update. Three detection layers feed that timeline. The first two need no setup beyond the tracking snippet; the third catches everything the first two miss.

Layer 1: the snippet fingerprint

Once per path per session, the tracking snippet computes a tiny fingerprint of the page's own content: the title, the meta description, the first H1, and the body text length bucketed to the nearest 200 characters, hashed with FNV-1a. It is sent to /api/page-signal during browser idle time, so it never competes with your page, and it is not billed as an analytics event.

The server compares the fingerprint to the last one it saw for that path. A mismatch means the page changed since the last crawl, and a targeted recrawl of just that page is queued immediately. The result: any edit to a page that gets traffic is detected on the first visit after it ships, on any platform, with no webhooks or plugins.

• A path Numative has never tracked that receives real traffic is probed; it only becomes a tracked page when it responds with a status below 400, so 404s stay out.
• A 15-minute cooldown after each snapshot and a cap of 30 triggered snapshots per site per hour keep per-visitor dynamic content (greetings, related-post widgets) from causing churn.
• The fingerprint contains no visitor data. See Privacy & data.

Layer 2: exact-time pings

When your CMS or deploy pipeline tells Numative the moment something was published, the change lands on the timeline with an exact timestamp instead of a detection time.

WordPress

The Numative Analytics plugin pings on publish, update, and unpublish with one checkbox. Nothing else to configure.

Any other stack

Call POST /api/v1/ping from a publish or deploy hook with a write-scoped API key (created under Account > API). The body is a single absolute url; its hostname must belong to one of your organization's sites (the site's domain, a subdomain of it, or a configured allowed host). The endpoint is limited to 60 requests per minute per key.

curl -X POST "https://app.numative.com/api/v1/ping" \
  -H "Authorization: Bearer nmv_live_..." \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/blog/new-post"}'

# 200 OK
# {"accepted": true, "path": "/blog/new-post"}

Layer 3: sitemap polling and the sampling crawl

• Hourly sitemap delta polling. Every hour, each site's sitemap files are conditionally fetched and hashed; only files that changed are parsed. New URLs get a launch date (first seen), removed URLs are recorded, and this stays cheap at any site size.
• Twice-daily sampling crawl. A scheduled crawl spends a per-plan page budget (from 500 pages per cycle on the smallest plan up to 20,000 on the largest, scaling with the plan size picked on the pricing slider) on top-traffic pages, per-template samples, and a rotating long-tail cursor, so even very large sites get structural coverage over time. It also monitors robots.txt and flags changed Disallow rules.

This layer catches what traffic-driven detection cannot: zero-traffic pages, template-level changes, and removals.

Blocked crawlers

Our crawler identifies itself on every request with this user agent:

NumativeBot/0.1 (+https://numative.com/bot)

If a CDN or firewall answers it with a challenge or a block page, no snapshot can be taken and no content change is detected. That failure is invisible from the dashboard on its own, because a site whose changes cannot be read looks the same as a site that has not changed, so Numative watches for it: a crawl now probes the homepage before spending any budget, stops the run on a refusal instead of working through thousands of pages that will all be refused, and shows a warning on the site once two crawls in a row have been turned away. Refused crawls are not counted against your plan's page budget.

To allow the crawler through Cloudflare, add a WAF custom rule matching User Agent contains "NumativeBot" with the action Skip, skipping Bot Fight Mode and managed rules. Under Super Bot Fight Mode, "Definitely automated" also has to allow verified crawlers. On other firewalls, allow requests whose User-Agent contains NumativeBot. The warning clears itself on the first crawl that gets through.

What gets snapshotted and diffed

Each crawl extracts a snapshot and diffs it against the previous one. Content measurements use the page's main content only: navigation, headers, footers, sidebars, comment sections, related-post widgets, carousels and other link-heavy boilerplate are stripped before anything is measured. Content changes are then judged by similarity, not by exact comparison, so a recommendation widget rotating a few words on every load never registers as a content change, while a real edit does.

A change record describes exactly what moved:

Alongside page diffs, the crawler fingerprints the site's technology: the platform (WordPress, Shopify, Next.js, Wix, Squarespace, Webflow, Ghost), the generator meta tag, and server headers. When the signature changes, a site-level change is recorded, so a migration or replatform shows up on the timeline too.

Chart flags

Detected changes and related events are overlaid on the traffic chart as numbered flags, each group in its own color with its own toggle. Clicking one opens the record behind it.

Annotations are the manual layer: mark a deploy, a campaign, an email send, a content push, or a plain note from the chart itself, or create them from CI with POST /api/v1/annotations (see the Stats API).

Seeing what actually changed

A change record does not just say a page was edited. Opening a page change shows the stored before and after: the old and new title or meta description, and for a content edit a word-level diff of the page's main text, computed on demand from the two crawls either side of it. Additions and removals are marked in place, so "content updated" becomes the sentence that was rewritten.

It is available from the flag on the chart, from the Changes section, from each page's own change history, and over the API at GET /api/v1/changes/diff. Diffs need both crawls to have stored their text, so changes detected before this feature shipped show their from/to values without the full diff.

The Changes section

Everything above, as a searchable feed rather than as flags: every detected page and site change plus your own annotations, newest first, filterable by category and type, with a daily activity strip you can click to jump to a day. It is the view for "what have we been doing to this site" as opposed to "what happened on the 14th".

The spike hunter

Every 3 hours, Numative looks for referral spikes and tries to find the exact page that sent the traffic. A referrer domain counts as a spike when its last-24-hour visits clear an absolute floor (50 visits by default) and reach at least 3 times its trailing 14-day daily average; a domain never seen before spikes on the floor alone. Search engines are excluded, since organic traffic grows gradually rather than in attributable bursts.

For each spike, the hunter first checks stored full referrer URLs (many platforms send the exact page). If the referrer was stripped to its origin, it searches Hacker News, Reddit, YouTube, Google, and X for the thread, video, or post that matches the timing and landing pages. A found source is pinned to the chart as a rose marker with a link to the exact page. At most 5 new spikes are hunted per site per run.

Social mentions

A spike is not the only way a mention matters. Whenever a site has received any referral traffic from a social platform recently, Numative searches that platform for posts linking your domain, so a thread that sent a trickle is still found and flagged, where the spike hunter above would never have noticed it. Hacker News, Reddit, YouTube, X and Bluesky are covered, plus a domain-scoped web search for anything else.

• Each platform is checked at most once a day per site, and each distinct post is flagged once no matter how long its link keeps sending traffic.
• Posts older than 30 days are not backfilled, so a check finds what is happening now rather than replaying a year of history.
• The flag renders the post itself - the tweet, the comment, the video - with its author and engagement, so you can read it without leaving the chart.

Google algorithm updates

Numative ships a hand-maintained, append-only list of Google ranking updates confirmed on the Google Search Status Dashboard, covering core, spam, helpful content, and reviews updates from January 2023 onward. They appear as violet markers on every site's chart, so a traffic shift that coincides with an update is not misattributed to your own changes.