Quick Answer
A WordPress custom CSS audit checklist should identify every place where visual overrides can live, decide whether each rule belongs in the Site Editor, the Customizer Additional CSS field, theme.json, a child theme, or a plugin, and remove duplicate or stale rules before a theme update. The best fit for a small publisher is a short inventory, one source of truth for each style decision, and a regression set covering homepage, post, page, archive, search, and mobile layouts.
Audit Map
| Review area | What to verify | Better operator decision |
|---|---|---|
| Style surface | Site Editor Styles, Customizer Additional CSS, theme file, child theme, plugin, or block-level CSS | Find the real source before editing |
| Scope | Sitewide, template-level, block-level, or one-off page change | Keep rules as narrow as the problem |
| Ownership | Editor, theme maintainer, developer, or plugin owner | Assign a clear maintenance owner |
| Duplication | Same selector, color, spacing, or layout rule repeated in multiple places | Keep one source of truth |
| Theme update risk | Rule depends on theme class names, block markup, or plugin markup | Record the rollback path |
| Regression set | URLs and devices checked after cleanup | Prevent invisible layout drift |
Who Should Use This Checklist?
Use this checklist when a WordPress publisher, editor-operator, theme maintainer, or small site owner needs to understand why a site looks different from the active theme, why a style change stopped working, or why a theme update changed spacing, colors, navigation, buttons, captions, or archive layout.
This is operational site-maintenance guidance, not legal, professional accessibility certification, security incident response, financial, tax, medical, or compliance advice. It does not claim that Yolkmeet inspected a private WordPress dashboard, Site Editor screen, Customizer screen, theme directory, child theme, plugin setting, production database, Search Console account, Bing account, Google AdSense account, server log, or staging site. The article is source-derived analysis from public WordPress documentation.
The practical issue is that WordPress can store visual decisions in several layers. Block themes expose the Styles interface in the Site Editor. Classic themes may still use the Customizer. A theme may define settings and styles in theme.json. A developer may add a child theme stylesheet. Plugins may add front-end styles. A content editor may add block-level classes. Without an inventory, the next operator may "fix" a layout by adding another override instead of removing the older one.
Step 1: Inventory Every CSS Surface
Start by naming where custom styling is allowed on the site. Official WordPress documentation describes Styles as a sitewide design layer for block themes, and the Customizer documentation describes Additional CSS as one of the Customizer options. The WordPress post type documentation also notes that custom CSS saved from the Customizer is stored as a theme-specific custom CSS post type.
Use this inventory before making a change:
| Surface | Typical owner | Audit question |
|---|---|---|
| Site Editor Styles | Editor-operator or theme owner | Is the change a global color, typography, layout, or block-style decision? |
| Site Editor Additional CSS | Editor-operator or developer | Is this rule really sitewide, or should it become a narrower block or theme rule? |
| Customizer Additional CSS | Site owner or legacy theme owner | Is this legacy CSS still active after a theme switch or block theme migration? |
| theme.json | Theme maintainer or developer | Should this be a theme-supported design token or block style instead of ad hoc CSS? |
| Child theme stylesheet | Developer or deployment owner | Is the rule version-controlled and tied to a release process? |
| Plugin stylesheet | Plugin owner | Is the rule compensating for plugin output that should be configured elsewhere? |
| Block custom class | Content editor or template owner | Is the class reused and documented, or only attached to one page? |
The first audit decision is not whether a rule is beautiful. It is whether the rule is stored in the right layer.
Step 2: Separate Global Decisions From One-Off Fixes
WordPress Styles documentation frames the Styles interface as a global layer: colors, typography, layout, spacing, and block defaults can affect the whole site. That is useful when a publisher wants consistent buttons, headings, links, and spacing. It is risky when a one-page layout issue is solved with a global override.
Use this decision table:
| Situation | Better choice | What to avoid |
|---|---|---|
| Every button needs a consistent color | Use Styles or theme.json if the theme supports it | Repeating button CSS in posts |
| One landing page needs a special section | Use a block style, pattern, template, or documented class | Changing the global button or group block style |
| A theme class changed after an update | Review the theme update and selector dependency | Adding a broader selector without removing the old rule |
| A plugin widget has a spacing problem | Check plugin settings and generated markup first | Applying sitewide CSS that affects unrelated widgets |
| The homepage header differs from posts | Audit templates and template parts first | Adding CSS that hides the underlying template mismatch |
| A color token belongs to the brand system | Move it into the theme-supported style layer | Leaving raw hex values scattered across custom CSS |
The best fit is the narrowest durable layer. If the issue is editorial layout, fix the content, block, or template. If the issue is a global design system decision, use the theme-supported global style layer. If the issue is a temporary patch, label it as temporary and add a review date.
Step 3: Look For Duplicate And Stale Rules
A custom CSS audit should remove confusion, not just collect selectors. Export or copy the current rule set into a private operator note, then classify each rule:
- [ ] Keep: the rule still supports a current layout decision.
- [ ] Replace: the rule can become a Site Editor style, theme.json setting, block style, or child theme rule.
- [ ] Narrow: the selector affects more templates or blocks than intended.
- [ ] Merge: two rules solve the same color, spacing, width, or typography problem.
- [ ] Remove: the target block, plugin, theme class, or template no longer exists.
- [ ] Monitor: the rule depends on markup from a plugin, navigation block, embed, gallery, or theme update.
For each rule, record the selector, current purpose, owner, affected URL examples, and removal risk. Do not publish private selectors when they reveal staging URLs, internal class names tied to unreleased templates, plugin license output, user names, or private business workflows.
Step 4: Check Theme And Editor Boundaries
The WordPress Site Editor documentation describes editing site parts such as header, footer, templates, and styles through blocks. The theme.json handbook describes theme-level configuration for settings and styles. For an operator, this creates a useful boundary:
| If the rule changes… | First review… |
|---|---|
| Sitewide typography or color | Styles and theme.json |
| Header, footer, or navigation spacing | Template parts and navigation structure |
| Single post content width | Template hierarchy and post template |
| Archive card spacing | Archive template, query loop, and block styles |
| Form or widget layout | Plugin settings and plugin markup |
| One page section | Page content, pattern, or custom block class |
This boundary prevents a common maintenance problem: using CSS to hide a template ownership issue. For example, if navigation wraps badly on mobile, the first review should include the navigation structure and header template part, not only the CSS selector that currently targets it.
Step 5: Build A Small Regression Set
After editing or removing custom CSS, check representative layouts. The regression set should be short enough to repeat after every theme update:
| Surface | URLs or states to review |
|---|---|
| Homepage | Desktop, tablet, mobile, header, hero, recent posts, footer |
| Single post | Recent post, old post, post with image, post with table, post with embed |
| Page | About, contact, policy, and any custom landing page |
| Archive | Category, tag if used, paginated archive, empty or thin archive if relevant |
| Search | Results page, no-results page, search form placement |
| 404 | Recovery links, header, footer, and readable main content |
| Interactive blocks | Navigation menu, buttons, forms, accordions, embeds, galleries |
This is a visual and functional review. It should not become a public claim that a private site was tested. Keep screenshots, dashboard paths, CSS exports, and exact affected URLs in private operator evidence unless the site owner has approved public disclosure.
Step 6: Keep A CSS Change Log
A useful WordPress custom CSS change log should include:
- [ ] Date of change.
- [ ] Theme name and whether it is a block theme or classic theme.
- [ ] Styling surface changed.
- [ ] Selector, token, or block style affected.
- [ ] Reason for the change.
- [ ] Affected page types.
- [ ] Owner who can approve future removal.
- [ ] Rollback method.
- [ ] Next review date.
Keep the log close to the source of truth. If CSS is version-controlled in a child theme, commit messages and pull requests can carry the detail. If the CSS lives in the WordPress editor, keep a private operator log with enough context for the next reviewer to decide whether a rule is still needed.
What Should Stay Out Of Public Notes?
Do not publish private CSS exports, hidden staging URLs, unpublished template names, production screenshots with account data, plugin license keys, server paths, WP-CLI output, database rows, Search Console data, Bing Webmaster Tools data, Google AdSense account details, internal editor comments, or security-sensitive class names.
Public notes can describe the checklist and cite official WordPress documentation. Private notes can store the full rule inventory, affected URLs, screenshots, rollback commands, and reviewer names.
What Is The Best Source Of Truth For Custom CSS?
The best source of truth depends on ownership. For an editor-managed block theme, global visual decisions usually belong in WordPress Styles or theme-supported settings. For a maintained custom theme, durable decisions often belong in theme.json or a version-controlled stylesheet. For a temporary production fix, a short-lived documented override can be acceptable if it has an owner and a removal date.
Avoid splitting the same design decision across the Site Editor, Customizer, theme.json, child theme CSS, and plugin overrides. That makes the next theme update harder to review and increases the chance that a stale rule wins because of selector specificity rather than intent.
Common Questions
Should small publishers use Additional CSS at all?
Yes, but sparingly. Additional CSS can be useful for small, clear overrides. The audit goal is to keep those overrides documented, scoped, and reviewed instead of letting them become an invisible second theme.
Is theme.json always better than custom CSS?
No. theme.json is a strong fit for theme-supported settings, styles, and design tokens. A content-specific one-off may belong in a block, pattern, or template instead. Choose the layer that matches ownership and scope.
Should I remove all old CSS after switching themes?
No. First inventory it. Some legacy rules may no longer apply, but others may still affect active blocks, plugin output, or migrated templates. Remove rules only after checking representative pages.
How often should custom CSS be audited?
Review custom CSS after a theme update, block theme migration, Site Editor redesign, navigation change, plugin layout change, or visible layout regression. For stable publishing sites, a lightweight review every 60 days is enough.
Source Notes
- https://wordpress.org/documentation/article/styles-overview/ checked 2026-06-11; used for source-derived analysis of WordPress Styles as a global layer for block themes, sitewide design changes, block-level style defaults, and Additional CSS in the Styles interface.
- https://wordpress.org/documentation/article/site-editor/ checked 2026-06-11; used for source-derived analysis of the Site Editor as the place where block themes expose full-site design surfaces, templates, template parts, and styles.
- https://wordpress.org/documentation/article/customizer/ checked 2026-06-11; used for source-derived analysis of legacy Customizer surfaces, including Additional CSS.
- https://wordpress.org/documentation/article/what-is-post-type/ checked 2026-06-11; used for source-derived analysis of custom CSS as a theme-specific post type for CSS saved from the Customizer.
- https://developer.wordpress.org/themes/global-settings-and-styles/ checked 2026-06-11; used for source-derived analysis of theme.json as a theme-level settings and styles configuration surface.
- https://developer.wordpress.org/themes/global-settings-and-styles/styles/ checked 2026-06-11; used for source-derived analysis of style properties in theme.json, including global, element, block, and custom CSS considerations.
No private WordPress dashboard, Site Editor session, Customizer screen, theme file, child theme repository, plugin setting, production URL set, CSS export, server log, Search Console account, Bing Webmaster Tools account, Google AdSense account, or staging site was inspected for this article. If a future operator adds account-specific CSS evidence, keep it private and limit public claims to the documented environment.
Internal Link Notes
Link to wordpress-style-book-audit-checklist when the reader needs a visual inventory before changing styles. Link to wordpress-template-hierarchy-audit-checklist when CSS appears to be compensating for the wrong template. Link to wordpress-theme-update-checklist when a rule may break after a theme update. Link to wordpress-navigation-menu-checklist when header or mobile navigation styles are involved. Link to wordpress-cache-clearing-checklist when stale CSS appears after a change.
Update Note
Review this checklist every 60 days. Recheck official WordPress documentation for Styles, Site Editor, Customizer, custom CSS storage, and theme.json. Refresh earlier after a major WordPress release changes the Site Editor, Additional CSS surfaces, block style controls, style revisions, or theme.json behavior.