The account lists five databases and none of the names says anything. You need to know which one belongs to the site, because you are about to clean it, copy it or delete it. There are three ways to find out, and each gives the same answer in under a minute.
|
Never delete a database you have not identified. A database deleted by mistake only comes back from a backup, and it takes with it a site you may not have known you had. Identify first, always.
|
1. From the configuration file (the most direct)
The answer is written inside the site, and you do not need to open WordPress to read it.
| 1 |
In cPanel, open File Manager and go into the site folder. Usually public_html; if the site is on an addon domain or a subdomain, it has a folder of its own.
|
|
| 2 |
Find wp-config.php, right click, View. Using View rather than Edit means you cannot save by accident.
|
|
| 3 |
Look for the DB_NAME and DB_USER lines. Between the quotes are the database name and the username. Note $table_prefix further down as well.
|
|
2. Through the WordPress tool in cPanel
If you would rather not open files, cPanel has a page listing the WordPress installations on the account with the details of each.
| 1 |
In cPanel, under Domains, open WordPress Management. Alternatively, under Software, the app installer’s WordPress manager does the same.
|
|
| 2 |
Find the installation by the site address.
|
|
| 3 |
Open its details. The database name is there, often with a direct link into phpMyAdmin for that database.
|
|
|
This is the one for when you have too many sites. On an account with six WordPress installations, this page shows all six side by side, with each one’s domain and database. It is the only route that gives you the whole map at once.
|
3. The other way round: from the database to the site
This is the route for when wp-config.php is gone, or when you have an orphan database and want to know whose it was. You ask the database itself which site address it serves.
| 2 |
Pick the database in the left-hand list and open the SQL tab.
|
|
| 3 |
Run SELECT option_value FROM wp_options WHERE option_name = 'siteurl';. If the tables have a different prefix, swap wp_ for whatever you see in the list.
|
|
| 4 |
The result is the address of the site that database serves. Repeat for each database until you find yours.
|
|
|
An even quicker shortcut. In phpMyAdmin’s left-hand list, open each database and look at the modification date and the table sizes. A live site’s database has _posts and _options tables with content in them; an abandoned one has nearly empty tables, or no WordPress tables at all.
|
What the names tell you, and what they do not
| What you see |
What it means |
| A prefix before the name |
On a shared account, every database and every user starts with the account name. It is not decoration: it is part of the name and it has to be in wp-config.php. |
| A number or random letters at the end |
An automatic installer created the database. The name means nothing, and there is no guessing the site from it. |
| Two databases with similar names |
Very common: one belongs to the site and the other is left over from a test or a migration. Confirm with siteurl before touching either. |
| Tables with different prefixes in one database |
Two sites sharing a database. Deleting it takes both. See how to remove WordPress from a domain. |
What you will need this for
It is worth writing the database name, the username and the prefix down somewhere of your own. You need them to repair a broken connection, to clean the database, to move the site elsewhere, and to delete it without leaving anything behind. The articles where that happens are rebuilding the wp-config.php connection, error establishing a database connection, cleaning and optimising the database and how to generate the zip and sql files.
RECOMMENDED PRODUCT WordPress hosting One-click install, updates handled, and speed that holds up. See plans |
Angola
Brasil
Kenya
Moçambique
Nigeria
Portugal
South Africa
United Kingdom
United States
International
