[Findability] Landing page prototype

[KOTungseth]

Closes https://github.com/elastic/docs-content-internal/issues/1018.

Summary of changes

Replaces the previous hero/card layout with a search-first design:

• Version disambiguation banner with link to 8.x docs
• Prominent search bar with What's new ribbon
• Analytics-driven popular destinations grid
• Get started cards (local, cloud trial, fundamentals)
• Browse by solution (Search, Observability, Security) with sub-links
• Full product index categorized by stack, cloud, ingest, query languages, APM agents, and developer tools
• Scoped CSS replacing Tailwind utility classes

Guiding principles for changes

Most landing page guidance is written for marketing and ecommerce contexts, which primarily focus on conversion funnels, single CTAs, social proof, and urgency. That advice doesn't translate cleanly to documentation.
A documentation landing page has a different job. Users aren't being persuaded because they've already decided to use the product. They arrive with a specific task in mind, at varying levels of familiarity with the docs site structure. The landing page succeeds when it gets them to the right content as quickly as possible, and fails when it makes them work to find it.

Principle 1: Serve task-focused users first

The majority of users landing on the Elastic Docs homepage are focused on completing a specific task. They know what they want and they want to reach it in one click. They are not browsing or evaluating whether to use Elastic.
This prototype is designed for this user first. Every element that isn't a direct route to content is friction.

What this means in practice:

• Lead with search. The search bar is the most important element on the page. It should be above the fold, visually prominent, and fast to load. For users that want to complete a specific task, it replaces the entire page structure.
• Surface the most visited pages directly. The current Elastic Docs landing page is designed by product, task category, and internal team structure. These are reasonable starting points, but they're not the same as what users actually need. Our search queries and pageview data tell us what users came for. We should use them. The CTAs on the landing page are data-informed. We know where users are going, and we don't want to make them rediscover the pages they need through navigation.
• Minimize decorative content. Introductory copy, product descriptions, and feature callouts serve discovery-based users, not task-focused users.

Principle 2: Acknowledge multiple user intents without serving all of them equally

The Elastic Docs landing page typically serves at least three distinct user types:

• Task-focused users — Returning users who know what they want
• Getting started users — New users who need orientation and a clear first step
• Discovery-focused users — Users evaluating Elastic, exploring what's possible, or looking for features they don't know exist yet.

If we design for all three of these user types equally, we'll produce a cluttered page that serves none of them well.

This design prioritizes in this order:

• Task-focused
• Getting started
• Discovery-focused (what's new, feature highlights, use case showcases should be present, but lightweight)

If you cover the search bar with your hand and ask whether the remaining page structure routes a new user to the right starting point in one click, the getting started content is doing its job. If you ask whether a returning user looking for a specific reference page can find it without thinking, the task-focused routing is also doing its job.

Principle 3: Make version and edition complexity visible, not hidden

The Elastic Docs site serves multiple product versions, deployment models, and products. Users frequently don't know the version they're on, which version the docs default to, or where to go if they're on an older version. We want to make sure we are not confusing users with our version/model/product layers. A user who follows installation instructions for the wrong version loses significant time and trust.

What this means in practice:

• State the default version prominently. The majority of Elastic Docs docs default to the latest Stack version, and we should say that.
• Provide a direct route to legacy versions for users who need them. The majority of our users are on older Elastic Stack versions, and we need to give that path equal or greater prominence than the current version.

Principle 4: Distinguish between navigation and content

The Elastic Docs landing page is navigation infrastructure, not content. Its job is to route users to content, not to contain it. This distinction matters because it shapes what belongs on the page. Landing pages that try to contain content (summarizing every product area, explaining what Elasticsearch is, describing use cases) become long, hard to maintain, and slow to scan.

What belongs on a docs landing page:

• Search
• Routes to high-traffic content (most visited pages, getting-started paths, installation guides)
• Version and edition disambiguation
• Product/topic navigation (where the product surface area is large enough to need it)
• A lightweight signal for discovery-mode users (what's new, release highlights)

What doesn't belong on a docs landing page:

• Marketing copy or product descriptions
• Detailed feature explanations
• Tutorial content
• Community links (unless analytics show significant demand)
• Anything that requires maintenance to stay accurate at the content level

Principle 5: Name things the way users name them

The landing page uses task-base terms that don't always match how users search. This creates a gap between the landing page labels and the search terms users arrive with.

🤖 Generated with Claude Code.