.htaccess Generator for WordPress

Recovery Guide

JA

Back Up Before Making Changes

A typo in .htaccess can directly cause a 500 Internal Server Error (site down) . Always take a backup before editing.

Examples of backup methods:

  • Download .htaccess to your local machine via an FTP client
  • Create a copy with a different name in the server's file manager (e.g. .htaccess.bak )
  • Take a snapshot using a backup plugin (e.g. UpdraftPlus)

Even if your site breaks, a backup lets you recover in minutes. Never edit without a backup.

Recovery Steps via FTP / File Manager

Emergency recovery procedure when a .htaccess misconfiguration causes a 500 error on your site.

Steps

Step Action Notes
1 Connect via an FTP client or the server's file manager Since the WordPress admin panel is inaccessible, connect directly to the server
2 Rename .htaccess inside public_html/ (or www/ ) Rename to something like _htaccess . Renaming (not deleting) lets you review it later
3 Visit your site and confirm it is back up If the site loads, .htaccess was the cause. WordPress permalinks may temporarily break
4 Open the renamed _htaccess and identify the problematic entry Comment out lines one by one (add # at the start) to isolate the cause
5 Once fixed, rename the file back to .htaccess Note that the filename has no extension. Some FTP clients require a setting to display hidden files (those starting with . )

How to Show Hidden Files in FTP Clients

Because .htaccess starts with . , it is a hidden file and may not be visible by default in some FTP clients.

Client How to Enable
FileZilla "Server" menu → "Force showing hidden files"
Cyberduck Preferences → "Browser" → "Show hidden files"
Server File Manager Open "File Manager" from your hosting control panel and enable the "Show hidden files" option

How to Identify the Problematic Entry

Binary Search Debugging

When there is a lot of content, the most efficient approach is to comment out half the file and narrow down which half contains the problem.

# Comment out the bottom half of the file to check
# ↓ Comment out everything below this line

# <IfModule mod_headers.c>
#     Header always set ...
# </IfModule>

Checking the Error Log

The cause of a 500 error is recorded in the server's error log. You may be able to access it from your hosting control panel.

Common error examples:

Error Message Cause Solution
Invalid command 'Header' mod_headers is disabled Check that it is wrapped in <IfModule mod_headers.c> . Contact your host to enable mod_headers
Invalid command 'RewriteEngine' mod_rewrite is disabled Check that it is wrapped in <IfModule mod_rewrite.c>
Options not allowed here The hosting provider restricts the Options directive Delete or comment out the Options -MultiViews -Indexes line
AuthType not set Basic Auth configuration is incomplete Check that AuthType , AuthName , and AuthUserFile are all present
Unable to open password file The path to .htpasswd is incorrect Verify the full path specified in AuthUserFile

What NOT to Do

Don't Reason
Edit .htaccess directly without a backup You won't be able to revert if something goes wrong
Edit inside the # BEGIN WordPress — # END WordPress block WordPress overwrites this block automatically when saving permalink settings, so your changes will be lost
Manually edit blocks generated by plugins (Wordfence, EWWW Image Optimizer, etc.) The plugin will overwrite your changes, and its integrity check may cause unexpected behavior
Apply a large batch of settings all at once on a production site It becomes difficult to identify the cause when a problem occurs. Add settings incrementally and test each time
Completely delete .htaccess WordPress permalinks will stop working. Disable it by renaming (e.g. to _htaccess ) instead

Re-configuring WordPress Permalinks After Recovery

After renaming .htaccess back in the recovery procedure, if the # BEGIN WordPress block generated by WordPress is missing, permalinks will not work.

Steps to Fix

  1. Log in to the WordPress admin panel
  2. Go to "Settings" → "Permalinks"
  3. Click "Save Changes" without making any changes
  4. WordPress will automatically write the # BEGIN WordPress block back into .htaccess

Always place custom rules above (outside of) the # BEGIN WordPress block. Placing them inside the block will cause WordPress to overwrite and erase your changes.

← Back to Generator