Why WordPress Looks for .htaccess in the Wrong Directory When Using WP_HOME and WP_SITEURL

When you configure WP_HOME and WP_SITEURL in your WordPress wp-config.php file, especially when they point to different URLs or when WordPress is installed in a subdirectory but served from the root, WordPress might appear to “look for .htaccess in the wrong directory.” This behavior isn’t a bug, but rather a consequence of how WordPress determines its file system paths and how web servers process rewrite rules.

Here’s a breakdown of why this happens:

1. WP_HOME and WP_SITEURL Define URLs, Not File Paths

• WP_HOME: This constant defines the URL of your WordPress site’s home page. It’s what people type into their browser to reach your site.
• WP_SITEURL: This constant defines the URL where your WordPress core files are located.

The crucial point is that both are URLs, not file system paths. WordPress uses these URLs for generating links, redirects, and determining the public-facing address of your site. It doesn’t directly use them to locate files on the server’s file system for .htaccess purposes.

2. WordPress Relies on its Internal Path Detection

When WordPress needs to generate its .htaccess rules (e.g., when you save permalinks), it primarily relies on its internal logic to determine the absolute file system path to its root installation. This logic often involves:

• ABSPATH: This constant, defined in wp-config.php, is the absolute file system path to the WordPress installation directory. This is the primary determinant for where WordPress expects the .htaccess file to reside.
• Server Variables: WordPress also inspects server variables like $_SERVER['SCRIPT_FILENAME'] or $_SERVER['DOCUMENT_ROOT'] to infer its location relative to the web server’s document root.

3. The Discrepancy Between URL and File System Structure

The “wrong directory” perception arises when WP_HOME and WP_SITEURL are used to create a URL structure that differs from the actual file system structure. Common scenarios include:

• WordPress in a Subdirectory, Served from Root:
  • File System: /public_html/wordpress/ (where WordPress core files are)
  • WP_SITEURL: http://example.com/wordpress
  • WP_HOME: http://example.com
  • In this setup, WordPress’s core files are in /public_html/wordpress/. When it generates the .htaccess file, it will try to place it in /public_html/wordpress/ because that’s where ABSPATH points. However, the web server (Apache) will be looking for rewrite rules in the DocumentRoot (e.g., /public_html/) because WP_HOME points there, and that’s the URL being accessed. You then typically need a separate .htaccess in the root (/public_html/) to redirect requests to the WordPress subdirectory.
• Symbolic Links or Aliases: If you’re using symbolic links or Apache aliases to serve WordPress from a different URL than its physical location, WordPress’s internal path detection might still point to the physical location, while the web server’s interpretation of the URL leads it to look elsewhere for .htaccess.

4. How Apache (and other web servers) Processes .htaccess

Web servers like Apache process .htaccess files based on the actual file system path of the requested resource.

• When a request comes in for http://example.com/, Apache looks for .htaccess in the DocumentRoot (e.g., /public_html/).
• If the request is for http://example.com/wordpress/, Apache looks for .htaccess in /public_html/wordpress/.

The server doesn’t “know” about your WP_HOME or WP_SITEURL settings; it only knows about the incoming URL and its mapping to the file system.

5. The Role of the Root .htaccess (for subdirectory installs)

For the “WordPress in a subdirectory, served from root” scenario, the solution is to have two .htaccess files:

1. Root .htaccess (e.g., in /public_html/.htaccess): This file contains a few lines to redirect all requests to the WordPress subdirectory’s index.php. This is what the web server sees first.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L]
</IfModule>
# END WordPress

2. WordPress .htaccess (e.g., in /public_html/wordpress/.htaccess): This file is generated by WordPress itself when you save permalinks. It contains the specific rewrite rules for your permalink structure.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wordpress/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L]
</IfModule>
# END WordPress

(Note: The RewriteBase and RewriteRule paths will reflect the subdirectory).

1. (Note: The RewriteBase and RewriteRule paths will reflect the subdirectory).

Conclusion

WordPress isn’t “looking for .htaccess in the wrong directory” in a faulty way. It’s placing the .htaccess file in the directory where its core files reside (as determined by ABSPATH and internal path detection). The “wrong directory” perception arises from the common practice of serving WordPress from a different URL than its physical installation directory, requiring a separate .htaccess file at the web server’s document root to handle the initial URL rewriting. Understanding the distinction between URL configuration (WP_HOME, WP_SITEURL) and file system paths (ABSPATH) is key to troubleshooting these scenarios.