Each plugin below is listed honestly — with a coded compatibility profile where one exists, and plainly marked as not yet verified where one doesn't.
This list covers what's specifically been checked in code so far — it isn't the limit of what works. Static Shield operates on ordinary rendered HTML, so most other well-behaved themes and plugins are likely to work fine even without a dedicated profile of their own yet.
Elementor's frontend output is treated as static with high confidence — the page builder renders regular HTML/CSS, and Static Shield serves that output directly. The editor itself (only reachable to logged-in admins) is treated as private, not part of the public surface.
Divi's frontend output — both its classic shortcode engine and its newer block engine — renders complete HTML server-side with no client-side hydration, so page content is served static with high confidence. Three optional modules talk back to the server and are bridged individually: the Contact Form module, the Signup/Email Optin module, and (only when enabled) a WooCommerce cart-count badge in the Menu module. The Visual Builder itself stays admin-only and was never part of the public surface.
Bricks is normally distributed as a theme with its own React-based visual canvas bundled in, the same shape as Divi and Avada — but that canvas is an editor-only surface in wp-admin, not something visitors ever load. On the public frontend, Bricks compiles builder data down to plain server-rendered HTML, so page content is served static.
WPBakery's shortcode-based frontend output is treated as static; both the wp-admin editor and the front-end inline editor require a logged-in, capability-checked user, so neither was ever part of the public route surface.
Beaver Builder's rendered layouts are treated as static, including their per-post cached CSS/JS. The front-end builder UI only activates for a logged-in user with edit rights on that specific post, so it was never public.
Divi's frontend output — both its classic shortcode engine and its newer block engine — renders complete HTML server-side with no client-side hydration, so page content is served static with high confidence. Three optional modules talk back to the server and are bridged individually: the Contact Form module, the Signup/Email Optin module, and (only when enabled) a WooCommerce cart-count badge in the Menu module. The Visual Builder itself stays admin-only and was never part of the public surface.
Avada (ThemeFusion) bundles its own page builder — Fusion Builder — directly in the theme rather than shipping it as a separate plugin, so theme and builder compatibility are covered together here, the same as Divi. Its shortcode-based page rendering and per-page Dynamic CSS output are both server-rendered with no client hydration, so pages are served static with high confidence. Three optional features bridge back to the server: the Form Builder element (with file uploads), the Search element's live-search mode when enabled, and WooCommerce's own cart-fragments mechanism when Avada is paired with WooCommerce.
Enfold (Kriesi) bundles its own Avia Layout Builder directly in the theme, the same shape as Divi, Avada, and Bricks — but unlike those three, this profile stays intentionally shallow: Avia Builder's shortcode output is a classic server-rendered architecture with no independently documented dynamic frontend surface of its own beyond its admin-only editor. Page content renders static with nothing else to bridge.
Flatsome (UX Themes) is a WooCommerce-focused theme built on its own bundled UX Builder/UX Blocks — deserving the same theme-plus-builder treatment as Divi and Avada, since nearly every hybrid feature here (live search, Quick View, filters) is Flatsome's own code layered on top of WooCommerce, not a separately installed plugin. Page rendering, product grids, and variation/checkout flows all render server-side and are served static; live search and Quick View both fetch content via admin-ajax.php and need bridging.
WordPress's own bundled default themes get one shared compatibility profile rather than six near-identical ones, since they behave the same way: WordPress-core-team maintained, template-only, with no theme-specific AJAX, REST route, or form of their own. Twenty Twenty-One is a hybrid classic/block theme; Twenty Twenty-Two onward are pure block themes (theme.json plus block templates) — both shapes render fully server-side with no client-side hydration.
Impreza ships no page builder of its own — a full sweep of the theme found no visitor-facing AJAX, REST routes, cookies, or logged-in branching anywhere outside its admin-only setup wizard. Page content normally comes from the separately installed WPBakery Page Builder plugin, which Impreza recommends but doesn't bundle — see the WPBakery integration for that part of the picture.
JupiterX (by Artbees) is a full rewrite of the older "Jupiter" theme, and has no page-building engine of its own — it's built as an Elementor extension, requiring the real, separate Elementor plugin. What's specific to JupiterX on top of Elementor's own compatibility: a mega menu that renders statically, three confirmed pagination/lazy-load AJAX bridges, and a site-wide maintenance-mode toggle worth knowing about.
Astra ships no page builder of its own — like Impreza, it's a lightweight base theme normally paired with Elementor, Beaver Builder, WPBakery, or plain Gutenberg, each already covered by its own adapter. Astra's own footprint is template chrome (navigation, sticky header, search overlay, 404 page, Customizer CSS) that renders as plain static HTML, plus a WooCommerce mini-cart flyout that needs a live cart-fragments bridge. Two further AJAX extras — live search and infinite scroll — exist only when the separate paid Astra Pro addon is active.
Blocksy ships no page builder of its own — normally paired with Elementor or plain Gutenberg, each already covered by its own adapter. Blocksy's own footprint is template chrome and the header builder's mobile/off-canvas menu, both plain static HTML, plus a WooCommerce mini-cart flyout in the header builder that needs a live cart-fragments bridge.
GeneratePress ships no page builder of its own — deliberately one of the lightest WordPress themes available, normally paired with GenerateBlocks, Elementor, or plain Gutenberg, each already covered by its own adapter. A full sweep of the theme's own code found no AJAX search, live filter, or builder-in-theme feature comparable to Astra Pro or OceanWP's paid extensions — just template chrome and a client-side mobile-menu toggle, both plain static HTML.
OceanWP ships no page builder of its own — normally paired with Elementor or plain Gutenberg, each already covered by its own adapter. Its own footprint is template chrome (navigation, sticky header) that renders as plain static HTML. The only hybrid surface is OceanWP's own named, optional paid extension, "Ajax Search," which resolves results via admin-ajax rather than a full page load when it's active.
Kadence ships no page-building layer of its own — the visual builder, Kadence Blocks, is a separately installed plugin (Gutenberg-based) that would carry its own adapter, as would the premium Kadence Pro and Kadence Blocks Pro addons. Kadence's own theme layer adds a sticky header and a WooCommerce header cart icon on top of core WordPress/WooCommerce behavior.
Form display is served static; form submission goes through one narrow, rate-limited bridge route rather than requiring the whole page — or site — to stay dynamic.
Form display is served static; submission is bridged through admin-ajax.php, the same mechanism WPForms itself uses for submissions.
Form display is served static; submission is bridged through admin-ajax.php. Gravity Forms is commercial-only with no free tier to test against, so this adapter's confidence is deliberately capped lower than the other form plugins.
Form display is served static; submission is bridged through admin-ajax.php (action=fluentform_submit), confirmed registered for both logged-in and anonymous visitors.
Form display is served static; the subscribe submission is bridged through admin-ajax.php (action=mc4wp_subscribe), this plugin's longest-standing submission pattern. Unlike Contact Form 7 or WPForms, this bridge hasn't been confirmed against a live install — it's a documented best-effort pattern, not a verified one, since the actual endpoint has shifted across major versions and installation modes.
Mollie confirms a payment by calling back to your site after the fact — sometimes well after the customer has closed the tab, especially for delayed methods like bank transfers common across the EU. That callback is bridged, never served from the static cache, so an order can't silently stay "pending" while Mollie already knows it was paid.
Unlike the other payment integrations here, Stripe's webhook still uses WooCommerce's classic "?wc-api=wc_stripe" query-string convention rather than a modern REST route — and that query string lands on your site's root URL, the same path your homepage is served from. We're flagging this honestly as a known open risk rather than a solved one: see Limitations below before putting a live Stripe-powered store behind a static release.
WooPayments works a little differently from a typical gateway: Stripe never calls your site directly — Automattic's WooPayments server receives events centrally and relays the relevant ones to your site over your Jetpack connection, authenticated as a real logged-in WooCommerce manager rather than a plain public webhook.
PayPal confirms a payment by calling back to your site after the fact, verified through a server-to-server check against PayPal's own API. That callback is bridged, never served from the static cache, so a payment, dispute, or refund can't go unnoticed.
Yoast's meta tags, Open Graph, and schema.org output are baked into every page as static content. Its XML sitemap is not yet included in the static crawl route manifest, so it still falls through to WordPress live.
Rank Math's meta tags, Open Graph, and schema.org output are baked into every page as static content, the same treatment as Yoast SEO. Its XML sitemap currently falls through to WordPress live.
All in One SEO's meta tags, Open Graph tags, and schema.org output are baked into the page head at render time, the same shape as Yoast SEO and Rank Math — captured as-is in the static build, along with its virtual robots.txt output. Its XML sitemap is tracked as a refreshable fragment rather than assumed permanently static. The one feature that pulls this toward Hybrid is its optional Redirects addon, which isn't part of AIOSEO's core SEO output and not every site enables it.
Wordfence's actual protection — its Web Application Firewall and brute-force login rate limiting — only inspects requests as WordPress/PHP processes them; neither can see or act on a request that never reaches PHP. Every feature that could count toward a classification lands as dynamic, so this is realistically closer to a plugin whose real value depends on WordPress staying in the loop than a typical Hybrid mix. Its login security (2FA), malware scanning, and live traffic log are all logged-in, wp-admin-only tooling, unaffected by serving mode.
Really Simple Security's HTTPS enforcement and security headers are fixed, request-independent values that map directly onto static host or CDN edge configuration — no live check needed. Login-attempt rate limiting, where the installed tier includes it, stays dynamic since it can only see attempts that actually reach wp-login.php. Its hidden/renamed login URL, forced 2FA, and vulnerability scanning are all admin-side, private concerns unaffected by serving mode.
WPS Hide Login does exactly one thing: it rewrites which URL reaches wp-login.php and blocks the real one. A public visitor never requests wp-login.php or wp-admin during ordinary browsing on a static site, so this has no effect on static build output at all. Worth knowing up front, though: this targets the exact same thing Static Shield's own built-in Admin Access Gateway already controls, and running both at once is a real, documented source of lockouts — not just redundancy.
Asset CleanUp lets an admin selectively stop specific CSS/JS files from loading on specific pages, plus basic minify and combine — all decided at render time. Whichever assets are actually left enabled for a given page is exactly what Static Shield's crawler captures as that page's final static output, the same as any other page. It has no page cache of its own, so there's no second caching layer to worry about.
Autoptimize aggregates, minifies, and optionally defers CSS and JS — all of it via output buffering at render time. Unlike WP Rocket, LiteSpeed Cache, or WP Super Cache, it has no page cache of its own, so there's no second caching layer running alongside Static Shield's build. Its optional "Optimize Images" setting (off by default) works differently: confirmed by reading the plugin's own source, it rewrites image URLs to ShortPixel's hosted optimization service rather than optimizing locally — still static-friendly, but a real external dependency rather than a one-time local build step (see limitations).
This covers the official Cloudflare WordPress plugin specifically, detected independently from Cloudflare the service sitting in front of an origin as a reverse proxy — a separate, already-handled concern (Static Shield's Admin Gateway already accounts for a trusted reverse proxy rewriting the visible client IP). The plugin's only real feature is an automatic cache-purge webhook that calls the Cloudflare API when content changes, plus a settings screen for security-level and page-rule toggles — neither affects what a visitor's request actually receives once a build is published.
FlyingPress is a premium, all-in-one performance plugin — page cache, asset optimization, image optimization and lazy-load, font optimization, and CDN — with no free wp.org distribution, so (like WP Rocket) this profile hasn't been behaviorally validated against a live install. Its asset/image optimization and CDN features are expected to behave the same as every other optimization plugin covered here; its own page cache is the one piece worth reviewing, since it runs as a second, independent caching layer alongside Static Shield's own static output.
Object Cache Pro is the premium counterpart to the free Redis Object Cache plugin, from the same author — a drop-in that backs WordPress's own internal object cache (transients, query caching) with Redis instead of per-request PHP memory, plus a paid support/feature tier (Relay support, cluster/replication config, analytics). This is a different layer from page caching entirely: it speeds up WordPress itself while WordPress is running — admin screens, a Static Shield build's own crawl — with zero effect on, or public-facing execution surface in, a static build's output.
Perfmatters is a premium optimization toolkit — script manager, deferred/delayed JS, unused CSS removal, lazy load, disabled emojis/embeds, local Google Fonts hosting — with no page cache of its own, unlike WP Rocket, WP Super Cache, or LiteSpeed Cache. Because it's commercial-only with no free tier to test against, this profile hasn't been behaviorally validated, but its feature set is the same shape as every other asset-optimization plugin covered here.
Redis Object Cache drops in wp-content/object-cache.php to back WordPress's own internal object cache — transients, query caching — with Redis instead of per-request PHP memory. It has zero public execution surface and zero effect on a static build's output: it only ever speeds up WordPress itself while WordPress is running (admin screens, the crawler's own render pass during a build), never something a visitor's request depends on once a page is served statically.
WP Super Cache, from Automattic, is one of the oldest WordPress caching plugins — its own page cache runs as a second, independent caching layer alongside Static Shield's static output, the same shape as WP Rocket or LiteSpeed Cache. Its "Expert" mode goes further, writing its own mod_rewrite rules to serve cached HTML files directly from disk, bypassing PHP almost entirely — functionally the same technique Static Shield itself uses, which makes it a direct rule-ordering conflict rather than just a freshness risk. Its CDN URL rewriting is compatible and fine to leave on.
This is the LiteSpeed Cache WordPress plugin, detected completely independently from the LiteSpeed webserver. Its asset minification, image optimization, and CDN integration are all static-friendly. Its own page cache and object cache have no public-facing effect, but running them alongside Static Shield's static output is worth understanding.
WP Rocket is premium-only with no free wp.org distribution, so this profile's confidence is deliberately capped lower than LiteSpeed Cache's. Its page cache, preload/cache-warming, and asset optimization are all expected to behave similarly, but haven't been behaviorally validated.
W3 Total Cache adds no visitor-facing WordPress dependency of its own — its CSS/JS minification and CDN URL rewriting both produce plain output a static build captures as-is, the same treatment as LiteSpeed Cache and WP Rocket. Its own page cache and object/database cache have no public-facing effect either, but running its page cache alongside Static Shield's static output is worth understanding.
WP-Optimize combines page caching, database cleanup, and image compression in one plugin. Database cleanup — removing post revisions, transients, spam comments, and orphaned table data — is purely backend housekeeping with zero public-facing effect, fully resolved rather than a caveat. Image compression produces plain, smaller static image files by the time a page is rendered. Its own page cache carries the same conflict shape as LiteSpeed Cache, WP Rocket, and W3 Total Cache.
WP Fastest Cache is free on wp.org, unlike WP Rocket, but adds no visitor-facing WordPress dependency of its own either way — its CSS/JS minify-and-combine output and, when a CDN endpoint is configured, its CDN URL rewriting both produce plain markup a static build captures as-is. Its own page cache carries the same conflict shape already established for LiteSpeed Cache, WP Rocket, and W3 Total Cache.
Smush's compressed image files are just static assets by the time a crawl captures them, and its optional CDN add-on rewrites image URLs the same way — both served static with high confidence. WebP/AVIF delivery is the exception: Smush typically decides whether to serve the modern format using a server-level rewrite rule or a PHP-side check of the browser's Accept header, a per-request decision a plain static host doesn't make on its own.
Imagify always compresses through its own cloud API rather than locally, but the result is just a static image file by the time a crawl captures it — served static either way. CDN delivery, when enabled, rewrites image URLs the same way. WebP/AVIF delivery is the exception: it commonly relies on a server-level rewrite or a PHP-side Accept-header check that a plain static host doesn't perform on its own.
EWWW can compress images locally, using bundled or system-level tools, or through its optional cloud API — either way the output is just a static image file by the time a crawl captures it, so which mode is configured doesn't change how this is served. Its own Easy IO CDN, when enabled, rewrites image URLs the same way. WebP/AVIF delivery is the exception: it commonly relies on a server-level rewrite or a PHP-side Accept-header check that a plain static host doesn't perform on its own.
Each translation is its own WordPress post with its own URL, so translated content and the language switcher are both served static. If more than one language is configured and automatic browser-language detection is enabled, that first-visit redirect decision needs to stay dynamic.
WPML is commercial-only with no free tier to test against, so this profile's confidence is deliberately capped throughout. Translated content is expected to mirror a per-language-URL pattern; language negotiation is treated as dynamic by default rather than assumed static.
Complianz's consent banner and script-blocking markup are served static; blocked third-party embeds show a static placeholder until consent is given, then swap in client-side. The frontend JS calls one specific bridge route for cookie/category metadata.
CookieYes's consent mechanism follows the same well-documented shape as Complianz: category/consent state lives in a browser cookie, and third-party scripts are blocked by swapping their type attribute (rather than removing them from the markup) until the visitor consents. Unlike Complianz, CookieYes declares no REST route or server-side bridge at all — the static build only has to preserve that markup exactly, with zero WordPress involvement on a per-visitor basis, which is what keeps it in Fully Static rather than Complianz's Hybrid.
Popup Maker is about as simple and low-risk as integrations get. Its show/hide rules, frequency capping, and targeting logic run entirely as client-side JavaScript driven by cookies and localStorage in the visitor's own browser, so that logic keeps working unchanged once it's captured in a static build — no WordPress round trip involved for any visitor, ever. Open and conversion tracking work the same way, firing straight from the browser.
OptinMonster is a SaaS lead-generation tool that runs almost entirely outside WordPress. In its standard, most common embed configuration, a script tag loads OptinMonster's own hosted JS, which renders the campaign and posts lead-capture submissions straight to OptinMonster's own API from the visitor's browser — WordPress is never in the request path for either step. That standalone-embed configuration is what this profile assumes and classifies as static.
ACF field values are read by your theme and rendered as ordinary page content — static by default. The field group editor is a logged-in, admin-only screen with no public-facing surface of its own.
Individual event, venue, and organizer pages are ordinary, deterministic content and served static, along with event archive/list pages. Switching between calendar views (month/list) uses a live REST/AJAX interaction that genuinely needs WordPress.
Loco Translate is an in-admin .po/.mo translation file editor with no public runtime footprint of its own at all — the same shape as Classic Editor. Whatever translated strings a visitor sees are a function of which translations already exist in the .mo files, not of Loco Translate itself running, and its editing UI never executes on the public side.
Choosing Classic Editor over the block editor is purely an admin-side, logged-in editing concern — the published post output is identical either way, so this has no effect on what a public visitor receives.
Tulapp
