When to run it
Use the consistency checker when a change affects repeated patterns such as headers, product cards, buttons, notices, checkout helpers, account sections, or footer blocks. A single polished page is not enough when the same component appears across the storefront.
Review scope
Compare representative pages before asking for CSS: homepage, archive, product detail, cart, checkout, account, and any campaign landing page. The checker should identify drift in tokens, typography, spacing, component density, responsive behavior, and accessibility risk. Pair this with responsive accessibility review when mobile or keyboard behavior may change.
Approval output
The final note should explain which pages were checked, which differences are intentional, which differences need design decisions, and which CSS changes remain scoped. Use client presentation workflow when the consistency review needs client approval.
Owner and cadence
- Primary owner: designer or developer, with site-owner approval for production visual impact.
- Review cadence: before publishing, after theme updates, and after cache or WooCommerce template changes.
- Escalate when repeated components drift across checkout, account, product, campaign, or navigation pages and the intended standard is unclear.
Production checklist
- Select representative pages for every repeated component family before asking Theme Assistant for a consistency recommendation.
- Document which differences are intentional and which require a design or approval decision.
- Capture the affected URL, target selector, intended visual outcome, reviewer, and rollback note for every meaningful visual change.
- Review mobile, desktop, keyboard focus, reduced motion, contrast, checkout, cart, account, and navigation behavior before publishing.
Acceptance checks
- Repeated components are reviewed across homepage, archive, product, cart, checkout, account, and campaign contexts where relevant.
- The output separates token drift, layout drift, accessibility risk, and intentional page-specific differences.
- The proposed CSS or presentation output can be traced to a specific page, component, and design goal.
- The reviewer can reject, revise, or roll back the change without guessing which selectors were affected.
Common mistakes
- Checking only the homepage and missing product, cart, checkout, account, or campaign variants of the same component.
- Publishing broad CSS from a single preview without checking logged-out, mobile, checkout, account, and cache states.
- Using external design references as production assets instead of review context.
Related operations
- Review Responsive and Accessibility Review for breakpoint-sensitive differences.
- Use Client Presentation Workflow when the findings need client approval.
- Use Responsive and Accessibility Review before visual publishing.
- Use Client Presentation Workflow when an agency needs client approval.
- Use Publishing and Rollback for Theme Changes before approving production CSS.
- Use Multi-Page Consistency Checker before broad component updates.
- Use Design Tokens and Style System before token-level changes.