> Short answer: a search intent matrix lets AIKit turn one product update into a small portfolio of pages that answer different buyer questions. Instead of publishing one blog post and moving on, the team creates five connected assets: an explainer, tutorial, comparison, FAQ, and conversion page.

The Problem

Product teams usually have more source material than they can publish. A new AIKit feature may include a pull request, a demo script, a support note, a changelog entry, and a customer question, but only one of those pieces becomes public content. That single post often tries to serve every reader at once. Beginners want definitions, builders want steps, evaluators want comparisons, and ready buyers want proof. When one page tries to satisfy all of them, it becomes long, vague, and hard to route into the funnel.

The deeper issue is that search intent is not one thing. A founder searching for content automation is in a different moment than an operator searching for how to structure llms.txt, and both are different from a buyer comparing AIKit with a manual publishing workflow. If AIKit treats every query as a blog topic, the site gets a pile of disconnected articles. If it treats every product update as a source event, the same work can generate a deliberate cluster of pages that support discovery, education, and conversion.

The Solution

Use a search intent matrix before writing. The matrix starts with one source event and maps it across five intent lanes: explain, implement, compare, troubleshoot, and convert. Each lane produces one asset with a clear job. The explainer answers the broad question. The tutorial shows the workflow. The comparison page positions AIKit against the old way. The FAQ captures long-tail questions. The conversion page invites a demo, checklist download, or product trial.

This approach is useful because it keeps content from competing with itself. Each page has a different promise, title, slug, internal link target, and call to action. AIKit can still publish fast, but the output looks like a connected knowledge system instead of a random blog archive. It also works well with AI discovery. Pages that are structured by intent, with clear headings and concise answers, are easier for search crawlers and AI agents to parse from llms.txt and llms-full.txt.

Architecture Overview

The matrix has four layers: source capture, intent mapping, asset generation, and funnel routing. Source capture records the product proof. Intent mapping decides which reader question each asset answers. Asset generation creates markdown with reusable sections, code blocks, tables, and answer-first openings. Funnel routing connects each asset to the next step in the buyer journey.

```text

Product update

-> source brief

-> intent matrix

-> five asset drafts

-> D1 publish and llms.txt exposure

-> CTA, lead magnet, or demo route

```

A practical matrix can live in a simple markdown table. The important part is not the tool. The important part is forcing the team to decide the job of each page before writing the body text.

| Lane | Reader question | Asset type | CTA |

|---|---|---|---|

| Explain | What is this and why does it matter? | Answer-first article | Newsletter signup |

| Implement | How do I do this in my workflow? | Step-by-step guide | Checklist download |

| Compare | Why use AIKit instead of manual work? | Comparison page | Demo request |

| Troubleshoot | Why is my result not working? | FAQ or support note | Docs link |

| Convert | Is this worth trying now? | Use-case page | Start free |

Step 1: Capture One Source Event

Start with a product update that already has proof. Good source events include a new workflow, a launch improvement, a customer-care pattern, a pricing insight, a plugin feature, or a repeat support question. The brief should be small enough to fill in quickly, but specific enough that a writer or agent can produce accurate material.

```yaml

source_event:

feature: dynamic llms.txt publishing for AIKit posts

user: founder or marketer publishing AI product content

problem: useful product details stay hidden in internal notes

mechanism: D1-backed posts appear in blog, sitemap, and llms files

proof: one approved post becomes human-readable and AI-readable

next_step: route readers to checklist, demo, or product docs

```

The brief prevents generic writing. If a draft cannot mention the user, mechanism, proof, and next step, it should not be published yet. The goal is to make every asset feel grounded in the product, not in a broad marketing claim.

Step 2: Build the Matrix Before Drafting

Once the source event is clear, write one row for each intent lane. The row should include the title angle, target query, internal link target, and funnel step. This takes less time than fixing a confused article after it is written. It also helps AIKit avoid duplicate slugs because the title angles are intentionally different.

For example, a dynamic llms.txt feature could become these assets: an explainer on AI-readable content, a tutorial on structuring posts for llms.txt, a comparison of blog-only publishing versus agent-readable publishing, an FAQ about why a post is missing from llms.txt, and a conversion page about using AIKit to maintain an AI-ready content library. Those pages can link to each other without repeating the same search promise.

Step 3: Publish With Internal Links and CTAs

Publishing is not finished when the post enters D1. Each asset should receive at least two internal links: one from a related existing post and one to the next page in the cluster. The CTA should match the intent. A beginner article should not immediately force a demo request; a checklist or newsletter is a better next step. A comparison page can ask for a demo because the reader is already evaluating options.

```bash

Simple pre-publish checks for each queue file

python3 - <<PY

import json, sys

data=json.load(open(sys.argv[1]))

assert 800 <= len(data["body_text"].split()) <= 1500

assert data["excerpt"] and data["title"]

assert "## The Problem" in data["body_text"]

PY queue/post.json

```

The same check should be paired with a human or automated review of the funnel step. A technically correct article can still underperform if it has no next action.

Results

The matrix changes the expected output of a product update. Instead of one page, AIKit gets a cluster of five search assets from the same research. That means more internal links, more long-tail coverage, more CTA options, and more inventory for llms.txt. It also reduces content waste because the source event is captured once and reused while the details are still fresh.

A practical benchmark is simple: for every meaningful product update, publish one primary article and reserve four companion angles in the content calendar. Not every update needs all five pages immediately, but the matrix makes the opportunity visible. The team can publish the strongest asset now, then return later to fill the cluster with support notes, demos, and comparison pages.

Key Takeaways

- One product update can support multiple search intents when the team maps the reader journey before drafting.

- The five useful lanes are explain, implement, compare, troubleshoot, and convert.

- Each asset needs a unique title angle, internal link target, and CTA so pages compound instead of competing.

- AIKit should treat llms.txt visibility as part of SEO because agent-readable content is now a discovery channel.

- The matrix turns product proof into a repeatable growth system, not a one-off writing task.