From writing articles to staying visible: how the content workflow took shape
Since I started building a GEO product, I have become less willing to treat “generate an article” as a complete action.
An article is, of course, a visible result. Enter a topic, generate the copy, add a cover, and the output looks polished and complete. Ask a few more questions, though, and it becomes less simple. Why should this article be written? Which user question does it answer? Where do its brand facts come from? Where was it published after review? Did publishing really finish? Later, how will we know whether it changed the original answer?
If none of that is recorded, the article is only an isolated content file. It may be well written, but it is unlikely to become the starting point of the next action.
In the previous notes, I wrote about the question library and the knowledge base. The question library defines what the brand is preparing to answer. Knowledge materials constrain what gives the brand the right to answer. What is still missing is the easily overlooked middle: how a question and a body of evidence become content that has been reviewed, can be published, and can later be verified.
That is where the content workflow truly begins to take shape.
01 The article is not the starting point; it is one deliberate act of answering
In the earliest version of the content feature, the input was usually just a topic.
A user entered “GEO,” “AI search,” or “brand growth,” and the system began generating. It was fast, but the most important context stayed in the user’s head. After the article was finished, nobody else knew whether it addressed awareness, comparison, or fact-checking. During the next retest, nobody knew which question to return to.
I eventually began requiring every article to start from a specific question.
The goal was not to repeat that question mechanically in the title. It was to make the team clarify, before production, who the user is, what situation they are in, what judgment they are making, and what role the brand should play in the answer.
Two articles about “GEO services” can have entirely different jobs. An article for “What is GEO?” needs to explain a concept. An article for “What should a manufacturer look for when choosing a GEO provider?” needs to organize selection criteria and risks. Their factual requirements, structures, publishing channels, and later verification methods will also differ.
The first change in content production is moving from writing about a topic to completing an answer.
That step keeps the article from being a disposable output. It begins to share one object with the question library, monitoring records, and the retest that follows.
02 Keywords, questions, and articles solve three different problems
I once placed these three things too close together.
A keyword is an entry point. It helps the team understand which direction a user may come from. A question is the concrete task the user needs to complete. An article is one public answer the brand prepares for that task.
If all three are called “content topics,” the product easily collapses into a word list. The list can keep growing, but it cannot explain why an article is related to a particular monitoring result.
I now prefer to keep them separate.
A keyword can expand into several questions. Only after review does a question enter a monitoring run or a content plan. A real monitoring run may find that the brand is absent, a fact is wrong, the cited sources are weak, or the brand does not enter the right comparison context. That evidence creates a GEO opportunity worth acting on. An article is one possible action, not the default answer to every question.
This also means an article can be associated with one primary question and several supporting questions. It cannot claim to cover an entire field simply because it contains a few keywords. Coverage depends on whether it actually answers the user’s task, not whether a word appears.
In BeanInsight, I want that relationship to remain visible wherever possible: where the question came from, which monitoring run exposed which gap, why the article was chosen as the action, and which question the team later returned to for verification.
The purpose is not to draw an impressive relationship map. It is to prevent “we wrote about it” from being mistaken for “we solved it.”
03 Before an article begins, define what it must not invent
The easiest thing to pursue in article generation is completeness.
A model tends to fill in the opening, method, examples, and conclusion until the article reads like a mature industry piece. GEO content carries an additional requirement: completeness must not come at the expense of factual boundaries.
Before generation, I now care more about whether the content brief sets several clear constraints. What is the target question? Which intent stage is the user in? Which brand facts are available? Which claims need public sources? What must not be written? What will the team observe after publication?
A knowledge base can provide internal factual guidance, but it cannot replace a public source. Unverified customer results, prices, qualifications, and cases cannot be added merely to make the article more persuasive. If the question is close to a decision and the only available material is a generic company introduction, the article cannot pretend to offer a complete decision answer.
These constraints sometimes make the first draft shorter. They can even make the system return “not enough relevant evidence.” That is easier to review than a dense-looking article that quietly mixes different situations together.
I came to see the content brief as the article’s boundary document. It is not merely a few prompt lines for a model. It is the team’s shared confirmation, before generation, of what this article will answer, what supports that answer, and what it will leave unsaid for now.
04 Review is not polishing sentences; it is checking whether the answer holds
After generation, review should not be limited to typos and tone.
The first questions are more fundamental. Did the article answer the original question? Do its critical facts match the brand material? Did internal information accidentally become a public claim? Can a reader trace the citations? Did the article turn a judgment that still needs verification into a certain conclusion?
If an article was created for a “brand absent” opportunity, review must check whether it fills the decision information the user actually needs, rather than merely mentioning the brand more often. If it addresses an “official source gap,” the reviewer needs to confirm that it creates a public page for the user’s question, not that it simply moves an internal manual onto the web.
The object under review has changed.
The team used to review a piece of writing. It now reviews the relationship among question, evidence, and expression. The article still needs to be readable, but readability comes after the answer is valid.
The product can preserve the question, knowledge passages, and article versions so the reviewer has less context to reconstruct. It cannot decide whether a fact is truly valid or assume the brand’s responsibility for what is stated publicly.
05 Publishing is not pressing a button; it is moving an action into a confirmable state
The easiest mistake after content is complete is to assume that clicking Publish means the content is published.
Different platforms have different intermediate states. Creating a WeChat draft is not the same as sending it. A platform response saying “submitted” does not necessarily mean a public URL exists. A browser extension finishing an operation does not mean the final result has been confirmed.
Publishing therefore needs to be a stateful action: pending, in progress, needs confirmation, published, or failed, with a path for human verification when necessary.
For a manual external publication in the current product, the reviewed title and body snapshot are locked before a publication record is created. After the operator submits a public URL, the system still checks that the link is accessible, that its domain matches the channel, and that it is not a duplicate publication. Only then does the record become published and participate in later citation and result observation.
This has more steps than a simple “publish succeeded” message, but it avoids two opposite mistakes: counting a draft as public content, and sending the same article again because the previous result was uncertain.
I increasingly believe that the most important capability of a publishing system is not clicking on behalf of a person. It is describing exactly how far the action has gone.
06 A change after publishing cannot immediately be credited to the article
An article appearing on a public page only proves that the action happened. It does not prove that AI has seen it, and it certainly does not prove that it produced a business result.
A public page still has to be found, understood, and cited. AI platforms can change their models, web access, account state, and sources. A different question environment can produce a different answer. Even when a metric rises after publication, the article cannot automatically be treated as the only cause.
The real next step after publishing is to return to the original question, preserve the pre-action baseline, and schedule another real monitoring run under conditions that are as comparable as possible.
“As comparable as possible” matters. The wording should remain stable. Platform and account scope should be explicit. Language, region, web access, and other important conditions should remain as consistent as possible. If the environment changes, the product should record that change rather than quietly place both results on one trend line.
The point of a retest is not to find a curve that must go up. It is to answer a more honest question: under the currently comparable conditions, what did we observe after the action? Which changes match the original improvement criteria? Which still lack evidence?
Publishing completes the action. Retesting begins the verification.
07 GEO opportunities keep the content calendar from depending on inspiration
Without an opportunity object, content planning usually returns to the question, “What should we write this month?” Topics come from experience, schedules from intuition, and after publication the team starts searching for a result.
A GEO opportunity offers another organizing principle.
A monitoring run can reveal brand absence, weak position, negative language, a gap in official sources, or competitor dominance. Each problem suggests a different expected result and action: add brand facts, build a public page, write comparative content, clarify a fact, or run more monitoring before acting.
An opportunity should not be a reminder to “write more articles.” It should carry the original question, target platform, current evidence, expected result, and verification criteria. After the action is complete, the opportunity moves to awaiting verification. It does not automatically become improved.
This changes the content calendar from “keep publishing” to “address an observed gap.” An opportunity can, of course, be misdiagnosed. Verification can fail, and the opportunity may need to reopen. The workflow does not guarantee that every action works. It gives even a failed action a path that can be explained.
08 A real loop is not a straight line, but a set of records the team can revisit
At this point, the complete path looks roughly like this:
Brand facts -> user question -> real monitoring -> GEO opportunity -> content brief -> article generation -> human review -> platform publishing -> same-question retest -> next action
It looks linear, but in practice it frequently moves backward.
Missing material can send the team back to the knowledge base. A question that does not fit the current goal can return to the question library for another review. A missing public source found during article review can send the work back to the content brief. An uncertain platform result may require human verification before any retry. A retest with too little evidence may have to remain “inconclusive for now.”
The workflow therefore has to preserve not only the endpoint, but the reason for every turn.
In the product, that means tasks need clear states, failure reasons, related objects, and timestamps. An article must keep its generation inputs and version. Publishing must keep title and body snapshots. Monitoring must preserve the original answer and environment. An opportunity must retain the evidence and verification plan that existed when it was created.
These records do not establish causality on their own. They tell the team where to continue next time instead of forcing everyone to reconstruct the path again.
09 Several problems I have not solved yet
The content workflow is much clearer than isolated article generation, but it is far from complete.
The same user question may need a long website article, a WeChat article, and third-party platform content. Adapting to each platform while preserving factual consistency is not a matter of copying one body everywhere. Questions and knowledge materials change over time; deciding when to update an old article and how to preserve historical verification requires version relationships. One article may serve several questions, and the way opportunity and publication records should distribute their weight still needs finer rules.
There is also an unavoidable reality: content can be produced on schedule, but whether AI cites it at a particular moment is not controlled by the product alone. The product can stabilize definitions, preserve evidence, arrange retests, and keep unknown states visible. It cannot present “published” as “seen by AI.”
That is the next area I need to keep exploring. Once the workflow connects the question, evidence, and content, publishing becomes especially important. When a platform offers no stable interface, how can manual work in the browser be assisted, recorded, and verified?
The next note explains why turning publishing into a workflow led me to the browser extension, and the product and technical tradeoffs that came with that path.