Actions

The assistant can change things, but only through the same guarded workflow the rest of SERPclimber uses. It explains and prepares; the project's scope and autonomy policy decide what runs.

What the assistant can do

Read-only requests need no approval: reading projects, tasks, audit findings, Performance evidence, reports, settings, integration status, published pages, and documentation, plus Search Console analysis and keyword research.

Changes are prepared as actions. The supported action classes are creating a task draft, commenting on a task, updating a task's status, marking a listing submitted or not relevant, running a site crawl, running an authority refresh, and preparing a guided checklist for work you will do yourself. Metered live checks — asking the AI engines a question, or a paid keyword lookup — count against your plan's allowances and are described as such before they run.

The assistant can also work the Tasks lanes on your say-so: skip a task with a reason, reopen a closed one, assign it to you or the engine, set its priority, record that you did the work yourself, and approve the plan a task is waiting on. It acts on one task or many at once and reports each separately. Approving is the one verb that authorises a site change or a spend, so it names the exact frozen plan and asks you in the same conversation before running it. Recording work as done is a claim the engine still verifies, and it is refused while the evidence behind the task is still open unless you ask to override that. Asking the assistant to file work creates a task owned by you in Your move.

The assistant cannot change account, billing, or integration credentials. It can open the secure Integrations screen for you.

Prepared actions

Before anything runs, a plan freezes:

• the exact target and intended change;
• the risk level and reversibility;
• estimated cost;
• whether approval is required;
• the steps and any warnings;
• the live verification method.

Under Copilot the assistant executes only low-risk classes on its own. Under Audit only / MCP it never executes site changes. Full still respects the per-action spend limit and maximum risk. Custom follows the rule for each department or action class.

A plan that needs approval waits in its task thread with Approve plan and Reject buttons. Approving executes that exact plan. If the target, policy, or evidence changes first, the plan is superseded and must be prepared again.

Reversibility

• Reversible means SERPclimber kept the previous state and has a supported undo path.
• Conditional means recovery depends on current state, timing, or an external system.
• Irreversible means SERPclimber cannot safely restore the previous state.

External effects are never called reversible merely because someone could compensate later.

Bulk work and partial failure

Related findings become one bounded task. Before a bulk action the plan freezes the exact targets. Results separate succeeded, failed, and skipped targets; retrying prepares a new plan for the failed targets only, so successful work is never repeated.

Content and publishing

Generated content appears in the task as a reviewable proposal with the current value, the proposed value, and the reason. Publishing to a connected CMS uses its own plan and policy check, and a fresh check runs immediately before the write. After execution the engine verifies the live page rather than trusting the tool response, and the receipt stays in the task thread.

Outside AI clients

MCP clients use the same two-step contract — prepare, then execute with the returned plan ID. See MCP access.