A hacked website does not always crash. It can still display your services, take form submissions, and process orders—all while quietly redirecting select visitors, serving spam, sending out phishing emails, or giving an intruder back-door access to your dashboard.
That is why, once a breach is detected, finding and deleting a suspicious file is never enough. You need to identify what the attacker accessed, close their entry point, rotate credentials, and only then bring the site back online safely.
How to tell if your website has been hacked
Sometimes, it is unmistakable: the site redirects straight to an unknown domain, displays unfamiliar content, or triggers a bright red security warning in Google Chrome.
More often, the early signs are subtle.
A new administrator account might appear out of nowhere. Google starts indexing pages under your domain advertising casinos, pharmaceuticals, or counterfeit goods you never created. Your hosting provider flags outbound spam. Customers report erratic redirects that you cannot reproduce on your own screen.
When this happens, check Google Search Console and inspect the indexed pages for your domain. If you spot unfamiliar URLs and content, act immediately—do not wait for more obvious signs to surface.
Attackers often intentionally serve modified versions of a site only to search engines or specific visitor groups. As an administrator logging in directly, you might see a perfectly healthy site the entire time.
Do not start by deleting suspicious files
The instinctive reaction upon spotting malicious code is to wipe it immediately. While understandable, this often destroys critical forensic evidence needed to determine how the breach occurred in the first place.
Before you start cleaning, preserve the current state: take a snapshot of the files, dump the database, and export server logs. This compromised snapshot is not meant for restoring the site; it is the evidence file that lets developers compare changes, locate backdoors, and establish the attack timeline.
If the site is actively distributing malware, redirecting visitors, or attempting credential phishing, your priority is to take it offline or restrict public access until the threat is contained.
For an online shop, account for ongoing orders and payments. Deleting files rashly or restoring an outdated database backup can wipe out real transactions that went through just before the breach was noticed.
Assume more than one password was compromised
Once someone gains administrative access to your CMS, you cannot assume they only hold that single password. They may have harvested credentials for your hosting panel, server, FTP, email, or connected services.
Because of this, changing only your WordPress administrator password will not solve the problem.
Review every single access point related to your infrastructure and rotate any credentials that could have been compromised. This covers the CMS dashboard, hosting portal, server, FTP/SFTP, databases, and administrative email accounts.
If the same passwords were used across other business services, broaden your audit accordingly.
Review user lists and privilege levels thoroughly. Any unrecognised account should be treated as part of the compromise—not merely deleted and dismissed.
Check access keys that work independently of standard passwords
This is one of the most common reasons websites get compromised again shortly after all visible passwords have been changed.
WordPress, WooCommerce, and external integrations frequently rely on separate API keys, application passwords, and access tokens. Changing a user’s login password does not automatically revoke these existing keys.
If an attacker generated an API key or an application password during their session, they can continue communicating with your backend long after your cleanup finishes.
A post-breach audit must include tokens and permissions used by your integrations. Do not just delete everything: establish which keys are required, who generated them, and verify that their current activity matches expected behaviour.
The core question: how did they get in?
Removing malicious code deals with the consequence of a hack. It does not address its root cause.
If an intruder entered through a vulnerable plugin and you clean the files without updating or removing that plugin, the site will be reinfected almost immediately. The exact same risk applies to compromised credentials, dormant admin accounts, or open server ports.
Before putting the site back live, pinpoint when changes were first introduced and what vulnerability allowed them.
In WordPress setups, pay close attention to plugins and themes. The larger your third-party codebase, the broader your attack surface and the greater your update burden.
Deactivating an unused plugin does not make it safe. As long as those files sit on your server, their vulnerabilities can still be exploited directly.
Is restoring a backup enough?
Not necessarily.
A clean backup made before the intrusion makes recovery much faster, but you have to know precisely when the breach started. A backup from yesterday will not help if an attacker has held persistent access for three weeks.
Restoring files also fails to close the entry vulnerability. If an unpatched plugin or leaked password let them in, the restored site remains just as vulnerable as before.
In an online shop, there is also the risk of data loss. Rolling back to an older database backup can erase recent orders, new customer registrations, invoice records, and order statuses recorded after the snapshot was taken.
A backup is an essential recovery tool, not a silver bullet for every security incident.
Check whether customer data was compromised
A compromised server and a personal data breach are not always the same thing. However, you must determine whether the intruder had access to data stored on your infrastructure.
In an e-commerce shop, this could mean customer addresses, phone numbers, and order histories. On a corporate website, it might involve contact form submissions. For custom web applications, the scope is often wider.
If there is any possibility of personal data exposure, this is no longer purely a developer’s task. You must evaluate the incident against legal data protection obligations.
Under GDPR, risk assessment and the strict 72-hour notification window for supervisory authorities come into play. Do not postpone this legal review until all technical work is finished.
What to do if Google flagged your site as dangerous
Cleaning malware off your server does not automatically remove Google’s security warnings.
If Google detects malware, deceptive content, or phishing pages, specific warnings and sample URLs appear inside Google Search Console.
Resolve the root vulnerability and remove every trace of the compromise first. Only once the entire site has been verified clean should you request a security review.
In your review request, be transparent and concrete: outline what was detected, how the site was cleaned, and what technical steps were taken to prevent recurrence.
Never request a review right after deleting the first malicious file you spot. If Google’s crawlers find remaining malicious scripts or spam pages during their scan, the request will be rejected, extending your downtime.
How long does it take for Google to lift a security warning?
There is no single timeline for every site.
Google treats different security issues with different priority. Phishing warnings can be reviewed within a day or two, while complex malware infections or domains flooded with thousands of spam pages often take longer to clear.
Even after a successful review, browser security warnings and search engine results pages do not update globally at the exact same instant.
De-indexing spam pages is a separate process. If an attacker injected hundreds or thousands of spam URLs, removing them from Google’s index can take weeks longer than clearing the primary security warning itself.
Monitor search results after the warning is lifted
A successful review in Google Search Console does not mean you can walk away.
Continue checking what pages Google surfaces for your domain over the following weeks—especially if the attacker generated new URLs or injected doorway links.
Keep a close eye on organic traffic trends, new alerts in Google Search Console, and unusual server activity.
If spam URLs resurface, it means either the original vulnerability was never closed or an obfuscated backdoor was left behind to regenerate the malicious content.
How to minimise the risk of future attacks
Fixing the initial vulnerability comes first. Once the entry point is sealed, layer in structured defenses.
Keep WordPress, WooCommerce, PrestaShop, themes, and plugins consistently up to date. Delete unused extensions completely rather than leaving them deactivated. Restrict administrative privileges strictly to individuals who require them right now.
Enforce two-factor authentication (2FA) across all administrative accounts and ensure automated backups are stored offsite, completely isolated from your production server.
Proactive monitoring is equally essential. If unexpected file changes occur, the site throws unhandled errors, or traffic patterns spike unnaturally, your technical team should know about it well before a client calls to complain.
When is a compromised site genuinely safe again?
Not when the homepage simply starts loading again.
A website is properly recovered only after all malicious modifications have been wiped, user permissions and integration keys audited, compromised credentials replaced, unpatched components updated, and the entry vector verified and closed.
For online shops, this also requires auditing transactions, payment gateways, and integrations that ran during the compromised window. When search penalties are involved, it means monitoring Google Search Console and search indexes until they are clean.
The worst outcome is rushing a surface cleanup only to leave the original back door wide open.
What to do if your site is compromised right now
If you suspect an active breach, do not start deleting files at random or installing arbitrary security plugins on top of an infected site.
First, secure an image of the current state, determine the blast radius, restrict further unauthorised changes, and identify the point of compromise. Only then can you safely proceed with malware removal and restoration.
At DOCK, we handle ongoing technical care and development for websites and online shops running on WordPress, WooCommerce, PrestaShop, and custom stacks. When an incident hits, we investigate the scope, remove malicious code, secure access points, and guide you through Google review procedures.
Once resolved, we configure continuous monitoring and proactive maintenance routines so any future anomaly is caught immediately.
