Removing WordPress means deleting two things: the files and the database. Deleting only the files leaves the database sitting there holding your content and a user table, which is why sites removed carelessly leave data behind for years. Deleting only the database leaves a site that errors on every request.
Both are permanent. There is no undo, no trash to recover from, and no version WordPress keeps for you. Everything below assumes you have taken a backup first, because the step you cannot reverse is the one worth being deliberate about.
Take a backup you can actually use
Even when you are certain you are finished with a site, keep a copy. Content you decided was worthless has a habit of being needed a year later, and the cost of storing an archive is nothing next to the cost of recreating it.
Back up the files and the database together, from the same moment, and store the copy somewhere other than the account you are about to empty. Managing WordPress backups goes into doing this properly.
If there is anything specific you want to keep, images, an export of posts, a customised theme, take it separately as well, so retrieving it later does not mean restoring a whole site.
Note what you are about to lose access to
Before deleting anything, write down the database name and user, which you will need in a moment, and check three things that are easy to forget.
Email accounts on the domain are separate from WordPress and are not affected, but if you are removing the site because you are closing the domain, they will be. Any commercial plugin licences tied to this domain should be deactivated from the vendor's dashboard first, so the seat is freed for use elsewhere. And any scheduled tasks or external services pointing at this site will start failing, which is better to expect than to discover.
Delete the files
In cPanel, open File Manager and go to the directory holding the site: public_html for a main domain, or the subdirectory if it was installed in one.
Delete the WordPress files: wp-admin, wp-includes, wp-content, every wp-*.php file, index.php, and .htaccess if it only contains WordPress rules.
Be careful here if the account holds more than one site. Deleting the contents of public_html when a second site lives in a subfolder takes both. Check what else is in the directory before selecting everything.
File Manager's delete may move items to a trash folder rather than removing them. That still uses your disk quota, so empty it afterwards if you want the space back.
Delete the database
This is the step that gets skipped, and the reason abandoned databases full of user records sit on hosting accounts indefinitely.
In cPanel, open MySQL Databases. Find the database this site used (the name you noted earlier) and delete it. Then delete the database user, which is a separate entry further down the same page and is not removed with the database.
If you are unsure which database belonged to the site, read wp-config.php before you delete the files. The DB_NAME and DB_USER values are there in plain text. Once the files are gone, matching a database to a site becomes guesswork, and guessing here means potentially deleting a database another site is using.
Never delete a database you cannot positively identify. An orphaned database costs a little disk space; a deleted live one costs a site.
Removing an installation created by the one-click installer
If WordPress was installed through cPanel's application installer, use the same tool to remove it. Open the installer, find the installation in its list, and choose the uninstall option.
This removes files and database together and clears the installer's own record of the site, which is tidier than doing it by hand. Doing it manually leaves the installer still listing an installation that no longer exists, and it will keep offering to update it.
Removing WordPress but keeping the domain live
If something else should be at that address, put it there in the same sitting. A domain pointing at an empty directory shows either a directory listing or a server error, and both look like a broken site to anyone who visits.
An index.html with a sentence about what happened is enough as a placeholder.
If the content is moving somewhere else rather than disappearing, redirect rather than delete. Visitors and search engines both arrive at old URLs for a long time, and a redirect keeps them useful:
Redirect 301 / https://newsite.example.com/
Redirect to the specific matching page where one exists. Sending everything to a homepage is better than a 404 and worse than a real match.
Removing one WordPress site from an account with several
The order matters more here, because a mistake affects sites you are keeping.
Read wp-config.php for the site you are removing and note its database name and user. Confirm that no other site uses the same database: on accounts set up hastily, two sites occasionally share one, and deleting it takes both.
Then delete only that site's directory, and only that database and its user. Load the sites you are keeping afterwards to confirm they still work.
Afterwards
Check disk usage in cPanel to confirm the space was actually released; if it has not moved, the trash folder is still holding the files.
Remove the site from anything that was watching it: analytics properties, Search Console, uptime monitors, backup schedules pointing at a directory that no longer exists. Backup jobs left running against a deleted site fail silently and quietly fill logs.
And if you are removing WordPress because the site broke rather than because you are finished with it, it is worth checking whether it was recoverable first. Most WordPress failures are a plugin or a configuration line rather than anything terminal: fixing common WordPress errors starts by making WordPress tell you what actually went wrong, which frequently turns a rebuild into a two-minute fix.