WordPress Hacked: Restore Your Website and Remove the Infection
If WordPress redirects visitors to another website, displays unfamiliar advertising or contains unauthorized changes, first contain the unsafe behavior and preserve the state for investigation. Then choose a verified recovery approach, establish the cause and test the site. Deleting one suspicious file does not confirm that the attacker's access has been closed.
For a commercial website, preserve recent enquiries, orders and payments separately. Restoring a week-old backup can remove essential data alongside infected changes. Before recovery, the team must identify what needs to be transferred and how its completeness will be verified.
On October 6, 2026, WordPress 7.1.3 was released with security fixes; its developers recommend updating immediately. This is a reason to review the project. An installed version number does not prove a hack, and updating the core does not replace investigating an infection already detected.
The steps below help website owners and support specialists decide what to preserve, how to choose a recovery method and how to accept the work. The exact cleanup depends on the identified cause and project architecture.
Download the recovery acceptance checklist — Russian CSV or the English CSV. It contains 18 checks covering containment, data preservation, recovery, access, business workflows and monitoring. The contractor and owner record actual results and redacted evidence. The table does not confirm that a particular incident is resolved without completed checks.
Signs that need investigation
An unwanted redirect, an unfamiliar administrator and a browser warning need investigation. A blank screen, server error or missing image can also result from an ordinary failure. Record the observation so a specialist can distinguish a service fault from an unauthorized change.
| Observation | Preserve | Question to investigate |
|---|---|---|
| Redirect to another domain | Original URL, timestamp, conditions | Where the redirect originates and which requests it affects |
| Unfamiliar pages in search | Example URLs and URL-inspection results | Whether spam exists in files, the database or generated responses |
| New administrator | Account name and creation details | Who authorized access and which actions occurred |
| Hosting restriction | Provider notification and timestamp | What the provider found and which resources are affected |
| A deleted file reappears | Path and recurrence time | Which process, access route or task recreates it |
| Enquiries no longer arrive | Last successful delivery time | Integration failure, changed settings or another fault |
Record recent authorized changes: plugin installation, theme changes, custom-code releases or contractor access. A timing match provides a lead, not proof of responsibility. A conclusion needs logs and investigation results.
Do not open suspicious pages on a work computer with active signed-in accounts. A specialist can inspect HTTP responses and code in an isolated environment. If only some visitors are affected, record the conditions: arrival from search, device type, login state and the specific URL.
Initial actions for the website owner
The guidance from WordPress recommends documenting symptoms, contacting the hosting provider and preserving a snapshot before cleanup. This gives the team material for diagnosis and for recovering important data.
Assign one owner and agree a temporary operating mode. If the site behaves dangerously, restrict access through the hosting platform or web server. An ordinary maintenance plugin may not cover every path. A specialist should verify the restriction, including requests for files and service routes.
Practical sequence:
- Contact hosting and support and provide symptoms and the discovery time.
- Contain unsafe responses and pause paid traffic where necessary.
- Preserve files, the database, available logs and provider messages in protected storage.
- List recent business data and external services that are still operating.
- Assign responsibility for investigation, recovery and acceptance.
Give customers a verified temporary contact method, such as a phone number or another working channel. Ensure staff understand the operating mode and do not promise successful processing of an enquiry that may be trapped in the damaged system.
What to preserve before recovery
Keep two distinct restore points: a snapshot of the current state for investigation and a candidate for a clean recovery. Label archives with timestamps and their purpose. A snapshot of an infected project does not become a clean backup merely because it was created successfully.
The guidance in Hardening WordPress explains the value of keeping multiple snapshots: a compromise may be discovered after it began. Test the selected backup separately. A date before visible advertising appeared does not prove that hidden changes are absent.
Prepare a business-data inventory:
- orders and enquiries created after the selected restore point;
- payment and delivery status changes;
- new users and their permitted actions;
- uploaded documents and images;
- catalog, pricing and content changes;
- records in external CRM or accounting systems.
This inventory defines the reconciliation plan. An external payment service or CRM may hold information missing from the old website database. Identify IDs and relationships so recovery does not cause the same purchase to be processed twice.
Choosing a recovery method
| Project condition | Possible approach | Evidence required |
|---|---|---|
| A verified pre-incident backup exists | Restore it in a separate environment | Clean state, compatibility and preservation of recent data |
| A backup exists, but its cleanliness is unknown | Investigate several snapshots | When changes appeared and which snapshot is usable |
| No clean backup exists, but source code is available | Build a trusted application version | Component provenance and validation of transferred data |
| A custom theme has substantial changes | Compare it with trusted source code | Which changes are product features and which are unauthorized |
| Server or hosting-account compromise is suspected | Rebuild a trusted environment with the provider | Infrastructure safety and the condition of other projects |
The decision to restore a backup needs a backup date, an inventory of data to transfer and investigation of the cause. Restoring a vulnerable component and previous credentials can allow the problem to recur. Continuing operations requires addressing the conditions that allowed the interference.
Use trusted core and extension distributions when rebuilding, and compare custom code against a confirmed version. Inspect uploaded files and the database separately. Copying all of wp-content from the suspect project also copies unknown changes.
Preserving recent orders: an illustrative example
Suppose a clean backup was made on Monday and the issue was discovered on Thursday. During that period, the website accepted orders, an external CRM created deals and a payment service confirmed payments. Simply restoring Monday's state breaks relationships between those systems.
Before switching, define the time boundary and reconcile order, payment and deal identifiers. Establish each order's state: created only, paid, shipped or cancelled. Then prepare a transfer of approved data to the clean environment, verifying relationships and amounts.
The acceptance condition is specific: a paid purchase exists in the new database, links to its original payment and does not trigger another notification or duplicate accounting action. Test integration reprocessing settings before connecting the recovered website to live services.
This is an illustrative workflow, not an NBM-IT project account. The actual procedure depends on order storage, plugin settings and external systems. If record integrity is uncertain, replace automatic transfer with controlled reconciliation by the data owner.
Checks that help identify WordPress changes
Comparing files with official checksums provides useful but limited evidence. WP-CLI core verify-checksums compares core files with WordPress.org data before WordPress loads. Account for the version and locale of the distribution being checked.
A successful core check does not cover the entire database, custom theme, uploads, server settings or credentials. A mismatch needs investigation: it shows a difference from the distribution but does not explain its origin. Save the results instead of immediately deleting the reported files.
For extensions, WP-CLI plugin verify-checksumsuses WordPress.org data. Suitable checksums may be unavailable for a commercial or custom component. Record that gap and compare the component with trusted source code instead.
A specialist also needs to examine application and server configuration, extensions, tasks, users and database contents. Symptoms and findings determine the scope. An external scanner sees public behavior, so a clean result cannot be accepted as a complete server-condition report.
Addressing the cause and recovering access
Ask the contractor to separate confirmed findings from assumptions. “A modified file was found” is a finding. “It arrived through a particular plugin” is a conclusion requiring further evidence. If the original entry point is unknown, retain that uncertainty in the report and provide a broader protection plan.
Agree which access routes were affected: WordPress, hosting, file transfer, the database and external integrations. The FAQ from WordPress covers changing credentials and updating secret keys to end active sessions. Work from a trusted device and coordinate changes to avoid breaking recovered integrations.
Record the outcome of each measure: a component was updated or replaced, unfamiliar access was revoked, an integration key was rotated or permissions were reviewed. After initial containment and cleanup, verify that new secrets were not entered into an environment that remained compromised; rotate them again where necessary.
Handle routine updates after investigation using a separate WordPress update plan. Check current versions with component developers: compatibility requirements and available fixes change.
When the website can return to service
Before sending live traffic, test the cleaned environment without real payments, emails or CRM reprocessing. A 200 response from the homepage confirms only one route is available. Accept a commercial website against its principal user actions.
| Area | Acceptance condition | Evidence |
|---|---|---|
| Unsafe behavior | The original symptom does not recur under tested conditions | URLs and checks performed |
| Application composition | Component provenance is confirmed | Versions and comparison results |
| Users and access | Unfamiliar permissions are reviewed and credentials updated | Action record without passwords |
| Orders and payments | Restored records are reconciled with external systems | Control IDs and reconciliation results |
| Forms | An enquiry reaches its intended recipient | One labelled test enquiry |
| Authentication | Authorized roles can sign in and perform their actions | Role-testing record |
| SEO | Useful pages have agreed responses and metadata | Main-template checks |
| Operations after cleanup | A new backup and monitoring procedure exist | Owner and instructions |
Enable external actions in the agreed sequence. First establish that a control enquiry completes its full journey, then restore the other workflows. For a store, verify separately that recovery has not caused old orders to be submitted again.
At launch, record a baseline and monitoring plan. Watch for the original symptoms returning, new changes, errors and business-data delivery. Choose monitoring duration and intensity according to the incident scope; a promise that one check prevents every future hack is unverifiable.
Checking search visibility after cleanup
Open the Security Issues report in Search Console. Google recommends fixing every listed issue before requesting a review, describing the changes and providing evidence. The example URL list may be incomplete.
For search acceptance, prepare two URL groups: useful business pages and spam pages created without permission. For the former, check responses, content, canonicals and crawlability. For the latter, agree appropriate removal and verify that the pages are not generated again.
Update the sitemap using the verified set of useful URLs. Exclude spam, temporary maintenance pages and URLs with incorrect content. After launch, monitor warnings, crawling and organic visits. Clearing a warning and restoring previous traffic are distinct outcomes without a shared guaranteed deadline.
Questions for a recovery contractor
An initial request can contain symptoms, discovery time, CMS and hosting details, backup availability, integrations and order-preservation requirements. Share credentials through an agreed secure channel. Keep them out of an open brief or a general project chat.
Clarify the deliverables:
- what was preserved before cleanup and where it is stored;
- which resources were investigated and which remained outside scope;
- what is known about the cause and which hypotheses remain unconfirmed;
- which data was restored and how completeness was checked;
- which credentials and components were changed;
- which user workflows were tested;
- who monitors the site and investigates a returning symptom.
Cost depends on the project condition, availability of a trusted backup, custom code, data volume and integrations. Ask for separate estimates for investigation, recovery, reconciliation and ongoing support. General WordPress development costs are discussed in the project-estimate guide.
Discuss recovery and ongoing maintenance through website technical support. If the project needs a post-incident review of access routes and vulnerabilities, define a separate security-testing scope. That review and urgent service recovery have different completion criteria.
Improving the support process
After recovery, assign owners for updates, backups and access provisioning. Maintain a component inventory, preserve change history and periodically test backup restoration. Each external service needs clear responsibility for its keys and exchange reliability.
Monitor the actions that matter to the business: form availability, enquiry delivery, order placement and required-role access. This complements technical monitoring: a website can load while its integration has already stopped delivering enquiries.
Keep the incident report with the support instructions. A new contractor should understand the original symptom, measures taken, remaining limitations and recurrence procedure. This reduces uncertainty at the next support request and provides a verifiable basis for further work.
FAQ
Can the website be recovered without a clean backup?
Sometimes it can be rebuilt from trusted components with verified data transferred. The work depends on source-code availability and database condition. Investigation comes first; preserving all content cannot be promised beforehand.
Will moving to another hosting provider help?
A move can be part of rebuilding the environment. However, infected files, unsafe settings and old credentials can carry the problem to the new host. Migration needs a confirmed application composition and investigation of the incident conditions.
Why does malware return after a file is deleted?
A way to recreate it or an access route remains. Areas to investigate include code, tasks, accounts and the environment. Establish the actual cause from evidence; the filename alone does not identify it.
Is installing a security plugin enough?
A plugin can help with specific checks and restrictions. It does not replace data preservation, environment investigation, restoring trusted code or testing business workflows. Establish exactly which outcomes it confirms.
Must the domain change after a hack?
A new domain alone neither fixes the cause nor cleans the application. Make the address decision separately from technical recovery. First restore safe behavior, then assess search effects and other constraints.
Sources
- WordPress 7.1.3: security release dated October 6, 2026.
- WordPress: FAQ My site was hacked.
- WordPress: Hardening WordPress.
- WP-CLI: core checksum verification.
- WP-CLI: plugin checksum verification.
- Google: Security Issues report.
Sources checked on October 9, 2026. The work-management steps, acceptance tables and order example are recommendations and an illustrative workflow; they do not describe an NBM-IT client incident.