Discovery Reading System - Guided Content

Your article is getting traffic. Users are leaving in under 20 seconds. The content isn't the problem.

You published something long and useful. Impressions are up. But average time on page is 18 seconds, maybe less. Users arrive and leave before they reach anything that would help them. The article isn't broken. The entry point is. A 2,000-word article looks like a wall when you arrive from a search result. The reader doesn't know where their answer lives. So they leave. You've seen this pattern before, probably in your own reading habits.

Not every page needs a discovery layer. The pages that need it share a specific pattern: high impressions in Google Search Console, low average time on page. That gap means users found the page relevant enough to click, then left before the content could help them. The discovery layer targets exactly that gap. It doesn't change the article. It adds a guided entry point above it. The full article stays in the DOM. Google indexes every word. But the reader gets a path in instead of a wall.

The 2024 Google API leak confirmed what was suspected: NavBoost, Google's click-based ranking system, tracks `lastLongestClicks`. A user who reads for three minutes and doesn't return to search results is a `goodClick`. A user who bounces in five seconds is a `badClick`. This has been in production since 2005. Google's VP of Search testified about it under oath. The discovery layer is a dwell time strategy. The user gets a better reading experience. Google gets a stronger engagement signal. Both come from the same mechanism.

The steps file lives next to your `index.md`. Wire detects it automatically. If it exists, the discovery layer renders above the article. If it doesn't, the page renders normally. No errors, no empty containers. The file uses three block types: `:::hook`, `:::step`, and `

The most common failure: choices that describe topics instead of situations. "Keywords or backlinks?" is a topic choice. "My traffic never grew" versus "My traffic dropped suddenly" is a situation choice. The reader doesn't know which topic applies to them. They do know what happened to them. Each choice should read like something a reader would say to a friend describing their problem. If you can remove "I want to" from the front and it reads like a heading, rewrite it. The step syntax enforces this by design. Situation-based choices create identification. Topic-based choices create cognitive load.

On arrival: the hook and two buttons. "Guide me through this" or "Read the full article." If they choose the guide, the hook fades out and the first step card fades in. Progress dots appear. Each choice click fades the current step out and the next one in. No page reload, no scroll jump. When they click "Read the full article on this," the discovery layer collapses and the page scrolls to the matching section in the article with a brief highlight. Step IDs map directly to heading anchor IDs in the full article. That connection is what makes the handoff feel seamless instead of disorienting.

Wire doesn't automate step generation yet. The current approach: paste the article and the step syntax rules into Claude, then review every choice line before publishing. The review is the critical part. Claude defaults to topic-based choices. Your job is to rewrite each one as a situation. With practice, the full process takes 15 to 20 minutes per article. Start with your highest-impression, lowest-dwell-time pages. Run `wire.chief audit` to surface them, then work through the list in order of impression volume.

Long articles lose most readers in the first 30 seconds. Not because the content is bad. Because nobody showed them where to start. The discovery system adds an interactive guided layer above your article content. Readers make choices. The content comes to them.

How it works

Every article can have a companion steps file. If the file exists, Wire renders a discovery layer above the full article. If it does not exist, the page renders normally. No errors, no empty containers, no layout shift.

docs/guides/getting-started/
  index.md         <- full article (unchanged)
  steps.md         <- discovery layer (optional)

The full article is always in the DOM. Google indexes everything. The discovery layer is a progressive enhancement. It works without JavaScript.

Writing a steps file

The steps file uses :::hook, :::step, and :::choices blocks:

:::hook
Most websites lose 80% of readers in the first 30 seconds.
Not because the content is bad. Because nobody showed them where to start.
:::

:::step id="start"
You published the article. Traffic arrived. But users left immediately.
Average time on page: 18 seconds. Something is wrong.
:::choices
- My content does not match what they expected -> intent
- My page might be too slow or broken -> technical
:::

:::step id="intent"
Search intent mismatch is the most common reason for high bounce rates.
Users searched for one thing and landed on something slightly different.
:::choices
- How do I check my intent -> intent-check
- I think my intent is right -> technical
:::

Rules for steps

Each step is 60 to 120 words. No more. Each step ends on something slightly unresolved, not a cliffhanger, just not a clean resolution. The next step resolves it.

Each choice reflects a reader situation, not a topic label.

Bad choice: "Keywords or backlinks?" Good choice: "My traffic never grew" vs "My traffic dropped suddenly"

The hook is one to two sentences. It is the only thing visible above the fold before the reader makes their first decision.

Step IDs should match heading anchor IDs in the full article. When the reader clicks "Read the full article on this", the page scrolls to the matching section.

What the reader sees

On arrival: Hook text and two buttons: "Guide me through this" and "Read the full article."

Guide me: Hook fades out, first step card fades in. Progress dots appear.

Choice click: Current step fades out, next step fades in. No page reload, no scroll.

Read full article on this: Discovery layer collapses. Page scrolls to the matching section in the full article with a brief highlight.

Technical details

Wire's build system handles everything automatically:

wire.build detects steps.md next to each index.md
wire.discovery.parse_steps() converts the syntax to JSON
wire.discovery.render_discovery_html() generates DOM elements with data-* attributes
discovery.js handles transitions and navigation (loaded via <script defer>)

All step content is in the DOM on page load. Hidden steps use display:none and are revealed by JavaScript. The full article below is never hidden or removed.

When to add discovery

Start with pages that have meaningful GSC impressions but low average time on page. These are pages where users arrive and leave too fast. The discovery layer attacks exactly that gap.

Run wire.chief audit to identify underperforming pages, then write steps files for the highest-impression ones first.

Generating steps with Claude

You can use Wire's prompt system to draft steps:

# Not yet automated — manual Claude prompt for now
# Paste the article + step syntax rules into Claude
# Review choices: they should describe reader situations, not topics

Total time per article with practice: 15 to 20 minutes.

The Dwell Time Evidence

The discovery system exists because of a specific finding in the 2024 Google API leak. NavBoost (Google's click-based ranking system, confirmed during the DOJ antitrust trial) uses lastLongestClicks as a ranking signal. This measures the maximum time a user spends on a page before returning to search results. Longer engagement sends a stronger positive signal.

The discovery layer targets this signal directly. Instead of presenting a 2,000-word article and hoping the reader scrolls, it breaks the reading experience into decision points. Each decision requires the reader to engage with the content before choosing what to read next. The full article remains in the DOM. Google indexes every word. But the reading experience keeps users engaged longer.

This is not speculation about what Google values. NavBoost has been in production since 2005. Google's VP of Search testified about it under oath. The API leak showed the exact feature names: goodClicks, badClicks, lastLongestClicks. A user who reads for 3 minutes and does not return to search results is a goodClick. A user who bounces in 5 seconds is a badClick.

Seer Interactive's research shows AI Overviews reduce organic CTR by 34-61%. In this environment, the users who do click through to your page are the most valuable signal source. They chose your page over an AI-generated answer. Keeping them engaged, measured in seconds, tracked by NavBoost, directly feeds your ranking for the next user who searches the same query.

The discovery system is a dwell time strategy disguised as a UX feature. The user gets a better reading experience. Google gets a stronger engagement signal. Both benefit from the same mechanism.

Why Not Just Write Better Headlines

Better headlines improve click-through rate. They do not improve dwell time. A user who clicks a compelling headline and finds unfocused content bounces just as fast. The discovery system solves the post-click problem: once the user arrives, guide them to the content that matches their situation.

The step syntax enforces this. Each choice describes a reader situation ("My traffic never grew" vs "My traffic dropped suddenly"), not a topic label ("Keywords" vs "Backlinks"). Situation-based choices create identification. The reader sees their own problem reflected in the option. Topic-based choices create cognitive load. The reader has to evaluate which topic is more relevant to their unnamed problem.

This distinction comes from journalism training methodology. The Trainingshandbuch Recherche from netzwerk recherche describes reader engagement as a function of relevance perception, not content quality alone. Readers assess relevance in the first 10-15 seconds. The discovery hook gives them a relevance signal immediately, before they decide whether to stay or leave.