Keeping names, handles and profiles consistent

A name is written in more places than anyone lists: the title element, og:site_name, structured data, the byline on each article, the footer, a social bio, a directory entry, an email sender line. Each place gets typed by hand at a different time, and small differences accumulate: an ampersand here, "Ltd." there, a handle with an extra underscore. Google's site name documentation asks for consistency across the sources it reads. The remedy is to decide each form once and record where it is used.

Five forms of a name

Most people and small organisations need five distinct forms. The fictional examples below describe a studio and its designer.

Google's guidance supports the split. For a site name it asks for a concise, commonly recognised name (its example is "Google" instead of "Google, Inc"), warns that a generic name is unlikely to be chosen unless it is an extremely well-recognised brand, and says long names may be truncated on some devices. For organisations, it lists legalName as the registered name when different from name. For people, it recommends name for real names and alternateName for social media handles.

Write the register once

Keep the decisions in one file that every template, profile and signature draws from. A register can be as plain as this:

{
  "site": { "name": "Harbour Studio", "alternate": ["Harbour Studio Design", "example.com"] },
  "legal": "Harbour Studio Design Ltd.",
  "people": [
    { "name": "Maya Okonkwo", "handle": "mokonkwo", "page": "https://example.com/people/maya-okonkwo/" }
  ]
}

The point is that each string exists once. When the site is generated from the register, a typo in a footer cannot disagree with the structured data, because both read the same field. Profiles on other platforms cannot be generated, so the register doubles as the checklist for those.

What Google reads on the home page

The site name document explains how the name is chosen. The process is automated and draws on the home page and on references to it that appear on the web. To state a preference, add WebSite structured data to the home page. The system also considers og:site_name, the <title>, headings and other text on the home page, though the structured data is described as the most important for stating a preference. Its practical rules:

• One name per site, where a site is a domain or subdomain. Subdirectory-level site names are not supported, and subdomains starting with www or m are generally treated as equivalent to the bare domain.
• The markup belongs on the home page, which must be crawlable.
• Duplicate home pages (HTTP and HTTPS, www and non-www) should carry the same structured data, not just the canonical one.
• Use the name consistently between the structured data and the other home page sources the system considers.
• Offer alternatives with alternateName, in order of preference. Google's example ends with the domain itself, in lowercase, as a backup option.

Two further points from the same page explain why alternates exist at all. Google says its system generally will not use the same site name for two different sites that are global in nature, so a preferred name can be unavailable. It may also decide that a site is more commonly recognised by an acronym than by its full name. In both cases, the alternates give the system acceptable options in your order of preference rather than leaving it to improvise from other text.

A home page head that follows the rules, as a fictional example:

<title>Harbour Studio | Brand identity for small studios</title>
<meta property="og:site_name" content="Harbour Studio">
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "Harbour Studio",
      "alternateName": ["Harbour Studio Design", "example.com"],
      "url": "https://example.com/"
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Harbour Studio",
      "alternateName": ["Harbour Studio Design", "example.com"],
      "legalName": "Harbour Studio Design Ltd.",
      "url": "https://example.com/"
    }
  ]
}
</script>

Google's Organization page says to use the same name and alternateName as the site name, which is why both nodes above carry identical values. The structured data was parsed with Node, and a short script compared the strings: the WebSite and Organization names and alternate names were equal, and og:site_name matched the structured data name.

If your preferred name is not selected, Google's troubleshooting list is short. Confirm the structured data holds the preferred name and has no errors, confirm other sources on the home page use it, confirm the redirects work, and allow time to be recrawled. It also notes that a system less confident in a name may generate one from other sources or show the domain.

People: name, handle and identifier

For a person, three fields do different jobs in Google's profile page documentation. name holds the real name. alternateName holds an alternate public identifier such as a social handle. identifier can hold a value your own site uses to recognise the person even if their handle changes, such as an internal database ID. sameAs lists other profiles or home pages for the same person.

The byline on an article should use the same name. Google's article markup guidance says author.name should hold only the author's name, without a job title, publisher name, honorific or introductory words such as "posted by". The title belongs in jobTitle and honorifics in honorificPrefix or honorificSuffix. It also recommends an author.url pointing to a page that uniquely identifies the author, and sameAs can serve as an alternative. Here is the author side of the same fictional site:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/people/maya-okonkwo/#person",
    "name": "Maya Okonkwo",
    "alternateName": "mokonkwo",
    "identifier": "author-1027",
    "url": "https://example.com/people/maya-okonkwo/",
    "sameAs": ["https://example.org/mokonkwo"]
  }
}
</script>

An article by Maya then carries "author": [{ "@type": "Person", "name": "Maya Okonkwo", "url": "https://example.com/people/maya-okonkwo/" }], and a script comparing it with the profile node found the name and URL equal. Details on @id and sameAs are in structured data for a person and a small company.

Structured data must also match what is visible. The general guidelines say not to mark up content that is not visible to readers and not to mark up misleading content. A name that exists only in JSON-LD, or that differs from the byline readers see, runs against the spirit of that rule.

Handles: pick a stem and record the exceptions

A handle is an identifier, and platforms set their own rules for length, characters and availability. Those rules differ and change, so read each platform's own terms and do not assume one string works everywhere. Choose a stem you want to be known by, claim it where it is free, and write down every variant that was forced on you in the register. Choose strings that survive being read aloud or copied by hand: the digit 1 and the letter l, or an underscore against a hyphen, make good candidates for error. Where a platform offers a link field, point it at your own site, because the site is the one address you control and can keep stable.

A worked reconciliation

A fictional audit of the home page finds four strings that name the studio: the title says "Harbour Studio", og:site_name says "Harbour Studio Design", the WebSite name says "Harbour studio" in lower case, and the footer says "Harbour Studio Ltd.".

The register decides the site name is "Harbour Studio". The title already follows it. The og:site_name becomes "Harbour Studio", and "Harbour Studio Design" moves to alternateName, since it is a name people do use. The structured data gets its capital S back. The footer should carry the legal name, so it becomes "Harbour Studio Design Ltd." in full, because the footer is the place for the registered name. One decision per string, and each decision ends in a field that the register already defines.

The same audit then turns up a profile on another platform that shows "Harbour Design Studio", with the words transposed. That one cannot be fixed by editing a template, which is the reason the register lists external profiles as a separate set of tasks.

Where a mismatch hides

Audit in one sitting

1. View source on the home page and list every string that names the site: title, og:site_name, WebSite and Organization name and alternateName, H1 and footer.
2. Compare the list with the register and note each difference.
3. Open one article and compare the byline, author.name and the author page.
4. Open each external profile in a private window to see what a stranger sees, and compare the display name, handle and link.
5. Search for the site and read the name shown with the result. Allow time for recrawling before judging the outcome.

Changing a name

A rename is a larger task than editing a footer. A workable order:

1. Change the register first, with the old name noted.
2. Update every on-site place in one deploy so that Google never reads a half-renamed home page. If the domain changes too, follow pointing a domain at a new host without downtime and keep the redirects described in canonical URLs, redirects and the www question.
3. Consider keeping the previous name as an alternateName for a time. That is a judgment, not something Google's documents prescribe, and the alternate list should still read as names a person would recognise.
4. Update the profiles you control, starting with the ones that link to the site.
5. Request a recrawl of the home page and expect the old name to persist for some days or weeks, as Google's documentation says recrawling can take.

Checklist

• Five forms are decided and written down: site name, alternates, legal name, display name, handle.
• The home page states the site name in structured data, og:site_name and the title, and all agree.
• WebSite and Organization carry the same name and alternateName.
• Bylines use the person's name only, with no titles, and link to an author page.
• Duplicate copies of the home page carry the same markup.
• Profiles on other platforms are checked against the register after any change.