XenForo does not ship a server browser. It ships threads, prefixes, custom fields, a forum list, and — if you buy the official add-on — a Resource Manager that is a catalogue, not a query of FiveM or Minecraft. That is enough to run a directory people can trust. It is not enough to show live player counts, ping, or a green “online” dot that updates itself. If you start by installing a listing add-on because you wanted a filterable list of connect strings, you skipped the part stock XenForo already does.
A listing is a job. Someone has to declare a server, staff have to decide whether that declaration is still true, and a stranger has to filter the board down to “whitelist Minecraft in EU” without reading forty first posts. Do that with the node tree, prefixes, and custom thread fields. Add a live query later only if the directory is already boring and correct.
What the directory is for
Gaming communities land on a forum because they need a room that is up, joinable, and not a scam. FiveM, Minecraft, and Discord-only groups all ask the same three questions. They ask them in different fields.
| Question | FiveM | Minecraft | Discord |
|---|---|---|---|
| How do I join? | Connect string / join code | Address and port | Invite |
| What am I joining? | Framework, voice, one-sync, whitelist | Version, mode, premium vs cracked | Topic, language, 18+ |
| Is it still real? | Staff-verified prefix, last bump | Same | Same — invites rot weekly |
The directory’s product is the answer to those three questions, not a card grid. A card grid with fake player counts is worse than a plain thread list with a required connect field. Write the fields first. Paint later.
Do not mix this job with a whitelist application form. Applications are a workflow: a user asks, staff decide, a group changes. That is a different article. A listing thread can say “whitelist required” with a prefix. It should not be the form.
Do not mix it with a Discord bot that posts status every five minutes. Stock XenForo will not talk to a game query protocol. If you need that, you are buying or writing an add-on. Be honest about it on day one so members do not treat a stale “Online” prefix as telemetry.
Pick the architecture before you create the forum
Three honest shapes. Pick one. Mixing them is how you get a Resources tab, a “Servers” forum, and a page node that all disagree.
| Shape | What each listing is | Filter UI | Discussion | When it is right |
|---|---|---|---|---|
| Thread directory | One discussion thread | Prefixes on the forum view; fields on the thread | Replies under the listing | Default. FiveM / Minecraft / Discord hubs where people ask “can I join” on the same page |
| Resource catalogue | One XFRM resource | Resource categories + resource prefixes + resource fields | Optional auto-created thread | The artefact is the listing and chatter is secondary — a curated partner list |
| Page | HTML you typed | None | None | Never, once you have more than five servers |
The thread directory is the one this article builds. It uses only core XenForo. The Resource Manager path is a paid official add-on; it is the right second architecture, not a free upgrade hiding in 2.3. A page node with a handwritten table is how last year’s connect strings stay on the homepage after the servers died.
Suggestion forums are a trap here. A suggestion thread can only live in a suggestion forum, and that forum orders by vote score. That is a “best server” contest, not a directory. Use it only if voting is the product. Do not convert a working discussion directory into suggestions so the list “feels more modern.” You lose last-post bumping, you lose a normal thread list, and you cannot put suggestion threads in a regular forum later without extra work.
Article forums are the other trap. An article makes the first post prominent and treats replies as comments. That sounds like a server card until you need staff to ask for a new screenshot, or a player to report a wipe. Use a discussion forum. Put the card in custom fields and the first post, not in a thread type that fights conversation.
Build a tree a stranger can filter
The directory is a node. Treat it like any other room: the right type, a parent, a display order, a URL portion you will not rename. The complete tree work is in the nodes guide. Here is only what a listing needs.
One public category named for the job — Play, Servers, or the game the whole site is about. Inside it, decide whether the game is a forum or a prefix.
Use a forum per game when each game has its own staff, its own connect rules, and its own argument culture. FiveM and Minecraft do. A player who wants a survival world should never have to skip a page of FiveM economy ads.
Use one forum plus prefixes when you have three small rooms and one moderator. Prefixes are the filter XenForo already draws on the forum view. Three prefixes (FiveM, Minecraft, Discord) on one “Servers” forum is a directory. Twelve game forums with two threads each is a dead mall.
A search forum is a saved search that looks like a forum in the list. Use it as a view — “Whitelist required,” “Verified this month” — not as a home. It does not replace the real forum. It also does not invent a filter on a custom field that the search engine cannot see. If you need “EU only” as a row in the node list, that is a prefix or a second forum, not a search forum you hope will read a dropdown.
Hide the staff intake forum from the node list. Staff still need a place for “this listing is a stolen banner” notes. Display-in-list is not a permission. Lock it with the same overlay you use on every private room; the permissions starter is the map.
URL portions: servers, fivem, minecraft, discord. Not new-server-list-2026. Changing a URL portion later is a redirect project. The listing will outlive the current game season.
Prefixes are the filter members actually use
Thread prefixes live in Forums → Thread prefixes. They print before the title in almost every context, including search-engine titles. A thread may have one prefix at a time. That limit is the design. Do not fight it with two vocabularies in the title ([FiveM] [EU] Cool RP) while also using prefixes. Pick the dimension the filter must carry.
On a game-split tree, the prefix is status, not the game:
- Verified
- Unverified
- Whitelist
- Offline
- Closed
On a single Servers forum, the prefix is the game, and status goes in a field or in the title the old-fashioned way. You cannot filter by two prefixes. If both dimensions matter equally, you need two forums or you need an add-on.
Since 2.2 a prefix can carry two helper texts. Description sits under the thread title for readers — use it for Offline (“Staff marked this listing down. Do not join until it flips.”). Usage help is for the person creating the thread — use it so they do not pick Verified themselves. Usable by user groups is the control that makes Verified staff-only. Applicable forums keeps FiveM prefixes off the Minecraft forum.
When you view a forum, XenForo already lets people filter by prefix. That is the directory UI. You do not need a second navigation. Style the prefixes so Verified and Offline cannot be confused at a glance. That is a style-property / extra.less job on the prefix class, not a reason to install a card-grid add-on.
Require a prefix on the forum if the ACP lets you treat “no prefix” as incomplete. If it does not, moderate the ones that ship with a naked title. An unprefixed listing cannot be filtered, which means it is not in the directory. It is just a thread.
Custom thread fields are the server card
Custom thread fields are in Forums → Custom thread fields. They belong to the thread, not to replies. The create-thread form asks for them once. Later replies never see the form. That is what you want: the connect string is metadata, not a conversation.
The manual names three display locations:
- Before message — in the first post, above the body.
- After message — in the first post, below the body.
- Thread status block — a small block above the first post, on every page of the thread.
Put join data in the thread status block. A player who opens page two of a busy listing still needs the connect string. Put flavour text (rules, lore, “what a new player does in the first hour”) in the first-post body, not in a field. Put a long paste (full changelog) After message only if you must; it bloats every first post.
Applicable forums and Editable by user groups work like prefixes. A Discord invite field does not belong on the Minecraft forum. A “Verified by” field should be editable by staff groups only, or you will moderate fiction.
The official page describes the same family of inputs as custom user fields: text boxes, radio buttons, checkboxes. Use a text box for connect strings and invites. Use radios for a closed set (premium / cracked, whitelist yes/no). Use checkboxes only when several things can be true at once (voice + one-sync + economy). Do not invent a “live player count” number field that owners type by hand and never update. If the number is not measured, it is marketing. A checkbox “Server was up when I posted this” is more honest.
Fields are not a second prefix. They do not show as tabs on the forum view. Members will not filter the list by a radio you hid in the status block. If a value must drive the list, it is a prefix or a forum. If a value must be copied to join, it is a field.
Keep the set small. Six fields is a card. Fourteen fields is a form people abandon. Required fields are for join data only. Everything else is optional or staff-only.
Field sets that match the three communities
Reuse IDs across forums only when the meaning is identical. A “Region” radio can be shared. A “Connect” text box should be per game so the hint text can tell the truth.
FiveM
| Field | Type | Required | Display | Who edits |
|---|---|---|---|---|
| Connect string | Text box | Yes | Status block | Owner, staff |
| Framework | Radio (stock / ESX / QB / other) | Yes | Status block | Owner, staff |
| Voice | Radio (none / built-in / third party) | No | Status block | Owner, staff |
| Whitelist | Radio (open / apply / closed) | Yes | Status block | Owner, staff |
| Region | Radio | Yes | Status block | Owner, staff |
| Staff notes | Text box | No | After message | Staff only |
The first post is the rules and the “first hour” paragraph. The banner, if you allow one, is an attachment on that post — not a remote hotlink that will 404. Prefix = Verified / Unverified / Offline. Do not put the framework in the prefix if you already have a field; you only get one prefix.
Minecraft
| Field | Type | Required | Display | Who edits |
|---|---|---|---|---|
| Address | Text box | Yes | Status block | Owner, staff |
| Port | Text box | Yes | Status block | Owner, staff |
| Version | Text box | Yes | Status block | Owner, staff |
| Mode | Radio (survival / creative / minigames / modded) | Yes | Status block | Owner, staff |
| Account | Radio (premium / cracked / both) | Yes | Status block | Owner, staff |
| Whitelist | Radio | Yes | Status block | Owner, staff |
Version as a text box, not a radio, unless you are willing to edit the field definition every release week. A radio that still says 1.20 when the world is on 1.21 is how the directory becomes a joke. Prefix can be the mode if the whole forum is Minecraft and you want the forum-view filter to be “show me survival.”
Discord
| Field | Type | Required | Display | Who edits |
|---|---|---|---|---|
| Invite | Text box | Yes | Status block | Owner, staff |
| Topic | Text box | Yes | Status block | Owner, staff |
| Language | Radio | Yes | Status block | Owner, staff |
| Age | Radio (all ages / 18+) | Yes | Status block | Owner, staff |
Discord listings die when the invite expires. Make Offline a staff prefix and tell owners in the usage help: if the invite 404s, the listing is Offline the same day. Do not store a “member count” field. It is a brag and it is wrong by dinner.
Cross-posting the same community as a FiveM thread and a Discord thread is fine if the Discord is a real hangout, not just the FiveM queue. If the Discord exists only to get a whitelist, keep one FiveM thread and put the invite in a field. Two listings for one room is how the filter lies.
Permissions: who may claim a server
A directory without an overlay is a classifieds wall. Use the same permission pattern as any moderated room.
- Create the listing forum (or one per game) under the Play category.
- Open Permissions for that forum. Start from Registered: post threads if you want self-serve listings, or revoke post and leave reply so only staff (or a “Server owner” group) can create the card.
- Give Moderating the right to edit others’ threads, change prefixes, and soft-delete. They will spend more time flipping Verified / Offline than writing posts.
- Confirm with a guest, a fresh Registered account, and a Server owner account. Guests should read. They should not see staff notes fields.
Two workable policies:
Self-serve + staff prefix. Anyone in Registered can create a listing. They cannot apply Verified. Staff apply Verified after a join test. This scales. The forum will contain junk. That is what Unverified is for. Filter the public homepage widget to Verified only.
Application first. Registered cannot post in the listing forum. They post in a separate “Request a listing” forum, or they wait for topic #6’s whitelist-style workflow. Staff create the listing thread. This is slower and cleaner. Use it when a fake server can steal logins or crash clients.
Never grant Registered the right to edit staff-only fields. A “Verified by” text box that the owner can type into is not verification.
Private the intake and the stolen-banner forum. A user who cannot view the parent will not see the children. That is still the official inheritance rule; do not try to hide a parent and then grant View on a child.
Keep the list from rotting
Stock XenForo will not ping a game server. The directory rots in three ways: the connect string changes, the invite expires, the owner disappears. Design for that.
Bump is the heartbeat. A discussion forum sorts by last post. Require a bump on a schedule you can enforce — every 14 days is enough for a hobby list, every 7 for a busy FiveM hub. A bump is a reply that says “still up,” not a new thread. Close or prefix Offline anything that goes quiet. Do not write a custom cron that you cannot see in the ACP.
Offline is a prefix, not a delete. People search for the old name. A Closed or Offline prefix plus a description is a tombstone. Hard-deleting a listing because the server moved is how you get a duplicate next week.
Verified expires. Re-join on a calendar. If staff cannot join, the prefix goes back to Unverified the same day. Write that rule in the forum description so owners stop arguing in reports.
One listing per community. Moderate duplicates by closing the newer thread and pointing at the original. Custom fields will not do this for you.
Attachments, not hotlinks. A banner loaded from an owner’s web host will vanish. If you allow a screenshot, it is an attachment on the first post. Keep dimensions in the rules so a 4000-pixel-wide splash does not wreck mobile.
No live player counts. If an owner pastes “200 slots, 180 online” in the body, treat it as flavour. Do not build a field for it. The moment you display a number next to the title, members will believe the board measured it.
Put the directory on the first screen, not on a second homepage
If the listing is the community, the forum list should say so. Dress the Play category like any other map: a short description, the right icons, Verified listings featured. The portal article is the first-screen decision. This article only cares that the directory is one of the rooms, not a parallel site.
Useful stock surfaces:
- The listing forum itself, with prefix filters. This is the directory.
- A Featured content widget (2.3) that pins one Verified thread above the node list. Feature by date, not by who paid. Do not feature Unverified.
- An HTML widget with three links: FiveM, Minecraft, Discord. Not a handwritten table of IPs.
- New posts in the sidebar so returning owners see bumps.
Do not set the index page route to a page that duplicates the forum. Do not install a magazine homepage whose featured row is the same three servers for six months. If the first screen’s job is “pick a server,” the map architecture is enough: index stays on the forum list, featured + HTML above the nodes.
Search forums belong in the tree as extra rows only when the saved search stays cheap — “Verified, last 30 days.” A search forum that tries to be “all EU Minecraft with whitelist” will disappoint if those facts live in fields the search cannot filter.
When Resource Manager is the better directory
XenForo Resource Manager is an official paid add-on. It is not hiding in 2.3 core. Install it from the same place you buy XenForo, then find it under Resources in the ACP and on the front end.
A resource is a catalogue entry with a description, not a discussion that happens to have fields. Categories are a tree, like nodes. Each category has Allowed resource types; a parent with no types is only a heading. Resource prefixes work like thread prefixes. Resource fields are the card: above the description, below it, on an Extra tab, or on their own tab named after the field. Each resource can automatically create a thread in a designated forum, with links both ways. Change that option later and existing resources keep the old behaviour.
Use XFRM when the listing is the artefact and the thread is the comments section. A curated partner programme, a short list of official servers, a file-plus-connect package — that is a resource. A noisy FiveM hub where half the value is “anyone online tonight?” is still a thread directory. XFRM will not query Minecraft. It will not expire invites. It will give you ratings, versions, and a UI that looks like a download site. Versions are a poor fit for a game server that does not ship builds. Ignore versions or abuse them as “season 4”; do not pretend they are protocol versions.
Permissions are new when XFRM lands. Confirm who can create resources, who can review, who can edit others. The installer picks reasonable defaults. They are not your policy.
Do not run XFRM and a thread directory for the same servers. Pick. Two catalogues is how members post in the wrong one and staff verify the empty one.
When an add-on is the right tool
Stock XenForo will not:
- Query FiveM, Minecraft, or Discord and paint an online lamp
- Sort by player count
- Draw a three-column card grid of banners
- Auto-expire a listing on a timer you set per thread
- Let a thread have two prefixes
- Filter the forum view by a custom field
If any of those is the product — a server browser that must look like the in-game list — you want an add-on built for 2.3, including style variations and the SVG icon system. Confirm it does not leak private node titles into cards. Keep a screenshot of the stock forum so rollback is not a database restore.
An add-on is not a substitute for a prefix policy. Cards of Unverified, Offline, and “test please ignore” are still those threads. Do the directory in stock first. Buy the query layer when owners are already bumping and staff are already flipping Verified.
This site used to sell a listing product. That product is not a requirement to have a directory. It is a reminder that the job is old and the board can do the unglamorous half without it.
FAQ
Can guests see connect strings?
If they can view the thread, they can see the status block. That is usually what you want. If a connect string is a secret, the listing is in the wrong forum.
Can I filter the forum by a custom field?
Not in the way you filter by prefix. Prefixes are the list filter. Fields are the card. If “EU” must be a tab, it is a prefix or a forum.
Should each owner get their own forum?
No. That explodes the node tree. One forum per game, one thread per community.
Do I need Resource Manager for a professional list?
No. XFRM is a catalogue with ratings and optional discussion threads. Use it when the resource is the page. Use a discussion forum when the conversation is the point.
Why not a suggestion forum so people can vote for servers?
Suggestion threads only live in suggestion forums and sort by vote. That is a contest. It is a bad directory. If you want a monthly “community choice,” run a separate suggestion forum and leave the directory as discussion.
Will extra.less cards replace this?
They will restyle the thread list. They will not add live data or a second prefix. Restyle after the fields and prefixes are right.
What about a whitelist application?
A prefix can mark “whitelist required.” The application itself is a different workflow — a form, a queue, a group change. Do not overload the listing thread with that form.
Do this afternoon
- On paper, write the three questions a stranger asks before they join. Those are your required fields. Everything else is optional or staff-only.
- In Forums → Nodes, make one Play category and either one Servers forum or one forum per game. Short URL portions. Staff intake hidden from the list and locked.
- In Forums → Thread prefixes, create the one dimension you will filter on. Staff-only Verified. Description on Offline. Applicable forums set. Require a prefix in practice even if you have to moderate the ones that skip it.
- In Forums → Custom thread fields, add the join fields. Display: thread status block. Applicable forums and editable groups set. No player-count field.
- Post one listing as a dummy owner. Open it as a guest and as Registered. Confirm the connect string is on page one and that Verified cannot be self-applied.
- Decide the rot rule (14-day bump, Offline after silence) and write it in the forum description. Feature one Verified thread on the first screen only after that rule has a staff owner.
A directory that tells the truth with six fields will beat a card grid that lies about who is online. Ship the truthful list today. Buy the query add-on when the list is already full.