Sitelinks search box on 27 homepages: 7 still ship markup for a feature Google retired in 2024

FIELD TEST · 2026-09-06 · 27 homepages · one request each · markup for a retired search feature

Sample and method: 30 homepages fetched once each on 2026-09-06 with a desktop Chrome user agent, redirects followed, no JavaScript executed, exit node in Japan. Three dropped out — stackoverflow.com, medium.com and www.reddit.com each returned 403 — leaving 27. Only JSON-LD was parsed; no microdata, no RDFa.

Google stopped showing the sitelinks search box on November 21, 2024. On these 27 homepages, 7 still declare the search action that fed it. The honest denominator is 13, not 27: only 13 sites carry a WebSite object at all, and the other 14 never had a place to put the markup. The half of that object Google still supports — the site name — is the thinner half.

How we measured this

One GET per site, desktop Chrome user agent rather than Googlebot, redirects followed, bodies written to disk. From each saved page we pulled every application/ld+json block, parsed it as JSON, walked the graph for objects typed WebSite, and recorded four things per site: whether a search action was declared, how its target was written, how its search term input was written, and what name and alternate name the object carried.

# Read the same four things from your own homepage
curl -sL -A 'Mozilla/5.0' https://example.com/ > home.html
grep -c 'application/ld+json' home.html
grep -c '"WebSite"' home.html
grep -c 'SearchAction' home.html
grep -c 'alternateName' home.html

Every block we found parsed. Zero parse failures across 27 homepages — worth saying out loud, because broken JSON-LD is the failure people expect here and it did not happen once.

Four limits, all of them load-bearing. One request per site, homepage only, and a homepage is not a site. JavaScript was not executed, so anything a tag manager or a front-end framework injects at runtime is invisible to this measurement, and that alone could account for some of the 10 sites where we found nothing. Only JSON-LD was read; microdata and RDFa were not. And a declaration in the HTML is not evidence that Google shows anything for that site — we did not check a single live search result, and from one fetch we cannot tell whether a search action is a leftover nobody has touched or a deliberate keep.

Split the 27 before reading the number

Seven out of 27 sounds small. Seven out of the 13 that could have carried it sounds like half the field. Both are true, and the second is the number that means something, because a site with no WebSite object was never in a position to declare a search action in the first place.

The 10 carrying nothing are developer.mozilla.org, linear.app, news.ycombinator.com, substack.com, www.wikipedia.org, slack.com, www.notion.com, github.com, astro.build and react.dev. The 4 that ship structured data on the homepage without a WebSite object are www.figma.com and www.framer.com, which declare an organization and stop; www.bbc.com, which declares a news organization type plus a page type; and vercel.com, which declares eight types and none of them is WebSite.

Seven homepages still declare the sitelinks search box markup

Seven of the 27 carry a search action inside their WebSite object: railway.com, arstechnica.com, techcrunch.com, www.nytimes.com, www.cloudflare.com, www.wired.com and www.theverge.com. Five are publishers, two sell infrastructure, and all seven were serving this on a homepage fetched nearly two years after the element it feeds stopped rendering.

Google announced the removal on October 21, 2024: "we'll be removing this visual element starting on November 21, 2024" (Farewell, Sitelinks Search Box, Google Search Central, read 2026-09-06). The same post says the change "will apply globally across all search results, in all languages and countries", that it "doesn't affect rankings or the other sitelinks visual element", and that Google would "remove the Search Console rich results report for it and stop highlighting the markup in the Rich Results Test". No report, no test surface, no element. The markup is still on the page.

The shapes disagree, and one target is not a search page

Five of the seven wrap the target in an EntryPoint object; two give it as a plain string. Six declare the search term input in the old string form; one, techcrunch.com, uses the object form. Seven sites, three combinations of those two fields, and nothing pulling them together — which is what happens to a format after the thing that read it stops reading.

One of the seven does not point at a search page. The template on railway.com resolves to its deploy page rather than to a list of results; the other six all point at a real site search path on their own host. We cannot tell from a single fetch whether that is a paste that was never finished or a deliberate reuse of a slot that no longer renders. We only know what the homepage said on 2026-09-06.

Markup outlives the feature that read it, because nothing sends your homepage a deprecation notice.

The supported half: website schema and the Google site name

The same WebSite type is still doing a job, and the farewell post says so on its way out: "If you decide to remove sitelinks search box structured data, note that site names also uses a variation of WebSite structured data, which continues to be supported." The site name documentation is more direct — "To indicate your site name preference, add WebSite structured data to your home page" (Provide a site name to Google Search, Google Search Central, read 2026-09-06).

On this panel the supported half is thinner than the retired one. Two of the 13 WebSite objects carry an alternateName: techcrunch.com with "TC", and www.nytimes.com with a four-item list — NYT, new york times, nytimes, ny times. The other 11 give a name and stop. And one of the 13, about.gitlab.com, has the string about.gitlab.com sitting in its name field, which is a hostname rather than a site name.

Google describes site name selection as "completely automated" and says it "takes into account content from a site's home page and references to it that appear on the web", with WebSite structured data "most important, if you want to specify a preference". Alternates exist for the case where the preference loses: "you can indicate alternatives for our automated system to consider if your primary preference isn't selected". Eleven of these 13 homepages skip that field entirely.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Example",
  "alternateName": ["Example Docs", "example.com"],
  "url": "https://example.com/"
}

What this means for you

Nothing here is urgent, and Google put that in writing: "While you can remove sitelinks search box structured data from your site, there's no need to do so. Unsupported structured data like this won't cause issues in Search, and won't trigger errors in Search Console reports." So the useful move is not deletion. It is looking at what else is in that block.

1. Open your homepage source and find the WebSite object. If there isn't one, that is the actual gap — 14 of these 27 homepages are in that position, and a retired search feature was never their problem.
2. Read the name field the way a stranger would. One site on this panel has its own hostname sitting there, which is roughly what an automated system would have guessed without any help.
3. Add an alternateName when people call your site something other than its formal name. Two of 13 here do it, and Google's documentation says that is exactly the field for a preference that might not win.
4. Leave the search action alone unless you are already editing that block for another reason. Removing it buys nothing Google has described, and a bad edit to a live JSON-LD block costs more than a dead property does.
5. If you keep it, check where the target points. One of the seven sites here points at something that is not a search results page, and nobody would have noticed, because nothing renders it.

Which types are still worth carrying, given what reads them now, is the subject of schema markup for AI search; the publisher half of the same block is counted in organization schema across 27 homepages. To read what your own homepage delivers before anything runs, see what QueryWin reads from a homepage.

Common questions

How did you measure this?

One GET per homepage on 2026-09-06, desktop Chrome user agent, redirects followed, bodies saved to disk. JSON-LD blocks were extracted from the delivered HTML and parsed; objects typed WebSite were read for name, alternate name and search action, and the target and input shapes were recorded per site. No JavaScript ran. Exit node in Japan. Three of the 30 sites returned 403 and were dropped before analysis.

Should I remove sitelinks search box schema?

Google says there is no need — unsupported structured data of this kind "won't cause issues in Search, and won't trigger errors in Search Console reports". If you are rewriting that block anyway, dropping it costs nothing either. We have no data on either outcome, because we measured what sites declare and not what happened to them afterwards.

Did the sitelinks search box ever come back?

Not according to anything Google has published. The 2024 announcement said the removal applies "globally across all search results, in all languages and countries". This measurement checked no live search results at all, so on that point we are relying on the announcement rather than on observation.

Does website structured data still do anything?

Yes, for the site name. Google's documentation names it directly: "To indicate your site name preference, add WebSite structured data to your home page." The same page warns that you are expressing a preference rather than setting a value, since "we can't manually change automatically selected site names", and asks for a name that "accurately reflects the identity of your site and isn't misleading for users".

Why do 10 homepages carry no JSON-LD at all?

We do not know. Our fetch executed no JavaScript, so a site that injects structured data at runtime looks empty from here, and some of the 10 are probably in that group rather than shipping nothing. One request per homepage cannot separate the two.