How to delete a WordPress site (self-hosted and managed)

Short answer: “Delete a WordPress site” means two completely different things depending on where the site lives. On WordPress.com, you click through their account settings and confirm. On self-hosted WordPress (your own hosting account), there is no single “delete” button – you take a final backup, drop the database, remove the files, clean up DNS, and either close the hosting account or reuse it for something new. Get the order wrong and you can leave a half-deleted site that costs money, exposes data, or breaks email for the domain.

This guide covers both paths. It also covers the smaller, related cases – deleting a single page, deleting a multisite child, and walking back from a delete you regret.

Quick reference#

If you are not sure whether you actually want a delete or just a temporary takedown, jump to Alternatives to deleting before doing anything irreversible.

WordPress.com vs self-hosted: which one are you on?#

The single most common confusion in this topic is people not knowing which platform they are on. Two minutes here saves you from following the wrong instructions.

If you log in at wordpress.com and pay them directly, you are on WordPress.com – the hosted product. If you log in at your own domain and pay a hosting company, you are self-hosted. The instructions below split clearly.

How to delete a WordPress.com site#

WordPress.com is a hosted product run by Automattic. When you “delete” your site there, you are asking Automattic to remove it from their servers. The interface is the same regardless of plan.

The full deletion flow

1. Log in at wordpress.com.
2. From the My Sites view, pick the site you want to delete.
3. Click Settings in the left sidebar.
4. Scroll all the way to the bottom of the General settings page.
5. Click Delete your site permanently.
6. WordPress.com offers a free export button on this page. Take it – this gives you an XML file of all posts, pages, comments, and media. You will need this if you ever want to rebuild somewhere else.
7. After exporting, click Delete site and type the site address to confirm.
8. The site is removed from WordPress.com immediately.

What actually goes away:

• All posts, pages, comments, and media uploads
• The site address (after a 30-day window during which it cannot be reclaimed by anyone)
• Any custom domain mapping
• Any active plan or upgrade tied specifically to that site

What stays:

• Your WordPress.com account itself (use account settings to close that separately)
• Any other sites on your account
• Any domain you registered through WordPress.com – that is yours and is managed separately
• Your purchase history and receipts

Closing your entire WordPress.com account

If you want to walk away from the platform entirely – not just one site – go to Account > Settings > Close account permanently. This deletes all your sites at once, releases all subscriptions, and removes your profile. Once closed, the username is gone forever and cannot be reclaimed by you or anyone else.

Before doing this, export every site separately. Closing the account does not export them for you.

“Deactivate” vs “delete” on WordPress.com

There is no soft “deactivate” toggle. WordPress.com has two real states for a site: active or deleted. The closest thing to a pause is changing site visibility to Private (Settings > General > Privacy), which makes the site invisible to non-logged-in users without removing any content. That is what most people mean when they say “deactivate” – they want it hidden, not destroyed. See Alternatives to deleting below.

How to delete a self-hosted WordPress site#

Self-hosted is where the work is. WordPress is just files on a server plus a database, so “delete” means removing both – in a specific order, after a backup, after handling the domain, and after thinking about who else still has links pointing at the site.

Before you delete: the five-minute checklist

Skip these and you will regret it within a week.

The backup is the only step that is genuinely irreversible if skipped. The rest are recoverable but expensive in time. The full delete process for a real production site usually takes 30-60 minutes if you do it carefully, mostly waiting for backups and exports to finish.

How long the actual delete takes

Once you have backed up, the deletion itself is fast. The slow parts are the prep and the post-delete cleanup.

Total realistic time: under an hour for a small site, half a day for a large WooCommerce site with thousands of products and a years-long backlink history.

Step 1: Take a final backup

This is non-negotiable. Even if you are sure you will never want the site back, take the backup. Use whatever tool you already trust:

• Hosting backup tool. Most hosts ship a one-click backup that captures files and database into a single archive. Take a fresh backup and download the archive locally before you delete anything.
• A backup plugin. UpdraftPlus, BackWPup, or Duplicator. Run a full backup and download the archive to your own machine.
• Manual. SSH or SFTP into the server, tar -czf the WordPress directory, mysqldump the database, then download both files.

Whichever route you pick, verify the archive locally before deleting anything. Open the tarball, confirm wp-config.php is in there, confirm the SQL dump opens. A backup you cannot read is the same as no backup.

Step 2: Export content separately

Even with a full backup, run the WordPress XML export from inside the dashboard. Go to Tools > Export > All content > Download Export File. This XML file is the easiest way to import the site’s posts, pages, and comments into a fresh WordPress install later. The full backup archive contains the same data but in a less portable format – the XML is the universally importable copy.

If you cannot reach the dashboard, recover access first – export is much easier from the UI than from the command line.

Step 3: Drop the database

If you only delete the files, the database keeps using disk space and stays connected to your hosting account. Drop it explicitly.

From the hosting control panel: open MySQL Databases, find the one tied to the site, and click delete. Confirm twice.

From the command line:

mysql -u root -p
DROP DATABASE wordpress_db_name;
DROP USER 'wordpress_user'@'localhost';
FLUSH PRIVILEGES;

If your host uses one shared database with prefixed tables, deleting tables instead of the whole database is safer:

SHOW TABLES LIKE 'wp_%';
-- Confirm only the right site's tables show up
DROP TABLE wp_posts, wp_postmeta, wp_users, wp_usermeta, wp_options, wp_terms, wp_termmeta, wp_term_taxonomy, wp_term_relationships, wp_links, wp_comments, wp_commentmeta;

The full default WordPress table list is 12 tables. Plugins add more (WooCommerce alone adds dozens). Use SHOW TABLES LIKE 'wp_%' to see the full list before you drop, in case you need to keep some.

Step 4: Delete the files

WordPress files live in whatever directory points at the site – usually public_html , www , or a subfolder. Three ways to remove them.

Via SFTP or a file manager: connect, navigate to the WordPress install directory, select all, delete. This is the safest path for non-technical users because you can see exactly what you are deleting.

Via SSH:

cd /path/to/wordpress
rm -rf wp-admin wp-content wp-includes
rm -f index.php license.txt readme.html wp-*.php xmlrpc.php

This pattern deletes only WordPress core and content, leaving the parent directory in case something else lives there. If you want to nuke the entire directory, cd up one level and rm -rf wordpress_directory_name – but only after triple-checking the name.

Via WP-CLI:

WP-CLI cannot fully self-delete (it cannot remove the wp-cli files it is using). Use it to clean up content first, then drop to SSH or SFTP for the file deletion.

Step 5: Clean up DNS

A deleted site that still has DNS pointing at the old server gives visitors a “this site can’t be reached” error – or worse, shows a generic hosting “site not found” page that looks broken. Update DNS so the domain either parks somewhere clean or points to a new destination.

Three common end states:

• Park the domain. Remove the A and AAAA records, or point them to a registrar’s parking page. Visitors see a clean “this domain is not in use” page.
• Redirect to another site. Point the A record at a destination server and configure a 301 redirect at the new server. Useful when you replaced the site with something else and want to preserve SEO equity from any backlinks.
• Let it expire. If you do not want the domain at all, just stop renewing. The domain enters grace period after expiration, then is released for re-registration.

If the domain was used for email, the MX records are separate from A records. Email keeps working as long as MX points at a working mail server. Deleting the website does not delete email – this trips up a lot of people.

For more on the moving parts, see How to migrate WordPress to another hosting provider – the DNS section there covers the same record types in detail.

Step 6: Cancel hosting (optional)

If the deleted site was the only thing on the hosting account and you do not plan to host anything else, cancel the hosting plan in your provider’s billing dashboard. Two warnings:

• Cancellation often deletes more than the website. Cancelling a hosting account usually removes email accounts, FTP users, MySQL databases, and any other site on the same plan. Make sure nothing else important lives there.
• Refunds are time-bound. Most hosts only refund within the first 30 days of a billing cycle. After that, cancellation just stops the next renewal.

If the hosting account hosts other sites, just delete the WordPress install and leave the hosting plan running.

Step 7: SEO cleanup (only if the site had traffic)

For a site with no inbound links and no search traffic, skip this section. For a site that ranked or had backlinks, leaving every old URL returning a generic 404 wastes the SEO equity.

Two ways to handle it cleanly:

• 301 redirects if you want to send the link equity to a successor site. Configure these at the new destination’s server, mapping old URLs to new ones.
• HTTP 410 Gone if you do not have a successor. 410 tells search engines “this is permanently gone, drop it from the index.” Faster removal than 404. See HTTP 410 Gone: what it means and when to use it for the exact server-config snippets.

For sites with hundreds of important URLs, export the list from Google Search Console first, then build the redirect map before you delete.

How to delete a single WordPress page or post#

You do not need to delete the whole site to delete one page. If that is what you came here for, this is the answer.

1. Log in to wp-admin.
2. Go to Pages (or Posts) in the sidebar.
3. Hover over the item to delete and click Trash.
4. Optionally go to the Trash tab and click Empty Trash to permanently delete.

WordPress holds trashed items for 30 days by default before permanent deletion. To recover, go to Trash, hover over the item, and click Restore.

Bulk delete: tick the checkboxes for multiple items, choose Move to Trash from the bulk actions dropdown, and apply.

A page that is set as the homepage cannot be trashed without first setting a different page as the homepage in Settings > Reading. WordPress blocks the delete to avoid leaving the site without a homepage.

How to delete a multisite child site#

WordPress Multisite networks have multiple sites under one install. Deleting one child does not affect the others.

1. Log in as Super Admin.
2. Go to Network Admin > Sites.
3. Hover over the site to delete and click Delete.
4. Confirm.

This removes the site’s database tables ( wp_2_posts , wp_2_options , etc.) and uploads (in wp-content/uploads/sites/2/ ). Plugins and themes stay – they belong to the network, not individual sites.

Backing up a single child site separately is awkward in multisite. The cleanest path is to take a full network backup before deleting any child, so you can extract just the affected tables and uploads if needed.

What if you cannot reach wp-admin?#

If the dashboard is broken, hacked, or you have lost the password, you cannot use the in-dashboard delete or export. Two paths:

• Recover access first. Reset the WordPress admin password or troubleshoot dashboard access. Then come back to this article.
• Delete from the server directly. Skip Step 2 (XML export) since that needs the dashboard. Take a full backup via the hosting control panel or SSH, then proceed with Steps 3-6. You lose the convenience of an XML export, but the full backup still contains everything.

If the site was hacked, follow the hacked site recovery process before deleting – in some cases you want to preserve evidence for a security review or rebuild fresh from a known-good backup, not delete the compromised version blindly.

GDPR and personal data#

If your WordPress site collected any personal data from EU residents – signups, comments with email addresses, WooCommerce orders, contact form submissions – you have data-protection obligations even after deleting the site.

The relevant requirements:

• Backups still count as personal data storage. A backup archive sitting on your laptop containing user emails is still subject to GDPR. Either anonymize the backup, encrypt it with a strong key only you hold, or delete it after a defined retention period.
• Third-party services need cleanup too. If you used Mailchimp, Stripe, Google Analytics, or any other service that stored user data on your behalf, delete or anonymize the data there separately. Site deletion does not propagate.
• Active subject access requests must still be honored. If a user requested their data before deletion, you are still on the hook to provide or delete it – the site going away does not extinguish the obligation.

If the site was small (personal blog, no signups, no comments), most of this is overhead you can skip. If the site had a real user base, treat the deletion as a structured data-purge event and document what you did.

Alternatives to deleting (when delete is the wrong tool)#

A surprising number of “I want to delete my WordPress site” requests are actually “I want to make it stop being public” or “I want to take it offline temporarily.” Those are different needs with different solutions.

Each of these is reversible. Deletion is not.

Common mistakes to avoid#

These are the ones that come up over and over in support tickets:

• Deleting files without dropping the database. The site looks gone, but the database still exists, still uses disk space, and still counts against your hosting plan limits.
• Deleting the database without deleting the files. Visitors see “Error establishing a database connection” instead of a clean takedown. Either delete both, or replace index.php with a static HTML “site closed” page.
• Forgetting about email. Deleting the site does not delete email accounts on the same domain – but cancelling the hosting plan usually does. If you want to keep email, set up email hosting elsewhere first.
• Forgetting about subscriptions. WooCommerce subscriptions, recurring payments, and active member access do not auto-cancel when you delete the site. Cancel them through the payment processor (Stripe, PayPal) before deletion to avoid charging customers for access to a site that no longer exists.
• Letting the domain expire by accident. If you wanted to keep the domain (for email, for a future project, to prevent someone else taking it), make sure auto-renew is on at the registrar before you cancel hosting. Domain registration and hosting are separate services even when you bought them in one bundle.
• Not testing the backup. A backup file you have never opened might be corrupt, partial, or missing the database. Open the archive, confirm the SQL file and wp-config.php are inside, and ideally do a test restore to a staging environment before relying on it.
• Deleting the wrong WordPress install. On hosting accounts with multiple sites, getting the directory wrong is easy. Triple-check the path. The damage from deleting the wrong site is the same whether it was intentional or not.

Summary#

WordPress.com deletion is a UI confirmation away. Self-hosted deletion is a multi-step process – backup, export, drop database, delete files, clean DNS, decide what happens to the domain, then cancel hosting if applicable. The single most common regret is skipping the backup. Take the snapshot. Verify it opens. Then delete.

If you are not sure you actually want to delete – if “make it stop being public” or “take it offline for a redesign” describes the situation better – use maintenance mode or set the site to private. Those are reversible. Deletion is not.