Kinsta's August batch is smaller than last month's but lands in more places. The bot protection exception list stopped being an allowlist and became a full traffic-control rule set, complete with country matching. MyKinsta now asks for your password again before sensitive account changes. The API gained five analytics endpoints and a search-and-replace. And sites on dedicated servers can add a standby server in another region. Here's what each change does and who it matters to.
Bot protection: the exception list became a traffic control
When Kinsta opened up bot traffic analytics last month, the tool could already block and challenge traffic at the level of the whole site. What it could not do was fine-grained exceptions: the Add new exception screen matched on IP address, path or user agent, and the only verdict available was allow. It was an allowlist, and nothing else.
Two changes turn it into something different. Each exception now carries one of three verdicts — Allow, Challenge or Block — and a fourth matching criterion joined the list: country of origin. Together those mean you can express rules the tool previously had no vocabulary for: challenge everything from one country, block a single abusive ASN's address range outright, and still wave your own monitoring through by IP.
Country matching is the change to think about hardest, because it is the bluntest instrument in the set. Traffic origin is not intent — a country that sends you a botnet also sends you customers, VPN users land wherever their exit node is, and a blanket block is invisible to you and total for whoever it catches. If your traffic is genuinely local it costs you little; if you sell across borders, reach for Challenge before Block, because a challenge page is recoverable by a human and a block is not.
The advice from last month applies doubly now: after every tightening, go back to the bot traffic charts and check what the rule actually caught. A rule strict enough to stop a botnet is strict enough to stop an uptime monitor or a payment provider's webhook, and the charts are where that shows up. Kinsta points out that the tool stays free, which is fair enough — traffic control at this granularity is usually a paid add-on, when a host offers it at all. The documentation covers the rule syntax.
Re-authentication: MyKinsta asks for your password again
MyKinsta now re-prompts for your password before five specific actions: setting up a two-factor authentication app, adding or removing SSH keys, creating or revoking API keys, connecting or disconnecting a Git service, and managing company users and their roles.
The pattern is sometimes called sudo mode, and the list is well chosen — every item on it is a way to hand someone durable access that outlives the session. An API key created by an attacker who found an unlocked laptop keeps working long after the browser closes; so does an added SSH key or a new company user. Re-authentication is what stops a hijacked session from quietly becoming permanent access.
It costs you a few seconds and a trip to the password manager, several times a year at most, because none of these are daily operations. The honest observation is less that Kinsta shipped it than that a hosting control panel reached 2026 without it — this is table stakes, and it is good to see it arrive.
API: five analytics endpoints, plus a search-and-replace
The API team added five analytics endpoints, all of the same shape: top requests by user agent, by referrer, by host, by browser and by ASN. Everything MyKinsta already showed on a dashboard is now something you can pull on a schedule — which is the difference between a chart someone remembers to open and a number that lands in your own reporting.
Top ASNs is the one worth flagging, because it pairs directly with the bot rules above. An ASN is the network a request came from, and automated floods tend to cluster in a handful of them. Pulling the ASN breakdown, spotting the outlier and writing the matching exception is a considerably sharper workflow than blocking a whole country and hoping.
Two non-analytics endpoints also landed. Search and replace is the more useful of them: the operation you run across a WordPress database after a migration or a domain change, and until now something you did through a plugin or WP-CLI. Having it as an API call makes it scriptable across a fleet. The second returns the date of the next available downloadable backup. Two existing endpoints changed as well — site logs gained a search and a date selector, and requesting a downloadable backup now returns an error if you trigger it more than once a week, rather than silently accepting a request that was never going to run.
Disaster recovery: a standby server, not a failover cluster
Sites on a dedicated server can now add disaster recovery: a standby copy of the server running in a different region, syncing every 10 minutes. If Kinsta's team identifies a critical issue at your primary data centre, they switch the site over manually and alert the company owners, administrators and developers on the account.
Read that description carefully, because the two words doing the most work are passive and manually. This is not high availability and Kinsta does not claim it is. There is no automatic failover: the switch happens when a human at Kinsta decides it should, which means your recovery time depends on their detection and response, not on a health check. And a 10-minute sync interval means up to 10 minutes of writes can be lost — fine for a content site, worth thinking about for anything taking orders or payments.
Kinsta already runs disaster recovery plans for every account, and the add-on does not replace them. What it buys is speed in the worst case. In a severe infrastructure incident — the data centre fires that occasionally make the news and take days or weeks to resolve — restoring from account-level backups takes time proportional to how bad the incident is. A warm standby in another region shortcuts that.
The catch is eligibility: the add-on exists only for dedicated servers, so if your sites run on a regular Kinsta plan, taking it up means migrating to a dedicated server first. That turns a resilience decision into a hosting-tier decision, and the honest way to evaluate it is to price the dedicated server and the add-on together against what an outage of several days would actually cost you. For most sites that sum will not add up; for a business whose revenue stops when the site does, it might. You will find it in MyKinsta under Sites > site name > Add-ons, in the Dedicated server section, and the details are in the documentation.
Summary
The bot protection change is the substantial one. Moving from an allowlist to Allow, Challenge and Block, with country as a matching criterion, turns a defensive setting into something you can actually shape around a specific attack — and the new top-ASN endpoint gives you the data to aim it properly rather than blocking by geography. Re-authentication is overdue rather than exciting, and the API additions are quietly useful if you run more than a handful of sites.
Disaster recovery deserves the closest reading. It is a genuinely useful product described honestly — Kinsta says plainly that the standby is passive and the switch is manual — but the words disaster recovery carry expectations of automatic failover that this add-on does not meet, and the dedicated-server requirement puts it out of reach of most accounts anyway. Worth knowing it exists; worth checking your own numbers before assuming you need it.
