Bots, Spam and DDoS: Protecting a Small Site
By CodexierPublished 5 min read
Every public website is visited by bots around the clock. Some are useful, like search engines. Many are not: they fill contact forms with spam, create fake accounts, try passwords on the login page, scrape prices or send so many requests that the site slows down. A small business does not need an enterprise security budget to handle this, but it does need the right layers in the right order. This guide explains what bad bots do and what protection is proportionate.
What bad bots do
- Credential stuffing: trying leaked email and password pairs on your login page.
- Vulnerability scanning: probing for old plugins, exposed admin pages and backup files.
- Form spam: filling contact and quote forms with ads, links and phishing.
- Fake sign-ups: creating accounts to abuse free trials, discounts or referral schemes.
- Scraping: copying content, prices or product data, sometimes at a rate that slows the site.
- Card testing: using a webshop checkout to test stolen card numbers with small purchases.
Form spam and fake sign-ups
Form spam is the bot problem small businesses notice first, because it lands in the inbox. Layer the defences so that each catches what the previous one missed, and keep the form easy for real people. A form that frustrates humans loses more enquiries than spam ever cost.
| Layer | Stops | Cost to real users |
|---|---|---|
| Honeypot field hidden from humans | Simple bots that fill every field | None |
| Invisible challenge, such as Cloudflare Turnstile | Most automated submissions | Usually none |
| Server-side validation and rate limits | Repeated submissions from one source | None |
| Email confirmation for sign-ups | Fake accounts with invented addresses | One extra step |
| Visible puzzle captcha | Determined bots | Friction, and accessibility problems |
Some challenge services set cookies or send visitor data to third countries. Check how the one you choose fits your cookie and GDPR set-up before adding it.
Overload attacks explained
A distributed denial-of-service attack sends more requests than your server can answer, from many machines at once, so real visitors get errors or nothing at all. Small sites are rarely targeted on purpose, but they are hit as collateral, by extortion attempts against a whole sector, or simply by an aggressive scraper. A single web server cannot defend itself against this, because the traffic fills the connection before any software on the server can react. The defence has to sit in front of the server, in a network big enough to absorb the traffic.
CDN and web application firewall
A content delivery network places copies of your site on servers worldwide and answers visitors from the nearest one. Traffic reaches your own server only when needed. Most CDNs include protection against overload attacks and a web application firewall, a set of rules that blocks known attack patterns, bad bots and suspicious countries or networks before they reach the site. For a small business this is the single most effective layer, often available on free or low-cost plans, and it also makes the site faster.
Turn on
Managed firewall rules, bot fight or bot management features, rate limiting on login and form URLs.
Lock down
The origin server, so it only accepts traffic from the CDN, and the admin path, by country or IP where possible.
Allow
Search engines, your uptime monitor, payment providers' callbacks and any integrations that call your site.
What a small site really needs
- A CDN with firewall in front of the site, with the origin locked down.
- Form protection with a honeypot and an invisible challenge, plus server-side checks.
- Login limits and two-factor authentication for every administrator.
- Updates applied monthly at minimum, security updates immediately.
- Uptime monitoring with alerts to more than one person.
- For webshops: fraud screening in the payment provider, to stop card testing.
When you do not need more: a brochure site on a managed platform such as Webflow or a hosted Shopify store already sits behind a CDN; add form protection and two-factor authentication and you are mostly done. When you run WordPress on your own hosting, have logins for customers or have seen spam or slowdowns, our performance and security optimisation sets up these layers and checks they work. Read the WordPress security checklist, see the pricing page, or book a call.
Frequently asked questions
Is Google reCAPTCHA a problem under GDPR?
It can be, because it sends visitor data to Google and may set cookies, which needs a legal basis and often consent. Many Swedish sites choose privacy-focused alternatives or combine a honeypot with server-side checks. Document whichever choice you make.
Will a CDN block Google from indexing our site?
No, if it is configured correctly. Major CDNs recognise verified search engine bots and let them through. Check Google Search Console after setting up the firewall to confirm crawling continues normally.
We get spam even with a captcha. What next?
Some spam is sent by people, not bots, and no captcha stops that. Add server-side filtering on content such as links and known spam phrases, rate limits per sender and a rule that routes suspected spam to a separate folder instead of deleting it.
Should we block whole countries?
For the admin login, often yes, if nobody logs in from abroad. For the public site, blocking countries can shut out real customers and travelling staff, so use it only when attack traffic clearly comes from regions you do not serve.
Check what reaches your site
Book a short call and tell us what you are seeing: spam, slowdowns or strange sign-ups. We tell you which layer is missing and what it takes to put it in place.
Book a free 15-minute call