Container pages, and why you shouldn't use them

I've seen them on so many sites, all over forums, blog posts and the community in general. Container pages with no other purpose than to be a parent page for other stuff. Feel free to give them a folder icon too, so they look cool and non-standard.

I simply don't understand why this has even become a thing. For you out there who fancy these container pages and are clenching your butts, hang on for a while. There are exceptions, and I'll get to them.

Your URL represents the exact location in a content hierarchy — removing one segment should always take you up one level. If a page has a template and can be viewed by the user, all its parent pages should be viewable too.

If I, as an end user, can end up on /about/employees/john-doe, I expect that /about/employees will give me a list of all the employees. If I'm on /stores/oslo/karl-johans-gt, and I remove the last segment, I expect to see a list of all stores in Oslo. This makes it easy for regular people and power users - as well as educating normal users.

URL design should be deliberate, not something that just happens. In a perfect world they should be thought about by your UX-people. Getting the everyday user of a web publishing platform to adhere to such rules can be difficult, but by not having a container page, a lot is already done. It's the work you should not do that will improve your site.

If someone suggests to "just add a container page here to hold those things", it's your job to stop them and come up with something better. A list of the underlying content is the textbook example that will suffice in 90% of cases - it doesn't need to be super sophisticated.

I'm even going to guess search engines punish you for container pages that only give you a blank page too.

The exceptions

There are a few notable exceptions, as I said.

Applications with no real content hierarchy: Even though I mostly think these should follow these rules too, for some complex applications it might not always be viable or make sense to implement in such a way. Usually, EPiServer based sites do not belong in this category, though.

Container pages might be OK when containing pages that can't be browsed to and viewed directly. For example pages that are only meant to be part of a list, or to hold some data to be displayed somewhere else.

However - why would you need an explicit page type to hold these? Lock them down with permissions or other mechanisms, and just reuse something else you have already, like an article page. Or, you could use blocks or custom IContent implementations to contain this content. These are by default not directly browsable. It might be more work, but it cleans the page tree and reduces the cognitive load it takes to browse it as an editor. Especially since most of these container pages are used as "set-and-forget"-style content.

I could kindof get it in the CMS6-days and older, but continuing this trend now seems to me to be hanging on to the past for no good reasons.