Hacked Website Recovery Without a Clean Backup

Identify what is missing and what still exists

Separate the loss of executable code, design assets, editorial content, customer records and operational configuration. Each has a different recovery source and risk. A fresh WordPress download can replace core software, but cannot recreate orders that existed only in a lost database. Likewise, screenshots can help reconstruct appearance without restoring the site's working records.

Ask the hosting provider about retained snapshots, database backups and account-level copies before assuming nothing exists. Ask the development agency about source control and original release packages. Record who supplied each candidate and when it was created. A newly discovered copy is an unverified source until its integrity and relevance have been assessed.

Preserve the current state before attempting salvage

Have an authorised administrator retain a restricted copy of files, database and relevant logs. Record timestamps and important business cut-offs, such as the last fulfilled order or confirmed enquiry. Do not leave database exports or ZIP archives in a public web directory while working. A recovery copy containing personal information needs controlled access and a retention decision.

Contain active harmful behaviour separately from preservation. A simple temporary page served from a trusted location may keep customers informed while the affected application is restricted. If the hosting account may be compromised, arrange a trusted recovery environment rather than adding fresh secrets to a place the attacker can still read.

Build a trustworthy foundation before importing content

Create the replacement application from verified publisher packages or reviewed deployment sources. Document required themes, plugins, custom modules and integrations, then justify each one before reintroducing it. Do not copy the entire old application directory over a clean installation merely to save time.

Use a restricted staging environment with appropriate test data. Disable live email dispatch, payment capture, fulfilment webhooks and other side effects until their configuration is explicitly reviewed. Some recovery tests can otherwise notify customers, duplicate an order or start an external workflow. Keep a written list of what must be re-enabled before launch.

WordPress documents files and databases as separate backup components. That distinction matters even when no backup exists: code can be rebuilt from a publisher, while database records and uploaded content need their own salvage decisions. A successful file transfer does not demonstrate that the business information has been recovered.

Salvage necessary content selectively

1. List the records needed to resume the business, and rank them by operational importance and sensitivity.
2. Inspect candidate database content and exports in an isolated workflow. Identify unexpected administrators, script-bearing settings and altered payment or contact destinations.
3. Import only reviewed records into the replacement where practical. Preserve identifiers needed for reconciliation and document any transformations.
4. Recover media from trusted originals where available. Inspect files from the affected host and keep executable content out of public upload locations.
5. Reconcile the result against independent records such as approved invoices, payment-provider records or the business owner’s editorial inventory. Record gaps rather than inventing missing information.

Avoid unreviewed bulk text substitutions inside a database export. Structured or serialised values can be damaged, and a harmless-looking string may have different meanings in different fields. A developer should use an import method suited to the application and test the affected features afterwards.

Prove the business functions before changing traffic

Make a launch checklist covering intended URLs, contact details, enquiries, account recovery, search, checkout if relevant and necessary third-party integrations. Confirm that private exports, debug output and test endpoints are not publicly reachable. Establish new credentials and least-privilege integration access in the trusted replacement environment.

For a website rebuilt without a clean backup, editorial and technical acceptance need separate owners. The business verifies that essential information and records are accurate; the technical team verifies configuration, functionality and the removal of the known access route. Neither should silently sign off the other team's assumptions.

When to pause for specialist investigation

Escalate when customer data may have been exposed, payment behaviour changed, multiple systems share compromised access or there is no defensible boundary around the incident. An urgent rebuild can restore service while a separate investigation continues, but it should not erase the evidence needed for that investigation. The decision and its trade-offs belong in the incident record.

Hypothetical example: a consultancy has no clean full-site backup but retains its source repository, approved service copy and monthly lead exports. It rebuilds the public site from trusted code, manually verifies service pages and preserves the affected database for investigation. It reports that some recent enquiry history remains unreconciled, rather than claiming that a visually complete homepage means all records were recovered.

CyberXperts can help define a practical salvage and rebuild scope. Share which systems and source materials are available through the initial enquiry, then arrange a secure transfer process for any sensitive recovery material.