Crit Pick, month two: one page per Pal, and the web that ties them together
Month two of the Crit Pick experiment, minus the numbers: how the site is split into small pages, why the links matter more than the pages, and the bet I'm making that the next post grades.
Month two, and Crit Pick still gets almost no traffic. The honest number is still tiny, and I'll put the real figures to it in the next checkpoint.
This post is about the thing underneath the numbers: the shape of the site. Over the last few weeks I've been splitting Crit Pick into a lot of small pages and wiring them together, and the whole bet is that the structure earns rankings before a brand-new site has any authority to spend. Here's how the pages are split, why one Pal gets one page, how they link, and the bets I'm making that the next post gets to grade.
Crit Pick is an SEO case study I run in the open for SeeIndie, and also a games project I'd wanted to build for years. If the method works, you'll see it here in real numbers. If it doesn't, you'll read that too.
Month two checkpoint ·
- The unit is the page, and the page follows the search. One Pal gets one page, because people look up one creature at a time. Volume per page is small on purpose.
- A page only exists when demand splits to it. Otherwise it's a section inside a bigger page. Thin pages that fight each other are the failure mode.
- The links are the actual product, not the pages. A pillar routes down to a hub, the hub to the individual pages, and those link back up and sideways to each other. A page with no links in and out ranks for nothing.
- A link a crawler can't follow isn't a link. My navigation was built in JavaScript, which the AI crawlers never run, so in the raw HTML the whole site was unreachable. That got fixed.
- The bet is structure first, authority later. It's slow, the numbers are small, and the next checkpoint is where you get to grade whether the shape actually paid off.
The unit is the page, and the page follows the search
The first decision on any topic isn't what to write, it's how finely to cut it. Get that wrong and you either bury ten searches inside one page nobody can find for any of them, or you spread one search across ten thin pages that compete with each other.
My rule is simple: a page exists when the search splits to that level, and not before. The clearest case is Palworld. Every single Pal gets its own page, because that's how people actually search, one creature at a time. Nobody types "list of all Palworld creatures" and reads it top to bottom. They type the one name they're standing in front of. So the page is the Pal.
The opposite case is RimWorld mods. There are dozens of Vanilla Expanded modules, and most of them don't have enough search demand to earn a page of their own. Those become sections inside the parent page. A module only graduates to its own deep dive when the data shows people searching for it by name. A "best of" ranking is a different animal again: a tier list targets people comparing options, so it's its own page, and it links back down to the deep dives it ranks.
None of that is clever. It's just refusing to let the site's shape drift away from the shape of the search.
Palworld, in three layers
Here's the whole idea in one worked example, because Palworld is where I've pushed it furthest.
The top layer is the pillar, the Palworld hub. It exists to introduce the topic and route you deeper. Under it sits the Paldex, a grid page where every Pal is a tile, and every tile links to that Pal's page. Right now the grid holds 34 of a planned 287, and it says so plainly, because a page that claims to be complete when it isn't is the kind of thing this whole project exists to not do. The bottom layer is the Pal pages themselves, one per creature.
Then the links start doing the work. A guide I'm about to publish, the best early-game Pals, ranks nineteen of them from strong to situational, and every one of those nineteen names links straight to its Pal page. That's a guide pouring visitors and link value down into the individual pages. The pages link back up to the Paldex and the pillar, and they link sideways to each other wherever it's genuinely useful, a breeding chain that needs two parents, a prev-and-next walk through the dex. No page is an island, and none of the links are decoration. Each one is a path a reader, or a crawler, can actually take.
The links are the product, not the pages
This is the part that's easy to underrate. The individual pages are the easy bit. The structure that connects them is where the ranking actually comes from, especially for a site with no backlinks and no authority yet.
The clearest proof so far is a RimWorld page I haven't touched in weeks. Last checkpoint, the animal tier list had 174 impressions and exactly one click. It's an evergreen answer to a steady search, and it sits in a cluster that kept filling in around it. Every new RimWorld page I published added another internal link pointing at it. I didn't optimise the page. I built its neighbourhood. That's the entire thesis in one page: publish the low-difficulty answer, wire it into a cluster, and let the link value gather. It's slow, and then it isn't.
That's why I keep saying the links are the product. A pile of good pages with nothing connecting them is just a pile. The cluster is what turns thirty small pages into something Google reads as an authority on a topic.
A link a crawler can't see isn't a link
One hard lesson belongs here, because it nearly sank the whole plan quietly. My site navigation, the menu that reaches every hub, was built in JavaScript. It looked perfect in a browser. But the AI crawlers, the ones ChatGPT and Perplexity and Claude send out, don't run JavaScript at all. So when I checked the raw HTML, the version those crawlers actually read, the site had 19 internal links and reached zero of its nine hubs. The entire structure I'd just described was invisible to exactly the crawlers I write about.
The fix moved the hub links into the part of the page that ships as plain HTML. Raw-HTML internal links went from 19 to 32, and reachable hubs from none to all nine, on every page. The lesson is blunt and it's the same one SeeIndie keeps making: a link that only exists after JavaScript runs is a link half the web can't follow. If it's meant to carry ranking, it has to be in the delivered HTML.
The honest part: this might be thin content
Here's the risk I'm carrying, said out loud. Thirty-odd near-identical Pal pages, on a brand-new domain with no authority, in a space that established sites have owned for years. There's a real reading of that where Google sees a stack of thin, samey pages and treats the lot as low value. I don't get to know yet which way it goes. The pages are new, they have no authority to lean on, and most of them are sitting on page two or three doing nothing.
The bets, so you can grade me
That's the point of doing this in the open, so here are the open questions I'm handing to the next checkpoint:
Does one page per Pal earn its rankings, or does the cluster read as thin content? Does the link value actually flow up to the hubs, or do the small pages rank while the hubs stall on page two? Does the evergreen tier list keep compounding? And does the one high-volume utility page I bet on, the event timer, ever climb once the cluster around it builds enough authority to carry it?
I don't know the answers. That's the honest state of it at month two. The structure is built and the bets are placed. Next time I'll put real Search Console numbers to every one of them, what climbed, what stalled, and what I got wrong.
Common questions
Isn't one page per Pal just thin content?
Why not one big Paldex page instead of hundreds of small ones?
Does internal linking really do anything this early?
Can I check any of this?
Follow the experiment
One practical discovery tip and whatever I'm currently testing on Crit Pick. No fluff, no pitch.
Sources
- Google Search Console (clicks, impressions, position) — via the Crit Pick case study, data through 5 July 2026
- Crit Pick content map and build log — the site architecture and the 19→32 internal-link / 0→9 hub counts in the raw HTML
- Own keyword research — the event timer at roughly 12,100 searches a month