Turn one customer question into a brief people can use

A useful article brief starts with one real customer question, not a topic bucket. If the question contains a decision, a risk, or a next action, we can turn it into something an editor or writer can actually use. If it does not, we usually do not have a brief yet, we have a theme.

Our aim at The SEO Blog is to make that conversion explicit. Instead of asking for “something on indexing” or “an AI search piece”, we take one question, identify the task hidden inside it, then build a brief around checks, evidence, limits and links. That is the practical work involved in turning one customer question into a useful article brief.

Choose one question with a real decision behind it

The easiest way to waste editorial time is to start with a broad phrase that has no decision attached. “Write about technical SEO” is not a brief. “Do we need to fix excluded pages in Google Search Console?” is much closer, because someone is trying to decide whether to act, what to check first, and what can safely be ignored.

When we choose a question, we look for three things.

First, it should be answerable in one article. “How do I do SEO?” is not. “What should I check before asking a developer to un-noindex a page?” probably is.

Second, it should lead to a practical outcome. A good question changes what the reader does next. They inspect a report, compare two controls, gather evidence, or avoid a mistaken request.

Third, it should be distinct from a guide we already have. If the site already has a broad explainer, the new piece should solve a narrower decision and then link back to the guide, rather than duplicating it. That matters on The SEO Blog because we are a publication, not a service page library. We want a reader to leave with a clearer method, not three versions of the same overview.

A reliable test is to ask, “What would the reader do in the next 15 minutes if this article were good?” If the answer is vague, the question is still too broad. If the answer is “open the Page indexing report, identify whether the excluded URLs are intentional, and only escalate the wrong ones”, we have something workable.

Questions that often produce usable briefs include:

• “Why is this page excluded, and do I need to fix it?”
• “Does blocking GPTBot also stop OAI-SearchBot?”
• “Why did impressions change after we edited one article?”
• “Do AI citations mean the page is ranking in Google?”

Each of those contains a practical uncertainty. Each can be supported with evidence. Each also has limits, which is exactly what a good brief should surface early.

Find the task hidden inside the question

A customer question is often phrased as a surface symptom. The real task sits underneath it.

Take “Why is this page not indexed?” On its face, that sounds like a diagnostic question. In practice, the reader’s task may be one of several different things:

• deciding whether the page should be indexed at all
• identifying whether the exclusion is expected
• collecting the right evidence before asking a developer to change something
• avoiding a false assumption that every excluded URL is a problem

That distinction matters because the article structure changes with the task. If the real job is prioritisation, the piece should not become a generic indexing explainer. It should help the reader sort URLs into “leave alone”, “review content value”, and “investigate configuration”.

This is where many briefs go wrong. They mirror the wording of the question but miss the reader’s actual job, risk or uncertainty.

We usually map the hidden task by asking four editorial questions:

1. What decision is the reader trying to make?
2. What evidence can they check themselves?
3. What mistake are they at risk of making?
4. What remains uncertain even after the checks?

For example, with excluded pages in Google Search Console, the mistake risk is obvious. Google’s own documentation says to investigate the reason a URL is excluded, and not every excluded URL should be indexed (Google Page indexing report). That single point changes the brief. The article should not encourage blanket “fixes”. It should teach the reader to distinguish intentional exclusions from accidental ones.

The same approach helps with AI search topics. If someone asks, “How do I get into AI answers?”, the hidden task may actually be “separate what can be checked from what is being guessed”. That would call for a brief that distinguishes crawler access, citations, impressions and clicks, because those are different kinds of evidence. Google states that existing search fundamentals apply to its AI features and that no special AI schema or text file is required (Google AI features). OpenAI separately documents that search access and model-training controls are different choices (OpenAI crawler documentation). So the task is not “find the secret AI setting”. It is “understand which control affects which system, and stop conflating them”.

When we identify the hidden task properly, the article becomes more useful and more honest. It stops pretending to solve everything and starts solving one thing well.

Build the brief from checks, evidence and limits

Once we know the question and the task, we build the brief around what the draft must check, what evidence it may use, and where it must stop.

For The SEO Blog, a usable brief usually includes these parts.

1. The editorial question

Write the exact question in plain English. Keep it singular. If you need “and” more than once, split it.

Example: “When Google Search Console shows a page as excluded, what should a website editor check before asking for a fix?”

That is better than “Everything you need to know about excluded pages”.

2. The reader and their starting point

Name the reader realistically. “UK website editor with access to Google Search Console but no developer access” is much more useful than “marketers and business owners”.

This helps the writer choose sensible steps. A beginner can open reports and inspect a URL. They may not be editing robots.txt or server headers themselves.

3. The practical outcome

State what the reader should be able to do after reading.

For example:

• tell whether an exclusion is likely intentional
• gather the right screenshots or report details for escalation
• avoid requesting indexation for low-value or duplicate URLs

This keeps the article from drifting into background theory.

4. The checks the article must walk through

This is the core of the brief. We list the checks in order, using the actual tools and labels the reader will see.

For a Google Search Console topic, that might include:

• open the Page indexing report
• inspect the reported reason for exclusion
• check whether the URL is canonical, duplicate, redirected, noindexed, blocked, or otherwise intentionally excluded
• compare the excluded URL with the intended indexable page
• review internal links pointing to the URL
• decide whether the page serves a unique search purpose

These are editorial instructions, not just SEO concepts.

5. Approved evidence and primary references

We separate primary-source facts from our interpretation. If we state that not every excluded page should be indexed, we support that with Google’s documentation, not with a forum summary. If we state that no special AI schema is required for Google’s AI features, we cite Google’s own documentation. If we explain the difference between OAI-SearchBot and GPTBot, we cite OpenAI’s crawler documentation.

This is especially important on topics where people have seen conflicting advice. The brief should tell the writer which claims need a source beside them, and which observations are interpretation.

6. Limits and exclusions

A strong brief says what the article will not do.

For example:

• will not promise rankings or inclusion in AI answers
• will not treat a crawler visit as proof of citation or business impact
• will not give legal advice on robots controls
• will not generalise from one report screenshot to all indexing issues

These limits protect the article from overstating what the evidence can support.

7. Internal links that prevent duplication

A brief for this site should point to existing guides where they genuinely help the reader. That way the new article solves a narrow task and the broader guide remains the main destination for the wider topic.

For instance, if the draft mentions measurement constraints in Google Search Console, it may naturally link to our guide on evidence and limitations in Search Console reporting. If it touches a broader diagnostic process, it may also link to how to investigate a change in search performance. If the topic overlaps AI visibility, the relevant wider context is our guide to AI search and visibility.

Worked example from question to article brief

Here is a full example.

Customer question: “Google Search Console says these pages are excluded. Do we need to fix them?”

That is a good starting point because there is a real decision behind it. Someone may be about to raise development work, remove a noindex, or panic about a normal report state.

Step 1, define the article angle

We would not brief “A guide to excluded pages”. That is too broad and likely duplicates existing explainers elsewhere.

We would brief: “How to review excluded pages in Google Search Console before requesting a fix”.

The angle is editorial triage, not technical completeness.

Step 2, identify the hidden task

The reader’s task is not “learn all indexing theory”. It is:

• decide whether the exclusion is expected
• identify the few URLs worth escalating
• avoid treating every exclusion as an error

Step 3, set the article outcome

After reading, the reader should be able to sort excluded URLs into three groups:

• expected and fine
• needs content or canonical review
• needs technical investigation

Step 4, list approved evidence

Primary references to cite next to supported claims:

• Google’s explanation that excluded URLs should be investigated by reason, and that not every excluded page belongs in the index (Google Page indexing report)
• Google’s broader guidance that useful, accessible content and descriptive links help discovery, without guaranteeing rankings (Google SEO Starter Guide)

If the draft strays into AI visibility, that needs separate sourcing and probably a different article.

Step 5, outline the headings

A workable heading plan might be:

• What “excluded” means in this report
• Check whether the page was meant to be indexed
• Match the exclusion reason to the likely next action
• Look for internal links and duplicate intent
• When to escalate to a developer or SEO
• What this report cannot tell you on its own

That last heading matters. It stops the piece from overstating the report.

Step 6, define what the writer must include

The brief should require the writer to mention examples such as:

• filter pages
• duplicate or parameter URLs
• redirected URLs
• thank-you pages
• staging or test pages
• pages carrying a deliberate noindex

It should also require a warning that an excluded URL is not automatically a problem, and that indexation is not a quality badge.

Step 7, define what the writer must avoid

The draft must avoid:

• implying every excluded page should be submitted
• promising that indexation will improve sales
• treating one Search Console status as a full diagnosis
• inventing percentages or “common causes” without evidence

Example brief, ready for use

Working title: How to review excluded pages in Google Search Console before requesting a fix

Reader: UK business owner, marketer or website editor with Search Console access, limited technical knowledge, and a list of excluded URLs.

Editorial question: When Google Search Console labels pages as excluded, which ones should we ignore, which ones should we review, and which ones should we escalate?

Purpose: Help the reader triage excluded URLs before asking for development changes.

Key checks to cover:

• Open the Page indexing report and note the exclusion reason.
• Confirm whether the URL was intended for search at all.
• Check whether another URL is the preferred canonical or destination.
• Review whether the page has unique value and a clear search purpose.
• Check whether important internal links point to an excluded version.
• Escalate only where the intended page is being wrongly excluded.

Primary references:

• Google Page indexing report
• Google SEO Starter Guide

Internal links:

• Link to evidence and limitations in Search Console reporting when explaining what the report can and cannot prove.
• Link to how to investigate a change in search performance if the article mentions wider context beyond one report.
• Link to a practical on-page check for one published article if the reader needs to assess whether the page itself is clear and useful.

Limits:

• No ranking promises.
• No claim that inclusion equals business impact.
• No assumption that all excluded URLs are mistakes.
• No legal or hosting-specific advice unless separately evidenced.

That is a brief people can use. It tells the writer what to solve, what to cite, what to leave out, and how not to duplicate broader guides.

Edit the brief so it fits The SEO Blog

The final step is not cosmetic. A brief that works for a sales site, a software blog, or a freelance consultant may still be wrong for The SEO Blog.

We edit the brief against our publication rules.

First, we remove sales intent unless it is genuinely relevant. This site teaches. It does not turn every topic into a pitch. If practical services become relevant, that belongs with Suffolk Web, which shares ownership through Fleeta Limited, but that is not the default destination for an editorial article.

Second, we check that the piece is evidence-led. If a claim needs a source, the brief should name one. If the source does not support the claim, we change or remove the claim. This matters on search and AI topics because people often merge separate systems. For example, Googlebot access, Google AI features, OAI-SearchBot access and GPTBot training controls are not interchangeable topics. Google says no special AI schema or text file is required for its Search AI features (Google AI features). OpenAI documents separate bots and controls for search and training access (OpenAI crawler documentation). A brief on one should not drift into unsupported claims about the other.

Third, we make sure the article serves a non-sales purpose. The next step should usually be a guide, checklist, feed, or another article. If the draft is really about understanding evidence rather than buying help, it should stay that way.

Fourth, we check for duplication. If the brief starts covering all of AI visibility, all of measurement, or all of content quality, it has become too broad. We narrow it back down and point to the existing guide instead. That is how we keep the publication coherent.

Fifth, we test the brief against a beginner reader. Could someone with access to the relevant report follow the steps without already knowing the jargon? If not, the brief needs plainer wording or a tighter scope.

A simple editorial checklist helps here:

• Is there one customer question, not three?
• Does it lead to a real decision?
• Does the brief name the hidden task?
• Are the checks concrete and in a sensible order?
• Are primary references attached to factual claims?
• Are evidence and interpretation kept separate?
• Does it avoid promises and unsupported outcomes?
• Does it link to existing guides instead of duplicating them?
• Would a website editor know what to do next?

If the answer to any of those is no, the brief is not ready.

That is the practical standard we use when turning one customer question into a useful article brief. Start with a single decision. Find the actual task inside it. Build the brief around checks, evidence and limits. Then edit it so it fits The SEO Blog, rather than becoming another broad SEO overview in new packaging.