Google Search profile badge: 2 of 1,093 home pages referenced it, both as data Google never asked for

What is the Google Search profile badge, and what does Google ask you to add?

The guide is short and its requirements are unusually concrete, so they are worth stating exactly. It says a Search profile brings together your content from across the web and social platforms into a single destination on Google, and that following a profile increases the likelihood that linked content appears on Google Discover. Those are the page's claims about Google's own product, reported here rather than tested by us.

The instructions to a site owner are three steps. Claim the Search profile, which the guide hands off to a Google support article. Find the profile URL, using the pattern the page gives: https://profile.google.com/@handle, replacing handle with the profile handle. Then download the badge assets and place them, following the brand guidelines.

What follows is the part that matters for anything measuring what a crawler can read, and it is the absence rather than the presence. The requirements the guide actually spends its words on are presentational. Keep the clickable target at least 48 by 48 dp on Android and 44 by 44 px on iOS and web. Do not stretch, distort, rotate or recolour the Super G icon or the Search profile button. Do not mix monochrome badges with colourful ones. There is a text-link alternative for a byline or a bio, and the guide suggests the wording: Find us on Google Search.

Nowhere in it is there a property, a type, a meta element or any other declaration. The badge is an anchor wrapped around an image, governed by a style guide. Compare that with the site names documentation, which carries the date 10 December 2025 and names the exact type and properties Google reads for a site name: a WebSite node with name and url required and alternateName recommended, placed on the home page. One Google page asks for data and says which fields. The other asks for a 44 pixel tap target. Both are about who you are, and only one of them is something a crawler reading bytes can evaluate.

An image points a reader outward, a declaration points a machine inward

The distinction is not pedantry, because the two things travel in opposite directions and only one of them lands anywhere a scanner can see.

A badge is an outbound link. It sits on your page and sends a human to a Google-hosted destination, where the aggregation the guide describes happens on Google's property rather than yours. Whatever value it carries is audience value: a reader who clicks arrives somewhere that collects your content. Nothing about that link is a statement to a crawler about who publishes the page it sits on, and the guide does not claim otherwise. We have no measurement either way on whether Google treats the presence of a badge as a signal, and we are not going to guess: the guide does not say it does, and absence of a claim is not a claim of absence.

A declaration runs the other way. A WebSite node with a name, an Organization node with a sameAs list, an og:site_name: these sit in the bytes a crawler already fetched and require no click from anybody. That is why they are the thing this site measures and the thing its methodology weights. When we read 1,080 home pages on 26 September 2026 we found that 412 of them named their site in neither of the two sources Google's own documentation ranks first, and that is a finding precisely because those two sources are readable without executing anything or following anyone.

So the badge is not a competitor to the data layer and it is not a substitute for it. It is a different instrument aimed at a different target. The reason to be careful about this is that the two get conflated the moment a vendor page lists them together, and a site owner who adds a badge and believes they have improved their AI visibility has added an image. The honest reading of Google's two pages, side by side, is that the data one is the one with the stated mechanism.

How many home pages reference a Search profile at all?

Lantad requested https://host/ once for each of the 1,419 hostnames in this repository's two committed corpus seed files on 3 October 2026, identifying as LantadBot, following up to five redirects with a twenty second timeout, from one network location, with no JavaScript executed. 1,093 answered with an HTML body a crawler could read. 219 answered HTTP 403 and 57 answered HTTP 503, which is the refusal rate this corpus has produced consistently and which we have written about separately after 103 of 1,089 sites served an unknown bot and then refused GPTBot. 20 hostnames did not resolve and 8 timed out. One, ramp.com, answered HTTP 200 with a content type of text/markdown rather than HTML.

Across those 1,093 pages, the string profile.google.com appeared on two: france24.com and lamoncloa.gob.es. Zero carried the wording the guide suggests for a text link.

Two out of 1,093 is a number that needs its caveats said out loud rather than buried. The guide is seventeen days old as of this measurement, so this is an adoption rate for a feature that has barely had time to be read, let alone deployed, and nobody should take it as evidence that the feature has failed. A Search profile also has to be claimed before a badge can point at one, and eligibility for claiming is not something this corpus can see: a site with no profile to link is not a site that declined to link one. And the corpus is 1,419 named hostnames chosen as a stratified editorial frame, not a random draw from the web, which is the same limitation every population figure on this blog carries and which the methodology page states.

What the number is good for is a baseline. The guide exists, it is dated, and on this set of pages on this day the surface is essentially undeployed. Anyone who wants to know whether that changes now has a figure to compare against, taken with a stated instrument on a stated date, which is more than the usual way these things get discussed.

Both sites used a URL form the guide does not document

This is the part that made the finding worth a post rather than a line in a changelog.

Neither of the two pages carried the URL pattern the guide gives. france24.com carried https://profile.google.com/cp/CgkvbS8wNG44ZDk and lamoncloa.gob.es carried https://profile.google.com/cp/CgkvbS8wNHJrdGY. Both are a /cp/ path followed by an opaque identifier, and the guide names only the @handle form. We requested both URLs on 3 October 2026 and both answered HTTP 200, so the undocumented form resolves. It is simply not the one the page tells a site owner to use, which means either the guide is describing one of several live forms without saying so, or these two sites obtained their URL from somewhere other than the guide. We cannot tell which from the outside and are not going to speculate.

Where the URLs sit is the second surprise. On both sites the profile URL is inside a sameAs array on an organisation node in JSON-LD. On france24.com it is one of 13 sameAs entries on a NewsMediaOrganization named FRANCE 24, listed alongside the site's Telegram, WhatsApp, TikTok and LinkedIn presences and a news.google.com publications URL. On lamoncloa.gob.es it is one of 11 sameAs entries on a GovernmentOrganization named La Moncloa - Gobierno de España, alongside Instagram, TikTok, YouTube, Flickr, LinkedIn and a WhatsApp channel.

So the two sites that reference this surface both reached for the declaration the guide does not ask for, and treated a Google Search profile as what it structurally resembles: another official account belonging to the same entity. That is a defensible reading of sameAs, whose definition is a URL of a reference page unambiguously indicating the item's identity. Only one of the two, lamoncloa.gob.es, also rendered an anchor a human could click, in the header row of social icons next to its WhatsApp link. france24.com carried no anchor at all: on that page the profile URL exists only as structured data, which is to say it is visible to a crawler and invisible to a reader. That is the exact inverse of what the badge guide describes.

What a machine can already read about who runs your site

If the badge is not the declaration, it is worth asking what state the declaration is in, because that is the layer with a documented mechanism and it is the layer this corpus can measure.

Of the 1,093 readable home pages captured on 3 October 2026, 618 carried at least one JSON-LD block that parsed, and 15 blocks across the set failed to parse at all, which is the same class of defect we counted when 117 of 612 home pages with JSON-LD carried a validator-nameable fault. WebSite was the most declared type in the capture: 408 pages, narrowly ahead of Organization on 406, the type whose declared logo URLs returned no image on 44 of 433. For a type almost nobody writes about, it is the single most common node on the web pages in this sample.

Then the gaps. 365 of the 408 WebSite nodes carried a name and 43 carried none, so on those 43 the type that exists to name the site declined to. 404 of 408 carried a url. 39 of the 408 carried alternateName, the property the site names documentation recommends for a commonly recognised acronym or shorter name, and the ones that did are exactly the cases you would want it for: AHS for Alberta Health Services, M&S for Marks and Spencer, NAMI for the National Alliance on Mental Illness, SciAm for Scientific American, and on france24.com a three-entry list of FRANCE 24 English, France24 and F24. 369 of 408 left an engine to work the abbreviation out on its own.

The join is thinner still. 177 of the 408 carried publisher, the documented edge from a WebSite to the organisation behind it, and on 171 of those it resolved to an organisation node. 336 of the 408 pages carried both a WebSite node and an organisation node, and 161 of those 336 connected the two with neither publisher nor about: two typed things describing the same business, sitting in the same document, formally unrelated. That is the same disconnection we measured from the identifier side when 313 of 615 home pages put an @id on no node at all, approached through a named property instead.

Two smaller faults are worth naming because they are free to fix. 20 pages declared more than one WebSite node, leaving a consumer to choose. And five pages, gldn.com, japantimes.co.jp, kayak.com, ssense.com and webnames.ca, declared a type spelled Website rather than WebSite. schema.org defines WebSite and type matching is case sensitive, so on those five the node resolves to nothing. None of the five also carried a correctly spelled node, which means five sites wrote the markup, shipped it, and got no node out of it. A capital S is the whole difference.

What to check on your own site this week

None of this requires a tool, and the order below is deliberate: it puts the things with a stated mechanism above the thing with a style guide.

Start with the name, because it is the cheapest and it is the one Google documents the ranking of. Fetch your own home page, read the HTML rather than the rendered page, and confirm there is a WebSite node with a name that is the name of your site and not your page title or your tagline. If your organisation is known by an acronym, add alternateName, because 10 percent of the pages in this capture did and the rest are leaving the match to inference. Then confirm the WebSite node and your organisation node are actually joined, by publisher or by a resolving @id, so a consumer reading the document learns that the site and the company are the same subject rather than two unconnected things. The five signals that tell AI who you are covers that ground in more depth than a checklist can.

Then check the spelling, which sounds insulting until you remember five sites in this sample shipped Website and got nothing. Structured data is case sensitive and silent about it: nothing warns you, the page renders, and the node is simply not there. While you are in the file, confirm your sameAs list names the accounts you actually control, which is the property both of the profile-linking sites in this capture used and which we found 317 of 433 identity nodes carried on 25 September 2026.

Confirm a crawler can reach any of it. 276 hostnames in this corpus answered 403 or 503 to a declared, documented scanner, and markup nobody is served is markup that does not exist, which is the access layer the AI crawler reference enumerates token by token. What GPTBot sees answers that for one page, and the crawlability study covers how often it goes wrong at the access layer rather than the markup layer.

Then, and only then, consider the badge. It is a legitimate thing to add. The guide is clear about how, the brand rules are reasonable, and an outbound link to a destination that collects your content is a perfectly ordinary piece of audience plumbing, in the same family as the preferred sources button Google documented in August 2026. Add it if a Search profile is something your readers would use, and keep it separate in your head from the work that bears on getting cited in AI Overviews. What this blog will not tell you is that adding it improved anything a machine reads, because the guide does not say so and we have not measured it. The honest summary of a seventeen-day-old feature is that it is documented, it is barely deployed, the two sites in this sample that reference it did so in a field the guide never mentions, and the layer that does have a documented mechanism is the one with 161 disconnected organisation nodes sitting in it. If you want to see which name an engine actually gives back for your brand, that is a different measurement again, and what AI says is where it lives.