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, and supported controls.

A theme change can alter available design tools without changing block plugins.

Inventory reusable content

Find synced patterns, 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.

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.

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 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.

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

The verdict

Buy only against an accepted capability brief and a documented adoption plan. Review WP Block Suite’s $299 lifetime licence.