If your WordPress database is lost but the files remain, preserve those files and look for a genuine database copy before reinstalling anything. Uploads, themes and custom code can be useful, but they do not normally contain the original posts, settings and relationships held in the database. If no database survives, public captures may support a new content rebuild, not recovery of the original private records.
First have the host or an authorized developer confirm that the database is actually missing. A connection error alone does not establish deletion. Keep the distinction between inaccessible data and confirmed lost data clear throughout the recovery.
Confirm database loss before starting a replacement
Record the exact error, when it began and the last known working state. Ask the provider whether the original database still exists, whether it can be accessed and whether a retained backup or export is available. Keep the provider’s answer instead of inferring loss from the front end.
WordPress’s common-errors documentation describes several possible causes of a database connection failure. Investigation belongs with an authorized person who can assess the actual installation. Do not create an empty database or change configuration repeatedly merely to see whether the error disappears.
Preserve a copy of the surviving files before changes. Treat configuration and backup material as sensitive because it may contain credentials. Do not place it on a public download URL or attach it to an unrestricted support forum.
What surviving WordPress files can provide
Inspect the available directory copy and note its date and source. The WordPress files backup guidance lists components such as themes, plugins, images and code. These can provide useful assets and implementation evidence, but a typical directory download is not the same as exporting the database.
- Uploads: original images, documents or generated variants may survive. Their presence does not identify every post that used them.
- Themes: templates and styling may help reconstruct presentation. A theme folder does not guarantee that all site-specific settings or licensed dependencies are available.
- Plugins and custom code: these may identify required features, but installing their code again does not recover missing stored data.
- Separate exports or backup packages: an independently created database or content export may be included somewhere in the copy. Establish its actual format and scope rather than relying on its filename.
Do not discard surviving files after installing fresh WordPress core. Keep originals unchanged until the recovery is accepted. Unknown or formerly compromised code needs a qualified review before reuse; archive-based rebuilding is not a guarantee that old files are safe.
What normally depends on database records
WordPress’s database reference identifies tables for posts, post metadata, options, users, comments and terms. Those are records and relationships, not simply folders inside the theme.
The core database schema shows post fields including content, title, status, slug and parent. That helps explain why copying PHP templates into a fresh installation does not recreate the original article records. The code defines how content can be displayed; the missing records supplied what that site displayed.
Additional tools can store information in metadata, options or their own tables. The WordPress plugin handbook explains custom table storage as well as alternatives. Ask what the actual site’s plugins used rather than assuming all important data lived in a single posts table.
This matters particularly for stores, membership sites and other applications. A public product page or account screen is not the original private record behind it. Orders, private customers, passwords and uncaptured account information cannot be reconstructed from public appearance alone.
Look for original data before rebuilding public output
Ask the host, owner and authorized former developer about retained database exports or backup-tool packages. Check independent downloads and approved storage locations. Record which site each copy belongs to, its date, the source and whether it has been inspected.
If you find an export, preserve it and assess it away from production. An old copy may still contain useful content but omit later work. Do not call it a complete current recovery until those differences are understood. The WordPress database backup and restore instructions explain that a database export is distinct from the files and that restoration can replace existing data.
If the surviving package is incomplete or difficult to read, establish its components rather than improvising an import. A WordPress content export can also contain useful selected material, but it is not automatically equivalent to the full database. Ask for the export’s scope and any separately available media.
Define a public-content rebuild honestly
When no usable original database remains, assess whether archived public pages and surviving assets can support a new WordPress site. The archive-to-WordPress guide explains conversion of captured public output into a usable CMS build. That process does not reproduce an unavailable private database byte for byte.
Create a recovery record for each important page using three separate statuses:
- Original data available: a verified surviving record or export supplies the content.
- Public evidence available: an identified capture supplies text, structure or an asset for reconstruction.
- Unresolved: the original data and sufficient authorized public evidence are unavailable.
Record the original page URL, source date, material recovered and what needs new work. Mark rewritten or newly supplied material as such in the project handover. An archived page can help establish a historical path without proving its former record ID, draft history or private metadata.
Do not invent missing article text, author information or publishing dates to make an imported page look complete. Obtain owner confirmation for facts that cannot be established from the available source. Prioritize accurate, useful pages over recreating a page count.
Rebuild relationships and verify the delivered editing experience
A newly reconstructed site can use different record IDs. Check menus, parent-child structure, inline images, featured assignments and links against the agreed content record rather than relying on historical numbers. Surviving uploads need appropriate media associations; a directory containing the images is not evidence that every page uses them correctly.
Preserve original public paths where feasible and verify the result logged out. Check that the intended content appears at each accepted URL, media loads and important contact routes function. Keep recovery of public content separate from rebuilding a new form, checkout or other processing feature.
Agree how the site must be editable. Simple WordPress restoration integrates recovered HTML into WordPress with limited customization; editing some layout details can require HTML or CSS knowledge. A visual-builder rebuild is a different delivery choice. Neither approach establishes that the former database or its private records have been recovered.
The handoff should state which files were preserved, which original data was found, which pages were reconstructed, which relationships were verified and which data remains missing. That is a usable recovery boundary even when a complete original database restore is impossible.
Questions about files-only WordPress recovery
Does wp-config.php contain my posts?
No. It supplies configuration information, including the database connection settings, rather than the original post records. Keep it private and have an authorized developer inspect it where needed.
Will installing the same plugins bring back their data?
Not automatically. The plugin code and the information previously stored by it are different components. Determine whether a genuine data copy survives and what the particular plugin requires before claiming the feature is restored.
Can a rebuild use the same public URLs with new WordPress IDs?
It can where the paths can be reproduced appropriately and the content is available. Internal record IDs and public URLs are different things. Verify each agreed destination rather than promising preservation solely because an import completed.
