A hacked WordPress site is an incident of access, persistence and business impact — not just a pile of suspicious files. A site can look completely normal to you while it sends spam, redirects only search visitors, or keeps hidden administrators. Recovery works in a deliberate order.
Step 1 — Regain control and contain
Confirm ownership and the authorised recovery route with the relevant account owners. If visitors are exposed, agree containment with the owner and hosting provider, preserving the relevant incident state where feasible without delaying urgent protection. For a store, include the effect on orders, payments and external systems in that decision.
Step 2 — Establish the timeline
Build a timeline from available alerts, access records, deployments and file or database changes. WordPress’s incident guidance recommends recording symptoms and timing. File timestamps and nearby requests are clues, not proof that a particular request wrote a file; record gaps and distinguish observations from supported conclusions.
Recover the store, with an agreed plan for its orders
A storefront loading again is only part of the job. Before the intervention, we agree which environment, business records and customer journeys are in scope. The assessment separates containment from recovery and explains the dependencies, proposed work and quote.
- Establish the affected journey: identify the URLs, sessions or checkout stage involved. An external destination is not automatically malicious; the guide to unexpected WooCommerce redirects separates configured payment journeys from behaviour that needs investigation.
- Plan around current orders: record the recovery point and changes since it, including orders, customers and fulfilment work. If restoration is proposed, agree how the gap will be handled before replacing live data. WooCommerce’s backup guidance for stores using Subscriptions describes missing records and additional renewal risks where that extension applies.
- Define the checks: agree the incident conditions and relevant account, cart, checkout, order and integration checks. The post-repair WooCommerce test guide helps specify them. Any test that can create an order, notification or payment needs an agreed controlled method.
The handover records the changes, checks performed, unresolved findings and next owner. If a charge and order status disagree, use the payment and order reconciliation handover to define what still needs checking. Reopening and closing the incident are decisions based on the agreed evidence; neither implies a guarantee against future attacks.
Is your website affected right now?
Send the URL and the symptom you can see. Jordi Ensenyat reviews the case personally and defines the scope and quote before anything is changed. This form never asks for passwords.
Step 3 — Investigate and remove confirmed persistence
- Assess affected core, plugins, themes and custom code against trusted packages or reviewed source. Agree replacement and compatibility checks; preserve material needed for investigation before removal.
- Inspect suspected persistence in code, uploads, must-use plugins, scheduled activity and database content. A function name or encoded string alone does not establish malicious intent; assess its context and behaviour.
- Review unexpected accounts, roles and injected content against the owner’s verified inventory. Document confirmed findings and unresolved items separately.
- Where evidence points beyond WordPress, involve the hosting or infrastructure owner and define the additional scope.
Step 4 — Correct exposed access and the supported entry route
Identify exposed accounts, sessions and integration credentials, then agree revocation or rotation with their owners and the required reconnection checks. Correct the supported entry route and other confirmed weaknesses. If the entry point cannot be established, retain that uncertainty and agree further investigation rather than inventing a single cause.
Step 5 — Address warnings and search results
Remove identified malicious content and test the affected conditions. If Search Console lists security issues, follow the security-review process after fixing all listed issue types across the affected site. Sample URLs may be incomplete; Google controls the review and its timing. A technical repair does not itself confirm that every warning or search result has changed.
When to escalate
If customer data, payments, hosting access or several sites may be affected, define the relevant specialist and provider involvement. For an initial assessment, send the URL, observed symptom, first alert, business impact, available recovery points and changes already attempted. Scope and quote are agreed before the intervention; do not include credentials, customer exports or backup archives in the first message.
EVIDENCE-LED WORDPRESS RECOVERY
Recover a hacked WordPress site without hiding the cause
In WooCommerce and ecommerce incident recovery, the visible symptom may be far from the cause. The objective is to restore revenue-critical journeys while preserving orders, customer data and payment evidence. A compromised site is an incident involving access, persistence and business impact—not just a collection of suspicious files. Recovery prioritises control of the website, preservation of useful evidence, removal of malicious changes and closure of the entry point where it can be established.
What we verify
- The complete journey, not only the screen where the error appears
- External dependencies, logs and evidence before configuration changes
- Authorised control of hosting, domain, WordPress and recovery email
- Malware, backdoors, rogue users, scheduled tasks and modified server rules
- Exposed credentials, vulnerable components and unauthorised integrations
- Clean public behaviour, administrator access and monitoring after recovery
What a verified outcome means
Close-out documents the cause found, the change applied and the tests performed. The result must be observable and repeatable—not a feeling that it “seems to work”.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
How do you verify that the problem is genuinely resolved?+
The affected journey is reproduced, its dependencies are checked and post-change evidence is recorded.
What is the first priority after discovering a hacked WordPress site?+
Regain authorised control, limit further damage and preserve evidence before making broad changes that could hide the entry point.
Is reinstalling WordPress enough?+
No. Compromise may remain in uploads, plugins, themes, the database, server configuration, users or stolen credentials.
When can the website be considered recovered?+
When malicious behaviour and persistence are removed, access is controlled, affected journeys are tested and remaining risks are documented.