Change:
priority: 1.0 --- <ins> {{< site-searchbar >}} </ins> {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} [Kubernetes]({{< relref "/docs/concepts/overview/" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Add a facility to search the website to the main page, Why is this needed Let's say someone arrives at and wants to find the download page. Well, the top 3 results on look pretty relevant. The trouble is there's no form on to do that search, and it's not obvious that navigating round the site will reveal that search. Comments Consider both desktop and mobile browser use cases. The main page is some readers' first impression of Kubernetes, so it's important to make a good one. Most people known how to use Google (other search products exist) so fixing this need not be a priority.
I think this dovetails with as well. From an implementation perspective (from what I can tell) the site uses a custom google search engine. First step would be identifying who the admin(s) of that are. Second step would be identifying what directories are scanned Third step would be including the pages we now want to include. Fourth step is fairly easy – add to the layout template you want to see a search box on. The third step requires some thought, however. If we put a search box on the homepage, is the expectation that it searches the entire_ site or just the docs+blog? From a UX perspective, if I see a search box on the homepage I kind of expect it to search everything.
The site search already covers the whole site, so this is really about adding a form to the front page.
For an example of where to put a site search on the main page, see (I'm not proposing to move the search UI there across for the whole site; that would be a separate issue).
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Also relevant: issue
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /lifecycle frozen
/triage accepted
/area web-development (ish)
/priority backlog
I'm more than happy to work on it and get this moving forward. /assign
/assign