Restore Hacked WordPress from a Backup Safely

A backup date is not proof of cleanliness

The day a business notices a hack may be later than the first unauthorised access. A backup taken yesterday can therefore contain the problem, while an older copy may still include the component that allowed access. Build a short timeline from logs, reported symptoms, account changes and deployments before choosing a candidate.

WordPress backup guidance distinguishes application files from the database. Confirm exactly which parts each backup contains, whether they were captured consistently and whether the copy can actually be restored. A compressed archive that opens successfully is not yet a functional or trustworthy recovery point.

Protect evidence and recent business records

Preserve the currently affected site and useful logs privately before overwriting anything. Keep that material clearly labelled as compromised. Establish a separate, reviewed record of recent business activity so a restore does not silently discard valid customer work. Restrict exports containing personal information and avoid email attachments passed around an entire team.

For a shop, decide how payment confirmations, refunds, dispatch and stock changes after the recovery point will be handled. For a service business, identify enquiries received since that point. Do not replay live integration events blindly: a technical import can otherwise trigger duplicate messages, fulfilment or other unintended activity.

Restore the candidate into a restricted environment

1. Create a trusted staging location with access restricted to the recovery team. Keep live email, payment capture and fulfilment integrations disabled until specifically needed for a controlled test.
2. Restore a copy of the candidate files and database. Record the backup identifier, restoration time and configuration changes required to make the test copy run.
3. Compare core software with verified publisher material and review themes, plugins, custom code and stored content. Investigate unexpected accounts and scripts rather than assuming the backup is clean.
4. Replace affected executable components and patch or remove the initial access condition before allowing normal public requests.
5. Reconfigure exposed credentials and revoke relevant old sessions or tokens in a trusted environment. Validate account ownership and recovery methods.

WordPress provides a core checksum verification command, but passing that check does not validate every part of a restored site. Use broader application and configuration review for components outside its scope. Keep test results and known gaps with the candidate's restoration record.

Reconcile recent content without reimporting the infection

Treat post-backup content as a separate migration task. Identify which records are legitimate and necessary, then import them through an appropriate reviewed process. Do not solve the loss of three recent orders by copying the entire compromised database over the repaired site.

Assign someone who understands the business records to approve reconciliation. Match identifiers with trusted external records and distinguish completed transactions from attempts, tests and cancellations. Keep the original export unchanged for reference, with transformed imports documented separately. If the records cannot be trusted, record the uncertainty and use a manual verification process.

The same principle applies to media and page-builder content. An image upload can be legitimate while a neighbouring executable file is not; a service page can be correct while a shared header setting contains an injected script. Review the content in its application context rather than classifying entire directories as safe by name.

Use a controlled go-live checklist

• Confirm intended public pages, forms, navigation, search and account recovery work in the restored environment.
• Test applicable checkout and integration behaviour using provider-approved test procedures, without unnecessary live charges.
• Verify canonical URLs, clean sitemap entries and the expected responses for legitimate and attacker-created paths.
• Check that private backups, exports, debug pages and staging credentials are not published.
• Purge affected caches after switching to the repaired application, then inspect the actual public response.
• Document the return-to-service decision, monitoring owner and fallback plan if the restored site behaves unexpectedly.

A fallback plan must not put the vulnerable or actively compromised site straight back online. Keep a trusted service notice or a known clean restricted build available while a functional problem is repaired. Speed matters, but a short controlled interruption is preferable to an unexamined cycle of restore and reinfection.

Record the outcome and improve the next recovery

Hypothetical example: a shop selects a backup from before the first suspicious account change. It restores the copy privately, replaces the affected plugin and reviews the administrator list. The trading team reconciles later paid orders against the payment provider before the new site opens. The result is described as a tested recovery with a documented data cut-off, rather than a one-click restore that supposedly reversed every consequence.

After recovery, agree backup frequency, retention and restore testing around the business's acceptable data loss and downtime. Keep backups separated from ordinary website write access and document who can delete them. A backup strategy is useful only if the business can find, trust and restore the required components when needed.

CyberXperts can help plan the technical review around a candidate backup and the business records that must survive. Provide the available recovery dates and platform details first; arrange a secure method for transferring any archives or database exports.