Audit score dropped unexpectedly

Symptoms

• Your audit score fell sharply between two runs.
• New critical or high-severity findings appeared that weren’t there last time.
• A defect seems to affect many pages at once rather than a single URL.

A score is a roll-up of weighted findings, so it moves when findings change. The platform weights indexation and crawlability problems most heavily — noindex and x-robots conflicts, robots/WAF blocking of critical pages or AI bots, canonical conflicts and cluster failures, soft 404 candidates, redirect loops, and broken internal links to important pages. A single template-wide regression in any of those can move the score more than dozens of low-severity items. Diff the two runs before assuming the worst.

Likely causes

• A newly detected critical. A deploy added a noindex meta tag or X-Robots-Tag header, pointed a canonical at a redirect or non-200, introduced a canonical loop, or shipped a Disallow that now blocks important paths (including AI crawlers).
• A regression — something fixed came back. Findings carry status (new, recurring, regressed, fixed); a regressed item is a previously resolved issue that reappeared.
• A template-wide defect. A change to one template propagates to every page built from it, so the finding count and weight jump together. Scope on the finding reads template or site rather than page.
• Render-parity change. JavaScript now alters the canonical, robots directive, or primary content after hydration, so raw and rendered disagree.
• New external evidence. A connector reconciliation (GSC selected canonical, traffic-weighted severity) upgraded existing findings now that data is present.

How to fix it

1. Diff against the prior run. Open Audit → Findings and filter by status new and regressed. These two buckets explain almost every score drop — they are exactly what changed since the last run.
2. Sort by severity and weight. Address criticals first. Indexation-blocking findings (noindex, x-robots, robots/WAF blocks, canonical failures, soft 404s, redirect loops) carry the heaviest weight, so resolving one can recover most of the lost score.
3. Check the scope. A finding scoped template, cluster, or site is systemic — fix the template once rather than chasing individual URLs. The finding’s affected-resources list shows the blast radius.
4. Read the evidence and guidance. Each finding ships observed-vs-expected evidence plus a guided fix — and where the fix is a file (robots.txt, a canonical tag, a JSON-LD block), the corrected artifact itself. Apply the suggested fix rather than reverse-engineering the problem.
5. Confirm the timeline. Cross-reference the run date against your deploy history. A score that fell right after a release points squarely at that change.
6. Re-run a validation crawl. After applying fixes, re-run the audit. Resolved findings move to fixed and the score recovers on the next run.

Rule out false positives

Not every drop is a real regression. If a flagged noindex, AI-bot block, or canonical chain is intentional, mark it Intentional so it stops counting against the score. See False positives and confidence levels for how confidence interacts with severity.

Still stuck?

If new and regressed are empty but the score still moved, the change likely came from new connector evidence or a re-scoped finding — email support@visibilityiq365.com with your project name and the two run dates. See also Audit shows no issues or empty results and Crawl not completing.