DDoS and Bad Bot Traffic Protection: A Plain Guide
How a DDoS attack and bad bot traffic slow a website down, which layers protect against them, and how much protection each kind of business needs.
rabbitclip teamPublished: 7 min read
Short answer
A DDoS attack sends an overwhelming number of requests to a site from many sources at once, so that the server can no longer answer; the aim is not to steal data but to shut real visitors out. Bad bot traffic is quieter: automated software copies content, fills in forms, tries login pages or simply uses up server resources. Protection rests not on one product but on layers that filter requests before they reach the server: a filter at the network edge, a web application firewall, rate limits and the server's own settings.
The practical question for an owner is usually this: my site has slowed down or will not load, is that an attack or a genuine crowd? The answer lies in where the traffic comes from and how it behaves. A rush after a campaign is scattered but behaves like people; an attack typically hits the same page, in the same way, at an unusual speed.
This article separates the two threats, lists the protection layers and explains why not every business needs the same measures.
What is the difference between DDoS and bad bot traffic?
DDoS is loud and works fast. More requests arrive than the server or its network connection can carry, and the site slows down or fails to open at all. The attack is usually spread across many machines, which is why blocking a single address does not help.
Bad bot traffic is steady and low in volume. One bot scans your price list, another floods the comment form with links, a third guesses passwords on the admin login. None of them brings the site down in an instant, but together they wear away server resources, advertising budget (through fake clicks) and the reliability of your statistics. The two threats are met with different tools.
How can you tell a site is under attack?
The first sign is a slowdown that does not match the number of visitors. If the site is slow when there is no sale or advertising push, and the server's resource graphs are hitting the ceiling, suspicion is justified. The second sign is unusually frequent requests in the server records, from the same address range or to the same page; traffic that peaks at odd hours is also a clue.
For a firm diagnosis you need to read the server records, which we have described in plain language elsewhere. Typical signs include the following.
- Sudden traffic and slowness with no campaign or announcement
- Requests piling up on one page or on the login address
- Heavy traffic from countries your real customers do not come from
- Meaningless or repeated entries arriving through forms
- Resource-limit warnings from your hosting provider
Which layers does protection use?
The first layer is the network edge. Putting a protection and delivery service in front of the site absorbs most attack traffic before it reaches your server. If the real address of the main server stays hidden, an attacker cannot aim at it directly. The everyday speed benefits of this approach are the subject of a separate article.
The second layer sits at application level. A web application firewall (WAF) cuts off known bad patterns and suspicious requests, while a rate limit restricts how many requests one address may make in a given time. The third layer is the site itself: limiting login attempts, adding an invisible check to forms and caching heavy pages make the server more resilient to the same attack.
Each layer is incomplete alone. A network filter does not fix an application flaw, and a WAF does not stop a network flood; working together they spread the risk.
Which business needs which measures?
Choose measures according to the site's real risk. For a small brochure site, basic protection at the network edge, up-to-date software and a limit on login attempts are usually enough. If being offline costs you no direct income, an expensive and complicated set-up is out of proportion.
Shops, booking systems and sites that take payment are different: every hour offline is lost sales and lost trust. For these, a WAF, rate limits, bad bot management and a contact plan for the moment of an attack should be considered together. Testing load and resilience before a campaign period also makes sense.
When is buying protection the wrong choice?
There are cases where buying protection is not the answer. If the problem is not an attack but weak hosting (a site hitting the resource limit on a shared server, say), a protection service will not solve it; the real fix is larger infrastructure or a lighter site. First diagnose whether the traffic really is an attack.
Likewise, relying on a block list and saying 'we have shut out all the bots' is a mistake. Search engine crawlers and payment or monitoring services are bots too, and blocking all of them can remove your site from search results. The aim is not to destroy bots but to tell the bad from the good.
What mistakes are common?
The most common mistake is looking for protection after the attack has started. Changing DNS and setting up a new service in the middle of an incident takes time and adds the risk of fresh errors. Putting simple edge protection in place beforehand takes far less work than doing it in a crisis.
Another mistake is leaving the real address of the main server exposed; even with a protection service in place, an attacker can find the address through another record and strike directly. Frequent mistakes include these.
- Setting up protection but leaving the real server address or old records exposed
- Putting no attempt limit or second verification on the login page
- Assuming the robots file will stop bad bots; it only speaks to bots that choose to obey
- Not deciding in advance who does what during an attack
- Not updating software and plugins; attacks often use a known flaw
What do you do during an attack?
First stay calm and work out what is affected: the whole site, a single page, only the login? Then contact your hosting provider and any protection service; many providers can add measures to filter traffic during an attack. Having that conversation beforehand rather than in the crisis makes a great difference.
After the attack, review the records: which page was the target, which weakness was used, which measure worked. That knowledge shapes the next set-up. For a quick look at your site's general security, you can use our security and SSL check tool.
Protection against DDoS and bad bot traffic is not one tool but layers set up at the network edge, the application and the site; how much you need depends on what being offline would cost. A small brochure site is well served by basic protection, while a site that earns money needs a layered and planned arrangement. If you would like to assess your site's real risk together, rabbitclip would be glad to arrange a calm discovery conversation.
FAQ
Does a DDoS attack steal data?
Usually not; its aim is to make the site unreachable. An attack is sometimes used as a distraction, though, so it is worth checking for any other weakness during and after an incident.
Why would a small site be attacked?
Attackers often do not pick a particular site; automated software scans for open and vulnerable ones. Every site therefore needs up-to-date software and a basic layer of protection.
Is it right to block all bots?
No. Search engine crawlers and some monitoring services are bots too, and blocking them harms the site's visibility in search. The goal is to separate malicious bots from well-behaved ones.
Does my hosting provider not protect me already?
Some providers offer basic network-level protection, but the scope differs. The safest course is to ask your provider in writing which types of attack it covers and up to what size.
Will a rate limit block real customers?
Not if the threshold is sensible. It is set above a genuine visitor's normal use but below attack speed, and adjusted in the first few weeks by watching the records.
