Applying Changes to Your CMS

1Connecting your CMS

Every project has a CMS Connect page under project settings. If your site runs WordPress, you can connect it directly with your site URL, a WordPress username, and an Application Password (not your normal login password). Visibilitas checks it against the WordPress REST API before saving anything, and detects whether Yoast or RankMath is installed.

For any other CMS, or if you'd rather not hand over an Application Password, the same page has a Browser Apply section. A toggle switches on routing approved changes through the browser extension instead of an API; changes only travel this way while the toggle is on.

Pairing is what links the extension to this specific project. Clicking Pair a device generates a one-time, eight-character pairing code that's valid for ten minutes only; you enter it once inside the installed extension, and it's spent after that. Paired devices are listed below with when they were last seen, and you can revoke any of them at any time to cut off their access.

2The Visibilitas Apply browser extension

Visibilitas Apply is a Chrome extension. Once installed, it adds a side panel you open next to whatever tab you're working in, and it needs to know which project it belongs to, which is what the pairing code from the CMS Connect page is for. It never signs in on your behalf and holds no login of its own for your site.

When you approve a fix and press Apply, the extension opens its own dedicated tab rather than taking over the one you're already reading, and drives it through your own signed-in CMS admin, finding the right page, opening the editor, and writing the new value while you watch it happen in the side panel. It narrates what it's about to change before it changes it, briefly highlights the field it's about to write, and you can type to it mid-run, including telling it to stop, if something looks wrong.

The security model follows from what the extension deliberately does not do. It does not request Chrome's debugger permission (the same access used to script a browser at the DevTools level) because writing form fields through the ordinary page is enough for every fix type it ships, and it keeps the extension out of the riskiest Chrome Web Store review category. The actual decisions are made by a model running on Visibilitas's servers; the extension only carries out instructions that were already approved, so a compromised page can at most make its own fields harder to find. If the assistant ever needs to reach a site outside your project, such as an admin on a different domain or a login redirect, it has to ask, and the panel shows you the exact address with Allow/No buttons; nothing is inferred from typed text.

Above all: Visibilitas never sees or stores your CMS password. Every write happens inside the browser session you're already logged into, and if that session gets signed out, the assistant stops and asks you to sign back in; it will never type into a password field.

3Tracking applied changes in Actions

The Take Action tab (under a project's Actions area) is the one prioritized list of everything you can do next on a site, including changes still waiting to be applied. Each entry shows a plain-language first step, an impact/effort badge, and a button that takes you straight to where the work happens: Fixes, GEO recommendations, or the CMS Connect page.

A fix that's ready to go through the browser extension shows up here as a pending action; once the assistant finishes writing it into your CMS, it drops off that list and reappears, struck through, under Completed, a running record of what's already been taken care of, without you having to go looking for it.

For the detail behind one specific browser-applied change (which field it wrote, what value was there before, and whether a post-deploy check confirmed it actually took), open it on the Fixes page, where each row carries its own status through the apply.