The useful unit of micro-SaaS SEO is not a keyword. It is one privacy-safe question, a dated inspection of the current result landscape, a supportable answer and one primary page. The workflow ends with a clear decision—create, improve, document, private or reject—and a trigger for inspecting the answer again.
Bring one privacy-safe question, not a broad topic
This workflow starts after a question has been observed and recorded from a source the business is authorised to use. Keep the original wording, reader moment, source date and private reference in the private source record, but remove names, account details and any combination of facts that could identify a person. One question proves only that the uncertainty occurred; it does not prove market demand.
If the wording cannot be separated safely from a confidential account, or the answer depends on a negotiated promise, keep it private. Search inspection should begin only when the question can be stated without exposing its source and the product can support a public answer.
Run a dated inspection before choosing a format
Search the question and close variants in the market and language you intend to serve. Record the date, location or localisation, device if relevant, and whether personalisation was reduced. The result page is a temporary observation. It can show which interpretations and formats are visible now; it cannot award the topic to your site.
Inspect enough results to answer four practical questions. First, what job appears dominant: learning a process, comparing approaches, obtaining a template, resolving an error or using a product? Second, which formats currently serve that job: documentation, product pages, tutorials, discussions, videos or downloadable assets? Third, which subquestions recur? Fourth, can you answer the job with specific product knowledge, a usable procedure, an honest comparison or a clear boundary?
A mismatch is a reason to stop. If the visible results mainly provide a free calculator and you can only offer a general essay, an article may be the wrong response. If searchers need vendor documentation for a changing API, your documentation may be the correct owner. If the question describes your product but the answer is missing from the interface, fixing the label or state may matter more than publishing anything.
Choose create, improve, document, private or reject
Every inspected question needs a decision. Avoid the soft middle ground of “add to the content backlog,” where duplicates accumulate without a primary page.
- Create: open a new URL only when the reader moment, page job and required answer are distinct from the current inventory.
- Improve: add the question to an existing page when that URL already owns the same decision but lacks a step, example, caveat or failure state.
- Document: place the answer in product or help documentation when it depends on current controls, setup steps, field meanings or recovery behaviour.
- Private: keep the answer in sales, support or account notes when it depends on confidential facts or a negotiated commitment.
- Reject: do not publish when the product cannot support the promise, the evidence is unauthorised, the intent is unrelated, or the proposed answer would be superficial.
These choices are not a quality ladder. Documentation can be more useful than an article; a private answer can be safer than a public generalisation; rejection can protect the site from a page with no defensible job.
Write the reason beside the decision. “Improve because the current guide owns the same recovery decision but lacks one failure state” is actionable. “Create because the phrase sounds relevant” is not. A reason should point to the reader job, product boundary, evidence and current primary page. When those fields remain uncertain, hold the question outside the active inventory and identify the inspection or product check that would resolve it.
Choose one primary page and settle overlap
For create or improve decisions, compare the proposed answer with the existing inventory. Two pages overlap when they serve the same person at the same moment, promise the same decision and require substantially the same explanation. Different phrasing is not enough to justify separate pages.
Write the distinction between neighbouring pages in one sentence. If the reader moment, evidence and next action cannot be separated clearly, improve the stronger page rather than creating another URL.
Name the primary page and the person responsible for keeping the answer current. Other pages may introduce the uncertainty, but only the primary page should carry the full answer.
Check that the answer can be supported
Before approving create or improve, list the minimum support the answer needs: a current product check, an appropriate primary source or a clearly labelled illustrative example. If that support is unavailable, choose document, private or reject. Drafting and claim-level editing begin only after this page decision is recorded.
Plan internal links and the update trigger before drafting ends
An internal link should continue the reader’s work. Plan at least one credible route into the page and one route out. A sales guide can introduce an evaluation question; the answer can lead to a validation procedure. A troubleshooting guide can receive a link from setup and lead to a safer operating practice. Anchor text should name the next decision rather than say “learn more.”
For example, a founder who is still testing whether a question represents a real problem may need the guide to validating a micro-SaaS idea before building. A question that repeatedly appears during demos may connect to a practical founder-led sales workflow. If the evidence originates in support, using support as product research is the more natural next step. None of those links belongs on the page unless it advances the current job.
Finally, replace “review regularly” with an event. Useful triggers include a changed product workflow, a new permission model, altered pricing, a replaced external source, a screenshot that no longer matches, a recurring question that reveals a second reader job, or two pages beginning to answer the same uncertainty. Record what must be rechecked: claims, steps, examples, links, screenshots, page ownership or the disposition itself.
Question-to-page decision record
Illustrative example only. The fictional entries below demonstrate the SEO decision. They do not describe a customer, a live query set or a product result.
The workflow ends with a dated decision, not a draft by default. Create only when a distinct job has a supportable answer. Improve when a primary page already exists. Document product-specific instructions, keep confidential answers private, and reject what the product or evidence cannot carry.