What direct access means and why you should block it

Direct access means someone visiting your WordPress site's backend files through a web browser instead of going through the WordPress dashboard. For example, instead of logging into wp-admin, they could try to load `wp-config.php` or `wp-settings.php` directly in their browser's address bar. These files contain database credentials, security keys, and other sensitive information that should never be visible to anyone outside your server.

Blocking direct access prevents attackers from reading configuration files, running PHP scripts meant only for WordPress to use, or uploading malicious files to directories that should only accept images or documents. It also stops bots from probing your site's structure and finding vulnerabilities. The protection works by telling your web server to refuse requests for certain file types and folders, so even if someone knows the exact path, they get an error instead of the file contents.

Key Takeaways

  • Add rules to your `.htaccess` file to block direct access to PHP files and sensitive WordPress directories like `/wp-admin` and `/wp-includes`.
  • If your host uses Nginx instead of Apache, you need to edit your server configuration file directly or ask your host to add the rules for you.
  • Disable PHP execution in upload directories so attackers cannot run malicious scripts even if they manage to upload files.
  • Protect your `wp-config.php` file specifically, since it contains your database password and security keys.
  • Test your changes by trying to visit a blocked file path in your browser — you should see a 403 Forbidden error.

Using .htaccess to block direct access on Apache servers

Most WordPress hosts run Apache web servers, which read instructions from a `.htaccess` file in your site's root directory. This file already exists on your site — it contains the rules that make WordPress permalinks work. You can add rules to it that block direct access to PHP files and folders.

Connect to your site using SFTP or your host's file manager. Navigate to the root folder (the one containing `wp-config.php`, `wp-content`, and `wp-admin`). Open `.htaccess` in a text editor and add these lines before the `# BEGIN WordPress` comment:

<FilesMatch "\.php$"> Deny from all </FilesMatch> <FilesMatch "^(index|wp-login|wp-cron)\.php$"> Allow from all </FilesMatch>

This rule blocks all PHP files from being accessed directly, then creates an exception for the three PHP files WordPress needs to load through the browser: `index.php` (which loads your front page), `wp-login.php` (the login page), and `wp-cron.php` (WordPress's scheduled tasks). Save the file and test by visiting `yoursite.com/wp-config.php` in your browser — you should see a 403 Forbidden error.

Protecting specific WordPress directories

Beyond blocking PHP files, you should also prevent direct access to directories that contain only WordPress code, not user-facing files. The `/wp-admin` and `/wp-includes` directories fall into this category — nothing in them should ever be loaded directly by a visitor.

Add these lines to your `.htaccess` file in the root directory:

<Directory ~ "^/wp-(admin|includes)"> Deny from all </Directory>

Some hosts do not allow `Directory` directives in `.htaccess`. If you get an error when you save, create a `.htaccess` file inside the `/wp-admin` folder itself and add `Deny from all` to it. Repeat for `/wp-includes`. This approach is less elegant but works on restrictive hosts.

Disabling PHP execution in upload directories

The `/wp-content/uploads` directory is where WordPress stores images, documents, and other files you upload through the media library. Attackers sometimes try to upload PHP files disguised as images, then run them by visiting the file directly. Blocking PHP execution in this folder prevents that attack even if the upload somehow succeeds.

Create a `.htaccess` file in `/wp-content/uploads` and add:

<FilesMatch "\.php$"> Deny from all </FilesMatch>

You can also add this rule to `/wp-content` itself to protect the entire folder and all subfolders. Do the same for `/wp-content/plugins` if your host allows it, though most plugins need some PHP execution to work, so test carefully after adding this rule.

Protecting wp-config.php separately

Your `wp-config.php` file contains your database password, database name, and security keys — the most sensitive information on your entire site. Even though the PHP-blocking rules above protect it, adding a specific rule for this file adds a second layer.

Add this to your root `.htaccess`:

<Files wp-config.php> Deny from all </Files>

This rule blocks access to `wp-config.php` specifically, regardless of how someone tries to reach it. WordPress itself reads this file from the server's file system, not through the web, so blocking web access does not break your site.

Configuring Nginx servers

If your host uses Nginx instead of Apache, `.htaccess` files do not work — Nginx reads a different configuration format. You will need to either edit your Nginx configuration file directly or ask your host to add the rules for you.

The Nginx equivalent of the PHP-blocking rules above looks like this and goes in your server block configuration:

location ~ \.php$ { deny all; } location ~ ^/(wp-admin|wp-includes) { deny all; } location = /wp-config.php { deny all; }

Most Nginx hosts provide a control panel where you can paste server configuration, or they offer to add rules for you if you submit a support ticket. Ask your host whether you can edit the configuration yourself or whether they need to do it. Do not attempt to edit Nginx configuration files directly on the server unless you are comfortable with server administration — a syntax error can take your site offline.

Testing your changes

After adding any blocking rules, test them to make sure they work and that your site still loads normally. Open your browser and try these URLs:

  • Visit your site's home page — it should load normally.
  • Visit `yoursite.com/wp-config.php` — you should see a 403 Forbidden error.
  • Visit `yoursite.com/wp-admin/` — you should see a 403 error (not the login page).
  • Visit `yoursite.com/wp-login.php` — the login page should load normally.
  • Try uploading an image through the WordPress media library and visiting it in your browser — it should display normally.

If your site stops loading or you see errors, the rules may have a syntax error or conflict with your host's configuration. Remove the changes, save, and try again. If you are unsure about the syntax, contact your host's support team — most can add these rules for you if you ask.

Frequently Asked Questions

Will blocking direct access break my WordPress site?

No. WordPress loads its files through the PHP interpreter on your server, not by requesting them through the web browser. Blocking direct web access only prevents visitors and bots from reading the files — WordPress itself continues to work normally. Your site's front page, admin dashboard, and all plugins will function as usual.

Do I need to block direct access if I use a security plugin?

Security plugins add another layer of protection, but they work differently — they monitor what happens after a request reaches WordPress, not before. Blocking direct access at the web server level is faster and stops attacks before they reach WordPress at all. Using both is more secure than using either alone.

What if I cannot edit .htaccess or my host uses Nginx?

Contact your host's support team and ask them to add direct access blocking rules to your server configuration. Most hosts can do this in a few minutes. Provide them with the rules you want added, or ask them to implement standard WordPress hardening. If they refuse, consider switching hosts — this is a basic security feature that any WordPress host should support.

Will these rules block legitimate bots like Google's crawler?

No. Google's crawler and other search engine bots request your site's pages normally through the web server, just like a visitor would. They do not try to access PHP files or WordPress system directories directly. Blocking direct access does not affect search engine indexing or any legitimate traffic.

Can I block direct access to other file types besides PHP?

Yes. You can block access to `.htaccess` files themselves, `.sql` database backups, or `.txt` files that might contain sensitive information. Add rules like `<FilesMatch "\.(htaccess|sql|txt)$">` to block them. However, focus on PHP files and WordPress directories first — those are the most commonly targeted.