Deleting a self-hosted WordPress site is two commands: remove the web root and drop the database. The hard part is the eight things that survive both, because a half-deleted site still resolves, still runs cron, and still holds a database user with live credentials in a file you just threw away.
Start by working out which of four jobs you are actually doing. They are not the same operation and three of them are not deletion.
Which kind of delete do you mean?
A self-hosted install you own. Files in the web root, one database, one database user. This is the case the rest of this post is about.
A subsite in a multisite network. Network Admin deletes the subsite and drops its tables, and it leaves the subsite's uploads directory on disk. Covered below.
A WordPress.com site. Deleted from the Hosting Dashboard, recoverable for 30 days, and the address is gone permanently afterwards. WordPress.com's own support page is the one to follow, and note that deleting a site does not close your account or cancel a registered domain.
You want to start over, not delete. This is most of the people who search for this. A reset empties the content and keeps the install, which is a different and much more recoverable operation, and we wrote it up separately in how to reset a WordPress site.
If you are in the fourth case, stop here and go to that post. Deleting and rebuilding to get a clean slate costs you the install and the domain mapping, and a reset does not.
Take a copy you can actually open
Every guide says "back up first". Almost none of them say what to check, which is why people discover their backup is unusable the week after the site is gone.
A .sql file and a zip of wp-content is an archive, not a working site. You cannot tell from looking at it whether the export truncated mid-table, whether the serialized option data survived, or whether the theme still renders.
The only test that proves a backup is restorable is restoring it. Push the copy into a throwaway install, open the front page, log in to the admin, and click through the pages that matter.
This is what the SandyWP Cloner plugin exists for: install it on the site you are about to delete, click once, and the database and files land in a sandbox with a live URL and a working admin login. Then delete the original knowing the copy opens.
Delete the files and the database
With a verified copy in hand, over SSH:
wp db export ~/final-backup.sql
rm -rf /var/www/example.com/public_html
Export before you delete the files, not after. wp-config.php holds the credentials, so once the web root is gone WP-CLI has nothing to connect with.
Then drop the database and the user. The database first:
mysql -u root -p -e "DROP DATABASE example_wp;"
And the user, which is the step that gets skipped:
mysql -u root -p -e "DROP USER 'example_wp'@'localhost';"
If you are working in cPanel instead, MySQL Databases has both a delete control for the database and a separate one for the user. Deleting the database leaves the user, its password and its grants in place.
What survives all of that
Here is the list that none of the current first-page guides covers. Work through it after the files and database are gone.
1. The database user and its grants. Covered above, and worth repeating because it is the only leftover that is a security problem rather than a tidiness problem. Its password was in a wp-config.php file that may now be sitting in an unencrypted backup.
2. The server cron job. If anyone disabled WP-Cron and wired up a real cron entry, that entry is still in the crontab, still firing, and now logging a fatal error on every run. Check with crontab -l for a line calling wp-cron.php or wp cron event run, and see how WP-Cron actually works for why the entry exists at all.
3. The DNS records. Files gone, A record still pointing at the server. The domain now shows whatever the server serves for an unmatched host, which is often another site on the same box or a default Apache page.
4. The virtual host or server block. Nginx and Apache do not care that the document root no longer exists. The config still claims the hostname, and on Apache a stale block can shadow a site you add later.
5. The TLS certificate and its renewal. Certbot keeps trying to renew a certificate for a domain that no longer validates, and you get failure mail every few days until you run certbot delete --cert-name example.com.
6. HSTS in browsers. If the site ever sent an HSTS header with a long max-age, every browser that visited it will refuse plain HTTP for that domain for the rest of the policy's life. There is no way to reach back and clear that remotely.
7. The sending domain. SPF, DKIM and DMARC records, plus the domain's verified-sender status at whatever relay the site used. A verified sending domain with no site behind it is a useful thing for someone else to find.
8. The host's own backups. Most hosts keep daily snapshots for one to four weeks after you delete something. That is a feature when you change your mind, and it means "deleted" is not true yet if the reason you deleted was a data problem.
And a ninth, outside your server entirely: the pages stay in Google's index until it recrawls and gets a 404 or 410. You can speed that up with the Remove Outdated Content tool in Search Console, but only for URLs that genuinely no longer resolve.
Deleting a subsite from a multisite network
Network Admin, Sites, then Delete on the row. Or over WP-CLI:
wp site delete 4
That drops the subsite's prefixed tables, which is the behaviour --keep-tables exists to prevent. The WP-CLI documentation for wp site delete is explicit about that flag, and there is a --delete-tables-with-prefix flag for the stragglers that is still nightly-only rather than in a stable release.
What it does not touch is the files. wp-content/uploads/sites/4 is still on disk with every image the subsite ever had, served by a URL that no longer has a site to deny it.
Delete that directory by hand after the site record is gone. The same caveat applies to anything a plugin wrote outside the prefixed tables, because wp site delete only knows about tables carrying the subsite's prefix.
We have more on the structural side of this in subdomain versus subdirectory multisite.
Is wp site empty a delete?
No, and the gap is wider than the name suggests. The documentation says it empties posts, comments, terms, links and meta, and that it "doesn't affect site configuration (options) or users".
So after wp site empty you still have every plugin, every setting, every user account, and every uploaded file unless you pass --uploads. Custom tables a plugin created are untouched as well.
That is the right tool for clearing content out of a site you are keeping. It is the wrong tool if your goal was to make the site go away.
When deleting is the wrong answer
If you are deleting a site because it broke, you are destroying the evidence. A white screen, a fatal error or a plugin conflict is diagnosable on a copy in a few minutes, and the fix usually transfers back to the original.
If you are deleting a site because you need the hosting plan slot back, check the host's backup retention first. Getting a site back from a snapshot five weeks later is not a thing.
If you are deleting a site because it was a test, that is the real signal. Test installs should remove themselves rather than wait for someone to tidy up, which is the whole point of a disposable install: SandyWP sandboxes expire and delete themselves on a timer you set when you create them.
The checklist
- Clone the site somewhere you can open it, and open it.
wp db exportwhilewp-config.phpstill exists.- Delete the web root.
- Drop the database.
- Drop the database user.
- Remove the cron entry.
- Remove the DNS records.
- Remove the vhost or server block, and reload the web server.
certbot delete --cert-name <domain>.- Remove the sending-domain records and the relay's verified sender.
- Note when the host's snapshots expire, and diary that date.
Steps one and five are the two people skip, and they fail in opposite directions. Skipping one means you cannot get the site back, and skipping five means part of it is still reachable.
