Deleting a WordPress site involves removing both the WordPress files and the database associated with it. This process is irreversible once complete, so ensure you have backups of any important data before proceeding. That warning is worth taking seriously rather than treating as boilerplate, there’s no undo button once files are deleted from a server and a database has been dropped, and a surprising number of people only realize they wanted to keep something after it’s already gone.
Reasons People Actually Delete a WordPress Site
Getting clear on which of these situations you’re actually in before starting also determines how much weight to put on each step below. A quick throwaway staging site you spun up an hour ago to test a plugin conflict needs almost none of the caution that a five-year-old business site with real customer history and search rankings needs, worth calibrating your own pace and thoroughness to which end of that spectrum your specific situation falls on.
Before walking through the steps, it’s worth being clear about the different situations that lead someone here, because the right approach varies depending on which one applies. Some people are shutting down a test or staging site that served its purpose and is no longer needed. Some are consolidating multiple sites down to one and removing the redundant installs. Some are moving a site to new hosting and need to clean up the old server afterward. And some are shutting down a business or project entirely and want every trace of the site gone. The mechanical steps below apply to all four situations, but the backup and verification emphasis matters most for the first three, where there’s a real chance you’ll want some piece of the old site’s content or data again down the line, and matters least for the fourth, where the whole point is a clean, complete removal.
How to Delete a WordPress Site
1. Backup Your Data
- Before deleting your site, make sure to back up all your content, including posts, pages, and media files. You can use plugins like UpdraftPlus or manually download the files via FTP and export the database via phpMyAdmin.
Don’t treat this step as optional even if you’re fairly confident you’ll never need the site again. A full backup takes a few minutes and costs almost nothing in storage; reconstructing content you decided you needed after the site is already gone can cost hours or simply be impossible. If the site has any content with genuine long-term value, published articles that rank in search, customer records, order history, download a complete WordPress export (Tools > Export in the dashboard, or a full UpdraftPlus backup covering both files and database) and store it somewhere outside the hosting account you’re about to close, a local drive or a separate cloud storage account, not another folder on the same server you’re deleting.
2. Delete WordPress Files
- Access Your Hosting Account: Log in to your web hosting account and navigate to the file manager or use an FTP client.
- Locate WordPress Files: Find the directory where WordPress is installed. This is typically in the public_html folder or a subdirectory if you installed it in a subfolder.
- Delete Files: Select all WordPress files and folders, then delete them. This action removes all the files related to your WordPress installation.
A common mistake at this stage is deleting files for the wrong site on hosting accounts running multiple WordPress installs, shared hosting plans and some VPS setups often host several sites under the same account, distinguished only by subfolder or subdomain. Before selecting anything for deletion, confirm you’re looking at the correct directory by checking for a site-specific detail, the exact domain referenced in wp-config.php, or a distinctive theme or plugin folder you know belongs to the site you actually intend to remove. This confirmation step takes thirty seconds and prevents one of the more common, and more painful, mistakes people make with this process.
3. Delete the WordPress Database
- Access phpMyAdmin: Log in to your web hosting account and navigate to phpMyAdmin, which is typically found under the database section.
- Select the Database: Find the database associated with your WordPress installation. The database name is usually specified in the wp-config.php file of your WordPress installation.
- Drop the Database: Select the database and choose the option to “Drop” or “Delete” it. This action will remove all tables and data associated with your WordPress site.
Just as with file deletion, confirming you’ve selected the correct database matters enormously on a hosting account with multiple databases, dropping the wrong one takes seconds and there’s no confirmation dialog forgiving enough to save you from it. The database name and credentials are defined in wp-config.php under DB_NAME, worth opening that file (before you delete the WordPress files in step two, if you haven’t already) and noting the exact database name so there’s no ambiguity when you reach phpMyAdmin.
4. Remove Database User (Optional)
- If you want to completely clean up, you can also delete the database user that was associated with the WordPress database. This is done within the database management section of your hosting account.
This step is genuinely optional and mostly a matter of tidiness rather than necessity, an orphaned database user with no database to access doesn’t pose a meaningful security risk on its own. That said, if the hosting account has accumulated several old, unused database users over time from previous site deletions, cleaning them out periodically keeps the account’s user list legible and makes it easier to tell, months later, which credentials still correspond to something live.
5. Clear DNS and Domain Settings
- If you no longer need the domain associated with the WordPress site, you can remove or update DNS settings and domain registration. This step is optional but recommended if you’re also shutting down or repurposing the domain.
Worth separating two distinct decisions here that often get conflated: deleting the WordPress site itself, and giving up the domain name pointing at it. These aren’t the same choice, and it’s entirely reasonable to delete a site while keeping its domain registered, either to redirect it elsewhere, park it, or simply prevent someone else from registering it once it lapses. If you are keeping the domain but the site is gone, update the DNS A record or point the domain at a holding page rather than leaving it pointing at a server that no longer has anything to serve, a domain pointing at a dead IP address just produces a confusing connection error for anyone who visits.
6. Verify Deletion
- Visit your domain to ensure that the site has been removed and no traces of the WordPress installation are visible.
Do this from a genuinely fresh browser session, or an incognito/private window, rather than the browser tab you’ve had the site open in throughout this whole process, your own browser cache can show you a stale, cached version of the old site even after it’s actually gone, giving a false impression that deletion didn’t work. If you have access to a different network (mobile data rather than the connection you’ve been working from), checking there too rules out any local DNS caching giving a misleading result.
Deleting a Site From WordPress.com Instead of a Self-Hosted Install
Everything above describes deleting a self-hosted WordPress.org site, where you control the actual server files and database directly. If your site instead runs on WordPress.com’s hosted platform, the process is considerably simpler and handled entirely through their dashboard rather than a file manager or phpMyAdmin: from your WordPress.com site’s dashboard, go to Settings > General, scroll to the bottom, and use the “Delete Your Site Permanently” option. WordPress.com handles the underlying file and database removal on your behalf, you don’t have direct server access to do it manually even if you wanted to. Confirm which platform you’re actually running before following either set of instructions, since the self-hosted steps above won’t apply at all to a WordPress.com site, and there’s no file manager or phpMyAdmin access to follow them with.
What Happens to Email Accounts on the Same Hosting Plan
If your hosting account also manages email addresses tied to the same domain, deleting the WordPress site’s files and database doesn’t automatically remove those email accounts, they’re typically managed separately within your hosting control panel. Before assuming everything associated with the domain is gone, check your hosting account’s email management section specifically if you also intend to close those accounts, otherwise they’ll continue functioning (and potentially continue costing money, depending on your hosting plan’s billing structure) even after the WordPress site itself no longer exists.
Canceling the Hosting Plan Itself
Deleting the WordPress files and database removes the site, but it doesn’t cancel your hosting plan or stop billing, those are separate actions handled through your hosting provider’s account or billing settings. If the goal is to stop paying for hosting entirely, not just remove one site among several on a shared plan, follow through with an actual plan cancellation through your host’s billing dashboard after confirming the site deletion is complete. Skipping this step is a common way people end up paying for hosting on an account with nothing left running on it, worth a calendar reminder to double-check your next billing statement actually reflects the cancellation if you’re not confident the process completed correctly the first time.
SEO and Search Console Considerations
If the site being deleted had any real search traffic or was verified in Google Search Console, it’s worth a few extra steps before or immediately after deletion rather than just letting the domain go quiet. If you’re keeping the domain but retiring the site permanently, consider setting up a simple redirect to wherever that traffic should now go, rather than letting previously indexed pages start returning errors, which can take months to fully clear from search results and generates a poor experience for anyone still finding old links. If the domain itself is also being abandoned, there’s less to actively manage, but it’s still worth removing the property from Search Console on your end for your own account hygiene, even though Google will eventually deindex the dead pages on its own once it recrawls and finds nothing there.
A Pre-Deletion Checklist
Before executing any of the deletion steps above, it’s worth running through a short checklist rather than diving straight into file manager or phpMyAdmin:
- Confirm you have a complete, verified backup (files and database both) stored somewhere outside the hosting account you’re about to modify.
- Confirm you’ve identified the correct site if the hosting account manages more than one WordPress install.
- Decide explicitly whether the domain is being kept, redirected, or also abandoned, rather than leaving that decision unmade until after the site is already gone.
- Check whether any email accounts on the same domain need separate handling.
- Note whether the hosting plan itself needs canceling, or whether this is one site among several staying on an active plan.
Deleting a WordPress site is a straightforward process but requires careful handling to ensure all associated data is removed. Always back up important information before starting, and follow each step meticulously to ensure a complete deletion. If you’re unsure or uncomfortable with performing these steps, consider reaching out to your hosting provider for assistance, most hosts are willing to walk through or even perform a site deletion directly on request, particularly if you’re also canceling the underlying hosting plan.
Deleting a Local Development Site
Everything covered so far assumes a live site on a remote hosting server, but the same underlying logic (delete the files, delete the database) applies to a local development environment too, with a somewhat lower-stakes process since nothing is publicly reachable in the first place. In a tool like Local by Flywheel, XAMPP, or a Docker-based setup, deleting a site typically means removing the site through the tool’s own management interface (Local, for instance, has a straightforward “Delete Site” option in its site list) rather than manually hunting down files and a database separately, though the underlying mechanism, removing site files and dropping the associated database, is conceptually the same. The lower stakes of a local environment don’t mean backups are irrelevant, if a local site contains work you might want again, the same “back it up before deleting” principle still applies, just without the added risk of touching a live, publicly accessible server in the process.
Deleting a Site on Managed WordPress Hosting
Managed WordPress hosts (WP Engine, Kinsta, and similar providers) generally don’t expose raw file manager and phpMyAdmin access the way traditional shared hosting does, since these platforms manage the underlying server infrastructure on your behalf. On these hosts, site deletion is handled through the host’s own dashboard, usually a straightforward “remove” or “delete site” action within their site management panel, rather than the manual six-step process described above. If you’re on a managed host and can’t find phpMyAdmin or a traditional file manager at all, that’s expected, not a sign something’s misconfigured, check your specific host’s dashboard for their equivalent site-deletion tool instead of trying to force the traditional shared-hosting workflow onto a platform that doesn’t expose those same controls.
Quick Answers
Can I recover a WordPress site after deleting it? Not without a backup taken beforehand. Once files are deleted from the server and the database is dropped, there’s no built-in recovery mechanism, which is exactly why the backup step at the start of this process isn’t optional.
Does deleting a WordPress site free up disk space immediately? Generally yes, once files are deleted and the database dropped, the space is returned to your hosting account’s available storage, though some hosts show this update with a short delay rather than instantly in the account dashboard.
Do I need to deactivate plugins before deleting the site? No, deactivating plugins first isn’t necessary if you’re deleting the entire WordPress installation and database together, that removes plugins along with everything else regardless of their active or inactive state beforehand.
What if I only want to delete a subsite on a multisite network, not the whole network? That’s a different, narrower process than what’s described here, handled through the Network Admin dashboard’s Sites screen rather than direct file and database deletion, since a multisite network shares a single WordPress installation and a single (though multi-table) database across all its subsites.
Will search engines immediately stop showing my deleted site in results? No, deindexing takes time, Google and other search engines need to recrawl the URLs and notice they’re no longer returning content before removing them from results, which can take anywhere from days to several weeks depending on how frequently the site was previously crawled.
Is there a way to schedule a site for deletion rather than doing it immediately? Standard WordPress and typical hosting control panels don’t include a built-in delayed-deletion feature, if you want a buffer period before permanent removal, the safer approach is to first take the site offline (via maintenance mode or by removing DNS records) while keeping the files and database intact for a set period, then perform the actual deletion once you’re fully confident nothing further is needed from it.
Should I export my content to a different format before deleting, in case I want to reuse it on a different platform later? If there’s a real chance you’ll want the content again on a non-WordPress platform, exporting to a more portable format (a CSV of posts, or downloading media files directly rather than relying solely on WordPress’s native XML export) is worth the extra effort, since a WordPress XML export is really only directly useful for reimporting into another WordPress site.