<p>It sounds like you have 3 different general buckets of entries to consider:</p>

<ul>
<li>Streams of similar entries (News section, blogs, etc.)</li>
<li>General content pages (100+ of them)</li>
<li>Unique/one-off pages (Contact Us, application forms, etc.)</li>
</ul>

<p><strong>Streams</strong></p>

<p>First, the easy ones: the streams of similar content (news, blogs, etc.) should each get their own Channel sections. A News channel, Bill’s Blog, Sally’s Blog, etc.</p>

<p><strong>General content pages</strong></p>

<p>For the 100+ general pages, I think putting them all in a single “Pages” section makes sense. Find out what different types of pages there will be, and give the section different Entry Types based on those, so authors have the flexibility of choosing what type of page they want to create.</p>

<p>URL format-wise, you can either require that these entries follow a particular slug-based URL format (e.g. every page will have a url such as <a href="http://example.com/some-slug" rel="nofollow">http://example.com/some-slug</a>), or give them a custom “Page URL” field where authors can choose what the entry URL would be. For the former, the section’s Entry URL Format setting would get set to <code>{slug}</code>; for the latter, it would be <code>{pageUrlFieldHandle}</code>.</p>

<p>As for the type of section Pages should be (a Structure or a Channel), here’s a good rule of thumb: Do you want <em>all</em> of the pages in this section to be shown in the navigation, or just certain ones? If you want them <em>all</em> in the nav, then use a Structure, and use the built-in Structure View on the Entries index to sort out the navigation. Otherwise make it a Channel, and manage the navigation separately (<a href="https://github.com/am-impact/amnav/" rel="nofollow">a&amp;m nav</a> and <a href="https://craftpl.us/plugins/craftnav" rel="nofollow">Craft Nav</a> are your two navigation options at the moment).</p>

<p><strong>Unique pages</strong></p>

<p>Finally, the unique pages like Contact Us and application forms. If you have any pages that are truly unique, which you would never conceive needing two of (e.g. a Contact Us page that has a bunch of custom fields that really only apply to that specific page), create Single sections for those pages. Otherwise you may just prefer to lump these in with the Pages section, with the help of a new entry type(s) (e.g. “Application Form”).</p>

CC BY-SA 3.0
2014-10-30T21:14:54.880Z
Almost reads like outside of the channel entries you could have one Structure section with unique entry types (and/or Matrix for content blocks). Am I following?
SethG
CC BY-SA 3.0
2014-10-30T21:40:01.043Z
@SethG Just edited the answer - hopefully it’s more clear now!
Brandon Kelly
CC BY-SA 3.0
2014-10-31T12:28:53.043Z
Thanks and helps confirm my thinking around the 100+ general page part.
SethG
CC BY-SA 3.0
2014-10-30T20:34:52.947Z
2014-10-30T21:39:45.980Z
2014-10-30T21:39:45.980Z
Brandon Kelly
<p>I am doing some content modeling for a site with over 100 pages with a pretty deep tree. The site has a lot of what I refer to as "General Pages" as well as a collection of channel type content in the form of news, blogs, and such. In addition there are many unique pages such as contact and application form pages. </p>

<p>My main question is: How to section the over 100 general pages for best balance for client friendliness?</p>

<ul>
<li>Do I create one "General Page" channel section and then use or build
some sort of nav add-on to create the appropriate heirarchy (This is
how we'd roll if we were building this in EECMS for example)?</li>
<li>Do I use multiple structures, one for each primary nav item? And then figure out how to mix in the other unique singles and entries?</li>
<li>Tons of singles? (my least favorite option)</li>
<li>Something else?</li>
</ul>

<p>I know the answer to these questions given a CMS as flexible as Craft is simply "Yes"; however, would love to get some thoughts on how people have dealt with a well branched site map and lots of "General Pages".</p>

<p>Thanks!</p>

CC BY-SA 3.0
2014-10-30T20:26:39.753Z
Updated to use "Channel" instead of "Entry" for section type for clarity.
SethG
<content><models>
Content Modeling for Site Architecture Recommendations
# Content Modeling for Site Architecture Recommendations

(Asked by: username_0 on 2014-10-30)

I am doing some content modeling for a site with over 100 pages with a pretty deep tree. The site has a lot of what I refer to as "General Pages" as well as a collection of channel type content in the form of news, blogs, and such. In addition there are many unique pages such as contact and application form pages.

My main question is: How to section the over 100 general pages for best balance for client friendliness?

* Do I create one "General Page" channel section and then use or build
  some sort of nav add-on to create the appropriate heirarchy (This is
  how we'd roll if we were building this in EECMS for example)?
* Do I use multiple structures, one for each primary nav item? And then figure out how to mix in the other unique singles and entries?
* Tons of singles? (my least favorite option)
* Something else?

I know the answer to these questions given a CMS as flexible as Craft is simply "Yes"; however, would love to get some thoughts on how people have dealt with a well branched site map and lots of "General Pages".

Thanks!

**Tags:** content, models

> **Comments:**
> **username_0**: Updated to use "Channel" instead of "Entry" for section type for clarity.  

---

## 1 answers

### Answer by username_1 on 2014-10-30. Score: 3 | Accepted answer

It sounds like you have 3 different general buckets of entries to consider:

* Streams of similar entries (News section, blogs, etc.)
* General content pages (100+ of them)
* Unique/one-off pages (Contact Us, application forms, etc.)

**Streams**

First, the easy ones: the streams of similar content (news, blogs, etc.) should each get their own Channel sections. A News channel, Bill’s Blog, Sally’s Blog, etc.

**General content pages**

For the 100+ general pages, I think putting them all in a single “Pages” section makes sense. Find out what different types of pages there will be, and give the section different Entry Types based on those, so authors have the flexibility of choosing what type of page they want to create.

URL format-wise, you can either require that these entries follow a particular slug-based URL format (e.g. every page will have a url such as <http://example.com/some-slug>), or give them a custom “Page URL” field where authors can choose what the entry URL would be. For the former, the section’s Entry URL Format setting would get set to `{slug}`; for the latter, it would be `{pageUrlFieldHandle}`.

As for the type of section Pages should be (a Structure or a Channel), here’s a good rule of thumb: Do you want *all* of the pages in this section to be shown in the navigation, or just certain ones? If you want them *all* in the nav, then use a Structure, and use the built-in Structure View on the Entries index to sort out the navigation. Otherwise make it a Channel, and manage the navigation separately ([a&m nav](https://github.com/am-impact/amnav/) and [Craft Nav](https://craftpl.us/plugins/craftnav) are your two navigation options at the moment).

**Unique pages**

Finally, the unique pages like Contact Us and application forms. If you have any pages that are truly unique, which you would never conceive needing two of (e.g. a Contact Us page that has a bunch of custom fields that really only apply to that specific page), create Single sections for those pages. Otherwise you may just prefer to lump these in with the Pages section, with the help of a new entry type(s) (e.g. “Application Form”).

> **Comments:**
> **username_0**: Almost reads like outside of the channel entries you could have one Structure section with unique entry types (and/or Matrix for content blocks). Am I following?  
> **username_1**: @username_0 Just edited the answer - hopefully it’s more clear now!  
> **username_0**: Thanks and helps confirm my thinking around the 100+ general page part.  

---

