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 an existing WordPress installation to another folder on the same server without reinstalling it. The safe sequence is to back up the files and database, set the WordPress Address and Site Address deliberately, move the core files, update the server’s rewrite configuration, and then refresh permalinks and check stored media links.
The two addresses have different jobs: WordPress Address identifies where the WordPress core files live, while Site Address is the public URL visitors enter. They can be different when the site is served at the domain root but the files remain in a subdirectory.
Recommended Free Tools
What “changing the WordPress directory” actually changes
A directory move is a file-location change, a URL-configuration change, or both. Deciding which one you need prevents the most common mistake: changing the public URL when you only intended to reorganize files.
| Setting or component | What it controls | Example |
|---|---|---|
| WordPress Address (URL) | The location of the WordPress core files. | https://example.com/wordpress |
| Site Address (URL) | The address visitors type to reach the site. | https://example.com |
| Server document root or rewrite configuration | How Apache, nginx, or IIS sends requests to the correct files. | Root requests routed to a subdirectory installation |
| Database options and stored content | URLs saved in settings, posts, widgets, and metadata. | Image links that still contain an old directory |
If both addresses remain the same and you simply move the files to a different physical folder, the server configuration still has to point requests to the new location. If the public address changes, the database and redirects require additional work.
#1 Best Overall
Choose the layout you want before touching files
Write down the final file location and the final visitor-facing URL. Keep the scheme and host consistent, including HTTPS and your chosen www or non-www form. Use full URLs with https:// and no trailing slash in the WordPress settings.
| Goal | WordPress Address | Site Address | Typical server work |
|---|---|---|---|
| Move the entire site from one folder to another, with the same public path | The new core-file URL | The same public URL visitors already use | Move files, point the server at the destination, refresh permalinks |
Keep visitors at the root while core files live in /wordpress |
https://example.com/wordpress |
https://example.com |
Copy the root loader and rewrite file, edit index.php, configure the server |
| Move files and change the domain | The new domain and directory | The new public domain | Directory move plus a database URL replacement and redirects planned separately |
| Dashboard is unavailable after a URL mistake | Temporarily force the intended value in wp-config.php |
Temporarily force the intended value in wp-config.php |
Restore access, then correct the saved settings and remove temporary overrides when appropriate |
Back up everything before changing the URL
Make a recoverable copy before editing either URL field or moving a single file. The backup should be usable independently of the live installation.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches- Download or snapshot the complete current WordPress directory, including core files, themes, plugins, and the
uploadsdirectory. - Export the WordPress database, not just a few tables. URL values can appear in options, posts, metadata, widgets, and plugin records.
- Save other files in the account that the site depends on, such as a custom root
index.php, rewrite files, or server-specific configuration. - Record the current WordPress Address, Site Address, document root, and PHP/server arrangement so you can restore the original layout if needed.
- Confirm that you can access the backup before proceeding. A backup that cannot be downloaded or restored is not a rollback plan.
Use your host’s file manager, SFTP, or another file-transfer method to make the file copy, and use a database export facility appropriate to your hosting setup. A migration-aware backup or migration tool can reduce mistakes, but it does not remove the need to verify the destination and URLs.
Move WordPress to another folder on the same server
This procedure assumes the domain itself is not changing. It follows the order documented for a same-server move; changing the order can leave the database pointing at files that have not moved yet.
- Create the destination. Make the new directory, or prepare the domain root if the installation is moving there. Do not delete the original directory yet.
- Open the URL settings. Sign in to WordPress and go to Administration → Settings → General.
- Change WordPress Address (URL). Enter the full URL of the directory that will contain the WordPress core files. For a subdirectory installation this might be
https://example.com/wordpress. - Change Site Address (URL). Enter the public URL visitors should use. For a root-served site, this is
https://example.com, even though the core files are below/wordpress. - Save once. Use the exact HTTPS and host form you intend to keep, and omit a trailing slash. After saving, do not browse around the site while the files are still in their old location.
- Move the files. Move all WordPress core files and subdirectories into the destination. Include the files that were in the old directory, not only the visible themes and plugins. Preserve the
wp-contentdirectory and its uploads, themes, and plugins. - Open the login endpoint at its new location. Try
yourdomain.example/wp-admin, orwp-login.phpif the normal dashboard path does not load. Replace the example host with your actual domain. - Refresh rewrite rules. In the dashboard, open Settings → Permalinks and save the existing structure again. You do not need to change the structure; saving it causes WordPress to regenerate the rewrite rules for the new arrangement.
- Audit stored references. Check posts, pages, widgets, theme settings, and media for the old directory string. Replace old links with a migration-aware method that preserves serialized data rather than performing an unsafe plain-text replacement.
Keep the old directory and your backup until the site has passed testing. Deleting the old files immediately removes an easy rollback path and can make it harder to identify whether a failure came from the move or the server configuration.
Serve the site at the root while keeping WordPress in a subdirectory
A common final layout is a public root URL such as https://example.com with core files in https://example.com/wordpress. Set the two WordPress URLs differently, then add a small root loader and the appropriate rewrite configuration.
Set the two addresses
- In Administration → Settings → General, set WordPress Address (URL) to the subdirectory URL, such as
https://example.com/wordpress. - Set Site Address (URL) to the root URL, such as
https://example.com. - Save the settings, and avoid opening front-end pages during the transition.
Place the root loader
Copy index.php from the WordPress directory to the document root. Copy the relevant rewrite file to the root as directed by the official WordPress procedure for your server. Edit the copied root index.php so its require statement loads wp-blog-header.php from the subdirectory:
require __DIR__ . '/wordpress/wp-blog-header.php';The exact existing line may use a different path expression; the important part is that the copied root file points to the new directory’s wp-blog-header.php, not to a file that no longer exists at the root.
Update the server’s rewrite behavior
The root loader only works when the web server sends requests to it and applies the right rewrite rules. The configuration is server-specific:
- Apache: Use the root
.htaccessand the Apache rewrite rules appropriate to the subdirectory layout. - nginx: Adjust the relevant server block. nginx does not read Apache
.htaccessfiles, so copying Apache instructions verbatim will not configure nginx. - IIS: Use the appropriate
web.configrules for the root and subdirectory arrangement.
If you do not control the server configuration, ask the hosting provider or server administrator to apply the rule for the actual server type. A syntactically valid rule for one server can be ignored or cause errors on another.
Server-specific details that commonly decide whether the move works
Apache and .htaccess
Apache commonly stores per-directory rewrite rules in .htaccess. When WordPress is moved, the root and destination directories may need different copies or rule locations. Saving Settings → Permalinks after the move lets WordPress regenerate its rules where it has permission to do so, but it cannot fix a document root that still points at the wrong directory.
nginx server blocks
nginx uses the virtual-host server block rather than .htaccess. The block must serve the intended document root and route WordPress requests to the PHP entry point and subdirectory layout you selected. Have the administrator validate and reload the configuration using the host’s normal procedure; do not paste Apache directives into nginx.
Rank #4
IIS and web.config
IIS uses web.config for rewrite behavior. Place or update the file in the location required by the selected root/subdirectory design, and ensure the IIS site points to the intended physical directory. Rules copied from Apache or nginx are not interchangeable with IIS configuration.
Recover if changing the URL locks you out
If the saved values are wrong, you can temporarily override them in wp-config.php. Add the definitions before the line that says “That’s all, stop editing!” (or its equivalent stop-editing comment), using the correct full URLs and no trailing slashes:
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 & 11define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );WP_HOME forces the public Site Address, while WP_SITEURL forces the location of the WordPress files. These constants override the home and siteurl options while they are present, but they do not rewrite the values stored in the database.
Once you can sign in, decide on a maintainable configuration. Correct the values in Settings → General or directly in the database using a careful, migration-aware process, then remove the temporary constants if you no longer need them. Leaving overrides in place can make later URL changes confusing because the dashboard fields no longer control the effective values.
Best Value
Why not leave RELOCATE enabled?
RELOCATE is not a permanent repair. WordPress warns that leaving the constant in wp-config.php is insecure because, in some configurations, an attacker could change the site URL. Use a controlled override with the intended URLs, restore access, correct the underlying settings, and remove unsafe temporary measures.
Test the site after the files move
Run these checks from a private browser window and, where possible, from more than one device or network. Each check catches a different class of failure.
- Front page: Confirm the root or intended public URL loads over HTTPS and does not redirect to the old directory.
- Dashboard and login: Sign in through
/wp-adminand verify that the dashboard assets load. - Permalinks: Open a post, page, category, and any custom post type, then save the permalink structure again if a URL returns a 404.
- Media: Open images and downloads from older posts as well as newly uploaded files. Search for the old directory string in content and widget fields.
- Internal navigation: Follow menus, logo links, pagination, feeds, and search results to detect hard-coded paths.
- HTTPS and host form: Check that links do not alternate between HTTP and HTTPS or between the
wwwand non-wwwhost you selected. - Server errors: Review the web server and PHP logs for missing files, rewrite loops, permission errors, or requests still aimed at the old path.
Media and internal links deserve a separate audit because moving files does not automatically rewrite every URL saved inside the database. Use a method that understands serialized data; an unsafe replacement can corrupt option or metadata records even when the visible URL looks correct.
If the domain is changing too
A directory move and a domain migration are related but not identical. When both change, plan a database URL replacement and redirects separately from the file move. The replacement must cover values stored in options, post content, metadata, widgets, and plugin settings while preserving serialized data. Redirects then tell visitors and search engines how old URLs map to the new domain.
Do not assume that changing WordPress Address and Site Address alone updates every old-domain reference. Finish the file move first, verify the new installation, then perform the domain-specific replacement and redirect work with a fresh backup available.
Quick Recap
Troubleshoot by symptom
| Symptom | Likely cause | What to check |
|---|---|---|
| Dashboard redirects repeatedly or shows the wrong host | One URL field still contains the old scheme, host, or directory, or a forced constant overrides the database. | Check both General settings fields and WP_HOME/WP_SITEURL in wp-config.php. |
| Front page loads but posts return 404 | Rewrite rules still describe the previous location. | Save Settings → Permalinks and verify the correct .htaccess, nginx server block, or IIS web.config. |
| Root URL is blank or displays a directory listing | The root index.php is missing, points to the wrong path, or the server document root is incorrect. |
Confirm the copied loader requires /wordpress/wp-blog-header.php (or your actual destination) and that the server serves the root directory. |
| Images show broken links after the move | Stored media URLs still contain the old directory. | Search content and metadata for the old path and run a serialized-data-safe replacement. |
| Apache instructions have no effect on the server | The site is running nginx or IIS. | Identify the server type and apply its server-block or web.config configuration instead. |
| Login is impossible immediately after saving | The URL was changed before the files or server routing were ready. | Use temporary WP_HOME and WP_SITEURL constants, restore the intended file layout, then correct the saved values. |
Decide which implementation path fits your access
| Available access | Best-fit approach | Additional requirement |
|---|---|---|
| Dashboard, file transfer, and database access | Use the documented same-server sequence. | Verified backup and server rewrite update |
| File transfer but no dashboard | Prepare the destination and use controlled configuration or database editing. | Exact URL values and a rollback copy |
| Dashboard but no server configuration access | Change the URLs only after the host confirms the document root and rewrite arrangement. | Hosting-provider assistance for Apache, nginx, or IIS rules |
| Domain and directory both changing | Treat the work as a migration rather than a simple folder move. | Serialized-data-safe URL replacement and redirects |
Final checklist
- Files, uploads, plugins, themes, other site files, and the database are backed up.
- The final WordPress Address and Site Address are written down, use the intended HTTPS/host form, and have no trailing slash.
- The URL fields were saved before the files were moved, and the site was not browsed during the interim state.
- All core files and subdirectories were moved to the destination.
- The root loader and server-specific rewrite configuration match the final layout.
- Permalinks were saved again, and old media/internal links were audited with a serialized-data-safe method.
- Any temporary constants were removed after the underlying settings were corrected, and
RELOCATEwas not left 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.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →
