Re-audits and improvement tracking

A single audit is a snapshot. The signal that matters is how that snapshot changes over time. CiteFlow re-audits your site on a schedule, computes deltas against the previous audit, and surfaces the four change types so you can see whether your work is paying off.

For a walkthrough of what a single audit covers (the 35 finding keys, the three pillars, the action plan), see the audits module guide. This page focuses on the lifecycle: when re-audits fire, how deltas are computed, and how to read them.

What's the difference between an initial audit and a re-audit?

Your first audit is the baseline. It runs automatically after domain verification and has no deltas attached, because there is nothing to compare against. The baseline matters: every subsequent re-audit is measured against the most recent completed audit, which traces back to this first one.

Re-audits come in three flavours, recorded as the audit's run_type:

• initial, the first audit on a verified domain.
• scheduled, fired by the cron scheduler when the cadence interval has elapsed.
• manual_reaudit, kicked off from your dashboard's Audits page.

How often does a re-audit run?

The scheduler runs daily with a system-wide cap of 20 enqueued re-audits per day, ordered oldest-first so no tenant is starved.

A re-audit is skipped this cycle if you already have an active audit in flight (queued, crawling, analysing, or paused). The next cycle picks it up automatically.

How do you trigger a manual re-audit?

You can trigger a manual re-audit from the Audits page in your dashboard whenever you want. Manual re-audits are rate-limited per tier to protect both your costs and the SerpAPI / crawler budget; the dashboard tells you when the next manual run is allowed.

A manual re-audit produces a real audit and contributes to delta computation exactly like a scheduled one.

How are deltas computed?

Delta computation runs automatically when an audit completes (when it has a previous_audit_id). The computer:

1. Aggregates findings from both audits, grouped by finding_key + scope (where scope is site or page).
2. Counts how many findings of each key existed in each audit.
3. Classifies each key into one of five change types.
4. Inserts one delta row per key into target_site_audit_deltas.

The audit's deltas_computed_at timestamp confirms the work succeeded. A delta-computation failure never blocks audit completion, so even if deltas are missing you still have your fresh scores.

What are the four change types?

The dashboard surfaces deltas as four buckets. (A fifth type, unchanged, exists internally but is not shown.)

Resolved + Improvements together are your wins for the cycle. Regressions + New issues are your work to do.

What does a re-audit actually measure?

Same scope as the initial audit. The crawler re-fetches every page, re-runs every check across the three pillars (SEO, AEO, LLMO), and re-scores. Nothing is incremental, every audit is a fresh, full crawl, which means the comparison is apples-to-apples.

For the full list of finding keys and how each is computed, see the audits module guide.

How are pages categorised by type?

Every crawled page is classified into one of eight types so you can filter findings by template:

• homepage
• content
• listing
• product
• category
• blog_post
• author
• utility

This matters because some findings only apply to specific page types (for example, "missing author schema" on author pages). Filtering by page type lets you focus a fix on the right template.

How does the by-template view work for marketplace sites?

Marketplace sites can have thousands of nearly-identical pages (product listings, author pages, geo-pages) where a single template fix resolves hundreds of findings at once. The audit detail page offers a "by template" grouping that collapses findings by URL pattern, so a single regression on your product template shows as one issue, not 5,000.

What is the section pattern audit?

For large sites where you only want to re-audit a slice (a single locale, a single subdirectory), the section-pattern filter accepts a URL pattern and restricts the crawl. Useful when you have shipped a fix to one section and want a fast feedback loop without re-crawling the whole site.

When are email notifications sent?

Audit completion sends an email to the tenant owner. The email includes the new overall score, the count of each delta type, and a deep link back into the dashboard. This is how trial customers get their end-of-trial audit summary even if they have not logged in.

Frequently asked questions

My fix is live but doesn't show as resolved. What's happening? Usually one of three things. (1) The next scheduled re-audit has not fired yet, check the cadence above. (2) The page that had the finding was crawled from cache; on the next re-audit the cache is refreshed and the finding will clear. (3) The fix was applied to a different URL than the one CiteFlow flagged (for example, the staging URL instead of the production URL).

Can I re-audit just one page? Not today. Audits are whole-site by design so deltas remain comparable. The section-pattern filter is the closest thing, restrict to a subdirectory to get a faster cycle.

Why does my delta count show fewer improvements than I expected? Deltas are per-finding-key, not per-page. If you fixed three different problems on one page, that's three delta rows (each saying "page count went from 1 to 0"), not one. Conversely, fixing the same problem across 50 pages is one delta row (count went from 50 to 0).

An audit completed but the deltas are empty. The audit had no previous_audit_id, it was either your initial audit or the link to the previous one was severed by a manual reset. The next re-audit will have deltas again.

How do you troubleshoot re-audit issues?

The scheduler hasn't fired my re-audit. Check that your subscription isn't cancelled, your previous audit completed cleanly, and you don't already have an active audit in flight. The scheduler skips tenants in any of those three states.

Re-audit shows much worse scores than the previous one. Compare the new-issues bucket. The most common cause is a new section of the site (new locale, new blog category) that was added between audits and is contributing fresh findings.

Related

• Audits module guide, how a single audit works and what the 35 finding keys check.
• Performance dashboard, your audit score is one of three inputs to the composite AI Visibility Score.