The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
You can move WordPress into a subfolder in two supported ways: keep visitors at the root URL while the WordPress files live in /wordpress, or move the public site itself to /wordpress. The critical decision is made in Settings > General: WordPress Address (URL) identifies where the core files are installed, while Site Address (URL) identifies the URL visitors use.
Back up the complete files and database first. Then save the correct URL values before moving files, move the installation, put the required entry point and rewrite configuration in the correct location, refresh permalinks, and repair any old media URLs. Following that order prevents the most common “site not found,” redirect-loop, and missing-image failures.
Choose the arrangement you actually need
“Move WordPress to a subfolder” can describe two different end states. Select one before touching either URL field or moving a file.
| Decision point | Core files in a subfolder, public site at the root | Public site also in a subfolder |
|---|---|---|
| Example visitor URL | https://example.com |
https://example.com/wordpress |
| WordPress Address (URL) | https://example.com/wordpress |
https://example.com/wordpress |
| Site Address (URL) | https://example.com |
https://example.com/wordpress |
Root index.php |
Copied to the web root and pointed at the subfolder’s bootstrap file | Kept with the installation in the subfolder |
| Rewrite configuration | Root rewrite rules must send requests to the subfolder installation | Rewrite configuration remains with the subfolder installation |
| Redirect impact | Existing public URLs can remain at the root | Public URLs gain /wordpress; plan redirects from old URLs |
| Stored URL replacement | Replace old file-path references where necessary, while preserving root-facing links | Update links, media references, and other stored URLs that should include the subfolder |
The first arrangement is usually what someone means by “put the files in a subfolder without changing my site address.” The second is appropriate when the subfolder should be visible in every public URL.
#1 Best Overall
Prepare safely before changing URLs
A URL change can make the dashboard and front end temporarily inaccessible. Have an independent way to edit files and the database before you begin.
Create two recoverable backups
- Download the entire current WordPress directory, including
wp-admin,wp-includes,wp-content, plugins, themes, and uploads. - Export the WordPress database and confirm that the export can be opened or restored.
- Store both backups outside the directory that will be rearranged. A backup inside the folder being moved is not a reliable rollback copy.
- Record the current values of both URL fields, the active theme, permalink structure, PHP/server details, and any custom rewrite rules.
Check access and prerequisites
- Confirm that you can use the hosting file manager, FTP/SFTP, or another server-side file method.
- Confirm that you can edit
wp-config.phpand the relevant rewrite file if the dashboard becomes unavailable. - Identify whether the site uses Apache, nginx, or IIS. The rewrite syntax is different for each server.
- Schedule the move when you can test pages, forms, feeds, and administrative login immediately afterward.
Understand the two URL settings
In Settings > General, WordPress presents two separate addresses:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- WordPress Address (URL) is the location of the WordPress core files. If the files will live in
/wordpress, this value ends in/wordpress. - Site Address (URL) is the public address people type or follow. Keep it at the root for a root-facing site; change it to the subfolder for a subfolder-facing site.
Use the complete scheme and host, such as https://example.com/wordpress. Keep the protocol and domain consistent with the existing site, and do not add an unnecessary trailing slash if the current WordPress fields do not use one.
When the fields cannot be edited
If wp-config.php defines WP_SITEURL or WP_HOME, those constants override the values stored in the database. The corresponding dashboard fields may be unavailable or appear not to save. Change the constants deliberately, or remove them only when you intend to return control to the database values.
Do not leave RELOCATE enabled as a permanent fix. WordPress warns that this setting can allow an attacker to change the site URL in some configurations. If it was added for troubleshooting, remove it after the site is restored.
Move the files while keeping the public site at the root
These steps produce https://example.com for visitors while the core installation resides in /wordpress. Replace that folder name with the one you chose.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors1. Create the destination folder
Under the current web root, create the destination directory, for example /wordpress or /blog. If WordPress is not already on the server, upload the unzipped package contents into that directory using FTP/SFTP or the host’s file manager. Do not create an extra nested level such as /wordpress/wordpress.
2. Set the addresses before the physical move
- Open Settings > General.
- Set WordPress Address (URL) to
https://example.com/wordpress. - Leave Site Address (URL) as
https://example.com. - Save the changes once.
The browser may report a redirect, a 404, or an inaccessible dashboard at this point. That is expected until the files and entry point match the new settings. Do not repeatedly change the fields while the physical move is incomplete.
3. Move the WordPress installation
Move the WordPress core files and directories into the new subfolder. Include wp-admin, wp-includes, wp-content, wp-config.php, and the remaining root-level installation files. Preserve permissions and ownership as you move them.
4. Copy the root entry point and rewrite file
Copy, rather than move, index.php from the installation into the web root. Keep the original installation copy in /wordpress. Copy the installation’s .htaccess to the web root as well when Apache is in use, then adjust the rewrite arrangement so requests received at the root are sent to the subfolder’s WordPress entry point.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11The root index.php must load the bootstrap file from the new directory. A typical root entry point has the following shape; change the folder name if yours differs:
<?php
require __DIR__ . '/wordpress/wp-blog-header.php';Do not paste this code into the copy that remains in /wordpress. That copy must continue to use paths appropriate to its own directory.
5. Match the rewrite rules to the server
For Apache, the root .htaccess must use the subfolder as the rewrite destination and must not contain a stale rule that points to the old root installation. For nginx, update the server block and its try_files or equivalent routing so the root request reaches the subfolder’s index.php. For IIS, use a web.config arrangement that performs the same hand-off. Use the configuration recommended for your server and WordPress version; copying Apache directives into nginx or IIS will not work.
6. Test the root site and refresh permalinks
- Open the home page in a private browser window.
- Open a known post, page, category, search result, feed, and an administrative URL.
- Go to Settings > Permalinks and click Save Changes without changing the structure. This regenerates the rewrite rules for the selected installation.
- Open several media files and inspect the browser’s address bar to confirm that the public URLs remain at the root.
If the home page works but every post returns 404, the rewrite rules are still pointing at the old location or were not regenerated. If the dashboard redirects between root and /wordpress, compare both URL fields and any constants in wp-config.php.
Move the public site under the subfolder
Use this route when visitors should reach the site at https://example.com/wordpress. Unlike the root-facing arrangement, the public URL changes and every link that should remain on the site must use the new base path.
Rank #4
1. Create and populate the destination
Create /wordpress below the web root and move the complete WordPress installation into it. Keep the files together, including the installation’s index.php and rewrite configuration.
2. Change both address fields
- Open Settings > General.
- Set WordPress Address (URL) to
https://example.com/wordpress. - Set Site Address (URL) to
https://example.com/wordpress. - Save once, then complete the file move if the dashboard becomes temporarily unavailable.
When constants override these fields, update WP_SITEURL and WP_HOME to the same subfolder URL instead of relying on the dashboard.
3. Keep rewrites with the installation
Leave the rewrite configuration beside the subfolder’s WordPress files and ensure its base path includes /wordpress. The web root should not retain a competing WordPress rewrite file that routes requests somewhere else. If the domain previously served WordPress at the root, configure your web server to redirect old root URLs to their corresponding /wordpress URLs where appropriate.
Free tools Windows power users keep installed
One-click scans. No signup required.
4. Regenerate and verify
After the site responds at the new address, visit Settings > Permalinks and save the existing structure. Test the home page, posts, pages, archives, login, feeds, XML sitemap, images, stylesheets, scripts, and canonical links. A successful home page alone does not prove that the migration is complete.
Repair stored URLs, media, and content
Moving files does not automatically rewrite every URL stored in the database or in post content. The migration can leave uploaded media, custom links, CSS references, JavaScript URLs, canonical tags, feeds, or XML sitemaps pointing to the old path.
Best Value
Search for the old path
Search the database and content for the previous installation path and domain form. Include attachment metadata, options, widgets, menus, serialized settings, and builder-generated content. Serialized data must be handled with a serialization-aware search-and-replace method; a blind text replacement can corrupt lengths and make settings unreadable.
Check the files users actually request
- Open representative images and confirm that they return the expected file rather than a 404.
- View source or use browser developer tools to check stylesheet and JavaScript URLs.
- Inspect canonical links, pagination, feeds, and the XML sitemap for the intended base URL.
- Submit a test form and check login, logout, password reset, and cookie behavior.
- Confirm that internal links do not send root-facing users into an unintended duplicate subfolder URL, or vice versa.
Do not replace every occurrence mechanically when the public URL and file location intentionally differ. In the root-facing arrangement, core files use the subfolder while visitor-facing links should continue to use the root.
Recommended Free Tools
Troubleshoot the common failure modes
| Symptom | Likely cause | What to check |
|---|---|---|
| Dashboard redirects repeatedly | The two address fields, constants, and physical paths disagree | Compare WordPress Address, Site Address, WP_SITEURL, WP_HOME, and the actual folder name. |
| Home page loads, posts return 404 | Rewrite rules still target the old location or were not regenerated | Correct the server-specific rewrite file, then save Settings > Permalinks. |
| Images or scripts are missing | Database or content still contains the old path | Run a serialization-safe search for the old URL/path and inspect representative requests in the browser. |
| Visitors see a directory listing or server 404 | The web root lacks the correct entry point or server routing | Confirm the copied root index.php, its bootstrap path, permissions, and the active virtual-host/server-block configuration. |
Some links contain a duplicated folder, such as /wordpress/wordpress |
The subfolder was nested twice or a hard-coded base path was changed twice | Inspect the directory tree and stored URLs; keep one consistent installation path. |
| Permalinks work only for the home page | Apache overrides are disabled, nginx routing is incomplete, or IIS rules are absent | Use the rewrite syntax for the actual server and verify that the server permits the required configuration. |
| URL fields appear locked | WP_HOME or WP_SITEURL is defined in wp-config.php |
Change the constants intentionally or remove them to restore database-controlled settings. |
Validate the migration before declaring it finished
Run this checklist from a private browser session and, if possible, from a second device or network:
- The selected public URL opens without an unexpected redirect chain.
- HTTPS remains in use and the browser reports no mixed-content errors.
- The dashboard, login, logout, password reset, and user profile pages work.
- Posts, pages, archives, search, pagination, comments, feeds, and the XML sitemap load.
- Images, downloadable files, CSS, JavaScript, and theme assets return successful responses.
- Canonical links and internal links use the intended public base URL.
- Forms, webhooks, scheduled tasks, and API endpoints still use valid paths.
- The old root URL either continues to work intentionally or redirects to the selected public location without a loop.
- The backup remains untouched until the site has passed these checks and normal traffic has been observed.
Rollback if the move fails
Stop making partial edits if the site is unstable. Restore the original directory layout from the file backup, restore the database if URL changes have already been written, and return both address settings to their recorded values. Remove temporary constants or test directives that are no longer needed, then clear caches and test again. A rollback is safer than repeatedly alternating URL values while files remain in an intermediate state.
Quick Recap
Important distinctions to remember
- The WordPress Address tells WordPress where its core files live; the Site Address tells WordPress where visitors find the site.
- A root-facing migration needs a copied root
index.phpand matching root rewrite rules; the original copies stay with the installation. - A subfolder-facing migration changes the public URL and therefore requires a deliberate redirect and stored-link plan.
- Saving permalinks after the move regenerates rewrite rules, but it does not repair every old URL in the database.
WP_HOMEandWP_SITEURLoverride saved dashboard values, whileRELOCATEshould not remain enabled.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
