WordPress installed in a subdirectory serves the site at example.com/blog/ or example.com/wp/. Moving it to the root changes every address on the site, which makes this a job with a right order and a wrong one.
Two ways, and one is much safer
Serve from the root without moving the files. WordPress stays where it is; the site answers at the root. Fewer files move, so less can break, and it is the method WordPress itself documents.
Move the files to the root. Everything ends up where a fresh install would put it. Tidier, and more to go wrong.
Use the first unless you have a specific reason to want the files at the root.
Before anything: back up
Files and database, and confirm the backup is somewhere you can reach if the site is broken.
This changes the site address, and getting it wrong locks you out of the admin area, which is exactly when you discover whether the backup was real. Managing WordPress backups has the detail.
The safe method, step by step
In Settings → General, leave WordPress Address pointing at the subdirectory and change Site Address to the root:
WordPress Address: https://example.com/wp Site Address: https://example.com
Save. You will be logged out, which is expected.
Then copy two files: index.php and .htaccess: from the subdirectory to the root. Copy, do not move: the originals stay where they are.
Edit the copied index.php at the root. Find the last line and add the subdirectory to the path:
require __DIR__ . '/wp/wp-blog-header.php';
That one edit is what makes the root serve the site. Admin stays at example.com/wp/wp-admin/, which is normal for this arrangement.
Finally, go to Settings → Permalinks and press Save without changing anything, so the rewrite rules are regenerated for the new address. There is more on why that step matters in permalinks and .htaccess.
The addresses in your content do not move
The part people underestimate, and it applies to both methods.
Changing the settings changes what WordPress generates. It does not change addresses stored inside your content: every image inserted into a post, every internal link written in a page body, every widget and page-builder layout still contains /wp/.
Those need a search and replace across the database, and it cannot be a plain SQL REPLACE. Serialised data records its own string lengths, and a plain replace leaves those wrong, which corrupts theme options and builder layouts. The symptom is settings reverting to defaults for no visible reason.
Use a tool that understands serialised data, then remove it afterwards. Changing the WordPress site URL explains this in full.
Redirect the old addresses
Every indexed URL, every inbound link and every bookmark still points at /wp/. Without redirects they all break.
A single rule handles the whole tree:
RedirectMatch 301 ^/wp/(.*)$ /$1
Place it carefully. With the safe method the subdirectory still holds WordPress, so a redirect that catches admin requests will break the admin area: test the login before assuming the rule is correct.
Redirect to the equivalent page rather than the homepage. Sending everything to the homepage is treated as pages that vanished rather than moved.
If you move the files instead
Move everything from the subdirectory to the root, then set both address fields to the root.
Two things to fix afterwards. wp-config.php may contain a defined path or explicit address constants, which override the database and will still point at the subdirectory. For that, see understanding wp-config.php.
And the old .htaccess in the root, if the root already had one, may conflict with the WordPress rules. Merge them deliberately rather than overwriting one with the other.
If you are locked out
The common outcome of getting the address wrong: the login page redirects somewhere that does not exist.
Add the constants to wp-config.php with the correct values. They override the database immediately, without any database access, and the site comes back on the next request:
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com/wp');
Log in, fix the settings, then remove the constants so the settings screen works normally again.
Check these five things
A single post, a category archive, and a paginated page. Each can break independently of the others.
Images on an older post, which is where content-stored addresses show up.
The admin login, at whichever address it now lives.
An old /wp/ URL, confirming it redirects rather than 404s.
And the site over HTTPS at the root, confirming the certificate covers it. Fixing mixed content warnings deals with the padlock breaking on old image URLs.
Expect a short dip
Search engines need to process the redirects, and rankings often move for a week or two afterwards. That is normal for any address change and recovers.
What does not recover on its own is a missing redirect. Keep the rules in place permanently rather than removing them once traffic settles, links from other sites do not get updated, ever.
Confirm the old addresses still resolve somewhere
Moving an installation changes every address on the site, and the old ones exist in search results, links and bookmarks. Before considering the move finished, request several of the old addresses and confirm each redirects to its new equivalent in a single step. Redirecting everything to the home page is the version of this that loses the traffic it was meant to preserve, since a visitor looking for a specific page is given a starting point instead. Capture the old address list from the sitemap before the move, because it cannot be reconstructed afterwards and it is the only source for building the mapping.