Moving a WordPress site from a subdomain such as blog.example.com to the main domain is a location change, not a fresh install. Treat it as a planned migration: make a restorable backup, decide exactly which directory will serve the main domain, update the site address carefully, and test the public site before the former subdomain is redirected.
This guide is for a standard single-site WordPress installation. It is deliberately backup-first and panel-neutral, with specific checks for cPanel and Plesk. If the site is a WordPress multisite network, has complex e-commerce integrations, or already has a live root-domain site, schedule a reviewed migration instead of applying a generic checklist.
Start With a Recovery Point and a Written Cutover Plan
Make two independent, restorable backups before changing anything: one for the WordPress files and one for its database. Confirm that both archives exist, are complete, and can be identified later. Keep the current subdomain live until the new main-domain site passes the checks below.
Write down the intended final state before moving files:
- The public address visitors should use, including whether it uses
www. - The directory that the main domain will serve.
- The current WordPress directory, database, and active caching or security plugins.
- Any forms, payment flows, membership areas, email notifications, analytics, CDN rules, and third-party services that depend on the old address.
WordPress distinguishes the public Site Address from the location of the WordPress core files. Both must make sense together after the move. The WordPress migration handbook also warns that location changes can leave old references in content and settings, so do not treat a successful homepage load as the finish line.
Prepare the Root Domain Before Moving WordPress
First, confirm what currently answers for the root domain. A placeholder page, an old application, a parked domain, or an existing WordPress install can all conflict with the migration. Preserve any root-directory files that are still needed, especially existing redirects or verification files. Do not overwrite an existing production site simply because the directory name looks familiar.
In cPanel, review the main domain under Domains and verify its document root before you move content. The cPanel Domains documentation is the source of truth for the domain and document-root relationship in that panel. In Plesk, review Websites & Domains and Hosting Settings; its general hosting settings expose the document root and preferred-domain controls.
Make the DNS and TLS plan clear as well. Usually the existing root domain should already resolve to the right hosting account, but confirm the public DNS records, the correct site at the origin, and a valid certificate for the final address. For the HTTP-to-HTTPS part of the cutover, use the separate WordPress HTTPS guide instead of stacking several redirect changes into the same untested step.
Move the Site as a Controlled Location Change
- Put a short, approved maintenance notice in place only if the move cannot be made without a brief editing freeze. Avoid an open-ended maintenance page.
- Copy or move the complete WordPress application, including uploads, plugins, themes, and configuration files, from the subdomain directory to the verified root-domain directory.
- Update the WordPress Address and Site Address so they match the intended public main-domain address. WordPress documents these settings in Settings > General for a normal single-site installation.
- Use a migration method that understands WordPress data structures to update old address references. Do not perform a broad, blind database replacement. Preserve stable feed identifiers and review the result before calling the move complete.
- Clear application, page, object, and CDN caches after the address change. Cached redirects and old HTML can make a completed move look broken.
If the files and database are also changing hosts, follow the broader WordPress host migration checklist. If your move genuinely requires a manual transfer, use the existing manual migration guide as the more detailed companion, not as an excuse to skip the backup and verification steps here.
Test the Main Domain Before Redirecting the Subdomain
Open a private browsing session and test the final HTTPS address before changing the old subdomain. Check more than the homepage:
- WordPress login, dashboard access, and the General settings values.
- Several old posts, pages, category archives, and search results.
- Featured images, media-library images, menus, internal links, and downloadable files.
- Contact forms, transactional email, checkout, account, and payment workflows where applicable.
- Permalinks, page templates, caching, and any protected or member-only pages.
- Mobile layout and browser-console-free loading on the main pages.
Then test known old subdomain URLs. They should send visitors and crawlers to the matching main-domain page, not to a generic homepage. A redirect that loses the page path creates a poor visitor experience and makes troubleshooting harder. Use the WordPress 404 and redirects guide if any old links do not land where they should.
Finish the SEO and Operations Cleanup
Once the root-domain version is stable, choose one preferred public address and make the old subdomain consistently redirect to it. Verify the canonical URL, sitemap entries, robots access, and social preview metadata on the new pages. Update key external profiles, email templates, advertising destinations, and monitoring checks that still point to the subdomain.
Keep the old address monitored during the first days after the cutover. Watch for 404s, form failures, mixed-content warnings, certificate problems, unexpected login redirects, and support requests. Retain the backup until the site has been through a normal update and backup cycle at its new address.
When to Stop and Restore
Stop the migration and restore the proven copy if the main domain shows the wrong site, administration becomes inaccessible, key transactions fail, media loads from an unexpected location, or redirects create a loop. Record what was changed before retrying. A clean rollback is far better than leaving visitors on a partially moved WordPress site.
For the wider operational picture, start at the Fix I.T. Phill WordPress Support Guide. If the address move also includes a registrar or DNS-provider change, pair this checklist with How to Move a Domain to a New Host Safely.
