WordPress, plugins and the hosting control panel all write to the .htaccess file. If a plugin leaves an incorrect line in it, or a typo creeps in whilst editing it manually, the website will return a 500 error, or the subpages will return a 404 error. In such cases, the quickest solution is to reset the file to its default state, as this will reveal within a few minutes whether this is indeed the cause of the error.

We tested these steps in October 2026 on an aWh cPanel hosting test account, using WordPress 7.1. A single incorrect line in the file caused the entire website to display a 500 error.

When is this helpful?

• 500 Internal Server Error following the installation or removal of a plugin, or after manually editing a file.
• The homepage works, but the subpages return a 404 error.
• A redirect loop (‘too many redirects’) caused by a plugin or a manual rule.

If the error was caused by an update, please first refer to the article ‘500 error after plugin update’, as the cause of the error in such cases is usually not the .htaccess file.

What will you lose if you reset it to its default settings?

The file does not only contain WordPress rules. On a cPanel hosting account, you may find sections such as:

• # BEGIN cPanel-generated php ini directives: cPanel sets these, including the location of the PHP error log. Without them, in our test, the error log was written to the error_log file in the directory of the running PHP file, rather than to ~/logs/php.error.log. The PHP version remained unchanged: this is managed via the ‘Select PHP Version’ interface.
• RewriteCond/RewriteRule lines outside the WordPress block: for example, redirects set up on the cPanel Redirects page.
• Plugin blocks: rules for caching and security plugins, usually marked with their own # BEGIN. Be careful with the # Wordfence WAF block: the website works without it, but in our test, the Wordfence firewall stopped working without us noticing.
• Custom rules: lines added, for example, to block bots or ban IP addresses.

Therefore, do not delete the old file; instead, rename it: you can copy the useful parts back later.

1. Rename the old file

1. Open the cPanel File Manager page and navigate to the WordPress root directory. For the main domain, this is public_html; for other domains, it is the Document Root shown on the Domains page (What is my website’s root directory?).
2. If you cannot see the .htaccess file, enable the display of hidden files.
3. Select the file, click the ‘Rename’ button and give it a name that includes the date, for example .htaccess-2026-10-30.bak

The same applies to SSH:

cd ~/public_html
mv .htaccess .htaccess-$(date +%F).bak

On the web hosting platform, you can do the same via the File Manager menu option or via FTP.

Next, open the website. If the home page and the admin interface load, the error was in the old file. In this case, the subpages may still return a 404 error until you create the new file.

2. Create a new file

The simplest method is via the admin interface: go to the Settings › Permalinks page and, without making any changes, click the ‘Save Changes’ button. WordPress will then create the .htaccess file with its own block. This only happens if you are not using the ‘Simple’ structure; in that case, the file is not required.

You can also create it manually if the admin interface is unavailable. In File Manager, use the ‘File’ button to create a file named exactly .htaccess, open it using the ‘Edit’ button, and paste in the default WordPress content:

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

If WordPress is located in a subdirectory (for example, pelda.hu/blog), set the RewriteBase / line to RewriteBase /blog/ and the final RewriteRule line to /blog/index.php.

It can be regenerated using WP-CLI without the admin interface, but the wp rewrite flush --hard command itself only displays this warning: Regenerating a .htaccess file requires special configuration, and does not create the file. To do this, you need to temporarily place a wp-cli.yml file in your WordPress directory:

printf 'apache_modules:\n  - mod_rewrite\n' > wp-cli.yml
wp rewrite flush --hard
rm wp-cli.yml

When modifying the structure via WP-CLI, the wp rewrite structure command returns an error on aWh’s cPanel servers due to proc_open being disabled; however, the setting is saved. The error is described in the article on using WP-CLI.

3. Check the website

Open the home page, a post, a page and the admin interface. If the error has been resolved, you can restore the rules. If not, the old file was not to blame: rename it and continue searching (see the end of the article).

4. Re-enable the necessary rules

Open the .bak file and copy back only what you need, one section at a time, reloading the website after each step. Place the blocks before the line # BEGIN WordPress, as WordPress may overwrite its own block.

1. The cPanel PHP block: copy back the section between # BEGIN cPanel-generated php ini directives and # END cPanel-generated php ini directives, including the two marker lines.
2. Redirects: copy the lines back or re-enter them on the Redirects page.
3. Our own rule: if the error reoccurs after a particular line, that is the line causing the error.
4. Rules for plugins: do not copy these back manually. Disable and then re-enable the relevant plugin, or save its settings again, so that its own block is rewritten. If the error returns after enabling a plugin, that plugin is the cause. For the Wordfence firewall, you must run the wizard again.

Finally, delete the .bak file or download it for your own use, as it does not need to remain in the folder accessible via the web.

Restoring an old file

If you do need the old file, rename the new one (for example, to .htaccess-uj.bak) and rename the dated file back to .htaccess.

If the reset did not help

• Check the error log: the Errors page in the cPanel Guide section or the file ~/logs/php.error.log.
• Read the articles on error 500, the white screen and the PHP memory limit.
• Enable debug mode.

The general rules for editing the file are set out in the article on the .htaccess file, whilst our blog post on .htaccess redirects explains the redirect patterns.