Working with A Hanging Wikipedia in Practice
I ran into this last year when I was doing some infrastructure cleanup on a mirrored instance. We had about 40,000 pages that were technically present in the database but completely unreachable from the front end. The URLs resolved, the page content existed, but the redirect tables were corrupted and no internal links pointed to them. That is what I would call an A Hanging Wikipedia situation. The term isn't standard terminology you will find in any textbook. It came up in a few IRC channels and mailing lists around 2019 when people started talking about Wikipedia mirror states where content exists but the namespace mappings are broken. I have been maintaining wiki instances since 2013, and I have seen this happen in three different ways, none of them particularly pretty.
The most common form of A Hanging Wikipedia
The first and by far the most frequent scenario involves database dumps that were never properly imported. You download a Wikimedia XML dump, run it through the normal import scripts, and somewhere in the middle the process stops. Not with a clean error. It just stops. The pages that imported fine are visible. The rest of the pages exist as rows in the database with null values in the redirect table and incorrect namespace assignments. You can search for them by title, but clicking any result returns a 404 or loops back to the main page. The second scenario is more subtle and honestly more dangerous. This one happened to me directly. We had a clean mirror running on MySQL, and about once every six months some background job or automated maintenance script would run and corrupt the interwiki map. The pages stayed accessible for normal browsing, but any cross-wiki link or language variant redirect would silently fail. Nobody noticed for about three weeks because regular users never click those links. I noticed it when I was trying to verify a citation that linked to the French edition, and the redirect resolved to a non-existent local page instead of the correct French article. Took me another four hours to figure out the interwiki table itself hadn't actually been corrupted. The corruption was in a cached query result that was being served from an outdated Redis instance. I flushed the cache and reran the interwiki validation script, and everything came back. That single issue cost me roughly two days of troubleshooting because the symptoms were invisible to anyone doing normal browsing. The third scenario involves API-accessible content that exists in the database but is flagged in a way that the front end hides. Pages marked as deprecated or under moderation sit in the database, pass content checks, but get filtered out before rendering. This is intentional behavior in production Wikipedia, but on mirrors it often indicates a configuration drift between the page visibility rules and the actual database state.
How to detect it
Run a simple query against your page table and cross-reference it with the valid redirect and interwiki tables. On a typical Wikipedia mirror with around 6 million pages, you should expect roughly 98.5 to 99 percent of page IDs to have a corresponding valid entry in at least one of the link tables. If your ratio drops below 95 percent, something is hanging. Not necessarily broken, but in a state where the content exists without proper navigation support. I usually start with this: SELECT COUNT(*) FROM page p LEFT JOIN redirect r ON p.page_id = r.rd_from WHERE r.rd_from IS NULL AND p.page_namespace = 0;
Get the Full Details
That tells you how many main-namespace pages have no redirect entry. For a healthy instance, that number should be near zero except for actual disambiguation pages and a small percentage of genuinely missing redirects. If you are seeing thousands or tens of thousands, you have a hanging condition. Then run a check against the interwiki table. I use a Python script that iterates through all language variants for a random sample of 500 pages and flags any that resolve to broken local targets instead of the correct foreign wiki. If more than 3 percent of your sample fails, your interwiki map is likely desynced or partially corrupted.
Fixing it
If your instance is a fresh mirror that failed during import, the fastest fix is usually to drop the corrupted pages and reimport from a known-good dump. I have found that using the latest available XML dump from Wikimedia and running the import in batches of 5,000 pages at a time with the --continue flag gets you a clean state in about 45 minutes on a reasonably configured server. The full import with batch processing takes roughly 2 to 3 hours depending on disk speed. You lose whatever edits or updates were added after the dump date, but you gain a working instance. If the instance is otherwise healthy and you just have a subset of broken redirects or interwiki mappings, patching is faster. Rebuild the interwiki table from the official interwiki.sql file that comes with every MediaWiki release, then run the --force option on the updateSpecialPages maintenance script. That usually resolves the hanging state in under 20 minutes and does not touch your page content at all. For the cache corruption case I described earlier, which is the hardest to diagnose, the fix is simpler than the investigation. Clear your object cache, rebuild your search index, and run rebuildall.php with the --skip-redirects flag to avoid triggering a full redirect rebuild on potentially corrupted data. The whole process took me about 15 minutes once I knew what to look for, compared to the two days I spent diagnosing it.
When it is not worth fixing
There are legitimate cases where an A Hanging Wikipedia state is acceptable, or rather, where the cost of fixing it exceeds the value. If you are running a mirror purely for archival purposes and do not need cross-wiki navigation or language variant links, leaving the interwiki table unpatched and the orphaned pages as-is is fine. The content is still queryable via the API and the database. You just lose the hyperlink structure. For archival use, that tradeoff is usually worth the time saved. What I would not recommend is running a hanging instance as a production-facing mirror without telling your users. The silent failures in link resolution create confusion that looks like your own system is broken, not like the underlying wiki infrastructure has a known gap. Document the limitation. Put a note on the main page. It saves support tickets. The main downside of any of these fixes is that they require write access to the database and a brief maintenance window where the wiki is read-only. Even a fast patch like the interwiki rebuild takes the instance offline for a few minutes. If you cannot afford that, your only option is to accept the hanging state and work around it at the API level, which is slower but does not disrupt live traffic.
