Content Audits

Audit evaluates existing content against your active ContentGuard rules and reports findings. It does not modify posts, fields, or rules.

What an audit does

1. Collects post types that have active rules
2. Scans published and private posts of those types
3. Evaluates each post against the same rule engine used at save time
4. Stores findings with field, rule, severity, and row context where applicable
5. Summarizes outcomes so you can review what passed and what needs work

Drafts, autosaves, and revisions are not included in audit scans.

Outcomes

Summary	Meaning
Passed	No blocking or warning findings for that post
Need attention	One or more Blocking findings
Need review	Warning findings (publication would still be allowed)

Findings identify the affected field and rule. Repeated/nested failures retain row context where applicable.

Running an audit

Open ContentGuard → Audit and start a run when no other audit is active. Large sites process content in batches (100 posts per batch) with progress shown while the run is active. Duration depends on content volume and hosting—audits may take longer on large sites.

You can cancel an in-progress run. Stale runs that stop making progress are failed so a new run can start.

History, filters, and pagination

Completed runs can be reviewed historically. Findings support filtering by severity (blocking vs warning), rule, and post type, with paginated results. Audit history is also paginated.

Repeated and nested findings

When the same rule and field fail on multiple Repeater rows, Audit collapses those failures into one finding and lists the affected rows (or nested outer/inner coordinates). Messages look like:

• Ingredient is required in row 3.
• … in 3 rows (rows 1, 2, 5).
• Nested pairs such as 2/1 for Repeater → Repeater paths

See Repeater Behavior.

Relation to publish-time validation

Audit uses the same active rules and evaluation logic as editor save validation, against stored published/private values. A Blocking audit finding means that content would also fail a Blocking rule on a supported publish/update path until it is fixed. Warnings appear as content that needs review.

Audit never blocks editors by itself—it only reports. Blocking still happens at save/publish time on supported paths.

Limitations and scale

• Only active rules are evaluated
• Only publish and private statuses are scanned
• Inactive rules and draft content are out of scope for the scan
• Processing is batched; very large sites need time and a stable admin session while the run progresses
• Audit does not send data to external services