Few things worry a business owner like a red warning screen in front of their own website. Google shows these warnings when it believes a site has been hacked or could harm visitors. The good news is that there is a clear process for cleaning up and asking Google to look again.
This guide explains what the warnings mean and where to find the details. It then covers the recovery steps Google itself recommends. It is written for business owners who need to understand the job, even if a developer does the hands on work.
What Google’s warnings look like
Google’s Security issues report in Search Console lists what it has found on your site. Affected pages can carry a warning label in search results. Visitors may also see a full warning page in the browser before they reach your site. For malware, Chrome may show a Dangerous warning.
Some warnings are milder. Uncommon downloads trigger a Chrome warning about the file but do not keep pages out of search results. Google lifts those warnings automatically once the files are verified as safe. Possible phishing on a login page can trigger a password reuse prompt for users.
The three types of security issue
The report groups problems into three broad categories. Hacked content is anything placed on your site without permission through a security weakness. Malware and unwanted software is software built to harm a device or its users. Social engineering is content that tricks visitors into revealing confidential details or downloading software.
Within those groups, Google lists specific issue types. Errors include code injection, content injection, URL injection, deceptive pages and harmful downloads. Warnings include suspected deceptive pages and possible phishing detected on a user login. Each issue comes with sample URLs, though Google notes that list is not necessarily complete.
Do not open infected pages in your normal browser to check them. Google suggests using the URL Inspection tool or a command line tool such as cURL instead. Safe Browsing warnings also vary with browsing context, so you may not see what a customer sees. Google treats the report as the source of truth for whether issues exist or are fixed.
First, take the site offline
Google’s web.dev recovery guide starts by quarantining the site. That means stopping the web server or pointing your DNS to a static page elsewhere that returns a 503 status. Going offline keeps harmful files away from visitors. It also makes it harder for the attacker to interfere while you work.
The guide says brief downtime is unlikely to hurt future rankings. It also warns that a robots.txt block is not enough, because it only stops search crawlers and not real people. The 503 page should be served from outside the compromised server. Your hosting provider may be able to set this up for you.
Tell your host what has happened as soon as you can. This is especially useful if they can serve the 503 page from outside your infected files. Next, review every user account on the site and note any the attacker created before deleting them. Then change passwords for all accounts, including FTP, database, admin and CMS logins.
Work out how they got in
Cleaning a site without finding the weakness leaves the door open. Google’s guidance lists four common ways sites are compromised. They are worth checking one by one with your developer.
- Infected admin computers. Spyware on a device used to sign in can record keystrokes and capture logins.
- Weak or reused passwords. These are easy to discover and can give direct access to the server.
- Outdated software. Old versions of the CMS, plugins or operating system may have known security advisories.
- Permissive coding. Open redirects and SQL injection through form fields both feature in the list.
Contracts matter here too. If an outside developer built or maintains the site, check who holds the logins and the code. Agreements covering design work, such as those discussed in non disclosure agreements for business website designs, can also shape who may access what. Knowing this before a crisis saves time during one.
Back up before you clean
It sounds odd, but Google’s guidance says to back up the infected site before cleaning it. Label these copies as infected and keep them aside. They help with investigation and act as a fallback if something goes wrong. Make copies of both the files and the database.
Then look for a clean backup. The guide stresses checking that the backup was created before the site was hacked. A clean and current backup can be restored, then updated and patched. An older clean backup can be restored and compared against the infected copy so only clean new content is carried across.
Backups only help if they exist and are stored somewhere safe. Physical risks to hosting hardware are part of that picture, as covered in our piece on server room fire safety. Regular automated backups kept away from the live server give you options when something breaks.
Clean, update and tidy up
If there is no clean backup, the files and database need cleaning by hand. Google recommends doing this on a copy rather than the live server. Files the attacker created should return a 404 response once removed. Hacked database records need cleaning too, and the guide advises checking more records than you think necessary.
Install every available update for the CMS, plugins, templates and server software. Google suggests a clean install rather than a simple upgrade, because upgrades can leave old files behind. Remove widgets, plugins and applications you no longer use. Fix any file permissions that are too loose, then change all passwords again.
Google’s guide to cleaning and maintaining a hacked site sets out a final checklist before going live again. The latest software should be running and unused software removed. Content should be restored and the root weakness fixed. You should also have a plan to keep the site secure from here.
Request a review from Google
Once every issue is fixed on every page, use the Request Review option in the Security issues report. Fixing only some pages does not earn a partial return to search results. A good request explains the exact issue, the steps taken to fix it and the outcome. Do not resubmit while a request is pending, and wait for a decision first.
Google says most reviews take several days or weeks. Reviews involving links can take longer. You receive an email when the request arrives and another when the review is complete. If you recently bought a site that already had issues, fix them and say so in your request.
Rebuilding trust after a hack
A clean site is only part of the job. Customers who saw a warning may want reassurance. A short and honest note about what happened and what changed can help. Good storytelling for your brand works best when it is truthful, and a security scare is no exception.
Prevention is cheaper than recovery. Google’s guidance points to regular automated backups, prompt software updates and strong passwords. It also advises checking the security of plugins and third party software before installing them. Keeping the devices you sign in from secure matters as well. Ongoing care like this belongs alongside the website development services a site needs after launch.
Frequently asked questions
How long does it take Google to remove a hacked warning?
Google says most security reviews take several days or weeks. Reviews related to links can take longer. You will get an email when the review is complete.
Will taking my site offline hurt my rankings?
Google’s recovery guide says brief or temporary downtime is unlikely to hurt future search rankings. Serving a 503 status from outside the infected server is the suggested approach. It protects visitors while you clean up.
Can I just fix the pages Google listed?
No. Google’s sample URL list is not necessarily complete. It also says fixing only some pages does not earn a partial return to search results, so fix the whole site before requesting a review.
Is a robots.txt block enough to protect visitors?
No. A robots.txt disallow only blocks search engine crawlers. Real visitors can still reach the harmful content, which is why taking the site offline is recommended.