Live data from Hacker News

Show HN: I built a tool that watches webpages and exposes changes as RSS

sitespy.app

71–80 of 86 posts

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#72
post #70

[flagged]

The selector is stored as a CSS path and matched against the fetched HTML on each check — so as long as the element's structure and nesting stay roughly the same, minor layout changes don't usually break it. The fragile cases are sites that generate class names on every build (React/webpack/vite apps often do this) — those selectors will just stop working. For semantic elements like price tags, availability text, or…

[flagged]

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#73
post #70

Earlier quoted context omitted.

The selector is stored as a CSS path and matched against the fetched HTML on each check — so as long as the element's structure and nesting stay roughly the same, minor layout changes don't usually break it. The fragile cases are sites that generate class names on every build (React/webpack/vite apps often do this) — those selectors will just stop working. For semantic elements like price tags, availability text, or…

[flagged]

Yeah, semantic anchors are definitely the right direction — [data-testid], aria-label, or text proximity tend to survive rebuilds much better than class paths. The picker leans towards CSS right now but that's something I want to improve.

The harder problem is auth-gated content — Instagram feeds, dashboards, paywalled pages. Browser Steps handles it today (you can script login flows), but honestly I think the real fix is AI-assisted interaction. A small cheap model that can find what you care about without needing a brittle selector at all. That's where I want to take this — less "maintain a CSS path", more "here's what I'm interested in, figure it out...

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#74
post #55
post #31

Earlier quoted context omitted.

Thanks, that’s a really good question. Site Spy uses a real browser flow, so it generally handles JS-rendered pages much better than simple HTML-only polling tools. In practice, the trickier cases tend to be sites with aggressive anti-bot protection or messy login/session flows rather than JS itself. I’m trying to make those limitations clearer so people don’t just hit a vague failure and feel let down

Curious how you're thinking about getting around anti-bot protection. I scrape a lot and I've noticed many highly trafficked sites investing in anti-bot measures recently, with the rise of AI browsers and such. Still, cool idea, congrats on the launch.

I'm planning to add proxy rotation across different regions to help with geo-restricted content and rate limiting. Anti-bot is an arms race though — some sites just can't be monitored without solving a captcha, which isn't something I'm trying to do. Focused on making the common cases work well rather than promising to bypass everything.

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#75
post #73

Earlier quoted context omitted.

[flagged]

Yeah, semantic anchors are definitely the right direction — [data-testid], aria-label, or text proximity tend to survive rebuilds much better than class paths. The picker leans towards CSS right now but that's something I want to improve. The harder problem is auth-gated content — Instagram feeds, dashboards, paywalled pages. Browser Steps handles it today (you can script login flows), but honestly I think the real f…

[flagged]

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#77
post #53

Does anyone here remember WinerWatch ? The tool Mark Pilgrim wrote, that monitored changes to blog posts by (the notoriously trollish) Dave Winer? It caused a big stir in the blogosphere in 2003, and Mark took it down very quickly after public blowback. I always thought it was pretty cool and he should have left it up. One of the very few surviving posts on the matter: https://burningbird.net/forget-the-law-forget-th…

What an interesting glimpse into the blogosphere. That post in particular is interesting, given the much larger discussions that followed it on essentially the same topic: how to decide what people can and can not say when there are those who ruin the commons. I'm thinking of Twitter/X's Community Notes feature and the many reputation mechanisms people put in place, and the subsequent griping of community politics that arise from those mechanisms...

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#78
post #73

Earlier quoted context omitted.

Yeah, semantic anchors are definitely the right direction — [data-testid], aria-label, or text proximity tend to survive rebuilds much better than class paths. The picker leans towards CSS right now but that's something I want to improve. The harder problem is auth-gated content — Instagram feeds, dashboards, paywalled pages. Browser Steps handles it today (you can script login flows), but honestly I think the real f…

[flagged]

Yes! Exactly this direction — the hybrid fetch is already live: plain HTTP first, Chromium if the content looks off. LLM semantic targeting is the next step, but only triggered when a selector breaks, not on every check — too expensive otherwise.

Re: Show HN: I built a tool that watches webpages and exposes changes as RSS

#79
This is directly useful for financial data monitoring. I've been thinking about watching specific elements on energy report pages (EIA weekly inventory releases, OPEC statements) rather than scraping the full page. The element picker + RSS output is exactly the right interface for that — pipe the change event straight into an NLP pipeline without the noise of a full page diff.

The RSS question: yes, RSS is useful precisely because it's composable. It works with anything. Direct alerts are convenient but RSS is infrastructure.

Post reply on HN