You can move WordPress to another folder on the same server without reinstalling it. The safe sequence is: back up the files and database, decide which URL visitors should use, update WordPress Address and Site Address, move the files, adjust the server’s rewrite configuration, then refresh permalinks and repair any old media paths. If the dashboard becomes inaccessible, temporary WP_HOME and WP_SITEURL constants in wp-config.php can restore access.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What “changing the WordPress directory” actually changes
A WordPress installation has two related URL settings, and confusing them is the most common cause of a broken move:
As an Amazon Associate I earn from qualifying purchases.
| Setting | Meaning | Typical value when core files are in /wordpress but the site is public at the domain root |
|---|---|---|
| WordPress Address (URL) | The URL where WordPress core files, wp-admin, and wp-includes live. |
https://example.com/wordpress |
| Site Address (URL) | The public address visitors type to reach the site. | https://example.com |
If the files and public site remain in the same folder, both settings are normally identical. They differ when the public site is served from one location while the WordPress files are stored in another. Enter complete URLs with the correct http or https scheme, the intended host name (including or excluding www consistently), and no trailing slash.
Moving a directory is not the same as changing a domain. A same-server directory move changes file locations and possibly the visible path. A domain change additionally requires a planned database URL replacement and redirects; treat that as a separate migration task.
Choose the layout you want before touching anything
Write down the desired end state first. The following layouts cover most same-server moves:
| Layout | WordPress Address | Site Address | What visitors see |
|---|---|---|---|
| WordPress at the domain root | https://example.com |
https://example.com |
https://example.com/ |
| Core files in a subdirectory, public site at root | https://example.com/wordpress |
https://example.com |
https://example.com/; the directory is hidden from normal page URLs. |
| Public site and core files in a subdirectory | https://example.com/wordpress |
https://example.com/wordpress |
https://example.com/wordpress/ |
The second layout is often called a “subdirectory installation with a root URL.” It requires a root index.php and the appropriate rewrite file in addition to the core files in the subdirectory.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchBack up the site and confirm access
Make a restorable backup before changing either URL field. Save both the database and the complete set of site files, not just the WordPress core:
Rank #2
- The entire current WordPress directory, including hidden files such as
.htaccess. wp-content/uploads, themes, plugins, custom files, and any non-WordPress files used by the site.- A database export containing posts, settings, users, menus, and plugin data.
- Your current server configuration, such as the Apache virtual-host or
.htaccesssettings, nginx server block, or IISweb.config.
Verify that the database export can be opened and that the files are readable before proceeding. Record the current WordPress Address and Site Address, the PHP/server account that owns the files, and the exact destination path. Schedule the change when you can leave the site alone during the brief transition: after saving new URLs, browsing the old or new front end before the files are moved can produce misleading errors.
Move WordPress to another folder on the same server
This order follows WordPress’s documented same-server procedure. It assumes you can still sign in to the dashboard and that the destination is on the same hosting account or server.
- Create or prepare the destination. Make the target directory, or clear and prepare the document-root directory if WordPress is moving to the domain root. Confirm that the web server and PHP process will be able to read the files and that the destination is inside the intended site’s document tree.
- Open the URL settings. In the dashboard, go to Administration → Settings → General. Do not edit unrelated options on this screen during the move.
- Set WordPress Address (URL). Enter the full URL that will contain the core files after the move. For a destination named
wordpress, this might behttps://example.com/wordpress. - Set Site Address (URL). Enter the public URL visitors should use. For a root-served site, enter
https://example.com; for a site that should visibly remain in the subdirectory, enterhttps://example.com/wordpress. Do not add a final slash. - Save the settings once. WordPress will begin using the new addresses immediately. Do not click through the front end, log in again, or open links while the files are still in the old location.
- Move the files. Move every WordPress core file and subdirectory to the destination, preserving permissions, ownership, hidden files, symbolic links, and the existing
wp-contentcontents. A partial copy can leave the dashboard or plugins unavailable even when the URL values are correct. - Handle the document root. If the public URL is the root while core files are in a subdirectory, put a copy of
index.phpand the applicable rewrite configuration in the document root. The copied index must load the bootstrap file from the new directory; for a directory namedwordpress, the require line should point to/wordpress/wp-blog-header.php, for example:
<?php
require __DIR__ . '/wordpress/wp-blog-header.php';- Test the dashboard directly. Open
https://example.com/wp-adminfor a root site, or the corresponding/wp-adminpath for a visible subdirectory. If the login screen does not load, trywp-login.phpat the same base URL and use the recovery method below rather than repeatedly changing settings. - Refresh rewrite rules. In the dashboard, go to Settings → Permalinks and click Save Changes without necessarily changing the structure. This causes WordPress to regenerate the rewrite rules for the new location.
- Check the whole site. Test the home page, a post, a page, category and tag archives, search, the login screen, uploads, plugin screens, and any custom application mounted under the old directory. Look at the browser address bar as well as the page content: a site can display correctly while links still point to the old path.
Keep the domain root public while core files live in /wordpress
Use this arrangement when visitors must stay on https://example.com but you want the WordPress files physically separated in /wordpress. Set:
Recommended Free Tools
Rank #3
- WordPress Address (URL):
https://example.com/wordpress - Site Address (URL):
https://example.com
Then copy the root-facing index.php and the rewrite file appropriate to your server from the WordPress directory into the document root. Edit the copied index.php so its require statement loads wordpress/wp-blog-header.php. Do not leave the original path in that file; otherwise the root request will look for the bootstrap file in the wrong place.
The rewrite configuration must match the server handling the request. Apache, nginx, and IIS do not use interchangeable syntax:
| Server | Artifact to update | Important check |
|---|---|---|
| Apache | .htaccess in the location that receives the public request |
Preserve required existing directives and let Settings → Permalinks regenerate WordPress rules after the move. |
| nginx | The site’s nginx server block and relevant location rules |
Translate the routing logic into nginx syntax; an Apache .htaccess file is not read by nginx. |
| IIS | web.config and the IIS URL Rewrite configuration |
Use IIS rewrite rules rather than copying Apache directives. |
If the root loads but individual pretty URLs return 404 errors, the index file may be correct while the rewrite rules are not. If every request downloads a file or shows a server error, check the document-root mapping, PHP handler, and file permissions before changing WordPress URLs again.
Recover if the URL change locks you out
If the dashboard or login page fails after the move, temporarily override the database values in wp-config.php. Add these lines before the file’s “stop editing” line, using your actual final URLs and no trailing slashes:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );WP_HOME supplies the public Site Address and WP_SITEURL supplies the WordPress Address. These constants override the corresponding home and siteurl options while they are present, but they do not rewrite the values stored in the database.
Once access is restored, use Settings → General to set the intended values, or correct the database through a controlled database-access method if the dashboard cannot be used. Then remove the temporary constants unless you deliberately intend to manage those URLs in configuration. Leaving an override in place can hide future settings changes and make the site harder to maintain.
WordPress also documents a RELOCATE constant as a troubleshooting option in some moves. Do not leave it enabled as a permanent fix: WordPress warns that, in some configurations, an attacker could use it to change the site URL.
Repair old directory references after the files move
Changing the two URL settings does not automatically rewrite every URL stored in post content, widgets, plugin settings, or metadata. A media link can therefore continue to contain the old directory even though the home page works.
Find the stale path
- Open several posts and pages containing images, downloads, galleries, or embeds.
- Inspect image sources and download links for the former directory string.
- Check menus, widgets, theme options, forms, feeds, and plugin-generated links.
- Review browser developer-console errors and server logs for requests containing the old path.
Replace it without corrupting serialized data
Use a migration-aware search-and-replace method that understands serialized PHP data. A blind SQL text replacement can change string lengths without updating the length markers used by serialized values, breaking plugin or theme settings. Take another database backup before a replacement, run a dry run when the tool supports one, replace only the old directory-to-new-directory mapping, and then test the affected settings.
If the move also changes the domain, separate the domain replacement from the directory move, plan redirects, and verify mixed-content behavior under HTTPS. Do not assume that changing the two URL options is sufficient for a domain migration.
Use this troubleshooting matrix when something fails
| Symptom | Likely cause | Action |
|---|---|---|
| Home page shows a server error immediately after saving | The URLs were changed before the files reached the destination, or the destination is not the active document root. | Stop browsing, confirm the move completed, verify the server’s root mapping, and use the wp-config.php constants only if the stored values need a temporary override. |
| Dashboard redirects between two addresses | WP_HOME, WP_SITEURL, and the database values disagree, or the scheme/host differs between them. |
Use one consistent HTTPS and host combination, remove stale temporary constants after access is restored, and save the intended values once. |
| Login works but CSS or JavaScript is missing | Static files are still referenced under the old directory, or the web server maps the new path incorrectly. | Inspect the failing asset URLs, confirm the files exist at those paths, and repair stored references with a serialization-aware method. |
| Pretty permalinks return 404 while the home page works | Rewrite rules were not regenerated or the server-specific configuration is missing. | Save Settings → Permalinks again, then check the correct Apache, nginx, or IIS configuration. |
| Images show the old directory | Attachment or content URLs retained the former path. | Audit media and content references and perform a careful, backed-up replacement. |
The site is reachable only with /wordpress |
Site Address still contains the subdirectory, or the root index.php/rewrite setup is incomplete. |
Set the public Site Address to the root, keep WordPress Address in the subdirectory, and verify the copied root files and server rules. |
| Files are present but uploads or plugins fail to write | Ownership or permissions changed during the move. | Restore the same service-account ownership and permissions used by the original installation; do not make the entire site world-writable. |
Decide which implementation path fits your access
| Path | Public URL changes? | Required access | Best use | Main risk |
|---|---|---|---|---|
| Dashboard move | Optional | WordPress administrator plus file access | A same-server relocation when the dashboard still works. | Saving URLs before moving files creates a short, intentional outage. |
| File and database recovery | Optional | File access and database access | A locked-out dashboard or a move performed during maintenance. | Incorrect database edits or serialized-data replacement can damage settings. |
| Root-served subdirectory | No visible directory in public URLs | File access and server-configuration access | Keeping the domain root public while organizing core files in a subdirectory. | Root index and rewrite rules must match the server type. |
| Domain-plus-directory migration | Yes | File, database, DNS/virtual-host, and redirect access | A move that also changes the host name. | It needs database URL replacement and redirect planning beyond a file move. |
If you cannot edit the server’s rewrite configuration, ask the hosting administrator or a WordPress specialist to apply the server-specific portion while you retain a verified backup. The WordPress files can be in the correct directory and still fail if the virtual host points elsewhere.
Final verification checklist
- The database and complete file tree have restorable backups.
- WordPress Address points to the directory containing the core files.
- Site Address matches the URL visitors should type.
- Both URLs use the same intended HTTPS and host convention and omit trailing slashes.
- The entire file tree, including hidden files and
wp-content, was moved or copied. - The root
index.phpand rewrite artifact are present when using a root URL with a subdirectory installation. - The server configuration matches Apache, nginx, or IIS rather than another server’s syntax.
- Settings → Permalinks has been saved after the move.
- Admin, login, front-end pages, media, forms, feeds, and plugin screens have been tested.
- Searches for the former directory path have been completed in content and configuration.
- Temporary
WP_HOME,WP_SITEURL, orRELOCATEtroubleshooting settings have been removed or consciously managed.
What a successful move looks like
A successful same-server relocation has three independent parts in agreement: the files are physically in the intended directory, WordPress’s two URL settings describe the correct file and public locations, and the web server routes requests to the right bootstrap file. Testing only the home page is not enough; permalinks, assets, uploads, login, and stored content can reveal a path that still points to the old directory. Complete those checks before treating the migration as finished.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
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.
