Wikipedia has no published service-level timeline for reviewing a new page, and the honest answer is that it depends heavily on the review route chosen and how much the draft needs fixing along the way, not just how busy the queue happens to be.
The two routes, and their realistic timelines
| Route | Typical Timeline | Risk Profile |
|---|---|---|
| Articles for Creation (AfC) | Weeks to a couple of months, depending on queue volume | Low, reviewed before going live, so it doesn't get deleted out from under you |
| Direct publish (no AfC) | Live immediately | High, subject to speedy deletion or AfD if it fails notability or reads as promotional |
The AfC queue is worked by volunteer reviewers with no fixed schedule, and wait times fluctuate with how many drafts are currently submitted and how many reviewers are active. A draft that's well-sourced and neutrally written on the first submission usually clears faster simply because it doesn't get sent back with feedback that requires a resubmission and another wait in the queue.
What actually adds delay
- Weak or borderline sourcing. A reviewer who isn't confident the sources meet the independence and significance bar will decline with feedback rather than approve, adding a full resubmission cycle.
- Promotional tone. Language that reads like marketing copy gets flagged regardless of whether the underlying subject is notable, sending the draft back for a rewrite.
- Missing conflict-of-interest disclosure. Reviewers who spot an undisclosed COI may decline on process grounds alone, independent of the content's quality.
- Queue volume. AfC volunteer capacity fluctuates, and there's no way to predict or influence how many other drafts are ahead in the queue at any given time.
What actually speeds things up
- Submitting with multiple genuinely independent, reliable sources already cited, not added after a decline.
- Writing in neutral, encyclopedic tone from the first draft rather than editing promotional copy down afterward.
- Disclosing any paid or affiliated editing upfront, which avoids a process-based decline entirely.
- Getting an honest pre-submission read against Wikipedia's actual sourcing standards, since it's easy to overestimate how independent or significant a source really is when you're close to the subject.
Setting realistic expectations
There's no way to guarantee a specific approval date, and anyone promising a fixed fast turnaround through AfC is either misunderstanding the process or referring to the riskier direct-publish route instead. The more useful planning question is how to make the first submission strong enough that it doesn't need a second pass, since the resubmission cycle after a decline is what most often turns a few weeks into a few months.
FAQ
Is it faster to publish a Wikipedia page directly instead of going through Articles for Creation?
Publishing directly can go live within minutes, but for a company, product, or person with any conflict of interest, it's a much riskier route, not a genuinely faster one. Directly published pages get scrutinized by patrolling editors just as quickly, and a page that fails notability or reads as promotional is more likely to be tagged for speedy deletion than a draft sitting safely in the AfC queue. The AfC wait is the cost of a lower-risk path, not wasted time.
- Direct publishing can go live fast but risks speedy deletion if it fails notability or reads as promotional.
- The AfC queue trades speed for a much lower risk of the page being deleted shortly after going live.
Can you do anything to speed up an Articles for Creation review?
Not directly. There's no paid or expedited review option, and the queue is worked in roughly the order drafts are submitted, by volunteer reviewers. The only real lever is submission quality: a draft with clear, cited independent sources and neutral tone is much less likely to be sent back with feedback, which avoids the resubmission cycle that adds the most time to the overall process.
- There's no way to pay for or formally expedite AfC review.
- A well-sourced, neutral draft avoids the resubmission cycle that adds the most delay.