Tell them apart with one test: check the drop’s timing, its scope, and your own change log together, because the two causes leave opposite fingerprints on all three. A technical break and an algorithm update do not look alike when you line up when it happened, how widely it hit, and what changed on your end. Run that comparison before you assume anything, including the popular assumption that every sudden drop must be an update.

A technical break usually arrives abruptly, a clean cliff on a single day or hour, and tends to hit broadly, often site-wide, because the thing that broke is shared infrastructure: a robots rule, a noindex tag pushed live, a server outage, a botched redirect, a template change. The decisive tell is that something traceable changed behind it. If you can point to a deploy, a CMS edit, a DNS change, or a configuration push near the drop date, you are very likely looking at a break, and it is yours to fix immediately.

An algorithm update wears a different profile. It tends to roll out across a date range rather than landing in one instant, so the decline often looks staggered over several days. It hits selectively, not uniformly, favoring or punishing pages by content type, quality, or topic, so some pages fall while neighbors hold or even rise. And critically, nothing on your side changed, your change log is clean around the drop.

So lay the two profiles side by side and read your evidence against them. Abrupt plus broad plus a traceable change points to a break. Gradual plus selective plus a clean change log, lined up with a known update date, points to an update. The discriminating move is the cross-check itself, not a description of each cause in isolation.

When your next sudden drop appears, pull up your change log and a reputable update tracker, then match the drop’s exact date and pattern against both before deciding which problem you are actually solving.