Designing Content Architecture for 10,000+ Structured Lessons

Content architecture becomes visible only when it fails. A few hundred articles can survive inconsistent naming and manual categorisation. A library of thousands of lessons cannot.

Start with the questions users actually ask

A teacher rarely asks for “all content tagged mathematics.” The useful question is closer to “Primary 4, Mathematics, First Term, Week 6, current curriculum.” The data model should make that request natural instead of reconstructing it from title strings.

Taxonomies should represent stable relationships

Class, subject, term and curriculum version are not decorative labels. They are dimensions of the product. Stable term IDs allow the website, APIs and mobile clients to agree even when visible names change.

Ordering deserves its own field

Publishing date is not a curriculum sequence. When week number matters, it should be explicit. A robust system can still fall back intelligently when metadata is missing, but the intended order should be stored rather than guessed forever.

Curriculum versions require deliberate canonical decisions

When an education system changes curriculum, many topics remain related while others move, merge or change scope. Treating every new lesson as unrelated creates duplication; treating every similar title as equivalent creates incorrect mappings. Matching needs class, subject and academic intent, not title similarity alone.

Good structure reduces future product cost

Once the content model is trustworthy, filters become simpler, internal linking becomes smarter, mobile offline snapshots become smaller and editorial repair tools can operate predictably. Content architecture is not an editorial afterthought; it is software architecture expressed through content.