Uninstalling WordPress From a Domain
A WordPress install is three things in three places: files, a database, and a domain pointing at them. Remove one and forget the others and you are left with debris that quietly costs you money or leaks data.
Before anything else: open wp-config.php and write down the database name, database user and table prefix. Once the files are deleted you have no reliable way to work out which of the databases in your account belonged to this site, and people routinely leave an orphaned database behind for years — or drop the wrong one.
Uninstalling is not one action. WordPress occupies three places at once, and a clean removal has to account for all three.
The three parts of an install
| Part | Where it lives | What happens if you skip it |
|---|---|---|
| Files | A directory on the server, usually the domain's document root | Old code stays reachable and stays a security liability |
| Database and its user | The database server, under a name set in wp-config.php |
An orphaned database consumes quota and holds your data indefinitely |
| Installer record | The auto-installer or application manager that created the site | The panel thinks the site exists, and may keep trying to update it |
| Domain mapping | The hosting account's domain settings | The domain serves a directory listing or an error page |
Most half-done uninstalls come from deleting only the files. The site disappears, so it feels finished, while the database sits there with every user account and password hash still in it.
Know what you are destroying
Deleting a WordPress install destroys the content, permanently and without a recycle bin: posts, pages, comments, user accounts, plugin configuration, orders and form submissions in the database, plus every image and document in the uploads folder.
It does not touch the domain registration, the hosting plan, other sites in the same account, or mailboxes on that domain. Those are separate things, cancelled separately — and confusing them is how people lose a domain they wanted while trying to remove a site they did not.
Take a backup, download it, open it
The backup rule that matters here is that it must leave the server. A backup sitting in the account you are emptying is not insurance.
- Back up files and database together. How to back up a WordPress site covers both the manual and plugin routes.
- Download it to your own machine or your own storage.
- Verify it. Open the archive:
wp-content/uploadsshould be present and populated, and the SQL dump should containCREATE TABLElines and recognisable content — not a truncated file or an error message. - Export anything you will want to read, such as orders or subscribers, as CSV. A SQL dump is for restoring, not for looking things up.
If you intend to rebuild the site elsewhere, restore the backup at its destination and load the homepage before you remove the original. That is the only real test.
Remove it with the tool that installed it
Where WordPress was installed by the host's one-click installer or application manager, use that same tool to remove it. Panels are reorganised constantly, so look for the concept rather than a menu path: a list of installed applications or WordPress sites, with a management view per site and a remove or uninstall action inside it. Hostinger, cPanel-based hosts and most managed platforms all present some version of this.
The point of using the installer is that it clears its own record and usually offers to remove the database as well. Read that confirmation dialogue rather than clicking past it — some remove files only.
Removing it by hand
When there is no installer entry, do it in this order:
- Note the database details from
wp-config.phpif you have not already. What each wp-config.php setting means identifies the right lines. - Delete the site's files, including hidden ones such as
.htaccess. Delete the contents of the document root rather than the root directory itself, unless you are also removing the domain from the account. - Drop the database and its dedicated user. Leaving the user behind leaves valid credentials in circulation. Deleting a WordPress database covers doing this without taking out a neighbouring site.
- Check for other installs. A staging copy, a
/blogsubdirectory or an old subdomain often shares the account and gets missed. - Cancel scheduled tasks the site created at server level, if any.
Leave the domain in a deliberate state
An emptied document root frequently serves a directory listing of whatever is left, or a raw server error. Neither is a good look, and both invite probing. Put something intentional there: a single static holding page, a redirect to wherever the content moved, or a fresh install if that was the plan — installing WordPress from a hosting panel covers starting clean.
Then leave the rest alone. The domain stays registered, the hosting stays active, and email keeps working — until you deliberately change those. If the plan is to close the account entirely, do that last and read deleting a WordPress domain first, because that step is the one that is genuinely hard to reverse.
Frequently asked
- No. The domain is a registration held with a registrar and is entirely separate from what is installed on the hosting. After the uninstall it stays registered, stays on its renewal date, and simply stops serving a website until you point it at something.
- You can, but it leaves the database, its database user and the auto-installer's record of the site behind. Read wp-config.php first to note the database name, because once the files are gone you have no easy way to tell which of several databases belonged to that site.
- Not from the uninstall itself, since mailboxes are part of the hosting account rather than the WordPress install. Email breaks later, when someone changes DNS or cancels the hosting plan, so record the existing mail records before you change anything.