[Findability] Landing page prototype

[KOTungseth]

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

Demo: https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3250

Summary of changes

• Prominent search bar above the fold
• Two primary destination cards: "Learn how to use Elastic" (fundamentals) and "Elasticsearch", which are the two highest-traffic destinations, accounting for ~50% of all landing page clicks
• "New to Elastic?" section with local install and Cloud trial paths
• What's New section with recent release highlights
• Full product index categorized by platform, solutions, deploy, ingest tools, query languages, APM agents, and developer tools & standards
• Support link for reporting docs issues
• Optimizations for machine reading
• 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: 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)
• Product/topic navigation (where the product surface area is large enough to need it)
• A lightweight signal for discovery-mode users (what's new)

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 4: Make the page readable by machines, not just people

An increasing share of documentation traffic comes through AI intermediaries, including LLM-powered search, coding assistants, support bots. These agents need semantic HTML, structured metadata, and a machine-readable site index to route users to the right content. If an AI agent can't parse the page hierarchy or understand what each section contains, it will hallucinate answers instead of linking to the right docs.

Principle 5: Name things the way users name them

The landing page uses task-based 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.