What Is a DDoS Attack? How to Protect Your Business Website

Picture a restaurant with hundreds of people standing in the doorway and blocking the entrance. Others walk in, keep every waiter busy with questions and never order anything. The kitchen is ready and the food is good, but a real customer can't get to a table. A DDoS attack does exactly that to your website.

Nobody has to break into your site to take it down. It is enough to flood it with more requests than it can answer. While that happens, customers see an error message, forms don't go through, your campaigns keep charging you for clicks to a page that won't load, and the business loses enquiries without knowing why.

In this guide we explain:

• what a DDoS attack is and how it is put together;
• why small businesses need to take it seriously too;
• which types of attack exist and how they differ;
• how to tell an attack from an ordinary traffic surge;
• which layers of protection really work on Webflow, WordPress and Wix;
• what to do at the moment your site goes down.

What is a DDoS attack and how does it work?

DDoS stands for Distributed Denial of Service. The attacker's goal is to stop legitimate users from reaching a website, server or network. To do that, they send the target more traffic than it can process, from a huge number of devices at the same time. The result can be a very slow site, a site that responds to only some visitors, or a complete outage.

The key word is "distributed". In a plain DoS attack the traffic comes from a single source, so blocking one IP address is enough. In a DDoS attack it comes from thousands of addresses or more, usually spread across many countries, which makes blocking addresses by hand pointless.

What is a botnet?

The traffic is usually generated by a botnet: a network of devices that have been infected with malicious code and are controlled remotely. Once a device is infected, it waits for instructions. The attacker activates the network through command-and-control servers, and all the devices start hitting the same target together.

A botnet can include computers, phones, compromised servers and, above all, IoT devices: security cameras, home routers and smart gadgets. In most cases their owners have no idea. The reason is simple: many of these devices keep their default password and never receive software updates.

Why are these attacks so hard to stop?

Two things make defence difficult. The first is distribution: there is no single source you can cut off. The second is disguise: in sophisticated attacks every request looks like a normal browser request, and only the overall volume reveals that something is wrong. That is why modern protection systems analyse patterns of behaviour and not just addresses.

Who launches these attacks, and why small businesses should care

Attackers have different motives. Some are after money and send a message demanding payment to make the attack stop. Some are unscrupulous competitors trying to knock a rival offline at the peak of the season. Some are hacktivists with a political or ideological agenda. And some are simply bored teenagers and adults buying a cheap "stresser" service online, which has pushed the cost of entry close to zero.

Size is not much protection. Hacktivist groups and automated tools don't always choose their targets by how big they are, and a company can suffer without being the intended victim at all. If your website sits on a shared server next to another site that comes under attack, it can go down along with it.

It also helps to know what downtime really costs you. For a brochure site, an hour offline in the middle of the night is a minor event. For an online shop in Black Friday week, or a business running campaigns to a landing page, even one hour means real money. Work out how many enquiries or sales you get in a peak hour: that number is the basis for deciding how much to invest in protection.

There is a legal side as well. Deliberately disrupting a computer system is a criminal offence across the EU and in most other jurisdictions, so an attack like this is not a "prank". This is general information and not legal advice, but it is worth knowing that you are the victim of a crime and can report it.

The three main types of DDoS attack

Network communication is usually described using the OSI model, which splits it into seven layers. DDoS attacks tend to fall into three groups, and each one calls for a different defence.

Volumetric attacks on bandwidth

The aim here is simply to fill the pipe. The attacker generates more traffic than the target's connection can carry, and a fully saturated network can't deliver legitimate requests either. Common methods include UDP floods and amplification attacks, in which the attacker abuses open servers on the internet to multiply the volume of traffic. A single server is helpless against this kind of attack, because the problem occurs before the traffic even reaches it.

Protocol attacks

This group exploits the way communication protocols work. The classic example is the SYN flood. When a TCP connection opens, the two sides perform a three-step "handshake". The attacker opens a huge number of connections and never completes them. The server reserves resources for every half-open connection and eventually has no room left for new ones.

Application-layer attacks

This is the type most relevant to business websites. The attacker sends HTTP requests that look completely normal and picks the pages that make the server work hardest: site search, product filters, the shopping cart or the login page. The traffic volume can be fairly low and a WordPress site with a database can still collapse, because each of those requests triggers PHP and database queries.

Three attacks worth knowing about

In 2000 a 15-year-old from Canada, known as Mafiaboy, temporarily took down the websites of Yahoo, eBay, Amazon and CNN. The case brought the subject into public debate for the first time.

In October 2016 a botnet called Mirai, made up mainly of IoT devices, attacked the DNS provider Dyn. Sites such as Twitter, Netflix and Reddit became unreachable for some users even though they were not attacked directly. The lesson: DNS is a point of failure too.

In February 2018 GitHub was hit by an attack of 1.35 terabits per second, a world record at the time, and the service was back within minutes because traffic was rerouted through a protection provider. Attacks many times larger have been recorded since. The lesson: what saves you is preparation.

How to tell an attack from a normal traffic surge

Not every slow website is under attack. Sometimes the reason is a good one: a campaign took off, a video went viral or a seasonal sale has started. Sometimes a plugin update has gone wrong, or the problem lies with your hosting provider. Before you declare an attack, check the following signs.

Signs that point to an attack:

• a sharp jump in traffic with no campaign, press mention or event to explain it;
• many requests to the same URL, usually a heavy page such as search or login;
• large volumes of traffic from countries or networks unrelated to your audience;
• unnatural timing patterns: a perfectly even rate or waves at fixed intervals;
• recurring 502, 503 and 504 errors while the server itself shows a high load.

Signs of legitimate load look different. The traffic comes from familiar sources such as ads and social media, visitors move between pages, and GA4 shows events and purchases. Bots usually don't trigger GA4, so a wide gap between your server logs and your analytics data is an important clue.

The layers of protection that really work

No single tool solves everything. Good protection is built in layers, and the central principle is to stop malicious traffic as far away from your server as possible.

CDN and edge network

A CDN distributes your website across servers around the world, so it can absorb a volume of traffic no single server could handle. Providers such as Cloudflare, Akamai and Fastly filter traffic at the edge, before it gets to you. As a bonus, your site loads faster in normal times too. Cloudflare includes unmetered DDoS protection even on its free plan, which makes it a good starting point for most websites.

Web application firewall (WAF) and rate limiting

A WAF inspects the content of requests and blocks suspicious patterns. Rate limiting sets how many requests are allowed within a given time period, and it is one of the most effective settings against application-layer attacks. Start with your sensitive pages: login, search, forms and payment.

For forms and login pages you can also add a challenge that real users barely notice, such as Cloudflare Turnstile. If you use a CAPTCHA, make sure it is accessible and meets WCAG, because a challenge some customers can't solve costs you those customers.

Hiding your server's IP address

This is a mistake we see again and again. If an attacker knows your server's origin IP address, they simply bypass the CDN and attack it directly. So configure the server to accept traffic only from your provider's addresses, check that the IP isn't exposed through old DNS records or a mail subdomain, and if necessary change it after connecting the CDN.

Caching, capacity and backups

The more pages are served from cache, the less work your server does, and the more easily it will ride out a medium-sized attack. That makes speed optimisation a form of protection as well. On top of that, make sure you have recent, working backups and can scale up capacity quickly.

Tools by business size

• Brochure sites and small businesses: Cloudflare or your platform's built-in protection is usually enough.
• Shops and cloud applications: AWS Shield (the Standard tier is included with AWS at no extra cost) and Google Cloud Armor.
• Enterprises and critical websites: Akamai, Imperva or Radware, usually with a 24/7 response team.
• Monitoring: UptimeRobot or Better Stack so you hear about an outage before your customers do, and Netdata or Grafana for server metrics.

Common protection mistakes

• Blanket blocking of foreign traffic. It looks like an easy fix, but it also blocks Googlebot, Meta's crawlers, payment providers and your own customers when they travel. If you block by country, set precise exceptions.
• Relying on a plugin alone. A plugin runs on the same server that is under attack. It can block bots, but it can't absorb a flood.
• Load testing a site without telling anyone. Your hosting provider may treat it as an attack and block you.
• Nobody holds the keys. When your site goes down on a Saturday morning, you need to know who can get into DNS and the CDN and where the access details are kept.

What changes on Webflow, WordPress and Wix

Webflow and Wix: most of the responsibility sits with the provider

On managed platforms, hosting, the CDN and network-level protection are in the provider's hands. You don't run a server, so you don't need to hide an IP address either. What remains your responsibility is account access with two-factor authentication, third-party scripts, and forms that pass data to other systems. Before you put an external proxy in front of a Webflow site, check the official documentation to see what is supported, because the wrong setup can break your SSL certificate.

There is also a weak point that is easy to forget. If a form on your site sends data to an external service or a webhook, an attacker can fire hundreds of thousands of submissions at it, flood your CRM or burn through your automation quota. Add bot protection and filter submissions on the receiving side.

WordPress: much more is in your hands

A WordPress site depends on the hosting you have chosen and on your own configuration. At a minimum, you should:

• connect the site to a CDN and make sure the server accepts traffic only from it;
• enable page caching so that not every visit runs PHP;
• limit login attempts on wp-login.php and turn off xmlrpc.php if you don't need it;
• keep core, theme and plugins up to date, and remove plugins you don't use;
• use a plugin such as Wordfence or Solid Security to block bots and scans;
• choose hosting that provides network-level DDoS protection rather than overcrowded shared hosting.

What to do when your website is under attack

When it happens, time is short and pressure is high, so it is best to write the plan in advance. These are the steps in the right order:

• Confirm it is an attack. Check your logs, the CDN dashboard and your provider's status page.
• Contact your hosting or CDN provider. They can often see the attack and filter it faster than you can.
• Turn on protection mode. On Cloudflare this is Under Attack mode, and other providers have a similar setting.
• Harden the pages being targeted. Apply rate limits, add a challenge to heavy pages and temporarily switch off search or filtering.
• Pause your campaigns. There is no point paying for clicks to a page that won't load.
• Keep customers informed. Post a short message on social media or WhatsApp Business with a phone number for urgent requests.
• Report and document. You can report the incident to your national computer security incident response team (CSIRT) and file a complaint with the police. Don't delete any logs.
• Check for a breach once things calm down. An attack is sometimes a smokescreen for something else. If you suspect personal data has been exposed, get legal advice straight away about your duties under GDPR, because the notification window is short. This is not legal advice.

Received a payment demand? Don't pay, and don't reply before taking advice. Paying doesn't guarantee the attack will stop, and it marks you as a target worth coming back to.

From an SEO perspective, a short outage usually leaves no lasting damage. If errors go on for a long time, Google may slow down crawling and eventually drop pages from its index. For a temporary outage the correct response is a 503 status code, as explained in Google's documentation, and not a 200 page with an error message. To read about other risks, see our guide to information security threats.

How RJL Studio helps you prepare your website

We build, connect and maintain websites on Webflow, WordPress and Wix, and we make protection part of the infrastructure instead of an afterthought. Along the way we connect a CDN, configure a WAF and rate limiting, hide the origin server address, protect forms and CRM integrations, set up monitoring and backups, and write you a short action plan that says who to call and what to do.

We are not a cybersecurity company and we don't replace one: for critical websites we will recommend bringing in a dedicated protection provider. For most business websites, the right layers and orderly maintenance already change the picture. Would you like us to check your site? Talk to us, and we will tell you honestly what is missing and what you don't need.

Frequently asked questions

Does a DDoS attack steal data?

Not by itself. Its aim is to take a service down, not to break into it. That said, it is sometimes used as a distraction from another operation, so after the incident it is worth checking your logs, new user accounts and files that have changed.

Is Cloudflare's free plan enough?

For most brochure sites and small businesses it is a good starting point, because it includes unmetered DDoS protection. Shops, sites with many dynamic pages and businesses that depend entirely on their website will benefit from advanced WAF rules and paid support.

Will an attack hurt my Google rankings?

An outage of a few hours usually has no long-term effect. Downtime lasting days, or a site that returns errors over and over, can lead to slower crawling and fewer pages in the index. Once you are back online, check the page indexing report in Google Search Console.

Can a small website really be a target?

Yes. Hacktivist groups and automated bots don't filter by size, and a site on a shared server can be hit by an attack on a neighbour. The basic steps aren't expensive, so it pays to take them before anything happens.

Can DDoS attacks be prevented completely?

You can't stop anyone from trying to attack you. What you can do is make sure the attack doesn't affect your customers: filter the traffic before it reaches your server, reduce the load each request creates, and know in advance what to do if something still gets through.