Visit Website →
← Back to blog

One Day Staging and WP-CLI Safety to Move WordPress to a Subdirectory

October 3, 2026
One Day Staging and WP-CLI Safety to Move WordPress to a Subdirectory

If you want your site to keep loading at the same address while the core files live in a subfolder, use Method I. If you want the public URL to actually change to example.com/subdirectory, use Method II. Either way, back up your files and database first, build a staging copy, and expect the exact commands to vary slightly between Apache, nginx, and IIS.

TL;DR:

  • Moving WordPress to a subdirectory keeps the URL unchanged but requires updating the index.php and permalinks to ensure smooth access.
  • Changing the public URL to a subdirectory needs a database search-replace and careful editing of WP_HOME and WP_SITEURL to prevent broken links.
  • Backups, staging, and disabling caching are crucial steps before migration to avoid data loss and simplify troubleshooting.
  • Server-specific rules for Apache, nginx, and IIS require different configurations, with plugins typically handling permalink rewriting on Apache.
  • Post-migration checks should include flushing permalinks, updating internal links, setting redirects if needed, and cleaning the database of leftover references.
inSave Hosting
Move WordPress With Less Risk
Build a staging copy and manage WordPress securely with hosting designed for smoother deployment, testing, migration, and ongoing site management.
Explore WordPress hosting

Table of Contents

Method I vs method II: keep the URL or change it

Method I moves WordPress core files into a subdirectory but keeps the public address at the root domain, so visitors never see a change. Method II moves the files and changes the public URL itself, so your homepage becomes example.com/blog or similar. Both are documented in the WordPress Developer Handbook, which covers the file structure and server rules for each.

Pick based on your goal, not habit:

  • Choose Method I when you want cleaner file organization or multiple apps sharing a domain, with no visible change.
  • Choose Method II when you're intentionally restructuring your site, such as folding a blog into a larger property.
  • For SEO, subdirectories generally consolidate authority under one domain better than subdomains, since a subdomain often needs to build its own signals separately.

Get ready: backups, staging, and a prep checklist

A reversible migration starts before you touch a single file.

  1. Take a full file and database backup, and confirm you can restore it before proceeding.
  2. Clone the site to a staging environment so every step below can be rehearsed first.
  3. Disable caching plugins and pause any CDN so you're not testing against stale pages.
  4. Write down current permalink settings and your active plugin list in case you need to compare after the move.
  5. Turn on maintenance mode and schedule the work for a low-traffic window.
  6. Run any planned WP-CLI commands on staging first, especially search-replace, before touching production.

Pro Tip: Keep the staging copy live for a day after launch. It's the fastest way to compare behavior if something on production looks off.

Method I: relocate files but keep the same public address

This path keeps your visitors at the same URL while core files sit one level deeper on the server.

  1. Create a new subdirectory on your server, for example /wordpress.
  2. Move every WordPress core file and folder into that subdirectory, except index.php and .htaccess.
  3. Copy, not move, index.php and .htaccess from the subdirectory back to the root.
  4. Edit the copied root index.php so its require line points to /wordpress/wp-blog-header.php.
  5. Update the WordPress address (WP_SITEURL) to include the subdirectory while leaving the site address (WP_HOME) at the root, either in Settings or wp-config.php.
  6. Check file permissions match your previous setup, then flush permalinks from Settings > Permalinks.
  7. Load the homepage and wp-admin to confirm both resolve normally.

Copying index.php, rather than moving it, means the version at the root survives when WordPress core updates files inside the subdirectory install.

This pattern is the standard sequence described in practical subdirectory migration walkthroughs, and it avoids a second edit every time core updates.

Method II: move files and change the public URL

This path is for a deliberate restructure where the address itself becomes example.com/subdirectory.

  1. Create the subdirectory and move the WordPress files into it, including index.php and .htaccess this time.
  2. Update WP_HOME and WP_SITEURL, either as constants in wp-config.php or through Settings > General, to the new subdirectory address.
  3. Run a database search-replace to update stored URLs, using WP-CLI rather than a manual find-and-replace tool.
  4. Verify menus, widgets, and internal links that may still point to the old address.
  5. Test the entire flow on staging before repeating the steps on production.

A typical command looks like:

wp search-replace 'https://example.com' 'https://example.com/subdirectory' --all-tables

WP-CLI's wp search-replace command is built to preserve serialized data during URL changes, which matters because a naive find-and-replace in phpMyAdmin can corrupt serialized arrays stored by themes and plugins. Setting WP_HOME and WP_SITEURL as constants also protects you from getting locked out if a database value is briefly wrong, since the constants override the stored option until you fix it properly.

Server-specific rules for Apache, nginx, and IIS

Each web server handles the rewrite rules differently, and none of them are interchangeable.

ServerConfig fileKey behavior
Apache.htaccessWordPress can usually rewrite this file itself after you flush permalinks
nginxserver blockRequires manual edits to try_files and PHP handling, then a service reload
IISweb.configUses XML rewrite rules that WordPress can generate, but they must be placed correctly to take effect

Apache setups benefit most from WordPress's own permalink flush, which rewrites the .htaccess rules automatically for either method. Nginx is the one platform where WordPress won't touch the config for you: you edit the server block's try_files and location rules directly, then reload the service. IIS relies on web.config rewrite rules that WordPress can format, but Windows hosts still need those rules pasted in by hand. If you're running multisite, subdirectory installs add their own rewrite patterns on top of these, so test thoroughly before rolling changes to production. Whatever platform you're on, copy the existing config file somewhere safe before editing it.

After the move: permalinks, mixed content, and redirects

A move isn't finished until you've confirmed the site behaves the same as before, or better.

  • Flush permalinks again from Settings > Permalinks so WordPress rewrites .htaccess to match the new structure.
  • Run a full mixed-content scan and replace any hardcoded HTTP links left in theme files or old posts.
  • Regenerate your sitemap and resubmit it in Google Search Console so crawlers pick up the new paths.
  • Set 301 redirects from old URLs to new ones if you used Method II, so bookmarks and backlinks still resolve.
  • Watch crawl errors and analytics closely for a week, since traffic drops after a URL change usually show up fast if something's wrong.

A migration consultancy's site migration SEO checklist is a useful second pass if you're mapping a large number of URLs.

What to do when something breaks

Most post-move failures trace back to the same handful of causes.

  1. If wp-admin is unreachable, set WP_HOME and WP_SITEURL directly in wp-config.php, or correct them with a WP-CLI database update.
  2. If every page returns a 404, restore the previous .htaccess file and flush permalinks again.
  3. If the homepage looks broken or half-styled, clear any CDN and browser cache before assuming the move failed.
  4. If none of the above resolves it, restore the full file and database backup you took before starting.
  5. After rolling back, reload the homepage, wp-admin, and one inner page in a private browser window to confirm the site matches its pre-move state.

Keep the rollback plan written down before you start. Reading it mid-incident wastes the minutes that matter most.

A low-risk testing workflow

Run the whole move on a staging copy first, including any WP-CLI search-replace commands, and check theme, plugin, and caching behavior before touching production. Staging environments exist for exactly this kind of rehearsal, and a host that includes free migration support can catch mistakes before visitors ever see them.

Pro Tip: Test your contact forms and checkout flow on staging too. URL changes quietly break form actions more often than people expect.

WordPress staging migration testing workflow

Cleaning up the database after the move

Changing URLs touches more of the database than most people expect, and leftover references cause problems weeks later if you skip this step. After a search-replace run, check your postmeta and options tables for any remaining references to the old address that the replace missed, particularly inside plugin settings stored as serialized arrays. Widget configurations, SEO plugin settings, and page builder data are common places where an old URL survives because it was double-serialized or stored in a custom table the search-replace command didn't target.

It's also worth clearing out orphaned data that accumulates from the move itself. Transients left over from before the migration can hold cached URLs that no longer match your site, and stale transients are safe to delete since WordPress regenerates them as needed. If your media library used absolute URLs in post content, confirm the replace command updated those too, since a missed reference shows up as a broken image rather than a broken link, which is easy to overlook during testing.

Once you've confirmed the data is clean, running your database's own optimization command (many hosting control panels expose this, or you can use phpMyAdmin's "Optimize table" option) reclaims space left behind by the update operations. This isn't required for the site to function, but it keeps the database from carrying dead weight indefinitely.

Cleaning up the database after the move — overview diagram

When to do this yourself vs hire migration support

Small sites with a staging copy are fine to move yourself. Larger stores or multisite networks carry more risk, so weigh the time against hiring help.

— Ihor

Get help if the move feels bigger than your weekend

If you'd rather not spend a weekend testing rewrite rules, a host that includes free migration support can do the file move and URL update for you. WordPress hosting plans include staging tools and migration support, so you can test the subdirectory change on a clone before it touches your live site. The same staging approach works whether you're consolidating a blog into a subdirectory or just reorganizing files for a cleaner setup. inSave Hosting Shared hosting plans are also available if your site is small enough not to need a dedicated WordPress stack, and both options come with free SSL and standard uptime and security practices applied across plans. Check the shared hosting plans if you're starting from scratch rather than migrating an existing install.

Sources

FAQ

How do I migrate a WordPress site manually?

A manual migration means copying your files via FTP or SSH, exporting the database, and importing both to the new location before updating the site URL. It's the same process described above for moving into a subdirectory, just applied to a full host change rather than a folder change.

How do I move WordPress to the root directory?

Reverse the subdirectory steps: move the core files up to the root, copy index.php and .htaccess if they're not already there, and update WP_HOME and WP_SITEURL to the root address. Run a WP-CLI search-replace if the public URL itself is changing, then flush permalinks.

Can you drag and drop files in WordPress?

You can drag and drop files through an FTP client or your host's file manager, but WordPress itself doesn't offer a built-in drag-and-drop for moving core files between directories. Database updates and permalink flushes still need to happen separately after the file move.

How do I set up a subdirectory for WordPress?

Create the folder on your server, move or copy the WordPress files into it depending on which method you're using, and update the site's URL settings to match. The WordPress Developer Handbook walks through the exact file placement for both the no-URL-change and URL-change approaches.