One-click fixes

Fix issues automatically

A site-health issue or a Search Console recommendation can be turned into a published fix. VectraSEO builds the smallest patch that resolves it, re-checks the result through the same quality gates as a normal publish, republishes it through your connected CMS and requests a recrawl. Where it cannot write to the page, it gives you a change set to apply yourself. Every attempt ends in a stated outcome, never a silent no-op.

Three kinds of page

Wix updates carry only the title and excerpt, so a fix that changes a post's body cannot be republished to Wix (reason body_update_unsupported); metadata fixes can.

Fixers

Deterministic fixers use no AI model and are not plan-gated. Model fixers write new text and need a paid plan or an active trial; without one the request returns 403 with code: "subscription_limit" before anything is queued.

Run a fix

The fix routes queue a job and return its job_id; poll GET /api/v1/jobs/{job_id} until it completes. For a site-health issue, take scan_id, url, rule_id and severity from the scan's issues; a rule no fixer handles is a synchronous 422.

• Single issue. implement takes {scan_id, url, rule_id, severity, fixer_id?} and answers with the tier. Tier C returns no job and republish_skipped: "no_write_path": build a change set instead.
• Every page one rule flagged. implement-batch takes {scan_id, rule_id, severity?, fixer_id?} and runs one job over the pages VectraSEO wrote; the rest are counted in skipped_unowned.
• Fix all recommendations. Call apply-all with dry_run: true first to see the plan; include_refresh: true opts into the paid content-refresh tier.
• One batch at a time. A project runs one Fix-all batch at a time; starting a second returns 409 naming the running job.

Change sets (pages VectraSEO can't write)

POST …/issues/change-set takes {url, rule_id, severity?, scan_id?, fixer_id?, persist?}. Pass scan_id and severity so the fix uses the issue's evidence. When the job completes, read the result from GET /projects/{id}/change-sets/job/{job_id}. With persist: true it is also kept in GET /projects/{id}/change-sets. Nothing is published.

The live page is the source of truth

For a published post, the fixer reads your live page, not a stored copy, and patches that. Edits you made outside VectraSEO are kept, not overwritten. It finds the editable content through the body marker, or falls back to the page's single <main> or <article> element checked against the last body VectraSEO sent. If the page can't be read, or its content can't be isolated with confidence, the fix is skipped rather than applied to an older copy. After a successful fix, VectraSEO's own copy is re-synced to the live, patched version.

Did the live page actually change?

A 2xx from your CMS is not proof that visitors see the fix. Before the update, VectraSEO fingerprints the live URL (ETag, Last-Modified and a hash of the content), then re-reads it for a short window afterwards. The result is stored on the post as live_verification.status: verified, unchanged or unknown. unchanged means the CMS accepted the write but the page did not move, typically a static site that does not rebuild on update, and the fix is reported as unverified. unknown means the page could not be measured; failing to observe is not evidence of failure, so the fix stays published. The check can never fail or delay the write.

Outcomes

A site-health issue carries fix_status: "submitted" while its job runs, then one of these. Batch results report the same as counts (republished, republished_unverified, republish_failed, skipped, failed) plus one items entry per page.

Skip reasons