Website security is the set of measures that stop an outsider from reading, changing or using a website and its data without the right to do so. It covers the server, the CMS, the plugins, the accounts that hold the keys and the traffic that passes between the site and the visitor's browser.
If you want to know where you stand, the first place to open is the Security issues report in Google Search Console. A security plugin tells you what it has found on your server; that report tells you what Google has found, and Google is the one that decides whether a searcher sees your result or a warning in its place.
The three things Google flags, and what searchers see
The Search Console documentation groups security issues into three categories, and for each one both the symptom and who sees it change.
| Category | What has happened | What the user sees |
|---|---|---|
| Hacked content | Someone has placed content on the site by exploiting a vulnerability | Google tries to keep those pages out of the search results |
| Malware and unwanted software | The site hosts or distributes software that harms the device of whoever downloads it | A warning in the SERP and a Chrome interstitial page before entering |
| Social engineering | Pages that pose as a trusted entity to obtain passwords or data | A Google Safe Browsing warning before the page loads |
The third category is the one that most often comes as a surprise, because the site does not need to have been hacked: a deceptive ad served by an ad network inside your pages is enough. Google is explicit on this point: embedded third-party content triggers the violation on the page that hosts it.
"Google penalises sites without SSL" is one of the most repeated claims on the subject, and it is inaccurate
HTTPS sits at the top of almost every checklist. On Google UK for "website security", the AI Overview lists HTTPS and SSL as its first best practice and the top organic result, a Reddit thread, puts HTTPS at number one (DataForSEO, Google UK, September 2026). From there it is a short step to saying that a site without a certificate gets penalised in the rankings. The original source says something else. When Google announced HTTPS as a ranking signal on 7 August 2014, it described it as a very lightweight signal, carrying less weight than content quality and affecting fewer than 1% of global queries. No increase in that weight has been announced since.
A missing SSL certificate is not a penalty. It is a "Not secure" label that Chrome shows in the address bar, and the damage comes from the user who leaves, not from the algorithm. A compromised site is a different matter: there, Google states that it does its best to remove those pages from the index.
It is also worth keeping apart the two things that both end up under the word "penalty", because they are fixed in different ways and sit in two different reports.
| Security issue | Manual action | |
|---|---|---|
| Typical cause | The site is compromised or harms its visitors | An attempt to manipulate the search index |
| Signal visible to the user | A label in the SERP or an interstitial in the browser | None: the site simply drops or disappears |
| Where to find it | Security issues report | Manual actions report |
| How it is closed | Cleaning the site and requesting a review | Removing the violation and requesting reconsideration |
In the UK, attackers come in through the inbox and the login, not through zero-days
The government's Cyber Security Breaches Survey 2025/2026, published on 30 April 2026 and based on 2,112 UK businesses interviewed between August and December 2025, contains the figure that should set the priorities of anyone running a website: phishing remains by far the most common type of breach or attack, experienced by 38% of businesses.
The other numbers from the same survey: 43% of businesses identified a breach or attack in the previous 12 months, about 612,000 businesses. The share rises with size, from 42% of micro businesses and 46% of small ones to 65% of medium and 69% of large businesses. Impersonation fell to 12%, from 17% in 2023/2024, and ransomware was reported by 1% of businesses, down from 3%. On the defensive side, only 47% of businesses use two-factor authentication.
Translated for anyone with a website: the way in is almost always an account, not an exotic flaw. A former contractor whose login is still active, a reused password that turned up in a data leak, a developer account created for a job two years ago. It is also why keeping the CMS and plugins updated matters so much: WordPress, Drupal and Joomla are easy targets because the vulnerabilities of old versions are public and can be exploited automatically.
How to check a site in fifteen minutes
The sequence below is the one Google itself describes on the report's help page, and it needs no paid software.
- Open the Security issues report in Search Console. If there is a green tick, Google considers you clean at the moment.
- Check the domain's status on Google Safe Browsing, the service that protects more than five billion devices a day and powers Chrome's warnings.
- Search Google for site:yoursite.co.uk with a few spam terms (pharmacy, loans, casino) and for site:yoursite.co.uk/wp-admin/. Pages you did not create show up here before they show up anywhere else.
- Inspect a couple of URLs with the URL Inspection tool, not with your browser. Many attacks show the spam only to Googlebot: that is cloaking, and its purpose is precisely to stop the owner from noticing.
- Search the source files for the strings eval, base64_decode and unescape. These are the terms Google's documentation points to for finding obfuscated code injected into pages.
One recommendation that checklists tend to leave out: do not open a page you suspect is infected in your browser. Google says so plainly: malware often spreads by exploiting browser vulnerabilities. To inspect a page from the command line, use curl with a Google referrer and an old user agent, because many attacks only activate with that combination.
When the site is already compromised, the order of operations matters
Clean first, then request the review. The other way round does not work, and the documentation warns that submitting a request before the problem is fixed lengthens the response time for the next request and may be treated as a repeat violation.
The clean-up has to cover every page, not just the sample URLs: Google states that fixing the problem on only some pages does not guarantee partial reinstatement in the results. You replace the affected files with the last good backup, or remove the injected content by hand, and look for new pages the attacker has created.
To be valid, the review request has to meet three stated criteria: explain the problem precisely, describe the steps taken to fix it and document the outcome of those steps. The review takes from several days to a few weeks. If you have recently bought a domain with pre-existing problems, the documentation says to state this explicitly in the request, and it is worth checking before the purchase alongside the usual technical checks.
If the site brings in customers, the long part is not the clean-up but the recovery: the pages go back into the index, the rankings do not, at least not straight away. That is the moment to bring in someone who works on organic search while whoever runs the server closes the hole.
Website security FAQs
HTTPS has been one since 2014, but Google described it as a very lightweight signal, affecting fewer than 1% of global queries and carrying less weight than content quality. A compromised site is a different case: there Google states that it does its best to keep hacked content out of the search results.
The review only starts once you submit a request from the Security issues report, and it takes from several days to a few weeks. Submitting the request before the site has been cleaned lengthens the response time for later requests.
No. It encrypts the data passing between the browser and the server, and it does not protect against stolen credentials, outdated plugins or injected content. Many phishing pages use HTTPS too: the padlock says the connection is encrypted, not that the site is honest.
Use the Site Status tool in Google's Transparency Report. Warnings are shown depending on the browsing context, though, and you may not be able to reproduce them: the reliable source Google points to is still the Security issues report in Search Console.
According to the UK Cyber Security Breaches Survey 2025/2026, 42% of micro businesses identified a breach or attack in the previous 12 months. Scanning for vulnerable versions is automated and does not pick its targets by turnover.
One last point, rarely made in this industry. The measure with the best ratio of cost to risk avoided is not the web application firewall: it is the list of who still has an account. A WAF does not stop a correct password, and phishing, the most common attack in the government survey, usually ends in a legitimate login. Deleting the accounts of people who no longer work on the project and switching on two-factor authentication for the rest takes an afternoon and closes the most used door. The same goes for backups: one you have never tried to restore is not a backup, it is a file.
