--- title: "The Block-Category Gap Audit: What Does Your Site Actually Need?" date: 2026-07-22 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-block-category-gap-audit.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # The Block-Category Gap Audit: What Does Your Site Actually Need? A block-category gap audit compares required content outcomes with proven editor capabilities. Audit core blocks, patterns, themes, installed plugins, workarounds, governance, and actual usage before purchasing. ## What is a block-category gap audit? It identifies content jobs the current WordPress block system cannot acceptably complete. The output is a prioritised requirement list, not a shopping list. ## Block categories are navigation, not requirements WordPress groups block types to help users browse the inserter. Those categories do not describe every business outcome or editorial workflow. ## Start with recurring content jobs List what visitors need to understand, compare, submit, navigate, watch, or download. Also list what editors must create, approve, reuse, update, and retire. ## Describe each job precisely Name the audience, content, interaction, context, constraints, and accepted result. “Need more design blocks” is too vague for a useful audit. ## Choose the audit boundary Select sites, post types, templates, languages, roles, devices, and review dates. A portfolio audit should preserve important site-specific requirements. ## Inventory current content Sample high-traffic pages, key journeys, recent posts, templates, and planned campaigns. Include drafts and archived layouts when they represent recurring work. ## Inventory available block types Record block names, namespaces, categories, versions, sources, and enabled contexts. Core, theme, plugin, and custom blocks need visible ownership. ## Inventory patterns separately Patterns are predefined block layouts available through the editor. A pattern can solve composition work without adding another block type. ## Inventory theme capabilities Record templates, template parts, style variations, [global styles](https://wpblocksuite.com/blog/wordpress-global-styles/), and supported controls. A theme change can alter available design tools without changing block plugins. ## Inventory reusable content Find [synced patterns](https://wpblocksuite.com/blog/synced-patterns-wordpress/), local patterns, templates, and documented starter layouts. Repeated manual layouts can signal a reuse gap, not a block gap. ## Audit text outcomes Test paragraphs, headings, lists, quotations, code, details, footnotes, and structured emphasis. Check semantics, keyboard use, styles, copying, translation, and responsive reading. ## Audit media outcomes Test images, galleries, audio, video, files, captions, credits, and alternative text. Include cropping, focal points, loading, embeds, and mobile behaviour. ## Audit layout outcomes Test groups, rows, stacks, grids, columns, covers, spacing, alignment, and containment. Use representative narrow, wide, nested, and long-content examples. ## Audit navigation outcomes Test menus, page lists, breadcrumbs, in-page navigation, pagination, and search discovery. Include keyboard navigation, current-state cues, focus, and small screens. ## Audit discovery outcomes Test related content, query displays, filtering, sorting, search, archives, and taxonomy views. Define which controls visitors need and which editors configure. ## Audit comparison outcomes Test tables, feature comparisons, specifications, prices, rankings, and decision summaries. Check small-screen reading, headers, semantics, editing, imports, and structured data needs. ## Audit conversion outcomes Test calls to action, buttons, forms, notices, testimonials, and trust content. Separate block presentation from form processing, consent, delivery, and analytics. ## Audit disclosure outcomes Test accordions, details, tabs, citations, source notes, and conditional explanations. Hidden content still needs keyboard access, semantics, findability, and printable behaviour. ## Audit social-proof outcomes Test quotations, reviews, ratings, author details, logos, and case-study summaries. Verify evidence ownership, dates, consent, sources, and update workflows. ## Audit structured-content outcomes Test repeated records, fields, templates, relationships, queries, and controlled presentation. A block alone may not provide the required content model. ## Audit site-template outcomes Test headers, footers, singular templates, archives, search, error pages, and [template parts](https://wpblocksuite.com/blog/wordpress-template-parts/). Separate Site Editor needs from post-content block needs. ## Audit interactive outcomes Test state changes, validation, loading, history, focus, fallback, and error recovery. Static visual resemblance does not prove equivalent interactive behaviour. ## Test core blocks first The Core Blocks Reference lists WordPress block-library capabilities and declared support. Configure core options fully before declaring a missing capability. ## Test composition before extension Several existing blocks can combine into the required outcome. Judge the resulting editor workload, consistency, output, and maintenance. ## Test a pattern solution Build the recurring layout once and expose it with a clear title. Test discovery, insertion, editing, variation, localisation, and future updates. ## Test a style solution Existing blocks may need an approved style rather than new behaviour. Check theme compatibility, global controls, responsive output, and editor parity. ## Test the installed specialist blocks Configure currently available products against the exact acceptance criteria. An overlooked feature can remove a perceived gap without adding code. ## Record full, partial, failed, and unknown Full means every required criterion passes with suitable evidence. Partial means named criteria fail. Unknown means testing remains incomplete. ## Capture the workaround Describe manual steps, custom code, copied markup, external tools, or changed requirements. Measure time, errors, accessibility, consistency, ownership, and future maintenance. ## Distinguish a gap from inconvenience A slower workflow can still meet every accepted outcome. Record inconvenience separately and measure its frequency and cost. ## Distinguish a gap from training need Editors may miss existing controls, patterns, transforms, or approved workflows. Test concise guidance before procuring equivalent capability. ## Distinguish a gap from governance failure Available blocks can produce inconsistent results when ownership and rules remain unclear. New blocks can increase that inconsistency without solving [governance](https://wpblocksuite.com/blog/block-editor-governance-teams-agencies/). ## Distinguish a gap from a defect A supported capability can fail because of configuration, compatibility, or implementation defects. Fixing the defect may remain safer than replacing the block. ## Measure frequency Count how often editors encounter the requirement during a representative period. Separate routine content, seasonal campaigns, migrations, and rare exceptions. ## Measure audience reach Estimate which visitors, members, customers, editors, or administrators experience the gap. Use relevant analytics and workflow evidence rather than assumed reach. ## Measure consequence Record lost understanding, task failure, accessibility barriers, delays, errors, or governance risk. A rare high-consequence gap can outrank frequent cosmetic inconvenience. ## Measure workaround cost Multiply measured time per occurrence by representative occurrence volume. Add review, correction, support, training, and future migration work. ## Measure quality loss Score important acceptance failures without converting unsupported guesses into money. Keep qualitative consequences visible beside cost estimates. ## Test accessibility explicitly Use keyboard, focus, structure, labels, errors, zoom, and assistive-technology checks. Test the configured editor and frontend result with representative content. ## Test responsive behaviour explicitly Inspect content across relevant widths, orientations, zoom levels, and long translations. Editor preview alone is insufficient evidence for frontend behaviour. ## Test performance explicitly Measure assets, requests, rendering, layout movement, queries, jobs, and editor responsiveness. Compare equivalent configured content under the same environment. ## Test content portability Disable candidate blocks [on staging](https://wpblocksuite.com/blog/test-wordpress-plugin-on-staging/) and inspect saved content and frontend output. Record transformations, fallbacks, exports, cleanup, and recovery requirements. ## Test editor permissions Use the real roles responsible for creation, review, publishing, and administration. An administrator-only workaround cannot satisfy every editor workflow. ## Test locking and controlled editing WordPress can restrict moving, removing, or editing blocks in supported contexts. Use controls carefully. Editors still need sufficient authority for their tasks. ## Create the gap matrix - Outcome and audience. - Frequency and consequence. - Acceptance criteria. - Core-block result. - Pattern or style result. - Installed-plugin result. - Current workaround. - Evidence and confidence. - Owner and priority. Keep test links and screenshots beside the matrix where appropriate. ## Prioritise confirmed gaps Rank consequence, frequency, reach, workaround cost, urgency, and strategic importance. Use consistent scales and define every rating. ## Add confidence to priority High-priority weak evidence should trigger testing, not immediate purchase. Show confirmed, likely, uncertain, contradicted, and outdated findings separately. ## Group related gaps Several content jobs can depend on one underlying capability. Grouping prevents buying several overlapping solutions for the same root need. ## Write a capability brief Convert each approved gap into required, preferred, prohibited, and testable criteria. Include content formats, roles, integrations, accessibility, performance, data, and exit. ## Test candidates against the same content Use identical examples, roles, environment, settings, and acceptance criteria. Consistent trials make capability evidence comparable. ## Reject catalogue inflation Do not count every included block as value. Count only proven capability addressing current or credible planned outcomes. ## Plan adoption Name configuration, pattern, documentation, training, migration, and support owners. A purchased capability remains a gap when nobody can adopt it. ## Plan removal before installation Understand saved markup, data, exports, content transformation, and licence effects. Record a practical staging test for future exit. ## Review after deployment Confirm adoption, output quality, editor effort, incidents, performance, and original outcomes. Close the gap only when evidence meets acceptance. ## Maintain a gap register Record open, testing, accepted, deferred, solved, and retired requirements. Review after major content, theme, editor, plugin, or team changes. ## Audit block discovery An available block provides little value when editors cannot find it reliably. Test inserter titles, keywords, categories, previews, descriptions, and team terminology. ## Audit transformation paths Transforms can move existing content between compatible block types. Test content preservation, settings, semantics, undo, and editor understanding. ## Audit copy and paste Editors often introduce content from documents, spreadsheets, or older pages. Test structure, formatting, links, lists, tables, images, and cleanup effort. ## Audit localisation workflows Translated text can expand, change direction, or require different media. Test required languages, translation tools, synced content, and responsive layouts. ## Audit print and alternate presentation Some content must remain usable when printed, exported, syndicated, or emailed. Interactive disclosure and decorative layouts can fail outside the primary page. ## Audit search visibility Important content should remain present in appropriate rendered markup. Test headings, links, structured relationships, indexing controls, and hidden states. ## Audit analytics needs Define which interactions need measurement and why those events support decisions. Separate content capability from consent, tracking, storage, and reporting systems. ## Audit moderation needs User submissions, comments, reviews, and community content require operational controls. Include approval, abuse handling, notifications, retention, export, and deletion. ## Audit dynamic-data needs Some blocks need current records rather than manually copied values. Test data sources, field mapping, empty states, caching, permissions, and failure. ## Audit design-token needs Editors may need approved spacing, colour, typography, borders, and layout choices. Prefer governed controls over unrestricted one-off styling when consistency matters. ## Audit content ownership Name who creates, reviews, publishes, measures, updates, and retires each content type. Unowned content can fail despite complete block capability. ## Audit change frequency Frequently changed layouts need safer controls and clearer editorial feedback. Stable templates may justify stronger locking and narrower editing surfaces. ## Audit support readiness Record documentation, escalation paths, known limitations, troubleshooting, and recovery. A capable block can still create an unsupported operating gap. ## Audit update resilience Use staging to test representative content after theme, plugin, and WordPress updates. The answer is in [what “Unexpected or invalid content” means](https://wpblocksuite.com/blog/unexpected-invalid-content-wordpress/). Keep recovery steps proportionate to the affected content consequence. ## Audit planned content Credible campaigns and product changes can reveal near-term capability requirements. Name the owner, date, acceptance, and funding before counting planned demand. ## Audit retirement needs Content systems need deletion, archiving, replacement, redirection, and evidence-preservation workflows. Test those final lifecycle stages before approving a new capability. ## Share the audit result Give editors a short capability map and owners a prioritised decision register. Remove outdated guidance after accepted tools, patterns, and requirements change. ## Know the honest weak case Frequency alone is a weak priority measure. Rare accessibility or transaction failures can dominate. Use evidence and consequence, not merely editor requests or feature counts. ## Use the block-category gap audit checklist 1. Define sites and content contexts. 2. List recurring visitor outcomes. 3. List recurring editor outcomes. 4. Define acceptance criteria. 5. Inventory core and installed blocks. 6. Inventory patterns and theme facilities. 7. Test core blocks first. 8. Test composition, patterns, and styles. 9. Test installed specialist capabilities. 10. Record full, partial, failed, and unknown. 11. Capture current workarounds. 12. Separate gaps from training needs. 13. Test accessibility and responsive behaviour. 14. Measure configured performance. 15. Test roles and governance. 16. Test content portability. 17. Measure frequency, reach, and consequence. 18. Prioritise with evidence confidence. 19. Write a capability brief. 20. Review outcomes after deployment. ## Frequently asked questions What is a WordPress block-category gap? It is a required content outcome the current block system cannot acceptably deliver. Should I audit block categories or individual blocks? Audit outcomes first, then test relevant blocks, patterns, styles, themes, and workflows. Can a block pattern solve a capability gap? Yes. Patterns can solve repeatable composition without introducing another block type. How should block gaps be prioritised? Use consequence, frequency, reach, workaround cost, urgency, importance, and evidence confidence. Does a missing block justify another plugin? Not automatically. Test composition, patterns, styles, existing tools, and adoption costs first. ## The verdict Verdict **A block gap is a failed content outcome, not an empty catalogue category.** Test core blocks, patterns, installed tools, governance, and evidence before adding capability. Buy only against an accepted capability brief and a documented adoption plan. [Review WP Block Suite’s $299 lifetime licence](https://wpblocksuite.com/#pricing).