Data and authoring

The layout area is on a different layout from the one this record's active revision uses. Then: it is an attribute, so it is on the Attributes tab or behind a cog rather than in the content form; a workflow step restricts editing to a group the author is not in; the area is hidden; or the record's layout was changed and the area exists only on the old one. Check the revision's layout first.

It did not. Content is stored against the layout area's internal id, and the admin shows it under the new name. What went dark is every template still reading the old name, which now gets nothing (Smarty throws for the shorthand, renders nothing for the getter; Twig renders nothing for both). Update every template and integration that used the old name and deploy them together; the content was there all along.

The field is printed with getAreaText() on a plain text or textarea area, which carries no live-preview marker, so it updates only on save. Or the value passes through a modifier (|escape, |truncate), sits inside an attribute or a comparison, is rendered by JavaScript, or lives in a fragment the template caches. For element content an author edits directly, print the shorthand or getAreaHtml() unmodified.

The layout area's supported layouts list is empty, which offers every component layout on the site, including the block itself. Fill it in on that area, and on every collection inside a component, with only the blocks that belong there. The list is enforced by the admin's editor and not by the API, so an integration can still write anything; templates guard for that with a blank check.

It is not a draft. A draft can never be the active revision, so what the public sees is a version somebody activated, usually by saving with the publish option instead of saving a draft. Check the revision history for who activated it and when. The other way round also happens: you are signed in, previewing with ?revision=, and mistaking the preview for the public page; anonymous visitors ignore that parameter.

The published date is in the future (scheduled), or the record is restricted to a group and answers 404 to everyone else, or you tested signed in and the public gets a 404 for another reason: no active revision (the page lookup requires one), an unpublished ancestor (the path is resolved one slug at a time, each under the published rule), the wrong site, or a rewrite or custom URL intercepting the path. Test with curl and read the status code, not the browser you are signed in to.

Often allowed: a page slug must be unique among its siblings only, a post's within its blog, a FAQ page's under its parent; so two "about" pages under different parents are fine and reachable by their full paths. Not allowed: FAQ questions share one namespace across the account, custom entity records one per definition across all sites, categories and tags one per site. The generator appends -1, -2 on a collision; a custom URL is unique per site and is the usual cause of a real clash.

The layout lives on the active revision: an older active revision keeps its old layout after you change it on a newer, inactive one. Then, by type: a blog post with no layout of its own falls back to the blog's post layout, then to the layout whose template is blogs/posts/show.html; a book or unit ignores its layout on public views; a custom entity record uses its definition's one layout; a signed-in ?revision= preview applies that revision's layout. And a site file with the same path as a platform template overrides it everywhere.

A deploy replaces every file with the branch's contents, so anything edited on the server, a template changed in place or a template held as a virtual file (which resolves last anyway), is overwritten. Content is records and survives a deploy untouched; a layout's template path is content too. Keep template edits in the repository, and treat the branch as the only source of files on any environment.