Quick Answer
A WordPress Interactivity API audit checklist should identify every front-end block or theme region that depends on Interactivity API behavior, confirm that the block declares the right support and script module metadata, map directives to the store they use, define server-rendered fallbacks, and check whether client-side navigation can replace the region without breaking state, styles, or event handling. The best fit for a small publisher is a focused register for interactive search, navigation, query, file, lightbox, menu, filter, accordion, and custom block behavior.
Interactivity Risk Map
| Review area | What to verify | Better operator decision |
|---|---|---|
| Interactive surface | Which block, template part, plugin, or theme region owns the behavior | Assign an owner before editing markup or scripts |
| Support metadata | supports.interactivity, viewScriptModule, and client-navigation support | Treat metadata as part of the release checklist |
| Directive scope | Where data-wp-interactive, context, actions, callbacks, and attributes appear | Audit the rendered HTML and the source block together |
| Store ownership | Which namespace holds state, actions, callbacks, config, or derived values | Keep store changes near the block or plugin owner |
| Server fallback | Whether initial HTML is useful before hydration or script execution | Keep important content visible without relying on a click |
| Navigation compatibility | Whether router regions and script modules survive client-side navigation | Declare compatibility only when the region has been reviewed |
Who Should Use This Checklist?
Use this checklist when a WordPress publisher, block-theme operator, developer-adjacent editor, or plugin maintainer depends on interactive front-end behavior inside blocks. It fits interactive search, query filters, navigation menus, file blocks, image lightboxes, disclosure panels, content filters, live previews, cart-like widgets, and custom blocks that update state after a reader action.
This is WordPress site-operations guidance, not legal, financial, medical, professional security, accessibility-certification, ranking, or AdSense revenue advice. It does not change WordPress plugins, themes, templates, Search Console, Bing Webmaster Tools, Google AdSense, DNS, hosting, payment settings, or production content. The article uses public WordPress documentation and release notes as evidence. No private WordPress dashboard, plugin repository, admin account, staging site, production URL, server log, analytics property, Search Console account, Bing account, or Google AdSense account was inspected for this article.
The operating problem is simple: interactive blocks can look like ordinary front-end markup while their behavior depends on script modules, directives, stores, router regions, and server-rendered state. If the team only reviews the visual result, a plugin update, theme cleanup, cache change, or client-side navigation setting can quietly remove behavior that readers rely on.
Step 1: Inventory Interactive Surfaces
Start with the public pages and templates where behavior changes after a click, search, scroll, toggle, or navigation action. The official Interactivity API reference names Core blocks such as Search, Query, Navigation, and File as examples of WordPress blocks using the API. That makes the first audit broader than custom code. It should include Core blocks, plugin blocks, theme regions, and custom block directories.
Use this first-pass checklist:
- [ ] List every block, template part, pattern, and theme region with front-end behavior.
- [ ] Record whether the behavior comes from Core WordPress, a plugin, a theme, or custom code.
- [ ] Mark the public page types affected: home, archive, single post, category, search, landing page, or utility page.
- [ ] Record the reader action that triggers the behavior, such as click, search, toggle, filter, navigation, or form input.
- [ ] Note whether the behavior affects content visibility, navigation, layout, analytics events, or a submission flow.
- [ ] Keep private URLs, unpublished page names, account IDs, keys, and internal dashboard screenshots out of public notes.
The better choice is to audit by reader impact, not by code novelty. A simple accordion that hides source notes can be more important than a complex widget that appears only on a test page. Start with behavior that changes what readers can see, follow, or submit.
Step 2: Confirm WordPress Version And Block Metadata
The Interactivity API is included in WordPress Core from version 6.5, and the package documentation notes that @wordpress/interactivity is bundled in Core for WordPress versions higher than 6.5. The operator checklist should still record the site's release baseline because plugins, Gutenberg plugin usage, and build tooling can change how a block is shipped.
Use this metadata table:
| Metadata item | What to check | Why it matters |
|---|---|---|
| WordPress baseline | Core version and whether the Gutenberg plugin is part of the workflow | Determines which Interactivity API features are available |
| Block support | Whether the block declares Interactivity API support in block.json | Makes support visible to maintainers |
| Script module | Whether front-end code loads through viewScriptModule | Keeps the block aligned with WordPress script module loading |
| Build path | Whether the project builds module output correctly | Prevents a deploy that ships stale or missing behavior |
| Owner | Core, plugin, theme, mu-plugin, or custom block directory | Tells the operator where rollback belongs |
Do not reduce this step to "JavaScript exists." The API has a WordPress-specific path: block metadata, script modules, directives, and a store. A block that uses jQuery, a one-off inline script, or a regular script may still be functional, but it should not be treated as Interactivity API coverage without evidence.
Step 3: Map Directives To Their Store
The official Directives and Store guide describes directives as the mechanism that manages interaction behavior, including state, side effects, event handlers, attributes, and content. The data-wp-interactive directive activates an interactive area and names the store namespace. For an operator, that namespace is the bridge between rendered HTML and the logic that changes it.
Use this directive register:
| Directive layer | Operator question | Review note |
|---|---|---|
data-wp-interactive | Which namespace owns this region? | Record the namespace and code owner |
| Context | What local state is attached to this element? | Avoid exposing private or unstable values in public markup |
| Actions | Which reader actions can change state? | Review click, submit, filter, and navigation behavior |
| Callbacks | Which effects run after state changes? | Check whether side effects are safe and reversible |
| Attributes and styles | Which visible values are updated by directives? | Confirm layout and content remain understandable |
| Nested regions | Do child blocks depend on a parent store? | Review parent and child changes together |
The better decision is to keep the register small but exact. A public article does not need a full code audit, but the site owner needs enough detail to answer: which namespace owns this behavior, which user action changes it, and what breaks if the store is removed or renamed?
Step 4: Separate Server-Rendered Content From Hydrated Behavior
The Interactivity API core concepts documentation points operators toward server-side rendering and state-aware HTML. That matters for publishers because readers, crawlers, caches, and link previews all encounter the initial HTML before any client-side behavior completes.
Use this fallback checklist:
- [ ] The initial HTML contains the essential content, label, or destination.
- [ ] A button or link still communicates its purpose before JavaScript runs.
- [ ] Hidden content is not the only place where the article's answer, source note, or disclosure appears.
- [ ] Empty states and loading states have useful copy.
- [ ] Cache behavior does not serve another page's state or context.
- [ ] The fallback path is documented for high-value pages and templates.
This is not a claim that every interactive feature must work without JavaScript. It is a publishing-quality rule: important content should not disappear behind behavior that only one script path can initialize. A filter can enhance a source table, but the core source notes should remain reachable.
Step 5: Review Client-Side Navigation Compatibility
WordPress developer documentation describes client-side navigation as a way to update only the page regions that change instead of loading a full new document. It also warns that compatibility has to be evaluated because interactive regions can lose state, fail to initialize, or render incorrectly after navigation.
Use this compatibility table:
| Navigation question | Better answer before approval |
|---|---|
| Does the page use router regions? | Record which regions are updated and which remain in place |
| Does the block declare client-navigation support? | Declare support only after behavior is reviewed |
| Does the block use regular scripts, jQuery, or runtime-injected CSS? | Treat it as incompatible unless rewritten or isolated |
| Are script modules marked so they load during navigation? | Verify the module path and navigation loading flag |
| Does state need to persist across pages? | Define which state is allowed to persist and which should reset |
| Is full-page client-side navigation involved? | Treat it as higher-risk because every interactive element must be compatible |
The better choice for most content sites is conservative adoption. Region-based navigation can improve transitions, but it should not outrank reliability. If a related-post block, filter widget, or navigation module only initializes on the first page load, it should not be declared compatible just because it looked fine during one direct visit.
Step 6: Pair Interactivity With Performance And Content Quality
Interactive behavior can help readers, but it can also hide content, delay useful answers, add layout shifts, or create unclear navigation. Pair this checklist with a Core Web Vitals review when the interaction changes loading, input response, or layout stability. Pair it with a template-part audit when the behavior appears in headers, footers, sidebars, or repeated article modules.
Use this operator decision matrix:
| If the interaction does this | Review it with |
|---|---|
| Opens or closes repeated content | Source-note and visibility review |
| Changes search, query, or filter results | Empty-state and crawlable-link review |
| Alters header, menu, or template-part behavior | Navigation and template-part review |
| Adds script modules to many pages | Core Web Vitals and cache review |
| Persists state across navigation | Privacy, reset, and client-navigation review |
| Comes from a plugin update | Plugin update and rollback review |
The best fit is not "more interactivity." The best fit is the smallest behavior that helps the reader complete the job while staying maintainable for the operator.
Step 7: Keep A Release And Rollback Note
Interactivity API behavior often crosses boundaries: PHP render files, block.json, module JavaScript, store names, styles, cache rules, and template placement. A release note should name the pieces that changed and how to back out safely.
Use this release note format:
- [ ] Feature or block name.
- [ ] Public surfaces affected.
- [ ] WordPress, Gutenberg, plugin, and theme baseline.
- [ ] Store namespace and directive area.
- [ ] Script module path and build command owner.
- [ ] Client-side navigation decision.
- [ ] Fallback behavior.
- [ ] Rollback path.
- [ ] Next review date.
For a small publisher, that note can be a short runbook entry. It does not need to expose private implementation details in a public article, but the internal operator should know whether rollback means disabling a plugin, reverting a theme file, removing a block, or restoring a previous build artifact.
What Should A WordPress Interactivity API Audit Include?
A complete WordPress Interactivity API audit includes an inventory of interactive blocks and theme regions, the WordPress and Gutenberg baseline, block metadata, script module loading, directive and store mapping, server-rendered fallbacks, client-side navigation compatibility, performance review, and a release or rollback note.
FAQ
Is the WordPress Interactivity API only for custom block developers?
No. Developers write the code, but operators still need to know which public blocks depend on the API. Core blocks, plugin blocks, and custom blocks can all create behavior that affects readers.
Should every interactive WordPress block use the Interactivity API?
Not automatically. Existing JavaScript can still work, but it should be documented honestly. If a block uses jQuery, regular scripts, or a separate library, do not label it Interactivity API-compatible without a code-level reason.
Does client-side navigation mean the site is a single-page app?
No. WordPress client-side navigation can still rely on server-rendered HTML. The audit question is narrower: which regions are replaced, which scripts load, and whether interactive state remains correct after navigation.
How often should this checklist be reviewed?
Review it every 60 days, and sooner after a WordPress release, Gutenberg plugin update, block plugin update, theme change, cache change, build tooling change, or any reader report that an interactive element stopped working.
AdSense And Policy Fit
This checklist supports AdSense-safe publishing because it improves content reliability, navigation clarity, and source-note visibility without changing ad settings, encouraging artificial clicks, hiding disclosures, creating manufactured traffic, or making unsupported ranking claims. Interactive behavior should help readers inspect and use the page; it should not be used to force engagement.
Source Notes
- https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/ checked 2026-06-13; used for source-derived analysis of Interactivity API purpose, WordPress 6.5 inclusion, Core block examples, support metadata, and
viewScriptModuleguidance. - https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/iapi-about/ checked 2026-06-13; used for source-derived analysis of the API goals, directives, declarative front-end behavior, and maintainability rationale.
- https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/directives-and-store/ checked 2026-06-13; used for source-derived analysis of
data-wp-interactive, context, directives, state, actions, callbacks, attributes, and content updates. - https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/core-concepts/ checked 2026-06-13; used for source-derived analysis of state, local context, server-side rendering, TypeScript, and client-side navigation concepts.
- https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/core-concepts/client-side-navigation/ checked 2026-06-13; used for source-derived analysis of router regions, region-based navigation, full-page navigation, script-module loading, and server-rendered HTML.
- https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/core-concepts/client-side-navigation-compatibility/ checked 2026-06-13; used for source-derived analysis of compatibility declarations, regular-script risks, dynamic CSS risks, and client-navigation support.
- https://developer.wordpress.org/block-editor/reference-guides/packages/packages-interactivity/ checked 2026-06-13; used for source-derived analysis of the
@wordpress/interactivitypackage and WordPress Core bundling. - https://make.wordpress.org/core/2024/03/15/wordpress-6-5-field-guide/ checked 2026-06-13; used for source-derived analysis of the WordPress 6.5 developer feature context, script module field, editor changes, and release-note review triggers.
Internal Links
Link to wordpress-block-hooks-audit-checklist when plugin or theme blocks appear automatically around interactive regions. Link to wordpress-block-bindings-audit-checklist when a visible interactive value comes from metadata or a custom source. Link to wordpress-command-palette-audit-checklist when the workflow is edited through admin shortcuts. Link to wordpress-data-views-audit-checklist when filters, lists, or bulk-action surfaces are involved. Link to wordpress-template-part-audit-checklist when the behavior appears in headers, footers, sidebars, or repeated layout regions. Link to core-web-vitals-for-blogs when script modules, hydration, or layout changes can affect performance.
Update Log
Update note: review this checklist every 60 days. Recheck official WordPress Interactivity API reference pages, Directives and Store guidance, Core Concepts, Client-Side Navigation, Client-Side Navigation Compatibility, @wordpress/interactivity package documentation, and WordPress release notes. Refresh earlier after a major WordPress or Gutenberg update, client-side navigation change, script-module tooling change, plugin update, theme deploy, cache incident, or reader report that an interactive block no longer behaves as expected.