Have you moved your WordPress website from a subdirectory such as /blog/ to your main domain, but your old blog URLs and RSS feeds are no longer working correctly?
This can happen when WordPress is installed in a subdirectory but configured to display the website from the root domain. An incorrect rewrite rule in your .htaccess file can make the problem worse by sending requests to the wrong location.
In this guide, I’ll explain a setup where the WordPress files remain inside the /blog/ directory while the website is accessible from the main domain. We’ll also look at how to configure the root index.php, handle old URLs, and test the RSS feed.
Understanding the Problem
I encountered this issue after changing my website address from a subdirectory to the root domain.
Before the change, the blog was accessible at:
https://www.example.com/blog/
After the change, I wanted the website to load from:
https://www.example.com/
However, I did not move the WordPress installation files. They remained inside the /blog/ directory.
After updating the website settings, the homepage and individual posts appeared to work. But when I tested some older URLs, I noticed unexpected behavior:
- The old
/blog/URL opened an unexpected page. - The old
/blog/feed/URL displayed an incorrect feed. - Some requests were being routed to the wrong location.
The problem was related to the rewrite configuration in the root .htaccess file.
What Changed in the WordPress Setup?
My website used the following configuration before and after the change:
| Setting | Before | After |
|---|---|---|
| WordPress files | /blog/ |
/blog/ |
| WordPress Address | https://www.example.com/blog |
https://www.example.com/blog |
| Site Address | https://www.example.com/blog |
https://www.example.com |
| Public website URL | /blog/ |
/ |
This configuration allows WordPress core files to remain in a subdirectory while visitors access the website through the root domain.
WordPress explains this arrangement in its official guide, Giving WordPress Its Own Directory.
Where the Problem Occurred
While checking the root .htaccess file, I found this rewrite rule:
RewriteRule ^(.*)$ blog/$1 [L]
At first glance, this rule looks harmless. It takes the requested path and internally rewrites it by adding the blog/ directory.
For example, a request for:
https://www.example.com/about/
can be internally rewritten to:
https://www.example.com/blog/about/
The problem is that this rule applies too broadly. It can also affect requests that already contain the blog/ path.
For example:
/blog/ → /blog/blog/
/blog/feed/ → /blog/blog/feed/
These rewritten paths are not necessarily the URLs WordPress expects. As a result, the request may reach the wrong page or feed endpoint.
Important: This rule is not a universal WordPress requirement. The correct rewrite configuration depends on your directory structure and server setup. Do not add a rule that blindly prefixes every request with blog/.
How to Fix the Problem
For this setup, WordPress remains installed in the /blog/ directory, but the public website is served from the root domain.
The following steps assume an Apache server using .htaccess. If your website uses Nginx, the rewrite configuration will be different.
Step 1: Remove the Incorrect Rewrite Rule
Open the root .htaccess file and look for the rule that adds blog/ to every requested URL:
RewriteRule ^(.*)$ blog/$1 [L]
Remove that rule if it is responsible for the incorrect routing in your setup.
Before editing the file, make a backup. Also check whether another plugin or server configuration is adding similar rewrite rules.
Step 2: Create an index.php File in the Root Directory
Since the WordPress core files are still inside /blog/, the root directory needs an index.php file that loads WordPress from that location.
Create or copy an index.php file into your website’s root directory. Its contents should be:
<?php
define( 'WP_USE_THEMES', true );
require __DIR__ . '/blog/wp-blog-header.php';
The important part is the path in the require statement. It tells PHP to load the WordPress bootstrap file from the /blog/ directory.
Make sure the path matches your actual WordPress installation directory. If WordPress is installed in a different folder, update the path accordingly.
Do not move the original WordPress core files just to make this configuration work. The root index.php is an entry point that loads the existing installation.
You can also refer to the official WordPress guide on running WordPress from its own directory for the complete setup instructions.
Step 3: Check the Root .htaccess File
For an Apache installation, the root .htaccess file must route public requests to the root index.php file while allowing existing files and directories to be accessed normally.
A typical WordPress rewrite block looks like this:
# 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
This is a standard WordPress-style rewrite block. Your actual root configuration may need to differ depending on your installation and existing server rules.
Do not simply overwrite your current .htaccess file with this example. Preserve any necessary redirects, security rules, and hosting-specific configuration.
For more information, see the official WordPress Apache and .htaccess documentation.
Step 4: Redirect Old URLs Carefully
After moving the public website URL to the root domain, you may still have old URLs indexed by search engines or saved by visitors.
For example, you may want these old public URLs to redirect:
/blog/to//blog/feed/to/feed/
For an Apache server, exact-path redirects can be configured using RedirectMatch:
RedirectMatch 301 ^/blog/?$ https://www.example.com/
RedirectMatch 301 ^/blog/feed/?$ https://www.example.com/feed/
Replace www.example.com with your actual domain.
Important: Because the WordPress installation still exists inside /blog/, do not create a broad redirect that sends every URL beginning with /blog/ to the root. That could interfere with access to WordPress files, the login page, administration, or other resources.
Use exact redirects only for old public URLs that should no longer be used. Test the redirects carefully and make sure your WordPress administration and required assets remain accessible.
A 301 redirect indicates that a resource has permanently moved. Apache also supports redirect rules through its mod_rewrite documentation.
Step 5: Verify WordPress Address and Site Address
Now open your WordPress dashboard and navigate to:
Settings → General
Check these two settings:
- WordPress Address (URL):
https://www.example.com/blog - Site Address (URL):
https://www.example.com
The WordPress Address identifies where the WordPress core files are installed. The Site Address is the public URL visitors use to access your website.
These values are intentionally different in this setup. Do not change both fields to the root domain when your WordPress core files are still inside /blog/.
You can read more about these fields in the official WordPress General Settings documentation.
Step 6: Refresh Permalink Settings
After updating the root entry point and rewrite configuration, log in to your WordPress dashboard.
Navigate to:
Settings → Permalinks
Review your permalink structure and click Save Changes.
This refreshes WordPress rewrite rules. It is especially important after changing the website’s URL configuration or modifying custom rewrite rules.
How to Test Whether the Blog and Feed Work
After making the changes, test both the website and its RSS feed. Do not rely only on whether a URL appears to load in your browser.
1. Test the Old Blog URL
Run this command from a terminal:
curl -I https://www.example.com/blog/
If you configured a permanent redirect for this exact URL, the response should include a status such as:
HTTP/2 301
location: https://www.example.com/
2. Test the RSS Feed
Now check the new feed URL:
curl -I https://www.example.com/feed/
A successful feed request should return a successful HTTP response, commonly:
HTTP/2 200
You can also inspect the feed content:
curl -L https://www.example.com/feed/
Check that the response contains valid RSS or XML content rather than an HTML page or an unexpected feed.
Note: A 301 response only confirms that a redirect is happening. Follow the redirect and confirm that the final feed URL returns a successful response with the expected feed content.
Common Mistakes to Avoid
- Using a broad rewrite rule: Adding
blog/to every request can create incorrect paths and routing conflicts. - Changing both WordPress URL settings: Keep the WordPress Address pointed at the actual core installation directory.
- Forgetting the root index.php file: The root entry point must load WordPress from the subdirectory.
- Redirecting every /blog/ URL: Broad redirects can break access to WordPress files and administration.
- Ignoring RSS feeds: Test the feed separately after changing the website URL.
- Overwriting .htaccess without a backup: Preserve existing rules and make changes carefully.
If you are troubleshooting other URL problems, you may also find this guide useful: WordPress post links not working because of custom permalink issues.
For more general troubleshooting, see common WordPress errors and how to fix them.
If you are moving a website between environments as part of a larger migration, you can also read how to install WordPress from development to production.
Frequently Asked Questions
Can WordPress files remain inside the /blog/ directory while the website opens from the root domain?
Yes. WordPress supports this configuration. Keep the WordPress Address pointed at the installation directory and set the Site Address to the root domain. You also need the appropriate root entry point and server rewrite configuration.
Why does /blog/feed/ show the wrong feed after moving WordPress?
An incorrect rewrite rule or URL configuration may send the request to the wrong location. Check the root and subdirectory rewrite rules, confirm the Site Address, and test the new feed URL at /feed/.
Should I remove the /blog/ directory after moving WordPress to the root?
No. Not when you are intentionally keeping the WordPress core files in that directory. The directory must remain available for WordPress core files, plugins, themes, and other required resources.
Do I need to redirect old /blog/ URLs?
If old public URLs have been replaced by new root-domain URLs, appropriate permanent redirects can help visitors and search engines reach the new locations. Configure exact redirects carefully so they do not interfere with the WordPress installation directory.
How can I confirm that my WordPress RSS feed is working?
Request https://www.example.com/feed/ using a browser or a command such as curl -I. Confirm that the final response is successful and inspect the response body to make sure it contains valid feed XML.
Conclusion
When you move the public WordPress website from /blog/ to the root domain but leave the core files in the original directory, the URL and rewrite configuration must be updated carefully.
In this example, the main problem was an overly broad rewrite rule that added blog/ to every request. Removing the incorrect rule, configuring the root index.php, checking the WordPress Address and Site Address, and handling old URLs carefully provides a more reliable setup.
Finally, test both the homepage and RSS feed. A website that looks correct in the browser may still have feed or redirect problems that need separate attention.
