Sitelinks Search Box Removed: Cleaning Up Your WebSite Markup

Google is retiring the sitelinks search box. And the markup your SEO plugin added for it? It can stay right where it is without throwing a single error. Pulling it out is optional cleanup, not a fire drill. If you run a WordPress site or an online shop whose plugin emits SearchAction markup on the home page, here is what changes, which part of the WebSite block to keep, and what to do about internal search pages afterwards.

What is Google changing about the sitelinks search box?

The visual element stops appearing in search results starting on November 21, 2024. Globally, all languages, all countries. In its announcement about retiring the search box, Google explains that usage has dropped over time and that it wants to simplify the results page. Rankings are not affected. Neither is the other sitelinks element, the list of links shown under a result (people mix these two up all the time). And don’t go looking for it in the Search status dashboard, because the change will not be listed there.

Two tools change once the element is gone. The Search Console rich results report dedicated to it is removed, and the Rich Results Test stops highlighting the markup. So if you used either one to confirm your setup, expect silence. Not a warning, not an error. Just silence.

Do you need to remove SearchAction markup from your site?

No. Google states that unsupported structured data like this causes no issues in Search and triggers no errors in Search Console reports. For anyone who never looked under the hood: SearchAction markup is a potentialAction property inside the WebSite block that describes the URL pattern of your site’s own search, so Google could send a query straight to it.

Is removal ever worth it, then? Sometimes. You get a leaner home page source, one less plugin feature to maintain, and less head-scratching when someone audits the site later and wonders what the property is for. But leave it alone when the plugin manages the block automatically and the only way to edit it is custom code that may break on the next update. In my view that trade is a bad one.

Which part of WebSite structured data should stay?

The WebSite block itself. Keep it, because site names in Google use a variation of WebSite structured data that continues to be supported. According to the site names documentation from Google, the markup belongs on the home page only, in JSON-LD, RDFa or microdata, and is not needed on every page. One catch: site names work for domain-level and subdomain-level sites, not for subdirectories.

The classic mistake here is switching off the whole WebSite schema in your plugin when all you wanted was to drop the search action. Do that and the signal for your preferred name goes out the door along with the property you no longer need.

How to clean up the markup in WordPress or a shop

Remove only the potentialAction part and leave name and url in the WebSite block. Structured data is produced by your CMS, theme or plugin, so that is where the work happens:

1. View the home page source and find the WebSite JSON-LD.
2. Check the SEO plugin’s schema settings for a search box toggle or a documented filter.
3. Remove the SearchAction property. Nothing else.
4. Confirm that the site name in the markup is your preferred one and matches other sources on the home page, such as the title.
5. Validate the syntax.

For that last step, reach for a schema testing tool such as Schema Markup Validator, since the Rich Results Test does not support site names. Oh, and while you are in the source anyway, look for duplicate WebSite blocks. They show up when a theme and a plugin both output one. Keep a single block with the correct name.

Site search SEO: keep internal search pages out of crawling

The search box is gone from results. What’s left is the less glamorous job: making sure internal search pages do not soak up crawler attention or land in the index. Why are these URLs such a headache? Query combinations are endless, the listings are thin or duplicate existing category pages, and spam queries can generate new addresses on demand. You have two tools, and they do different things:

• robots.txt disallow for the search URL pattern stops crawling of those addresses.
• noindex keeps the pages out of the index while they remain crawlable.
• Never both on the same URL. A crawler cannot read a noindex on a page it is blocked from fetching.

Which one fits? That depends on whether the pages are already indexed and how many of them bots request. The comparison of noindex versus robots.txt disallow walks through that choice. Running a small site? Then first consider whether crawl budget matters at your scale before you sink an afternoon into fine-tuning rules.

How to check whether crawlers still hit your search URLs

Go to the logs. Server access logs show whether bots request your search parameter or path after the change. Look for requests to the search URL pattern from search engine user agents, and watch whether they decline once a disallow rule is in place. The logs live on your own origin server or NGINX, and a guide to reading crawler requests in access logs explains how to filter them. Requests still coming in? Check that the rule matches the exact pattern your search uses.

So the call is an easy one. The sitelinks search box disappears from results, its markup is harmless, and removing it comes down to tidiness. Work in this order - keep WebSite markup for the site name, drop SearchAction only if your plugin makes it convenient, and control how internal search pages are crawled and indexed.

FAQ