Above every organic result, Google shows two things most site owners never set on purpose: a small icon and a site name. When those are wrong, the listing looks like it belongs to someone else. A treatment center that rebranded after an acquisition keeps showing its old name. A multi-program provider sees a bare domain where its brand should be. A clinic’s result carries a gray placeholder globe next to competitors that show a logo. None of these is a ranking penalty. But each one costs you recognition at the moment a family is deciding which result to trust, and each one comes down to a small number of documented rules.
This post walks through how Google picks the site name and favicon, why it sometimes ignores your preference, and the checks we run when a client’s listing looks wrong.
What the site name and favicon actually are
The site name is separate from the title link. The title link is the blue headline for one specific page (we covered how Google writes those in an earlier post). The site name belongs to the whole site and sits above the title, next to the favicon. Google’s site names documentation says the name is generated automatically from your home page and from references to your site elsewhere on the web. You can state a preference, but you cannot hand-set it, and Google says it cannot manually change a name its system has chosen.
Both elements are set at the hostname level. That detail causes more confusion than anything else on this list, so it gets its own section below.
The favicon rules, with the numbers
Google’s favicon guidelines require a square image (1:1 aspect ratio) of at least 8×8 pixels and recommend going larger than 48×48 pixels so it looks sharp on different screens. The supported formats on Google’s favicon documentation, last updated 28 August 2026, are BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. SVG is not on that list, so a site whose only declared icon is an SVG file is relying on a format Google does not document. Keep a PNG or ICO version declared on the home page as well.
The rest of the favicon rules are short:
- Declare it with a
<link rel="icon">tag (orshortcut icon,apple-touch-icon) in the head of the home page. Google reads it from there. - Googlebot must be able to crawl the home page, and Googlebot-Image must be able to crawl the icon file. A robots.txt rule that blocks your uploads folder can quietly block the favicon.
- The favicon URL should be stable. If your build process renames the file on every deploy, Google keeps chasing a moving target.
- Meeting every guideline does not guarantee the icon appears. Google says so plainly.
On WordPress, the Site Icon setting under Appearance asks for an image of at least 512 by 512 pixels and generates the smaller sizes for you. On our own homepage it outputs icon links at 32×32 and 192×192 plus an apple-touch-icon, all PNG. That default setup meets Google’s requirements. The problems usually come from themes or page builders that add a second, conflicting icon tag, or from an SVG-only icon.
Why Google shows a different site name than the one you chose
When a client tells us “Google is using the wrong name,” the cause is almost always one of these:
Generic name: Google says a descriptive name like “Best Dentists In Iowa” is unlikely to be selected unless it is a well-known brand, so “Top Rehab in Orange County” will usually lose to your domain.
Inconsistent home page signals: Google weighs WebSite structured data most heavily but also reads og:site_name, the <title> tag and headings, so a schema name that disagrees with your title tag weakens your preference.
Name already taken: Google generally won’t give two global sites the same site name, which matters for treatment centers whose brand shares a name with a larger organization.
Subdirectory expectations: Google supports one site name per domain or subdomain and none at the subdirectory level, so example.com/adolescent-program can never carry its own name.
Duplicate home pages with different markup: Google asks that HTTP, HTTPS, www and non-www versions of the home page all carry the same structured data, not only the canonical one.
Stale crawl after a rebrand: Google says recrawling can take anywhere from a few days to a few weeks after a change, and interior pages update on their own schedule after the home page does.
That last one is common in behavioral health, where facilities get acquired and renamed. The new name goes up on the site, the old one stays in search results for weeks, and someone assumes the SEO is broken. Usually it is a crawl timing problem, and the fix is to confirm the markup is right and request indexing of the home page in Search Console.
The WebSite structured data that states your preference
The markup lives on the home page only. It needs two required properties, name and url, defined on the Schema.org WebSite type, and it takes an optional alternateName, which can be a list in order of preference:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Example Recovery Center",
"alternateName": ["Example Recovery", "examplerecovery.com"],
"url": "https://www.examplerecovery.com/"
}
</script>Two details in Google’s documentation are easy to miss. First, if you add your domain as the last alternateName, it must be all lowercase for Google to treat it as a site name preference. That gives Google a clean fallback instead of something it builds from headings. Second, if your SEO plugin already outputs a WebSite node, add the properties to that node instead of pasting in a second block. We often find two WebSite nodes on one home page when a theme and an SEO plugin both write schema, and they rarely agree.
When we checked our own homepage while writing this post, the WebSite node carried the name “Relative Marketing Group” with no alternateName, while our title tag ends in “RMG.” That is exactly the kind of small mismatch described above. It rarely causes a visible problem, but it’s worth closing so Google has nothing to second-guess.
Test in the right tool
This catches people out: the Rich Results Test does not support site names. Paste your home page into it and you will see nothing about site names, which looks like the markup is missing when it may be fine. Google points to the Schema Markup Validator for syntax checks and to the URL Inspection tool in Search Console to confirm Googlebot can reach the home page.
Here is the check to run today. It takes about ten minutes:
- Open your home page, view the source, and search for
"WebSite". Count the nodes. There should be one, and itsnameshould match what you call yourself in the title tag andog:site_name. - In the same source, search for
rel="icon". Open each icon URL directly. Confirm it loads, is square, is larger than 48×48 pixels, and is not SVG-only. - Open
yoursite.com/robots.txtand make sure nothing blocks the folder the icon lives in. - Load the http://, https://, www and non-www versions of your home page. They should all redirect to one version, or all carry identical markup.
- Paste the home page URL into the Schema Markup Validator at validator.schema.org and fix any errors.
- In Search Console, run URL Inspection on the home page and request indexing. Then give it a few weeks.
When to stop tuning
If the markup is correct, consistent and crawlable and Google still picks something else, Google’s own suggested last resort is to set your lowercase domain as the preferred name. We only recommend that after the alternateName route has had a full recrawl cycle to work. A domain name in the result looks less polished than a brand, but it is accurate, and it beats an old name from before an acquisition.
These are small details, and they’re the kind that get missed when a site is built quickly or changes hands. We check them as part of every technical SEO engagement and set them correctly at launch on every website we build. If you are working on how your brand appears in AI-generated answers as well as classic results, our answer engine optimization work starts from the same place: a home page that states clearly and consistently who you are.
