How to Edit .htaccess on the Site Level or Add Rules Globally

In “How to Stop High Server Load from Distributed Botnets, Scrapers, and Database Queue Locks” we talked about how to fix your high server loads. That included adding rules to your site’s .htaccess file, or updating the rules globally. If you don’t know how to do that yet, this guide is for you.

Crucial First Step: Make a Backup

Before touching .htaccess, always make a copy. A single typo in this file will cause a “500 Internal Server Error” and take your entire website offline.

Method 1: Using the Terminal (Recommended for Speed)

If your server load is high, the terminal is more reliable than a web interface.

1. Log in to your server via SSH (using Putty, Terminal, or the WHM Terminal).
2. Navigate to your website’s root directory. Replace username with your actual cPanel username: cd /home/username/public_html
3. Check if the file exists. Because it starts with a dot, it is a hidden file. Use ls -la to see it: ls -la .htaccess
4. Create a backup copy: cp .htaccess .htaccess.bak
5. Open the file in a text editor (Nano is easiest): nano .htaccess
6. Edit the file: Use your arrow keys to move to the very top. Paste your rules.
7. Save and Exit:
   • Press Ctrl + O (to Write Out/Save).
   • Press Enter to confirm the filename.
   • Press Ctrl + X to exit the editor.

Method 2: Using cPanel File Manager (GUI)

If you prefer a visual interface, use the cPanel dashboard.

1. Log in to cPanel for the specific domain.
2. Open “File Manager” (found under the “Files” section).
3. IMPORTANT: Show Hidden Files.
   • By default, files starting with a dot (like .htaccess) are hidden.
   • Click the Settings button in the top right corner.
   • Check the box for “Show Hidden Files (dotfiles)”.
   • Click Save.
4. Navigate to public_html. (or www) Look for the .htaccess file in the list.
5. Create a backup: Right-click the file and select Copy. Give it a name like .htaccess-backup.
6. Edit the file: Right-click the original .htaccess and select Edit.
7. Paste your rules at the top and click Save Changes in the top right.

Method 3: WHM “Global” Apache Configuration (Advanced)

If you want to apply these blocks (like the Autodiscover or WordPress blocks we discussed) to every single website on your server at once, you don’t edit a .htaccess file. Instead:

How to apply the “Shield” in WHM

1. Log into WHM.
2. Go to Apache Configuration > Include Editor.
3. Under Pre VirtualHost Include, select All Versions.
4. Paste your RedirectMatch rules there.
5. Click Update and then Restart Apache.

Result: You have now protected every single domain on your server with one click, and it’s more resource-efficient than putting it in 50 different .htaccess files.

How to Tell if the Update Worked

After saving the file and updating your settings, visit your website in a browser.

• If the site loads: The syntax is correct.
• If you get a 500 Error: You made a typo. Restore your backup, or edit again to fix it. If you edited via the terminal, go back to the terminal and restore your backup:
  cp .htaccess.bak .htaccess (This instantly brings the site back up).

What is the difference between Pre Main Host Include vs Pre Virtual Host Include or Post Virtual Host Include?

Choosing between these depends on when you want Apache to process the rule. Think of the Apache configuration like a funnel: it starts with global server settings and narrows down to specific website settings.

For the attack mitigation rules we discussed (blocking xmlrpc.php, autodiscover, etc.), Pre-VirtualHost is almost always the best choice.

Here is the breakdown of why and how to choose:

1. Pre-Main Include (The “Foundation”)

• When it runs: Before Apache even loads the definitions for your websites (VirtualHosts).
• What it’s for: Settings that affect the Apache “engine” itself.
• Use this for:
  • Changing the server’s timeout settings.
  • Setting global memory limits.
  • Configuring custom logging formats that apply to the whole server.
• Why NOT for blocking: If you put a RedirectMatch here, it usually works, but it’s less efficient because the server hasn’t even “sorted” the traffic yet.

2. Pre-VirtualHost Include (The “Shield” – RECOMMENDED)

• When it runs: After the main server settings are loaded, but BEFORE the server looks at the specific configuration for example.com or mysite.com.
• What it’s for: Global rules that you want to apply to every single domain on the server without exception.
• Why use this for attacks:
  • It is the most efficient.
  • It catches the “bad” traffic before Apache wastes energy looking up which specific user account the request belongs to.
  • It overrides almost everything. If a bot hits a domain that doesn’t even exist yet, this will still block it.
• Best for: The RedirectMatch 404 rules for xmlrpc.php, wp-login.php, and autodiscover.xml.

3. Post-VirtualHost Include (The “Safety Net”)

• When it runs: AFTER all the individual website configurations have been loaded.
• What it’s for: Rules that you want to apply globally, but you want to give individual websites the chance to handle things their own way first.
• Why use this: Use this if you have 100 sites and you want a specific rule for all of them, BUT you want to allow a specific site owner to override that rule in their own .htaccess file.
• Risk: If a website has a very broad “Catch-All” rewrite rule in their .htaccess, the traffic might never reach your “Post-VirtualHost” rule.

Selection	When it triggers	Best Used For…
Pre-Main	Before any websites load	Server-wide performance tweaks (Timeouts, KeepAlive).
Pre-VirtualHost	Before individual site rules	Security blocks (The “Shield”). Use this to stop botnets globally.
Post-VirtualHost	After individual site rules	Fallback rules or settings you want site owners to be able to override.

---

Related: How to Whitelist Googlebot, Bingbot in CSF

---

Looking for a website builder that is flexible enough for a developer but easy enough for a beginner? Learn more about UltimateWB! We also offer web design packages if you would like your website designed and built for you.

Got a techy/website question? Whether it’s about UltimateWB or another website builder, web hosting, or other aspects of websites, just send in your question in the “Ask David!” form. We will email you when the answer is posted on the UltimateWB “Ask David!” section.