I Built 30 AI-Generated Game Wiki Sites in 45 Days. Google Rejected Every Single One. Here's the Post-Mortem.

The numbers, the three layers of failure, and the 78% hallucination rate I found when I actually audited my own data.

Between August 12 and September 10, I used AI coding agents to build a network of game wiki sites — Roblox game guides with interactive calculators, code lists, and tier lists — deployed on Next.js and Vercel, all hanging off one domain with subdomains.

The plan was simple: pick games with real search demand, ship useful tools faster than legacy wikis, let SEO do the rest.

Google indexed approximately zero pages from the entire network. Not "ranked poorly." Not "sandboxed for a few weeks." The indexing report read like a rejection letter.

This is the honest post-mortem: what the data said, the three separate layers of failure I found, and the uncomfortable discovery that scared me most — that when I finally audited my own content, most of it was fabricated.

The numbers

Here's what Google Search Console showed for the whole network (302 known URLs):

Zero pages ranking. Meanwhile, Bing had already indexed at least 7 of the sites organically — same pages, same content. That contrast mattered later, because it ruled out "the content is unindexable" and pointed at something else.

The timeline was the most revealing part. The "crawled, not indexed" count sat at 16–19 pages through late August, then jumped from 19 to 107 in a single day (Aug 29), then flatlined at 116 for the next three weeks. I hadn't launched 88 sites that day — Google had simply finished sampling the network, decided what it thought of it, and applied that verdict wholesale. Sites it never sampled just stayed frozen in "discovered, never crawled," with crawl dates showing the epoch default: January 1, 1970.

Lesson 1: Google evaluates site networks as networks, not as pages. A sample of your pages becomes a verdict on all of them. If your first impression is a bad one, the other 80% of your pages don't even get a crawl.

Layer 1: Technical self-sabotage

Before blaming algorithms, I ran a full technical audit across every domain. What I found was embarrassing:

• A canonical tag pointing at a domain that doesn't exist. One site's layout declared its canonical URL as a .com domain I had apparently planned to buy and never did. DNS said NXDOMAIN. Every page on that site was telling Google "the real version of this page lives at an unregistered domain." That's not a quality issue — that's a self-destruction switch.
• Three sites with no canonical tags at all, because an earlier fix script had injected metadata into client components, which broke their builds. The builds failed silently for weeks while everyone assumed Vercel was just slow.
• 64 URLs inside sitemaps that redirected (trailing-slash mismatches between the sitemap generator and the server config). Every one burned scarce crawl budget on a 308 dance.
• Pages marked noindex still listed in sitemaps. "Please index me" and "don't index me" in the same envelope.
• Broken builds freezing deployments. Three sites served stale content for days because a regex-based cleanup script had mangled JSX syntax, and a static validation script couldn't catch what only a build would catch.

All of this is fixable in a sprint, and we fixed it: canonicals everywhere, sitemaps byte-identical to final URLs, noindex pages pulled from sitemaps, builds gated before every push. But I want to be honest about what it changed: nothing immediately. Technical health is a threshold, not a ranking factor. Cleaning it up removes self-inflicted rejection reasons; it doesn't create a reason to rank you.

Lesson 2: "It builds on my machine" is not enough. If your deployment pipeline doesn't fail loudly on build errors, you will ship a site that serves a stale snapshot for weeks and nobody notices.

Layer 2: The 78% hallucination rate

This is the part that should scare anyone shipping AI-generated content sites at scale.

Our code-list pages listed "working redeem codes" for each game. When I finally verified them against actual public code trackers — instead of trusting that the generated content looked plausible — 18 out of 23 sites had fabricated code tables. Roughly 63 invented code strings across the network.

The fabrication wasn't random. It fell into seven repeatable patterns, which I now use as an audit checklist:

1. Developer names as codes — "SUPERGAMING", "ASSEMBLERX"
2. Game title prefixes as codes — "SKYASSASSIN" for a game titled [SKY ASSASSIN] Jujutsu Shenanigans
3. Game mechanics as codes — "MONARCH", a trait name from the game, listed as a redeem code
4. Version numbers as codes — "UPDATE14", "FALLPREVIEW"
5. Real codes rewritten — "Origins" became "ORIGINS2026", "Release!" became "RELEASE"
6. Template filler — "XXX2026", "BETA_TEST_2025", "SUB2XXX"
7. Entire code systems invented for games that have none — including full "how to redeem" tutorials for games with no redemption feature. One game had never even launched.

Worst of all: a joke code in one game actually deducts 300 units of in-game currency, and our page told players it gives 300. Anyone who followed our advice lost money.

The tells were invisible from the outside. The pages looked confident, structured, complete. LLM-generated content doesn't look wrong — it looks exactly right until you check it against reality.

Lesson 3: You cannot audit generated content by reading it. The only reliable method is external verification: pull the entity, search for it in independent sources, and require agreement before publishing. We rebuilt every table this way — every code cross-checked against at least two independent trackers, and where no source documented a reward, the entry now literally says "reward not documented by the publisher" instead of guessing.

We also found that some of our "verified" data sources were inflating their own numbers — major outlets listing dead codes as working, with duplicate entries. Freshness of the source mattered more than the brand of the source.

Layer 3: Thirty thin subdomains, zero external trust

Even with perfect technicals and honest data, the network had a structural problem: 30 subdomains, each with 5–20 pages, sharing one root domain, with zero backlinks between them and the rest of the web. No community presence, no creators linking in, no directory listings. Nothing.

From Google's perspective, this is the textbook footprint of scaled content abuse — exactly what the March 2024 spam policies target. And no matter how good each page is, a site with no incoming trust gets a much higher bar for "worth indexing" than an established domain.

We hadn't earned a single external signal. We were asking Google to trust 300 pages from a domain nobody had ever linked to, powered by content we hadn't verified. The rejection was, in hindsight, reasonable.

Where it stands

The technical layer is now clean across all 29 domains. Every code table has been rebuilt from verified sources — and we open-sourced the result as a CC-licensed dataset of 527 verified codes across 19 games, including the verification methodology, so anyone building similar tools can skip the fabrication phase.

Has Google noticed? Too early — the re-crawl window is weeks, not days, and trust rebuilds slower than it collapses. The honest summary of where we are: we removed every reason for the rejection, but we haven't yet added a reason for the acceptance. That next layer is real external signals — community participation, creator links, content people actually cite — and it can't be generated by an agent. It has to be earned at human speed.

Five takeaways if you're doing this

1. Sample-based judgment is network-wide. Don't ship ten sites to "test" — the ten sites are the test, and a bad verdict spreads to everything else on the domain.
2. Verify generated data against external sources before shipping. "Looks right" is exactly what a confident hallucination looks like. An 80% fabrication rate is invisible from inside the document.
3. Canonical tags are load-bearing. One wrong canonical can hide an entire site from the index while every page returns 200.
4. Gate deploys on builds. A static check that doesn't compile your code will let a broken site serve stale content for weeks.
5. AI can generate the site, but not the reputation. The moat in a post-LLM-content world is precisely the stuff agents can't fake: first-hand data, real community presence, and links you earned.

The open dataset is here: github.com/lianlele168/roblox-codes-dataset — 527 verified codes, per-code source notes, CC BY 4.0. Examples of the rebuilt pages: Pressure's codes page (including the joke codes that deduct currency, which most trackers get backwards) and Fisch's codes page (135-entry expiry archive; that game kills weekly codes within 24 hours by design).