What the Sitelinks Searchbox generator does
This tool builds the WebSite schema with a SearchAction that tells Google your site has its own internal search, and exactly which URL pattern a query should be sent to. When Google decides to show a search box directly underneath your homepage listing in the results, this markup is the signal that lets a searcher type a query into that box and land on your own on-site search results page instead of staying inside Google. You paste your homepage URL and your search URL template, and the generator returns a ready-to-embed JSON-LD block.
The sitelinks searchbox is a brand-query feature. It typically appears when someone searches for your company or site name and Google is confident the result is your official homepage. The markup does not create the feature on its own; it tells Google where to route the query if Google chooses to display the box. That distinction matters, and most of the confusion around this schema comes from expecting the markup alone to force the box to appear.
The two inputs that actually matter
The generator needs two real values from you. The first is the canonical URL of your site, which becomes both the url property of the WebSite object and, critically, the value Google checks the markup against. This should be your homepage at its preferred host, with or without www exactly as your site canonicalizes, and over HTTPS. The second is your search results URL with a placeholder where the query goes.
That search URL is the part people get wrong. Find out how your own site builds a search results page. If searching for the word shoes sends a visitor to a page ending in search?q=shoes, then your template is the same URL with the literal query swapped for the required placeholder token. The SearchAction target uses a urlTemplate containing that token, and a query-input property declares the token as a required string parameter named search_term_string. The generator wires both of these together so the token in the template and the token named in the query-input always match, which is the single most common reason hand-written versions fail.
What the generated JSON-LD contains
The output is a single JSON-LD script with @context set to schema.org and @type WebSite. Inside it sits a url pointing at your homepage and a potentialAction object of @type SearchAction. The SearchAction has a target, which can be a plain string urlTemplate or an EntryPoint object wrapping that template, and a query-input written as the special required name=token syntax that schema.org defines for search actions. The generator produces the EntryPoint form because it is the current, more explicit shape Google documents, but both are valid.
You place the resulting block on your homepage, and only your homepage. Unlike most schema types, the sitelinks searchbox belongs on the single page Google treats as the site root. Adding it to interior pages does nothing useful and can muddy your structured data. Drop the script into the head or body of the homepage HTML, deploy, and let Google recrawl. The markup is identical regardless of whether your homepage is static, server-rendered, or built by a framework, because JSON-LD is independent of your visible layout.
How to read the result and verify it
A correct block passes three quick reads. The url should be the exact canonical homepage. The urlTemplate should contain the placeholder token in the position where a real query would appear in your live search URL. And the query-input should name that same token. If any of the three drift apart, the searchbox routes queries to a broken or wrong page. Paste a sample query in your head where the token sits and visualize the resulting URL; if that URL would not return search results on your live site, the template is wrong.
After embedding, confirm syntax and eligibility with Google's Rich Results Test against your live homepage. It will report whether the SearchAction is detected and well-formed. Keep in mind that a clean test confirms the markup is valid and detectable; it does not promise the box will render. The searchbox is one of the features Google has scaled back over time, and its appearance is at Google's discretion based on the query and your site's prominence.
Common mistakes specific to this schema
Mismatched tokens top the list. The string inside urlTemplate and the name inside query-input must be character-for-character identical. People often rename one and forget the other, and Google then cannot map the typed query into the template. This generator removes that risk by keeping the two in sync, but if you later hand-edit the output, re-check them.
Putting the markup on the wrong page is the second trap. The searchbox is a homepage feature tied to your site's root, so a block sitting on a blog post or a category page will never trigger it. The third is using a search URL that does not actually exist. Some sites run search through a JavaScript overlay or a third-party widget that never produces a clean, linkable results URL with a query in it. If you cannot reach your own search results by typing a URL with the query in it, you do not yet have a target this schema can use, and you need a real server-readable search endpoint first.
A subtler mistake is host mismatch. If your WebSite url says the non-www host but your real search page lives on www, or one side is HTTP and the other HTTPS, Google may distrust the markup. Make every URL in the block agree with the exact canonical form your site redirects everything else to.
WebSite SearchAction versus sitelinks and other search features
Do not confuse the sitelinks searchbox with ordinary sitelinks, the cluster of deep links Google sometimes shows under a homepage result. Those are generated automatically from your site structure and internal linking; there is no markup that creates them. The searchbox is the separate, schema-driven feature that puts an actual input field in the result. This generator only addresses the searchbox.
It is also distinct from on-page search experiences inside AI surfaces. The SearchAction here is about classic Google web results. It does not power ChatGPT, Perplexity, or AI Overviews, which read your content rather than offering a search field. If your goal is AI visibility, this schema is not the lever to pull, though having a clean, crawlable site search can still help large language models understand your site's breadth.
Where this fits in modern SEO and AI search in 2026
Structured data has shifted from a pure rich-results play to a machine readability play. Search engines and AI systems alike lean on schema to understand what an entity is and how its content is organized. The WebSite type, even just with a name and url, helps establish your site as a coherent entity and can feed your sitelinks and brand presence. The SearchAction is the optional layer on top that declares an interactive capability.
Because Google has reduced how often the visual searchbox appears, treat this markup as low-cost insurance rather than a guaranteed win. It is cheap to add, it never hurts a well-formed homepage, and on brand queries where Google still shows the box, it keeps searchers inside your own search funnel instead of bouncing them back to a results page you do not control. For a site with strong brand search volume and a genuine on-site search engine, that retained traffic is the real payoff.
The EntryPoint and query-input syntax in plain terms
Two details in this schema trip up almost everyone, so it helps to understand them in plain terms. The target can be written either as a bare urlTemplate string or as an EntryPoint object that wraps the same template under a urlTemplate property. Both are valid; the EntryPoint form is simply the more explicit, current style and is what the generator emits. There is no behavioral difference for Google, so do not waste time agonizing over which to use, but do keep your choice consistent rather than half-converting an old block.
The query-input is the genuinely unusual part. It is not an ordinary property value; it is a special string written in the form required, then name, then your token. That syntax declares that the search action expects a required text input and names the exact placeholder that the urlTemplate uses for the query. Because it is a fixed micro-syntax rather than free text, a single typo, a missing keyword, or a token that does not match the one in the template will quietly break the whole searchbox. The generator writes this string correctly and keeps its token aligned with the template, which removes the most error-prone part of building this schema by hand.
What to do after you generate the markup
Copy the JSON-LD, paste it into your homepage template, and deploy. Run the Rich Results Test on the live URL to confirm the SearchAction is detected and free of errors. Then trigger a recrawl by requesting indexing of your homepage in Search Console so Google picks up the change sooner than its natural schedule. Search for your brand a few days later and watch whether the box appears; if it does, test typing a real query to confirm it lands on your live results page rather than a 404.
If the box never shows after weeks, that is normal and not a sign your markup is broken. Verify the schema is still valid, make sure your internal search works and is crawlable, and keep your brand-query presence strong. The markup is doing its job by being present and correct; the rest is Google's call. Meanwhile, audit the rest of your homepage schema so the WebSite block sits alongside a clean Organization or LocalBusiness entity, giving search engines a complete, consistent picture of who you are.