Published 19 May 2026 — by Andrii
The 14% came back in February 2026 and I didn't see it coming. That's the part of this story I wasn't going to write about publicly, because it's embarrassing to admit that after 18 months of methodical work taking traffic from a declining platform, a chunk of it reversed without me doing anything wrong. Google adjusted something at the entity association layer and Fandom got positions back that they had no business getting back based on content quality alone.
I'll explain exactly what happened, why I think it happened, and what I'd do differently knowing what I know now. But first: the 38% gain is real, documented, and came from specific technical and content decisions rather than from Fandom collapsing on its own. They are declining — their ads situation is genuinely bad and their Core Web Vitals scores on mobile are what you'd see on a site that decided user experience was someone else's problem. But "declining giant" is not the same as "easy to beat." Nothing about this was easy.
How Fandom Is Actually Declining (It's Not What You Think)
Fandom's problem is not that their content is bad. On many pages — particularly for major franchises with active editing communities — the content is genuinely comprehensive and frequently updated. That content is not what I was competing against. Nobody wins against a well-maintained Fandom wiki page on a major franchise character in 2026. The entity association depth, the community contribution scale, and the historical link equity make that a losing fight.
What's declining specifically: long-tail pages. The stub articles, the minor character pages, the location pages for things that don't have dedicated fan communities anymore, the pages on games or shows whose communities peaked in 2018 and have since scattered. Fandom has millions of these. They were written during the fanbase's active period and haven't been substantively updated since. The game mechanics are from a version that was patched three years ago. The character lore has been retconned. The "current events" section references a storyline that concluded in 2022.
Those pages still hold positions based on accumulated domain authority and internal link equity. But they're losing positions incrementally as Fandom's Core Web Vitals scores on mobile drag down the overall quality assessment, as Google's freshness signals apply more pressure to content in categories where users demonstrably expect current information, and as quality rater assessments of Fandom's advertising density feed back into quality calculations.
Fandom's advertising situation deserves a specific mention because I think it's doing more damage than people realize. Their mobile ad load creates LCP scores above 4.5 seconds on pages I've tested as recently as this month. That's failing the Core Web Vitals threshold significantly. On desktop the numbers are better, but mobile now drives the majority of gaming-related search traffic. They are failing the majority of their traffic on a metric Google has stated clearly it uses in ranking assessments.
The places I found opportunity: pages where Fandom's content was last substantively updated before a major content event — a game patch, a season finale, a lore expansion. Pages where the primary topic had changed enough that accurate information required significant revision that the Fandom community hadn't prioritized. Pages where the competitive query set had long-tail variations that Fandom's broad topic pages couldn't serve without dedicated subtopic articles.
The LORE Framework: Wiki Content Architecture That Ranks
Running a wiki at scale — ours covers a single gaming franchise across 11,000 articles — requires a content architecture framework that can be applied consistently across contributors with varying levels of expertise and motivation. LORE is what I developed: Layered, Outlinked, Revision-signaled, Entity-anchored.
L — Layered Content Depth
Every topic on the wiki exists at one of three content layers. Stub: 200 to 500 words, primary entity identification, two to three key facts, a clear note that the article needs expansion. Standard: 800 to 1,500 words, full factual coverage, infobox with structured attributes, three or more internal links to related topics. Comprehensive: above 1,500 words, sourced claims, comparison tables, revision history narrative for topics that have changed over time.
The layering matters for internal linking logic. Comprehensive articles link to standard and stub articles. Stub articles never link outward to comprehensive articles — all stubs link inward to their parent category and one standard-level parent topic. This creates a directed PageRank flow from stub pages toward comprehensive pages, which are the ones that rank for competitive queries. Many wiki operators let stub pages link everywhere, which distributes PageRank horizontally across shallow content rather than concentrating it on the articles that can actually use it.
O — Outlinked to Authority
Wiki articles that make specific factual claims need outbound links to primary sources. Not SEO-for-links reasons. Because Google's quality assessments of wiki-style content in 2026 appear to correlate with the presence of verifiable primary sources. An article about a game mechanic that cites the developer's official patch notes ranks better than an identical article making the same claims without citation. The difference isn't the link equity flowing in from the external source. It's the signal to quality systems that the content is grounded in something verifiable.
I introduced a policy in June 2025: any article making a specific numerical claim (damage values, statistical probabilities, time-based mechanics) requires a citation to an official source or a verified data extraction from the game itself. Articles without required citations get a "citation needed" tag that appears in the page and in our editorial queue. Response time on tagged articles from our editor community: median 11 days.
R — Revision-Signaled
The revision history of a wiki article is an SEO signal if you expose it correctly. Our article pages surface three pieces of revision data prominently: date of creation, date of last substantive revision (we distinguish substantive from minor edits in our edit tagging system), and a human-readable "accurate as of [version/date]" statement for topics that change with updates. All three appear in our Article JSON-LD schema as well as in the visible UI.
The "accurate as of" statement is the most valuable for search behavior. A user searching for current information about a game mechanic sees in the SERP snippet that our article was verified accurate against the most recent patch. Fandom's articles don't have this signal. That click-through advantage compounds into better engagement metrics which compound into better ranking stability.
E — Entity-Anchored
Every wiki article is anchored to a specific named entity with an unambiguous identity. The article for a game character includes the character's canonical name, their franchise, their first appearance date, and a disambiguation link if the name is shared with another entity. This anchoring appears in structured data, in the page title pattern, in the URL slug pattern, and in the first paragraph text.
Entity anchoring is what lets Google's systems connect our articles to Knowledge Graph entities rather than treating them as floating text documents. Once an article has a confirmed entity connection, it benefits from entity-based ranking signals that go beyond pure link equity and content quality. This is the mechanism behind the 14% reversal, which I'll explain in detail below.
Entity Building: The Long Game That Paid Off
Entity building is the unglamorous work that drives wiki SEO at the domain level. It's the process of accumulating verified entity associations between your site's topics and Google's Knowledge Graph — so that when a user searches for a specific game character, location, or mechanic, Google's systems recognize that your article is about that specific entity rather than text that mentions it.
What this looks like in practice: structured data with Wikidata IDs where available, Wikipedia links from article content where they exist, consistent entity naming across all articles that match canonical naming conventions used in Knowledge Graph entries, and a structured sitemap submission that groups articles by entity type so Google can batch-evaluate our coverage of related entities.
The Wikidata ID inclusion is small but meaningful. For game characters and franchises that have Wikidata entries, including the QID in our article schema ("sameAs": "https://www.wikidata.org/wiki/Q12345678") gave Google's systems an explicit entity match signal. I added this to 847 articles in September 2025. Within 90 days, those articles showed measurably better ranking stability on their target queries — less volatility, smaller swings between tracking updates. The entity anchor was doing the stabilizing work.
Structured Data for Wiki Articles at Scale
At 11,000 articles, generating structured data manually is not an option. I use a template-driven approach in MediaWiki where the infobox fields map directly to JSON-LD schema properties. The template generates the structured data automatically from whatever is filled into the infobox.
<!-- MediaWiki template: Template:Character_Schema -->
<!-- Called by infobox template, generates JSON-LD automatically -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Thing",
"name": "{{{canonical_name}}}",
"description": "{{{one_line_description}}}",
"url": "https://wiki.example.com/wiki/{{{page_slug}}}",
"sameAs": [
"{{{wikidata_url|}}}",
"{{{wikipedia_url|}}}"
],
"isPartOf": {
"@type": "CreativeWorkSeries",
"name": "{{{franchise_name}}}",
"url": "https://wiki.example.com/wiki/{{{franchise_slug}}}"
},
"dateCreated": "{{{first_appearance_date}}}",
"dateModified": "{{REVISIONTIMESTAMP}}"
}
</script><!-- For game mechanics articles, use a different type -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "{{{mechanic_name}}}",
"description": "{{{mechanic_description}}}",
"step": [
{
"@type": "HowToStep",
"text": "{{{step_1}}}"
}
],
"dateModified": "{{REVISIONTIMESTAMP}}",
"tool": {
"@type": "HowToTool",
"name": "{{{game_version}}}"
}
}
</script>The {{REVISIONTIMESTAMP}} MediaWiki variable is crucial. It automatically updates to the current revision timestamp whenever any editor saves the page, which means Google's freshness signal is automatically refreshed with every legitimate edit. No manual date maintenance. No stale modification dates on actively maintained articles.
The sameAs array handles the entity anchoring at the structured data level. Empty fields are handled by the | fallback in the template syntax — if there's no Wikidata URL for a minor entity, that field simply omits rather than generating a null value that invalidates the schema.
Internal Linking in Wikis: The Counterintuitive Rules
Wiki internal linking is a topic where conventional wisdom is mostly backward. The typical advice: link everything to everything, create a dense internal link graph, maximize the number of internal links per article. This advice treats internal linking as a PageRank distribution tool and concludes that more distribution is always better.
It isn't. Here's what I've observed over 18 months of tracking internal link changes against ranking changes:
Over-linking in stub articles distributes PageRank away from comprehensive articles that need it. A stub with 15 outbound internal links is leaking PageRank to 15 destinations, most of which are other stubs. That's PageRank you needed concentrated at your comprehensive articles to compete with Fandom.
Reciprocal linking between articles of equal content depth (two comprehensive articles linking to each other) creates stable PageRank equilibrium rather than flow — neither article receives net additional PageRank from the relationship. Useful for topical association signals. Not useful for accumulating ranking authority at specific articles.
The counterintuitive rule: link from many shallow pages to a few deep pages, and be conservative about linking from deep pages back to shallow pages. Direct the flow. Don't just create connections.
My current linking policy:
- Stub articles: maximum 3 outbound internal links. All three must go to standard or comprehensive articles in the same topic category.
- Standard articles: maximum 8 outbound internal links. Majority to comprehensive articles, a few to related standard articles.
- Comprehensive articles: unrestricted internal linking for genuine reference value. These articles are PageRank sinks — they receive more than they send — so outbound links from them carry meaningful authority.
The 14% That Came Back and What It Taught Me
Between November 2024 and July 2025, we steadily gained positions on Fandom across roughly 2,200 tracked queries. The gains were consistent and explained by our content quality improvements, better Core Web Vitals, and structured data advantages. I was tracking the gains weekly and the trend line was clean.
February 2026: 14% of our gained traffic reversed. Not gradually. Over three weeks, rankings dropped back to where Fandom held them before our gains on a specific cluster of queries — primarily queries involving named characters who had dedicated Wikipedia entries and strong Knowledge Graph associations.
I spent a month trying to understand what changed. The content on those pages hadn't changed — ours or Fandom's. Our Core Web Vitals hadn't changed. No manual actions in Search Console. What changed, as best I can reconstruct from the pattern: Google appeared to recalibrate entity association strength between Fandom's wiki pages and specific Knowledge Graph entities. The recalibration favored Fandom's longer-established entity connections, even on pages where our content was objectively more current and complete.
Fandom has been building entity associations with these characters and franchises since their wikis launched — many of them 12 to 15 years ago. Those associations run through Wikipedia links, Wikidata connections, external news coverage that mentions both the entity and Fandom's wiki, and historical SERP patterns that Google's systems have accumulated signal on for over a decade. My nine months of entity-building work, however correct in method, couldn't replicate that depth in a period that short.
What this taught me: entity competition is not won by having better structured data. It's won by accumulating association signals over time at a volume that takes years to build. I can compete with Fandom on content quality, freshness, and page experience. I cannot compete with their entity association depth on major character pages in the near term. I need to pick the right battlefield.
The queries I've been winning back since February: minor character pages, mechanic-explanation queries, lore-interpretation content where there's no single canonical answer and Fandom's coverage is shallow. Not the flagship character pages. Those will take two or three more years of consistent entity-building work before the competition is meaningful.
Two Contrarian Positions on Wiki SEO
Contrarian Take 1: Wikipedia Links Don't Help the Way People Think
There is a common belief in wiki and general SEO circles that getting a link from Wikipedia is enormously valuable for domain authority. I've tested this directly. We received two Wikipedia external links in December 2024 — one to our main franchise hub, one to a specific article on a mechanic we'd documented thoroughly. Both were editorially added by Wikipedia editors who found our content genuinely useful.
Domain-level trust metrics from third-party tools moved upward modestly. Ranking positions on pages directly linked from Wikipedia? No measurable change. Ranking positions on other pages? No measurable change. The Wikipedia links appear to matter for entity association confirmation — Google can see that a Wikipedia editor considered our article a credible source on this topic — but not as a link equity transfer in the way a high-DA editorial link from a relevant publication would work.
Don't pursue Wikipedia links as a ranking tactic. Accept them gratefully when they happen organically, because they validate that your content is reference-quality. That validation has long-term brand value. It doesn't move rankings next month.
Contrarian Take 2: Wikis Should Have Fewer Articles, Not More
The instinct when building a wiki is to cover everything. Every minor character. Every quest. Every throwaway item in the inventory system. Comprehensive coverage is a feature, the thinking goes, and comprehensiveness signals topical authority.
My experience: wikis that cover everything without prioritization are harder to maintain to a quality standard that Google's current systems require. The maintenance burden of 25,000 articles is five times the maintenance burden of 5,000 articles, but the ranking benefit of the extra 20,000 articles — mostly stubs, mostly on minor topics — is not five times the ranking benefit of 5,000 well-maintained articles. It's closer to 1.3 times, while the quality risk from unmaintained stubs is compounding continuously.
I reduced our target article count in October 2025 from "cover everything" to "cover everything at standard level or above." Stubs below the quality threshold were consolidated into parent articles or deleted. 2,100 articles removed. Traffic impact: down 4% short-term, flat by month two, up 9% by month three as the domain-level quality signal improvement started affecting our higher-priority pages.
The Mistake That Cost Three Months of Progress
In August 2025 I implemented automated structured data generation for our full article set without validating the output on edge cases first. The template logic worked correctly for articles with complete infoboxes. For the 1,400 articles with partially completed infoboxes — required fields missing, optional fields empty — the template generated malformed JSON-LD with empty string values in fields that Schema.org requires to be either a valid type or omitted entirely.
Google's Rich Results Test flagged errors on 1,400 pages simultaneously. Search Console showed a sharp spike in structured data errors in the coverage report. We didn't lose ranking positions immediately, but the error volume put us on a watch list for a manual quality review that arrived six weeks later — a soft notification in Search Console about structured data quality, not a manual action. I spent two weeks cleaning up the template conditional logic to properly handle empty fields by omitting them rather than outputting empty strings. Then another month waiting for recrawl and revalidation.
The lesson I should have known: test your template output on a sample of 50 articles covering edge cases before deploying to 11,000 pages. I ran it on 5 articles. All 5 had complete infoboxes. That was not an adequate sample.
Where This Stands in May 2026
The net position as of today: we hold 38% of Fandom's traffic in our franchise niche on the queries where we directly competed, minus the 14% that reversed in February, which puts us at roughly 24% net gain over where we started in November 2023. That number is real. It's what I see in our analytics and in our Search Console data compared against Fandom's ranking positions in my weekly tracking spreadsheet.
The 24% is also incomplete as a summary because the character of the traffic has changed. We're winning on long-tail and mid-tail queries, on freshness-sensitive content, on mechanic-explanation content where Fandom's pages are outdated. Fandom holds its positions on major character head terms and franchise hub queries where entity associations run deep. That's a meaningful split that affects the quality of the traffic, not just the volume.
What I'm building toward: three more years of consistent entity-building work to close the association gap on the major character queries where Fandom currently can't be beaten by content quality alone. In parallel, continuing to expand coverage of content areas where Fandom's community isn't actively maintaining quality — smaller games in the same franchise, older content that got retconned, mechanic edge cases that hardcore players need and Fandom's broad-coverage model doesn't serve well.
Fandom is declining. Slowly. Unevenly. With genuine strengths in entity association depth that aren't going away on their own. Anyone treating it as an automatic win because of their ads problem is making the mistake I almost made.
Related on this site: UGC SEO in 2026 covers how community review platforms are using similar entity-building tactics against TripAdvisor. Forum SEO in 2026 applies the crawl efficiency principles to phpBB and Discourse. The Disqus engagement signal data is relevant to wiki talk-page indexation strategy. Full index: Community Site SEO — All Articles.
External authority: Schema.org documentation for Thing and its subtypes — Google's Knowledge Graph API and entity documentation.
