How to Use Kinsta to Update Plugins Without Breaking Pages

The short answer: if a plugin update has ever broken a landing page or a checkout, Kinsta Automatic Updates compares screenshots of up to five pages you choose before and after each update and restores the pre-update backup when it spots a change, for $3 per environment a month after a free first month (Automatic Updates docs, checked on 26 October 2026). The steps: rehearse once on the free staging environment, switch the add-on on, set a testing window, enter your five money pages as Test URLs, exclude anything that moves on its own, let an agent list what the add-on cannot reach, and read the update log every week.

Disclosure: I may earn a commission through some links on this site. It does not change what this page says.

Three inputs, then the setup:

1. The monthly cost. For example, four live sites at $3 per environment is 4 x $3 = $12 a month, and adding the same four staging environments makes it 8 x $3 = $24, from the Automatic Updates docs.
2. The five pages that carry revenue. Your top landing page, pricing, the sign-up form, its thank-you page and checkout. You already know them from analytics; they become the Test URLs in step 4.
3. The log you will read. Each update appears with before and after screenshots, kept for 60 days, under Plugins and themes, per the same docs. Count rollbacks per month; a rising count is a plugin to replace.

Plugin updates break pages quietly. The site stays up, the checkout button drops below the fold or a form loses a field, and nobody notices until conversions do. Kinsta's add-on looks at the pages the way a visitor does, before and after, and that is the whole idea. Plans and prices are in the Kinsta glossary entry.

What you need

• A Kinsta WordPress plan. Plugin management in MyKinsta does not cover WordPress Multisite.
• A MyKinsta login that manages the site; for step 6, an owner, administrator or developer, the roles that can create API keys.
• The five URLs, and a browser with developer tools for step 5.

Step 1: Rehearse once on free staging

Each WordPress install at Kinsta can have a free standard staging environment, per the staging docs. Create one by cloning the live environment, update the plugins there by hand and open the five pages. That run shows you what an update does to your pages before any automation does it on live. If you push the result to live, the push docs let you push files only, which leaves the live database, and its new orders, untouched.

Step 2: Switch on Kinsta Automatic Updates

In MyKinsta, go to Sites, the site, Plugins and themes, Automatic updates, then Change. Select Kinsta Automatic Updates and click Continue. Turning it on switches WordPress's own auto-updates off for every plugin, and the docs ask you to disable any other automatic update system as well, so two updaters never race each other.

Step 3: Pick the days and the window

Under Testing frequency, choose the days; under Testing time window, the hours. Avoid editing the site during the window, because a failed update restores a backup taken before it and your edits go with it. Kinsta's own maintenance runs from 2 am to 5 am in the data center's time zone, and updates that collide with it retry later. Tick Enable WordPress maintenance mode if you want visitors to see a maintenance page while updates run.

Step 4: Enter the five money pages

By default the test uses your homepage and four random pages from your sitemap. Enter your five URLs in Test URLs, one per line, and only those are tested, even if you list fewer than five. A random blog post breaking is a nuisance; a checkout breaking is lost revenue, so choose the pages accordingly.

Step 5: Exclude what moves on its own

Rotating banners, a "Welcome back" message or a chat widget change between screenshots even when nothing broke, and a false difference marks the update as failed. Run Preview visual regression test on each Test URL. If it reports dynamic content, click Show difference for a heat map, find the element's class or ID with your browser's Inspect tool, and add it to CSS selectors to exclude. Preview again until it reports no dynamic content, then set Sensitivity: lower ignores minor differences, higher catches subtle ones and raises false alarms.

Step 6: Let an agent list what the add-on cannot reach

This is the agent step. The docs warn that premium and custom plugins may have no public update endpoint, so MyKinsta cannot update them. Kinsta's tutorial on building an MCP server on the Kinsta API shows an agent in Claude listing sites, environments, and outdated or vulnerable plugins and themes. Point that agent at your company once a week and ask for one list: plugins with an update available that Automatic Updates has not installed.

Create a dedicated API key for it under Company settings, API Keys, with an expiry date, per the API docs. The key inherits the access of the person who creates it, so a developer's key reaches less than an owner's. The tutorial's server can also trigger plugin updates; for this job, leave that tool out. The agent drafts the list, and a person updates those plugins on staging, checks the five pages, then pushes.

Step 7: Read the log every week

Updates installed by the add-on appear under Plugins and themes, Kinsta Automatic Updates, with Details for each run: what succeeded, what failed, the screenshots and any highlighted differences. A plugin that fails three times is paused on that environment and retried after 1, 2, 4, 8 and 16 days, then every 30 days. The error names tell you where to look: a domain error, a screenshot difference, a height difference that suggests part of a page failed to render, or a WP-CLI error worth a support ticket.

Where the docs say it trips

• Password protection. It blocks the screenshot service, so lift it during the window, or allowlist the kinsta-bot user agent or ScreenshotOne's IP ranges if your security rules block unknown visitors.
• New plugins. One passage says newly installed plugins join the add-on automatically; another, on the same page, says automatic updates are not enabled for a plugin installed afterwards. You are not misreading it: check the setting for each new plugin.
• Too many updates for one window. The rest carry over to the next testing day.
• Changing plan early. If you change your hosting plan within two months of activating the add-on, the docs ask you to contact the Billing team.

Free first, then the add-on

Step 1 costs nothing and works without the add-on: one staging rehearsal per plugin batch, five pages checked by eye. For one site with a few plugins that may be all you need. The add-on earns its $3 when there are more sites than anyone has time to check. Know what you are trading when you turn it on: enabling it switches off WordPress's free auto-updates for every plugin, so after the free month Kinsta's $3 per environment is the only automatic updater left running unless you switch back, per the Automatic Updates docs.

FAQ

What happens when an update breaks a page?

The add-on detects the change in the screenshots and restores the backup taken before the update. Those backups stay for three days under Backups, System-generated, with a note of which plugin was updated, per the Automatic Updates docs.

Does it update inactive plugins too?

Yes. All plugins and themes are updated, including inactive ones, according to the same docs.

Can I turn it on for all my sites at once?

Yes, from Sites: select the sites, click Actions, then Plugins and themes, then Change automatic updates. Test URLs and excluded selectors still have to be set site by site.