The SEO Abilities of MediaWiki and the .Wiki TLD
We fix search problems for a living at The Discoverability Company, which means we spend a lot of our time and resources finding out what actually works before we sell it to anyone. Some of it becomes client work. Some of it becomes a post like this one.
Either way, it's my favorite part of the job.
I'm thrilled to share our findings after we built fourteen MediaWiki sites across two TLDs, .com and .wiki, on the same pipeline, with the same team. Half the thesis worked. The other half cost us real money and about nine months. Every number here comes from our own properties.
The sites are ours, so the data is complete. I'm not naming them. What they're about matters to the results, which are clear and offer meaningful points on a few questions.
What we already knew
The last few years of SEO and AI visibility have been about structured data. The logic is simple once you look at the incentives. Claude, ChatGPT, Gemini and the agents being built on top of them have the nearly-impossible task of scraping and understanding the entire internet.
That is an expensive effort.
So it's only natural that a site that arrives pre-structured is cheaper to read, cheaper to trust and cheaper to return as part of search results than one that has to be reverse-engineered.
That's why schema markup is still one of the highest-return things you can do in 2026. The effect isn't subtle.
So we asked the next question. Schema is table stakes. What else signals structure to a crawler? What looks at a domain and says: this site is organized, come here first?
The two hypotheses
Two of them were worth spending real money on.
One: MediaWiki is a CMS that crawlers prefer
MediaWiki is the open-source platform that runs Wikipedia. Anyone can download it and install it for free, and it ships with the exact structures that matter. Dense internal links. Category trees. One entity per page. Clean canonicals. A well-run install is a machine for declaring what a page is about and what it relates to.
Our test: fourteen domains, registered through Cloudflare. Three on .com, eleven on .wiki. Some geographic, like city and regional guides. Others thematic. All MediaWiki. All built by the same team, on the same pipeline, to the same standard, and all measured the same way on the same days with the same tools.
We launched the flagships in late 2025 and the city sites early in 2026. We did keyword research up front, kept generated-content scores low, improved pages continuously and ran light link building. The goal was a resource people would use, per Google's own guidelines.
Two: the .wiki TLD is itself a signal
A domain that says what it is. Cheap structure at the registrar.
This has long been the subject of some debate. Google's position is that TLD isn't a ranking factor: John Mueller has said it for years, and Google published its own Q&A on handling new top-level domains saying the same. Bill Hartzer's research argued the other way, that a new gTLD can rank perfectly well and that domain choice moves outcomes. Reputation datasets show some new gTLDs carry extreme spam density, which is one way a TLD acquires a trust problem without any explicit rule ever being written.
Our design: same software, same team, same pipeline, same standards. Split across .com and .wiki. Measured separately on Google, Bing and everything else. As close to a controlled test as the open web allows.
How we measured it
Of the pages we built, what share did the engine take? That ratio is the study.
It's the first question when you put up a new domain. Ranking is a fight you can only have once you're in the index. Everything below is judged by that ratio, measured per site, per engine and by approach.
Result one: a properly configured MediaWiki is a rankings machine
One caveat before the good part. Getting a MediaWiki install properly configured is most of the work, and it is not fun work. MediaWiki is not WordPress and it isn't friendly. The extension ecosystem is thin. Everything is high-touch. A meta description edit could break a page's layout until you cleared the parser cache. Links drift. Templates rot. We rebuilt pieces of these sites constantly, on every domain, on both TLDs.
The community earns the credit it gets. The MediaWiki project and its subreddit are one of the friendliest corners of open source I've run into. Several fixes in this post exist because of them.
When it's dialed in, crawlers love it. Our standout is Site A, a thematic aggregator on a .com. The subject area had plenty of information available, but it sat scattered across siloed sources. One site would cover a single facet. Another would cover two. Nobody assembled the whole picture. We assembled it, with clean internal links and real outbound attribution to the sources we drew from.
Google took all of it. Every one of the 470 pages, plus the category and list pages the software generates on top of them, 525 URLs in all. 216,993 impressions and 11,592 clicks last quarter at an average position of 18.7. This far out-paced the pickup and horizontal coverage that we see in similar sites launched on WordPress.
Result two: don't put that MediaWiki on a .wiki TLD. Google hates it.
Here is the flagship comparison. Same software. Same team. Same pipeline. Site B is a reference wiki on a .wiki, built out to eleven times the size of Site A, on a domain registered about twenty-one months later.
| Site B (.wiki) | Site A (.com) | |
|---|---|---|
| Pages built | 5,681 | 470 |
| Google: URLs indexed | 2 | 525 |
| Google: indexation rate | 0.04% | 100% |
| Bing: URLs indexed | 57 | 1,520 |
| Referring domains | 277 | 154 |
| Total backlinks | 888 | 838 |
| Google: impressions, 90d | 318 | 216,993 |
| Google: clicks, 90d | 2 | 11,592 |
| Average position | 8.7 | 18.7 |
Site B has 5,681 pages. Google has indexed 2 of them. It has the stronger link profile of the two sites. It didn't matter.
Run that ratio across all fourteen and the split is not subtle.
Across the ten .wiki domains where Google returns a total, we built 22,459 pages. Google took 1,112 of them. Just under 5 percent. The three .coms, running the same software, came in at 71, 84 and 100.
The links say it isn't the links
Here is the part I keep coming back to.
Site B has the strongest link profile of any site in the study: 277 referring domains and 888 backlinks. It has two pages in Google. Site M has a third of those referring domains and a seventh of the backlinks, and 71 percent of its pages are indexed. Site N sits between them on links and lands at 84 percent.
| Site | TLD | Pages built | Referring domains | Backlinks | Google indexed |
|---|---|---|---|---|---|
| Site B | .wiki | 5,681 | 277 | 888 | 0.04% |
| Site A | .com | 470 | 154 | 838 | 100% |
| Site N | .com | 7,129 | 109 | 298 | 84% |
| Site M | .com | 10,088 | 89 | 128 | 71% |
The best-linked site in the study is the worst indexed, by three orders of magnitude. The two thinnest link profiles are on .coms indexed above 70 percent, one of them carrying 10,088 pages.
Links are the lever everyone reaches for when a site won't index, and here they ran backwards. Whatever Google is weighing before it decides to crawl a domain deeply, authority as we usually measure it isn't doing the work. The TLD is the variable that moves with the outcome.
What we tried
This wasn't for lack of trying. We pulled every lever we had. Internal link restructures. Rewrites. Schema. Sitemap resubmissions. URL inspection and requested indexing, page by page, on the ones we cared about most. On a few of the domains we paid third-party indexing services, which is not something I enjoy doing, but I wanted the answer more than I wanted to be precious about method.
None of it moved the rate.
And to be clear about one thing: there is no manual action on any of the fourteen domains. Search Console is clean on every one of them. No manual actions, no security issues, no spam notices, nothing sitting in the message center. No warning, no flag, no explanation. The pages simply don't get taken.
Bing disagrees. Completely.
The same .wiki domains that Google starves, Bing indexes by the ten thousand. Site C: 6.4% of its pages on Google, and a Bing Webmaster Tools count many times its own page count. Site D: no Google total, about 18,000 URLs on Bing against 2,140 pages built. Site L: 13.3% on Google, fully indexed on Bing.
The traffic follows the indexing. Last quarter Site B received 3,994 visits total. Google didn't make its top five referrers. DuckDuckGo sent 1,312. Bing sent 1,229. Site C received 2,831 visits: DuckDuckGo 1,240, Bing 896, Yahoo 433, Google 56.
Eleven .wiki installs, between 1,765 and 5,681 pages each, built to the same standard as the rest. Combined Google clicks last quarter: 123. The three .coms: 43,589.
Same pages, same markup, same team. The only variable the two engines are reading differently is the domain itself.
What I think is happening
It's not a penalty, which is the part I didn't expect. What I'd been bracing for was a manual action, or a Search Console sanction for scaled content abuse, on domains publishing at this volume. Nothing like that ever arrived.
The slivers Google does index from these domains rank fine. Site D's average position is 7.9. Site B's is 8.7. Site I sits at 11.2. Google treats the handful it takes perfectly well. The problem is the size of the handful.
This looks like a crawl budget decision. A trust throttle. Google indexes the front door of a .wiki domain and holds back the rest until the domain earns belief, and nothing we did moved that clock. Bing weighs relevance more directly and simply indexes the pages.
The obvious explanation, spam density, doesn't fit. alphaMountain's reputation data, measured 15 May 2026, puts the worst TLDs at .xin with 85.1 percent of domains flagged risky, .bond at 81.6 and .buzz at 77.3. .wiki does not appear in it. .com sits well under 10. If abuse rates per TLD drove this, .wiki would be fine.
What's left is priors. A .com arrives with two decades of accumulated trust patterns. A freshly registered .wiki arrives with none, and links don't appear to buy them. We proved that by accident: the .wiki with the stronger link profile still lost, badly.
Conclusions
- MediaWiki is worth it. The structure is exactly what crawlers reward, and on a .com it got us full indexation faster than the same team gets on WordPress. Budget for the maintenance. It never stops.
- Don't build on .wiki. The TLD isn't banned or spammy, and there's no manual action on any of these domains. What we see is Google withholding crawl budget. An indexation rate under 5 percent means no long tail, no long tail means no impressions, and links don't fix it, which the link table shows plainly. Bing rewards the same sites well. That traffic is real, and it's smaller.
- Signals only work on a domain the crawler already believes. That's the lesson underneath the structured-data thesis. A .wiki domain tries to tell Google what the site is, and Google has no interest in being told by a domain it has no history with.
Limitations
This is one operator, one CMS, fourteen domains. The pattern is consistent enough that I'd build on it. It isn't a census. It is the second time I've run a publishing network at volume to find out what the gatekeepers let through, and the first one, five months of AI-generated local news sites and paid placements, ended somewhere similar.
This is correlation. We can show the engine differential and what survived our controls. We can't see inside the ranking systems.
And we have a commercial interest in looking like people who run these experiments. That's why the tables came first.
If you want to do this yourself
MediaWiki lives at mediawiki.org, and the subreddit is one of the nicest places in open source. Expect the configuration to fight you. Budget accordingly.
The rest of what I've written on search, discoverability and startup failure is on the blog, and the patterns behind the failures sit alongside it.
If you want a wiki of your own, or want to know what your domain is signaling to crawlers, that's what The Discoverability Company does. This is the kind of test we run before anyone pays us for the answer.
Methodology. Clicks, impressions and average position: Google Search Console, 90 days ending 2026-09-12, plus its manual actions and security issues reports for all fourteen properties. Google index counts: site: queries run through SerpAPI on 2026-09-15. Bing index counts: Bing Webmaster Tools. Backlinks and referring domains: DataForSEO, September 2025. Visits by referrer: Umami, self-hosted, same 90-day window. Page counts: each site's own MediaWiki database, read from its Special:Statistics. Indexation rate: indexed URLs divided by pages built, capped at 100%, so a site at the ceiling had every article taken and in several cases more URLs than articles once category and list pages are counted. Every site in the study is one of ours. The labels are anonymized and every figure is unchanged.