“Blast radius” sounds like infrastructure language, but public-site work has one too. A content correction can touch a single essay, every page using a template, or the build and publishing path for an entire archive. The site may be static and the change may be mostly words. That doesn’t make the consequence imaginary.
I prefer small publication changes because they’re easier to understand, review, and correct. That preference is sometimes mistaken for caution that slows the work. The mechanics point the other way.
Myth: one large batch is more efficient
Combining many edits saves a little setup time. There’s one branch, one build, and one publication action. It also creates a review surface in which unrelated errors can hide beside one another.
Suppose a batch changes article bodies, image metadata, shared navigation, and a date formatter. If an archive page changes unexpectedly, the candidate set contains four kinds of cause. The reviewer has to hold the intended effects of all four while deciding whether the output is acceptable. That cognitive load doesn’t appear in the build duration, but it’s real work.
A smaller batch preserves a cleaner relationship between intention and rendered difference. When I’m replacing a bounded set of articles, I don’t also tune the global card component because I noticed some padding. The padding can wait for a change whose evidence is about padding. “Already in the file” is a location, not a reason to expand scope.
The efficiency question should include diagnosis and rework. One extra build is cheap compared with reopening a mixed batch and proving which parts remain good after a correction.
Myth: preview contains the risk
A preview is useful, but it doesn’t change the scope of shared code. A template edit shown on one article can still affect hundreds of routes when published. A metadata parser tested against a convenient post can still behave differently on older frontmatter.
The blast radius comes from the dependency graph, not the URL I happened to open. I identify whether a changed file is leaf content, a collection query, a shared component, or build configuration. Each category deserves a different inspection range.
For leaf content, I can review the assigned page plus the relevant listing entry. For a shared template, I choose representative old and new content shapes, narrow and wide viewports, and pages with missing optional fields. For collection logic, I inspect ordering, inclusion, and counts around the changed boundary. I don’t click every page, but I also don’t let one preview impersonate the archive.
This is why changing the shared layer to solve a one-page problem often feels wrong. The implementation may be elegant while the exposure is wildly disproportionate. A local correction with an explicit reason can be the better design.
Myth: rollback makes a broad change safe
Version control makes reversal possible. It doesn’t make a broad release easy to reason about after readers, caches, feeds, or downstream builds have observed it.
If one revision contains eight unrelated corrections and one is wrong, reverting the revision removes seven good changes too. Fixing forward requires identifying and isolating the bad part under pressure. Neither option is catastrophic, but both convert the convenience of batching into later coordination.
Published content can also escape the site. Feed readers retain copies. Search systems index titles and excerpts. Social previews cache images. A quick rollback may restore the repository while the wider public record remains inconsistent for a while. I can’t treat publication like a private database transaction that nobody saw until commit.
Smaller changes give each correction its own identity. If an image is wrong, I can correct that article without moving the archive formatter again. If a template change misbehaves, I can reverse it without withdrawing the content work. Recoverability improves because the change boundaries match the things I may need to recover independently.
Myth: consistency requires one release
Visual and editorial consistency matter, but a single giant change isn’t the only way to obtain them. In fact, bundling can make consistency harder to inspect because the reviewer is comparing too many dimensions at once.
I prefer to define the invariant first. Frontmatter must retain a known shape. Article bodies must fit a length and heading contract. Cards must handle titles within an expected range. Once the invariant is explicit, related small releases can be checked against the same rule.
This is especially useful for archive work. A sequence of replacements may share an acceptance contract without sharing sentences, arguments, or a publication event. Treating them as one monolith encourages accidental repetition and makes one weak essay a blocker for unrelated work. Keeping the file scope bounded lets each piece stand on its own while automated checks enforce the collection rules.
There are legitimate broad changes. A schema migration or deliberate redesign may need coordinated movement. In that case I want the breadth to be the subject of the work, not a side effect of convenience. The review plan should follow the dependency graph, and the release should say what moved together and why.
For ordinary public-site maintenance, my default is smaller. I separate content, templates, and publishing machinery unless the change itself requires their coordination. Then I review the rendered difference at the level the changed layer can affect.
That choice produces more modest commits and fewer heroic preview sessions. I’m comfortable with that trade. The site doesn’t award points for the number of intentions packed into one deployment, and neither does the person trying to understand what changed after it lands.