People do not return to a forum because the tree is complete. They return because something happened since yesterday in a room they already understand, and because the first screen shows that something without a scavenger hunt. Most dead boards fail the second half: eighty forums, twelve of them empty, a last-post column that has not moved in a month, and a new member who cannot tell which empty room is the one they were invited to.
This is an information-architecture article. It is about rooms, prefixes, tags, and return loops. It is not the XenForo node-painting guide — icons, extra.less, 2.3 variations. Paint after the tree is honest. It is not the stock XenForo engagement-hooks tour (What’s New, watches, thread types). Those hooks need a structure worth watching. It is not a migration essay; if the structure is the reason you want a new product, read the old-forum filters first. Changing software to escape an 80-node maze usually gives you an 80-category maze.
The rule that survives every platform: broad rooms plus markers (prefixes or tags) beat deep trees. XenForo community practice has been saying this for years on gaming and support boards. Discourse Meta says the same thing every time a phpBB migrant arrives with 200 forums. phpBB will let you ignore both and create another child board. That is how you got here.
What a return loop actually is
A return loop is a reason to open the site that is not “maybe someone replied to me.”
Three parts, in order:
- A room the member already belongs to. Not twelve rooms they might belong to.
- A first screen that shows motion. Last post, Latest, What’s New, a watched list — pick one primary.
- A marker that makes the motion scannable. Prefixes (
[Help],[EU],[Solved]), tags, thread types. Not another child forum.
If any part is missing, people lurk until they forget the password. Structure cannot invent replies. It can stop hiding the replies you already have.
Measure the loop with your own baseline, not with a benchmark this article will not invent:
- Second session in seven days
- Topics with at least one reply
- Posts in the two or three rooms you claim are “the community”
- Empty rooms that still appear on the index (count them; the number is the diagnosis)
If the busy room is busy and the index looks dead because of ghosts, you do not have an activity problem. You have a tree problem.
Why deep trees die
Deep trees feel like organization. They are usually anxiety. Someone saw a misplaced thread and created a more specific forum so it would not happen again. It happens again, one level down.
Empty rooms
A forum with three threads and a last post from 2019 is not a category. It is a vacancy sign. New members read vacancies as “this place closed.” Veterans stop checking the index because most rows are noise. Staff create another child to “give the new topic a home,” which adds a vacancy.
XenForo community practice is blunt: broad setups reduce cognitive load, minimize empty forums, and centralize conversations. Deep sub-node layouts force extra screens and produce misclassified threads — the thing you added children to prevent.
Permission cost (XenForo-shaped boards)
On stock XenForo, changing group settings or node-specific permissions rebuilds a permission cache. Complexity scales with user groups × nodes. Community reports on a medium board (on the order of 80 nodes and 60 groups) put a single primary-group change in the two-to-four-minute rebuild range. At hundreds of nodes, those rebuilds run into timeouts, PHP execution limits, and table locks — the site feels offline while you “just add a forum.”
Prefixes do not do that. A prefix is a field plus an index. It is not a permission domain. If you are creating a node so you can grant a different ACL, you have a real permission problem. If you are creating a node so the title can say “EU” or “unsolved,” you have a prefix problem you are paying for with cache rebuilds.
Discourse does not have that cache shape, but it has the empty-room shape. Forty categories with three topics each make Latest look like a junk drawer. The product is trying to show you recency. You gave it forty places to be empty in.
SEO waste
Broad taxonomies give crawlers a short list of living URLs. Deep trees give crawlers a long list of thin forum-index pages that duplicate each other. Community practice treats this as a crawlability win for the broad side. You do not need a case-study number. You can see it in Search Console: forum-index URLs with almost no impressions, thread URLs doing all the work. Keep the threads. Stop inventing indexes.
Misplaced threads anyway
Members do not read your 12-level map. They post in the room that is already open, or in General. Moderators then move posts for a living. A prefix move (or a tag edit) is cheaper than a forum move, and it does not leave a trail of “this thread was moved to a board you have never heard of.”
Broad rooms: how many is enough?
Enough is the number of conversations that have different audiences or different rules, not the number of topics you can name.
A working default for almost any community:
| Room | Audience | Why it is a room, not a prefix |
|---|---|---|
| Announcements | staff write, everyone reads | Different permissions. One-way. |
| The actual subject | everyone | The product. One room, many prefixes. |
| Support / Help (if you do support) | everyone | Different success state (an answer). Tags or prefixes for product / version. |
| Off-topic / Lounge | everyone | Different standard of “on topic.” One lounge. Not four. |
| Meta / Site | everyone | Talk about the site. |
| Staff | staff | Private. Not on the public index if you can help it. |
That is five or six. A gaming community might add Looking for group if LFG has different rules and a different lifespan than lore. A company might add Internal as a group-restricted category. A regional org might add Chapters only if chapters have different people, not different topics.
You should be able to say, for every extra room, who would be angry if we merged it into the room above. If the answer is “nobody, but the map would look incomplete,” merge it.
What must stay a room
Keep a separate room when at least one of these is true:
- Different readers. Guests must not see it. Donors only. Staff only. A game faction that is actually a private club.
- Different verbs. Announcements are not discussions. Tickets are not lounge. Applications are not show-and-tell.
- Different lifespan. LFG threads should age out. Lore should not.
- Different moderation. The NSFW line, the trading-rules line, the “no medical advice” line.
If none of those are true, it is a prefix or a tag.
What must not stay a room
- Version numbers (
Help / 2.2,Help / 2.3,Help / 2.3.1) - Regions (
EU,NA,OCE) unless they are legally or socially separate communities - Status (
Solved,Open,WIP) - Mood (
General,Off-topic,Misc,Other,Spam,Test) - Every game mode, every product SKU, every city
Those are markers. XenForo thread prefixes (with a required prefix on the forum if you must). Discourse tag groups with a minimum tag count on the category. phpBB prefixes if you have them; if you do not, one broad forum is still better than eight empty children.
Prefixes and tags are the rest of the map
Markers do three jobs the tree pretends to do:
- Filter. “Show me only EU LFG.” “Show me only unsolved.”
- Scan. A prefix in the title is visible on the index and in What’s New / Latest.
- Enforce. XenForo can require a prefix on thread create. Discourse can require a tag and restrict which tag group applies.
XenForo community practice for gaming hubs and product support: thread prefix filtering instead of another child node. Automated ACP rules can require the prefix. Computational cost is negligible next to a permission rebuild.
Discourse’s intended replacement for the child-board maze is the same idea with different nouns: few categories, tag groups, per-category required tags. A Support category that only accepts version tags is usable. A global soup of 200 user-created tags is not. For a new site, start with users cannot create tags. You can loosen later.
Do not build a marker for every old forum name. Markers answer “what is this about besides the room,” not “what was the phpBB forum id.”
A starter marker set:
| Group | Examples | Required? |
|---|---|---|
| Status (support) | Question, Solved, Bug, How-to | Yes, in Help |
| Platform / version | iOS, Android, 2.3 | Yes, if you support more than one |
| Region (if it matters) | EU, NA | Only if people actually filter on it |
| Type (main room) | Discussion, Show, Event | Optional; one default is enough |
If a marker has not been used in 30 days, it is a ghost. Delete it the way you would delete a ghost forum.
The first screen is the loop
Structure that nobody sees on session start is decoration.
Traditional index (phpBB, XenForo, MyBB). The index is the map. It only works if most rows moved recently. A last-post column full of 2019 dates trains people to stop looking. Hide or archive ghost forums until the index is a list of living rooms. One category heading, four forums, yesterday’s timestamps: that is a return loop. Two category headings, forty forums, mixed dates: that is a museum.
XenForo also gives you What’s New and watches. If your members already ignore the index, make What’s New the first screen and treat the index as a directory for the two times a year someone wants a directory. The engagement article owns the widgets. The IA job is: What’s New should not be 90% ghost-forum noise.
Discourse Latest. Recency is the product. Empty categories still pollute filters and the category page. They do not belong. Default notification on Announcements should usually be watching so the one-way room reaches people. Default on General should not mail the whole site. If veterans demand a last-post column, that is a product-fit signal, not a theme ticket.
Either product. A member who has to hunt for “what changed since Tuesday” will not hunt twice. Pick a primary first screen. Document it in the welcome topic. Do not give new users three homepages.
Return loops you can staff
Structure creates the slot. Staff have to put something in it. These loops work on every platform because they are calendar, not code.
The daily “what moved”
You need one place a returning member can scan in thirty seconds.
- Traditional: the two or three living forums, last-post column honest, ghosts gone.
- XenForo: What’s New filtered to those forums, or a search forum that is “active this week” if you use that node type.
- Discourse: Latest, plus watched categories. No empty children.
If you cannot keep that place honest, stop adding rooms.
The weekly open thread
A staff-started topic a stranger can answer without lore. “What are you working on?” “What broke this week?” “Show a photo of the bench.” Same room every week. Same prefix (Weekly). People return because they know where Thursday lives.
Do not invent a new forum called Weekly. That forum will be empty six days.
The status loop (support)
Help rooms die when solved and unsolved look identical.
- XenForo: prefixes, or the question thread type, plus a search forum of unanswered questions if you want that row on the index.
- Discourse: official Solved plugin if you use it; a
solvedtag is a weaker substitute you will forget to apply. - phpBB: a prefix and moderator discipline.
The loop is: I posted a problem → I can find it → I can see it is still open → I come back when it is not. Structure without a solved marker makes every return visit a reread of the whole room.
The watch / follow loop
A room nobody watches is a bottle with no mail slot. Explain watches once. Set Announcements to watching for new users if you want a broadcast. Do not silently watch every forum — that is how you train people to ignore notifications, which breaks the loop you were building.
The “something happened to my people” loop
Factions, chapters, cohorts: they return because their room moved. This is the exception to “merge everything.” A private faction forum with daily posts is a loop. A public Factions / Red / EU / Casual / Overspill tree is four vacancies and a permission rebuild. Prefer one faction room plus prefixes, or a private room per real group of humans, not per mood.
Worked maps
A hobby photography community (any platform)
| Room | Markers | First screen |
|---|---|---|
| Announcements | none | watching |
| Critique | prefix: Portrait / Landscape / Film | What’s New or Latest |
| Gear | prefix: Buy-sell / Question | same |
| Lounge | none | same |
| Staff | — | hidden |
Five rooms. “Canon / Nikon / Sony / Fuji” are prefixes or tags, not forums. A “Canon 5D archive 2014” child is how the index dies.
A product support community
| Room | Markers | Notes |
|---|---|---|
| Announcements | none | staff only to create |
| Support | required: Product, Version, Status | Solved must be visible |
| How-to / Knowledge | prefix: Guide | staff + trusted; or a docs pattern |
| Feature ideas | prefix: Idea / Planned / Shipped | one room |
| Staff / Internal | group-restricted | not on the public map |
If you have four products, you still have one Support room. The product marker is the filter. Four product forums each with their own “solved” child is sixteen ways to be empty.
A game community that insists it needs 40 forums
It does not. It needs:
- Announcements (patch notes live here, not in Discord-only)
- Play (LFG, prefix: Region + Mode)
- Lore / Stories (if people actually write them)
- Support / Tech
- Lounge
- Staff
- Private rooms for groups that are really groups (a faction that recruits, a staff-only rules room)
Server listings, whitelist applications, and character sheets are products, not prefixes. They may justify XenForo and they do not justify forty public children. If those products are load-bearing, the migration filter may say stay on a traditional platform. Structure still says: one LFG room, not LFG → Game → Region → Mode → Mic-only.
How to flatten without a civil war
You already have the bad tree. Do not delete it on a Sunday and tweet “we simplified.”
- Count 30-day posts per room. The empty ones are the candidates. Numbers, not opinions.
- Interview five members the same way the migration article does: “If you wanted to ask X, what would you click?” If they already search, they will survive a flatten.
- Announce a map, not a deletion. “These six rooms remain. These prefixes replace the children. Old threads stay readable.”
- Move, then hide. Merge or move threads into the surviving room. Prefix them as you go if you can do it in bulk; if you cannot, prefix going forward and leave history messy. Hidden / archived children can keep permalinks alive.
- Leave a stub. A locked post in the old room: “This forum is archived. New threads go to Play with the EU prefix.” Traditional software can keep the row as a link forum or a redirect. Discourse can lock and redirect the category or just un-list it.
- Do not flatten Staff, private factions, or legal walls. Those were never prefix problems.
- Watch the two weeks after. If a prefix is unused, it was a vanity marker. If a merged room becomes unreadable, you needed two rooms after all — split once, with a reason.
If you are about to migrate, flatten before the import. Discourse stock importers already flatten depth beyond two levels into tags on the nearest subcategory. You will understand the result better if you chose the tags.
Platform notes (only where the nouns differ)
XenForo. Nodes are the tree. Prefixes live on forums. Search forums can display a filter (unanswered, a prefix) without being a permission domain. Private node + group Yes is how you hide Staff. Do not create a node to change a color; that is the painting article.
Discourse. Categories are few. Tags do the rest. Category security is hierarchical — do not add every trust level. Latest is the first screen whether you like it or not. A category that exists “for completeness” is a smell.
phpBB. You can still do this. Broad forums, prefixes if available, hide empty forums from the index, stop adding children. A flatten on phpBB is cheaper than a migration you wanted because the index looked busy in 2012.
IPS. Clubs can isolate new people from the only lively room. Do not put the return loop behind a club they have not found. The rest of the broad-room rule still applies.
Cross-platform discipline XenForo community practice also names, because it affects whether people speak in the rooms you built: do not casually post as the root Admin account. The Admin handle is for announcements and structured warnings. Humans use a personal profile without a giant staff badge. Members will not argue with a god. Rooms without argument do not need a clever prefix. They need a human.
What structure will not do
It will not create the first ten members. That is the founding calendar. It will not onboard a person who already joined. That is the member 30-day plan. It will not replace watches, mail, or a staff reply budget. It will not make Discourse feel like a last-post column. It will not make XenForo feel like Latest unless you send people to What’s New.
It will also not save a community whose only living room is Discord. If the forum is an archive, flatten it into an archive on purpose. An honest archive is a kinder index than forty rooms you have not posted in since the server launch.
Takeaways
- Return loops need a room people belong to, a first screen that shows motion, and a marker for scan/filter. Deep trees break all three.
- Broad rooms plus prefixes (XenForo / phpBB) or tags (Discourse) beat child boards. Empty rooms are vacancy signs.
- On XenForo, extra nodes are extra permission-cache work. Prefixes are not. Community reports put medium-board rebuilds in minutes, large trees in timeout territory.
- Keep a room only for different readers, verbs, lifespan, or moderation. Versions, regions, and “solved” are markers.
- Flatten with counts, a public map, moved threads, and stubs that protect permalinks. Flatten before you migrate.
- The first screen is part of IA. An index of ghosts is not a map. Latest plus empty categories is not a stream.
If you cannot explain the map in one screen to a stranger, it is not a map. Delete a room before you add a style.