How can Kinsta bot protection allow a needed WordPress automation?

The Citead team, updated

In short. Enable the WordPress automation allowance or add a narrowly scoped Kinsta exception with an Allow action.

Definition: Kinsta Bot Protection can allow common WordPress features, integrations, and background tasks through its WordPress automation allowlist. If a needed service still needs a specific rule, an exception can allow matching requests by IP address, path, user agent, or country.

Key facts

  • Kinsta describes the automation setting as an allowance for WordPress features, integrations, and background tasks that rely on automated requests to the site. Kinsta's Bot Protection documentation says the allowlist is managed by Kinsta and may change over time.
  • The WordPress REST API Handbook says applications interact with a WordPress site by sending and receiving JSON through REST endpoints.
  • WordPress's Cron documentation says WP-Cron handles time-based tasks and is triggered by page loads.

When should you enable the WordPress automation allowance?

Enable Allow typical WordPress automations when plugins or integrations, the WordPress REST API, or background work such as scheduled posts, updates, cron jobs, or data syncing needs automated requests. Kinsta says the setting is disabled by default. In MyKinsta, open Sites, select the site, open Bot protection, and turn on Allow typical WordPress automations. The Kinsta instructions also provide a bulk path through Actions, Bot protection, and Change WordPress automation allowlist.

Kinsta separately allows requests from the site's own container and Kinsta-managed internal infrastructure. The documentation names internal requests to /wp-json/* and Kinsta-managed WP-Cron tasks as examples, and says core scheduled tasks continue running internally in most cases. The managed allowlist covers trusted WordPress endpoints, tools, and third-party services, but Kinsta says that list may change over time.

The REST API is a normal integration surface for applications. WordPress documents that its endpoints represent posts, pages, taxonomies, and other data types, and that an application can send and receive JSON through them. WordPress also documents WP-Cron as the mechanism used for time-based tasks such as update checks and scheduled post publication.

How do you add a custom exception?

Use a custom exception when a required external service is still challenged or blocked, or when you need a narrower rule than the managed allowance. For one site, go to Sites, select the site, open Bot protection, and choose Add exception in Exceptions. Kinsta's exception instructions also describe a bulk action for several selected sites.

Choose the field that identifies the request, then choose Allow, Challenge, or Block. Kinsta documents four fields: IP address, path, user agent, and country. A path rule uses Starts With matching by default, and wildcards are unsupported. For an API path, the documentation gives this example:

/wp-json/
/wp-admin/admin-ajax.php
/webhooks/

The /wp-json/ entry therefore covers URLs beginning with that path, including custom REST endpoints. A monitoring service can instead be identified by its user agent, and a fixed office or agency connection can be identified by IP address. Kinsta allows up to 50 exceptions.

What happens when exceptions overlap?

Kinsta evaluates matching actions in this order: Allow, then Challenge, then Block. If a request matches more than one of your exceptions, the action with the higher priority wins, so an Allow rule takes precedence over a Block rule even when the Block rule uses a more specific field. The Kinsta documentation gives a country Allow and user-agent Block as an example of this result.

These exceptions bypass Bot Protection challenges and blocking rules. They remain subject to Kinsta's Vulnerability protection and other platform-level security, which can still block an allowed source when the request is identified as malicious or violates a platform rule.

Exceptions are environment-specific. A live-environment exception does not apply to staging, and an exception is not copied to the target environment when one environment is pushed to another.

FAQ

Will enabling the setting allow every automated request?

No. The setting uses a Kinsta-managed allowlist of trusted WordPress endpoints, tools, and services. Kinsta says that internal requests are automatically allowed, while external requests can still need a custom exception.

Which custom rule is suitable for a WordPress REST integration?

Use a Path exception for the required path, such as /wp-json/, and select Allow when the integration should pass without a challenge. Because path matching starts with the entered text, a /wp-json/ rule also covers URLs below that path.

Do exceptions apply to both live and staging environments?

No. Kinsta documents exceptions as environment-specific, so the rule must be configured in each environment where the automation runs.

Sources

  1. Kinsta, "Bot Protection", 12 June 2026
  2. WordPress Developer Resources, "REST API Handbook", 14 October 2026
  3. WordPress Developer Resources, "Cron", 14 December 2023

Check how a page reads to answer engines. Open the GEO score analyzer

Test a page and see what to fix first

The analysis usually takes less than 10 seconds and needs no account.

400,000+ pages scored in the public benchmark