Categories vs. tags for “content type” vs. “subject matter” — what are the right URL patterns?

Community
1

Hi all — looking for guidance on structuring our Discourse since if we take approach -Option 1 , we will have 1200 categories when we have 3 level of categories (L1-L2-L3) and if we eliminate L3, we have around 150 categories with L1 & L2

Context
We publish several content types (questions, discussions, how-tos/articles, events, jobs, bulletins) across different subject matter. Think examples like:

  • Topic Areas (L1): Cooking, Photography
  • Subtopics (L2): Italian (under Cooking), Portrait (under Photography)
  • Focus (L3): pasta, sourdough, lighting, composition

I’m torn between two approaches and would love best-practice advice.

Approach A (subject matter = categories, content type = tags)

  • Categories

    • L1 (Topic Area): cooking, photography
    • L2 (Subtopic): italian, portrait
    • (Question) Should we add a 3rd level category for “Focus” (e.g., cooking → italian → pasta) or keep the tree shallow and model Focus as tags instead?

  • Tags

    • Required content-type tag (exactly one): question, discussion, how-to, event, job, bulletin
    • Optional/required focus tag: pasta, sourdough, lighting, composition, …

URL patterns (Approach A)

  • Pre-filled composer (L2 + type + optional focus):
    /new-topic?category=cooking/italian&tags=question,pasta
  • Category filtered by one tag (e.g., “Questions in Italian”):
    /c/cooking/italian?tags=question
  • Tag intersections (AND) (site-wide, e.g., “pasta + question”):
    /tags/intersection/pasta/question
  • Category + multi-tag (use Advanced Search):
    /search?q=category:cooking/italian%20tags:pasta+question

Questions for Approach A

  1. Is the recommended practice to avoid a 3rd category level and keep “Focus” as tags?
  2. Any gotchas with category pages only supporting one ?tags= filter (needing Advanced Search for multi-tag in a single category)?

Approach B (content type = categories, subject matter = tags)

  • Categories: top-level (or a few) for Questions, Discussions, How-tos, Events, Jobs, Bulletins.

  • Tags (three groups for subject):

    • Topic Area (e.g., cooking, photography) — limit one
    • Subtopic (e.g., italian, portrait) — limit one
    • Focus (e.g., pasta, lighting) — 1 required (or optional)

URL patterns (Approach B)

  • Pre-filled composer (type category + subject tags):
    /new-topic?category=questions&tags=cooking,italian,pasta
  • Browse a type by subject (e.g., Questions about Italian):
    /c/questions?tags=italian (multi-tag + category → Advanced Search)
  • Site-wide subject intersections (independent of type):
    /tags/intersection/italian/pasta

Questions for Approach B

  1. Does splitting content across “type” categories make subject browsing harder?
  2. Any pitfalls with requiring multiple tag groups (Topic Area + Subtopic + Focus) per topic?

Cross-cutting questions

  • Best practices today: Keep a shallow category tree (1–2 levels) and push detail into tags?
  • When is a 3rd category level justified? Only for truly high-volume Focus areas that need separate permissions/landing pages?
  • Feature scoping: If we enable Solved/Voting, is it better to scope them at subject categories in Approach A, or at “Questions” categories in Approach B?
  • Composer UX: Are pre-filled composer links (/new-topic?category=...&tags=...) still the preferred way to guide authors?
  • Search UX: Any newer patterns for category + multi-tag filtering (beyond Advanced Search) we should know about?

Thanks in advance for pointers, examples, and “what worked for you”!

1 Like
2

I think the answer depends a bit upon your expectations for how much the different subject matters within your community appeal to a given member.

Do you expect a lot of overlap between the groups that discuss photography and cooking? If so, tags for these different subjects probably works well.

Or are you trying to serve multiple sub communities – one for cooking, and one for photography – within the same site? If so, you may prefer categories for each.

I’m going to make an assumption that you’re talking about a single community first, where people may together discuss many subjects.

My suggestion would be to start with something more like Approach B.

Having different categories for the different types of content will enable you to more clearly signal what kind of discussion it is, and what the expected behavior is of the participants. You can take that further in some cases by configuring the categories for those purposes (e.g. using the solved plugin for a Q&A category).

Then, lean first on tags for the subject matter. That gives you the freedom to apply multiple tags to discussions when there is overlap (photos of cooking!).

If, at some point, you observe it’s helpful to more clearly divide some subject matter from others, you can use the tags to help recategorize things.

I’m general, we recommend fewer categories, rather than more, especially when starting out, and a shallower hierarchy rather than a deep one. By default we only support two levels of depth. You have to go out of your way to turn on support for a third.

I don’t know that people heavily use URLs to prefill the composer. I can imagine it being useful in some scenarios but I would suggest leaving that idea aside until you find a need for it.

For discovery, something else to check out is the /filter page, which lets you construct more custom topic lists, which you could configure in your sites sidebar: Filtering topic lists in Discourse

1 Like
3

Thank you, Mcwumbly. I realize my earlier question didn’t set the full context—it was a bit tricky to articulate. Here’s additional background to frame our use case and user expectations: we’re building a forum in the following context:

(Food-only niche forum to illustrate the structure)

1) Subject Matter (three levels; can be categories or tags)

  • L1 = Cuisine — Italian, Caribbean, Indian, Mexican
  • L2 = Focus — examples: pasta (under Italian), tacos (under Mexican), chaat / tandoori (under Indian)
  • L3 = Micro-focus — techniques/dishes/ingredients, e.g., extruded-pasta, naan, guajillo, sous-vide

Reality of use: About 70% of posts happen at L2 (Focus) combined with an L3 (Micro-focus).
• If L3 is a category, the topic is posted in L3.(important note here we will have L3 categories considerable higher name when compared to L2 and L1)
• If L3 is a tag, the topic is posted in L2 with the L3 tag attached.

2) Content Types (cross-cutting; can be categories or tags)

Each topic type needs a distinct composer form:

  • Question → Problem • What I tried • Environment • Expected vs. Actual
  • How-to / Article → Prereqs • Steps • Verification • Gotchas
  • Event → Start/End • Timezone • Location/Link • RSVP
  • Job → Role • Location/Remote • Requirements • How to apply
  • (Plus) Discussion

3) Open decision (mirrors the enterprise case)

  • Should Cuisine / Focus / Micro-focus be categories (with tag helpers) or tags (with a shallow category layer)?
  • Should topic types be categories (easy per-type templates) or tags (keeps Cuisine/Focus as the primary “place”)?
  • With 70% of activity at Focus + Micro-focus, which option best preserves strong Focus landing pages while keeping the IA simple?

Summary of our constraints & goals (applies to both versions)

  • Keep navigation intuitive where users actually spend time (L2 + L3)…how we still need to give some context here (reference of L1 whether it is italian or mexican-where post is done from breadcrumb stand point or SEO stand point )
  • Avoid unnecessary category bloat, but still provide clear “home bases” for heavy-traffic subjects.
  • Enforce exactly one Content Type per topic and support subject intersections (e.g., Software + Technical Area, or Cuisine + Focus).
  • Ensure the right composer form appears for each Content Type, regardless of whether types are modeled as categories or tags.

We’re looking for guidance on which modeling choice (categories vs. tags for Subject Matter and Content Types) best fits these constraints, given that most engagement happens at L2 + L3 with different content type with different forms for each content type.

1 Like
4

I think to give you the best answer possible here, getting even more into your specific context would be necessary. I would want to probe further into the your particular subject matter, the different user personas in your community, how confident you are in their needs and behavior, whether you already have an active community, and if so, how large and active it is, etc.

In lieu of that, we’re generalizing, of course, and the advice you get may or may not be the best fit for you.

That said, given what you’ve shared so far, I think I would approach things this way:

  1. Create categories only for the use-cases at first (questions, events, etc); Use tags for the subject matter
  2. As subcommunities emerge that need their own space, create a top level category for them, create a top level “subcommunities” category (name of your choosing) and create subcategories for each of them – within these, there wouldn’t be use-case categories. The assumption is that these are more freeform discussions among emerging tightknit groups, who may be going deeper into a subject together while continuing to contribute in the other top level categories
  3. If those subcommunities grow to the point where they need their own use-case based categories, promote them to top level categories and duplicate the use-case based subcategories within them (questions, events, etc); nest the initial set of categories under a more general top level category to represent the “main” community.
  4. Continue to use tags to connect content across all these categories by subject matter
1 Like
5

Thank you Mcwumbly for your reply and it made sense to factor others as well to decide the approach. we kind of got the approach factoring mental model flow and discourse suggested way of working.

1 Like