Fix & troubleshoot

WordPress MCP connection failed, timed out, or returned a 5xx error

This is a connectivity problem, not a login problem. Your username and application password are probably fine (if you were getting a 401 or 403 "unauthorized," see our separate MCP 401/403 fix page). Here the request from wptaskify's server, or from your AI client, never gets a clean answer from your site: it is blocked, challenged, redirected, or it takes too long and times out. There are a handful of very common culprits, and most of them live in front of WordPress rather than inside it: 1. A bot filter is blocking the request. Cloudflare's "Block AI Bots"/"Bot Fight Mode"/"Super Bot Fight Mode," or a managed host's own anti-bot AI (SiteGround, WP Engine, and similar), sees a server-to-server request with no browser, no cookies, and a plain HTTP user-agent, scores it as "a bot," and blocks or challenges it. This is the single most common cause in 2026, and it is silent - you just see a failure or timeout. 2. A security plugin is blocking the REST API. Wordfence, Solid Security (formerly iThemes), All-In-One WP Security, or "Disable REST API"-type plugins can restrict /wp-json/ to logged-in users or block routes outright. 3. The /.well-known/ or /wp-json/ path never reaches WordPress. Some hosts serve /.well-known/ straight from the server (nginx/Apache) and return 404 before WordPress runs, which breaks the OAuth discovery step some connectors use. Setting WordPress permalinks to "Plain" also disables the rewrites those endpoints rely on. 4. The connection or a tool call times out. On slow or shared hosting, a low PHP max_execution_time or a low gateway timeout means a heavier tool call (bulk edits, media, big queries) is killed mid-request, showing as a 504 or "timed out." 5. The plugin is not installed, not active, or the site is not publicly reachable over HTTPS. A local-only site (LocalWP, .test, MAMP) or an http:// (non-SSL) site cannot be reached or cannot use application passwords. Some of these are things you can fix on the site; some are host-side and need your host's support. We flag which is which below.

The fix

Step by step

First, confirm the wptaskify plugin is installed and activeIn wp-admin go to Plugins and confirm the wptaskify connector plugin is installed and Activated. If it is missing or deactivated, the MCP endpoint and the encrypted application password it creates will not exist, and every connection attempt will fail. Reinstall or reactivate it, then reconnect from your wptaskify dashboard. This is the quickest thing to rule out.
Confirm the site is public and on HTTPSYour site must be reachable from the public internet over https:// (a valid SSL certificate). WordPress application passwords are rejected over plain http:// in production, and a local-only site (LocalWP, a .test/.local domain, MAMP/XAMPP) cannot be reached by wptaskify's server at all. Open your site in a normal browser and confirm the padlock. If the site is local-only, put it behind a public URL (for example a Cloudflare Tunnel or ngrok) or connect a live/staging site instead.
Check that /wp-json/ actually respondsIn a browser (or with curl), open https://yoursite.com/wp-json/ . You should get a JSON response, not a 403, a challenge page, a redirect, or a spinner that never loads. If you get JSON, the REST API is reachable and the problem is likely bot-filtering or auth-header handling (later steps). If you get 403 or a security/challenge page, a security plugin or firewall is blocking it - continue below.
Allowlist wptaskify in your security pluginIf you run Wordfence, Solid Security, All-In-One WP Security, or any "Disable/limit REST API" plugin, these can block anonymous /wp-json/ requests. Look for the option that restricts the REST API to logged-in users, or an allowlist/whitelist for paths, and allow /wp-json/ (and any MCP/OAuth route the connector uses). As a quick test, temporarily deactivate the security plugin and retry the connection - if it works, re-enable the plugin and add the allowlist rule rather than leaving it off. Exact menu labels differ between plugins and change between versions, so look for the REST API / firewall / allowlist section rather than a fixed click path.
If you use Cloudflare, stop it from blocking the AI/MCP requestCloudflare is the most common blocker in 2026. In the Cloudflare dashboard, under Security, check for Bot Fight Mode, Super Bot Fight Mode, and the "Block AI bots"/"Manage AI bots" setting - any of these can silently block a server-to-server request. On paid plans, the recommended fix is to add a WAF custom rule that Skips bot protection for your REST/MCP path (a rule matching URI Path starts with /wp-json/ , action "Skip", placed at the top), so you keep protection everywhere else. On Cloudflare's Free plan you cannot create path-based skip rules, so you must either turn off Bot Fight Mode / "Block AI bots" or allowlist by IP. Also exclude /wp-json/ from any page-cache rules so POST requests are not served from cache. Note: the exact toggle names and menu layout in the Cloudflare dashboard change fairly often - navigate by the Security area rather than a memorized click path.
Rule out a host-level firewall or anti-bot (this is host-side)Some managed hosts run their own bot AI in front of your site that you cannot control from wp-admin - for example SiteGround's Anti-Bot AI (can throw a CAPTCHA at the connection) and WP Engine's WAF (has been reported to 403 requests whose user-agent contains "python"). If steps above did not help and you are on managed hosting, contact your host's support and ask them to allowlist wptaskify's connection to your /wp-json/ (and /.well-known/) paths, or allowlist the connecting IP. Be explicit that this is a legitimate integration, not a scraper. This one genuinely cannot be fixed from inside WordPress on those hosts.
If it fails at the connect/authorize step specifically, check /.well-known/ and permalinksSome connectors discover the server via /.well-known/ URLs. On certain hosts the whole /.well-known/ prefix is served by the web server and returns 404 before WordPress runs, and separately, setting WordPress permalinks to "Plain" disables the rewrites these root-level endpoints depend on. Fix the easy one first: in Settings > Permalinks choose any non-Plain structure (e.g. Post name) and Save (this also flushes rewrites). If /.well-known/ requests still 404, that is usually a server-level rewrite and needs your host to route /.well-known/ through to WordPress, or a Cloudflare Transform Rule - handle it with host support. We are describing this generally on purpose; the exact server rewrite differs per host.
Fix Authorization-header stripping (Apache/managed hosts)Some Apache and managed-host setups strip the Authorization header before it reaches PHP, so the application password never arrives and the request fails. On Apache, adding a SetEnvIf Authorization rule to .htaccess restores it; on nginx, the fastcgi_param HTTP_AUTHORIZATION line does the same. On managed hosting you may not be able to edit these files - ask support to pass the Authorization header through. If you are unsure whether this applies, this is worth checking specifically when the site is reachable and not obviously bot-blocked but auth still "doesn't take."
Raise PHP/gateway timeouts if it connects but tool calls time outIf the initial connection works but the AI's actions fail with a timeout or 504 - especially bulk operations, media handling, or large queries - your host's PHP max_execution_time (often 30-60s on shared hosting) or gateway timeout is too low. Increase PHP max_execution_time (and memory_limit) via your host's PHP settings panel, or ask support to raise them. On strict shared hosting these limits are capped server-side and only your host can lift them; running heavier tasks in smaller batches also helps. After raising limits, retry the operation.
Retry the connection, then reconnect from wptaskifyAfter making a change, retry from your wptaskify dashboard's connect flow (a fresh attempt, ideally from a clean/incognito browser session so a cached challenge or stale redirect doesn't interfere). If the connection now holds and a test tool call succeeds, you're done. If it still fails, note exactly which stage broke (reaching the site, authorizing, or a later tool call) and the exact error/status code - that tells support whether it's site-side, host-side, or client-side.
Still stuck? If you've worked through all the steps and it still fails, capture exactly where it breaks and hand that to support - it's the difference between a 5-minute fix and hours of guessing. Note: (1) the exact error text and HTTP status code, (2) which stage fails - reaching the site, authorizing/connecting, or a later tool call, and (3) what https://yoursite.com/wp-json/ returns in a plain browser. Then: if https://yoursite.com/wp-json/ is itself blocked/challenged/hangs, the blocker is your host or a firewall - open a ticket with your hosting support asking them to allowlist wptaskify's requests to /wp-json/ and /.well-known/ (they can see their own WAF/anti-bot logs, which you can't). If /wp-json/ works in a browser but the connection still fails, send those three details to wptaskify support so they can see where the handshake breaks. If your host caps timeouts or refuses to allowlist and won't budge, the practical fallback is to move the site to a less restrictive host or a staging site you control. This connectivity/timeout issue is independent of which AI client you use (Claude, ChatGPT, or another MCP client), so switching clients will not fix a site-side or host-side block.
FAQ

Related questions

Is this the same as the 401/403 "unauthorized" error?

No. A 401/403 means the site was reached but rejected your credentials - see our separate MCP 401/403 fix page for that (application passwords, user role, disabled REST auth). This page is for when the request fails to complete at all: connection refused, timeout, a 5xx server error, or a bot challenge before authentication even happens. That said, a firewall returning 403 to block a bot can look like an auth error - if /wp-json/ returns 403 to an anonymous browser request, treat it as blocking (this page), not as a credential problem.

Do I have to turn off my firewall or security plugin to connect?

No, and you shouldn't leave it off. Deactivating a security plugin or Cloudflare bot protection is only a diagnostic step to confirm it's the blocker. Once confirmed, add a targeted allowlist/skip rule for your /wp-json/ (and MCP/OAuth) paths and turn protection back on. The goal is to allow this one legitimate integration through, not to lower your site's security everywhere.

Is the problem wptaskify, my AI client, or my site?

Usually it's something in front of your WordPress site - Cloudflare, a host firewall, a security plugin, or a low server timeout - not wptaskify and not your AI client. wptaskify's server just makes a normal authenticated request to your REST API; if that request is blocked, challenged, or times out, the failure surfaces as a connection error. The fastest way to tell: open https://yoursite.com/wp-json/ in a browser. If that itself is blocked or hangs, the issue is on the site/host side.

I'm on SiteGround or WP Engine and nothing in wp-admin fixes it. Why?

Those hosts run their own bot/AI filtering in front of your site that you can't see or toggle from the WordPress dashboard. SiteGround's Anti-Bot AI can challenge the connection, and WP Engine's WAF has blocked requests based on user-agent. On these hosts the fix is to contact the host's support and ask them to allowlist the connection (by path and/or IP). This is a genuine host-side limitation, not something wptaskify can override for you.

It connects fine but the AI's actions randomly fail or time out. What's wrong?

That points to server timeouts rather than connectivity. Heavier tool calls (bulk edits, media, large queries) can exceed a low PHP max_execution_time or gateway timeout, especially on shared hosting, and get killed mid-request (often a 504). Raise PHP max_execution_time and memory_limit via your host, or ask support to, and run big jobs in smaller batches. If limits are capped server-side, only your host can lift them.

Ready to connect your AI to your site?

Start free How it works