Add to Discord
Most advice about Discord servers is really advice about decorating Discord servers — which bot to add, which emoji to use, how to make the rules channel look nice. None of that is what separates a server people stay in from one they mute on day two. The difference is whether a stranger can join, look around for sixty seconds, and work out what they are supposed to do.
This guide is the whole job in order: deciding what the server is, building the smallest structure that supports it, handling the first five minutes a new member spends inside, and setting up the parts that stop it degrading as it grows. It assumes you have a server and permission to change it, and nothing else.
Decide what the server is for
Almost every dead server was built by someone who skipped this. It is not a branding exercise — it is the thing you check every later decision against, and without it every decision is a coin flip.
The test is one sentence, in this shape:
This is a place where [these people] come to [do this thing].
If you cannot fill both halves, you do not have a server yet, you have a group chat with ambitions. And the halves matter differently: who decides the tone, what decides the channels.
- A community for gamers
- A chill place to hang out
- My server for everything
- A place for fans of my content
- Where my Minecraft SMP players organise builds and sessions
- Where people learning Blender post work and get critique
- Where my regulars talk between streams and get pinged when I go live
- Where our study group swaps notes and sits in a silent voice call
The second column tells you what channels to make. The first column tells you nothing, which is why servers built on it end up with thirty channels and no conversation — when every channel is equally plausible, you make all of them.
Start with fewer channels than you think
Discord caps a server at 500 channels and 250 roles. You will never get near either, and quoting them is not the point — the point is that nothing in the product stops you making a channel, so the only limit is your judgement, and most people's judgement is wrong in the same direction.
An empty channel is not neutral. It is evidence. A new member scrolling a sidebar of fourteen channels where the last message in nine of them is three weeks old does not think "this server has a lot of options". They think "this server is dead", and they are reading the situation correctly.
Conversation concentrates or it dies. Ten people in one channel is a conversation. Ten people spread across five channels is five people wondering why nobody is talking.
So start smaller than feels right, and let the server tell you what it needs. Here is a structure that works for almost any new community:
- welcomeRules, what this is, where to go. Locked.
- announcementsYou post, they read. Locked.
- generalEverything, until it visibly needs splitting.
- mediaScreenshots, clips, art — whatever your thing produces.
- VoiceOne. Add a second when the first is regularly full.
- mod-logWhere the bot writes what happened.
- staff-chatCoordination. Not visible to members.
That is it. No #introductions nobody posts in, no #memes competing with #general for the same twelve messages a day, no #suggestions that collects three suggestions and then sits there for a year as a monument.
When to add a channel
There is a real signal for this, and it is not "it seems like we should have one":
- A topic keeps derailing another channel. When people apologise for going off-topic in
#generaltwice a week, that topic has earned a room. - A channel is genuinely too fast to follow. If people are missing replies to their own messages, split it.
- A group needs privacy the current structure cannot give. Staff, a project, a paid tier.
Notice that all three are things you observe, not things you predict. Adding a channel costs nothing and is trivially reversible; adding fourteen channels costs you the impression your server makes on everyone who joins for the next year.
Categories are for you, channels are for them
Categories look like navigation. They are really a permissions tool, and that is the more useful way to think about them.
A channel created inside a category inherits that category's permissions. So the actual job of a category is to answer "who can see this group of channels" once, instead of once per channel — which is what turns a permission mistake from a thing you fix in one place into a thing you hunt for across forty.
- Group by audience first — everyone, members, staff. That is what the permissions actually vary on.
- Then by topic, inside that. A
COMMUNITYcategory with four channels beats four categories with one channel each; a category with one channel in it is a heading, and headings take up sidebar space without earning it. - Keep the sidebar readable without scrolling. If a new member has to scroll to see the shape of your server, the shape is not doing its job.
The full model — who wins when a role says yes and a channel says no — is its own subject. If permissions are where you are stuck, read Discord roles and permissions, explained before you go further; almost everything below assumes you can express "staff only" without locking yourself out.
The first five minutes decide everything
Someone clicks your invite. What happens next is the entire product, and most servers leave it to chance.
The failure mode is not dramatic. They land in #general, see a conversation between four people who know each other, have no idea whether they are allowed to interrupt it, scroll the sidebar, find nothing that tells them what to do, and close the tab. They do not leave the server — leaving takes a decision. They just never come back, which looks identical in your member count and nothing like it in your channels.
A good first five minutes answers four questions, in this order:
What is this place?
One or two sentences, at the top of the first channel they see. Not a wall of rules — a description. "This is the server for the Tuesday night SMP. Sessions are 8pm UK, everything gets organised in #sessions."
What am I not allowed to do?
Short rules, in plain language. Nobody reads twenty numbered rules; five that sound like a person wrote them get read and, more importantly, get quoted back later when you need them. There is a set you can copy.
Where do I go?
Name the channel. Literally point at it: "Say hi in #general — that is where everything happens." One destination, not a tour.
What do I pick?
If you have optional roles — game, region, ping preferences — this is where they belong, and they should be one click. A role you have to ask a moderator for is a role most people will not have.
Discord has a built-in tool for exactly this. Server Settings → Onboarding is available once your server is set to Community, and it puts the questions in front of people before they reach any channel. It requires at least seven default channels, five of which @everyone can view and post in, and it can only be configured on desktop. If your server qualifies, use it — a native flow beats anything a bot can draw.
What a welcome message should actually say
Short, specific, and pointed at one thing. The most common mistake is writing it for you rather than for them — a long paragraph about your community's values, when what the reader needs is a name and a door.
Two sentences, one fact, two destinations. Compare that with the version most servers ship — "Welcome to the server! Please read the rules and enjoy your stay!" — which contains no information at all and could have been written for any server that has ever existed.
Roles do two different jobs — keep them separate
This is where most servers get messy, and the mess is always the same: roles that grant permissions and roles that express identity end up in one undifferentiated list of thirty, and nobody can remember which ones are load-bearing.
| Permission roles | Identity roles | |
|---|---|---|
| What they do | Grant access — moderate, manage messages, see staff channels | Say something about the member — game, region, pronouns, pings |
| Who assigns them | You, deliberately, one person at a time | The member, themselves, in one click |
| How many | As few as possible — usually two or three | As many as are genuinely useful |
| Position | High, above the roles they moderate | Low, below everything that matters |
| If you get one wrong | Someone can delete your channels | Someone has the wrong colour |
Keeping them separate has a practical payoff: identity roles can be handed out by a self-service panel and forgotten about, while permission roles stay a short list you can hold in your head. When a server has three permission roles, "who can do what here" is answerable. When it has fifteen, it is not, and that is how servers end up with a member who can ban people because of a role they picked up in 2024.
- Give
@everyonethe baseline you actually want. It is a real role and every member has it. Most permission problems are solved here rather than by adding another role. - Do not stack permissions on identity roles. The moment
@Valorantgrants anything, it stops being safe to hand out freely. - Remember colour comes from the highest coloured role. Someone with four identity roles shows the colour of whichever sits highest, not the one they picked most recently — which is why colour roles are worth handling as their own thing rather than mixing them in with everything else.
Set moderation up before you need it
Moderation feels like a problem for later. It is not, for one specific reason: the first time it matters, you will be dealing with it live, in front of everyone, while annoyed. That is the worst possible moment to be deciding policy, and whatever you decide then becomes the precedent.
The minimum, for a server of any size:
- A log channel. Staff-only, written to automatically. Not because you will read it daily, but because the one time somebody says "I was banned for no reason", the answer is a link rather than an argument.
- Automatic handling of the boring 90%. Invite links, mass mentions, wall-of-caps spam — these are not judgement calls and they should never have reached a human.
- One escalation you have already decided on. Usually: warn, then timeout, then remove. Write it in the rules so it is a published policy and not a mood.
Give people a reason to come back
Here is the part most guides get wrong, so it is worth being blunt about: no bot creates activity. Levels, economies, daily rewards — none of them make a quiet server busy. They make an already-busy server stickier, which is a real and worthwhile effect, and a completely different one.
A quiet server does not have an engagement problem. It has a reason-to-be-there problem, and no feature fixes that.
What actually brings people back, roughly in order of how much it matters:
- Something happens on a schedule. A weekly session, a Friday call, a monthly event. Predictability beats intensity — people can plan around a thing that always happens, and cannot plan around a thing that sometimes does.
- Someone replies. The single highest-leverage habit in a small server is answering every message a new member posts, quickly, for the first few weeks. That is unglamorous and it works better than anything else on this list.
- They get pinged about something they chose. Which is what the identity roles were for.
- Their presence is visible. Levels, recognisable regulars, a starboard of the best messages. This is the layer bots are genuinely good at.
If you are at step four and steps one and two are missing, you are decorating an empty room. Why members leave goes through the failure in detail, and it is the more useful read if your server is quiet right now.
What changes as it grows
The right server for twelve people is the wrong server for twelve hundred, and the mistake runs both ways — small servers cosplaying as large ones feel empty, large ones still run like small ones fall apart. Roughly:
| Size | What matters | What to add | What to resist |
|---|---|---|---|
| Under ~50 | That anyone talks at all | Almost nothing. Reply to people. | More channels. More roles. Any bot that adds noise. |
| 50 – 500 | That new members find a way in | Onboarding, self-roles, a real welcome, automatic spam handling | Splitting #general before it is actually too fast |
| 500 – 5,000 | That it does not need you personally | A staff team, a written escalation policy, logging, levels | Making every regular a moderator |
| 5,000+ | That moderation scales and structure stays legible | Automation for anything done more than weekly, forum channels for support | Assuming the structure that got you here still fits |
The transition that catches people is the third one. A server that has always run on the owner being present breaks the week the owner is busy, and it breaks in a way that looks like the community losing interest rather than a process failing.
The mistakes worth naming
Everything above, compressed into the things people actually do:
- Building for the server you want in a year. Thirty channels and twelve roles on day one is not ambition, it is an empty-looking server that never gets to year one.
- A rules channel nobody can finish. Twenty numbered rules is a legal document. Five is a set of rules.
- Adding bots to fix quietness. See above. Add bots to remove work, not to manufacture activity.
- Making friends into moderators. Moderator is a job with a permission attached, not a gift. Give people the role when there is work for them, not as a thank you.
- No staff channel. Moderation decisions discussed in public turn into arguments in public.
- Never announcing anything. A server where the owner has not posted in three weeks reads as abandoned, whatever the members are doing.
- Treating the member count as the score. A hundred people who talk is a community. A thousand who do not is a mailing list with worse notifications.
Frequently asked
How many channels should a new Discord server have?
Five to eight, including staff channels, and two of those are locked information channels. One general chat, one media or topic channel, one voice channel. Add more only when a specific topic keeps derailing an existing channel, or when a channel is genuinely too fast to follow.
Do I need bots to make a good Discord server?
No. A well-structured server with clear rules and an owner who replies to people beats a badly-structured one with ten bots. Bots are worth adding when there is a repetitive job to remove — greeting people, handing out roles, catching spam — not to make a quiet server feel busy.
Should the rules be in their own channel or in the welcome message?
Their own channel, locked so only you can post, and linked from everywhere else. You need a stable place to point at during a disagreement, and a rule buried in a scrolling welcome channel is not stable. If your server is set to Community, Discord's Onboarding can also require people to acknowledge them before they reach any channel.
How do I get people to actually join?
Nothing inside the server solves this — it is a distribution problem, not a design one. The server's job is to convert the people who do arrive, which is what the first five minutes is about. A server that converts one in three visitors from a small audience beats one that converts one in twenty from a large one.
Is it bad to delete channels?
Deleting an unused channel is good housekeeping and nobody will notice. Deleting a used one has a real social cost — pinned messages, links people have shared, habits. If a channel is quiet but has history, archiving it (remove the ability to post, keep it readable) is usually the better move.
Where to go next
If you are building from nothing, the order that works is: structure, then rules, then the first five minutes, then everything else. Those are the next three guides in Start here.
If the server already exists and it is quiet, skip all of that and read why members leave instead — the fix is almost never structural, and rebuilding the channel list is the most satisfying way to avoid the actual problem.