HTTP 406 can mean the service cannot return a format acceptable to the client. Some hosting security configurations also use it for a blocked request. Identify the responding component and compare its message or logs with the failing action before choosing between request-format correction and a specific security-rule review.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Failure pattern | Inspect | Useful next step |
|---|---|---|
| Custom client always fails | Accept headers and supported response formats | Align with the documented service contract |
| One editor submission fails | Matching security event and reduced content example | Review the actual rule or application response |
| External API returns the error | Destination and response body | Ask that provider about accepted formats |
| Simple draft works; an embed fails | Smallest reproducible difference | Review the content and matching event |
Understand the standard meaning
MDN explains that 406 concerns a response that cannot match the acceptable values requested by the client, when the server is unwilling to provide a default. Headers such as Accept and Accept-Language can be part of that negotiation. This is about what the requesting tool says it can receive.
For example, a custom client might request a particular document format from a service that only returns JSON. Its developer should compare the request with the service’s documentation and choose a supported format. Changing the website’s visual theme would not address that mismatch.
For ordinary visitors, the server should provide a useful message where possible. If the response names supported formats or another requirement, keep that text when reporting the problem. The number alone leaves out the most helpful detail.
Consider the component returning the message
Keep the evidence paired: failed save time, content difference and any matching security event. A simple harmless draft is a useful comparison. A security product being installed does not prove it returned this particular 406; its event and rule identifier strengthen that finding.
Some hosting security systems also return 406 for blocked requests. cPanel documents that ModSecurity 3 with NGINX can use 406 in situations where another version returns 403. That establishes a possible source, not proof that every WordPress 406 is a firewall block.
If a save action fails, record the time, the affected screen, and whether a simple harmless test also fails. Ask the hosting provider to compare that attempt with the security event logs. A matching event and its rule identifier provide a firmer basis for discussion.
Imagine that saving a short plain-text draft works, while adding one particular embedded element consistently fails. Preserve the intended content separately and describe the smallest reproducible example. That lets the provider review the request without asking you to disable protections across the site.
Use a targeted investigation
Start with one failing action and one comparison. Note the URL, whether you were signed in, and any recent integration or hosting changes. Avoid changing several plugins, server settings, and browser options at the same time; you will lose the connection between the test and its outcome.
A developer can inspect the response body and headers to identify the service involved. If the request goes to an external API, the API provider may need to explain its accepted formats. If the host’s security log identifies a block, the hosting team can review that event instead.
When sharing evidence, redact cookies, authorization values, and private form content. The endpoint, time, and a reduced example are often enough to begin. Keep a full private copy only where appropriate for your own troubleshooting.
Correct the requirement or review the rule
For an API, confirm the client’s accepted format and the service’s actual output together. For a confirmed false match, the provider should assess the exact path, condition and content involved. Review an unfamiliar script or embed itself before concluding the security decision is mistaken.
For a format mismatch, align the client with the documented response formats. The developer should also check that the application handles the response it receives. Simply removing a header without understanding the service’s contract may produce a different error.
For a confirmed security false positive, ask the provider for a narrowly scoped correction that permits the legitimate action while keeping protection in place. The rule, path, and request context matter. A blanket instruction to turn off ModSecurity is too broad for a diagnosis based on one rejected submission.
If the content itself contains an unexpected script or an unfamiliar embed, review it before assuming the security system is mistaken. The goal is a working legitimate request, not making every request pass without examination.
Test the same action after the correction
Repeat the original action with a suitable test and confirm that the expected result is saved or returned. For an article edit, reopen the saved content. For an integration, verify the response and the resulting record, not just the absence of an error banner.
Keep the identified source and correction in a brief note. A response-format problem and a confirmed security-rule problem can look similar on screen, but they need different explanations. Knowing which occurred will make a future incident much easier to handle.
References: MDN’s HTTP 406 explanation and cPanel’s ModSecurity 3 documentation.
Verify the saved or returned result
Repeat the original action with suitable harmless data. Reopen the saved article or inspect the integration’s expected output. Record whether the confirmed source was response negotiation, application behavior or a matching security rule so a later recurrence follows the right branch.