Hosting and firewalls

If MoraWP reports a blocked request, use the named layer below to find the fix. A blocked request never uses an AI Action. Most layers refuse the request before WordPress runs anything. A few, such as ModSecurity and Imunify360, can replace WordPress's answer after the action ran, so your Agent is told to check the result before trying again.

Confirm the block

What you see: the website's status in the Dashboard says Blocked by the layer, such as Blocked by Cloudflare, and your Agent's error names it too. MoraWP recognizes Cloudflare, SiteGround, Sucuri, Imunify360, Wordfence, ModSecurity, and Hostinger. A ModSecurity refusal shows Blocked by your host, and any other refusal shows Blocked by a firewall. The status clears on its own once MoraWP reaches WordPress again.

What to do: use Check now in the Dashboard to refresh the website's status. In WordPress, open the MoraWP Plugin's Troubleshoot connection to check the Authorization header, REST API restrictions, and recognized hosting protection, then follow its next step.

What to allow

Give this table to your host or firewall administrator. Allow requests that match both the User-Agent and the plugin routes; keep the exception scoped to those routes. Every request to them still needs MoraWP's Application Password and signature, so the exception does not open your website to anyone else.

Cloudflare

What you see: a Cloudflare block or browser challenge prevents MoraWP from reaching WordPress.

What to do: check Security Events for the time of the failure; in the current navigation, open Analytics → Events. Check whether Block AI bots, Bot Fight Mode, or Super Bot Fight Mode caused it.

• On the Free plan, WAF custom rules cannot skip Bot Fight Mode. Turn off Bot Fight Mode if it blocks MoraWP.
• On paid plans with Super Bot Fight Mode, create a WAF custom rule matching both MoraWP's User-Agent and the plugin routes, with action Skip for the protection identified in the event. Include the rest_route query form if your website uses it.

SiteGround anti-bot

What you see: SiteGround returns a CAPTCHA instead of a WordPress response.

What to do: ask SiteGround support to let MoraWP's requests through its anti-bot protection for your website. Send the table above and the failure time.

Hostinger CDN, Sucuri, Imunify360, or ModSecurity

What you see: MoraWP names one of these layers, or the host's logs show a firewall rule blocking the request. Imunify360 and ModSecurity may protect websites managed through cPanel, Plesk, or DirectAdmin.

What to do: allow MoraWP's User-Agent on the plugin routes in the relevant protection, or ask your host to find the blocked request in its logs and exempt the specific rule ID for MoraWP's traffic. Keep the rest of the firewall enabled.

Wordfence

What you see: Wordfence blocks a request to a MoraWP Plugin route.

What to do: open Wordfence → Tools → Live Traffic, find the blocked request by its time and MoraWP's User-Agent, and inspect its rule and parameter. For a confirmed false positive, use Add param to firewall allowlist for only that blocked parameter on that URL.

Without pretty permalinks, the blocked parameter may be rest_route in /index.php?rest_route=/morawp/v1/…. Enabling pretty permalinks avoids this query-parameter case by using /wp-json/morawp/v1/… instead.

Security plugins restricting the REST API

What you see: REST API access is denied by Disable REST API, Solid Security, All In One WP Security, Perfmatters, WP Cerber, Clearfy, or WP Hide.

What to do: allow authenticated requests to /wp-json/morawp/v1/ and its routes, including the equivalent rest_route form where used. MoraWP authenticates with an Application Password; a logged-in-only restriction is fine when it recognizes that authentication instead of requiring a browser login cookie.

Authorization header removed

What you see: the website shows Blocked by your host, or the error mentions morawp_runtime_authorization_missing. Some GoDaddy proxy configurations and Apache CGI/FastCGI/PHP-FPM setups remove the Authorization header before it reaches PHP, so WordPress never sees MoraWP's Application Password.

What to do: update the MoraWP Plugin. Current versions recover on their own: MoraWP resends the same credential in its own header, only to the MoraWP Plugin's signed routes. Nothing runs twice, because WordPress refuses the first attempt before any Ability starts.

If you can't update, ask your host to pass the standard header to PHP using one of these Apache settings. The first requires Apache 2.4.13 or later:

CGIPassAuth On

Or:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

Ask your host which setting belongs in .htaccess or server configuration if you are unsure.

Still blocked

What you see: the same block remains after the relevant exception.

What to do: use Check now again, then get help with the blocked layer, HTTP status, time and timezone, and rule ID if available. Remove credentials and authorization headers from anything you share.