Defining Pages

A page is an entity that has its own URL. Any entity may be a page, and only the error page must be one. Deciding which entities are pages shapes the site's navigation and search, and it decides which custom fields an entity can have. There is more than one valid answer for most types, so treat the guidance below as considerations and write your reasons down.

Which entities are usually pages
• Nearly always pages: articles, blogs, blog posts, tags, and authors.
• Depends on the site: calendars and calendar entries, folders, forms, galleries, and datastores and datastore items. A form may be a page of its own or may be embedded in other pages. Many datastores and their items have pages (see Datastore Design), and some never do.
• Almost never pages: documents and images. It is possible, but rare.
Site Objects Checklist lists the specialized templates a finished site usually has for each entity type that is a page.

What a page has that other entities do not
A page has a URL, a template, a browser title, and search settings. The editor requires a browser title and a template for anything that has a URL, and a template or other page-specific field set on an entity without a URL is ignored.
A page also has the custom fields its template defines. An entity without a URL has only the core fields its own type defines, because without a URL it has no template to say which custom fields to use. A datastore item shows the difference: it always has the fields its Datastore defines, and only an item with a URL also has the fields its template defines. This is why a datastore whose items have no pages needs its fields on the Datastore. See Where Custom Fields Belong and Datastore Fields and Template Fields.

One URL space
A URL is unique per domain across all pages, whatever their type, because otherwise the CMS could not tell which page to serve. An Article cannot claim a URL that a Datastore, Blog, or any other page already uses.

Articles as the general page
An Article can be the page for content that has no URL of its own. It can select the content through a picker field or fetch it, and it can show items from several datastores or other content records together. Consequences: the editor controls which items appear and in what order; the Article is a second record that describes the content, so a new item appears only if the Article picks or fetches it; and a plain listing of every published item needs no Article at all. Choose an Article for a hand-curated landing, a page that mixes sources, or a page that needs a different editing surface than the content's own. For a datastore's landing page, see Datastore Landing Pages. If both an Article and another record describe the same family, write down which one is the landing and why.