Your bot works, and people want it in their servers. Growth is exciting, but it brings a few things you can't ignore: a hard verification gate from Discord, the mechanics of getting discovered, and the discipline to not get rate-limited into oblivion. This is a conservative checklist — the parts that are stable and worth planning around, without promises about traffic that nobody can make.
| At a glance | |
|---|---|
| You need | a working, deployed bot |
| Plan | any — though 24/7 uptime becomes more valuable as you grow |
| Time | a checklist to work through over time |
1. The verification gate
This is the big one, and it's Discord policy, not opinion. A bot can be added to servers freely up to a point — but once it reaches 100 servers, it must be verified to be added to more, and Discord grants privileged intents (Message Content, Server Members, Presence) to verified bots only, by approved request. You can apply for verification as you approach 75 servers. Verification means the owner completes identity verification and explains why the bot needs any privileged intents it requests.
Two things follow, and you should plan for them early:
- Prefer slash commands so you don't depend on the Message Content intent at all — see Slash commands vs prefix commands. A bot that never needs a privileged intent sails through this.
- Request only the intents you actually use. Every privileged intent you ask for is something you'll have to justify at verification.
🎯 Good to know: Discord owns these thresholds and can change the exact process. Treat "75 to apply, 100 to require" as the stable shape, but read Discord's current developer documentation before you apply for the up-to-date steps.
2. Sharding (later than you think)
A single connection to Discord can only handle so many servers. At large guild counts, Discord requires your bot to shard — split its connection into pieces. You won't hit this early, and you don't hand-roll it: discord.js ships a ShardingManager that handles the split for you, and Discord's gateway tells your library how many shards it recommends. The honest takeaway: know sharding exists so it isn't a surprise, and turn it on when Discord tells you to — not before.
3. Get listed
Bot lists are how most people discover bots. Prepare a good listing and submit to the well-known directories (top.gg, discord.bots.gg, discadia, and others):
- A clear description of what the bot does and its main commands.
- An invite link with the exact scopes and permissions it needs —
botandapplications.commandsscopes, and only the permissions your features use. Over-asking scares people off. - Screenshots of it working.
Many lists can POST to a webhook when someone votes for you, which you can turn into a reward — hook it into your economy or leveling data. No list can promise you traffic, so treat listings as availability, not a growth strategy.
4. Rate-limit hygiene
Discord rate-limits every route, and a well-behaved bot never trips them. The rules are simple:
| Do | Don't |
|---|---|
| Let your library's built-in request queue pace calls | fire hundreds of API calls in a tight loop |
| Cache data you already have | re-fetch the same user/guild repeatedly |
| Batch updates into one message | edit a message on every single event |
On a 429, wait the Retry-After and retry |
hammer the same request immediately |
Ignore these and you earn a global 429 — or worse, a temporary Cloudflare ban on your whole server's IP. See Discord rate limits.
5. Reliability becomes table stakes
At a handful of servers, a crash is a shrug. At hundreds, it's visible to everyone at once. Before you push for growth, make the bot boring and dependable:
- Stay online. A free session timer that lapses is downtime for every server. Premium's 24/7 is worth it once people depend on you.
- Catch errors so one bad command can't crash the process — see crash-proofing your bot.
- Log to a channel so you find out about problems from your logs, not your users — see logging.
- Back up your data and evolve the schema safely — migrations and the Backups page.
The pre-scale checklist
| ✅ | Before you push for growth |
|---|---|
Token in .env, never in code or Git |
secrets |
| Only the intents and permissions you actually use | slash vs prefix |
| Slash commands, so you don't depend on Message Content | above |
| Errors caught; the process survives a bad command | error handling |
| Data backed up and migrations in place | migrations |
| Invite link with correct scopes/permissions | section 3 |
| Tested in a private server before shipping | test server |
| A plan for uptime | keeping apps online |