A website can still open after it has been tampered with
At 10 p.m. last Tuesday, I was in Hangzhou helping a client update their company website. The page looked normal, and I could still log into the backend. A few days later, the client said the search results were redirecting to an unfamiliar page. I assumed it was just a cache issue and nearly rebuilt the site from scratch. The real problem was not that one site had broken; it was that we had no idea which sites in the wider batch had been silently altered.
I have hit the same uncertainty: a self-built site still works, but there is a strange block of code in a corner; a client says the page looks different on mobile; an SEO ranking suddenly drops. Panic makes sense. I got stuck too: at the time, I could not even tell the difference between “normal access” and “malicious content injected into the site.”
Public clues can help rank the risk, but they are not a full checkup
The incident was later discussed publicly: researchers confirmed that around 15,579 websites had been infected. In a public analysis from October 2020, Scott Helme noted that teams knew infections existed but struggled to identify the specific affected sites. He shared public indicators that website owners could use to shortlist suspicious cases.
Here is how this played out in practice: in October 2020, a London production company found suspicious scripts across several client websites. Instead of reinstalling every system, the team listed the sites that matched the public indicators and then asked their hosting providers to investigate. This works for narrowing the search space, not for certifying a website as secure.
If someone hands you an infected-site list and asks you to follow it, it is worth pausing. A list usually means “these sites match certain suspicious characteristics,” not that every listed site was compromised. Conversely, a site missing from the list is not necessarily safe. It is also reasonable to defer this work, especially if all you have is a simple brochure site with no user data.
Reproduce it today: spend $0 on a low-barrier first pass
Replication cost: $0; 2–4 hours of time, provided you can already log into the website backend or hosting panel; and a technical barrier of being able to read a snippet of HTML source code and copy a URL. Programming knowledge is not required. The first step is to open the public analysis link in the article and find its detection entry point. If you have a list of client sites, test one first rather than running a batch operation immediately.
I would not advise a nontechnical founder to run unfamiliar scripts against their own computer. The safer route is to list the latest modification times for the website, hosting account, and code repository, then have a developer or hosting provider check the public indicators, backups, and login records. My earlier mistake was focusing only on whether the page opened and forgetting to check who had modified backend files, and when.
Choose a stage and do only what that stage needs
If I am just starting out with one or two brochure sites, I would do two things first: turn on automatic backups, and record the hosting credentials and main administrator details. Public-indicator checks can come second; that is not worth buying a complex service for.
If I already have one or two clients, I would make a simple checklist: site URL, hosting provider, latest backup time, and developer contact. If something looks wrong, I would capture screenshots as evidence before asking a professional to investigate, rather than deleting files and destroying the clues along with them.
If I am scaling and managing more than 10 sites, I would make the checks part of a routine: sample website files monthly, keep change logs, and have a trusted security professional review the rules once. Not everyone needs this process. If I sell consulting, courses, or offline services and do not have website backends yet, I would skip it for now.