My first year as a front end developer not just fast-tracked my growth in coding, but opened up the brand new world of content modelling to me. I learnt many crucial lessons about the shape of content when building a website up from scratch using a CMS: what is the anatomy of a single node of content (be it media or text or reference link) and what's their relationships other content nodes.
Create an extra page type wherever possible
This is an interesting one, and I have read dissenting opinions on this. Page types could change in meaning, responsibilities and fields over time as the business changes. For example, "About Us" could change into a "Brand overview", which could suddenly take on new responsibilities and needed to display other types of content nodes as the company changes direction.
In these instances, rather than deleting the existing page types, create a new one and retire use of the older version. This way, client content could remain intact and there is less chance that unspooling the data rendering would damage the other parts fo the project.
Always add page types, never delete.
Rely on reusable components to fill out the content of the page type
The reusable components that I'm referring have different names: partials, slices or widgets. They usually take on the appearance of image galleries, call-to-action boxes, dynamic tabs, accordions.
Giving the client creator to swap and choose different widgets gives them the flexibility to be creative and control at the wheel. For one, there is no need to delineate each and every single field attached to a page type. There would simply be one widget zone to maintain. For example, the "Legal Policy" page is often a page filled with dense legalese. Choosing a widget zone over a single over-arching text field for that page type means that the client creator can make changes to the content and page type down the track should they need to.
Do not delete fields from page types
In the same vein, never delete fields from page types. A senior developer had regaled me with a horror story where a field was accidentally deleted from a page type, and along with it all the client content. A heart stopping moment, but with happy endings (hooray for backups!). But the moral of the story still stands: any deleting of fields should be at the discretion of the client with consultation with the development team.
Use parent content nodes
Building up a mental model of the data structure should go hand in hand with the project specification and any client discussions you've had. Where multiple content nodes could have similar fields, set up a parent page node on the structure. This parent node could be use to render data dynamically from all its children.
So where this is most relevant could be a folder node for a list of image nodes. The folder node could then be used to spin up a header banner. Or an umbrella page node can be parent to a series of individual brand nodes. On the parent node, a widget could be used to render children node data dynamically. This gives greater control over searching and displaying data from multiple pages at the same time.
Sensible naming conventions
With all the thinking around nodes, sometimes the easiest way to bridge the knowledge gap with clients could simply be using sensible names for content types, nodes and fields. Avoid using general terms such as "page", "node" or even "folder". Purpose driven names such as "Policy" or "Gallery group" would make it much easier for clients to cotton on the hierarchical nature of the content structure.
SEO & Social fields
From the projects that I have been involved in, there are a number of base fields that should accompany every page type.
SEO: metadata fields for sitemap
Blurb image and introduction text: the image and introduction could be used to literally introduce the particular page from another page.
Visibility: a page should be able to be hidden from sitemap and navigation even with content
But why bother? Structuring your content clearly, logically and with just the right amount of hierarchy over flexibility means content creators and marketers can fully express themselves creatively. At the same time, it prevents technical debt down the track as the site grows or changes in direction. There is no fixed science doctrine, no magical finite list of things to tick off, and can be opinionated according to the team, client or project.
The rule of thumb is there is no strict rule of thumb. But sensible thinking should prevail.