Ignoring findings & tuning
Not every finding needs action. A template pack full of hardcoded colors, an intentional design choice, a rule that doesn’t fit your workflow, you can silence these so your scans stay focused on real problems.
Two ways to ignore a finding
Each finding has two ignore options:
- Ignore, hides this specific finding (this element/group). Use it when a particular case is intentional but you still want the rule active elsewhere.
- Ignore rule, hides every finding from that rule, across the whole project. Use it when a rule doesn’t apply to how you build.
Ignored items don’t count against your Health Score, and you can see and undo every ignore under Settings → Ignored.
Turning off whole audits
If an entire category isn’t relevant to a project, toggle it off under Settings → Scan modules. A disabled module is skipped during scans and doesn’t affect the score. Turn it back on any time.
Skipping whole pages
Some pages aren’t worth auditing, a staging sandbox, a legacy landing page you’re about to retire, a client’s experiment. Tick them under Settings → Skip pages and they produce no findings, cost no scan time, and are never loaded for responsive checks.
Skipping is deliberately narrower than it sounds, and this is the important part: a skipped page still counts as a place your classes and variables are used. If a global class is used only on a page you’ve skipped, it will not start reporting as “unused”, and the cleanup fixes will not offer to delete it. Asking for less noise can never cause Bricks Health to remove something your site still needs.
What the scan reads before it reports
Three sources of false positives are handled for you rather than needing an ignore.
Your theme’s own CSS and JavaScript. Before reporting an element as empty, the scan reads the stylesheets and scripts of the active theme and its child theme and checks whether anything there targets the element by class or id. An element styled or scripted from your theme is not empty. The check reads the active theme and child theme only: not plugin CSS, not files loaded from a CDN, not @import, and not the wider cascade. Class and id selectors only.
Elements a script or a class is driving. An element that carries a data- attribute, an inline style declaring a CSS custom property, or a global class that paints or sizes it counts as rendering something, and is not reported as an empty wrapper. Each of those is an act you only perform on purpose. The suppression has a floor: a class that sets only padding or margin still leaves the box empty, and that is the spacer case the rule exists to report.
Automatic.css. If Automatic.css is active, its utility classes are recognised from three places, the framework’s own configuration, its generated stylesheets, and the ACSS category in your Bricks class manager, and shown as managed in the site inventory rather than as unused. They are never reported as unused or single-use. The category is read alongside the files so that classes left registered by an older Automatic.css version, or by a module you have since switched off, are still recognised as the framework’s rather than offered for deletion. Automatic.css is the only framework recognised this way.
A wrapper whose only child is a query or repeater loop is also no longer reported as a pass-through wrapper, since the loop is what it is for.
When to ignore vs fix
- Fix when the finding reflects real debt, hardcoded colors on your own site, duplicated styles, mobile overflow.
- Ignore when it’s a deliberate choice, a one-off brand color, a decorative pattern, a third-party template you don’t intend to refactor.
Tuning is normal. A scan you trust is one where every remaining finding is something you’d actually act on.