Every pillar page and cluster article needs visuals, but “add images” isn’t one decision — it’s at least two. There’s the hero image, the single featured image that represents the whole article in previews, social shares, and the page header. And there’s in-article imagery, the pictures that break up the body text and support specific sections. AutoSchedulePost’s Pillar Pages builder treats these as two separate toggles because they serve different jobs and behave differently when you’re generating 20-40 articles at once.
The Hero Image Toggle
Turn on the hero-image setting and every article in the batch — pillar and clusters alike — gets a featured image generated through the same AI image pipeline used elsewhere in the product. This is the image that shows up when the post is shared, in your site’s archive listings, and typically at the top of the article itself. Because it’s generated automatically as part of the batch, you don’t need to source or upload a separate image for each of 30-plus articles by hand — a task that would otherwise be one of the biggest bottlenecks in publishing a cluster at scale.
The Per-H2 Image Toggle
Separately, you can turn on an image-under-every-H2 setting. When enabled, the generator embeds a responsive image block under each major subheading in the article body — not just one image at the top, but visual breaks throughout the piece. These are built as responsive figure blocks with a maximum width tied to the content column, so they never overflow their container regardless of screen size — a deliberate fix for the common complaint of AI-inserted images rendering oversized or breaking a layout on mobile.
Why These Are Separate Settings
Hero and section images solve different problems. A hero image is about how the article presents itself before anyone starts reading — in a social preview, an archive grid, a search result rich snippet. A per-H2 image is about pacing the reading experience once someone is actually in the article, breaking up long stretches of text with visual anchors tied to specific sections. You might want both for a long, dense pillar page and only a hero image for a shorter cluster article — keeping them as independent toggles lets you make that call per batch rather than being locked into an all-or-nothing image policy.
Why There's No Manual Click-to-Insert Picker
A natural expectation might be a true editor where you click into any heading and manually choose or place an image. That doesn’t fit how pillar and cluster content actually gets produced: articles are queued for generation before their HTML exists — the body content is written later, in the background, as part of the batch job. There’s no article to click into at queue time, because it hasn’t been generated yet. Instead, the toggles set an instruction that’s honored during generation itself, so the image placement happens automatically as the content is written, achieving the same practical outcome (images at the top and under every H2) without requiring a manual editing pass on each of 30-plus articles after the fact.
When to Use Which
- Hero only: shorter cluster articles, or batches where visual variety matters less than getting a clean batch published quickly.
- Hero + per-H2: long-form pillar pages and substantial cluster articles where the reading experience benefits from visual breaks — a 2,000-word pillar page with six H2 sections and no imagery at all reads as a wall of text.
- Neither: rare, but reasonable if you have a separate manual image workflow you prefer to run after publishing, or your site’s design already handles visual variety through layout rather than in-article images.
Practical Considerations for Large Batches
Turning on both toggles for a 40-article batch means the generation pipeline is doing meaningfully more work per article — an extra image per H2 section, on top of the hero image, on top of the article body itself. That additional generation load is one contributor to longer processing times on large batches, which matters if your batch is scheduled with a tight interval or is competing against a background job timeout. If you’ve seen articles stall mid-generation on a large batch, reviewing your image settings — not just your scheduling interval — is worth doing alongside the diagnosis covered in our companion piece on generation timeouts.
A Reasonable Default
For most pillar sets, turning on the hero-image toggle for everything and the per-H2 toggle for the pillar page plus any cluster article expected to run long is a sensible middle ground — you get consistent, professional-looking previews across the whole batch, and visual pacing where the content actually needs it, without pushing every single short cluster article through the extra generation overhead of per-section imagery it may not need.
The Takeaway
Hero and per-H2 images are separate toggles because they solve separate problems: one is about how an article presents itself before the click, the other is about pacing the read after it. Set them deliberately per batch rather than defaulting to both-on or both-off out of habit, and factor them into your expectations around generation time on larger pillar sets.
