A pillar’s keyword list changes over time. You start with the cluster the builder generated, prune a few, add a few more as you research the topic further, and eventually some keywords have already been sent off and published while others are still sitting in the queue. Keeping track of which is which becomes genuinely important the moment you’re managing a cluster of any real size — and it’s exactly the distinction AutoSchedulePost’s “Send to Pages builder” flow is built around.
The Core Filter: Not-Yet-Published
When you trigger “Send to Pages builder” on a cluster, the flow doesn’t hand over every keyword indiscriminately — it specifically filters for keywords that haven’t been published yet. Anything already live as a page or post is excluded automatically. That single filter is what makes it safe to run the send-to-Pages action more than once on the same pillar: the second time you run it, only the newly added, still-unpublished keywords go through, and nothing that’s already live gets duplicated or reprocessed.
Why This Distinction Matters
Without a sent/not-sent distinction, managing a growing cluster would require manually tracking, outside the tool, exactly which keywords have already been turned into live pages — a spreadsheet side-project that inevitably falls out of sync with reality the moment someone publishes something manually or the cluster grows past a size you can track by memory. Building the filter into the send flow itself means the tool is always the source of truth for “sent vs not sent,” not a separate document you maintain in parallel.
Where You See This in Practice
The natural workflow looks like this: you build a pillar, generate an initial cluster, and send an early batch to the Pages builder. Weeks later, you do more keyword research on the same topic, add a dozen new cluster keywords, and want to send those along too — without touching anything already published. Triggering “Send to Pages builder” again picks up exactly those new keywords, because the ones from the first batch are now excluded by the not-yet-published filter. You never have to remember which keywords went out the first time; the system already knows.
Using the Picker Deliberately
Once keywords land in the Pages builder, its editable list is where the actual “pick which to send” decision happens. Every not-yet-published keyword shows up there, and you decide, batch by batch, whether to:
- Send the entire not-yet-published set through in one action, appropriate when you’ve already reviewed the list and trust it’s ready.
- Review the list and remove anything you’re not ready to publish yet, before running the send.
- Leave the list untouched for now and return to it later, since nothing is forced through until you actively trigger the send.
A Common Mistake: Assuming Everything Sends Automatically
It’s worth being explicit that adding a keyword to a cluster doesn’t publish it anywhere on its own — it only becomes eligible to be sent, through either “Write all” (as a blog post) or “Send to Pages builder” (as a page). A cluster can accumulate dozens of researched, unsent keywords sitting quietly, doing nothing, until you actively choose to process them through one of those two paths. That’s by design — it gives you a holding area for keyword research that hasn’t been committed to content yet — but it’s easy to assume a keyword is “in progress” the moment it’s added, when in fact it’s just sitting in the not-yet-sent pool until you act on it.
Checking Your Sent Status Before a Big Push
Before running a large send-to-Pages batch, it’s worth a quick pass through the keyword list to confirm:
- Every keyword you expect to already be live actually shows as published — catching this early avoids confusion later about why a keyword wasn’t included in a send.
- No near-duplicate keywords have crept into the not-yet-sent pool that would produce two very similar pages if both were sent through.
- The keywords you’re about to send are actually page-shaped content (service, location, comparison intent) rather than better suited to a blog post via “Write all.”
The Takeaway
The sent vs not-yet-sent distinction is a small mechanic with an outsized practical effect: it’s what lets you treat a pillar’s keyword list as a living, growing thing you can return to indefinitely, sending fresh batches through as research continues, without ever worrying about duplicating or reprocessing something that’s already live. Trust the filter, use the editable list as your picker, and you can manage a cluster’s rollout over months without a parallel tracking system.
