My blog about web-dev work

[snapshotarchive]

The spreadsheet that nobody updated

A QA lead I worked with kept a Google Sheet called "Weekly Site Check." Every Monday she'd open 30 pages, take manual screenshots, and paste them into rows. Compare this week to last week. Note anything different.

Took her about two hours. She did it for eighteen months straight.

Then she went on vacation for three weeks, nobody picked it up, and a pricing page redesign went live with the wrong tier names. Support tickets rolled in for six days before anyone connected the dots.

Manual checks fail at the worst time

Not because people are lazy. They fail because humans are inconsistent. You notice the big stuff — a page that's completely broken, a missing hero image, a layout that's clearly off. But small changes? A phone number that changed. A disclaimer paragraph that got removed. A button that shifted from "Start free trial" to "Contact sales."

Your brain filters those out. Especially on Monday morning when you're checking 30 pages and you've seen them all a hundred times.

Pixel-level comparison catches what you won't

Automated visual monitoring takes a screenshot on a schedule and overlays it against the previous capture. If anything moved — even a single pixel — it gets flagged. No judgment calls, no "I think this might be different," no fatigue after page 12.

We switched a client's monitoring workflow to track website changes automatically last year. Within the first week it caught a footer link that someone had accidentally deleted during a CMS update. Nobody would have noticed that manually. The link pointed to their terms of service — kind of important.

What automated monitoring actually gives you

A timestamped archive you can scroll through — see exactly how any page looked on any date

Diff overlays that highlight changes in red so you don't have to squint

Alerts on your schedule — hourly, daily, weekly, whatever makes sense

Evidence for compliance teams who ask "when did this change?" six months later

Still worth doing manual checks?

Honestly, for some things, yes. Automated tools can't tell you if copy sounds weird or if a design choice looks bad. That's still human territory. But catching whether something changed? Automation wins every time. Let the tool handle detection, save your energy for decisions that need a brain.

[snapshotarchive]

Staging looked perfect. Every page matched the design. QA gave a thumbs up. You deployed on Thursday afternoon because you were feeling confident.

By Monday morning, support tickets started coming in. The hero section was overlapping the nav on Safari. A third-party review widget had doubled in size. The pricing table's decimal alignment was off by one pixel on screens wider than 1440px.

None of this showed up in staging.

Staging isn't production. It never was.

Real talk — staging environments don't load the same third-party scripts. They don't get the same traffic patterns. They run behind VPNs with cached assets that haven't been purged in weeks. Half the time your staging database has test data that doesn't trigger the same edge cases.

So when someone says "it worked in staging," that means almost nothing about what's actually happening on your live site right now.

I'm not saying staging is useless. But trusting it as your single source of truth for visual correctness? That's how things slip through.

The gap nobody talks about

Between "deploy to production" and "customer complaint," there's a window. Could be hours, could be days. Most teams have zero visibility into what their site actually looks like during that window.

You deployed. CI passed. Monitoring says the site is up and returning 200s. Cool. But is the page actually rendering correctly? Is the layout intact? Did that new CSS rule accidentally break something three pages deep that nobody checks manually?

Usually you find out when someone screenshots the bug and drops it in Slack. By then who knows how long it's been broken.

What closes the gap

Automated visual monitoring on production. Take screenshots of your key pages on a schedule — every few hours, daily, whatever makes sense. Compare them over time. When something shifts, you see it before your users bother reporting it.

We started doing this after a particularly embarrassing incident where a payment form was half-hidden behind a cookie banner for three days. Three days. On the page that literally makes us money.

After trying a couple of approaches (Puppeteer scripts that kept breaking, a free tier monitoring tool that only checked uptime), we landed on SnapshotArchive for the screenshot archiving side. It runs scheduled captures and keeps a timeline you can scrub through, which made it way easier to pinpoint when something changed vs. just knowing that it changed.

Not saying it's the only option — there are a few tools in this space. Point is, you need something watching production visually. Uptime checks and synthetic tests don't catch layout regressions. Screenshots do.

The minimum viable setup

If you're starting from scratch:

Pick your 10-15 most important pages. Homepage, pricing, signup, checkout, main landing pages.

Set up daily full-page captures in production.

Review diffs once a day. Takes five minutes when nothing changed, saves you hours when something did.

That's it. You don't need pixel-perfect diffing algorithms or AI-powered anomaly detection (though those exist). You need a timestamped visual record of what your live site looks like, independent of your deploy pipeline.

Staging will keep lying to you. At least now you'll catch it.

[snapshotarchive]

Your Competitors Redesigned Their Pricing Page Last Week

Did you notice? Probably not. Most companies track competitor pricing manually — someone opens a spreadsheet once a month and jots down numbers. By the time they check, the change happened weeks ago and whatever campaign it was tied to is already running.

I started screenshotting competitor pages on a schedule after missing a pricing change that undercut us by 40%. Our sales team found out from a prospect who asked why we were so much more expensive. Embarrassing doesn't begin to cover it.

What changes matter

Not every update is worth tracking. A blog post or a footer tweak — whatever. But these are worth watching daily:

Pricing and plan structures

Feature comparison tables

Homepage messaging and positioning

Job postings (tells you where they're investing)

The job postings one surprised me. When a competitor starts hiring for enterprise sales, you know where their roadmap is heading before they announce anything.

Screenshots beat bookmarks

Bookmarking pages and checking them manually is a commitment nobody maintains past week two. Automated screenshots with visual diffing catch changes you'd miss — font color updates, removed features from comparison tables, subtle wording shifts in legal pages.

Had a case where a competitor quietly dropped their free tier. No announcement, just gone from the pricing page one Tuesday. We adjusted our marketing to highlight our free plan that same week. Wouldn't have caught it otherwise.

[snapshotarchive]

5 posts!

[snapshotarchive]

Had a SaaS product update their ToS last quarter — added a clause about data residency that affected how we stored user files. We only found out because a customer flagged it during their compliance review.

That was embarrassing.

Turns out, most SaaS vendors update their terms 2-4 times a year. Some do it more often. They don't always send emails about it. Sometimes the changes are minor wording tweaks, sometimes they shift liability or change data processing terms entirely.

If you work in fintech, healthcare, or anything with audit requirements, this stuff matters. Your legal team probably wants to know when a vendor quietly changes their privacy policy, but nobody's actually watching those pages.

What I started doing: scheduled screenshots of key vendor ToS and privacy pages, compared weekly. Not automated legal analysis — just a visual diff that shows "hey, paragraph 3 changed" so someone can go read it.

Caught two meaningful changes in the first month. One was a data retention policy update from a payment processor. The other was a subprocessor list change from our email provider.

It's boring work to do manually. But missing a compliance-relevant change is worse.

[snapshotarchive]

Ran into something annoying last month. A client's checkout page looked fine in staging, passed every test. Went live, and the embedded payment form shifted 40px down because the provider updated their iframe height.

Nobody caught it for three days.

The thing is — you can't write unit tests for stuff you don't control. Third-party widgets, embedded forms, cookie banners from external scripts. They change whenever the vendor feels like it, and your CI pipeline won't notice.

What actually works is visual monitoring. Set up scheduled captures, compare them, flag differences above a certain threshold. Not pixel-perfect diffing on every element — that gets noisy fast. More like "hey, this section moved or disappeared, go look at it."

I've been using SnapshotArchive for this on a couple of projects. Captures pages on a schedule, shows side-by-side diffs. Caught a footer link swap on a partner site that would've gone unnoticed for weeks otherwise.

Most teams only check their own deploys. But half the visual bugs I've seen in the past year came from things outside our codebase entirely.

[snapshotarchive]

Pixel-Level Paranoia (In a Good Way)

Someone on the team updated a shared CSS file and the footer on your pricing page lost its background color. The functional tests? All green. The page loads, the links work, everything's technically fine. It just looks wrong. For three days.

Visual diffing is the thing that catches these invisible-to-automated-tests problems.

The Basics

You take a screenshot of a page. That's your baseline. Later — could be hours, days, after a deploy — you take another screenshot of the same page. Then you compare the two images algorithmically and get back a diff showing exactly what changed visually.

Simple concept. The details are where it gets interesting.

How the Comparison Works

Three main approaches exist, and they're not interchangeable.

Pixel comparison literally checks every coordinate — does pixel (234, 891) in screenshot A match screenshot B? It's fast and easy to implement, but it flags rendering differences that are completely invisible to the human eye. Font smoothing variations between captures, sub-pixel shifts from anti-aliasing — all noise, all flagged. SSIM (Structural Similarity Index) is better for most real-world use. It looks at luminance, contrast, and patterns in image regions, which maps closer to how we actually perceive visual changes. A page that looks the same to you will probably score near 1.0 on SSIM even if a few individual pixels differ.

Then there's perceptual hashing — good for catching big layout shifts, not great for subtle stuff like a 3px padding change.

Real Use Cases Beyond "Did the Deploy Break Something"

Yeah, regression testing is the classic. But here's what I've actually seen teams use visual diffing for:

Catching when a third-party ad script injects unexpected elements into the page layout

Verifying that all 30+ localized versions of a landing page match the approved design

Monitoring competitor pricing pages weekly for changes

Making sure legally required elements (cookie banners, disclaimers) don't vanish after CMS updates

The legal compliance one is probably the most underrated. A cookie consent banner silently disappearing can mean actual fines in some jurisdictions. Automated visual checks make that risk basically zero.

Why Most Setups Fail (and It's Not the Tool's Fault)

Alert fatigue. Every time.

Teams spin up visual diffing, point it at 150 pages, use default settings, and immediately get flooded with alerts. Rotating hero images, live visitor counters, dynamic timestamps — all triggering diffs. Within a week the alerts get muted. Within a month the whole thing's abandoned.

Ran into this myself. The solution was honestly pretty boring — just better configuration. Define ignore regions for content that's supposed to change. Set different thresholds per page (your blog index changes daily, your terms of service shouldn't change at all). Pin the browser version and viewport dimensions so you're not diffing rendering engine differences. Wait for async content before capturing.

After that tuning? The noise dropped dramatically. The remaining alerts were almost always legitimate issues.

Quick Setup Advice

Start small. Your top 5-10 most important pages with sensible thresholds. Update baselines deliberately after every approved change. Run diffs on a schedule that matches your deploy frequency — hourly if you ship constantly, daily if you don't.

Don't compare across browsers unless you have separate baseline sets per browser. Chrome and Firefox render things differently enough that cross-browser pixel comparison is mostly meaningless noise.

[snapshotarchive]

Last year, a mid-size SaaS company changed their pricing without announcement. Existing customers only noticed weeks later when their renewal quotes came in higher. By then, the old pricing page was gone from Google's cache too.

This happens constantly. Web content changes and nobody keeps a record.

Why should you care

If you work in any of these areas, web archiving is not optional:

Competitive analysis. You cannot track trends if you only see the current state. Competitors adjust positioning, features, and pricing over time. Without captures from three months ago, you have no baseline to compare against.

Compliance and legal. "But the website said X" is not a defense if you cannot produce the page. Timestamped screenshots and HTML captures serve as evidence. Plain text quotes do not.

Your own site QA. Deployments introduce visual bugs that automated tests miss. A banner shifts, a CTA disappears, text overlaps on mobile. Having a visual history of your own pages lets you spot regressions quickly.

Why not just use the Wayback Machine?

The Internet Archive does incredible work, but it was built as a public library, not a monitoring tool. You cannot choose which pages it captures or when. Coverage varies wildly. Some pages get crawled every week, others go untouched for years.

For professional use, you need control: pick the pages, set the frequency, get alerts when content changes.

A simple archiving setup

List the URLs you want to monitor (competitors, your own pages, regulatory pages, key references)

Capture them on a schedule — daily for fast-moving content, weekly for stable pages

Store HTML and full-page screenshots side by side

Set up change detection so you only review captures that differ from the previous version

The whole point is not to build a complete mirror of the internet. It is to make sure the specific pages you rely on are preserved before they change or disappear. That narrow focus is what makes it practical instead of overwhelming.

[snapshotarchive]

I work on tools that track how websites change over time. Screenshots, visual diffs, page archives — that kind of thing.

This blog is where I'll share what I learn along the way. Some of it will be about web monitoring specifically — how to catch visual regressions, why pages break silently, what compliance teams actually need from screenshot archives.

Some of it will be broader. Thoughts on building software as a small team, tools I find useful, problems I run into and how I solve them.

No posting schedule, no content calendar. Just notes when I have something worth writing down.