Is Your Website Actually Secure? The Questions Every Business Owner Should Be Asking

Most business owners find out their website was compromised from a customer, from Google, or from a sudden collapse in search traffic. Almost never from their own monitoring, because they do not have any.

We build websites, and we also break into them for a living when clients hire us to test their own. Below is what we get asked most often, answered straight, including the parts that make our own industry look bad.


Part 1: The Threat Picture

1. My business is small. Why would anyone target me?

Because you are not being targeted. That is the part people get wrong.

Almost nothing that hits a small business website is a person who chose you. It is automation, scanning the entire internet for a specific vulnerable plugin version, taking whatever it finds. Your business could be a bakery in Ampara or a law firm in Detroit and the scanner does not know or care.

The data backs this up hard. Around 43% of all cyberattacks are aimed at small and medium businesses. Small businesses receive targeted malicious emails at the highest rate of any size category, roughly 1 in every 323. And 59% of SMB owners with no security in place believe they are too small to be attacked, which is precisely why attackers like them.

Roughly 13,000 WordPress sites are hacked every day. Nobody hand-picked them.

2. What actually happens when a site gets hacked?

Forget the image of a defaced homepage with a hacker logo on it. That is almost extinct, because it makes no money.

What actually happens is quieter and much worse for your business:

SEO spam and cloaking. The attacker serves one version of your site to Google's crawler, stuffed with spam keywords and links to gambling or pharmacy sites, and a completely normal version to you and your customers. Your site looks fine every time you check it. Meanwhile Google is indexing thousands of spam pages under your domain. The dominant malware families in 2025 and 2026, including the Japanese SEO campaign, jgalls, and Parrot TDS, all use exactly this cloaking approach.

Redirects. Visitors arriving from Google get bounced to a phishing page or a fake store. You do not, because the malware checks the referrer and skips repeat visitors.

Quiet data theft. Customer records, form submissions, and order data slowly exfiltrated while everything appears normal.

Your server used against others. Sending spam, mining crypto, or participating in attacks on someone else, which gets your IP and your domain blacklisted.

The reason this matters: you will not notice. As Patchstack put it in their 2026 report, hosting providers often do not discover compromises until the damage is already done, whether that is a collapse in rankings, customers complaining about redirects, or a security blacklist. By the time it is visible, the attacker already got what they came for.

3. What does an incident actually cost?

For a small business website compromise, the realistic figure is around $14,500 in total recovery. That is not the malware removal fee, which is usually a couple of hundred. It is malware removal plus emergency developer time plus downtime plus lost revenue plus the months of SEO work needed to undo injected spam links and clear a Google manual penalty.

If it escalates into a real data breach, the numbers get serious. Verizon's 2025 DBIR puts typical SMB incident costs between $120,000 and $1.24 million. Downtime alone runs around $53,000 per hour. And 40% of SMB owners say an attack costing $100,000 or less would put them out of business.

The comparison that matters: prevention runs somewhere between 50 and 60 times less than recovery. Ongoing protection is a line item. Recovery is an emergency.


Part 2: How Sites Actually Get Broken Into

4. My site is on WordPress. How exposed am I?

WordPress itself is fine. Patchstack recorded only 6 vulnerabilities in WordPress core across all of 2025.

The problem is everything you bolted onto it. In that same year there were 11,334 new WordPress vulnerabilities recorded, up 42% year on year, and 91% of them were in plugins. Cross site scripting alone accounted for 47.7%.

Two numbers should worry you more than the total:

57% of vulnerabilities in the first half of 2025 required no authentication at all. No stolen password, no login. Just a vulnerable plugin, installed and active on your site.

The median time from public disclosure to mass exploitation is 5 hours. Not 5 days. If a flaw in a plugin you use is announced on a Tuesday morning, the scanners are hitting your site before lunch.

For scale, one week in January 2026 saw 333 new vulnerabilities disclosed, 253 in plugins and 80 in themes. That is a normal week.

5. I keep everything updated. Isn't that enough?

No, and this is the uncomfortable part.

A large share of vulnerabilities have no patch when they go public. Patchstack found more than half of plugin developers they reported flaws to did not ship a fix before public disclosure. You cannot update your way out of a hole that has no fix yet.

Updates themselves have become an attack vector. In April 2026, over 30 WordPress plugins were found carrying a deliberately planted backdoor. The attacker had bought the entire Essential Plugin portfolio on Flippa for six figures, inserted a PHP deserialization backdoor in August 2025, and left it dormant for eight months before activating it to serve cloaked SEO spam to Googlebot. It arrived on thousands of sites disguised as routine compatibility updates. WordPress.org pulled 31 plugins on 7 April 2026. The same week, Smart Slider 3 Pro, with over 800,000 installations, was separately compromised through its update infrastructure.

Nobody running those sites did anything wrong. They updated their plugins, exactly as advised, and that is how they got infected.

And attackers have changed where they hide. The 2026 Patchstack and Monarx research shows a shift toward injecting malicious code directly into legitimate WordPress core, plugin, and theme files instead of dropping obvious new files. The standard scan-and-delete approach misses this completely. Another common trick is the must-use plugins directory, wp-content/mu-plugins, which executes automatically on every page load and does not appear in your admin plugin list at all. Most site owners have never looked in it.

Updating is necessary. It is nowhere near sufficient.

6. My hosting company says they handle security. Do they?

Partially, and much less than the marketing implies.

Patchstack's 2026 whitepaper found that 87.8% of exploits bypass standard hosting defences. Separately, traditional web application firewalls block only about 12% of WordPress-specific attacks, because generic firewall rules are written for generic attacks, not for the specific logic flaw in the specific plugin you happen to run.

There is also the shared hosting problem. Hundreds of sites often sit on one server. Without proper isolation, one compromised neighbour can reach across to you. Your security posture becomes the posture of the least careful person on the box.

Your host protects the building. What happens inside your unit is yours.

7. How would I even know if I had been hacked?

If you are relying on looking at your own site, you would not. That is the entire design goal of modern cloaking malware.

Real warning signs, in rough order of how often we see them:

  • Search traffic drops without any algorithm update to explain it
  • Google Search Console shows indexed pages you never created, often in another language
  • A "this site may be hacked" label appears under your search listing
  • Customers mention being redirected, but it never happens to you
  • Your emails start landing in spam because your domain got blacklisted
  • Server CPU or bandwidth jumps with no traffic increase to match
  • Files with recent modification timestamps that nobody on your team touched

The reliable answer is not vigilance. It is monitoring: file integrity checking, external scanning from an IP that looks like Googlebot, and log analysis. Those catch it in hours. Eyeballs catch it in months.


Part 3: What We Actually Do About It

This is the part most agencies wave at with the word "secure" in a bullet list. Here is our actual work.

8. What is in an ELRQ security audit?

A fixed-scope engagement, delivered as a written report you own, with everything ranked by real risk rather than by scanner severity score.

Surface mapping. Every subdomain, every exposed service, every open port, every forgotten staging site. Old staging environments are one of the most common ways in, because nobody patches something they forgot exists.

Dependency and supply chain review. Every plugin, theme, package, and third-party script you run, checked against known vulnerability databases, plus ownership and maintenance status. A plugin that has not been updated in two years is a liability. A plugin that quietly changed hands is a bigger one.

Configuration review. Web server config, TLS, security headers, Content Security Policy, cookie flags, CORS, directory listing, exposed .git folders and backup files, admin path exposure, file permissions.

Application testing. Authentication and session handling, access control between user roles, injection points, file upload handling, forms, API endpoints, and rate limiting. We test against the OWASP Top 10 as a floor, not a ceiling.

Compromise check. File integrity comparison against known-good sources, cloaking tests where we request your pages while presenting as Googlebot and compare against a normal browser request, malicious cron and scheduled task review, database inspection for injected content, and a look in the places malware actually hides including mu-plugins.

Data and privacy review. What personal data you collect, where it sits, who can reach it, how long you keep it, and whether your policies match your reality.

You get a report with an executive summary a non-technical owner can act on, a technical appendix your developer can work from, proof of concept for anything we found, and a prioritised remediation plan with effort estimates. If you want us to do the remediation, we quote it separately. If you want your own team to do it, the report is written so they can.

9. What does hardening actually involve?

Depends on the stack, but the core of it:

  • Cut the attack surface. Every plugin removed is a vulnerability class deleted. We routinely remove half of what we find, replacing bloated plugins with a few lines of code.
  • Web application firewall, tuned. Not a default install. Rules written for your actual stack, with virtual patching so a newly disclosed flaw is blocked at the edge before the vendor ships a fix. This is what closes the 5-hour window.
  • Security headers and a real Content Security Policy. Locks down what can execute and where data can be sent, which converts many XSS findings from critical to unexploitable.
  • Admin lockdown. Multi-factor authentication, admin paths moved and IP restricted, brute force protection, session hardening, least privilege on every account. Weak or stolen passwords are a contributing factor in a large majority of hacked WordPress sites.
  • File permission and write access lockdown. Most sites let the web server write to directories it has no business writing to. That is how a small upload flaw turns into a persistent backdoor.
  • Server and TLS hardening. Including the nginx and Apache config, which is a place attackers love because changes there are invisible from the CMS admin panel.
  • Isolation. Separate database users, separate environments, staging that is not publicly reachable, and secrets kept out of the codebase.
  • Backups you have actually tested. An untested backup is a belief, not a backup. We restore one and time it, so you know your real recovery window.
  • Monitoring. File integrity, external cloaking checks, uptime and blacklist monitoring, log alerting, and Search Console alerts routed to a human who reads them.

10. What if my site was built by someone else?

That is most of our security work. We do not require you to rebuild with us and we do not use the audit as a sales trap for a redesign.

If your existing developer is good, we hand them the report and they fix it. If they are not, or they have gone quiet, we do the remediation ourselves. Plenty of our clients keep their current site and their current developer and just add us for security. That is a completely valid arrangement.

11. What happens if I get hacked while you are managing my site?

You call us and we start immediately. Our incident process:

  1. Contain. Get the site into a safe state so damage stops accumulating. Sometimes that is maintenance mode, more often it is targeted blocking so you stay open for business.
  2. Preserve evidence. Snapshot everything before cleaning. If you skip this you never find out how they got in, and you get reinfected.
  3. Find the entry point. Log analysis and file timeline reconstruction. Cleaning malware without finding the door is the single most common failure in this industry, which is why reinfection rates are so high.
  4. Clean properly. Restore modified core and plugin files from verified sources rather than deleting suspicious-looking code. Remove every persistence mechanism, including cron jobs, mu-plugins, injected database rows, and rogue admin accounts.
  5. Close the door and rotate everything. Patch or virtually patch the entry point, then rotate all credentials, keys, salts, and tokens.
  6. Recover reputation. Detailed below, because this is the step nearly everyone skips.
  7. Write it up. You get a plain-language report on what happened, what data was and was not exposed, and what changed so it cannot recur. If you have notification obligations, you have the facts you need.

12. Do you handle the SEO damage, or just the malware?

Both, and this is where most security vendors leave you holding a cleaned site with wrecked rankings.

The malware is usually gone in a day. The search damage takes weeks and needs deliberate work:

  • Full inventory of the spam URLs Google indexed under your domain
  • Correct status codes on every one of them so they are removed from the index rather than left as soft 404s
  • Sitemap rebuilt and resubmitted, robots.txt verified
  • URL inspection and re-indexing requests on your real pages, prioritised by revenue value
  • Security issues report in Search Console cleared and a review requested, plus a reconsideration request if a manual action landed
  • Blacklist delisting with Google Safe Browsing and the other major vendors
  • Ranking and impression monitoring until you are back to your pre-incident baseline

We do this because we have had to do it for ourselves. Which brings us to the next question.

13. Have you ever been hacked?

Yes. In July 2026, our own site, elrqweb.com, was hit with a cloaking attack.

The entry point was a known CMS vulnerability, and what the attacker did next was clever. Rather than dropping obvious malware files, they injected a malicious nginx server configuration. That is a nasty place to hide, because the CMS admin panel shows nothing wrong, standard malware scanners do not read your web server config, and the site serves clean content to every normal visitor while feeding spam to search crawlers.

We found it, traced the entry vector, removed the injected configuration, closed the vulnerability, rotated everything, and then ran the full SEO recovery process above.

We are telling you this for two reasons. First, it is honest, and any agency claiming they have never had an incident is either new or lying. Second, it is the reason our process looks the way it does. The cloaking test, the nginx config review, and the Search Console monitoring in our audit checklist are all there because we learned what happens when they are missing.

You want a security partner who has actually cleaned up an incident, not one who has only read about them.


Part 4: Building It Right, and What It Costs

14. What do you do differently when you build a site from scratch?

Most of the risk above is inherited from the architecture, not added later. So we design it out.

We do not build brochure and marketing sites on plugin-heavy CMS stacks. Our default is SvelteKit with a headless content layer, deployed as mostly static output. There is no PHP execution surface, no plugin ecosystem, no database sitting behind a public login form. The class of vulnerability that accounts for 91% of WordPress problems simply does not exist in that architecture.

Everything dynamic is server side and explicit. Forms, carts, and API routes are code we wrote and can read, with input validation using schema validation, rate limiting, and CSRF protection as standard rather than as a plugin someone might deactivate.

Secrets never reach the browser. API keys, credentials, and system prompts live server side only.

Docker deployments with minimal images, so what runs in production is a small, known, reproducible thing rather than a server that accumulated software over three years.

Dependencies are pinned, audited, and few. Every package is a supply chain risk, as the Essential Plugin story demonstrated.

If you genuinely need WordPress, for example because your team lives in that editor, we will build it and harden it properly rather than talking you out of it. But you should make that choice knowing the risk profile you are accepting.

15. Does hardening make my site slower?

No. In most cases it makes it faster, because the biggest single hardening measure is removing unnecessary plugins and third-party scripts, which is also the biggest single performance measure.

Security headers cost nothing measurable. A properly configured firewall at the edge adds a few milliseconds. Our target is that PageSpeed scores go up after a hardening engagement, not down, and that is usually what happens.

16. What does this cost, and how do I justify it?

Three ways to work with us:

One-off audit. Fixed price, fixed scope, a report you own. Best if you want to know where you stand before committing to anything. Most clients start here.

Audit plus remediation. We find it and we fix it, quoted after the audit so you are not paying for unknown work.

Ongoing security retainer. Monitoring, patching, virtual patching, monthly reporting, and incident response with a committed response time. Priced monthly.

On justification, the arithmetic is not subtle. Recovery for a small business site averages around $14,500 and a serious breach starts at $120,000. Prevention costs somewhere between 50 and 60 times less than recovery. Add that 63% of small businesses saw cyber insurance premiums rise by 200% or more, and 27% could not get coverage at any price because their security controls were inadequate. If you carry cyber insurance, an audit report is increasingly what keeps it affordable.

17. What about AI chatbots and the newer attack surfaces?

Real and growing, and most agencies bolting AI onto client sites are not thinking about it.

Research accepted to IEEE Symposium on Security and Privacy 2026 studied 17 third-party chatbot plugins running on more than 10,000 websites. Eight of them, on around 8,000 sites, did not verify the integrity of conversation history, letting an attacker forge fake system messages and push the bot into unintended behaviour with three to eight times the success rate. Fifteen scraped website content without separating your trusted product data from untrusted third-party content like customer reviews, opening the door to indirect prompt injection. About 13% of e-commerce sites in that study had already exposed themselves this way without knowing.

We cover this in detail in our chatbot article, but the short version is that if you are adding AI to your site, the prompt stays server side, conversation state stays server side, trusted and untrusted content are fenced separately, output is sanitised before rendering, and any tool the bot can call runs on least privilege. If your current AI vendor cannot explain how they handle those five things, that is your answer.

18. What can I do myself today, for free?

Genuinely useful, no charge, no us required:

  1. Turn on multi-factor authentication for your CMS admin, your hosting panel, your domain registrar, and the email account those recover to. The registrar and email matter most, because whoever controls those controls everything else.
  2. Delete every plugin and theme you are not using. Deactivated is not enough. Deleted. Inactive plugins are still exploitable.
  3. Verify your site in Google Search Console if you have not, and check the Security Issues and Pages reports. This is the cheapest early warning system that exists.
  4. Search Google for site:yourdomain.com and page through the results. If pages appear that you did not create, in languages you do not publish in, you are already compromised.
  5. Audit your user accounts. Remove the ex-employee, the old developer, and the agency you stopped working with in 2023. Nobody who does not need admin should have admin.
  6. Confirm your backups exist and restore one. If you cannot restore it, you do not have backups.

That list closes a real percentage of the risk, and we would rather you did it than not.

19. How do I know you are any good?

Fair question, and the industry deserves the scepticism. Security is easy to claim and hard for a buyer to verify.

What we offer instead of claims: we will do a free initial surface scan of your site and show you findings before you pay us anything. Not a generic PDF with your logo on it, actual specific issues on your actual site. If we find nothing meaningful, we will tell you that and you can stop there.

If we find things, you will already know exactly how we work before you decide whether to hire us.


Where to Start

Two options, both low commitment.

If you just want to know whether something is already wrong, run the six free checks above. It takes an hour and it catches the most common problems.

If you want a real answer, ask us for the free initial scan. We will look at your site, tell you what we see, and give you a straight assessment of whether you need us. Sometimes the answer is that you do not, and we will say so.

The one thing we would ask you not to do is assume that being small is protection. The scanners hitting your site right now do not know how big you are.

ELRQ Agency builds and secures web platforms for businesses that need the thing to actually work. Security audits, hardening, incident response, and SEO recovery. Get in touch at elrq.agency.