Why your alt text does not change in the Media Library
This is the single most frequent question about Bialty. You install the plugin, configure a rule, save, then open the Media Library — and the alt text field looks exactly the same as before. Nothing changed.
That is not a bug. It is how the product is designed to work.
Bialty does not write to the Media Library
Bialty uses dynamic frontend injection. It hooks into WordPress rendering filters and modifies the HTML at the moment the page is served to a visitor. The alt attribute is added or replaced in the rendered output, but the stored metadata in the WordPress database stays untouched.
This is a deliberate design choice. It means the original Media Library state is always preserved, the process is instantly reversible, and there is no risk of a destructive bulk rewrite corrupting years of stored metadata. The trade-off is that the Media Library never shows the injected value, because the value is not stored — it is generated at render time.
Where to check the actual result
The correct proof layer is the rendered frontend HTML. Here is the sequence that gives you an accurate answer.
Open the published page in a browser — not the WordPress editor, not the media modal, not a preview. Use the actual public URL. If the site uses any caching layer (page cache, server cache, CDN, performance plugin), clear it first. Stale HTML from a cached version will not reflect the current rule.
Once on the published page, right-click the image and select "Inspect" (or view the page source). Look at the alt attribute on the <img> tag. If Bialty is working, the alt text will match the configured rule — the focus keyword, the post title, the image name, or the combination you selected.
If the alt attribute is present and correct in the HTML, the plugin is doing its job. The fact that the Media Library still shows the old value (or an empty field) is expected.
Common reasons the frontend still looks unchanged
If you check the rendered HTML and the alt text is still missing or wrong, the issue is not that Bialty "does not work." It is usually one of these situations.
Cache was not cleared. This is the most common cause. The browser, the WordPress cache plugin, the server, or the CDN is serving a stale HTML version from before the rule was applied. Purge all cache layers and reload.
The content type is not in scope. Bialty's free edition covers posts and pages. Custom post types and WooCommerce products require the commercial scope. If you are testing a product page on the free edition, the rule will not apply.
The signal source is empty. If the rule uses the focus keyword but the post does not have a focus keyword set in Yoast, Rank Math, or AIOSEO, the plugin has no value to inject. Check that the signal source actually contains data for the specific page you are testing.
A page builder bypasses the rendering path. Some builders render images through custom code that does not pass through the standard WordPress content filters. If the theme or builder bypasses the_content or post_thumbnail_html, Bialty cannot intercept the output. This is a builder limitation, not a plugin failure.
The page is blacklisted or Bialty is disabled for that post. The commercial scope includes a blacklist feature and a per-post disable option. Check whether the specific page or product has been excluded.
Debug mode is needed. In rare cases, the wrapper strategy used by Bialty for DOM processing can conflict with certain themes. Debug mode changes the rendering approach and may resolve the issue. Use it only for troubleshooting, not as the normal operating mode.
Why this design is actually an advantage
Once you understand the model, the fact that the Media Library stays unchanged becomes a strength rather than a source of confusion.
It means you can test a rule, see the result on the frontend, and change your mind without any cleanup. It means you can compare different signal sources — focus keyword, title, image name — and switch between them instantly. It means the plugin is safe to try on a production site because the worst-case scenario is simply disabling it, with zero residual effect on stored data.
For sites that want permanent, stored alt text in the Media Library, a different approach may be more appropriate. But for sites that value safe testing, iterative refinement, and non-destructive deployment, the dynamic model is the better fit.
The one sentence that resolves most confusion
If you remember only one thing from this article, make it this: Bialty changes the rendered frontend HTML, not the Media Library. Check the published page, not the media editor.