Running one workflow is straightforward: build the sequence, set the pacing, let it advance. Running two at once — say, one dedicated to pillar pages and another to standalone supporting posts — introduces a new question that a single workflow never has to answer: what happens when both of them decide, independently, that right now is a good time to publish?
Why Collisions Happen
Each workflow paces itself using its own interval settings, whether fixed or weighted, and its own sense of when it’s “due” to advance. Neither workflow knows the other exists. If both are configured with similar target cadences — say, both favoring morning and evening windows, as covered in “Building a Time-of-Day Posting Curve: Morning, Midday, Evening Weights” — there’s nothing stopping them from both deciding to publish within the same few minutes of each other, simply because they were each independently tuned toward the same attention windows.
That’s not a bug exactly — it’s the natural consequence of treating each workflow as its own self-contained pacing system. The collision only becomes a real problem when it results in more total publishing volume landing in a tight window than you actually intended, site-wide.
Thinking About Combined Density, Not Just Individual Cadence
The fix isn’t complicated, but it does require a shift in how you think about pacing: instead of tuning each workflow’s interval in isolation, treat the sum of both workflows’ output as the thing you’re actually shaping. If your pillar-page workflow and your post workflow both want to lean into the 8–10 a.m. window, ask what the combined publishing rate looks like during that window across both — not just whether each workflow’s own settings look reasonable on their own.
Practical Approaches to Avoiding Overlap
- Offset the peak windows. Instead of both workflows favoring the identical morning and evening peaks, shift one slightly — pillar pages weighted toward late morning and early evening, posts weighted toward early morning and late evening, for instance. Distinct enough to avoid stacking, close enough that both still land in reasonably high-attention periods.
- Widen the interval range on whichever workflow is lower-priority. If pillar pages matter more for a given push, give the post workflow a looser, wider interval range so it’s less likely to land in the exact same minute as a pillar page publish.
- Stagger by content type, not just time. Since one workflow is pillar-focused and the other is post-focused, the content itself is already naturally distinguishable to readers — some teams find that’s actually acceptable overlap, since a pillar page and a supporting post landing close together isn’t necessarily bad, especially if the post links back to the pillar as companion content.
- Monitor the Content Calendar directly. Because every workflow’s output lands on the same calendar grid as everything else, you can visually check for days where both workflows produced a cluster of chips close together and adjust settings if the pattern looks too dense.
When Overlap Is Actually Fine
Not every overlap is a problem worth engineering around. If a pillar page and one of its supporting posts happen to publish within an hour of each other, that’s often a reasonable outcome — the post can reference the pillar as newly available companion reading, and readers arriving at either piece have a natural link to the other. The collision to actually worry about is volume-based: multiple unrelated pieces landing at nearly the same moment, making your site look like it dumped a batch of content all at once rather than publishing at a steady, human-plausible pace throughout the day.
A Simple Test for Whether You Have a Real Problem
Look at the Content Calendar for a representative week with both workflows active. If any single day shows a tight cluster of chips within the same hour or two — more than you’d expect a small team to plausibly produce and review in that window — that’s the signal to adjust one workflow’s weighting or interval range. If the chips are spread with reasonable variation across the day, even if both workflows lean toward similar peak windows, you likely don’t have a meaningful collision problem, just two workflows that happen to agree on when your audience is most active — which, if your time-of-day research is accurate, is exactly what you’d want both of them doing anyway.
The Underlying Principle
Two workflows aren’t automatically in conflict just because they overlap in timing — they’re only in conflict if their combined output produces a publishing pattern you wouldn’t have chosen deliberately. Treat “what does my site’s total publishing rhythm look like across all active workflows” as the actual thing you’re managing, not each workflow’s settings viewed in isolation, and collisions become a tuning question rather than a structural limitation.
