I could queue a year of articles in a single afternoon. My pipeline drafts far faster than I could ever publish, so lining up a hundred posts into the calendar is trivial mechanical work. I don’t do it, and I’ve stopped recommending it, because when you pre-schedule posts that far ahead you trade away the one thing that actually decides whether they rank: your ability to react to what indexing tells you week by week. Here’s the arithmetic behind that call, the difference between batching your drafts and batching your publishing, and the cadence I use instead.
The afternoon I could have queued a whole year
The temptation is real, and it feels like discipline. You have a content plan, you have drafts stacking up faster than your calendar fills, and scheduling them all at once looks like the responsible thing to do. One sitting, a hundred future dates, and the publishing problem is “solved” for twelve months. I’ve sat in front of exactly that queue with my finger over the button.
What stopped me wasn’t a rule someone handed me. It was watching a young site try to digest more posts than search would accept, and realising that a full queue isn’t a plan — it’s a bet you place before you have any of the information that would tell you how to bet. Publishing is cheap. Getting indexed is the part that’s scarce, and a year-long queue spends that scarce resource blind.
The indexing math that changes the decision
Start with the only ratio that matters here: your index rate, which is indexed pages divided by all pages Google knows about. If Google has discovered 100 of your URLs and indexed 40, your index rate is 40 percent, and the 60 sitting in “discovered” or “crawled — currently not indexed” aren’t earning a thing. They’re not neutral, either. A pile of unindexed URLs is a signal in its own right about how much of your site Google judged worth keeping.
A young domain gets a small allowance of crawling and trust, and that allowance grows with demonstrated quality rather than with volume. Google is explicit that it prioritises what to crawl and how often, and that publishing more URLs does not buy you more attention — if anything, a flood of thin or slow-to-index pages tells it to spend less. You can read the mechanics in Google’s own guidance on managing crawl budget and on creating helpful, people-first content.
So the math runs the wrong way when you pre-load a queue. Push out fifty posts in three weeks on a site that has earned the crawl budget for maybe eight, and roughly forty of them stall. Your index rate drops, and a low index rate slows the crawling of the next batch, which drops the rate further. That’s a compounding loss, and you set it in motion the moment you scheduled everything at once instead of pacing the release to what the site could absorb.
Batch the drafts, not the publishing
Here’s the split that resolves the whole tension, because the instinct to work in batches isn’t wrong — it’s aimed at the wrong stage. Drafting in bulk is pure upside. Writing ten pieces in one focused stretch keeps the voice consistent, reuses the research momentum, and lets a pipeline do the mechanical formatting once instead of ten scattered times. Nobody gets penalised for having a deep draft folder.
Publishing in bulk is where the same instinct turns costly. The moment those drafts become live URLs on a fixed future schedule, you’ve converted a flexible asset into a rigid commitment that ignores every piece of feedback the site is about to give you. The fix is simply to keep the two stages apart: let the drafts pile up as high as you like, and release them on a cadence that matches indexing reality. A batch queue of finished drafts is an asset; a batch queue of scheduled publishes is a liability wearing the same clothes.
This is exactly the seam I designed around in the AI WordPress content pipeline I run: the drafting side is allowed to run ahead, and the publishing side is deliberately throttled, so the machine’s speed never becomes the site’s problem.
What a flooded queue does to a young domain
Beyond the index-rate spiral, a year-long queue costs you three things you don’t notice until they’re gone. The first is feedback. When posts land one at a time, you can see which topic got indexed fast, which one pulled impressions, which one Google shrugged at — and you can steer the next release accordingly. Dump them all at once and every signal arrives tangled together, so you learn almost nothing you can act on.
The second is the ability to fix a systemic mistake before it multiplies. A queue is a template applied over and over, and if a formatting or structural flaw is riding in that template, a paced release lets you catch it after post two instead of after post sixty. The third is priority: a story that matters this month shouldn’t wait behind forty pieces you locked in during some optimistic afternoon. A queue that can’t be reordered without unpicking dates isn’t a schedule, it’s a cage.
The cadence I pre-schedule posts at instead
I still pre-schedule posts — just not a year of them. On a young site I keep the live queue short, usually two to three weeks deep, releasing roughly every two to three days. Scheduling itself is two fields through the WordPress REST API: a status of future and a date in the site’s timezone. The same code that validates a post is the code that queues it, so nothing slips in between.
The rhythm is deliberate. Publish, request indexing, and give it a couple of weeks before I judge whether the site is keeping up. If posts are getting indexed within days, I can tighten the interval; if they’re stalling, I slow down and spend the freed time strengthening what’s already live rather than adding more. The queue stays short on purpose, because a short queue is one I can reorder the instant something more urgent shows up.
| Pre-schedule the whole year | Batch-draft, rolling-publish | |
|---|---|---|
| Draft in bulk | Yes | Yes |
| Publish in bulk | Yes, all at once | No, paced release |
| Reacts to indexing feedback | No — dates are locked | Yes — adjusts each week |
| Catches a template flaw early | Rarely — it’s already shipped | Usually — after a post or two |
| Can reprioritise a timely piece | Only by unpicking the queue | Freely |
| Effect on a young domain | Index rate spirals down | Index rate holds and grows |
None of this is about publishing less over a year. A paced site and a flooded site can land the same number of posts across twelve months. The difference is that one of them got most of those posts indexed and learned something from each release, while the other buried good work under a quality signal it created itself.
FAQ
Is it bad to pre-schedule posts at all?
No. Scheduling a short, rolling queue is fine and useful. The problem is the depth: locking in months of dates removes your ability to react to indexing and to reorder for timely topics. Keep the live queue a few weeks deep, not a year.
How many posts a week can a new site safely publish?
Fewer than you can draft. On a young domain I stay around two a week and let the index rate tell me whether to speed up or slow down. The ceiling is how fast Google will index your pages, not how fast you can write them.
What’s the difference between batching drafts and batching publishing?
Batching drafts is pure efficiency — consistent voice, shared research, formatting done once. Batching publishing converts those flexible drafts into a rigid schedule that ignores feedback. Batch the first stage as much as you like; pace the second.
Why does a flood of posts lower my index rate?
A young site has a limited crawl and trust allowance. Publish more URLs than that allowance covers and many stall in “discovered” or “crawled — currently not indexed.” A low index rate is itself a signal that slows the crawling of your next batch, so the loss compounds.
How do I schedule posts through the WordPress REST API?
Set the post’s status to future and give it a date in your site’s timezone. That turns a publish into a schedule with two fields, no plugin required, and lets you queue at a controlled pace from the same code that validates the post.
My Thoughts
The version of me that wanted to queue a year of posts was really trying to buy certainty — to make the future feel handled. What I learned is that a full queue doesn’t buy certainty, it forfeits it, because it commits you before the site has told you anything. A short, honest cadence keeps the decision open: I get to see how each post lands and let that steer the next one. On a young domain, staying responsive beats looking organised, and I’d take a calendar with room to change my mind over a tidy year of locked-in dates any day.