MediaWiki SEO Best Practices

MediaWiki's architecture creates SEO challenges that don't exist on a typical CMS: the same article is often reachable through several different URLs, every page has a permanently indexable edit history sitting one click away, and namespaces like Talk and User generate large volumes of pages search engines have no real reason to index. None of this is a flaw - it's simply what a wiki engine does by design - but it means MediaWiki SEO is less about generic content advice and more about correctly configuring features that already exist in the software.

This guide covers the specific MediaWiki settings, extensions, and on-page practices that affect search visibility, based on MediaWiki's own technical documentation.

Why Wiki SEO Is Different

A standard website typically has one clean URL per piece of content. MediaWiki, by contrast, can serve the same article through its short URL, its raw index.php?title= query-string URL, and sometimes a mobile-specific URL, depending on configuration. Search engines treat near-identical content reachable through multiple URLs as duplicate content, which can dilute ranking signals and cause the wrong URL variant to appear in search results.

MediaWiki also auto-generates large numbers of secondary pages - Talk pages, User pages, revision history views, diff comparisons, and Special: pages - that have legitimate value to logged-in editors but little to no value as search results. Left unmanaged, these can outnumber actual content pages in a search index. The good news is that MediaWiki already handles part of this automatically, and the rest is controlled through documented configuration settings rather than custom development.

Core MediaWiki SEO Settings

Key Configuration Variables for SEO
Setting	Purpose	Default Behavior
`$wgEnableCanonicalServerLink`	Outputs a `<link rel="canonical">` tag on every page pointing to the preferred URL	Disabled by default
`$wgDefaultRobotPolicy`	Sets the site-wide default indexing policy (index/follow vs noindex/nofollow)	Defaults to allowing indexing and following links
`$wgNamespaceRobotPolicies`	Overrides the indexing policy for an entire namespace (e.g. Talk, User)	Not set; inherits the site-wide default
`$wgArticleRobotPolicies`	Overrides the indexing policy for individual, specifically listed pages	Not set
`$wgExemptFromUserRobotsControl`	Controls which namespaces allow editors to use the magic word on individual pages	Defaults to content namespaces, meaning editors generally cannot self-noindex main content pages without an administrator change
`$wgSitemapNamespaces`	Restricts which namespaces are included when generating an XML sitemap	Not set; all namespaces with content are included

Several of MediaWiki's indexing protections are not configurable at all because they're hardcoded into core: edit pages, page history views, diff comparisons, and most Special: pages always output a noindex,nofollow meta tag, regardless of any setting above.

Step-by-Step: Core SEO Configuration

Set up short URLs first, if not already done. Clean URLs (e.g. /wiki/Page_Name rather than /w/index.php?title=Page_Name) are both a ranking-relevant signal and the foundation the other steps below build on. See "How to Install MediaWiki on Ubuntu Server" for the short URL configuration steps.
Enable canonical links. Add the following line to LocalSettings.php:

$wgEnableCanonicalServerLink = true;

This tells search engines which URL variant of a page is authoritative, reducing duplicate-content dilution between the short URL and the raw query-string URL.

Set sensible namespace robot policies. Most wikis don't want Talk, User, or other non-content namespaces indexed. For example:

$wgNamespaceRobotPolicies = [
    NS_TALK => 'noindex,nofollow',
    NS_USER => 'noindex,nofollow',
    NS_USER_TALK => 'noindex,nofollow',
];

Generate an XML sitemap. MediaWiki ships a core maintenance script for this, so no extension is required:

php maintenance/run.php generateSitemap --fspath=/var/www/html/w/sitemap/ --server=https://yourdomain.com --skip-redirects

The --skip-redirects flag prevents redirect pages from appearing in the sitemap as separate entries, which avoids a common source of duplicate-content warnings in Google Search Console.

Automate sitemap regeneration with a cron job, since content changes over time and a stale sitemap loses most of its value:

0 3 * * * www-data php /var/www/html/w/maintenance/run.php generateSitemap --fspath=/var/www/html/w/sitemap/ --server=https://yourdomain.com --skip-redirects

Reference the sitemap in robots.txt. MediaWiki provides an on-wiki system message, MediaWiki:Robots.txt, that can be edited directly through the wiki interface to control robots.txt content without needing server file access.
Submit the sitemap to Google Search Console. This isn't strictly required for indexing, since search engines will typically discover the sitemap via robots.txt on their own, but it provides visibility into crawl frequency and indexing status.

Controlling What Gets Indexed

For individual pages that shouldn't be indexed - a draft article, an internal procedural page, or a duplicate of content that lives elsewhere - the magic word can be added directly to the page:

__NOINDEX__

This only works in namespaces listed in $wgExemptFromUserRobotsControl, and by default that list is the wiki's content namespaces - meaning, somewhat counterintuitively, that out of the box editors often cannot self-noindex a page in the Main namespace without an administrator first adjusting this setting. Pages carrying the magic word are automatically placed into a tracking category, which makes it straightforward to audit how many pages have been excluded from indexing at any given time.

For broader control, $wgArticleRobotPolicies can target specific named pages, while $wgNamespaceRobotPolicies (covered in Step 3 above) handles entire namespaces at once. As a general principle, namespace-level policy is the right tool for "this whole category of page should never be indexed," while the magic word is the right tool for "this one specific page shouldn't be indexed right now."

On-Page SEO for Wiki Content

Page titles. MediaWiki uses the page title as both the URL slug and the browser title by default, which is generally desirable for SEO, but title formatting (disambiguation parentheses, colons for namespaces) should be planned deliberately rather than left to accumulate inconsistently across the wiki.

Meta descriptions. MediaWiki core has no native per-page meta description field. The community-maintained WikiSEO extension is the most commonly used solution for adding custom meta descriptions, title tag overrides, and Open Graph data on a per-page basis. MediaWiki's own documentation specifically advises against auto-generating meta descriptions through an extension, since search engines are generally better at extracting a relevant snippet from the page content than a generic auto-generated description is - writing them manually, page by page, tends to produce better results.

Internal linking. Wikitext's native double-bracket linking (Page Name) makes internal linking low-friction by design, and dense, relevant internal linking between related articles is one of the more effective and least labor-intensive SEO levers available on a wiki, since it's a natural byproduct of normal editing rather than a separate task.

Categories. Categories function as a built-in topic-clustering mechanism. A well-organized category structure helps both human navigation and a search engine's understanding of how content is grouped, which can support topical authority for content silos.

Images. MediaWiki has $wgResponsiveImages enabled by default, which serves higher-resolution images to high-DPI screens automatically. Beyond that, uploading images in WebP format where supported (smaller file size than PNG or JPEG at comparable quality) and writing descriptive alt text on every meaningful image are both worth doing consistently, since image search is a real, if secondary, traffic source for many reference wikis.

Best Practices

Treat short URLs and canonical link configuration as day-one setup tasks rather than something to retrofit later, since changing URL structure after a wiki has accumulated external links and search engine indexing is far more disruptive than configuring it correctly from the start. Automate sitemap regeneration rather than running it manually, since a sitemap that silently goes stale provides a false sense of SEO coverage. Write meta descriptions and page introductions for human readers first; search engines consistently reward genuinely useful content over content structured primarily for crawlers. Periodically audit the noindex tracking category and namespace robot policies to confirm they still match how the wiki is actually being used, particularly after adding new namespaces or extensions. And keep an eye on thin or stub pages - wikis that allow large numbers of near-empty pages to accumulate can dilute average content quality signals across the site.

Common Mistakes

A frequent mistake is leaving $wgEnableCanonicalServerLink disabled while still allowing both short URLs and raw query-string URLs to resolve, which creates exactly the duplicate-content situation canonical links exist to prevent. Another is installing a meta-description extension configured to auto-generate descriptions from page content and never revisiting them, producing generic, low-value snippets across the entire wiki. Wikis sometimes also apply an overly broad $wgDefaultRobotPolicy of noindex,nofollow during initial setup for safety and then simply forget to relax it once the wiki is ready for public traffic, accidentally keeping the entire site out of search results indefinitely. On the opposite end, leaving Talk and User namespaces fully indexable by default allows large amounts of low-value, often unmaintained content to compete with actual articles in search visibility. Finally, treating sitemap generation as a one-time task rather than a scheduled job is a common and easily avoidable gap.

Frequently Asked Questions

Do I need an extension to generate a sitemap?

No. generateSitemap.php (or maintenance/run.php generateSitemap on current versions) is a core maintenance script bundled with MediaWiki itself; no extension installation is required.

Will enabling canonical links hurt my existing search rankings?

Generally no - canonical links are specifically meant to consolidate ranking signals that may currently be split across duplicate URL variants of the same content, which more often helps than hurts once correctly configured.

Can I noindex a single page without an administrator changing server settings?

Only if that page's namespace is included in $wgExemptFromUserRobotsControl. Many wikis don't include the Main namespace in that list by default, so an administrator may need to adjust this setting before the magic word will take effect on ordinary content pages.

Are Talk and User pages automatically excluded from search engines?

Not automatically - they follow the site-wide default robot policy unless an administrator explicitly sets a different policy for those namespaces using $wgNamespaceRobotPolicies.

Does MediaWiki support structured data or schema.org markup natively?

Not in core. Structured data typically requires an extension (such as those built on Wikibase) or custom skin/template work; it isn't part of MediaWiki's default output.

How often should the sitemap be regenerated?

This depends on how frequently content changes, but a daily cron job is a reasonable default for an actively edited wiki, and less frequent regeneration is fine for largely static reference content.

Conclusion

MediaWiki SEO is less about adopting unfamiliar techniques and more about correctly configuring capabilities the software already includes: canonical links to resolve duplicate URLs, namespace and per-page robot policies to keep low-value pages out of search results, a sitemap to help search engines discover content efficiently, and deliberate, human-written on-page elements like meta descriptions and alt text where the platform doesn't generate them automatically. Most of this is configuration work done once and then maintained, rather than an ongoing campaign - which makes it a reasonable, finite project for most organizations running a MediaWiki site.

For the broader technical setup these settings sit on top of, see "How to Install MediaWiki on Ubuntu Server," or for help implementing this configuration on an existing installation, see MediaWiki Development Services.

References

External Links