I’m sure there are a lot of variation implementing content tree structure out there, here I’m sharing the content tree structure that i have grown liking to.
The idea is to keep things simple and organized for the content editor so they can work their way around the site and feels natural about how the content is structured.
We start simple, a website node has two child node, a home page node and a libraries node.
A home page node serve as the landing page when the site URL is accessed, a libraries serve as a place to put the data sources of components that’s being used through out the site.
And there’s pretty much how content tree is structured, as a convention i usually use lowercase and no whitespace for the pages node item name because that translate directly into a URL, so you want a friendly URL to be generated. You can enforce this by using a custom pipeline that change the item name after creation and update but convention is good enough for me.
For the pages under supplementary pages, these are the pages that do not belong to the site’s pages hierarchy/sitemap and usually i give them alias so we can achieve URL such as /404 instead of /supplementary-pages/404. It’s just a matter of taste but think about it.
Hey, what about multisite ?
What about it ?, we replicate the same structure for the other sites and if you notice we have a global node over there. The global node serve as a place to put shared content across the sites, maybe the sites shared the same banner data source or carousel put it in the libraries of the global node. And that also goes for the shared pages, you can put it in the supplementary-pages of the global node.
The same structure can be found on other places as well
also keep in mind these following things:
- if you have a need of referencing items avoid referencing by item path and use item id instead because item path can change, for example when the content editor move the item around or rename them.
- remember that it’s a bad practice to have hundreds of child nodes under a single node, use categorization to manage them – see news page above.
- if there’s a need to store a huge amount of data that results in hundreds of child nodes don’t try to store it Sitecore as is, give it a thought and see if storing in a custom table suit your requirement better or take a look at the Sitecore Item Bucket.
- use branch template to specify a content structure.
- use insert options to specify child node type that can be inserted under a node.
- use icon to give visual information to your content editor, this way they can easily distinguish which is which, but be wise in the implementation don’t just give any random icon.