Sitelinks Searchbox Schema Generator

When someone searches for a well-known brand or website by name, Google sometimes displays an expanded result with a search box embedded directly in the listing. This is the sitelinks search box. It lets the user type a query into the search result itself and get taken directly to the search results page on that website.

You've seen this on searches for sites like Amazon, Wikipedia, YouTube, and major retailers. Below the main listing and above the sitelinks, there's a text input field with the site's logo or name next to it. Type a query, hit enter, and you land on that site's internal search results for your query. It shaves a step off the user journey by skipping the homepage entirely.

The sitelinks search box only appears on branded or navigational queries where Google is confident the user is looking for a specific website. It doesn't show up on informational or commercial queries. And it only appears for sites that Google considers sufficiently prominent and well-structured to warrant the feature. The schema markup this tool generates is a prerequisite, but Google makes the final decision about whether to display the search box based on its own evaluation of your site.

The sitelinks search box is powered by WebSite schema with a potentialAction property that defines a SearchAction. The SearchAction tells Google two things: the URL pattern for your site's internal search, and where the user's query gets inserted into that URL.

The schema structure looks different from most other structured data because it describes an action the user can take rather than a piece of content. Instead of marking up an article or a product, you're marking up a capability: the ability to search your site.

The core components are a WebSite entity with your site's name and URL, and a nested SearchAction that specifies the search URL template. The template includes a placeholder (typically {search_term_string}) that Google replaces with whatever the user types into the search box. When the user submits a query, Google constructs the full URL by inserting the query into your template and redirects the user to that page.

The entire schema block goes on your homepage and only your homepage. It defines a site-wide capability, so there's no reason to repeat it on other pages. Google reads it from the homepage and applies the search box to your branded search listing globally.

The search URL template is the URL pattern your site uses when someone performs an internal search. Finding it is straightforward.

Go to your site and search for something. Type a test query into your site's search bar and submit it. Look at the resulting URL in your browser's address bar. If you searched for "blue widget," you might see something like https://yoursite.com/?s=blue+widget or https://yoursite.com/search?q=blue+widget or https://yoursite.com/search/blue-widget.

Identify the query parameter. The part of the URL that contains your search term is the query parameter. In ?s=blue+widget, the parameter is s. In ?q=blue+widget, it's q. In /search/blue-widget, the query is embedded in the URL path.

Build the template. Replace your test query with the {search_term_string} placeholder. If your search URL is https://yoursite.com/?s=blue+widget, your template becomes https://yoursite.com/?s={search_term_string}.

Common CMS patterns. WordPress uses /?s={search_term_string} by default. Shopify uses /search?q={search_term_string}. WooCommerce uses the WordPress pattern. Squarespace uses /search?q={search_term_string}. Custom search implementations vary, but the process of finding the template is always the same: search, observe the URL, swap the query for the placeholder.

No. The schema is a prerequisite, but Google decides independently whether to display the search box. Having valid WebSite schema with a SearchAction makes your site eligible. It doesn't guarantee the feature appears.

Site prominence. The search box appears primarily for well-known websites with significant branded search volume. If people regularly search for your brand name, you're more likely to qualify. A local business with minimal branded search volume probably won't see the search box even with perfect schema.

Site search quality. Google evaluates whether your internal search provides useful results. If your search returns irrelevant results, shows mostly ads, or delivers a poor user experience, Google may withhold the search box. A site whose search regularly surfaces relevant content is a better candidate.

Sitelinks themselves. The search box appears within the expanded sitelinks display. If Google doesn't show sitelinks for your branded query, the search box won't appear either. Sitelinks and the search box are part of the same expanded listing format.

Implementing the schema is still worthwhile even if you don't see the search box immediately. Your site's prominence and authority can grow over time, and having the schema in place means the search box can appear as soon as Google decides you qualify. There's no downside to having it ready.

Yes. If you don't want Google to display a sitelinks search box for your site, you can add a meta tag to your homepage that explicitly opts out.

Adding <meta name="google" content="nositelinkssearchbox" /> to the head of your homepage tells Google not to display the search box in your branded listing. The sitelinks themselves will still appear if Google chooses to show them, but the search input field will be suppressed.

Your site search is poor. If your internal search consistently delivers bad results, the search box creates a negative first interaction. Users who search from the SERP and land on a useless results page have a worse experience than users who visit your homepage and navigate manually.

You don't have internal search. If your site has no search functionality at all, the schema has nothing to point to. Don't implement SearchAction schema on a site without a working search endpoint.

Most sites benefit from the search box and should implement the schema rather than opting out. But the option exists for cases where it creates more problems than it solves.

The WebSite schema with SearchAction belongs exclusively on your homepage. It defines a site-level capability, and Google reads it from the homepage to apply it across your branded search presence.

Placement in the HTML. Add the JSON-LD script tag to the <head> section of your homepage. It works in the <body> too, but the head is the conventional location and ensures the schema is processed early.

WordPress implementation. You can paste the schema into your theme's header.php within a conditional that limits it to the homepage: if ( is_front_page() ). Alternatively, use a plugin like Insert Headers and Footers with homepage targeting, or add it through Rank Math or Yoast's custom schema features. Some SEO plugins generate WebSite schema automatically, so check whether yours already outputs it before adding a duplicate.

Single-page apps and JavaScript frameworks. If your homepage is rendered client-side, ensure the JSON-LD is present in the server-rendered HTML or the pre-rendered output that Googlebot receives. Schema delivered only through client-side JavaScript may not be processed reliably. Use server-side rendering or static generation to guarantee the schema is in the initial HTML.

Don't repeat on other pages. Placing the WebSite schema on every page across your site is unnecessary and can create validation noise. One instance on the homepage is sufficient.

Yes. Your homepage often carries multiple schema types, and they coexist without conflict.

A typical homepage might have WebSite schema (with the SearchAction for the sitelinks search box), Organization schema (defining your business entity, logo, social profiles, and contact information), and potentially WebPage schema (describing the homepage itself). Each serves a different purpose and generates different search features.

You can implement these as separate JSON-LD blocks, each in its own script tag, which is the cleanest approach for maintenance and debugging. Or you can nest them if you prefer a single block, using the publisher property on the WebSite to reference the Organization entity.

The one thing to avoid is conflicting information between blocks. If your WebSite schema says your site name is "WidgetCo" and your Organization schema says the name is "Widget Company Inc.," you've introduced ambiguity. Keep entity names, URLs, and other shared properties consistent across all schema on the page.

Using the wrong search URL template. The most common implementation error is a template that doesn't match how your site's search actually works. If the URL pattern is wrong, users who search from the SERP get redirected to a broken page or an empty search. Always test the template by manually replacing the placeholder with a real query and pasting the resulting URL into your browser.

Pointing to a third-party search engine instead of your own. The SearchAction must point to a search results page on your own domain. Pointing it to a Google Custom Search page, an external search provider's domain, or any URL that isn't under your site's control violates Google's guidelines and won't work.

Placing the schema on every page. WebSite schema with SearchAction belongs on the homepage only. Repeating it across your entire site doesn't improve eligibility and creates unnecessary duplication.

Duplicating WebSite schema from an SEO plugin. Many SEO plugins generate WebSite schema automatically. If you add the schema from this generator without checking what your plugin already outputs, you'll have two competing WebSite schema blocks on the same page. Check your homepage source code before adding new schema.

Not maintaining the search endpoint. If you redesign your site, switch CMS platforms, or change search plugins and your search URL structure changes, the template in your schema becomes invalid. Update the schema whenever your internal search endpoint changes, and add it to your post-migration checklist as a verification step.