❌ The mistake
Designing a site where everything is created as a “generic content page” – product categories, case studies, whatever – all squeezed into one infinitely flexible but completely vague content type.
⚠️ What problems this creates
You can’t reliably filter or query: every listing becomes a small crime scene investigation.
Developers end up hard-coding logic based on tree location or naming conventions.
Content editors lose guidance: “What fields do I even fill in for this thing?”
Reuse across channels becomes fragile or impossible.
Any change in structure means “big bang” refactoring instead of controlled evolution.
🤦♂️ Why teams make this mistake
It feels fast and “agile”:
“We already have a generic page type.”
“It can hold anything.”
“We’ll standardise later.”
Under deadline pressure, a flexible blob feels safer than committing to real content types… until the site goes live and marketing wants proper listings, filters, and reuse.
💸 How much it costs to fix
On a recent project, product categories and case studies were modelled as generic content. After ~200 pages were populated, the dev team tried to build listings and ended up with heavy tree-based hacks like "if this page URL starts with products - treat it like product category" type of thing. Cleaning it up — remodelling content types, implementing proper listings, and migrating all that unstructured content — took ~120 developer hours. Not counting the editor's pain.
📘 Best practice
Model specific content types (e.g., Product category, Case study) with clear fields and relationships. Even if it requires some extra time, it will pay off in the end! Kentico’s content modelling guides are spot on here:
Content modelling overview
Structured vs unstructured content
Structured vs Page Builder content
💬 Seen this in the wild? Share your “generic page” war stories in the comments.