MediaWiki Namespaces Explained

Every page on a MediaWiki installation belongs to a namespace. Namespaces are the fundamental mechanism MediaWiki uses to separate different types of content - encyclopedia articles from discussion pages, user profile pages from uploaded files, interface messages from templates. Understanding how namespaces work is essential for anyone administering, organising, or developing a MediaWiki wiki, because namespaces affect page URLs, search behaviour, access control, SEO indexing, and how content is counted in wiki statistics.

This guide covers all 18 built-in namespaces, explains the difference between subject namespaces and talk namespaces, and walks through how to create, configure, and apply access control to custom namespaces for your own deployment.

What Is a Namespace?

A namespace is a named prefix that categorises every page on a wiki. Every page title in MediaWiki follows the pattern:

Namespace:Page_Name

Pages in the Main namespace are the only exception - they have no visible prefix. A page titled Project Management in the Main namespace is simply accessed as Project_Management. A page titled Project Management in the Help namespace is accessed as Help:Project_Management.

The namespace prefix is part of the page's full title and its URL. It determines how the page behaves, which user groups can edit it, whether it appears in search results by default, and whether it is included in the wiki's article count.

Namespaces are not the same as categories. A category is a classification tag applied to a page's content. A namespace is the structural container a page lives in - it is part of the page's identity and location, not a tag that can be freely added or removed.

Why Namespaces Matter

Namespaces provide several practical benefits that become increasingly important as a wiki grows:

Content organisation. Namespaces create a clean structural separation between different types of content. Templates live in the Template namespace. Help documentation lives in the Help namespace. Discussion lives in Talk namespaces. This separation makes it clear to both editors and search engines what kind of content a page contains.

Access control. MediaWiki's namespace protection system allows different editing permissions to be set per namespace. An organisation can, for example, allow all staff to edit general content pages in the Main namespace while restricting edits to policy documents in a custom Policy namespace to administrators only.

Search behaviour. MediaWiki's built-in search only includes certain namespaces by default, and this is configurable. Keeping working notes, templates, and discussion out of the default search scope makes results cleaner and more relevant for readers looking for actual content.

SEO management. As covered in "MediaWiki SEO Best Practices", namespace-level robot policies allow entire namespaces - such as Talk and User - to be excluded from search engine indexing without having to noindex individual pages one by one.

Statistics and discovery features. The Special:Random page, the article count in Special:Statistics, and maintenance pages like Special:LonelyPages and Special:ShortPages only apply to namespaces designated as content namespaces. This prevents template pages and help documentation from inflating article counts or appearing as random content pages.

The 18 Built-in Namespaces

MediaWiki ships with 18 built-in namespaces. Each has a numeric ID and a PHP constant derived from its name.

MediaWiki Built-in Namespaces

ID	Constant	Name	Purpose
-2	NS_MEDIA	Media	Virtual namespace; used in wikitext links to media files (e.g. Media:File.pdf). Does not correspond to actual pages - it redirects to the file itself. Cannot be edited.
-1	NS_SPECIAL	Special	Virtual namespace for automatically generated special pages (e.g. Special:RecentChanges, Special:AllPages). Pages here are generated dynamically and cannot be edited directly.
0	NS_MAIN	Main	The primary content namespace. Pages here have no prefix. This is where encyclopedia articles, knowledge base articles, or general wiki content lives by default.
1	NS_TALK	Talk	Discussion pages for Main namespace content. Each Main namespace page has a corresponding Talk page where editors can discuss the content.
2	NS_USER	User	Personal user pages. Each registered user account has a corresponding User page (e.g. User:JohnSmith). Subpages are commonly used for user sandboxes and drafts.
3	NS_USER_TALK	User talk	Discussion pages for user pages. Messages left on a user's Talk page trigger a notification banner for that user on their next visit.
4	NS_PROJECT	Project	Site-wide documentation and policy pages. The prefix displays as the wiki's own name (e.g. SolidWiki:). Commonly used for about pages, style guides, and internal policies.
5	NS_PROJECT_TALK	Project talk	Discussion pages for Project namespace pages.
6	NS_FILE	File	Pages associated with uploaded files. Each uploaded file gets a File page displaying the file itself along with metadata and usage information. Also accessible using the legacy Image: prefix.
7	NS_FILE_TALK	File talk	Discussion pages for file pages.
8	NS_MEDIAWIKI	MediaWiki	Interface customisation namespace. Contains pages that control interface text, system messages, and site-wide CSS and JavaScript. Editing this namespace requires the editinterface permission, which is restricted to administrators by default.
9	NS_MEDIAWIKI_TALK	MediaWiki talk	Discussion pages for MediaWiki namespace pages.
10	NS_TEMPLATE	Template	Reusable wikitext blocks that can be transcluded into other pages using the Template:Template Name syntax. Templates are the mechanism behind infoboxes, navigation boxes, and standard notice banners.
11	NS_TEMPLATE_TALK	Template talk	Discussion pages for templates.
12	NS_HELP	Help	Documentation pages intended to help editors and readers understand how to use the wiki. Has no special technical functionality beyond the Main namespace.
13	NS_HELP_TALK	Help talk	Discussion pages for Help namespace pages.
14	NS_CATEGORY	Category	Category pages that automatically list all pages tagged with a given category. Created implicitly when a category tag is added to a page.
15	NS_CATEGORY_TALK	Category talk	Discussion pages for category pages.

Subject Namespaces and Talk Namespaces

Every subject namespace in MediaWiki has a corresponding talk namespace. The talk namespace's ID is always the subject namespace ID plus one - which is why all subject namespaces have even-numbered IDs and all talk namespaces have odd-numbered IDs.

This pairing has practical implications for custom namespace creation: every custom subject namespace must have an even ID, and its companion talk namespace must be assigned the next consecutive odd number. Assigning an odd ID to a subject namespace or an even ID to a talk namespace will create problems with how MediaWiki handles the subject-talk relationship.

When a user's Talk page is edited, MediaWiki automatically displays a notification banner to that user on their next wiki visit. This only applies to the User talk namespace (ID 3), not to other talk namespaces.

Virtual Namespaces

The Media namespace (ID -2) and the Special namespace (ID -1) are called virtual namespaces because they do not correspond to stored pages in the wiki's database.

Media (-2). A link using the Media: prefix (e.g. Media:Diagram.pdf) creates a direct link to the file itself, bypassing the File description page. This is useful when linking directly to a downloadable file rather than to the page describing it.

Special (-1). Special pages are generated dynamically by MediaWiki based on current database content. Examples include Special:RecentChanges, Special:Statistics, Special:AllPages, and Special:UserList. Special pages always output a noindex directive and cannot be searched or edited. Extensions can register their own Special pages, which also appear in this namespace.

Content Namespaces

Not all namespaces are considered "content" namespaces by MediaWiki. By default, only the Main namespace (ID 0) is a content namespace. Content namespace status determines:

• Whether pages appear when using Special:Random
• Whether pages are counted in the article total shown on Special:Statistics
• Whether pages appear in maintenance lists like Special:LonelyPages and Special:ShortPages

If a custom namespace is created to hold actual content - for example, a Policy namespace for company policies, or a Procedures namespace for step-by-step processes - it should be registered as a content namespace using $wgContentNamespaces. Without this, pages in it will not appear in random page links and will not be counted in the wiki's article total.

Step-by-Step: Creating a Custom Namespace

Custom namespaces are defined in LocalSettings.php before any extension loading lines. The order matters: if any extension needs to work with the new namespace, the namespace definition must appear above the wfLoadExtension() line for that extension.

Step 1: Choose a numeric ID. Custom namespace IDs must start at 100 or higher. MediaWiki's official documentation recommends using IDs starting at 3000 to avoid conflicts with IDs used by popular extensions. The subject namespace must have an even ID; its talk namespace must have the next consecutive odd ID.

Step 2: Define the constants. Add these lines to LocalSettings.php:

define( 'NS_POLICY', 3000 );

define( 'NS_POLICY_TALK', 3001 );

Step 3: Register the namespace names. Spaces in the display name must be written as underscores in the configuration:

$wgExtraNamespaces[NS_POLICY] = 'Policy';

$wgExtraNamespaces[NS_POLICY_TALK] = 'Policy_talk';

Step 4: Register as a content namespace (if the namespace holds primary content):

$wgContentNamespaces[] = NS_POLICY;

Step 5: Enable subpages (optional - subpages are not enabled on all namespaces by default):

$wgNamespacesWithSubpages[NS_POLICY] = true;

$wgNamespacesWithSubpages[NS_POLICY_TALK] = true;

Step 6: Include in default search (optional - controls whether the namespace is searched when a user runs a basic search without specifying a namespace):

$wgNamespacesToBeSearchedDefault[NS_POLICY] = true;

Step 7: Add namespace aliases (optional - allows editors to use a shorter or alternative prefix in wikilinks):

$wgNamespaceAliases['Pol'] = NS_POLICY;

After saving LocalSettings.php, the new namespace is immediately available. Pages can be created in it by navigating to yourdomain.com/wiki/Policy:Page_Name or by creating a link to Policy:Page_Name from any existing page.

Access Control per Namespace

MediaWiki's $wgNamespaceProtection setting restricts which users can edit pages in a given namespace by requiring a specific permission to be held by the editing user's group.

The following example restricts editing of the Policy namespace to users in the managers group, while allowing all authenticated users to edit its talk pages:

$wgNamespaceProtection[NS_POLICY] = [ 'edit-policy' ];

$wgGroupPermissions['managers']['edit-policy'] = true;

$wgGroupPermissions['*']['edit-policy'] = false;

The Talk namespace for a protected namespace is not automatically protected - it must be configured separately if needed:

$wgNamespaceProtection[NS_POLICY_TALK] = [ 'edit-policy-talk' ];

$wgGroupPermissions['managers']['edit-policy-talk'] = true;

$wgGroupPermissions['user']['edit-policy-talk'] = true;

Important limitation. $wgNamespaceProtection only restricts editing - it does not restrict reading. A user who cannot edit pages in a namespace can still read them. For wikis that need to restrict read access to specific namespaces, the Extension:Lockdown extension is required, since core MediaWiki does not support per-namespace read restrictions natively.

Namespace Configuration Reference

Key Namespace Configuration Variables

Variable	Purpose	Example Use
$wgExtraNamespaces	Defines additional custom namespaces with their display names	Required for any custom namespace
$wgContentNamespaces	Marks a namespace as a content namespace for statistics, random pages, and maintenance pages	Add custom content namespaces here
$wgNamespaceProtection	Restricts editing of a namespace to users holding a specified permission	Apply to sensitive or official-document namespaces
$wgNamespacesWithSubpages	Enables subpage support for a namespace (e.g. Help:Guide/Advanced)	Useful for hierarchical documentation namespaces
$wgNamespacesToBeSearchedDefault	Includes a namespace in search results when no namespace filter is selected by the user	Add content namespaces that should appear in general searches
$wgNamespaceAliases	Creates alternative prefix names that resolve to the same namespace	Useful for shorter aliases or maintaining legacy URL compatibility
$wgNamespaceRobotPolicies	Sets the search engine indexing policy (noindex, nofollow, etc.) for an entire namespace	Exclude Talk, User, and other non-content namespaces from indexing

Best Practices

Plan namespace structure before launching a wiki rather than adding namespaces incrementally after content has been created, because renaming pages across namespaces after they've accumulated links and backlinks is significantly more work than designing the structure correctly from the start. Always define custom namespace constants and registration in LocalSettings.php before any extension loading lines - extensions that interact with namespaces must see the namespace definition at initialisation time. Use IDs starting at 3000 for custom namespaces, since IDs in the 100–999 range are in active use by many popular extensions and collisions cause subtle, hard-to-diagnose problems. Always create a Talk namespace alongside every subject namespace, even if discussion pages are not currently planned - retrofitting a Talk namespace later is more disruptive than defining it from the start. Register any namespace that holds genuine content in $wgContentNamespaces so it is included in article statistics and random page features. Set $wgNamespaceRobotPolicies for Talk and User namespaces to keep them out of search engine indexes, as covered in "MediaWiki SEO Best Practices".

Common Mistakes

The most consequential namespace mistake is removing a custom namespace definition from LocalSettings.php after pages have already been created in it. Without the namespace definition, MediaWiki cannot resolve those page titles - the pages become effectively inaccessible, and the only path to recovery is restoring the namespace definition or manually moving every affected page. Never remove a custom namespace definition from a live wiki without first moving all content out of it. Assigning an odd ID to a subject namespace (or an even ID to a talk namespace) breaks the subject-talk pairing that MediaWiki relies on for discussion page linking and the new-messages notification system. Defining a custom namespace at a low ID (below 3000) without checking the extension namespace conflict list risks silent collisions with extensions installed now or in the future. Forgetting to register a content namespace in $wgContentNamespaces means its pages won't appear in Special:Random and won't be counted in the article total - a common source of confusion when a wiki's statistics don't match expectations. And using $wgNamespaceProtection to restrict a sensitive namespace and then assuming its content is private from unauthorised readers is a critical misunderstanding - protection restricts editing only, not reading.

Frequently Asked Questions

Can I rename a built-in namespace?

Yes. Built-in namespace display names can be changed using $wgExtraNamespaces by assigning a new name to the namespace's ID. The canonical English names remain in use internally for compatibility, but the displayed prefix on pages and in URLs changes to the name you specify.

Can I delete a namespace?

Not in the conventional sense - there is no "delete namespace" operation. Namespaces are created by defining them in LocalSettings.php. To retire a namespace, all pages in it should first be moved to another namespace, and only then should the definition be removed. Removing the definition without first moving the pages leaves those pages inaccessible.

Why do namespace IDs need to be even for subject namespaces and odd for talk namespaces?

MediaWiki calculates the talk namespace for any subject namespace as the subject ID plus one. If a subject namespace has ID 3000, MediaWiki expects its talk namespace to be at 3001. Giving a subject namespace an odd ID means MediaWiki would calculate an even ID for its talk namespace - which is inconsistent with the built-in pairing convention and will cause unexpected behaviour in discussion page links and notifications.

Does $wgNamespaceProtection restrict who can read a namespace?

No. It only restricts who can edit pages in the namespace. To restrict read access per namespace, the Extension:Lockdown extension is needed, since MediaWiki core does not provide per-namespace read permissions.

What happens if two extensions use the same namespace ID?

They will conflict. Pages intended for one extension's namespace will appear in the other's, and both extensions may behave unexpectedly. Before choosing an ID for a custom namespace, check MediaWiki's published list of namespace IDs already in use by popular extensions and select a number that is not listed.

Can a namespace be excluded from the wiki's search results?

Yes. The $wgNamespacesToBeSearchedDefault variable controls which namespaces are included in search results when no explicit namespace filter is applied. Setting a namespace to false in this array removes it from the default search scope, though users can still manually select it in the advanced search options.

How do I make VisualEditor available in a custom namespace?

Add the custom namespace ID to the $wgVisualEditorAvailableNamespaces array, as described in "MediaWiki VisualEditor Setup Guide".

Conclusion

Namespaces are one of MediaWiki's most important structural features, and one of the most underestimated by organisations setting up a wiki for the first time. A well-planned namespace structure creates natural boundaries between different types of content, gives administrators fine-grained control over who can edit what, keeps search results clean, and makes SEO management tractable at scale. A poorly planned one - or no deliberate structure at all - creates problems that become progressively harder to resolve as the wiki grows.

The key decisions are straightforward: identify the types of content your wiki needs to hold, decide which types warrant their own namespace, assign IDs starting at 3000, always pair subject and talk namespaces, and define everything in LocalSettings.php before the wiki goes live. Retrofitting these decisions later is possible but significantly more time-consuming.

For help designing namespace structure for a new wiki or restructuring an existing one, see SolidWiki's MediaWiki Development Services page.

See Also

• What Is MediaWiki?
• How to Install MediaWiki on Ubuntu Server
• MediaWiki SEO Best Practices
• MediaWiki Security Hardening Guide
• MediaWiki VisualEditor Setup Guide

External Links

• MediaWiki Manual: Namespace
• MediaWiki Manual: Using Custom Namespaces
• MediaWiki Manual: $wgExtraNamespaces
• MediaWiki Manual: $wgNamespaceProtection
• MediaWiki: Extension Default Namespaces (ID conflict reference)