When you change a website, you are not always working in the same place. Images and application code are usually files, while page content, settings and orders may live in a database. Understanding the difference helps you avoid changes that delete information or disrupt the site. Before you intervene, identify the database in use, protect its connection details and prepare a backup that you have checked you can restore.
1. Website files and the database do different jobs
Website files include application code, themes, plugins, images and other uploaded documents. The database holds structured information that the application reads and updates. MySQL is a database management system commonly used by WordPress websites; some installations use MariaDB, which is compatible with many everyday MySQL use cases.
Think of a product page: the photograph may be a file, while the product name, description and price may be stored in the database. The theme determines how those elements appear, and the application brings them together when someone visits the page.
- Files: code, themes, plugins, images and documents.
- Database: content, accounts, settings and application records.
Not every website works this way. A static site may store its pages directly in files. For a dynamic website, copying only the files is usually not a complete backup. Whatever web hosting service you choose, establish which components your application uses.
2. Where pages, settings and orders are stored
In WordPress, the text of posts and pages is normally stored in the database. Uploaded files usually live in the uploads directory, while the database holds information about them. The final appearance can depend on both theme files and settings or templates saved in the database.
Understanding WordPress tables
A database is organised into tables, with rows and columns. In a typical WordPress installation, you may find table names ending in posts, postmeta, options, users or usermeta. Their prefix may be something other than wp_, and plugins can add their own tables.
Shop orders may be stored in general WordPress structures or dedicated tables, depending on the platform, plugin and configuration. Do not assume you know where they are simply because an online tutorial describes one particular setup.
Relationships between records matter. A product can have related attributes and variations, while an order can have separate records for items, tax and delivery details. Deleting one row does not necessarily remove all its connections and may leave inconsistent data behind. The database does not automatically enforce every relationship; some are managed by the application.
3. How to identify the database your website uses
A hosting account may contain several databases: one for the live site, another for an old installation and another for testing. The database name alone is not enough to establish which one is active.
- Find the correct installation. Check the directory associated with the domain and distinguish the live website from any copies.
- Read the application configuration. WordPress usually defines its database connection in wp-config.php, although some setups retrieve values from the server environment.
- Record the relevant details. The database name, database server, username and table prefix help you confirm the connection. Do not copy the password into an unsecured note.
- Check without editing. Compare the structure and a few familiar details without changing records. The website address can be a clue, but not conclusive proof: a clone may contain the same address.
The principle is the same in a WordPress hosting environment: confirm the connection between the installation and its database before making changes. If you cannot identify it confidently, stop and ask for help.
4. Protect connection details and limit access
Database credentials allow the application to read and change information. Do not expose them in screenshots, public messages or archives accessible through a browser. Configuration files and database exports can contain sensitive information.
- Store passwords in a password manager and share them only through a secure channel with authorised people.
- Use individual administration accounts where possible, and enable two-factor authentication on services that support it.
- Grant only the permissions required, and avoid giving a single application an account with access to every database.
- Remove temporary access when the work or collaboration ends.
If a password has been exposed, coordinate its replacement with the corresponding update to the application configuration. Otherwise, the website may lose its database connection. Do not experiment with permissions or passwords on the live website.
5. Prepare a complete backup and test recovery
Before making changes, prepare a backup of the database and the files the website needs. A database export does not automatically include images, themes or plugins. Equally, an archive of website files does not automatically contain the database content.
- Define what to save. Include the correct database, application files and configuration needed for recovery.
- Choose a suitable time. If the site receives orders or other updates, coordinate the backup process so that the database and files remain consistent with each other.
- Store the backup separately. Use a protected location outside the public web directory, preferably with a copy separate from the website server too.
- Test restoration. In an isolated environment, check that the archive opens, the database imports and the application can use the restored data.
The test must avoid sending real messages, processing payments or exposing customer information. Restrict access and disable the relevant external integrations. Having an export file does not, by itself, demonstrate that you have a recoverable backup.
6. Use the application first, then check the outcome
For routine website administration, start with the application's own features: page editing, user management, settings or order management. These normally apply validation and related updates that a direct database edit may bypass.
Do not run copied SQL statements unless you understand what they select and change. A text replacement can damage serialised data, where values are stored in a format with its own rules. A deletion may affect more records than intended or remove history the shop needs.
If a direct change is justified, test it on an isolated copy, document the operation and establish a way back. Afterwards, check the affected functions and relevant error messages. Do not automatically restore an older backup over the live site: doing so could erase orders or changes received since that backup was made.
The practical takeaway: identify the database, protect access and verify recovery before changing data. If you cannot explain what an operation will do, do not run it on the live website. Use the contact page for questions about the hosting service; for application behaviour and data relationships, ask the developer or specialist who maintains it.
