A 406 Not Acceptable error almost always means a security module intercepted the request before it reached your application, not that your code returned it on purpose. On shared and WordPress hosting this is typically a web application firewall rule reacting to something in the URL, headers, POST body, or a cookie: unusual characters, a pattern that looks like an injection attempt, or a request that just doesn't look like normal browser traffic. The fix is to narrow down what's triggering the rule and either adjust the request or get it excluded for your site.
Find the request that's blocked
Don't guess at the cause. Open cPanel from your hosting service and check Metrics > Errors first. If nothing shows in the PHP error log, the block happened before PHP ever ran, which points more strongly at the firewall layer than the application. In that case check Raw Access Logs in cPanel for the request that returned 406 and look at what's unusual about it: a long query string, encoded characters, an odd Content-Type, or a request coming from a script or tool rather than a browser. Note the exact request, timestamp, and any error detail you can find, since support will need it to identify the specific rule.
Common triggers
- Form submissions with special characters. Apostrophes, angle brackets, or SQL-like keywords (
SELECT,UNION,--) in a text field can look like an injection attempt even when they're legitimate user input, like a business name with an apostrophe. - Custom or unusual
User-Agentheaders. API clients, monitoring tools, and some mobile apps send a bare or missing user agent, which some rulesets treat as suspicious. - REST API and AJAX requests. WordPress's REST API, WooCommerce checkout, and plugin AJAX endpoints send POST bodies and headers that can resemble attack patterns, especially with JSON payloads containing nested quotes or brackets.
- Aggressive query strings. URLs with long parameter lists, repeated parameters, or encoded slashes can trip pattern-based rules meant to catch path traversal or injection attempts.
If the same requests are also showing up as 429 Too Many Requests from other IPs or user agents, that's a different mechanism (rate limiting, not pattern matching) but worth checking in the same log review since both often trace back to bot traffic.
Reproduce it narrowly
Before asking for a rule exception, isolate exactly what triggers the block. If it's a contact form, submit it field by field, or with minimal test data, to find which input causes the 406. If it's an API integration, capture the exact request (headers and body) that fails and try a simplified version. Firewall rules match on specific patterns, so a request with just the suspicious substring removed will usually go through fine, which confirms the cause before you request any changes.
For plugin or theme AJAX calls that consistently fail, check whether the plugin has a known compatibility note about security modules or WAFs. Some plugins send data in a way that's technically valid but pattern-matches poorly; a plugin update sometimes resolves this without any server-side change at all.
What to do once you've identified the trigger
If the block is caused by unusual but legitimate input (an apostrophe in a name field, a JSON payload from your own integration, a specific API client), you generally can't tune firewall rule sensitivity yourself from cPanel. This is where a support ticket is the right move: share the exact request from your log review and ask for an exception for that specific pattern on your domain. A precise report, with a reproducible example, gets resolved far faster than "my form doesn't work."
If the request is coming from your own server-side code or a script you control, consider whether the input can be sanitized or the request reshaped before it's sent, since that avoids waiting on a rule change entirely. For example, URL-encoding a payload consistently, or trimming unnecessary parameters, often sidesteps the pattern without weakening anything.
When to open a ticket
Contact support through the portal (Support > New ticket) or live chat if you've confirmed the block is firewall-related but can't resolve it by changing the request yourself, especially for a checkout flow, API integration, or form that needs to keep accepting the input that's getting flagged. Include the log entry from your error log review, the exact request that fails, and what the request is supposed to do. That's usually enough for a rule exception to be added, since the module is working as designed and just needs a scoped carve-out for your legitimate traffic.