Most content teams build topic clusters by hand: a spreadsheet of keywords, a folder of drafts, a checklist of internal links that someone inevitably forgets to add. AutoSchedulePost’s Pillar Pages builder exists to collapse that entire workflow into one screen — you type a seed keyword, the tool assembles a pillar-and-cluster structure around it, and you decide how and when the whole set gets written and published. This guide is the umbrella overview: what the builder actually does, how the pieces fit together, and which companion articles to read next for the details on any one part.
What a Pillar Page Is, in Practical Terms
A pillar page is the broad, central article for a topic — the one that could rank for a competitive head-term — surrounded by narrower “cluster” articles that each target a related, more specific keyword and link back to the pillar. Search engines read that pattern (one hub, many spokes, all interlinked) as a signal of topical depth, and readers get a clean path from a broad question to the specific answer they actually came for. Our companion piece What Are Pillar Pages and Why They Anchor Topical Authority goes deeper into why this structure works; here, the point is simply that the builder is designed around this exact hub-and-spoke shape from the moment you enter a keyword.
Starting From a Seed Keyword
Everything begins with one seed keyword — the phrase you want the pillar to own. Type it in, and the builder generates a set of related cluster keywords underneath it. Where a lot of AI content tools quietly rewrite your seed into something more “SEO-friendly” behind the scenes, the pillar slug in AutoSchedulePost is built from the exact keyword you typed, not an AI-rephrased version of it. If you typed “commercial espresso machine maintenance,” that’s what ends up in the URL — not some broadened or reworded variant the model decided sounded better. Each cluster item gets the same treatment: its slug comes from its own exact keyword. The seed keyword itself is also added into the cluster set, so the phrase you started with is represented both as the pillar and, structurally, as part of the family it anchors. We cover the mechanics and the SEO reasoning in How Slug Structure Affects Pillar Page SEO and Why Exact Seed Keywords Make Better Slugs Than AI Rephrasing.
Nested Paths: Pillar, Parent, Child
Once you’ve got a pillar and its cluster keywords, the builder can arrange them as a real URL hierarchy rather than a flat list of unrelated slugs. Instead of every cluster article sitting at the site root, you get nested paths — pillar, then parent, then child — so a URL might read as your-domain.com/pillar-keyword/parent-keyword/child-keyword. This is built on a “chain” mechanism that tracks each item’s position in the hierarchy and constructs the full path accordingly, supporting three to four levels deep. That nested structure is what makes the site’s information architecture visibly match its topical structure — a search engine (and a human skimming the URL bar) can tell at a glance that a child page belongs under a specific parent, which belongs under the pillar. Building Nested Cluster Paths: pillar/parent/child Explained and How Deep Should Nested Slugs Go? 3 vs 4 Levels Explained walk through this in more detail, including when extra depth helps versus when it just adds friction.
Writing the Whole Set: "Write All" and Scheduling Controls
Once a pillar and its clusters are mapped out, you don’t have to queue each article individually. The “Write all” action processes the entire set, and you control the pacing with three options: publish everything now, space items out by a fixed interval measured in hours, or spread them one per day. A start-time field lets you set exactly when the batch begins, and the pillar page itself respects that same start time rather than firing separately from its clusters. This matters in practice because dumping 30-plus posts onto a site in a single afternoon looks unnatural to both readers and search engines, while a controlled drip — six hours apart, or one a day — reads as a normal publishing cadence. Scheduling a Full Pillar + Cluster Set: Interval vs One-Per-Day and Setting a Start Time for a Batch of Scheduled Cluster Posts cover how to choose the right pacing for a given batch size.
Behind that scheduling sits the same engine that runs the rest of AutoSchedulePost’s “schedule for later” features: a scheduler tick that checks for due items and publishes them, running continuously in the background. If you’re publishing “now,” that happens immediately in the same request — no dependency on the background scheduler at all. Anything scheduled for later, though, does rely on the scheduler ticking reliably, which is why generation speed and scheduler health matter for large batches; we get into failure modes in Why Generation Timeouts Happen on Large Pillar Batches and Troubleshooting Posts That Sit in the Queue Past Their Schedule.
Images: Hero and In-Article
Each pillar and cluster post can carry a hero image and, separately, an image under every H2 subheading. Turn on the hero-image toggle and the article gets a featured image generated through the same AI image pipeline used elsewhere in the product. Turn on the per-H2 toggle and the generator embeds a responsive image block under each major heading, sized so it never overflows its column regardless of screen width. Because pillar and cluster content is queued before the actual HTML exists — the article body is generated later, in the background — there isn’t a manual point-and-click editor for choosing exactly which heading gets which image ahead of time. What you get instead is the same outcome delivered through generation: toggle the settings once, and every post in the batch comes out with hero and section images already in place. Hero Images vs In-Article Images: Setting Up Your Pillar Page Visuals, Image-Under-Every-H2: When Responsive Figures Help Readability, and Reusing an AI Featured-Image Pipeline for Every Cluster Post cover this in depth.
Send to Pages Builder
Not every cluster keyword needs to become a blog post. Some belong as actual site pages — service pages, location pages, comparison pages — arranged in the same nested URL structure. That’s what the “Send to Pages builder” button does: it takes a pillar and whichever of its keywords haven’t been published yet, and hands them to a separate page-building flow. That flow publishes each one with the exact keyword as its URL slug, still nested as pillar/cluster paths. The editable keyword list in the Pages builder doubles as your picker — you can send the full set through in bulk, or select just the subset you want built as pages right now, leaving the rest for later. Meanwhile, the ordinary “Write all” path is still there as the straight-to-processing option when you just want blog posts, not pages. Because the flow specifically hands over keywords that haven’t been published yet, you can send a batch, come back later, add more cluster keywords, and send again without re-sending anything already live. Send-to-Pages: Moving Clusters From Pillar Pages to a Live Build, Picking Which Keywords to Send: Sent vs Not-Yet-Sent Filtering, and Bulk-Sending a Cluster vs Hand-Picking a Subset go through this workflow step by step, and How the Pillar & Cluster Builder Differs From the Simple Pillar Flow explains when to reach for which tool.
Tone Stays Consistent Across the Batch
A 40-post cluster written in wildly inconsistent tones reads like it was outsourced to different freelancers — because functionally, without a shared setting, that’s what an AI batch can end up looking like. Every pillar and cluster item in a queue carries your chosen tone explicitly rather than falling back on a generic default behind the scenes. Set your preferred tone once in your account settings — informative, conversational, authoritative, whatever fits your brand — and every post in the batch, pillar included, is generated to match it. Tone Consistency Across a 40-Post Cluster covers why this matters more for pillar sets than for one-off posts, precisely because readers are likely to click from one cluster article to another and notice if the voice shifts.
Why the Structure Matters Beyond SEO
It’s tempting to treat pillar-and-cluster as purely a search-engine trick, but the same structure pays off for readers and for your own content operations. Readers get a coherent path from a broad question to the specific sub-question they actually have, with real internal links connecting the two rather than an orphaned article sitting alone. Your own team gets a visible map of what’s been covered and what’s still a gap — a pillar with 40 mapped keywords and 12 published is obviously an in-progress project, not a mystery pile of drafts. Why Every Cluster Should Link Back to Its Pillar, Interlinking Strategy Inside a Single Topic Cluster, and Building Internal Navigation for a Large Topic Cluster all dig into different angles of this same idea.
Where This Fits Alongside Keyword Research
Pillar Pages doesn’t have to start from a keyword you typed cold. If you’ve already run a Keyword Gap comparison against competitors, the resulting list of coverage gaps can seed a pillar set directly, turning a research report into a build-ready structure without manually retyping keywords. Turning a Keyword Gap Report Into a Ready-to-Build Pillar Set covers that handoff, and How to Plan a 40-Post Cluster Around One Pillar Keyword and Building a Pillar Page From a Single High-Volume Seed Keyword cover planning a set from scratch.
Common Failure Modes
Large batches introduce their own problems: generation jobs that run long can hit a timeout and get killed mid-write, leaving a queued item stuck showing as “processing” indefinitely instead of failing cleanly. If your background scheduler cron isn’t actually running reliably — something worth double-checking, especially on shared hosting — due items pile up past their scheduled slot and sit unpublished. Neither failure mode is fatal, but both are worth knowing about before you queue a 40-post batch and walk away for the weekend. Why Generation Timeouts Happen on Large Pillar Batches, Troubleshooting Posts That Sit in the Queue Past Their Schedule, and How to Recover a Stuck or Failed Pillar Generation Job cover diagnosis and recovery in detail.
Getting Started
If you’re new to the builder, the shortest path to a working pillar set looks like this: pick one seed keyword you genuinely want to own, let the builder generate its cluster, review the keyword list and prune anything off-topic, decide on nesting depth if you want a multi-level structure, set your tone once, choose hero and section image toggles, and then either run “Write all” with an interval that matches your comfort level, or send the not-yet-published keywords to the Pages builder if some of them are better suited to standalone site pages than blog posts. From there, the remaining 40 articles in this series each take one piece of that workflow — slugs, nesting, scheduling, images, send-to-Pages, interlinking, troubleshooting, and use-case templates like local service businesses, SaaS products, and seasonal planning — and go deep enough to actually execute on it. Read them in whatever order matches the decision you’re facing right now; they’re written to stand alone, but they all point back to the same builder described here.
