Which built-in type fits which purpose, how categories, tags, slugs, custom URLs and SEO settings behave across them, how revisions and publishing gate what the public sees, how to model a domain the platform has no type for, and where uploaded files live.
L1–L3
Unit 02 · Taxonomy, URLs and SEO
SEO settings and Open Graph
Taxonomy, URLs and SEOPage 11 of 35Updated
Every content record carries SEO settings: a title, a description, a canonical URL, a robots value and a share image. The platform prints none of them; the site's templates do. The fields, the robots mapping that is easy to get backwards, what the sitemap does with them, and Open Graph data from custom fields, in both engines.
Who this is for. The theme developer writing the head of the base template, and the content modeller deciding what authors fill in for search engines and social cards. Afterwards you can print every record's SEO settings from one include, with Open Graph data the authors control.
The fields
Admin label
Getter
Notes
SEO Title
getTitle()
Empty unless the author set one; fall back to the record's name
Meta Description
getDescription()
Meta Keywords
getKeywords()
Comma-separated
Canonical URL
getCanonicalUrl()
Free text: absolute or a path
Alternate URLs
getAlternateUrls()
One URL per line
Robots settings
getRobots()
A stored code, mapped below
Share image
getShareImage()
An image, or nothing
Pages, books, units and book pages, blogs, blog posts, FAQ pages and questions, and product and category descriptions have them, through getSeoSettings(). A custom entity record keeps them on its revision, when its definition's SEO Settings switch is on: getActiveRevision().getSeoSettings(). Any of these can return nothing for a record whose SEO panel was never filled in, so test before reading through it.
The framework prints none of this: no title tag, no meta tags and no canonical link. The site's base template does, which is why it belongs in one include that every page type calls.
The robots value needs a mapping
The robots setting is stored as one of four codes, and the codes are not meta-robots values:
Admin label
Stored
Print
Default (recommended)
empty
nothing
Index & follow
all
index, follow
Index, but don't follow
index
index, nofollow
Don't index, but follow
follow
noindex, follow
Don't index and don't follow
none
noindex, nofollow
Printed as it is, follow gives no instruction about indexing, so a page the author marked "Don't index" is indexed. Map the codes, as the include below does.
Open Graph from custom fields
SEO settings take custom fields. Define them once, in the admin under Customization, Custom Fields, for the entity SEO Settings: a select ogType with the options website and article, and an image ogImage. They appear in the SEO panel of every record that has SEO settings, so every page type gains them without a new layout area. One include then prints the lot:
Template codeincludes/seo.html, called with seo and title
Each page type passes its own record and the include does the rest, so a new page type needs one line rather than its own head. Structured data follows the same shape: a schemaType custom field on SEO settings chooses the @type of a JSON-LD block, and the values come from the record. The custom fields read back with the default you give when a record's author left them empty.
What the sitemap does with them
The platform generates /sitemap.xml from the published records of the types that are switched on for it, and it reads their SEO settings:
a record whose robots value is follow or none (either "Don't index" option) is left out;
a record with a canonical URL is listed at that URL, and left out when the canonical URL is on another site;
a record's translations are listed as its alternates.
The file is generated in the background and kept for an hour, so a change shows in the sitemap within the hour, not at once.