Google Still Shows Your Old Brand Name? Here’s Why

TL;DR — Direct Answer – The bold name Google shows above your URL is called the “site name,” and it is computed separately from normal indexing — updating your title tags and structured data does not force it to refresh. – Google draws the site name from several signals at once: WebSite structured data, the og:site_name meta tag, the homepage <title>, and — critically — how the rest of the web (links, directories, profiles) refers to you. – Redirects, sitemap resubmission, and “request indexing” fix crawling and ranking. They do not directly fix the site name, which is a slower, signal-weighted recomputation that can lag real content changes by weeks. -The fastest path to a fix is closing every gap in signal consistency at once — on-site, off-site, and platform-level — rather than repeating the same re-indexing request and waiting.

The Problem

A site goes through a full rebrand: new name, new logo, new domain or subdomain, new everything. The team does the job properly — every page carries the new brand in its <title> tag, meta description, and Open Graph tags. Structured data (Organization and WebSite schema) is updated sitewide. Redirects are in place, the sitemap has been resubmitted, Search Console’s Change of Address tool has been run where applicable, and individual URLs have been submitted for re-indexing.

Weeks pass. The site is fully crawled under the new brand. Rankings are intact or recovering normally. But when someone searches for the site by name or navigates to it through Google, the bold text above the URL — the “site name” — still shows the old brand.

This is a narrow, specific failure. It is not a ranking problem, not an indexing problem, and not something that shows up in a Screaming Frog crawl or a Lighthouse audit. Nearly every generic SEO audit will come back clean, because everything the audit checks — titles, canonicals, redirects, schema syntax — is genuinely correct. That’s exactly why it’s confusing: the fix that should have worked, on paper, already happened.

Why This Happens: The Actual Mechanics

Google’s “site name” feature (the bold label shown above the URL on both desktop and mobile results) is not the same thing as your page title, and it is not generated the same way. It is a separate, algorithmically-computed entity label, and understanding that distinction is the whole diagnosis.

1. Site name is computed independently of indexing

Re-indexing a page tells Google to re-crawl and re-evaluate that URL’s content for ranking purposes. It does not, on its own, trigger Google to recompute what it displays as your “site name” across the domain. That’s a separate process that runs on its own schedule and re-evaluates signal weight across the whole site, not per-URL. This is the single biggest reason the standard playbook — redirects, sitemap, re-indexing — doesn’t touch this specific problem. Those steps fix crawling and ranking. They were never going to fix the site-name label by themselves.

VERIFIED — Google’s documented behavior Google has publicly stated that the site name shown in results is generated from a combination of on-page signals and is not simply pulled from the <title> tag, and that changes can take time to be reflected because the system re-evaluates signals rather than reading them live on every query.

2. It draws from multiple signals, weighted — not one field

The signals Google has referenced for this feature include, in rough order of how commonly they’re the actual gap:

• WebSite structured data — the “name” property in your sitewide JSON-LD.
• The og:site_name Open Graph meta tag — a field that’s easy to update in a page title but easy to forget in a platform’s global SEO settings.
• The homepage <title> tag specifically, more than title tags on interior pages.
• How consistently the new name appears across the site as a whole, not just on one or two priority pages.

A rebrand that updates the visible <title> on every page but leaves og:site_name untouched, or updates og:site_name but leaves the WebSite schema “name” property pointing at the old brand, is sending Google mixed signals from the same domain. Mixed signals get resolved conservatively — usually in favor of whichever signal has more history behind it, which is almost always the old name.

3. Off-site signals carry real weight

This is the gap most teams miss entirely, because it isn’t fixable from the CMS. Google’s entity understanding of a brand isn’t built solely from the site itself — it’s reinforced by:

• Backlink anchor text from other sites still using the old name.
• Business directories, review platforms, and citation sources (Google Business Profile is a major one if the site has any local/business presence).
• Social media profile names and bios.
• Any existing Knowledge Graph / Knowledge Panel entity tied to the old brand.
• Press mentions, guest posts, and partner sites that reference the company by its former name.

If ten external, often higher-authority sources still call the business by the old name while the site itself says the new one, the old name can remain the stronger signal in aggregate — even though the domain owner has done everything right on their own property.

DISPUTED — weighting is not published Google has never published the exact weighting between on-site and off-site signals for this feature, or a precise threshold for how much off-site consistency is “enough.” Everything about relative signal strength here is informed inference from documented behavior and observed recovery patterns, not a disclosed formula.

4. Structured data “name” vs. “alternateName” confusion

A common, well-intentioned mistake during a rebrand: adding the old brand as “alternateName” in Organization/WebSite schema, to “help people who still search the old name find us.” This is reasonable for user-facing search behavior but works against the fix here — it gives Google an explicit, structured signal that the old name is still a valid, current label for the entity, which can actively slow down the transition rather than speed it up.

5. Platform-specific settings that don’t live where you’d expect

On page-builder platforms (Webflow is a common example), Open Graph and site-name-adjacent fields often live in a separate global settings panel — distinct from the per-page SEO fields most teams update first. It’s entirely possible to update every page’s title and meta description, update the visible schema through a custom embed, and still have a sitewide “Open Graph Site Title” or similar global field sitting untouched in project-level settings, because it’s not visible from the page editor and nothing flags it as out of sync. This single overlooked field is one of the most common root causes of exactly this symptom.

VENDOR CLAIM — verify against current settings Page-builder platforms change their settings panels over time. Confirm the exact location of global Open Graph / site name fields against the current version of your platform’s own settings before assuming this is (or isn’t) the gap — don’t rely on older screenshots or outdated help docs.

Diagnostic Checklist: Find Your Actual Gap

Work through these in order. The goal is to find which signal is still inconsistent, not to redo work that’s already correct.

1. View source on the homepage specifically. Confirm the og:site_name meta tag exists and says the new name — not just the <title> tag.
2. Pull the site’s JSON-LD (via Google’s Rich Results Test or a manual view-source check) and confirm the WebSite/Organization “name” property is the new brand, and that the old brand is not present as “alternateName” unless that’s a deliberate choice.
3. Check the platform’s global SEO/social-sharing settings panel — not just individual page settings — for a separate site-name or Open Graph field.
4. Run a search for the old brand name in quotes alongside your domain to see how many external sites, directories, and profiles still use it.
5. Check Google Business Profile (if applicable) and confirm the business name field matches the new brand exactly.
6. Search for the old brand name directly in Google to see whether a Knowledge Panel still exists under it — that’s a separate entity record that needs its own correction path.
7. Confirm consistency: is the new name used identically (not just similarly) across title tag, og:site_name, schema, footer copyright text, and social bios?

The Fix

On-site

• Set og:site_name explicitly on every page — don’t assume it inherits from the <title> tag. On page builders, set it at the global/project level, not per-page.
• Confirm WebSite and Organization structured data both carry “name” as the new brand, sitewide, not just on the homepage.
• Remove the old brand from “alternateName” unless you have a specific, deliberate reason to keep the association — and if you do, treat it as a temporary transition setting to remove later, not a permanent fixture.
• Keep the homepage <title> tag exact and consistent with the new brand — this page carries more weight than interior pages for this specific signal.

Off-site

• Update Google Business Profile, industry directories, and any citation sources to the new name — this is frequently the highest-leverage fix outside the CMS.
• Update social profile names/bios so they match the site exactly.
• Reach out for anchor-text updates on a handful of your highest-authority existing backlinks where feasible — you don’t need volume, you need your strongest existing signals pointing the same direction.
• If a Knowledge Panel exists under the old name, claim/verify it and submit a correction through Google’s own feedback flow for that panel — this is a distinct process from standard Search Console fixes.

Process

• Do not repeat “request indexing” as a troubleshooting step once the page is confirmed indexed — it isn’t the lever that moves this. Fix signals, then wait.
• Re-run the diagnostic checklist after every fix rather than assuming one change resolved everything — mixed signals from a partial fix can be as slow to resolve as no fix at all.
• Track the site name specifically (not just rankings or impressions) as its own signal to monitor, since it can lag behind otherwise-healthy indexing and traffic data.

What to Expect on Timeline

Once every on-site and off-site signal is genuinely consistent, the update is not instant. This is a recomputed entity label, not a cache that clears on the next crawl. Teams that have gone through this typically report the change resolving over a period of weeks rather than days — and it can take longer if strong off-site signals (an established Knowledge Panel, a large volume of old backlink anchor text) are still working against the new name in the background.

FAQ

Does resubmitting the sitemap fix the site name in search results?

No. Sitemap resubmission affects what Google crawls and how quickly, not the separately-computed site name entity. It’s a necessary step for indexing but not a lever for this specific problem.

Is the site name the same as the <title> tag?

No. The <title> tag is one input among several. The site name is a distinct, algorithmically-determined label that also draws on structured data, og:site_name, and signal consistency across the site and the wider web.

Should I keep the old brand name as “alternateName” in schema to help people find us?

Only as a deliberate, temporary transition choice — and understand that doing so gives Google an explicit signal that the old name is still valid, which can slow down the switch to the new one.

We changed everything on our own site — why isn’t that enough?

Because the signal isn’t sourced from your site alone. External references — directories, backlink anchor text, social profiles, and any existing Knowledge Panel — are part of the same computation, and they don’t update just because your own pages changed.

How long should we wait before assuming something is actually broken?

Confirm every item on the diagnostic checklist is genuinely resolved first — most “still broken after weeks” cases trace back to one inconsistent signal, most often a platform-level Open Graph field or a lingering “alternateName” entry, not a problem with Google’s processing.