The situation. After a major platform migration, a national nonprofit’s site was fielding roughly 800,000 requests per month for pages that no longer existed — two decades of old links, retired documents, dead bookmarks, and search-engine memory, plus automated scrapers probing paths from the old system. Each miss cost 10–14 seconds of server compute to render an error page, and the noise made real problems hard to see.

The investigation. We built a segmented 30-day analysis of every failed request: human, search crawler, or bot, for every path. The findings redirected the whole effort:

• The #1 “broken link” — 20,000+ hits — wasn’t humans at all: a scraper disguised with browser fingerprints, methodically walking thousands of filter combinations of a search page from the old platform, following links that had not existed for months.
• A steady stream of genuinely human traffic was arriving at legacy chapter URLs from old emails, bookmarks, and documents — real people, recoverable.
• The long tail — hundreds of thousands of unique paths — was automated probing that deserved milliseconds of attention, not seconds.

The solution. Three layers, matched to what the data showed: 24 precision redirects carrying ~38,000 monthly hits to the right current pages (the disguised scraper’s entire maze now collapses into a single cheap redirect); edge rules so device probes and known-dead paths are answered before they ever reach a server; and a purpose-built recovery page for genuine misses — loads in milliseconds instead of seconds, detects what the visitor was looking for, and offers a path back to mentors, workshops, and their local chapter, with every miss reported into analytics so the next fix is data-driven, not anecdotal.

Results.

• ~38,000 monthly dead-end hits now land on real pages
• Error-page cost heading from 10–14 seconds to milliseconds — reclaiming meaningful server capacity from traffic that was never going to convert
• Search engines told the truth (404/410) so they stop recrawling retired content
• A repeatable 30-day report the client’s own team uses to measure progress against Search Console

---

Case Study: Faster and Cheaper

Most capacity conversations end with a bigger bill. This one didn’t.

The situation. The client’s delivery fleet was hitting capacity during peaks — slowdowns, strained servers, an ops system working overtime to keep things smooth. The conventional answer is reflexive: add servers, grow the bill.

The investigation. Before buying anything, we measured what the fleet actually starved for. The answer was lopsided: servers were compute-bound with 84% of their (expensive) memory sitting idle — the wrong machine shape for the workload — and on shared-CPU instances whose performance wobbled with noisy neighbors at exactly the busy moments that mattered. We also found a compounding factor most sizing exercises miss: every additional server dilutes the caches. Content edits must re-render once per server, so more small servers means colder caches and more slow first-loads — the naive “just add nodes” plan would have partially defeated itself.

The solution. A live A/B, not a leap: we cloned a production server onto a dedicated-CPU tier — cheaper per node than the incumbent — admitted it to the load balancer as a low-weight canary, graduated it to a full traffic share, and measured it against its siblings under real load for days. It matched the fleet on throughput, beat it on consistency, and did it for less money. The data settled the target architecture: fewer, stronger servers — 50% more total compute, all dedicated, with fewer caches to keep warm — and the migration executed live, node by node, with zero downtime and zero errors recorded through every transition. The worst-performing legacy server (14 days of health telemetry made the choice for us) was retired the same week.

Results.

• ~50% more real compute than the original fleet, with noisy-neighbor variance eliminated
• Warmer caches by construction — every content edit now re-renders on fewer machines
• Monthly infrastructure cost lower than the fleet it replaced
• Every step validated live behind a load balancer: no downtime, no maintenance window, no leap of faith