How to move WordPress from a subdirectory to the root of your domain

A site at example.com/wordpress/ can be made to answer at example.com in two ways. You can leave the files in the folder and change only where the site answers. Or you can move the files to the root and change every address the site has.

The first is the smaller job and is easy to undo. The second leaves nothing behind in the folder, but the dashboard and every image get a new address, so the database has to be updated too. Either way, old links into the folder have to keep working. The steps here are for a single site, not a multisite network.

Which of the two jobs you have

Choose route A when the folder is only untidy and all you want is the site at the root. Choose route B when the folder has to go: its name must not show anywhere, not even in the address of an image, or you are settling the site's layout for good.

Look under Settings, then General before you decide. If "Site Address (URL)" already shows the root and "WordPress Address (URL)" shows the folder, route A is already in place.

Before you start

• Back up the files and the database, both. How to schedule automatic WordPress backups covers what a full backup holds. Route B changes the database in a way that only a backup undoes.
• Try it on a staging copy first, where you can. How to set up a WordPress staging site has three ways to make one.
• Look at what is in the root now. If it holds an index.php, an index.html or a .htaccess, download copies. Both routes put files of those names there. If another site runs from the root, this move would replace it.
• Write down the two addresses exactly as Settings, then General shows them now.

Route A: leave the files where they are

These are the steps in WordPress's documentation, for a site that is already in a folder. The folder in the examples is wordpress. Use your own.

Open https://example.com in a private window. The home page and a post should load at the root, with their images.

nginx has no .htaccess, and WordPress cannot change its configuration. On nginx, the line in the site's server block that hands addresses to WordPress has to name the index.php in the root, as in WordPress's own example: try_files $uri $uri/ /index.php?$args;. On managed hosting, ask the host.

What still lives under the folder. The dashboard, the login page, every uploaded file, and the theme and plugin files. So do not run a search and replace of the folder's address on this route. It would rewrite the addresses of images that have not moved. Links you typed by hand, such as custom links in a menu, still name the folder. Correct those one at a time.

To undo it, set "Site Address (URL)" back to the folder's address, remove the two files from the root, and put back anything that was there before.

Route B: move the files to the root

The order matters. WordPress's instructions are to set the addresses before the files are moved, and not to open the site in between.

Redirect the old addresses

Every old link and every search result still points into the folder. Google counts a change of path on the same domain as a site move. Its guidance is a permanent, server-side redirect from each old address to its own new one, never from all of them to the home page.

After route B: the whole folder

RewriteEngine On
RewriteRule ^wordpress(/.*)?$ https://example.com$1 [R=301,L]

On Apache, put the two lines in the root's .htaccess, above the line # BEGIN WordPress. On nginx, the line goes inside the site's server block, and nginx has to be reloaded. /wordpress/hello-world/ then answers with a 301 to /hello-world/.

The rule catches every address that begins with the folder's name. If the site is to have a page at that same address, such as a page of posts at /blog/ after a move out of /blog/, a rule for the whole folder cannot be used. Redirect the old addresses one by one. The redirect map builder turns a list of old and new addresses into 301 redirect rules for Apache or nginx, with chains, loops and duplicates pointed out. Use it too when addresses change in more than their first part.

After route A: only what is not a real file

On route A the folder is still in use, so a rule for the whole folder would cut off the dashboard and the images. WordPress's instructions say nothing about old links to posts under the folder. Check one first, as described below. If it does not arrive, add a rule that redirects a request only when it matches no real file or folder.

RewriteEngine On
RewriteRule ^$ https://example.com/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

On Apache these lines go in the .htaccess inside the folder, not the one in the root, above # BEGIN WordPress. In a folder's own .htaccess, Apache matches the pattern against the part of the address after the folder's name. On nginx, the three blocks take the place of any location /wordpress/ block the server block already has.

To undo either rule, remove the lines you added.

Check each one

Put an old post's address, an old image's address and the folder itself into the redirect checker. It shows what an address answers and every redirect on the way: each hop, its status code and where it sends you next. Each should reach its new address in one hop, with a 301. The one exception is an image after route A, which answers 200 where it is. How to set up redirects in WordPress covers writing rules, and what to do about chains and loops.

What to check afterwards

• Pages, logged out. In a private window, open the home page, a post, a page and a category. If the home page loads and everything else answers 404, save the permalinks again. How to fix 404 errors on posts and pages that exist has the rest.
• Images. Open a few older posts. After route B, a missing image means its old address is still stored. Repeat the dry run for the other forms the address has had, such as http:// or www.
• The dashboard. Log in, open a post in the editor and save it.
• Forms. Send a message through each form and see that it arrives. On a store, place an order.
• Menus. WordPress's instructions warn that menu links may still hold the old folder. Open each menu and correct them.
• The sitemap. WordPress's own is at /wp-sitemap.xml, unless an SEO plugin provides another. Its addresses should not name the folder. Submit it in Google Search Console. Google says its Change of Address tool is not needed for a move of paths on the same domain.

If the dashboard will not load

A mistyped address, or files moved before the addresses were set, leaves the dashboard unreachable. Nothing is lost. Two constants in wp-config.php overrule what is in the database: WP_HOME for the Site Address and WP_SITEURL for the WordPress Address. Add them above the line that says "That's all, stop editing!", using your host's file manager or SFTP. These are the values for route A:

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

For route B, both are https://example.com. To go back to how things were, with the files still in the folder, both are https://example.com/wordpress.

The constants do not change the database, and while they are there the two fields under Settings cannot be edited. Once you are in, put the right values in the database and remove the lines. How to change your WordPress URL has each way of doing that. If the login page keeps coming back, work through the login page that keeps refreshing.

WordPress also documents a RELOCATE constant, which sets the WordPress Address to wherever you open wp-login.php and corrects nothing else. Its documentation calls leaving that line in place insecure. The two constants above do the job without that risk.