Audits, tasks and credits

These tools close the loop between finding something and doing something about it. start_site_audit dispatches a crawl, get_site_audit_issues reads what it found, the task tools turn findings into work, get_site_timeline explains what changed and when, and the two credit tools tell you what any of it costs before you commit.

The table above is generated from RankX AI itself rather than written by hand, as at 19 August 2026 (source 377ef780). When the product changes, this page changes with it.

Running an audit

start_site_audit is the first dispatch-and-poll pair. It returns a job id immediately and the crawl takes minutes; poll get_site_audit_status until it reports complete, then read the findings with get_site_audit_issues.

Two modes: a full crawl, or a single-page quick check. It spends credits per page crawled, and its own description carries the current price. This documentation does not print prices, because rates in RankX AI are versioned and republishable.

get_site_audit_issues returns the most recent completed audit only, with severity, category, affected page counts and fix guidance, plus the overall score and crawl statistics.

A check that did not run is reported as not assessed, never as passed. Three audit paths exist, not every check can be produced by every path, and RankX AI records the coverage per check rather than inferring it. Seven checks once rendered confident green ticks for checks that had never run, and this is the fix. See what "a check did not run" means.

The Tasks board

list_tasks reads it, ordered by opportunity score rather than by category. Dismissed tasks are excluded unless you ask for them.

create_task is additive only, and it deduplicates: pass the source that prompted the task, and if an open task already tracks that source, the existing task is returned rather than a copy. This is what stops an assistant running the same analysis twice and producing two boards.

apply_task_fix is the one tool here that changes something outside RankX AI. It applies a task's recommended fix to a connected WordPress site, currently the SEO title and meta description, and it carries the publish scope for that reason rather than sitting with the rest of the group.

It dry-runs by default. The dry run returns the exact before and after, plus a run id. Show the diff to the person, and only if they agree call again with the dry run switched off and that run id. Several tasks often point at one page: the diff says how many the change resolves, and they are resolved together for a single charge.

The change timeline

get_site_timeline is the correlation axis, and it is the tool most integrations forget exists. It merges onto one time axis every change RankX AI made to the site, every article published, every audit completed and every task finished, newest first.

Use it to explain a movement rather than to find one: fetch the traffic or ranking change first, then ask the timeline what happened around that date.

It states its own blind spots on every response, not just an empty one, and that is deliberate: shown only when empty, a caveat reads as an excuse. The timeline is a record of what RankX AI did, not a history of the website. An edit made directly in WordPress, a plugin update, a hosting incident and a change at a search engine are all invisible to it.

So an empty result means "we have no record", never "nothing happened", and an assistant reporting it should pass that caveat on rather than presenting the timeline as complete.

Its counts describe the match, not the returned slice: the summary is what gets quoted to a person while the table is only what fitted.

Credits

Both credit tools are free to call, and calling them is the difference between proposing work and proposing work someone can afford.

get_credit_balance returns credits available now, credits held by work in flight, the plan and its monthly allowance, any trial state, when unspent grants expire, and on a client-scoped credential the ceiling set for that client. RankX AI instructs every connected assistant to call it before proposing anything that spends, because a price with nothing to weigh it against is not a decision.

get_credit_usage answers "where did my credits go" over a period, grouped by action or by Website. Two properties make it trustworthy:

Refunded work nets to zero and never reads as spend. The wallet reserves before the work and releases in full on failure, so a failed action leaves no spend behind it.

Platform-funded onboarding writes no ledger rows, so the free setup package cannot inflate the figure.

Action grouping carries no client dimension, so a client-scoped credential is refused it and pointed at Website grouping rather than being served an account-wide total it should not see.

Example prompts

"Start a site audit on my main website. Tell me what it will cost first, then poll until it finishes and give me the issues by severity."

"Show me the top ten tasks by opportunity score, and tell me which of them point at the same page."

"Apply the SEO title fix for task X. Dry run it first and show me the exact before and after."

"My Search Console clicks dropped around the 14th. What does the site timeline say happened around then, and what can it not see?"

"What is my credit balance, and how much of it is held by work in flight?"

"Where did my credits go last month, grouped by website?"

Where to go next

• Running an audit for the workflow.
• Tasks for the board itself.
• Credits and metering for the wallet model and the four refusals.