If Apache reports Order not allowed here while loading a WordPress site that uses Akismet, the problem is usually not Akismet itself. Your .htaccess contains the legacy Order, Allow or Deny directive, but the Apache <Directory> block for the site does not permit the Limit override class. Add Limit to that directory’s AllowOverride value, test the configuration, and reload Apache. On Apache 2.4, migrating the rule to Require is the cleaner long-term fix when you can safely rewrite it.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Do not enable AllowOverride All globally just to suppress one error. Keep the change limited to the WordPress document root, or ask your hosting provider to make the narrowly scoped change.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →What “Order not allowed here” means
Apache reads .htaccess files only when the server configuration allows the directive classes used in those files. The legacy access-control directives Order, Allow and Deny belong to Apache’s Limit override class. If the relevant directory permits only FileInfo, or disables overrides entirely, Apache rejects a line such as Order Allow,Deny before WordPress can finish serving the request.
The result can look like an Akismet failure because the error appears after a plugin update, a WordPress migration or a change to the generated .htaccess. The underlying failure is Apache’s directive policy: the file asks for an override class that the site’s directory configuration does not grant. The exact Akismet template and the Apache version on the affected site determine which repair is safest, so inspect both before changing production files.
#1 Best Overall
Check the scope before editing anything
Back up both configuration layers
Save a copy of the current WordPress .htaccess and the Apache virtual-host configuration. Keep the backup outside the web root and record the original file permissions. If a change causes a 500 response or prevents Apache from reloading, you can restore the previous version instead of trying to reconstruct it under pressure.
Find the document root’s <Directory> block
AllowOverride is valid in an Apache <Directory> section. It is not the setting to place in a <Location> or <Files> section. Identify the directory that physically contains the WordPress installation, for example:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →<Directory "/var/www/example.com/public_html">
AllowOverride FileInfo
</Directory>Do not assume that the first directory block you find controls the site. A virtual host, an included configuration file or a more specific directory section may apply instead. Confirm that the path matches the WordPress document root and that the block belongs to the virtual host serving the failing domain.
Confirm what the error names
Look at the Apache error log for the complete message and the file-and-line reference. A message that explicitly names Order or says order not allowed here points to the legacy authorization rule. If the log instead reports a missing module, a syntax error, or a permissions failure, solve that separate problem rather than changing AllowOverride blindly.
Choose the least disruptive repair
| Option | Use it when | Change | Main trade-off |
|---|---|---|---|
| Permit the legacy class | The existing .htaccess intentionally uses Order, Allow or Deny, and you need a quick compatible repair. |
Add Limit to the site’s AllowOverride value, such as FileInfo Limit. |
It keeps deprecated authorization syntax in service. |
Convert to Require |
The server is Apache 2.4 and you can verify the rule’s intended access policy. | Replace the legacy access logic with the Apache 2.4 authorization directives. | A careless rewrite can change who is allowed or denied. |
| Ask the host to change it | You cannot edit the virtual-host or <Directory> configuration on shared or managed hosting. |
Request a narrowly scoped Limit allowance or a safe conversion to Require. |
You must wait for the provider and follow its configuration policy. |
The correct choice depends on the Apache version, whether you control the directory configuration, and whether the file contains old or modern authorization syntax. A narrowly scoped directory change is safer than enabling every override class for the entire server.
Repair a legacy rule with AllowOverride Limit
1. Inspect the existing value
Read the active AllowOverride line. If it says only FileInfo, Apache will allow directives in that class but will reject Order. If overrides are disabled, the file’s directives will also be rejected. Preserve any class already required by the site; do not replace the value with Limit alone unless you have confirmed that no other directives need the previous class.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
2. Add the required class in the matching directory
For a legacy file that genuinely needs Order, the usual narrowly scoped adjustment is:
<Directory "/var/www/example.com/public_html">
AllowOverride FileInfo Limit
</Directory>Limit is the class that authorizes Order, Allow and Deny. Keep the change in the WordPress document root’s block. Do not put it in a filesystem-root block merely because that is easier to find, and do not use AllowOverride All as a generic workaround.
3. Save the file and check for conflicting blocks
After editing, verify that a later include or a more specific <Directory> section is not overriding the value. On a multi-site server, check that the path does not accidentally grant the class to unrelated applications. The goal is to authorize the one site and directory that need the legacy rule.
Validate Apache before reloading
Always run a syntax check before asking Apache to reload. Apache documents both of these commands for checking configuration syntax without starting the server: apachectl configtest and apachectl -t.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsapachectl configtest
# or
apachectl -tA successful check normally reports Syntax OK. If it reports an error, do not reload. Correct the named file and line, then run the test again. A syntax check confirms that Apache can parse the configuration; it does not prove that the access policy is what you intended, so test the affected WordPress URL as well.
Reload using the host’s normal procedure
Once the test succeeds, reload or restart Apache using the service procedure provided by the operating system or hosting platform. Avoid an improvised stop/start on a production server when a graceful reload is available. Request the page that previously failed, then inspect the error log. The original order not allowed here message should no longer appear for that request.
Modernize the rule on Apache 2.4
Why the old directives are discouraged
Apache 2.4 supplies Order, Allow and Deny through the mod_access_compat module. They are deprecated. Apache’s preferred authorization system uses Require directives instead.
A rule whose intent is to allow every client can use:
Require all grantedIP-based and host-based restrictions can use Require ip and Require host, respectively. The exact replacement depends on what the old rule was meant to do. Read the complete legacy block before converting it; an Order line by itself does not reveal whether the rule was intended to create a public endpoint, deny a network, or combine allow and deny lists.
Do not mix authorization systems casually
Do not combine old Order/Allow/Deny directives and new Require rules in the same access-control logic unless you understand Apache’s merging behavior. Apache documents the compatibility module for older configurations but discourages mixing the two systems. During a migration, convert one complete access-control block, test the intended allowed and denied requests, and remove the obsolete directives from that block.
When conversion is not appropriate
If a plugin or a vendor-managed file will regenerate the legacy rule, a temporary Limit allowance may be less disruptive than repeatedly rewriting the file. Treat that as a compatibility measure, not proof that the deprecated syntax is the preferred design. Plan the conversion when you can control the generated configuration and verify its behavior.
Why the error can appear after an Akismet or WordPress change
A plugin update, migration, restore or hosting move can rewrite .htaccess or place the site on a server with stricter override settings. If the regenerated file contains Order while the new host permits only FileInfo, the next request exposes the mismatch. The same symptom can occur when a previously permissive virtual-host configuration is replaced during a migration.
Free tools Windows power users keep installed
One-click scans. No signup required.
The exact Akismet-generated template and the affected site’s Apache version are not established here. What is established is the Apache behavior: a bundled legacy rule fails when its directory allows only classes such as FileInfo, or when overrides are disabled. A matching error report shows order not allowed here with AllowOverride FileInfo and reports that enabling Limit resolves the legacy rule. Verify your own file and server version before applying that pattern.
Troubleshooting branches
The error remains after adding Limit
- Confirm that you edited the directory block serving the failing virtual host, not a similarly named site.
- Run
apachectl configtestagain and check that the edited file is actually included. - Look for a more specific
<Directory>block or an included file that overrides the value. - Check the error log for a different directive or line number; the original message may have been replaced by a second configuration problem.
- Make sure Apache was reloaded after the successful syntax check and that the request is reaching that Apache instance rather than another frontend or container.
The site returns a 500 error after the change
Restore the backed-up configuration if Apache will not pass its syntax test. If the test passes but WordPress returns 500, inspect the error log for the exact directive and file. A malformed .htaccess, an unsupported module, or a separate PHP failure can produce the same HTTP status without being an AllowOverride problem.
You cannot edit the <Directory> block
On shared or managed hosting, the provider may be the only party able to change virtual-host configuration. Send support the full error-log line, the document-root path, the current AllowOverride value if visible, and the relevant .htaccess lines. Ask for either the Limit override class on that document root or a conversion of the rule to Apache 2.4 Require syntax. Do not attempt to work around the restriction by enabling broad overrides in a file you do not control.
The host uses a non-Apache web server
The directives discussed here are Apache directives. If the site is behind another web server or a proxy, identify which component is reading .htaccess and obtain that platform’s supported configuration method. Changing an unused Apache file will not repair an error generated elsewhere.
Quick Recap
Security and maintenance checks
- Scope the permission: grant
Limitonly in the directory that needs legacy access directives. - Preserve existing classes: add
Limitalongside required values such asFileInforather than deleting them without checking their purpose. - Prefer explicit authorization: on Apache 2.4, use
Requirewhen you can reproduce the old policy safely. - Keep systems consistent: do not leave half-converted access rules that combine compatibility directives with
Requireunexpectedly. - Test both outcomes: request a URL that should work and, where the rule is restrictive, verify that a request that should be denied is actually denied.
- Record the change: note the date, file, directory path and reason so a later plugin update or migration does not silently undo the fix.
Quick decision checklist
- Back up
.htaccessand the applicable Apache virtual-host configuration. - Read the error log and confirm that
Order,AlloworDenyis the rejected directive. - Locate the
<Directory>block for the WordPress document root. - Check whether the site permits only
FileInfoor disables overrides. - If the legacy rule must remain, add
Limitin that block; do not enableAllowOverride Allglobally. - If the server is Apache 2.4 and the policy is understood, convert the complete rule to
Require. - Run
apachectl configtestorapachectl -t. - Reload Apache using the normal service method.
- Request the affected WordPress URL and inspect the log for confirmation.
- If you lack configuration access, give the host the exact error and request a scoped change.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
