Website: page tree, blog, redirects

Overview
A site is a public web presence: one or more domains, one or more languages, a page tree. This area runs the frame — the individual pages are built in the web builder.
The separation is deliberate: here it is decided where something sits and under which address; in the builder it is decided how it looks.
Core tasks
Set up a site. Domains, languages, robots rules and the maintenance mode belong to the site.
Bring a domain to the website. Enter the domain as the primary host (or as an additional host) — without https:// and without a path; www. is included automatically. At your hosting provider the domain points to the same directory as the application (document root …/current/public); no further web server setup is needed: Octibiz keeps a list of every domain of an active website, and only these domains get the website — any other domain keeps showing the application. If the domain is changed or the website is deactivated or deleted, the domain belongs to the application again right away. The application's own addresses (sign-in, customer portal, your brands' domains) cannot carry a website; saving rejects them.
Maintain the page tree. Pages are created, moved and given language variants. The slug determines the address.
Build menus. Navigation menus point at pages of the tree — so moving a page does not change the menu structure.
Run a blog. You write blog posts under Content → Blog — the website displays them. A post appears on the website once it is published to the Own website target: at /blog/<address> in the default language and at /<language>/blog/<address> in every other language it has a title for. The website's Blog tab lists which posts are there and under which address; the title opens the post in the content system.
The website always shows the published version. If you change a published post, the change reaches the website only after you publish it again — writing and releasing are two rights. A withdrawn post disappears from the website, the blog overview, the sitemap and the website search.
A post's content appears inside your brand's Blog post template (Builder → Templates) if there is one; scripts and embedded third-party content from the text are not delivered.
Feeds, categories and tags. The posts create further public addresses by themselves: an RSS feed at /blog/feed.xml and an Atom feed at /blog/atom.xml (per language with a language prefix, such as /en/blog/feed.xml), an archive page per category and per tag — in English /blog/category/<name> and /blog/tag/<name>, in German /blog/kategorie/<name> and /blog/schlagwort/<name>. Archives only show published posts and are listed in the sitemap; every blog page announces the feeds in its page head so feed readers find them. Below the article the website links its categories and tags and shows Related posts — the content system computes them from shared tags and categories. The Blog tab lists all these addresses under Feeds and archives.
Review changes first, then go live. The Versions tab holds two tools:
- Staging: Prepare staging version builds every surface of the website from its draft as a
separate version — pages, posts with a builder surface, and the brand's templates and popups. Live stays unchanged. Preview shows which surface changes and gives a link under which the website appears in exactly this version. Publish puts the version live for the whole website; the current live version is saved as a restore point first.
- Restore points capture the published state of all surfaces. Before you Restore, Preview
shows the same list of changes and the same link — you see what comes back before it comes back.
The preview link is valid for one day, is never cached and never indexed; End preview on the website ends it. No separate staging domain is needed for this.
See who changed what. The Activity tab shows the log of the website: who created, changed or deleted the website, pages, languages, menus, addresses, content, versions and the builder surfaces of its pages, and when — with the changed fields. A filter narrows it to one object type.
Keep addresses under control. The URL table shows every address in use. Renaming creates a redirect so that old links do not run dry; manual redirects are possible too.
Evidence consents. Cookie consents are logged — the evidence is the purpose, not the display.
Fields in detail
| Field | Required | Values / format | What it does |
|---|---|---|---|
Name name | yes | text | What the site is called internally. |
Brand brandId | no | one of your brands | Which brand the site stands for. |
Primary host primaryHost | yes | domain, e.g. www.example.com (scheme, path and port are removed) | The address the site is reachable at. It is the canonical address for search engines. Not an address of the application itself and not a domain of a brand. |
Additional hosts additionalHosts | no | list of domains | Further addresses pointing at the same site. They redirect to the primary one — otherwise search engines rate the same page several times and none of them well. The same rules as for the primary host apply. |
Default language defaultLocale | yes | language code | Which language is served when the visitor prefers none. |
Languages locales | no | several languages | Which languages the site carries. |
Site search searchEnabled | no | yes/no | Turns on the site's own search: pages are indexed and a result page appears under /search. Off means a search box would come up empty. |
Theme themeUlid | no | a configured theme | The look of the site. |
Favicon faviconUrl | no | image (PNG, SVG or ICO), ideally square | The icon in the browser tab and in bookmarks — for this website only. You upload it in the settings or pick it from the media library. Without a favicon of its own the browser shows its default icon. |
Home page homepagePageUlid | yes | an existing page | What appears at the primary address. |
Error page errorPageUlid | no | an existing page | What appears at an unknown address. Without a page of your own a plain default message appears. |
Maintenance page maintenancePageUlid | no | an existing page | What is shown during maintenance. |
Maintenance mode maintenanceMode | no | yes/no | Takes the site off for visitors. This is a blunt switch — to search engines the site then temporarily looks empty. |
Access password accessPassword | no | text, max. 200 characters | Puts a password in front of the whole site — for previews and pages that are not meant to be public yet. It is stored as a hash only and never returned; an empty value lifts the protection again. |
Imprint imprintPageUlid, privacy privacyPageUlid, accessibility accessibilityPageUlid | partly | existing pages | The legally required pages. They are linked in the footer; imprint and privacy are mandatory in Germany, not optional. |
Consent settings consentConfigJson | no | structure | What the cookie notice looks like and what loads without consent. What requires consent may only load after it is given — not already while asking. |
Search engine rules robotsPolicy | no | structure | What search engines may read. |
Notes for AI services llmsTxt | no | text | What AI services are told about the site. |
Head code headCode | no | markup | Delivered on every page of this site right before the end of the head section — typically analytics or verification snippets. Whatever is here goes out unchanged; a mistake in it hits the whole site. |
Consent for the head code headCodeConsent | no | consent banner category | The code is only loaded once the visitor agrees to this category. Empty means load immediately — the wrong value for anything that needs consent. |
Body end code bodyEndCode | no | markup | The same right before the end of the page. The right place for anything that must not slow the page down while it builds. |
Consent for the body end code bodyEndCodeConsent | no | consent banner category | The consent category for the body end code; empty = load immediately. |
Active active | no | yes/no | Whether the site is served. |
Settings & permissions
- Sites:
site.site.view/site.site.manage - Page tree:
site.page.view/site.page.manage· Menus:site.menu.manage - See the website's blog:
site.post.view— write and publish posts:content.item.manage/content.item.publish(see Posts) - URLs and redirects:
site.url.view/site.url.manage - View restore points:
site.backup.view· create and restore them:site.backup.manage· prepare and publish staging:site.staging.manage(any of the three is enough to preview a version) - Activity log:
site.activity.view - Consent records:
site.consent.view
Module flag: module.site.
FAQ & troubleshooting
A page is no longer reachable under its old address. Check the URL table: as a rule there is a redirect; if it is missing, create a manual one.
A language is missing. Languages apply per site; the page additionally needs a variant in that language.
The site is unreachable. Check the maintenance mode first.
The domain shows the application's sign-in instead of the website. Check that the domain is entered exactly like this as the primary or an additional host of an active website. If it is, ask operations to resync the list of website domains (bin/console app:update:backfill --nur=site.host-markers) and to check the domain's document root (operations runbook §10).
"The domain belongs to the application itself". The domain is the sign-in or portal address or a domain of a brand (Settings → Brands → Domains). Such a domain cannot show a website at the same time.
A blog post is missing from the website. In the post, check the Own website line under “Distribution”: if it says “This language is not configured for the site”, the website does not carry that language. If the post was changed after publishing, publish it again.