Defaced homepage, redirects to someone else's site, a warning in Google, a hosting account suspended. We remove malicious code from files and from the database, restore the WordPress core from official checksums, close the entry point they used β and hand over a report listing every single file we found. Malicious code on your site does not sit idle β it works at the expense of your domain. If even one of the symptoms below looks familiar, every hour counts. Search results show "This site may be hacked" and browsers throw up a red warning screen. Traffic drops to almost nothing within hours. The host's automated scanner found malicious content and took the site down. It will not lift the block without a cleaned server and a report of what was done. Instead of your offer, a stranger's page loads β usually gambling, pharmacy or crypto, often in a language you do not speak. Google shows pages under your domain full of Japanese or Chinese characters and links to shops you have never run. Unknown accounts appear in the user list β or worse, they exist in the database but are deliberately hidden from you. On a desktop the site looks fine, but visitors from a phone or from Google get thrown onto someone else's domain. Beware of the apparent calm. The most common pattern we see: the infection sits on the server for days without a single visible sign, right up to the moment the attacker defaces the homepage or the host suspends the account. If you see something in your logs or file list that you cannot explain, it is far cheaper to check now than to explain later how customer data ended up in someone else's hands. Attacks on WordPress are fully automated. Bots scan the internet non-stop for known vulnerabilities and do not care whether you run a million-euro store or a one-page brochure site. The pattern is almost always the same. Usually a vulnerability that allows uploading a file through a form, or running code without logging in. Nobody needs to know your password β an unmaintained component is enough. An uploaded PHP file that hands the attacker a file manager and a system console straight in the browser. It is often disguised as a WordPress file or as an image β in one of our cases the web shell posed as a .png inside a popular plugin's folder. Administrator accounts hidden from the user list, files in the mu-plugins folder that WordPress loads automatically, a keylogger capturing the admin password at login, entries in the database. All so they can come back after your "clean-up". That is why deleting one suspicious file settles nothing. Here is a real timeline from our own work β under three days from the first web shell to a suspended hosting account:
β a vulnerability in a file-upload plugin β β‘ web shells in the uploads folder β β’ a new administrator account β β£ four files in mu-plugins (including an admin-password keylogger and three files hiding the fake accounts) β β€ a defaced homepage β β₯ the host's automated suspension of the account.
Cleaning has to cover every layer at once β files, core, the mu-plugins folder, the database and the accounts. Otherwise the infection is back within hours, by exactly the same route. A complete clean-up, from the backup to the follow-up scan. We do not tick off "scanned with a plugin" β we go through every layer an infection can hide in. A full copy of files and database before we touch anything. There is always something to roll back to. We establish when and through what they got in. Without it you lock the door and leave the window open. We look for malicious code signatures, not just recent modification dates β including inside .png, .jpg, .ico, .css and .js files. Clean files from wordpress.org plus checksum verification, without touching wp-config.php or the uploads folder. We remove auto-loaded files, counterfeit plugins and leftovers from components that are no longer installed. Fake admin accounts, injections in content, options left by malicious plugins, orphaned cron events. New passwords, new salt keys, every active session invalidated. A stolen password stops working. Updating or removing the vulnerable component, blocking PHP execution in uploads, blocking xmlrpc.php. Database passwords and keys move outside the public folder, so one leaked file no longer hands over the whole install. A document listing every file found and every action taken, plus a second audit a few days later. The order is deliberate. First we preserve the current state, then we find the cause, and only then do we clean up β because cleaning without finding the entry point buys you a single day. We take SSH or FTP access plus the admin panel, run a full backup and assess the scale of the infection. Server logs and file timestamps. We establish how and when they got in, and what they managed to do. Files, core, mu-plugins, database, accounts. We scan by content until another pass returns nothing. Closing the hole, rotating passwords and salt keys, blocking PHP execution and xmlrpc, credentials out of the webroot. Documentation of the work plus a second audit a few days later, to confirm nothing has come back. After every stage you get a note on what was done and what it found β you never have to ask where things stand. The call came in after the fact: the hosting provider had already suspended the account because malicious content was found on the server. Below is the real timeline β first of the attack, then of the recovery work. Client name and domain available on their approval. The figures and sequence come from the actual reports written during this work. Cleaning the server is half the job. The other half is undoing what the infection did to your domain's visibility and to your standing with your hosting provider. We review security notices and β something that is easy to miss β check whether the attacker added their own verification of your domain in Google's tools. We found exactly such a code in a real case, inside the defaced homepage. Unauthorised access gets removed. Once the site is clean we submit a review request in Search Console. The "This site may be hacked" label and the red browser screen normally disappear within a few days of approval. We check how many injected URLs Google managed to index (Japanese keyword spam being the classic case) and request re-indexing of the clean versions so the foreign content drops out of the results. We prepare the ticket with a list of removed files and hardening measures applied β hosting providers lift suspensions on the strength of that kind of description, not on an assurance that "it is fine now". Why speed matters: as long as the site is infected, search engines keep indexing more foreign pages and your host keeps collecting more reports. Every day of delay means more URLs to clean out of the index and a slower return to your former rankings. Cleaning the server itself takes the same time on a Monday and on a Friday β the difference is what the infection leaves behind in Google. We quote after a short assessment, not halfway through the work. If the infection turns out to be extensive, we say so straight away along with the exact figure β instead of padding the invoice afterwards. One WordPress site, a standard file-level infection. from 159 β¬ netβ 690 PLN Β· one-off A store, a portal holding user data, or a repeat infection. from 299 β¬ netβ 1 290 PLN Β· one-off For those who would rather not go through this twice. Custom quotemonthly retainer Not sure which case is yours? Tell us what you see on the site and whether your host has already suspended the account. After a short assessment β usually within a few business hours β we give you a firm price and a deadline. Cleaning a single standard site usually takes 24β48 hours from the moment we have access. An extensive infection β several sites on one account, database backdoors, a repeat break-in β can take a few days. We give you a realistic deadline after the first assessment, not a guess at the moment you call. No. We start with a full backup of files and database, and we restore the WordPress core without overwriting wp-config.php or the uploads folder. Content, orders, customer accounts and media stay exactly where they are. We only remove what does not belong to your installation. A security plugin detects some known files and helps a great deal preventively, but after a break-in it is rarely enough. A web shell disguised as an image, a backdoor in the mu-plugins folder, an injection in the database, or a database management tool hidden under a WordPress filename β these routinely pass a standard scan. That is why we scan by file content and verify the core against official checksums. Infections return in two situations: the entry point was never closed, or one backdoor was left behind. That is why every clean-up ends with hardening and a follow-up scan a few days later. If an infection returns by the same route after our work, we come back to it at no extra charge. Yes β that is a very common starting point. Hosting providers usually leave FTP or SSH access available while the site is down, or re-enable it for the duration of the work once you ask. We help write that request, and after cleaning we prepare the list of removed files and hardening measures β which is exactly what the suspension gets lifted on. SSH or FTP access, access to the WordPress admin (if it still works) and to the hosting panel. Server logs from the last few days are very useful β that is what we reconstruct the attack timeline from. If you do not know where to find any of this, we will walk you through it step by step; you do not need to be technical. In most cases yes β server logs let us identify the vulnerable component, the moment of entry and what the attacker managed to do. It all goes into the report together with the list of removed files. If the logs have already been rotated by the host, we work from file analysis and say so plainly rather than guessing. WordPress and WooCommerce are our specialism β that is where most cases come from and where we have the most established procedures. With other PHP-based systems we can usually help too. Tell us what the system is and we will answer honestly whether we are the right fit, rather than learning on your outage. Every hour means more foreign pages in Google's index and a higher chance your host pulls the plug. Tell us what you see on the site β we will run a quick assessment and say plainly how long the fix takes and what it costs.Site hacked? We clean it, close the hole and hand you a report.
Symptoms you cannot wait out
Google warns about your site
Your hosting account is suspended
Defaced homepage
Foreign pages in search results
Admin accounts you never created
Redirects only on mobile
It is not bad luck β it is one outdated plugin
A hole in a plugin or theme
A web shell
Backdoors and hidden accounts
Exactly what we do
Backup before cleaning
Server log analysis
Content-based file scanning
WordPress core restore
mu-plugins and plugins
Database clean-up
Password and key rotation
Closing the entry point
Credentials out of the webroot
Report and follow-up scan
Five steps to a clean server
Report and access
Vector analysis
Clean-up
Hardening
Report and re-scan
An industry portal with WooCommerce β from a suspended host to a clean server
Timeline
Google warnings and hosting suspensions β we handle those too
Search Console and domain hijacking
Review request
Foreign pages in the index
Getting your hosting unblocked
A clear figure before we start
Malware removal
Report an infection
Post-hack audit + hardening
Ask for a quote
Care and monitoring
Ask about care plans
Malware removal β frequently asked questions
Site infected? Do not wait until morning.