What we watch
A company's own website, all of it: the pages found from its sitemaps, its links and its hub pages, including investor-relations pages, PDFs and pages that need a real browser to render.
The live dashboard needs JavaScript.
Illustrative example changes. Not real company disclosures.
How it works
What it watches, what you get, and one example page from the check to the record.
A company's own website, all of it: the pages found from its sitemaps, its links and its hub pages, including investor-relations pages, PDFs and pages that need a real browser to render.
A record of each real change: which company, which page, what kind of change, and the wording before and after. Byte-level churn and failed page loads are kept apart from real change.
example.com/products/sensors/s2
BeforeThe S2 ships in three sizes and fits existing mounts.
AfterThe S2 ships in four sizes and fits existing and older mounts.
Product · Specification · rule R2
Every step runs on fixed rules you can read, with no AI.
Respectful by design. Public pages only. Paced to each site, in a compliant manner.
Map the whole site. Every page, found once.
See itWatch every page. As often as its site allows.
See itDetect what changed. Noise out, then word by word.
See itLabel it by fixed rules. First match wins. No AI.
See itDeliver a record you can check. Straight into your feed.
See itWe start from the company's own domain and list every page on it. Sitemaps give the pages the site declares; internal links find the ones the sitemaps leave out; hub pages such as news archives, document lists and job boards are walked page by page. Each address is reduced to one canonical URL, so tracking parameters, redirects and duplicate paths count once. The map is rebuilt continuously, PDFs and pages that need a real browser included.
| Section | Sitemaps | + Links | + Hubs | Unique |
|---|---|---|---|---|
| Investor relations | 30 | 8 | 34 | 67 |
| Newsroom | 42 | 6 | 71 | 110 |
| Careers | 10 | 5 | 26 | 37 |
| Products | 56 | 14 | 6 | 69 |
| About and leadership | 13 | 4 | 2 | 18 |
| Legal and policies | 8 | 7 | 0 | 13 |
Unique pages are counted after duplicates (tracking parameters, redirects, alternate paths) are merged into one canonical URL.
Each page keeps its own schedule. Pages that change often, such as a newsroom index, are revisited sooner; quiet ones, such as a policy page, less often; and the whole site is paced to what it can comfortably serve. Most visits end early: the page is normalised and fingerprinted, and when the fingerprint matches the stored one, it is logged as checked and nothing more is done.
Every check fetches the page, normalises it, fingerprints it and compares the fingerprint with the stored one. When they match, the page is logged as checked and skipped, which is the outcome of most checks. When they differ, the full word-level compare in step 03 runs; only some of those are real changes, the rest is noise.
When the fingerprint differs, the new version is compared with the stored one. Known noise goes first: dates and times, counters, session tokens and other values that change on every load, each removed by a written pattern. What remains is compared word by word, and the change is isolated with enough surrounding text to read it in context. Both versions are kept, and failed page loads are kept apart from real change.
Stored 09:12 and new 14:01, after noise is removed:
The S2 sensor ships in three four sizes and fits existing and older mounts.
Ignored as noise: the "Updated" date and time, the customer counter and the session token in a help link.
Each change passes an ordered set of rules that look at the page type, the kind of block that changed and patterns in the words. The first rule that matches sets the category, the page type and a significance level. There is no AI and no model: the same change always gets the same label, and every label points back to the rule that produced it.
| Rule | When | Label |
|---|---|---|
| R1 | Investor relations page and a document link is added | Investor relations, document added, high |
| R2 | Product page and a quantity or specification changes | Product, specification, medium |
| R3 | Careers page and a listing row is added | Jobs/Hiring, new listing, low |
| R4 | Legal page and a sentence is reworded | Site & legal, policy wording, medium |
| R5 | Newsroom page and an article is added to the list | Newsroom, new article, medium |
| R9 | Anything else | Site & legal, other change, low |
The result is a timestamped change record: company, page, label, the wording before and after, and links to the live page and to both stored versions. It lands in your watchlist feed straight away, and can also arrive as an alert or through the API. Timing starts at the check that found the change, so how soon a change is seen depends on step 02.
14:01 Example company, example.com/products/sensors/s2
The S2 sensor ships in three four sizes and fits existing and older mounts.
Product, specification, medium (rule R2). Stored versions 09:12 and 14:01.
Why it matters
Product pages, job listings and policies change all the time, and almost none of it is announced. Undercurrent picks up each change when the check finds it.
Nobody will tell you a page changed, so you would have to look yourself. Follow a company's whole website instead: one feed replaces revisiting pages and comparing them from memory.
Each change comes with the wording before and after, both stored versions and the fixed rule that labelled it. No AI summaries, nothing to take on trust.
Contact
We are still in pre-alpha.