How do you track updates WordPress does not show you?
By checking them by hand each month. A bundled plugin does not report to the WordPress updates screen, so the bundled builder and slider on your site can sit years behind the current releases without a single notice, which is exactly how these sites drift. Every month we compare those versions, and the theme's own last release, against what is current. You get the gap in plain numbers, and a recommendation only when the gap becomes a reason to act rather than a reason to worry.
How are the parts you can update handled?
Carefully, and with the builder-heavy pages looked at before release. WordPress core, PHP-sensitive plugins and everything else that does update normally go onto a staging site, and the pages built most heavily in WPBakery are opened at phone and desktop width there first. That ordering matters more here than on a typical site: a core or PHP change can alter how old shortcodes render, and the failure is visual rather than an error, so nothing alerts you. The check is a person looking at the pages that bring in money.
Which security work actually helps on this stack?
The specific kind, not generic hardening. On a site whose exposure is a known vulnerability in a component that cannot be patched, a checklist of general settings does little. What helps is blocking the request patterns aimed at the historic slider exploits, restricting who can upload and what, and watching the folders those exploits write to. If a site is compromised anyway, cleanup starts from $299 and we would rather have prevented it.
How are Slider Revolution and the other bundled plugins handled?
Each one is listed with its source, version and update path, because on these themes they rarely share one. Some bundled plugins can be moved to a licence you own and update normally from then on; some can be replaced with something lighter; and some are not used at all and can simply be removed. We work through that list over the first months rather than in one sitting, so each change is small, tested and easy to reverse.
Can the backups actually be restored?
Yes, because we test them. A copy of a bundled-theme site is only worth having if the theme and its bundled plugins come back exactly as installed, which is the part many backup plugins handle badly. We include the full theme directory, keep enough versions to go back past a problem that went unnoticed for a fortnight, and periodically restore one onto a scratch server to confirm the site comes up whole. An untested backup is a belief, not a safeguard.
Who makes the small monthly changes?
We do, as part of WPBakery website support. Text corrections, price updates, a new staff photo, a seasonal banner: on a WPBakery site each of these carries a small chance of a layout shifting, so we make them, check the published page at the widths that matter, and log what changed. Plan hours cover these, and the log is what makes the next change quicker rather than a fresh archaeology exercise.
When do we have to do something bigger?
When the risk outgrows the arrangement, and a plan gives you a date for that rather than a worry. We keep a running position on how long the current setup remains reasonable, based on the theme's update history, the severity of anything published against the bundled versions, and how much the site earns. When that position changes, you hear it early and with options (a direct licence, a theme replacement, or a staged move) rather than in the week something breaks.
How much is WPBakery maintenance?
Essential is $159/mo a month for monitoring, weekly off-site backups, a malware check and a monthly report, with no development time. Staged updates and small changes are done on the development plan at $700/mo, which includes a block of developer hours every month. Hours beyond a plan are billed at $100, or bought in advance in five-hour ($500) and ten-hour ($1,000) blocks. Every plan is monthly and can be cancelled; nothing here is a contract you have to argue your way out of.
