User blog:FishTank/Categories and Navigation on 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.



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.

 Wikipedia links and rationale regarding these topics
 * Categories, lists, and navigation templates &middot; A navbox on every page &middot; Not everything needs a navbox

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.



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 ). 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.



Sidebars (sometimes called vertical navboxes) are navboxes similar to infoboxes in layout, and their functions are replicated in the  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.

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.

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!




 * Stockholm metro map by xyboi via Wikimedia Commons, CC BY-SA 3.0
 * Butchart Gardens image by Michael S. Shannon via Wikimedia Commons, CC BY-SA 4.0
 * Square-townsend-fledermaus.jpg by Velho via Wikimedia Commons, Public domain
 * 500px-Baseball_bat.svg.png by Gerald G via Wikimedia Commons, CC0