Fix · Emergency
Hacked or Infected Website: Cleanup, Hardening and Getting Back Online
Your site redirects visitors to spam, Google shows a "deceptive site" warning, or your host has quarantined the account: it's compromised, and cleaning it out of order makes things worse. We work in a fixed order — confirm the scope and date the intrusion, lock the attacker out, replace code from official sources instead of disinfecting file by file, close the way in, then get the Google warning lifted. It applies to WordPress as much as to Drupal, PrestaShop, Magento or a bespoke PHP application. Remote, worldwide, no subscription, billed in 30-minute increments, with a reply within two business hours.
What a compromised site actually looks like
- Visitors get redirected to ads, counterfeit shops or fake support pages — sometimes only on mobile, sometimes only when they arrive from Google
- Google shows "This site may be hacked" or a red "deceptive site ahead" warning before the visitor ever reaches your page
- Search Console reports a security issue: hacked content, injected spam, or thousands of pages you never created suddenly in the index
- Your search results contain words you never wrote — pharma, casino, replica — on URLs that don't exist in your site
- Your host suspended the account or quarantined the site after a malware detection and wants it cleaned before reactivation
- Administrator accounts you didn't create have appeared, or your own access was revoked
- Unknown PHP files turned up in your uploads folder, or .htaccess contains redirect rules nobody wrote
- The site was cleaned once and the problem came back days later: a backdoor or a scheduled task is re-injecting the code
- Your domain landed on a blocklist and your email now goes to spam or bounces, because the server was used to send spam
- You don't know whether customer data was exposed, or what technical evidence to gather to find out
How we clean it up, in order
- Confirm and date the intrusion before touching anything. We reproduce the symptom under the conditions where it appears (from Google, on mobile, on a specific URL), record the exact warning Google or the host displays, and list recently modified files to place the date of entry. That date is what tells us where to look next.
- Back up the infected state, then lock the attacker out. We take a full copy — files and database — even compromised: it holds the diagnostic evidence and the fallback point. Then we rotate every credential (admin, FTP/SFTP, database, hosting) and regenerate the CMS session keys, which immediately kills any session the attacker still has open.
- Measure the real scope. We compare the CMS core, plugins and theme against their official releases using file integrity checks, look for executable code where none belongs (uploads folders), inspect the head and tail of configuration files, and list administrator accounts and scheduled tasks. A scanner speeds up detection; it does not replace this reading.
- Replace rather than disinfect. Reinstalling the core, plugins and theme from official sources is more reliable than cleaning each file by hand: we keep only what cannot be replaced — your database content and your media, verified — and start from a known-good base instead of hoping we found everything.
- Close the way in, or it comes back. We identify the vulnerability used where possible: an outdated plugin with a known CVE, a reused password, an unfiltered file upload, an end-of-life PHP version. We update, remove what is no longer maintained, disable code editing from the admin interface, and restore correct file permissions.
- Verify, get the warning lifted, document. We re-test the key journeys, check that no redirect survives for a visitor arriving from a search engine or on mobile, prepare and submit the review request in Search Console, and if the domain was used to send spam we check its sender reputation and its SPF, DKIM and DMARC records before sending resumes. You get a written account of what we found, what we changed and what to keep an eye on.
Technologies & environments — examples, not a limit
This isn't a compatibility checklist. Sites get compromised whatever the CMS or framework, and the work is the same: understand how they got in, replace what's suspect, close the door. Tell us the symptom — the exact warning Google or your host shows, and when you first saw it — plus your environment (CMS, host, the access you still have), and we'll confirm quickly. Our scope is technical cleanup and hardening; we don't do court-grade forensics or legal advice.
Frequently asked questions
My site is hacked — what should I do first?
Don't delete anything and don't fire off blind updates. The first useful step is a backup of the current state, infected and all: it holds the diagnostic evidence. Then change every password — admin, FTP, database, hosting — because a stolen credential is the most common cause. If the site is already harming visitors, put it in maintenance rather than shutting the hosting down, which would cost you the traces. Then describe the exact symptom to us: we reply within two business hours.
Do I have to rebuild, or is my content recoverable?
In most cases the site is not rebuilt. Your content — posts, pages, products, orders — lives in the database, and your media in the uploads folders: those are what we keep, after verification. What we replace is the code: CMS core, plugins, theme. It exists in official form, and reinstalling it is safer than disinfecting it line by line.
Is a security scanner enough to clean a hacked site?
No. A scanner detects known patterns and is a good starting point, but it misses bespoke injections and, above all, it doesn't tell you how the attacker got in. Without that answer the site gets cleaned and then re-compromised. That's why we replace code from official sources and hunt for the entry point, instead of trusting a tool's report.
My site was already cleaned and the hack came back. Why?
Because the cleanup removed what was visible without closing the door: a backdoor left in an uploads folder, a scheduled task re-injecting the code, an abandoned plugin with a known vulnerability, or a stolen password never changed. This is the case we take over most often. We treat a reinfection as the symptom of an unidentified vulnerability, not as a cleanup to redo identically.
How do I remove the "this site may be hacked" warning in Google?
The warning doesn't disappear the moment the site is clean: you have to submit a review request from Search Console describing what was fixed. We prepare it once the site is genuinely clean — sending it too early wastes time, since a check that still finds injected code keeps the warning up. Google then re-reviews on its own timeline, which nobody can guarantee.
How long does a cleanup take, and what does it cost?
No subscription: we bill the time actually spent, in 30-minute increments, and give you an estimate after the first assessment. The effort depends directly on the scope — a single redirect in one or two files is nothing like several backdoors, a phantom admin account and a modified database. We tell you which case you're in before committing to the work. First reply within two business hours, and an urgency option lets us prioritise your request.
A compromised site costs you twice: in traffic and in trust. Tell us the exact symptom — the redirect, the Google warning, the message from your host — and your environment. We'll confirm we can take it on, tell you which scope you're in, and start with the assessment. If your host has suspended the account, we work with the access that remains and document the cleanup for your reactivation request. No subscription, billed in 30-minute increments, reply within two business hours.
Besoin d'une intervention ciblée ?
Décrivez le blocage — devis sans engagement, ou rappel sous 2 h ouvrées. Supplément urgence possible (+40€).