Moving a site from an address such as https://example.com/site/ to https://example.com/ changes both routing and stored links. Decide whether you want to physically move WordPress files or keep the application in its own directory while showing the website at the root. These are different configurations.
IN THIS ARTICLE
01 Check what already occupies the root
Back up the complete files and database. Inspect the domain's actual document root for an existing website, redirects, verification files and applications. Do not overwrite another installation or assume the folder is named public_html. Record the existing WordPress Address, Site Address and any corresponding configuration constants.
02 Plan a physical move
- Test the move on a copy and schedule a period with no content or transaction changes.
- Prepare the destination directory and preserve required server configuration and hidden files.
- Move or copy the WordPress files to the verified document root using the planned migration method.
- Set the installation and public site addresses to the new location, accounting for configuration overrides.
- Perform a serialisation-safe replacement of the old content URL with the new URL, using a preview and excluding GUIDs.
- Refresh the appropriate permalink rules and add redirects from the old public paths to their matching new pages.
Can the files stay in the subdirectory?
Yes, WordPress supports an arrangement where its application files remain in a separate directory while the public Site Address uses the root. Follow the official directory method for your server and configuration. In that arrangement the WordPress Address and Site Address may intentionally differ, so setting both to the root can break the site.
How do I avoid redirect loops?
Use one documented routing plan. Review WordPress address settings, root and subdirectory rewrite files, hosting redirects and CDN rules together. A rule that sends every root request into the subdirectory can conflict with a rule that sends the subdirectory back to the root. Keep recovery access through the hosting file manager or SSH.
Confirm the expected result
Test login, administration links, images, forms, feeds and several old deep URLs. Check that the old path reaches the intended replacement in a short redirect chain. Update menus, canonical settings and sitemaps, then retain the previous backup until the root installation has passed normal business checks.