Choosing the Right Catalog Structure in Evolution CMS

Catalog problems in Evolution CMS are rarely caused by output snippets alone. More often the trouble starts earlier, when the data model is built around whatever import file arrived first instead of around how the site will actually be browsed and maintained.

The original question came from a project whose catalog structure was being prepared from spreadsheet data. That is a common scenario, and it is exactly where a rushed resource tree can become expensive later.

Questions to answer first

• Will each product be a real resource, or will some rows stay as TV-driven data only?
• Which categories are navigational, and which are only labels or filters?
• Do editors need to manage products individually in the tree?
• Will imports update existing products or recreate them from scratch?

A practical Evo rule

If products need individual URLs, SEO fields, related items, or editorial control, they should usually be real resources. If the dataset is only a technical lookup table, a lighter storage pattern may be enough.

Why this matters

The catalog structure influences everything else: filters, breadcrumbs, import logic, related products, and frontend URLs. A clean category tree plus well-defined TVs is easier to scale than a flat list patched later with complex snippets.

Recommended direction

Model the resource tree around the visitor-facing catalog, not around the spreadsheet. Imports can always be adapted. Bad information architecture is much harder to fix once templates, menus, and filters depend on it.