How to delete sites from WordPress Multisite

We once walked into a Melbourne office where the marketing team nervously hovered over an old site that still appeared in their network. They wanted it gone, but feared breaking shared content and user access.

We built this short, practical guide to help make that decision safe and predictable.

In a wordpress multisite setup, multiple sites share one installation, themes and plugins, while each site keeps its own tables and uploads. Super Administrators manage the whole network and use the dashboard path My Sites > Network Admin > Sites to perform edits, archive or delete.

This intro sets expectations: permanent removal versus reversible alternatives, who can delete (Super Administrator), and key risks from shared resources. We preview housekeeping steps — DNS, uploads folder, database tables and redirects — and flag common post‑deletion issues like login redirects and cookie errors.

If time is tight or customisation is complex, contact hello@defyn.com.au so we can advise on safe removal and Australian compliance for decommissioning a website.

Key Takeaways

• Deleting a site affects only that site’s tables and uploads; shared code remains.
• Only a Super Administrator in the network can delete from the network admin screens.
• Back up, test on staging and plan DNS and redirect clean‑up before deletion.
• Watch for login redirects, cookie issues and user access flow‑on effects.
• Contact hello@defyn.com.au for help with complex customisations or tight timelines.

Why deletion matters in a WordPress Multisite network

Networks that host dozens of sites can carry hidden risks when unused pages linger.

Deleting a site can be the right operational move when a site has finished its purpose or poses a risk to the wider network.

Common Australian examples include retiring an EOFY campaign microsite, consolidating regional websites into a single company hub, or removing a community blog that breaches policy.

• Cost vs value: maintenance, updates and legal checks can exceed the benefit of keeping inactive sites.
• Reputation: outdated content misleads customers and harms trust in regulated industries.
• Data minimisation: removing old sites reduces stored personal data and supports security controls.

“A disciplined offboarding process protects stability for remaining sites and keeps analytics clean.”

We treat deletion as one tool among archiving and blocking. Coordinate messaging and redirects so customers aren’t surprised when a site disappears.

Understand the network: roles, sites and shared resources

Before you press delete, it helps to map who holds power in the network and what lives where.

In a Multisite setup the Super Administrator role sits above standard admins. Only the Super Administrator — via Network Admin screens — can install themes and plugins across the network and delete a site. Site administrators manage content and settings for their own site but cannot remove sites or install network‑wide code.

What is shared and what is per‑site

• Shared assets: one installation holds core files, installed themes and plugins, and the global user table.
• Per‑site data: each site has its own database tables (for example wp_2_posts) and an uploads folder.
• Users: accounts live once for the network; deleting a site removes only the site‑association, not the user record.

“Confirm who holds Super Administrator rights before any destructive action.”

Pre‑deletion checklist: backups, access and risk mitigation

We start every removal with a checklist that protects the network and its users. Confirm approvals, Super Administrator access and MFA before any destructive step.

Full network vs single‑site backups

Create a full network backup of the installation plus a targeted backup of the specific site. Include database dumps and a copy of the site uploads folder on your hosting or server.

Export per‑site tables: wp_{blog_id}_posts, _options, _terms, _term_taxonomy, _term_relationships, _comments, _commentmeta, _postmeta, and any user associations needed for that site.

Staging and testing

Clone the site to a staging environment. Test deletion, redirects and domain mapping there to avoid surprises in production.

Security and audit

Verify the exact website to remove by domain, path, site ID and owner email. Document business sign‑off, pick a low‑traffic deletion window and add a contact email for escalations.

• Snapshot the uploads directory to secure storage.
• Pre‑stage DNS and redirect changes to reduce downtime.
• Keep a recovery plan that combines the network backup and targeted site data for rapid rollback.

Safe alternatives to deletion: deactivate, archive or mark as spam

Before deleting, try a softer approach that keeps recovery options open. We prefer reversible steps when the business value of a site is uncertain.

Where to act: open Network Admin > Sites to see the available controls. The common options are Deactivate, Archive, Mark as Spam, and Delete.

Deactivation versus archiving

Deactivation takes a site offline but keeps data intact. Archiving renders a site inaccessible to visitors and admins. Both remain in the list and can be restored later.

When to mark as spam

Mark as Spam is for abusive or policy‑breaking blogs and creators. It blocks the site and prevents the creator from adding more sites. Use this option during investigations or legal holds.

Operational tips:

• Document which feature you used and why for governance.
• Set review dates to decide restore, delete or retain the status.
• Plan redirects: SEO signals change when content becomes inaccessible.
• Inform the Super Administrator to keep the network consistent.

The exact steps: delete a site from Network Admin

We’ll guide you through the precise Network Admin flow so deletion is predictable and auditable.

1. Open the dashboard path: My Sites › Network Admin › Sites to list all sites.
2. Hover the target site to reveal actions: Edit, Dashboard, Deactivate, Archive, Spam, Delete, Visit. Use Edit first to confirm domain, path, site ID and owner.
3. Ensure the site is Deactivated to stop last‑minute edits, then choose Delete when authorised.

Quick checks and post‑delete actions

• Capture screenshots or export critical settings and options for audits or rebuilds.
• Record who performed the deletion and the exact time for your change log.
• Understand what is removed: per‑site database tables and network site mappings are dropped; shared themes, plugins and core code remain on the network.
• Note that uploads folders or leftover files can remain on the server depending on hosting — plan housekeeping after deletion.
• If you later add new sites or re‑create this site, use a different path or domain to avoid cache and mapping conflicts.

Final verification: refresh the Sites list in the network admin and confirm the site no longer appears. Test front‑end URLs and document the result. These steps keep the network stable and traceable.

Subdomains, subdirectories and domain mapping considerations

How a site is addressed — by subdomains, subdirectories or a mapped domain — changes the steps you must take after removal.

Cleaning up DNS, mappings and redirects after a site removal

Start by confirming the exact domain and mapping entries for the removed site in the network. This stops stray traffic and broken links.

• Subdomains: remove the A/CNAME records for the host unless other sites use them. Check wildcard entries before deleting.
• Subdirectories: implement web‑server or CDN 301 redirects from example paths to relevant pages on the main domain.
• Domain mapping: unmap custom domains, revoke or update SSL/TLS SANs, and remove mapping records so the domain points elsewhere.
• Invalidate CDN and clear caches. Test DNS propagation from multiple ISPs and devices across Australia.

Example: retire blog.aubrand.com — delete DNS A/CNAME, remove the mapping in the network, revoke the certificate entry and add 301 redirects at the apex domain if content moved.

Document every change so future audits show which domains were removed and why.

Files, media and database housekeeping post‑deletion

Deleting a site rarely finishes the job — files and tables can linger and need a tidy‑up. We treat this as a discrete clean‑up task that follows the deletion step.

Start with the database. Verify that all per‑site tables (for example wp_{blog_id}_posts and siblings) were dropped. If any remain, export them first and then drop them manually from the server with backups in place.

Next, reclaim server space. Look for the deleted site’s uploads directory under the uploads tree and remove it only after confirming no shared assets remain. Scan for cache folders, log files and backup snapshots that reference the site.

Search your code and configuration for hardcoded domains or paths. Update or remove references to avoid broken links and unexpected errors.

• Scope filesystem deletions carefully so you do not remove files used by other sites.
• Create a post‑clean‑up report that lists files removed, database actions taken and any remaining artefacts.
• Compare storage usage before and after to validate reclaimed space and spot anomalies.
• Monitor error logs for several days to catch missed references.
• Remember the shared installation and code remain intact — continue patching and routine maintenance.

Themes, plugins and code: what does not get deleted

Shared themes and plugins remain after a site is deleted. The network installation keeps those assets available to other sites until a Super Administrator removes them.

That means deleting one site only removes per‑site tables and uploads. It does not uninstall themes, plugins or core code from the installation.

We recommend these practical steps:

• Audit usage: map which sites use which themes and plugins before removing anything.
• Network deactivate plugins you no longer need to reduce risk without uninstalling them.
• Check mu‑plugins and network‑level code; custom snippets can persist and may reference the removed site.
• Remember: deleting a plugin from the network affects all sites — plan and communicate first.

Keep shared assets up to date. Test any network-wide code or themes/plugins changes in staging and schedule regular reviews to trim unused items and protect the whole network.

Security, compliance and record‑keeping after removal

Removing a site starts a short, important security and compliance workflow. We treat this as standard procedure to close gaps and keep the network clean.

User accounts, shared users and access reviews

Users are stored once for the network; deleting a site removes only that site assignment. User records remain in the central table and must be reviewed.

• Access review: remove roles no longer required and validate MFA for remaining admins. This reduces lingering access paths.
• Record keeping: log who performed the deletion, when it happened and the affected domain. Retain backups per your company policy.
• Documentation: update runbooks, asset registers and internal docs so the removed site is clearly marked as decommissioned.
• Credential hygiene: rotate API keys, webhooks, OAuth apps and any integration passwords unique to the deleted site.
• Privacy and retention: check data retention rules, DPA clauses and client contracts to decide how long to keep backups and whether to notify by email.
• Tooling audit: review analytics properties, tag managers and SEO tools to prevent data drift and access leaks.
• Post‑mortem: run a short review to capture lessons and improve the decommissioning playbook.

Clearing redundant sites and access paths strengthens overall network security and reduces future risk.

Troubleshooting common issues after deleting a site

After a site is removed you may still see redirects or login failures that point to the old domain. These problems usually come from cached records, leftover mapping or a cookie mismatch.

Login redirects, cookie errors and mapped domain stragglers

Quick fix for cookie errors: when users see “Cookies are blocked or not supported by your browser…” add this to your wp-config.php:

define('ADMIN_COOKIE_PATH','/');
define('COOKIEPATH','');
define('SITECOOKIEPATH','');
define('COOKIE_DOMAIN',false);

• Clear caches: purge server, CDN and plugin caches, then ask users to clear browser cookies for affected domains.
• Confirm mapping and DNS: remove domain mapping entries and delete any DNS records that still point at the site.
• Scan for hardcoded links: search code, config and environment files for the deleted domain and update or remove matches.
• Check server rules: review .htaccess or Nginx rules and multisite setup directives for legacy redirects.
• Review plugins: disable redirect, SSO or proxy plugins temporarily to isolate loops.
• Test widely: check from different networks and browsers to rule out local caching.
• Audit logs: review 404s and 301 loops to find leftover routes tied to the old path.

Recovery path: if removal caused a critical outage, restore from backups and repeat the removal in a staged setup. We recommend documenting each step so the network stays stable.

Need help with customisation or complex networks?

Large agencies often juggle dozens of live websites, and complexity grows faster than visibility. When domain mapping, SSO or legacy code are involved, the risk of mistakes rises.

We work with teams to make decommissions predictable and safe. Our approach blends technical fixes with clear runbooks so your people can repeat the process.

How we help

• Hands‑on support for decommissions, domain mapping transitions and structured redirects across websites.
• Review of hosting and server architecture to ensure clean removals and steady performance.
• Audit of roles, permissions and automation to reduce accidental deletions in large networks.
• Tailored guide and runbooks for your team, plus collaboration with your developer to create new processes.
• Troubleshoot SSO, cookies and plugin edge cases in complex environments.
• Stakeholder coordination with legal and marketing, and evidence‑based sign‑off via email for every step.

Need a reliable partner? Email hello@defyn.com.au and we’ll step in to stabilise and streamline your multisite operations for your company and its websites.

Conclusion

Treat site removal as a short project with defined checks and owners.

We recap the safe path: verify permissions, take backups, test in staging, delete via Network Admin and finish DNS and filesystem clean‑up. Focus on per‑site tables and uploads because shared code and themes persist across the network.

Strong governance, role review and routine updates reduce risk for remaining sites. Use deactivation, archiving or spam marking when you need a reversible hold. Plan redirects and notify stakeholders to protect user experience and SEO.

If you need help with complex customisation or a busy schedule, contact hello@defyn.com.au. We’ll make decommissioning predictable and safe for your wordpress multisite setup.