Edge fixes deploy from WebOptiva; editorial fixes need your CMS
Every checklist item belongs to one of two layers, and acting in the wrong one wastes a sprint: changes WebOptiva controls are deployed from this dashboard, changes your site controls have to happen in your CMS or codebase.
The edge layer#
Redirects, SEO rules (titles, meta, canonicals, robots, JSON-LD), rewrites, cache and image policy — anything in the domain's configuration. You edit it here, it deploys from here, and the proxy applies it in front of your origin. Rule panels carry their own truth about timing: SEO rules deploy on save and invalidate cached pages, while Redirect changes affect live traffic only after Deploy is clicked.
the editorial layer#
Body copy, headings, accessibility semantics, adding real content — the checklist instructions say things like reviewing in your CMS or with your developer, precisely because WebOptiva will not (and cannot) rewrite your application's markup. The remediation side spells the same boundary out: Apply the fix in the page's own markup/CMS — WebOptiva does not change accessibility semantics automatically.
Proof of what happened#
Two histories keep you honest. The dashboard Change log (eyebrow Account activity, heading Change log, table Action | Target | Actor | Context | Observed, with From/To filters and Apply filters) records workspace-visible actions across domains; the domain's History view adds configuration versions and Published deployments. After editorial fixes, re-audit — the checklist only clears when the next audit stops seeing the finding, which is also the loop the subtitle promises (screenshot: the change log below).