Compatibility

Compatibility is where most plugin sites get vague. Bialty should not.

The right way to talk about compatibility is to separate documented support, strong fit, and real-world validation needs.

Strongest compatibility zone

Bialty is strongest when content is rendered through the standard WordPress frontend flow.

That includes the classic editorial path on:

• posts
• pages
• featured images in the standard rendering pipeline
• content blocks that pass through expected frontend filters

SEO plugins

Bialty is designed to work with contextual SEO signals from:

• Yoast SEO
• Rank Math
• All in One SEO

These integrations matter because they give Bialty a clean source for focus-keyword-style logic.

WooCommerce

WooCommerce belongs to the commercial scope.

The product is positioned for:

• product pages
• product image workflows
• gallery-related settings
• catalog testing via the paid trial

That said, WooCommerce output can vary because themes, builders, and custom templates often reshape product HTML. Real validation is still required on the live stack.

Builders and editors

Documented builders and editors include:

• Gutenberg
• TinyMCE / classic content flows
• Elementor
• SiteOrigin

Important nuance:

Bialty can only affect what passes through the expected WordPress frontend path. A builder that stores or renders content in a custom way can limit or change the result.

Beaver Builder note

Beaver Builder deserves a specific note.

The product includes a known special case for Beaver Builder edit mode. That means you should not talk about Beaver Builder as a blanket “yes” without qualification. The right phrasing is:

validate frontend behavior separately from builder edit mode.

Areas outside the default promise

Do not present these areas as automatic wins without testing:

• headers
• footers
• sidebars
• custom widgets
• template zones outside the standard content flow
• heavily customized product templates

Compatibility table

Area	Status	How to talk about it
Posts and pages	Strong fit	Core product scope. Safe to document clearly.
Yoast SEO, Rank Math, AIOSEO	Documented signal sources	Use the wording “when those signals are available on the site.”
WooCommerce	Commercial scope	Document as supported, but require theme validation for rollout.
Elementor and SiteOrigin	Validate on output	Works when the builder output follows the expected frontend path.
Beaver Builder edit mode	Special case	Call out edit mode separately from published frontend behavior.
Headers, footers, sidebars	Outside default promise	Do not promise broad coverage without project-specific testing.

Recommended validation workflow

Before calling a stack “compatible”, validate:

1. a published page or product on the frontend;
2. the rendered HTML after cache purge;
3. the real theme template in use;
4. any builder-specific view that differs from the normal frontend.

Bottom line

Compatibility is not a badge list. It is a rendering question.

The strongest, safest claim is this:

Bialty works best where WordPress output stays close to the standard frontend rendering pipeline.