Skip to main contentSkip to content

How it works ​

Bialty is easiest to understand when you separate three layers:

  1. stored WordPress content;
  2. editor and Media Library state;
  3. rendered frontend HTML.

Bialty acts on the third layer.

The rendering model ​

The product hooks into WordPress and WooCommerce rendering so it can inspect the HTML that is about to be served on the frontend.

At that stage, Bialty can:

  • find images inside the rendered content flow;
  • decide whether an image alt attribute is empty or already populated;
  • apply the configured rule;
  • output the changed HTML back to the frontend.

That is why the plugin feels immediate. You change the rule, and the rendered output changes without a massive migration step.

Why the Media Library stays untouched ​

Bialty does not need to update the Media Library in bulk to do its job.

This design has practical consequences:

  • there is no destructive rewrite to roll back later;
  • there is no need to regenerate a full metadata history;
  • the product stays reversible;
  • you can validate output before you decide to keep a rule.

The logic layer ​

At a high level, Bialty answers two questions:

1. What should happen when alt text is missing? ​

You pick a rule such as:

  • focus keyword
  • title
  • image name
  • combined variants

2. What should happen when alt text already exists? ​

You choose whether to leave the current value alone or replace it according to the selected rule.

That split is important because many sites do not have a single clean historical state. Some images are blank, some have weak values, and some have values worth preserving.

Signal sources ​

Depending on the site and plan, the plugin can use:

  • post title
  • image file name
  • focus keyword from Yoast SEO
  • focus keyword from Rank Math
  • keyphrase data from All in One SEO
  • target keyword from SEOPress

That makes Bialty a contextual rule engine rather than a caption generator.

Manual override path ​

Bialty also supports manual overrides through a post-level workflow.

This is where you keep control over:

  • premium landing pages;
  • important product pages;
  • templates where a global rule is not enough.

Commercial expansion ​

The commercial scope extends the same logic to:

  • custom post types
  • WooCommerce product flows
  • extra configuration controls such as blacklist and Add Site Title

In other words, the product architecture stays the same. The scope expands.

Why debug mode exists ​

In normal operation, Bialty uses a wrapper strategy that helps the DOM processing step.

Debug mode exists for edge cases where a wrapper may create rendering or styling issues. It is a troubleshooting tool, not the normal path.

The right mental model ​

If you remember only one sentence, make it this one:

Bialty changes rendered output, not stored Media Library metadata.

That single sentence explains most of the product behavior, most of the troubleshooting, and most of the trust advantage.