What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
You can put WordPress’s core files in /wordpress or another subfolder while keeping visitors at https://example.com. The safe method is to separate the WordPress Address (URL), which identifies the core-file location, from the Site Address (URL), which identifies the public site. Back up the files and database, set those addresses before moving anything, copy the root entry files when necessary, regenerate permalinks, and then repair any stored URLs that still reference the old path.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Choose the public URL before moving a file
WordPress supports two different layouts. Decide which one you need first; the correct file placement and URL values depend on this choice.
As an Amazon Associate I earn from qualifying purchases.
| Arrangement | Public URL | WordPress Address (URL) | Site Address (URL) | Entry point and rewrites | URL replacement work |
|---|---|---|---|---|---|
| Root-facing site | https://example.com |
https://example.com/wordpress |
https://example.com |
Core files and rewrite configuration live in /wordpress. Copy index.php and .htaccess to the web root; the root index.php must load WordPress from /wordpress. |
Visitors keep the existing URLs, but database content, media, canonical links, feeds, or scripts can still contain the old installation path and must be checked. |
| Subfolder-facing site | https://example.com/wordpress |
https://example.com/wordpress |
https://example.com/wordpress |
Keep the installation’s entry point and rewrite configuration with the files in the subfolder. The public URLs now include /wordpress. |
Links and references that previously pointed at the root may need to be changed to include the subfolder; redirects from old URLs may be required. |
The two fields are deliberately separate. WordPress Address says where the application is installed; Site Address says where readers find the site. WordPress describes this flexibility in its migration documentation, but mixing the values or changing them after the move is the usual cause of a blank site, redirect loop, or missing assets.
Back up the complete installation
Do this before changing either URL. Keep the backup outside the directory you are about to rearrange so a file move cannot overwrite your only recovery copy.
#1 Best Overall
- Archive the entire WordPress directory, including
wp-admin,wp-includes,wp-content, plugins, themes, and uploads. - Export the complete WordPress database, not only the options table.
- Record the current document root, PHP version, database name, active theme, permalink structure, and server type (Apache, nginx, or IIS).
- Save the current root
index.php,.htaccess, nginx server block, or IISweb.configseparately. - Confirm that you can download the backup and, if possible, test that the database export can be opened or restored.
A file-only backup cannot restore URL settings, posts, attachment metadata, or serialized plugin data. A database-only backup cannot restore themes, plugins, or uploaded files.
Create the destination subfolder
On an existing server installation
Create a directory directly under the web root, such as /wordpress or /blog. Its final web path should be predictable: a folder named blog under the document root normally becomes https://example.com/blog. Check ownership and permissions against the existing WordPress directory rather than making the new folder universally writable.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →When WordPress is not on the server yet
Upload the unzipped WordPress package into the new folder using the host’s file manager or FTP/SFTP. Do not place a second copy inside the destination (for example, avoid accidentally creating /wordpress/wordpress). The package contents should be directly inside the target directory, with wp-admin, wp-includes, and wp-content at that level.
Set the URL values before the physical move
Root-facing layout
In the WordPress dashboard, open Settings > General. Set:
- WordPress Address (URL):
https://example.com/wordpress - Site Address (URL):
https://example.com
Save the changes before moving the files. The dashboard can become temporarily inaccessible at this point because WordPress is now looking for its files in the new location; that is expected until the move and root entry point are in place.
Subfolder-facing layout
Set both fields to the final subfolder URL, for example:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →- WordPress Address (URL):
https://example.com/wordpress - Site Address (URL):
https://example.com/wordpress
After the move, visitors will use URLs containing /wordpress. Existing root URLs do not automatically remain equivalent; plan redirects and link updates if the site has already been published.
If the dashboard fields are unavailable
Definitions in wp-config.php override the values stored in the database. When these constants exist, the corresponding fields in Settings > General are unavailable:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );Use the pair that matches your intended arrangement. Edit the existing definitions rather than adding competing definitions elsewhere in the file. Once the migration is stable, keep the constants only if you intentionally want the URLs locked in configuration; otherwise remove them and save the values through the dashboard.
Move the files into the subfolder
Root-facing site: copy the two root files
- Move the WordPress core directories and files into the destination, including
wp-admin,wp-includes,wp-content, and the installation’s PHP files. - From the moved installation, copy
index.phpand.htaccessinto the web root. Do not delete the originals from the installation unless the server’s documented configuration specifically requires that layout. - Edit the copied root
index.phpso its bootstrap path points to the subfolder. A typical root file for a folder namedwordpressis:
<?php
/** Loads the WordPress environment and template */
require __DIR__ . '/wordpress/wp-blog-header.php';If your destination is named blog, replace /wordpress/ with /blog/. Preserve the rest of the file unless your existing installation has a deliberate customization. The copy in the subfolder remains the installation’s own entry file; the root copy is the public front door.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsSubfolder-facing site: keep the entry point with WordPress
Move the complete installation into the destination and leave its index.php and rewrite configuration there. Do not copy a second front controller to the root unless you also intend to serve the site from the root. A root-level index file left over from the old arrangement can send requests to the wrong bootstrap path.
Match the rewrite configuration to your server
Use the documented configuration for the server and the arrangement you selected. Apache commonly uses .htaccess; nginx uses a server-block configuration; IIS uses web.config. The important details are the request base and the filesystem location: a root-facing site must send root requests to the WordPress installation in the subfolder, while a subfolder-facing site must route requests under that subfolder.
- For Apache, put the copied root
.htaccessin the root-facing layout’s web root and retain the installation’s configuration in the subfolder as required by the WordPress setup. - For nginx, update the relevant
locationandtry_filespaths in the server block, then reload nginx using your host’s normal service procedure. - For IIS, place the rewrite rules in the location that receives the public requests and ensure the subfolder path is represented correctly.
Do not blindly combine root and subfolder rules from different layouts. A rule that is correct inside /wordpress can create a loop or prepend the folder twice when copied to the root.
Regenerate permalinks after the site loads
- Open the public homepage and one known post or page.
- Sign in to the dashboard at the URL appropriate to the new layout.
- Go to Settings > Permalinks.
- Leave the selected structure unchanged and click Save Changes.
Saving the screen rebuilds the rewrite rules for the active server integration. It does not rewrite old absolute URLs stored in posts or plugin settings, so complete the database and content checks below as a separate task.
Free tools Windows power users keep installed
One-click scans. No signup required.
Repair stored paths, media, and generated URLs
The migration can be technically correct while content still points to the former location. Search for the old path in the database and in exported content, taking special care with serialized PHP data. A plain text replacement can corrupt serialized lengths and break widgets, theme settings, or plugin options.
Rank #4
Use a serialization-aware replacement method
- Make a fresh database backup immediately before the replacement.
- Search for the old base URL and, where relevant, the old installation path.
- Use a migration or search-and-replace tool that understands serialized data, or run a carefully tested command-line/database procedure that does so.
- Run a dry run or report first, review the affected tables, then perform the replacement.
- Clear page caches, object caches, and CDN caches after the replacement.
For a root-facing site, public links may already be correct even though plugin settings or media metadata contain /wordpress. For a subfolder-facing site, references that formerly began at the root usually need the new subfolder included. Do not replace every occurrence of a word such as “wordpress” indiscriminately; target the exact old URL or path.
Check these outputs manually
- Images, galleries, and downloadable media.
- Theme CSS, JavaScript, fonts, and favicon files.
- Canonical tags, pagination links, feeds, and XML sitemaps.
- Login, password-reset, comment, and search forms.
- Embedded video or iframe URLs and any hard-coded links in menus or widgets.
Validate the migration before declaring it finished
Test in a private browser window and, if possible, from a second network so cached redirects do not hide mistakes.
- Load the homepage over HTTPS and confirm the browser stays on the intended public URL.
- Open an old post, a page, an attachment, a category, a tag archive, and a search result.
- Log in and log out; verify that the dashboard, media library, editor, and preview links work.
- Inspect the page source or browser network panel for requests to the old folder, unexpected HTTP URLs, 404 responses, or repeated redirects.
- Submit a test form and check that transactional email links use the correct base URL.
- Review the canonical URL, feed address, robots output, and XML sitemap location.
- Check server error logs for PHP include failures, permission errors, rewrite loops, and missing files.
Troubleshoot the common failure modes
The dashboard or homepage redirects repeatedly
Compare both URL fields character for character, including protocol, hostname, trailing slash policy, and subfolder. Check whether WP_HOME or WP_SITEURL in wp-config.php overrides the dashboard values. Then inspect the root and subfolder rewrite rules for a rule that adds the folder twice.
Every post returns a 404 but the homepage works
Save Settings > Permalinks again. If that does not help, verify that the server has the correct rewrite module or server-block rules and that the rule file is in the directory receiving the request. On nginx and IIS, changing a WordPress .htaccess file alone has no effect.
CSS, JavaScript, or images are missing
Inspect one failed request and note whether it contains the old folder, the folder twice, or an HTTP URL on an HTTPS site. Correct the stored URL using a serialization-aware method, then clear caches. Also verify that the moved files retained their ownership and readable permissions.
Best Value
The site shows a database or “Error establishing a database connection” message
A file move does not normally change database credentials. Restore the previous wp-config.php from your backup or compare its database name, user, password, host, and table prefix with the original. Do not overwrite a working configuration with a fresh package copy.
You are locked out after saving the new addresses
Use the configured WP_HOME and WP_SITEURL constants temporarily, or correct the values directly in the database using your hosting control panel. Once you can sign in, remove temporary overrides if they are no longer needed and save the intended URLs in Settings > General.
Remove temporary migration settings and keep a rollback plan
Do not leave RELOCATE in wp-config.php. WordPress warns that, in some configurations, leaving it enabled can allow an attacker to change the site URL. Remove the line after recovery or migration work is complete.
Keep the old files and database backup until you have verified posts, media, forms, scheduled tasks, feeds, and search-engine-facing URLs. If the new arrangement fails, restore the original files, restore the database backup taken before the URL change, and return both address fields to their original values. Roll back as one coordinated operation; restoring only the files while leaving the new database URLs can produce the same redirect and missing-file symptoms.
Root-facing or subfolder-facing: which should you use?
Choose a root-facing site when
- You want visitors and search engines to keep using the existing root URLs.
- You want WordPress core files separated from other files in the web root.
- You are prepared to maintain a root entry point and matching rewrite rules.
Choose a subfolder-facing site when
- You want the installation’s physical and public paths to match.
- Changing every public URL to include a subfolder is acceptable.
- Your server or deployment process is easier to manage with the entire application under one directory.
Neither layout is inherently safer. The reliable choice is the one whose public URL, rewrite rules, deployment process, and stored links you can maintain consistently.
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.
Recommended Free Tools
