Two different animals
Half of SoiTarot is built for machines to crawl. The other half is built for a person to play with. They share a brand and almost nothing else.
Everything I've written about SoiTarot so far has been about the machine that prints pages — the combinatorial SEO, the content fence, the agents. But a site that only does SEO is a brochure. The reason to build the search engine was to bring people somewhere worth arriving — and that somewhere is a different beast entirely. SoiTarot is really two products wearing one brand.
The crawl half and the play half
The two halves have opposite jobs, and almost opposite engineering:
| The SEO pages | The interactive product | |
|---|---|---|
| Who it's for | crawlers + skimmers | a person, leaning in |
| Count | ~15,000, generated | a handful, hand-built |
| Rendering | static, prerendered | dynamic, stateful |
| Animation budget | 3 at once, ≤600ms | 6 at once, up to 1s |
| Success metric | indexed + ranked | the draw feels good |
| Data | content, mostly read | accounts, saved readings |
The compatibility pages, the card meanings, the horoscopes — those are the crawl half: fast, static, held to a strict Core Web Vitals budget because a tenth of a second of jank is a ranking tax. The draw flow — shuffle, pick, flip, read — is the play half, where the animation is the product and a little theatre is the point. The card-flip that would be reckless on a horoscope page is exactly right here.
Why the split is the architecture
Trying to serve both jobs with one approach is how sites end up mediocre at both — a janky app bolted onto slow content, or beautiful content no one can interact with. So I let them be different on purpose. The crawl half is prerendered and motion-starved; the play half is a real app with state, accounts (sign in with Google), and a database holding what a person drew and saved. Same tokens, same art direction, same Crescent Eye brand — but underneath, two different animals.
SEO's job is to get a stranger to the door. The product's job is to make them glad they came. Build one thing to do both and you usually get neither.
A decision that proves the split
Early on, I tried using the same card-flip animation on the SEO compatibility pages and in the draw flow. Same component, same timing. On the compatibility page — where a person wants an answer, not a show — the 600ms flip felt like a tax. You came for "will Cancer and Sagittarius work," and the site made you wait for a card to turn over. I cut it. The page got faster, the bounce dropped, and the content did its job.
In the draw flow, the same flip is the moment. Shuffle, pick, and then the card turns — that's the whole emotional arc. Cutting it there would be like removing the pause before a punchline. So the same animation lives in one place and not the other, and that's not inconsistency. That's the architecture working.
The cost of running two
Nobody tells you that splitting a product in two means maintaining two things. The crawl half has its own build pipeline, its own Core Web Vitals budget, its own content generation system. The play half has state management, auth, a database, animation choreography that would be overkill on a static page. When I change a design token, I check both. When I update the brand, I update both. The SoiTarot case study shows the result; what it doesn't show is the Tuesday evening I spent debugging why a CSS variable rename broke the draw flow but not the SEO pages, because they load their styles differently.
The split is right. But "right" and "free" are different words.
The funnel nobody talks about
Here's the strategic point that the SEO-heavy story hides. All those combinatorial pages aren't the destination — they're the top of a funnel. Someone searches "Cancer and Sagittarius," lands on a genuinely useful page, and the interactive draw is right there: want a real reading, not just the compatibility note? The static half is the world's most patient acquisition channel; the interactive half is where attention turns into a session, an account, and — eventually — the question of whether any of this converts into something.
That conversion question is the next thing I have to answer, and I haven't yet. The machine proved it can bring people in. Whether the play half is good enough to keep them — and whether "kept" ever becomes "paid" — is the part of the experiment still running. The crawl half was the engineering. The play half is the actual product. I spent the first week proving the first one works; the more interesting bet is the second.