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 →The safest WordPress .htaccess repair is: back up the file, rename it temporarily to isolate the fault, test the site, then regenerate rewrite rules from Settings > Permalinks. If posts still return 404, verify that the site is running Apache with mod_rewrite and that the WordPress rules are present. A missing file, wrong permissions, hidden dotfile, subdirectory install, or a non-Apache server requires a different fix.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What the WordPress .htaccess file does
.htaccess is Apache HTTP Server’s per-directory configuration file. A standard WordPress installation uses the copy in the site root to route human-readable URLs such as /news/example-post/ through index.php. Those rewrite rules are what make “pretty” permalinks work; the file may also contain directives added by a host, security tool, cache system, or another plugin.
As an Amazon Associate I earn from qualifying purchases.
The file is relevant only when the web server allows Apache-style per-directory overrides. An nginx or IIS site normally uses a different configuration format, so repeatedly editing a WordPress .htaccess file will not repair routing on those servers. Identify the server before changing configuration.
Choose the repair path from the symptom
| Symptom | First action | What to verify next |
|---|---|---|
| HTTP 500 immediately after editing | Back up and rename .htaccess to a temporary name such as .htaccess_old. |
Test the site, inspect Apache/PHP error logs if it still fails, then regenerate the file if renaming fixes it. |
| Posts or pages return 404, but the home page works | Open Settings > Permalinks and save the existing structure. | Confirm Apache mod_rewrite, the WordPress rule block, and host permission for overrides. |
| WordPress says the file is not writable | Copy the rule block displayed on the Permalinks screen manually. | Review file ownership and permissions with the hosting provider or server administrator. |
No .htaccess is visible |
Enable hidden-file display in the SFTP/FTP client or host file manager. | Check whether the server is nginx or IIS and whether WordPress is installed in a subdirectory. |
| Site is on managed hosting | Use the host’s documented configuration method before changing Apache settings. | Ask support whether mod_rewrite, overrides, permissions, and custom directives are permitted. |
Prepare safely before editing
- Confirm the affected site and directory. Locate the document root that contains
wp-admin,wp-content, andwp-includes. A file in a parent directory can affect more than the intended installation. - Make a copy. Download the current root
.htaccessthrough SFTP, FTP, or the host file manager, or duplicate it in place. Keep the original content, including directives outside the WordPress markers. - Record the current permalink structure. In the dashboard, note the selected option under Settings > Permalinks. This makes it easier to confirm that a repair did not silently change URL formats.
- Keep an alternate access route. Have SFTP, FTP, or the hosting file manager ready before testing. If a malformed directive causes a 500 response, the dashboard may be inaccessible.
Do not delete the only copy. Renaming is reversible; deletion is not.
Fix an HTTP 500 caused by .htaccess
WordPress identifies a corrupted .htaccess file as the most likely explanation for this particular failure. A syntax error, unsupported directive, invalid option, or rule inserted by a plugin can make Apache reject the request before WordPress runs.
1. Rename the file to isolate it
- Connect with SFTP, FTP, or the host file manager.
- In the WordPress document root, rename
.htaccessto a temporary name such as.htaccess_old. Do not add an extension that your file manager silently hides. - Load the home page, an administrator URL, and one previously failing page.
If the site loads after the rename, the old file contains the fault or a directive your server does not support. If the 500 remains, restore the filename and investigate other causes, such as PHP errors, a failed plugin, a host outage, or a server-level configuration problem. Apache and PHP error logs are the next evidence to collect; the exact log location depends on the host.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
2. Regenerate rather than repairing unknown lines
When renaming resolves the error, leave the old file outside the active name and open Settings > Permalinks. Visiting that screen triggers a rewrite-rule flush; saving the screen also requests a rewrite-rule update. If WordPress can write to the root file, it creates a clean block for the current installation.
3. Reintroduce custom directives cautiously
If the old file contained redirects, caching rules, access restrictions, or headers that the site needs, add them back in small groups after the basic WordPress block works. Test after each change. A 500 that returns after one group identifies the directive family to remove or have the host translate into supported server syntax.
Regenerate .htaccess from the WordPress dashboard
- Sign in to WordPress and go to Settings > Permalinks.
- Do not change the selected permalink option unless changing URL structure is intentional.
- Click Save Changes. Even when no option changes, opening the screen flushes rewrite rules.
- Visit a post, page, category archive, and the home page in a private browser window.
- Return to the file manager and confirm that the root
.htaccesscontains the current WordPress block.
WordPress documents that the file can be written automatically when permissions allow. If the screen displays a message saying the file is not writable, use the manual method below instead of repeatedly clicking Save.
Copy the standard rule block manually
For a WordPress installation in the web root, the baseline block published in the WordPress Apache HTTPD/.htaccess handbook is:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress- Open the root
.htaccessin a plain-text editor supplied by the file manager or SFTP client. - Replace a damaged WordPress block with the block shown on your own Permalinks screen. That generated text takes precedence over a copied example when the installation has unusual paths or server settings.
- Keep host-specific directives and legitimate custom rules outside the
# BEGIN WordPressand# END WordPressmarkers. - Save as exactly
.htaccess, with no.txtsuffix, and test the site immediately.
Do not paste Apache directives into a PHP file or into wp-config.php. Do not combine several historical WordPress blocks; duplicate rewrite sections make troubleshooting harder and can produce unexpected routing.
When pretty permalinks return 404
A working home page with 404 responses for posts and pages usually means the request is not reaching WordPress through the expected rewrite rules. WordPress lists Apache’s mod_rewrite module as a prerequisite for pretty permalinks.
Rank #3
Check the server module and override policy
- Ask the host or server administrator whether the site runs Apache HTTP Server and whether
mod_rewriteis enabled. - Confirm that the virtual host permits the site’s
.htaccessdirectives. A host can disable per-directory overrides even when Apache andmod_rewriteare installed. - After a server-level change, revisit Settings > Permalinks and save once to flush the rules.
Check the active block
Make sure the file is in the document root, not only in a local computer’s download folder. Confirm that the WordPress markers and the conditions excluding real files and directories are present. A rule that routes every request to the wrong path can create a site-wide 404 or an administrative redirect loop.
Check for a changed URL structure
If the site was moved, switched from plain to pretty permalinks, or had its directory name changed, the old rules may still point at the previous location. Select the intended structure, save the Permalinks screen, and test both old and new URLs so that you know whether redirects are required separately from rewrite routing.
Handle a “.htaccess is not writable” warning
WordPress cannot update the file when the process lacks permission to write it. The warning does not necessarily mean the rules are wrong; it means the automatic regeneration step could not complete.
- Copy the exact rewrite block shown beneath the warning on the Permalinks screen.
- Open the root file through SFTP, FTP, or the host file manager.
- Replace only the damaged WordPress section, preserving required directives outside its markers.
- Save and retest the home page and several pretty-permalink URLs.
- Ask the host to review ownership and permissions if you cannot save, if the file repeatedly becomes unwritable, or if changing permissions would affect other sites.
Permission changes should be coordinated with the host or server administrator. A quick, overly broad permission change can expose configuration data or be reset by the hosting platform.
Find a missing .htaccess file
Dotfiles are hidden by default in many FTP clients and file managers. Turn on an option such as Show hidden files, reconnect, and look again in the directory containing wp-admin. If no file exists, visiting the Permalinks screen may create one when the server allows WordPress to write it; otherwise create it as a plain-text file and paste the generated block manually.
Before creating anything, identify the server type. nginx does not process Apache .htaccess files, and IIS uses its own configuration mechanism. On those platforms, request the host’s WordPress rewrite configuration or follow its documented migration instructions rather than adding an ignored file.
Subdirectory installations and moved sites
A site installed at a path such as example.com/blog needs rewrite rules that match that installation path. The generated RewriteBase and the front-controller path must correspond to the subdirectory, not to the domain root. If the directory was renamed or WordPress was moved, update the WordPress and site URLs through the supported migration procedure, then visit Settings > Permalinks and save.
Keep separate the concerns of URL rewriting and database URL replacement. Correcting .htaccess cannot repair hard-coded links, serialized settings, or media URLs that still reference the old directory.
Plugin rules, redirects, and other custom directives
The WordPress block is only one part of many real-world files. A plugin or host may add redirects, authentication rules, cache headers, compression settings, or security directives. Those additions can fail after an Apache upgrade or when moved to a host with different modules.
- Compare the backed-up file with the regenerated file to identify non-WordPress additions.
- Restore custom sections one at a time, testing a front-end URL and the dashboard after each change.
- Remove duplicate redirect rules and rules that target an old domain, protocol, or subdirectory.
- When an error log names an unsupported directive, ask the host for an equivalent supported setting instead of guessing a replacement.
A redirect loop often comes from conflicting HTTP-to-HTTPS, www-to-non-www, or old-domain rules. Temporarily disabling the custom redirect section and testing the canonical URL helps separate that problem from WordPress’s internal rewrite block.
Managed hosting and server-side limits
Some managed hosts generate or lock configuration files, disallow arbitrary overrides, or apply rewrite rules at the virtual-host level. Follow the provider’s documented method before changing file ownership or Apache settings. When opening a support request, include:
- the exact URL and HTTP status code;
- the time the failure began and the last file change;
- whether renaming
.htaccesschanged the result; - the server type and PHP version if the host exposes them;
- the relevant Apache or PHP log excerpt with credentials and personal data removed;
- whether WordPress is installed at the domain root or in a subdirectory.
This gives the host enough context to check mod_rewrite, override policy, ownership, and server-level directives without asking you to make blind changes.
Verify the repair without creating a new outage
- Load the home page in a private window.
- Open one post, one page, one category or tag archive, and a search URL.
- Sign in to
/wp-admin/and open the Permalinks screen without changing the selected structure. - Check an image, a CSS file, and a JavaScript file to ensure real files are not being routed incorrectly.
- Test the site’s canonical HTTP/HTTPS and www/non-www versions if custom redirects are present.
- Watch the server error log while requesting a previously failing URL.
Only after these checks pass should you remove the temporary backup. Keep it until you are confident that redirects, plugin endpoints, REST requests, and scheduled callbacks still work.
Common mistakes to avoid
- Editing before backing up: you lose the only working custom rules and cannot compare the failure.
- Renaming the file but not testing: the rename is useful only if you request the failing URL while the file is inactive.
- Assuming every server reads .htaccess: nginx and IIS require different configuration formats.
- Changing permissions indiscriminately: ownership and access policies are host-specific and can create a security problem.
- Using a root rule block for a subdirectory install: paths and
RewriteBasemust match the actual installation. - Deleting custom directives with the WordPress block: redirects, cache behavior, or access controls may disappear even though permalinks recover.
- Repeating the dashboard flush on a non-Apache server: WordPress can regenerate text that the active server never reads.
Bottom line
Start with a backup, temporarily rename the root .htaccess, and test. If that removes the 500 error, regenerate the file through Settings > Permalinks and restore custom rules gradually. For 404 permalinks, verify Apache mod_rewrite, override policy, the generated block, and the installation path. If the file is hidden, unwritable, controlled by managed hosting, or irrelevant because the server is nginx or IIS, the host’s file and server configuration—not another WordPress dashboard refresh—is the correct next step.
Quick Recap
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.
