WordPress Global Styles Audit Checklist

Quick Answer

A WordPress global styles audit should compare the intended design system with the actual sources of style truth: theme.json, the Site Editor Styles interface, style variations, block-level styles, presets, custom CSS, and theme updates. The best fit for a small publishing site is a short change register that names which layer owns colors, typography, spacing, layout, and block defaults, then records when an editor override or theme update changes those decisions.

Global Styles Decision Map

Style layer	What to inspect	Better operator decision
Theme defaults	Root theme.json, schema, version, settings, and styles	Treat this as the baseline design contract
Site Editor Styles	Global colors, typography, layout, spacing, and block tweaks	Record intentional editor overrides before theme updates
Presets	Color palette, gradients, font sizes, font families, spacing, and shadows	Keep names stable so editors do not choose mystery tokens
Block styles	Per-block defaults for buttons, headings, images, navigation, and groups	Use block defaults only when the rule belongs everywhere
Style variations	JSON files in the theme styles folder	Review each variation as a separate design path
Custom CSS	Global or block-level CSS added outside standard settings	Keep it small, named, and tied to a reason

Who Should Use This Checklist?

Use this checklist when a WordPress publisher, site operator, block-theme maintainer, or small editorial team changes a theme, edits global colors, updates typography, ships a style variation, cleans up custom CSS, or notices that blocks no longer match the site's brand system. It is especially useful for sites where multiple editors can touch the Site Editor but only one person understands the theme files.

This is WordPress site-operations guidance, not visual design certification, legal advice, accessibility certification, SEO consulting, AdSense account advice, or private theme debugging. It does not require changing Search Console, Bing Webmaster Tools, Google AdSense, DNS, payment settings, hosting settings, or production account permissions. The article uses public WordPress documentation as evidence. No private WordPress dashboard, theme repository, staging site, production URL, analytics property, Search Console property, Bing account, or AdSense account was inspected for this article.

The operating problem is that WordPress global styles can come from more than one place. A theme may define settings and styles in theme.json; an editor may change the same design areas through Appearance > Editor > Styles; a theme may ship style variations; and custom CSS may sit beside those standard controls. Without a register, a minor color or spacing change can become hard to reverse because no one knows whether it belongs to the theme, the editor, a variation, or a one-off workaround.

Step 1: Establish The Baseline Theme Contract

Start with the theme's intended source of truth. WordPress theme documentation describes theme.json as a configuration file for global settings, styles, and other theme behavior. For an operator, the file is not just developer configuration. It is the baseline contract for what editors are allowed to choose and what the front end should render by default.

Use this baseline checklist:

• [ ] Theme name and active child or parent theme.
• [ ] theme.json location and version.
• [ ] Whether the theme also ships style variation JSON files.
• [ ] Which style decisions are controlled by the theme rather than by editor overrides.
• [ ] Which settings expose editor controls for color, typography, layout, spacing, borders, shadows, dimensions, and similar design areas.
• [ ] Which styles apply globally, to elements, or to specific blocks.
• [ ] Whether custom CSS exists outside the standard global styles system.

Do not begin by changing values. Begin by naming the layers. If the site has a brand palette, typography scale, spacing system, or reusable block defaults, the audit should identify where each decision is stored before anyone edits a live style.

Step 2: Separate Settings From Styles

The easiest way to lose control of global styles is to treat every visual option as the same kind of data. WordPress documentation separates settings from styles. Settings control which tools, presets, and options are available. Styles apply the visual output. That distinction matters because an operator may need to remove a confusing control without changing the visible design, or change a visible default without exposing more controls to editors.

Use this decision table:

Audit question	Settings answer	Styles answer
Can editors choose this option?	Controlled by settings	Not enough by itself
What is the default visual result?	Not enough by itself	Controlled by styles
Are preset names clear?	Review settings presets	Apply those presets through styles
Is a block too flexible?	Disable or limit tools	Keep only the intended default
Is a block visually wrong everywhere?	Check whether a preset exists	Fix the global or block style

The better choice is to document both sides. For example, a color palette audit should record the available named colors and where those colors are applied. A typography audit should record available font sizes and where headings, paragraphs, buttons, navigation, and captions actually use them.

Step 3: Review Presets Before Editing Individual Blocks

Presets are the operator's bridge between design intent and editor behavior. A theme can define reusable values such as colors, gradients, font sizes, font families, spacing sizes, and other design tokens. When presets have clear names and sensible defaults, editors can make consistent choices. When presets are vague, duplicated, or stale, editors work around them one block at a time.

Use this preset audit:

• [ ] Color palette names match real site usage, not launch-era labels.
• [ ] Font size names are understandable and not only numeric.
• [ ] Spacing sizes reflect the current layout system.
• [ ] Gradients, shadows, and other decorative presets have a real editorial use.
• [ ] Deprecated brand colors or campaign tokens are removed or clearly marked before reuse.
• [ ] Preset slugs are stable enough that existing blocks do not break during cleanup.
• [ ] Editors know which presets are default, accent, warning, or special-use values.

For a small publishing site, fewer clear presets usually beat a large palette of unused options. The audit should not remove values casually, because old blocks may still reference them. It should mark which presets are active, legacy, or candidates for cleanup during a planned theme release.

Step 4: Inspect Root, Element, And Block Styles

WordPress style documentation describes styles at multiple levels, including global root styles, element styles, and block styles. That is useful because a publishing site often needs a global type system, element-level consistency for headings and links, and block-level defaults for recurring editorial components.

Use this style-level checklist:

Level	Typical scope	Audit question
Root	Site-wide background, text, layout, typography, spacing	Does the whole site have one coherent baseline?
Elements	Links, headings, buttons, captions, and similar HTML elements	Are common elements consistent across templates and posts?
Blocks	Navigation, buttons, images, groups, quotes, query loops, tables	Are recurring blocks readable without manual styling?
Variation	Alternative theme style JSON	Does the variation intentionally change the same design decisions?
Custom CSS	Rules outside the standard system	Is the rule still needed after the theme and Styles audit?

This is where the audit should catch invisible drift. A heading may look correct in one template because an editor patched it locally, while the root heading style remains wrong. A button may look correct on a landing page but not in a post template. A navigation block may inherit colors that work on a white header but fail on a dark style variation. The register should point each mismatch to the layer that should own the fix.

Step 5: Compare Site Editor Overrides With Theme Files

The WordPress Styles interface lets site owners adjust the overall aesthetics and layout of a block theme at a global level. That is useful for legitimate operations. It also means a live site can drift away from the theme files without a clear code change. Before a theme update or redesign, the operator should ask whether editor-saved styles are deliberate, temporary, or accidental.

Use this override register:

• [ ] Global palette changes made in the Site Editor.
• [ ] Global typography changes made in the Site Editor.
• [ ] Layout or spacing changes made in the Site Editor.
• [ ] Block-specific changes, especially Button, Navigation, Query Loop, Group, Image, Table, and Heading blocks.
• [ ] Custom CSS added through the Styles interface.
• [ ] Date, reason, and owner for each override.
• [ ] Whether the override should move into theme.json, stay as an editor-owned change, or be reverted.

The better choice is not always to move every override into code. A small operator may intentionally use the editor for fast brand cleanup. The risk is unrecorded ownership. If a change should survive a theme update and apply to every environment, it probably belongs in the theme. If it is a temporary local adjustment, it should have a review date.

Step 6: Audit Style Variations As Separate Choices

Style variations are alternate JSON style paths that a theme can ship in a styles folder. WordPress theme documentation treats them as alternate versions of the theme's style configuration. For operators, that means each variation should be reviewed like a real design mode, not like decorative sample data.

Use this style variation checklist:

• [ ] Variation filename and display title are clear.
• [ ] Variation changes have a documented purpose.
• [ ] Colors, typography, spacing, and layout still match the site's content model.
• [ ] Navigation, buttons, tables, forms, and query lists remain readable.
• [ ] The variation does not depend on one homepage preview while breaking post templates.
• [ ] Custom CSS is not compensating for avoidable variation drift.
• [ ] The team knows which variation is active on the live site.

Style variations can be useful for seasonal designs, brand refinements, or theme packages with multiple looks. They become operational risk when editors experiment on the live site without recording which variation is active, what it changes, and how to roll back.

Step 7: Keep Custom CSS Accountable

Global styles and theme.json do not eliminate every need for custom CSS. They do reduce the number of places where CSS should be the first answer. Before adding a rule, audit whether the same decision belongs in settings, styles, block defaults, a style variation, or a template change.

Use this custom CSS triage:

CSS reason	Better first check	Operator note
Brand color mismatch	Palette presets and root styles	Fix token names before adding selectors
Button inconsistency	Button block styles	Avoid one-page button patches
Heading scale issue	Typography settings and element styles	Keep heading hierarchy predictable
Table readability	Table block style and content structure	Use CSS only for durable display fixes
Mobile spacing problem	Layout, spacing, and template structure	Do not hide structural issues with narrow selectors
Third-party embed issue	Embed block, plugin settings, or isolated CSS	Keep vendor-specific rules labeled

Every custom rule should have a reason, owner, and review trigger. If no one can explain a rule, do not delete it blindly. Mark it for a controlled cleanup pass that checks affected templates and common post formats.

Step 8: Build A Global Styles Change Log

A global styles change can alter every article, category page, landing page, and template. Keep a short change log so future operators can understand what changed and why.

Use this change-log format:

• [ ] Date reviewed.
• [ ] Active theme and style variation.
• [ ] theme.json baseline checked.
• [ ] Settings changed or confirmed.
• [ ] Styles changed or confirmed.
• [ ] Presets added, renamed, deprecated, or removed.
• [ ] Site Editor overrides recorded.
• [ ] Custom CSS added, retained, moved, or retired.
• [ ] Templates or block patterns that need visual review.
• [ ] Rollback path and next review date.

This is not a claim that the article inspected a private site. It is the evidence pattern an operator should use during an approved site review. Future editors can attach screenshots, sanitized exports, theme diffs, or staging notes internally when they have permission.

What Should A WordPress Global Styles Audit Include?

A complete WordPress global styles audit includes the active theme, active style variation, theme.json baseline, settings, styles, presets, block-level defaults, Site Editor overrides, custom CSS, affected templates, rollback notes, and a change log. The audit is ready when the operator can explain which layer owns each design decision and whether the current live appearance matches the intended design system.

FAQ

Is theme.json required for every WordPress theme?

WordPress documentation describes theme.json as foundational for block theming and useful for configuring settings and styles. Classic themes can also use it for some behavior, but block themes depend on it more heavily as the central style configuration layer.

Are Site Editor style changes bad?

No. Site Editor style changes are useful when they are intentional and recorded. They become risky when no one knows whether a color, font, spacing, or block default came from the theme, the editor, a variation, or custom CSS.

Should every global style override move into the theme?

Not always. Durable brand decisions and defaults that must survive across environments usually belong in the theme. Short-lived adjustments can remain editor-owned when the owner, reason, and review date are documented.

How often should global styles be reviewed?

Review global styles every 60 days, and sooner after a theme update, WordPress editor update, redesign, style variation switch, custom CSS cleanup, Font Library change, homepage refresh, or template-part change.

Is this the same as a Style Book audit?

No. A Style Book audit checks how blocks appear in a visual preview. A global styles audit is broader: it checks the configuration layers that create those appearances, including theme.json, settings, styles, presets, variations, editor overrides, and custom CSS.

AdSense And Policy Fit

This checklist supports AdSense-safe publishing because it improves site consistency, readability, navigation clarity, and editorial operations without changing ad settings, encouraging artificial clicks, hiding disclosures, manufacturing traffic, making ranking guarantees, or using unsupported revenue claims. Global styles should help readers understand and use the site; they should not be used to disguise thin pages or push accidental ad interactions.

Source Notes

• https://developer.wordpress.org/themes/global-settings-and-styles/ checked 2026-06-13; used for source-derived analysis of WordPress Global Settings and Styles as the theme-level system for settings, styles, and theme.json.
• https://developer.wordpress.org/themes/global-settings-and-styles/introduction-to-theme-json/ checked 2026-06-13; used for source-derived analysis of theme.json structure, properties, schema, settings, styles, and theme configuration scope.
• https://developer.wordpress.org/themes/global-settings-and-styles/settings/ checked 2026-06-13; used for source-derived analysis of settings as the layer that controls available editor options and presets.
• https://developer.wordpress.org/themes/global-settings-and-styles/styles/ checked 2026-06-13; used for source-derived analysis of styles as the layer for applying theme visuals through standard WordPress style properties.
• https://developer.wordpress.org/themes/global-settings-and-styles/styles/applying-styles/ checked 2026-06-13; used for source-derived analysis of root, element, and block-level style decisions.
• https://developer.wordpress.org/themes/global-settings-and-styles/style-variations/ checked 2026-06-13; used for source-derived analysis of style variations as alternate JSON style files stored in a theme styles folder.
• https://wordpress.org/documentation/article/styles-overview/ checked 2026-06-13; used for source-derived analysis of the WordPress Styles interface and global site-level editing areas such as colors, typography, layout, and spacing.

Internal Links

Link to wordpress-style-book-audit-checklist when operators need visual preview coverage for common blocks. Link to wordpress-custom-css-audit-checklist before keeping or removing CSS outside the standard global styles system. Link to wordpress-font-library-audit-checklist when typography presets, font families, or editor font choices are part of the drift. Link to wordpress-theme-update-checklist before updating a theme that owns theme.json or style variations. Link to wordpress-site-identity-checklist when brand colors, logo usage, and visual identity need a broader review. Link to wordpress-template-part-audit-checklist when headers, footers, and reusable template areas inherit global style decisions.

Update Log

Update note: review this checklist every 60 days. Recheck official WordPress Global Settings and Styles, theme.json, settings, styles, style variations, and Styles overview documentation. Refresh earlier after a WordPress release changes theme style behavior, a theme update modifies theme.json, a style variation changes, an editor saves global overrides, Font Library choices change, or custom CSS cleanup affects visible templates.