How to Change the WordPress Directory on Your Server Without Breaking Your Site

You can move a WordPress installation to another folder on the same server without reinstalling it. The safe sequence is: make a complete backup, decide whether the public URL will change, update WordPress Address and Site Address, move the files, align the server’s rewrite configuration, then refresh permalinks and repair any old media paths. If the dashboard is already inaccessible, temporary WP_HOME and WP_SITEURL definitions 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 addresses in Administration → Settings → General:

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

• WordPress Address (URL) is the location of the WordPress core files, including wp-admin, wp-includes and the main PHP files.
• Site Address (URL) is the public address visitors type to reach the site.

They are often identical, but they do not have to be. For example, WordPress can keep its core files in https://example.com/wordpress while visitors use https://example.com. In that arrangement, the WordPress Address includes /wordpress, while the Site Address is the root URL.

Moving files and changing the public URL are separate operations. A same-server move can leave the domain unchanged, change only the directory, or change both the directory and the domain. Treat a domain change as a broader migration because database URLs, redirects, cookies, certificates and search-engine signals also need attention.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

Choose the right move before touching settings

If your goal is simply to move /old-folder to /new-folder while keeping the domain, use the same-server procedure below. If the domain is changing too, plan a separate URL-replacement and redirect project after the file move.

Back up everything before changing a URL

Make backups while the original site still works. Save a copy of the entire WordPress directory, not just the visible uploads folder. Include:

• WordPress core files and subdirectories;
• wp-content/uploads, themes, plugins and any custom files;
• the active wp-config.php and server configuration files;
• a database export containing posts, settings, users and plugin data; and
• a record of the current WordPress Address, Site Address, permalink structure, PHP version and web-server type.

Store the database export and file backup separately from the server. Confirm that the database dump can be opened and that the archive contains the expected files. A migration or backup utility can automate this, but the essential requirement is a restorable copy of both files and database before you edit either.

Prepare the destination and check prerequisites

Confirm the destination path

Create the destination directory, or identify the document-root directory if WordPress is moving to the domain root. Check ownership and permissions so the web server can read PHP files and WordPress can write where it normally needs to, especially under wp-content/uploads.

Keep the canonical scheme and host consistent

Use the exact production scheme and hostname in both fields. If the live site is HTTPS, enter https://. Decide whether the canonical host includes www and use that choice consistently. Do not mix HTTP and HTTPS, or the bare domain and its www form, during the move; inconsistent values can cause redirects, login cookies or mixed-content problems.

Schedule a quiet transition

Changing the settings creates a short period in which the database points to a location whose files have not moved yet. Perform the operation when you can avoid publishing content, running scheduled jobs or allowing visitors to edit data. Have file access and database access available before saving the new URLs.

Move WordPress to another folder on the same server

Follow this order when you can still use the dashboard. The order matters because WordPress needs to know the destination before its files are relocated.

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

1. Prepare the destination. Create the new directory or prepare the root directory. Do not copy only the visible front-end files; the complete WordPress installation, including hidden files such as .htaccess where applicable, must be available at the destination.
2. Open the URL settings. Sign in and go to Administration → Settings → General.
3. Change WordPress Address (URL). Enter the full URL corresponding to the directory that will contain the core files. Omit the trailing slash. For a move to https://example.com/site, enter exactly that value.
4. Change Site Address (URL). Enter the public URL visitors should use, also with the scheme included and no trailing slash. If visitors should continue using the domain root, leave this as https://example.com even when the core files move to a subdirectory.
5. Save once. Submit the General Settings form. Do not browse the front end or repeatedly reload the dashboard while the database and files are in different locations.
6. Move the files. Move all WordPress core files and subdirectories from the old directory to the prepared destination. Preserve filenames, hidden files, permissions and symbolic-link targets if your setup uses them.
7. Update the web server. Point the virtual host, document root or rewrite configuration at the new arrangement. The required artifact depends on whether the server is Apache, nginx or IIS.
8. Test administrative access. Open the new /wp-admin URL. If that does not load, try the new /wp-login.php path and inspect the server error log before making additional changes.
9. Refresh permalinks. Go to Settings → Permalinks and click Save Changes without necessarily changing the selected structure. WordPress regenerates the rewrite rules for the current configuration.
10. Exercise the site. Test the home page, several posts, a page, category and tag archives, a search, the login screen, media files, forms and any custom endpoints. Check both logged-in and logged-out views.

Do not delete the original directory until the backup is verified and the new site has passed testing. If you need a short rollback, keeping the old copy available makes it possible to restore the previous document-root and URL values.

Keep the domain root public while core files live in a subdirectory

This layout is useful when you want visitors to use https://example.com but want WordPress files isolated in /wordpress. Configure it as follows:

1. Place the complete WordPress installation in the subdirectory, for example /wordpress.
2. Set WordPress Address (URL) to https://example.com/wordpress.
3. Set Site Address (URL) to https://example.com.
4. Copy the WordPress index.php file to the document root. Copy the relevant rewrite file to the root as directed by the server-specific configuration.
5. Edit the root copy of index.php so its require statement points to the subdirectory’s wp-blog-header.php. The resulting path should reference /wordpress/wp-blog-header.php relative to the root file.
6. Apply the matching rewrite configuration for your server, then save the permalink structure in the dashboard.

The root index.php is a loader, not a second WordPress installation. Do not edit the copy inside the subdirectory when the public root is meant to load the root copy. If you later rename the subdirectory, update the loader path and the WordPress Address together.

Match the server configuration to the new layout

Changing the two WordPress fields does not automatically reconfigure the web server. A request must still reach the correct PHP entry point and, for pretty permalinks, be rewritten correctly.

Apache

Place the applicable .htaccess rules where Apache reads them for the public directory. A root-served subdirectory installation commonly needs the root loader and root rewrite handling, while a conventional subdirectory site uses rules in that subdirectory. Confirm that AllowOverride permits the directives you rely on, and clear any hosting-panel cache after changing the file.

nginx

Update the correct server block rather than adding Apache directives. Set the document root or location mapping to the new path, ensure PHP requests are passed to the intended PHP-FPM socket, and make the fallback route to the correct index.php. Reload nginx and inspect its error log if a request is routed to the old directory.

IIS

Change the site’s physical path and update web.config rewrite rules for the new location. IIS does not read Apache .htaccess syntax, so copying an Apache recipe can produce ignored rules or startup errors. Restart or recycle the site after validating the configuration.

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

Do not mix instructions between server types. A successful PHP response proves only that PHP ran; it does not prove that permalink rewrites, static files and the root/subdirectory relationship are correct.

Recover if changing the URL locked you out

If the dashboard redirects to the wrong path, shows a redirect loop or returns a server error after the URL change, use file access to add temporary constants to wp-config.php. Insert them before the line that says to stop editing:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );

Use the real public URL for WP_HOME and the real core-file URL for WP_SITEURL. Both values must include the scheme and must not end with a slash. These constants override the home and siteurl options while they remain defined, so they can restore login access even when the database contains the wrong values.

They do not rewrite the stored database options. Once access is restored, decide on one maintainable configuration: remove the temporary constants and correct the values in Settings → General, or retain deliberately documented constants as part of your deployment configuration. Leaving conflicting values in both places makes the next move harder to diagnose.

Use RELOCATE only as a controlled emergency measure

WordPress also documents a RELOCATE constant that can help recover a site in limited situations. It is not a substitute for setting both URLs correctly and moving the files in the documented order. Never leave RELOCATE enabled as an unattended permanent fix: WordPress warns that, in some configurations, an attacker could use it to change the site URL. If you used it while recovering access, remove it immediately after the correct URL values and server configuration are in place.

Repair links and media references after the move

The URL settings control how WordPress generates many new links, but existing content can still contain the old directory string. Audit:

• image, video, document and audio URLs in post content;
• featured-image and gallery metadata;
• customizer settings, widgets and navigation menus;
• plugin settings that store absolute callback or asset URLs;
• hard-coded paths in theme templates, JavaScript, CSS and server scripts; and
• feeds, sitemaps, canonical tags and email templates generated by extensions.

Use a migration-aware search-and-replace method that understands serialized database data. A plain text replacement can change string lengths without updating serialization metadata, corrupting options or widget settings. Work on a fresh database backup, search for the old directory and host separately when appropriate, and review the replacement report before running it against production.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

After replacements, clear page, object, CDN and browser caches. Upload a new test image, open an older attachment, inspect the page source for the old path, and check that redirects do not bounce between the old and new URLs.

Troubleshoot the most common symptoms

The site redirects to the old folder

Check both URL fields, any WP_HOME/WP_SITEURL definitions, reverse-proxy settings and cached redirects. Search the active configuration for the old directory. A browser’s permanent redirect cache can hide a fixed server rule, so test with a private window and a command-line or separate browser request.

The home page works but every post is a 404

Save the permalink structure again, then verify the rewrite file or server block is being read from the directory that serves the public URL. On Apache, check .htaccess permissions and overrides; on nginx or IIS, inspect the equivalent server-specific rules.

Images show broken links

Compare an image URL in the page source with the actual file location. If it still contains the old directory, update stored content and metadata with a serialized-data-safe method. If the URL is correct, check file permissions, case sensitivity and the web server’s static-file root.

The login form loops or immediately logs out

Verify that the scheme and hostname match exactly, including HTTPS and the chosen www form. Remove contradictory URL constants, clear cookies for the site and check whether a proxy is terminating HTTPS while WordPress believes the request is HTTP.

The dashboard cannot be reached at all

Use the temporary constants in wp-config.php, confirm the new file path exists, inspect PHP and web-server logs, and verify that the server is executing the intended index.php. If the move is incomplete, restore the original files and database backup rather than making multiple untracked edits.

A domain change was included accidentally

Stop treating it as a directory-only move. Restore a consistent domain in the URL settings, then plan database URL replacement, HTTPS certificates, redirects, cookie scope and external integrations as a separate migration. Directory changes alone do not update every domain embedded in content or plugin data.

Final verification checklist

• The complete file backup and database export are stored off-server.
• WordPress Address points to the directory containing the core files.
• Site Address matches the URL visitors should type.
• Both values use the intended HTTPS and hostname form and have no trailing slash.
• The web server’s document root, PHP handling and rewrite rules match the new layout.
• The root index.php loader, if used, points to the correct wp-blog-header.php.
• /wp-admin, /wp-login.php, the home page, posts, archives and media all load.
• Permalinks have been saved again after the move.
• Old directory references have been audited in content, metadata, themes and plugins.
• Temporary recovery constants and any RELOCATE definition have been removed or deliberately documented.

WordPress does not need to be reinstalled for a same-server relocation. The reliable result comes from keeping the two URL meanings distinct, moving the complete installation in the documented order, and making the server’s routing agree with the new file location.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

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.