FANDOM


Wikis are full of information, and organizing that information leads to a better experience for readers exploring your wiki. Categories are a part of our communities that add grouping and association to pages. They’re also a very wiki-centric concept; as such, there is less general research available under that term, and we rely on more of the data Fandom collects to determine the Best Practices. For research purposes in the non-wiki world, the Category is most akin to a web model called “topic clusters”, but categories also have elements typical of tags (aka labels) common in blog posts.

Stockholm metro map

A subway system is a network of tunnels and trains, with organized groups of stops. This is similar to the navigational paths between wiki articles.

While there are many methods of moving between wiki pages, only a few show highly organized clusters of pages. The most common of those used for navigation, including Navboxes, can and should work together with categories. Like stops for a train, the network of articles can be grouped into clean lines and intersect to pass between tracks.

Why are we focused now on these long under-appreciated spaces? Fandom modified the typical function of Category pages in 2018, dramatically improving their search engine visibility and making them more important to our community organization. In short, Categories now hold as much weight or more as landing pages in search engine results as articles do, making them more ideal pillar pages.

In the topic clusters model, “pillar pages” are the areas where seekers land to find strongly related groups of articles. They signal to search engines that there’s a semantic (or meaningful) relationship between articles (or “cluster pages”). That’s a useful way to think of categories, too, for humans traveling through your wiki. Humans tend to think in linked concepts, rather than keywords. Placing related articles into a few good categories (and fewer bad categories) is a natural way of bringing those articles together conceptually.

Order from chaos

The term “topology” describes “the study of placement” or overall organization or map of items; in this case, a wiki’s topology is the map of articles within namespaces and categories. Every article — and realistically every page and category, even if they’re not articles — should be able to be reached from the root category and the Main Page. Fandom’s Mobile Main Pages and mobile apps were built with this concept in mind for drilling down through categories to reach articles via a tiled interface of category and article thumbnails. Once on the wiki, both navigation by link and search are equally valid ways of reaching pages, and a community should work to eliminate the orphaned and lonely pages that can’t easily be navigated to directly.

Butchart Gardens - Italian Garden

Categories should group similar things together, making them easier to find.

The root Category (under which all other categories should nest) should include the Main Page in its members, so that the drilling down action of navigation is possible. The default root Category is created on new wikis as “Browse”, due to technical limitations; it is a good practice to create and use the wiki’s name as the root Category, replacing “Browse”, as early in your wiki’s creation as possible. In order to make best use of a community’s infrastructure, it is also strongly suggested that the content of Main Pages (and Mobile Main Pages) link to fundamental or significant category pages. In other words, linking to Categories directly from your main page alongside other articles helps to reach the broader areas of your content. Category pages also provide the infrastructure that power the dynamic functions of the local community navigation bar.

Article pages should always belong to at least one primary Category. This Category is frequently assigned in the article’s infobox template, defining what class of entity a page represents (e.g. “Character”, “Episode”). Categories should not be confused with tags (popular in social media) nor semantic page properties. There are few good uses for a category like “Married Characters”, unless it’s a story focusing on marriage. It’s also good to avoid “Alive Characters” and “Dead Characters”, as those exploring your wiki might be at any point in the story where this state is not actually true. It becomes very easy to overload an article with categories that hold little relative meaning, association, or context. Categories such as “Characters who are 5’10″” should largely be avoided unless there is a strong use case and enough significance to write a paragraph that is true of all items in that category. We’ll be exploring good topology practices in an upcoming Best Practices post.

Categories used for maintenance functions should always be hidden from the general reader. It does not present a good impression if a non-editing reader can look at such a category and see all the articles that are flawed within your community. Instead, these otherwise hidden categories can be pointed to from the root category or an editor-centric page like Special:Community.

Category pages

Category pages, due to their search engine value on Fandom, should always contain a lede that is relevant and descriptive. Otherwise, the Category shows up in a confusing mess of code on search engine results pages (“SERPs”). The lede may be preceded by an infobox where appropriate, or an infobox acting in the role of a vertical navbox. The lede should be no less than one sentence and no more than three paragraphs (at which point it has reached maximum usable and valuable content). Immediately after the lede, you can also add a small navbox to convey a special order or relationship of pages.

A natural name of “Enemies in Final Fantasy IV” should be used for Categories over a comparable “Final Fantasy IV/Enemies”, as should “Season 4 episodes” instead of “Episodes/Season 4”. Natural language is more important for general discoverability, and use of slashes confuses and falsely conflates the concepts of subcategories and nested categories. Slashes are also interpreted in Google as a character, which can be a disadvantage in ranking.

To be clear

Disambiguation is a concept that Fandom users tend to misunderstand. For example, The Orville episode “Krill”, which (not exclusively) features the species “Krill”, understandably holds this information in two different articles. However, that does not justify the creation of a third disambiguation page "Krill (disambiguation)" when a simple note at the top of each article can do the job more effectively. You should only create a disambiguation page when the titles of several pages are identical (or nearly identical) and easily confused as to which is which. For two or three articles which require disambiguation, use a small note at the top of the page; these are commonly called “context links” or hatnotes on Fandom (and are formatted specially in the mobile skin). For more than three articles that require disambiguation, use a disambiguation page.

Long articles can also be hard to navigate. When a basic article becomes long enough, it could have long chunks that could reasonably be split into their own independent articles. For example, a character’s narrative in a television season could be placed into "Character/Season 1" with detailed plot points and spoilers in that article. The base article could then replace a long section with a spoiler-free summary with the most important points, linked by a context-link hatnote above it (such as {{Main|Character/Season 1}}). These subpages have a natural method to get back to the base article: they’re linked from the top of the page!

Navigation boxes and bars and beyond

Navboxes predate Categories on MediaWiki by several years. They typically present a flat horizontal block of text links inside a table cell, sometimes grouped by a labeled header cell. They are hidden in most cases on the Fandom mobile skin due to usability concerns, as they are on Wikipedia’s mobile skin and apps. Clustering links together in blocks is not finger friendly, and there are historically few good ways to lay these out on small, tall devices like mobile devices. Also, repeating the same exact block of code on multiple articles, particularly on short articles, detracts from their uniqueness and has a negative SEO effect.

Screenshot of Stranger Things Episodes navbox

A classic navbox

Sidebars (sometimes called vertical navboxes) are navboxes similar to infoboxes in layout, and their functions are replicated in the <navigation> tag of Portable Infoboxes. Usage in this manner is a good idea, as it provides mobile-friendly page switching in the “above the fold” area and consistently looks good on small screen devices. On desktop devices, this provides a consistency between the two user experiences and is preferred over tab navigation due to UI/UX concerns with tabs.

EraIcons (as popularized on Wookieepedia) are navigational links placed in the header area, for purposes of navigation between articles on another wiki (as is the case when two versions of a game exist) or namespace. The classic intrawiki example is navigation between alternate versions of the same character (Canon vs non-Canon, Television vs Book). This pattern also can be seen in rail navigational widgets on multi-game franchises (such as Final Fantasy Wiki, where they’re called “sideicons”). Navigation of this type is often ad-hoc and requires JavaScript and / or CSS to function properly, and as such does not always provide a consistently good experience on mobile. Further, many pages use tabs at the top of a page to navigate between subpage or alternative pages (such as /Gallery or /Transcript). Where feasible, all of these articles should present a consistent user navigation experience and interface inside their infoboxes, where they can be shaped reliably on all platforms; doing so provides a good user experience and should be strongly encouraged over ad-hoc solutions. An additional benefit of placing navigational links in a Portable Infobox <navigation> tag is that they signal search engine crawls as strongly related pages semantically.

Another alternative might signal appearances and inclusion via infobox data. For example, an infobox on a page for an “M16” weapon that appears in multiple games in a franchise might include an “Appearances” group, with a data / row label of the game title (linked back to the game page) and a link to the game-specific page for “M16” as the data / row value. This model can be applied to character and other appearances as well to strongly associate linked concepts.

M16 Infobox at Battlefield

A model of contextual linking in an infobox

Mapping a path for your readers

Between search, main pages, categories, careful use of navboxes, and crafty infoboxes, there are plenty of paths your readers can take to get around your community and see all your great work. Without structure, there’s no way to get through all of the content you enter in. Keeping things organized is always a best practice!



FishTank-100×100

Isaac Fischer Fandom Staff

Isaac rose from the ranks of Fandom contributors to join the Community Technical team in late 2015. He is now an Editor Experience Specialist, with a focus on User Education. Isaac is a television and book fanatic, a sucker for the great outdoors, and a lifelong learner. He's been coding since before attending school but didn't discover Fandom until 2010. Even now, he's hard-pressed to identify his favorite fandoms.
Want to stay up to date on the latest feature releases and news from Fandom?
Click here to follow the Fandom staff blog.

Interested in learning more about community management on Fandom?
Click here to view our community management blog.

Would you like insights on wiki building and usability?
Read through our Best Practices guides for keeping your community growing and healthy.
Want to get real-time access to fellow editors and staff?
Join our Official Discord server for registered editors!

Community content is available under CC-BY-SA unless otherwise noted.