Copying clean files directly over a hacked site changes timestamps, removes unknown payloads and makes later comparison unreliable. Recovery is safer when the compromised root is frozen and a separate clean root is built.
Preserve a trustworthy snapshot before any destructive file operation.
Contain public execution
Use hosting/CDN controls or a static maintenance response outside WordPress. Disable unsafe checkout, downloads or login while keeping responder access controlled.
Do not leave the infected root publicly executable simply to preserve it. Isolation protects both visitors and evidence.
Record containment method and any temporary bypass.
Snapshot the original root
Create a filesystem snapshot/archive including hidden files, ownership, permissions and relevant parent/server configuration. Preserve web/PHP/FTP/panel logs separately before rotation.
Store copies outside public paths with limited access. Record source, time, size and checksum where practical.
Do not email archives or upload them to an ordinary shared drive.
Preserve metadata listings
Capture file paths, sizes, owners, permissions, modification/change times and hashes. A listing enables comparison even when the working copy changes.
Modification times can be forged and copying can alter metadata, so retain host/provider snapshot information where available.
Do not touch suspicious files merely to inspect them through a browser.
Create a new clean root
Install WordPress core, maintained plugins/themes from trusted sources in a separate document root. Recreate configuration with fresh secrets and restricted permissions.
Validate custom code from a trusted repository/known-good version. Do not copy whole plugin/theme folders from the incident root.
Keep production DNS/document-root mapping unchanged until testing.
Set clean ownership and permissions
Create the new root under the intended hosting system user and PHP handler. Apply the provider’s minimal writable paths; do not make the whole tree world-writable to avoid deployment errors.
Separate deployments from runtime uploads where architecture permits. Record owner/group/mode baseline so later unexpected changes are detectable.
Test updates and media upload through the supported process without granting account-wide write access.
Import media selectively
Copy validated media types, not cache, backup, temporary or executable files. Check uploads for PHP/server rules, unexpected extensions and customer-data access requirements.
Rebuild thumbnails/generated assets. Store suspect samples separately and never make the evidence directory web-accessible.
Document files intentionally excluded.
Import database content carefully
Use a protected database snapshot and inspect users, options, cron, snippets, redirects and page-builder content before connecting it to clean code.
Avoid broad search-and-replace or wholesale restoration when database persistence is suspected. Back up affected rows and use WordPress-aware changes.
Keep the original database read-only under the incident process.
Compare behaviour before switching
Use a controlled hosts mapping or provider preview at the canonical hostname. Test redirects, cookies, REST/AJAX and security indicators without sending production mail or payments.
Compare new-root logs and file changes during cron/cache/admin triggers. A clean static homepage alone does not validate the application.
Switch using a reversible method
After isolated testing, change the hosting document root, virtual-host mapping or controlled release symlink according to provider architecture. Keep a tested rollback that does not reactivate the infected site publicly.
Do not move/delete directories with broad globs or ambiguous paths. Record exact old/new roots.
Purge cache only after the mapping is correct.
Retain and dispose responsibly
Keep incident evidence for the approved period and restrict who can access it. Remove temporary working copies, public ZIP/SQL files and obsolete credentials after recovery.
If legal/payment/privacy handling applies, follow its preservation schedule rather than normal backup cleanup.
Record custody and final disposal.
Verify the new production root
Test redirects, login, users, forms, checkout, cron, mail, uploads and backups. Monitor file/database/account changes and requests to old malicious paths.
Confirm the infected root cannot execute or receive public traffic. Reconcile business activity during maintenance.
Request emergency clean-root recovery when the only site copy is live. Share file inventories and managed hosting access—never archives, database dumps, credentials or malware publicly.