Use Site > Site setup, Catalogs or SEO in the site admin for the shared settings listed below. This reference helps you check which pages a change can affect.
Checked against the product’s code on 7 November 2026.
Shared settings can affect many pages. They are separate from the content of a selected section and from account billing or domain ownership. A change to the active site identity, navigation or theme can take effect without publishing a page draft.
Site setup and identity
Section titled “Site setup and identity”| Setting or area | Meaning |
|---|---|
| Site → Site setup → Front page | Chooses which page the root address / serves. Review and approve the proposed change. It does not publish a draft page. |
| Site → Site setup → Header button | Changes the button’s words and target together. Choose a page of this site or an address. The control reports whether the button is currently showing. |
| Site → Site setup → Header link | Sets the link’s words and destination separately from the menu and header button. Clear both the words and the address to remove the link. |
| Site → Site setup → Header style | Chooses Standard or Editorial for the shared header. |
| Site → Site setup → Footer layout | Chooses Links in a row or Columns for the shared footer. |
| Site → Site setup → Footer note | Sets the note shown with the Columns footer. It is separate from the footer copyright line. |
| Site name and tagline | Shared site identity. The saved name can appear in header, footer and metadata according to the layout. |
| Footer line | Closing text in the site’s footer copyright line. Clearing the line can remove it. Imported layouts can retain their own footer structure. |
| Logo and favicon | Site identity assets used by the CMS and layouts that read them. They do not replace every image in page content. |
| Site → Catalogs → Themes | Shared design choices. See Theme tokens and roles. |
| Navigation locations | Assign existing menus to the header, second header row or footer. A menu draft and its live publication are separate. |
There is no single universal value for these settings. Site setup, a migration and later saved changes can supply them. Confirm the stored and rendered values before changing a live site.
The native footer’s built-in credit is © 2026 Name. Powered by Praxis., using the current year and your site name. A different footer line written by your team keeps its separator.
EmDash’s own site settings
Section titled “EmDash’s own site settings”The CMS also has EmDash’s own settings. Governed requests expose the following groups:
| Group | Stored values and scope |
|---|---|
| Identity | Site title, tagline, logo and favicon. |
| Site URL | EmDash’s site address setting. Changing it is not a custom domain attachment or a DNS change. Hosted public reading resources use the actual host serving the request; do not use this setting as proof of their hostnames. Unless an Amadalis staff setting replaces this value, sign-in and invitation emails use this address, so a wrong value can send account links to the wrong domain. |
| Formats | Date format, time zone and posts per listing page. Confirm scheduled content and archive pagination when changing them. |
| Social links | Supported social account links. Unmentioned accounts are left unchanged by a targeted update. |
| Search verification | Google and Bing verification values published in the page head. They are different from account credentials. |
Copilot changes to these groups need approval. Undo can restore prior settings when the earlier values were saved. It cannot recall emails already sent or changes made elsewhere.
Site SEO defaults
Section titled “Site SEO defaults”In Site → SEO, site defaults include:
| Field | Behavior |
|---|---|
| Title template | Supports %title% and %sitename%. It applies to content pages without an explicit SEO title. The front page, 404 page and explicit SEO titles keep their separate title assembly. |
| Default meta description | Used when a content page supplies no description. |
| Default social image | Used when a content page supplies no social image. |
An absent default leaves the platform’s existing fallback behavior. A default is not an instruction to overwrite every page’s explicit metadata. Changing the defaults requires approval.
Crawler policy and robots text determine instructions given to machines. While the Praxis bot policy supplies robots text, it is used instead of EmDash’s own robots setting. See The public site for machines.
Visitor, capture and integration policy
Section titled “Visitor, capture and integration policy”| Area | Shared settings |
|---|---|
| Privacy & Data → Consent → Consent policy | Consent defaults by location and the site’s essential, analytics, personalization and marketing policy. Saved visitor choices and Global Privacy Control can take priority over those defaults; follow the consent rules for their order. |
| Privacy & Data → Consent → Head & CSP | Public head entries, their consent purpose and activation conditions, and Content Security Policy. A tag configured to load before consent is not made consent-gated by the notice alone. |
| Insights → Events & Capture | Event definitions, automatic capture and extra arrival query parameters. Defining an event does not create its sender. |
| Visitor identity policy | Identity scope and external analytics identifiers. Changes need approval because they affect collection and joins. |
| Affinity and targeting | Saved interest weights and targeting behavior. An event catalog weight does not itself change live affinity tuning. |
| Insights → Connections | Connected analytics services. Credentials stay in the trusted connection controls. |
| Exports and retention | Export datasets and scheduling are separate from deletion. Visitor events are kept with no limit until you set a retention period. Once you set one, events older than it are deleted on the site’s regular scheduled run, but only after an archive export has covered them. |
The account’s Security tab controls team sign-in policy and support entry grants. The team session policy is checked on the Praxis account and inside open site admin sessions. Revoking a support grant stops new entries and ends its open session on the next request after the grant check refreshes, within 30 seconds. At expiry, the next request ends the session. See Account Security for timing, read failures and staff restrictions.
Site API tokens obey the team’s applicable network, membership and two factor rules, with the token checks and read-failure limits. Session lifetime and idle timeout do not apply to tokens.
For the request-level approval and Undo inventory, see What you can ask the copilot.
Your next step
Section titled “Your next step”Follow Site setup to review a shared front page or header change and check the public result after approval.