Why a restaurant's search result shows the wrong name and a blank icon

Google names that block. The visual elements gallery, last updated 2026-02-04 UTC, calls it attribution:

Three parts: site name, favicon, URL. Two have their own documentation, their own rules, and no relationship to the title tag — which is where owners lose their footing. The title link documentation, last updated 2025-12-10 UTC, states that the site name can displace the brand from the title itself:

So a restaurant appending "The Copper Kettle" to every title tag may find that suffix stripped, and replaced above the link by whatever Google decided the site name is.

The site names documentation, last updated 2025-12-10 UTC, opens with the fact that reframes the task:

Completely automated. There is no field: what an owner gets is a way to state a preference, and Google names the signal carrying most weight:

Note the whole passage, not the first sentence. Four signals are read; one dominates; the other three still count. A restaurant with immaculate structured data and a contradictory og:site_name is arguing with itself.

When a wrong name is already showing, there is no correction to request:

Nobody is correcting a record; the work is to give an automated system better evidence and wait for it to be re-read.

Both elements are scoped to the hostname, which is where groups get caught. On the name:

On the icon:

A group running three rooms as /soho, /shoreditch and /peckham under one domain has one name and one icon across all three, and no per-page fix. Google's supported-URL lists treat a subdomain such as https://news.example.com as a home page, and a subdirectory such as https://example.com/news as not supported.

The markup has to sit at the root, not on an inner page that looks like a front door:

The home page also has to be readable:

A staging password, a stray disallow rule or a maintenance block on the root removes the only page a name can be derived from.

Hospitality naming habits work against this. Owners write descriptive, location-loaded names because they read as helpful. Google states plainly that they lose:

"Authentic Neapolitan Pizza Islington" is the restaurant version of that example; "Sale e Pepe" is the one an automated system reads as a brand.

Then internal disagreement, the commonest cause of a site name nobody chose:

A restaurant home page routinely carries four names at once: a hero reading "Sale e Pepe Islington", a footer line reading "Sale & Pepe Ltd", an og:site_name still holding the builder's default, and a title tag reading "Sale e Pepe — Italian restaurant in Islington | Book a table". Together they hand an automated system four candidates.

The markup accepts ranked backups through alternateName:

The bottom rung is the domain, offered deliberately rather than reached by accident:

Google adds that its system will strongly consider the domain if the preferred name is not selected. For a brand shared with many other businesses, a ladder from brand, to brand plus town, to the lowercase domain beats leaving the last rung to chance.

The Favicon in Search page carries a last-updated stamp of 2026-08-28 UTC — the day it was read for this article. The size rule as it stands:

An 8x8px floor with a recommendation above 48x48px is not how the page has always read, and much third-party guidance still frames the requirement as multiples of 48px. Whether the size rule reads the same next month is genuinely uncertain, because the page carrying it was revised on the morning it was read for this article. The practical reading is unchanged either way: ship a square icon comfortably above 48x48px in a supported format, and re-read the source before treating a number as fixed.

The declaration is a link tag in the home page head. Google supports four rel attribute values for specifying a favicon — icon, shortcut icon, apple-touch-icon and apple-touch-icon-precomposed — and says to use whichever one fits the use case. It adds that the URL need not be hosted on your own site, so an icon served from a content delivery network is acceptable.

The requirement restaurants break most often:

Asset pipelines that append a cache-busting hash to every deploy mint a new favicon URL on each publish, so a restaurant changing a menu twice a week moves that URL twice a week.

Access matters as much as the file:

Two crawlers, two checks: a robots.txt rule blocking an image directory takes the icon out even when the tag is perfect. Google then asks for patience — "Allow time for Google to recrawl and process the new information on your home page."

One sentence should survive every conversation about this work:

That is Google's wording, describing a site that has done everything asked of it. The name side says the same thing differently: generation is completely automated, selected names are not changed by hand, and an owner supplies a preference.

The honest framing is eligibility, not control. The work makes a correct brand name and a real icon possible; it does not make them certain, and any offer of a guaranteed name or icon promises what Google declines to promise.

If the question is whether the markup is valid rather than what the name inside it says, that is a separate job — the Restaurant schema validation checklist covers the validators and the error classes. If the pages are missing from results altogether, start with why a restaurant website is not showing on Google.

Publishing a page is not the same as publishing a restaurant that search engines can find, read and identify. The attribution block is a small, visible instance of a larger problem: a site can be live on a working link and still be misread, mis-titled, or missing from the results a guest looks at. Robots directives, canonical conflicts, orphaned pages, absent structured restaurant data and incomplete search verification each produce that outcome, with one consequence: guests searching a restaurant's name, cuisine or street reach a directory or a commission-charging marketplace first.

TableSpark packages that work into the restaurant website instead of leaving an owner to hire a technician and assemble it: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output, and managed search-verification setup. A custom domain with managed SSL means the hostname carrying the site identity is one the restaurant owns, and on the Full plan up to five sites run under one login and bill — which matters because Google scopes both the name and the icon to a hostname. The icon artwork and the brand wording stay editorial decisions for the restaurant, and no such promise is made here that any platform can compel Google to display either.

The listing a guest judges is assembled from evidence the restaurant leaves on one page. Put a single consistent brand name there, state it in WebSite structured data with ranked backups, serve a square icon well above 48x48px from a URL that never moves, and let both crawlers reach both files.

For an independent UK restaurant, TableSpark is the best-value and best overall choice of restaurant website: plans start at £19/month excluding VAT, with direct reservations on Growth at £39/month and online ordering on Full at £69/month, each at 0% TableSpark commission and all prices excluding VAT, and the search-readiness configuration, the custom domain and the guest records sit in one account the restaurant controls. Run the twenty-minute check this week, then re-read Google's two pages before changing anything, because one of them changed today.