Site Identity and Branding

Your site’s identity is six fields on one screen: Settings → General → General Details, plus the four social handles below it. They autosave as you type, and they reach your live site only when the Settings (General) item is published. Everything on this page is free on every plan.

The one thing to keep straight is scope. These fields set who the site is — its name, its one-line description, its mark. They set nothing about how it looks: colors, fonts, spacing and layout are CSS in your repository, which How Styling Works covers.

The identity fields

The section heading carries an amber must-publish indicator whenever it holds unpublished edits. The same Settings → General screen also holds your domains, the documentation appearance block and the publish reminder.

Where your site title and description surface

These two values fan out further than anything else you set in the CMS.

Your title and description are the channel metadata for all three feeds, which is the largest single consumer of them.

One honest caveat about browser tabs. Leed emits <meta name="title"> but never a <title> element — that belongs to your own master template, and the conventional form combines the two values:

<title>{{ title }} | {{ siteTitle }}</title>

If your tab text looks wrong, the fix is in your template, not on this screen. How Templates Work covers where that line goes.

Logo and favicon

Click Create (or Update if one is already set), pick a file, and confirm. SVG and PNG both work.

The upload is committed to your site repository’s main branch immediately — before any publish, and without a build. The file is timestamp-named so a re-upload never collides with a cached copy:

src/static/images/logo-2026-07-11T15-12-07-709Z.png
src/static/images/favicon-2026-07-13T18-17-42-980Z.svg

If the filename changed, the previous file is deleted in its own commit. The new path is stored on your company record, the company configuration file is re-committed, and your organization’s favicon URL is updated. What the upload does not do is trigger a build — the new mark appears on your live site at your next deployment.

The favicon is used in two places, and the second one surprises people: as well as the <link rel="icon"> tag in every page head, the build writes a 302 from /favicon.ico to the timestamped file into _redirects, so clients that ask for the legacy root path still get the right icon.

Documentation pages do not use this logo. They use their own light and dark pair, set separately in the documentation configuration and covered on Documentation Header, Footer and Logos.

Social handles

Four handles have CMS fields. They drive exactly two things: the social icon row in the default documentation footer, and the twitter:site meta tag on every page of your site.

The handles the CMS does not expose

Default social title and description

Two more company-level fields feed the sharing card: Social Title (up to 70 characters) and Social Description (up to 240). They are set as company defaults and can be overridden per page type.

There is one asymmetry worth knowing: og:description falls back to Social Description, but twitter:description does not — it is emitted from the page summary alone and omitted entirely when there is none. Social Cards and Structured Data works through the whole card, tag by tag.

What identity does not cover

Four things a reader reasonably expects to find here and will not.

• Site locale. It is stored, it drives og:locale, the RSS <language> element and the JSON Feed language — and it has no control anywhere in the CMS. It is set when your site is provisioned.
• The social card image and card type. ogCard.image, ogCard.cardType, ogCard.imageWidth and ogCard.imageHeight are read by the card templates but have no CMS field; they come from repository data.
• All CSS. Colors, fonts, spacing, the accent — none of it is on this screen.
• The documentation logo pair. Separate fields, separate files, separate page.

Everything these settings do reach is delivered to your templates through the site data cascade, as ordinary values in src/src.11tydata.json. Here is the identity half of a real one:

{
  "siteTitle": "Leed",
  "siteDescription": "Leed brings together your marketing workflows, website, and customer journey into a seamless, accelerated experience informed by AI.",
  "siteLocale": "en-us",
  "logo": "/static/images/logo-2026-07-11T15-12-07-709Z.png",
  "favicon": "/static/images/favicon-2026-07-13T18-17-42-980Z.svg",
  "ogCard": {
    "title": "Leed",
    "description": "Docs as a Service"
  },
  "externalAccounts": {
    "linkedinId": "leed-ai",
    "twitterId": "Leed_AI",
    "blueskyId": "leed.ai"
  }
}

That file is written wholesale by the CMS on every settings publish, which is why it is on the read-only list — a hand edit survives exactly until the next publish. Global Site Data and the Data Cascade explains how a template reaches these values.

A person’s own name, photo and social handles are a different record entirely — see Your Profile, which is also what decides whether an author is credited in your feeds.

Publishing a branding change

Branding edits reach the site the same way every other setting does:

1. Make your changes in Settings → General. They autosave — there is no Save button.
2. Open Deploy and find Settings (General) under Pending Changes.
3. Select it and click Publish Selected.

A build runs and the new identity is live a couple of minutes later. A logo or favicon file is already in your repository at that point; the publish is what makes your site reference it.

One last note for Free workspaces: the default documentation footer shows a Powered by Leed badge in place of your own copyright line until you reach Starter. That gate, and everything else about the docs footer, lives on Documentation Header, Footer and Logos.