Content briefs by user situation: how to write docs that search (and AI) value

Anyone who writes documentation, tutorials, or technical guides knows the cycle: grab a list of keywords, sort by search volume, and produce an article for each one. The problem is that volume tells you what people search for, but never why they search or what they need next. Amanda King, an SEO consultant with more than a decade of experience, argues in Search Engine Land for a reversal: start the brief from the situation the reader is in, and only then let the keyword shape the text. For technical content creators, this fixes a chronic ailment, the generic article that ranks poorly and helps no one.

The symptom: docs written for the keyword, not the person

King uses an example from outside our world, but one every dev recognizes once translated: in the US, practically every accountant's website has an FAQ answering "what is a fiscal year?". The reason is always the same, someone saw high search volume and wanted a slice of the impressions. The result is a pile of 300-word texts, written between 2015 and 2018, that someone now has to clean up.

The technical parallel is immediate. How many READMEs and blog posts exist explaining "what is a REST API" or "what is Git"? You're competing with the official documentation and, at bottom, assuming that whoever reached your content doesn't know the basics and doesn't know how to search. King poses two uncomfortable questions that apply to any technical author:

• Why am I trying to outrank the entity that should be the only answer to this question (the official spec, the RFC, the maintainer's docs)?
• Why would I want to attract a reader who doesn't even know the most basic concept in my field?

Answering generic questions to chase volume, she says, does a disservice to your expertise. You put yourself up against whoever defined the standard, and end up looking foolish.

Humans don't think in keywords

The argument gains strength with conversational search on LLMs. Nobody types "best sweet snacks 2026". The person thinks: "my wife is pregnant and craving weird sweets she's never tried before". The situation is rich, contextual, and that's exactly how language models were trained to reason alongside the people who use them.

Translating that to documentation: the dev doesn't search for "useEffect example". They're in a situation, "my component keeps re-firing the API call in an infinite loop and I don't know why". The keyword is the impoverished residue of a concrete situation. Writing for the situation gets you closer to thinking at the topic level, which is how both the reader and generative AI organize knowledge, rather than at the level of an isolated term.

This is where the reason the method also works for GEO (generative engine optimization) comes in. Content structured around a well-defined situation gives the model the context it needs to cite you as the answer to a specific question, instead of diluting you in a sea of identical texts about the basic concept.

The 7 W's: the exercise before you write

King draws on category entry points (CEPs), a marketing concept she borrows from Better Brand Health, by Jenni Romaniuk. CEPs are the leap from the topic back to the situation that created it, and they boil down to seven questions:

• Why (the reason)
• When (the moment)
• Where (the place)
• While (the context, what else is going on)
• With whom (who's involved)
• With/for what (the tool or the purpose)
• How feeling (the emotion)

Filling in these seven lines is the core exercise of the brief. In a technical context, a guide on setting up CI/CD might start like this: when the dev is building the team's first pipeline; where, at a startup with no dedicated infrastructure platform; feeling insecure about breaking production; for achieving deploys without depending on a single person. That framing changes everything, the outline, the tone, the examples, what you assume the reader already knows.

One important detail: the person who helps most in filling out the 7 W's isn't the keyword tool, it's whoever talks to the audience. In our world, that's support, DevRel, whoever answers issues on GitHub, whoever handles the community's Discord. They know the real situations where people get stuck.

The brief in practice

The fields King suggests for the document:

• One line for each of the 7 W's, noting who on the team the information came from. That traceability helps when someone needs to check a fact or ask for more detail.
• The scenario you're solving for: the business owner panicking at the end of their first fiscal year, someone inheriting a legacy system, the intern learning the basics. Give the situation a name and a face.
• Everything a normal brief would already have: content type (informational, consideration, transactional), suggested outline, tone notes, a check of what's already published (existing coverage check), length guidance, and the success metric.

The gain isn't just steering the text. The brief documents, with feedback from real people, where your brand still isn't answering the audience's questions, and gives a structured path to answer within the context of your product.

The weak point (and how to work around it)

King is honest about the method's weakness: it comes from brand science and marketing principles, and doesn't translate into a clean metric the way search volume does. But she flips the argument around, keyword volume was always an abstraction, distant from the audience's real concerns. The 7 W's force you, the team, and leadership to anchor decisions in real people.

Compare the two justifications: "this is the feedback support gave us over the last six months" versus "this has the highest search volume in the country in our sector". The first is less measurable, but far more defensible.

Test instead of believing

The final recommendation is faithful to "measure before and after": if leadership is skeptical, test it. Write two briefs for the same topic, one traditional and keyword-based, another built around the 7 W's and the scenario. Compare the quality of what writers turn in and, if you can, run an A/B test on the site measuring:

• scroll depth (does the reader reach the end?);
• engagement (clicks, code copies, active time);
• search impressions.

For technical content, you can add format-specific signals: code block copy rate, "was this helpful?" feedback at the bottom of the doc, a drop in support tickets on the topic. The expected outcome is an audience that reaches a decision with more of their questions already answered, and an internal team more attuned to what readers actually worry about. As she sums it up, that's worth far more in the long run than ranking first for "what is a fiscal year" for your entire tenure at the company.