Organic Search Engine Optimization: Specialist Results in 3h

A solo SaaS developer rarely needs more SEO tasks. The backlog already contains possible articles, title rewrites, technical warnings, internal links, landing-page changes, and analytics fixes. The difficult part is deciding which task is constraining organic growth now.

Treat three hours as the boundary of one focused weekly session. The useful result is to identify the best-supported constraint, complete one improvement, and record how you will judge it. A new article may be the right improvement, but it is only one option. The better move may be to restore indexation, consolidate overlapping pages, improve a page that already earns impressions, or repair the path from an organic visit to a product action.

The workflow below gives an AI assistant the collection, comparison, and first-pass analysis. You keep the decisions that require product context and approve the final change. The prompts keep the review in sequence. The evidence sets the limit on each conclusion.

A focused organic SEO session

Move through six decisions: prepare the context, diagnose the main constraint, choose one action, execute the change, run quality assurance, and record the measurement plan. Spend most of the session on the selected change. If the diagnosis exposes missing evidence or a change that needs another owner, finish with a review-ready artifact instead of forcing a release.

Do not squeeze every SEO discipline into the session. The diagnosis protects the implementation block from a low-value task.

Step 1: Prepare the context

Spend about 20 minutes gathering evidence the assistant can inspect. A compact weekly packet should include:

• the product, audience, and business action you want an organic visitor to take;
• important pages and the job of each page;
• Google Search Console exports for pages and queries, with a useful comparison period;
• crawl or indexation observations relevant to those pages;
• analytics for organic landing pages and the selected product conversion;
• known releases, migrations, tracking changes, and content updates;
• constraints such as framework, CMS, engineering access, and prohibited claims.

If Search Console or conversion tracking is missing, treat that gap as a possible constraint. Do not replace it with a traffic estimate. Google’s SEO Starter Guide covers discovery and indexing basics. The Search Console Performance report provides query, page, click, impression, and CTR data.

Use this prompt to separate the supplied facts from interpretations:

You are preparing an organic SEO review for a solo SaaS product.

Inputs:
- Product and audience: [paste]
- Primary business action: [paste]
- Important pages and intended jobs: [paste]
- Search Console data: [attach or paste]
- Analytics and conversion data: [attach or paste]
- Technical observations and recent changes: [paste]
- Constraints and prohibited claims: [paste]

Return only:
1. confirmed facts with their source and date;
2. observations derived from the supplied data;
3. missing information that would change a decision;
4. assumptions that must not be treated as facts.

Do not recommend an SEO action yet. Do not invent benchmarks.

Keep plausible explanations separate from observed facts so another reviewer can challenge the recommendation.

Step 2: Diagnose the main constraint

Give the diagnosis about 30 minutes. Review organic search as a chain: a page needs a path to discovery, a reason to be indexed, relevance to the query, a search result that earns the right click, and a page experience that supports the intended product action.

Use this order to investigate the site. The chain is a heuristic: Search Console data can be delayed or aggregated, CTR varies with the query and search context, and conversion data may be incomplete. Keep those limits beside the diagnosis.

Audit the supplied evidence across this chain:
crawlability -> indexation -> query relevance -> impressions -> clicks -> product conversion.

For each stage, report:
- what the evidence supports;
- what it does not support;
- the strongest observed constraint;
- plausible alternative explanations;
- the smallest check that could distinguish between them.

Then name one main constraint. Cite the exact page, query, period, or technical observation behind it. Do not recommend new content unless no suitable existing page can satisfy the intent.

For a repeatable version of this diagnostic, use the SEO Audit skill. It supplies an audit framework; your evidence still determines the conclusion. The linked skills in this guide are third-party, so review their instructions and access before use.

If the evidence cannot separate two explanations, use part of the session for the smallest diagnostic check. “Insufficient evidence” is more useful than an invented root cause.

Step 3: Choose one action

Cap this decision at about 10 minutes. Turn the diagnosis into a short list of concrete choices:

• fix a crawl or indexation problem;
• improve an existing page for the intent it already serves;
• consolidate overlapping pages and redirect deliberately;
• strengthen internal discovery and context;
• improve how an existing page appears in search;
• create a page for a confirmed gap in coverage;
• repair the path from organic landing page to product conversion.

Prioritize business relevance and evidence strength before theoretical upside. Choose a change you can finish, review, and measure during this session.

Rank the candidate actions using:
1. strength of supporting evidence;
2. relevance to the primary business action;
3. ability to complete the change or leave it review-ready during this session;
4. reversibility and implementation risk;
5. clarity of the measurement signal.

Return one action only. Include:
- why it is the current bottleneck;
- the exact page or system in scope;
- the expected leading signal;
- the evidence that would invalidate the choice;
- what is explicitly out of scope this week.

Do not convert uncertainty into a numeric score unless the inputs justify it.

What one session can look like

Suppose an existing comparison page is indexed and receives impressions for the intended query, but its search result does not clearly communicate the decision the page helps readers make. Treat search presentation as the constraint. Choose the search-presentation branch, revise the title and snippet inputs, validate any relevant structured data, and record impressions and clicks for the next review. This example shows the decision sequence without predicting the result.

Step 4: Execute one branch

Protect roughly 90 minutes for execution. Give the assistant only the material and access required for the selected branch. Ask for a finished change or a review-ready artifact. General advice is outside this branch.

Branch A: Fix technical access or indexation

Use the supplied crawl/indexation evidence and implementation context to produce the smallest safe fix for [exact issue].

Separate observed behavior from suspected cause. If you can edit the implementation, return the exact patch and focused validation. Otherwise return the files, settings, or CMS fields to change. Include risks and rollback steps. Do not change canonical, robots, redirects, or sitemap behavior without explaining the impact.

Branch B: Improve an existing page

Improve [URL] for [confirmed intent] using only the supplied sources, search evidence, and verified product facts.

Preserve accurate sections and existing query coverage. Return a gap analysis, revised structure, exact copy edits, claims requiring qualification, contextual internal links, and a concise change summary. Do not add length, keywords, or FAQs without reader value.

Branch C: Improve search presentation

Improve how [URL] appears for [confirmed query and intent] using the supplied search evidence and verified page content.

Review the title, on-page heading, snippet inputs, and eligibility for relevant structured data. Return exact edits, implementation notes, and validation steps. State what Google may choose independently. Do not promise that Google will use a proposed title or snippet or show a rich result.

If structured data is relevant to the diagnosed search appearance problem, use the Schema Markup skill to produce and validate the appropriate markup.

Branch D: Consolidate overlap or improve internal links

Compare [URLs] using the supplied evidence for intent, queries, links, conversions, and unique material.

Choose: keep separate, merge, or reposition. If merging, name the destination, material to preserve, redirects, link updates, and validation steps. If keeping pages separate, define a distinct job for each and propose only contextual internal links. Return a review-ready change plan or exact edits where access allows.

Branch E: Create a page for a confirmed gap

Run the content workflow in Flexim:

1. Choose a candidate from Suggested Topics and compare it with the site’s existing coverage.
2. Use estimated volume and difficulty to compare candidates; require audience fit and a confirmed coverage gap before approving the page.
3. Review or correct the Article Brief: reader situation, useful action, promise, scope, evidence, claim permissions, product role, and internal links.
4. Approve the brief only if the main promise has enough evidence, then create the CMS draft.
5. After connecting Flexim MCP to your AI client, scope the agent to the approved brief and draft. Keep publication as a separate human decision.

Flexim keeps the topic context, editorial contract, draft, and CMS status connected. That removes the planning document and manual transfer step that a standalone prompt would create.

Once the brief is approved, continue with the relevant specialist workflow instead of repeating it here:

• Optimize and publish a blog article in under three hours for article production;
• AI SEO tools for small business for missed-topic research;
• How autoblogging saves solo developers time for a recurring publishing pipeline.

Branch F: Improve the search-to-product path

Review [organic landing page] against the defined product action using the supplied analytics and page copy.

Identify where visitor intent, page promise, CTA, product state, or tracking diverges. Return one reversible change, the event or funnel definition needed to measure it, QA steps, and risks. Do not infer user motivation from aggregate data alone.

Use the Analytics Tracking skill when the branch requires a new event definition, measurement plan, or tracking validation.

The assistant can prepare the implementation. The owner still verifies technical behavior, product claims, and user-facing copy before release.

Step 5: Run branch-specific QA

Reserve about 20 minutes for branch-specific QA. A generic checklist can miss the failure introduced by the selected change, so review the implementation against the diagnosis and the risks of its branch.

Act as the final reviewer for this organic SEO change.

Inputs: [diagnosis], [chosen action], [implementation or revised copy], [constraints].

Check:
- whether the change addresses the diagnosed constraint;
- factual and product-claim accuracy;
- crawl, indexation, canonical, redirect, and internal-link side effects where relevant;
- intent, title, snippet, accessibility, and mobile readability where relevant;
- analytics event continuity and conversion definition where relevant;
- rollback or correction path.

Return blockers first, then warnings, then passed checks. Do not mark a check passed without evidence.

For the Flexim new-page branch, run the SEO Checklist after this review. The checklist works against the same draft, so it can catch content and publishing omissions without an extra report. Leave evidence verification and branch blockers to the branch-specific QA.

Release the change only after you resolve the blockers and understand the rollback or correction path. Otherwise, leave it review-ready for the appropriate owner.

Step 6: Record the measurement plan

Use the final 10 minutes to record the measurement plan. SEO changes rarely produce a useful verdict immediately, so capture what changed and what evidence will make you keep, improve, consolidate, or reverse it.

Create a measurement note for this change.

Include: change and release date; affected pages; baseline period; comparison period; leading search signal; product conversion signal; known data limitations; earliest sensible review point; and a keep, improve, consolidate, or revert rule.

Use only supplied data. Do not forecast rankings or traffic.

For a technical fix, the first signal may be successful crawling or the intended canonical. For a page improvement, it may be relevant impressions and clicks. For a conversion change, track the defined product action from the appropriate organic landing pages. Treat average position as context and judge the business result with the defined product conversion.

Start with the constraint, not the content calendar

For the next session, export page and query data, define one product conversion, and run the context prompt. Follow the chain until one constraint has stronger support than the alternatives. Spend the remaining time completing the corresponding change.

End with one change and a dated note. The note should explain why you made the change and when you will review the evidence.