CreatePageByDefault and Page-Owning Content

Datastore, Blog, and Calendar objects can each own a repeated family of pages — one detail page per item, post, or entry — instead of every page living as its own separate Article. `CreatePageByDefault` is the property that makes this practical, but it is a narrower mechanism than the name suggests.

What CreatePageByDefault actually does
`CreatePageByDefault` only sets a default for the CMS editor UI: when someone creates a new item in that Datastore (or a new post in that Blog, or a new entry in that Calendar), it decides whether the "give this item its own page" option starts checked. For Datastore and Blog, `DefaultTemplateGUID` and `DefaultRootPath` go with it, pre-filling the suggested Template and URL root an editor would otherwise pick by hand. None of this generates a page, and none of it exempts an item from carrying its own page fields.

Every page-owning item still needs its own URL, Template, and BrowserTitle
Whether authored through the CMS UI or in an import package, a DatastoreItem, BlogPost, or Calendar entry that has its own page still needs the same page-identity fields an Article would: its own `URL`, `TemplateGUID`, and `BrowserTitle`, plus whatever SEO fields the site conventionally sets (`MetaDescription`, `Keywords`, `IncludeInSearch`). `CreatePageByDefault` and its `Default*` companions never populate these — they only supply starting values a human editor sees in the UI. Hand-authoring a package import payload skips the UI entirely, so nothing pre-fills anything: omit `URL`, `TemplateGUID`, or `BrowserTitle` on a page-owning item and it has no page, `CreatePageByDefault: true` on its parent Datastore notwithstanding.

Why choose a page-owning Datastore over one Article per item anyway
The value isn't less per-item authoring — an Article needs the same fields. It's that the items share one Datastore schema (its `Fields` definitions) and one detail Template, and a listing page can render all of them with a single dynamic query instead of a listing template that has to be hand-edited every time a new item joins the family. Prefer a page-owning Datastore — or a Blog for chronological content, or a Calendar for scheduled entries — whenever a design has two or more cards leading to similarly structured detail pages. Reach for a plain Article when the page is genuinely one-off.

Singleton settings are the other common use of a Datastore
Not every Datastore needs `CreatePageByDefault` at all. A Datastore used to hold one global settings record — logo, contact details, footer content — is typically `CreatePageByDefault: false`: its single item is read by templates, not rendered as a page of its own.