I had one question before writing any code: does the size of a flashcard deck mean anything?
The obvious way to answer it is to open a few decks and squint. The reliable way is to pull the whole sitemap and count. This post is the second way.
What follows is a self-audit of a site I run — 156 public book decks, every card on them, one morning of curl and regex. The interesting part wasn't the totals. It was how little the numbers vary.
The crawl
sitemap.xml → 191 URLs. 156 are decks (/book-cards/<slug>/), the rest are blog and marketing pages.
Six-way parallelism with curl, 45s timeout, browser user agent, one proxy. Then a Python pass over each page:
- questions in
class="bc-qa-q" - answers in
class="bc-qa-a" - chapter labels in
class="bc-ch-name" - JSON-LD pulled from every
application/ld+jsonblock
Word counts are on the answer string after tag stripping. No tokenizer, no readability library — len(text.split()), which is crude and perfectly adequate for comparing decks against each other.
One page needed a second attempt. 289 KB of HTML, timed out at 45 seconds, returned 200 on both retries.
Results
| Metric | Value |
|---|---|
| Deck pages | 156 |
| Q&A pairs | 34,500 |
| Answer words | 2,729,190 |
| Median cards per deck | 123 |
| Median cards per chapter | 3.75 |
| Max cards per chapter | 4.00 |
| Mean answer length (per-deck, averaged) | 59.9 words |
| Min / max single answer | 25 / 109 words |
| Median page bytes | 227 KB |
| Max page bytes | 613 KB |
What the distribution says
Cards per chapter has a hard ceiling at 4. The median is 3.75 and the maximum is 4.00 — across 156 books, thousands of chapters, no book exceeds four cards per chapter. That's not a property of literature. That's a parameter. Which means deck size is essentially chapters × 3.75, and a 531-card deck is just a long book.
Answer length is nearly constant. 59.9 words averaged across decks. 84 of 156 decks never drop below 40 words on any single card. The whole site spans 25 to 109 words, and the 109 comes from the single heaviest page. For a set of cards spanning Machiavelli, Aristotle, the Tao Te Ching and a 1877 history of a fire in Saint John, that is an unnaturally tight distribution.
If you've ever built a content pipeline with a length target in the prompt, this is what the output looks like from the outside.
The markup points at the wrong thing. All 156 deck pages emit Book, WebPage, BreadcrumbList, Person. Zero emit Quiz, Question, or FAQPage — I checked every page for those type strings. The blog posts and the FAQ page do carry Question markup: 25 of 35 non-deck pages.
So the crawlable surface treats a 249-card study deck as a page about a book, and treats a marketing post as structured Q&A.
What this method can't answer
Whether the cards are correct. Comparing 34,500 questions to 156 source books is a reading project, not a scraping project. I checked one book.
Whether the pipeline that produced them has a fixed answer length by design or by accident. I never ran the generator — no account, no upload. Observing the output can't tell you which constraint produced it.
Whether anyone finishes a deck. No analytics on the public pages.
One thing I got wrong
My own note said "191 decks". It's 156 — I'd been reading the sitemap count as the product count. The 35 extra pages are blog posts and a pricing page.
Disclosure
wakecards.com is a site I build. The crawl is reproducible from the sitemap; the numbers above are what came back on 9 November 2026.
The next pass is the blog: 24 posts, and I suspect the markup split there is worse, not better. If you've done a similar crawl on a content site and the answer lengths came out flat too, I'd like to know what your prompt looked like — mine clearly had a number in it somewhere.
