This is part 3 of our series on keeping your website safe, and like the last two, this one is built from problems we've actually run into and fixed, not a generic checklist copied from somewhere else. If you missed the earlier posts, go check those out first. This time we're covering three more issues: DNS hijacking, rate limiting, and bot traffic eating your resources. None of this overlaps with what we've already covered, and there's more coming in parts 4 and 5.
What Is DNS Hijacking and Why Should You Care
DNS is the system that translates your domain name into the actual server address that hosts your site. Think of it as the phone book for the internet. When someone types in your web address, DNS is what tells their browser where to actually go find your site.
The problem is that DNS records live with your domain registrar or DNS provider, not on your website itself. That means someone can compromise your domain account, change the DNS records, and quietly redirect your visitors somewhere else entirely, without ever touching your actual website server. Your site still runs fine. Your visitors just don't end up there.
We've seen this happen through weak registrar passwords, accounts with no two-factor authentication, and DNS providers that don't lock down who can make changes. The fix isn't complicated, but it gets skipped constantly:
- Lock two-factor authentication on your domain registrar account, not just your website login
- Use a registrar lock so your domain can't be transferred without extra verification
- Set up DNS change alerts so you get notified the moment a record gets edited
- Use a reputable DNS provider that supports DNSSEC, which verifies that DNS responses haven't been tampered with
Most business owners lock down their website login and completely forget the domain and DNS layer even exists. It's a different door into the same house, and it's usually the one left unlocked.
How Rate Limiting Stops Brute-Force Attacks
Here's a problem we see constantly: bots hammering your login page, trying username and password combinations thousands of times an hour. Most of the time this isn't a targeted attack on you specifically. It's automated software crawling the web, hitting every login form it can find, hoping something sticks.
Without protection, this does two things. First, it slows your site down because your server is busy processing thousands of fake login attempts. Second, if your passwords are weak, eventually one of those attempts works.
Rate limiting is the fix, and it's simpler than it sounds. It's a rule that says: if an IP address tries to log in more than a set number of times in a set window (say, 5 attempts in 10 minutes), block that IP for a while or force a delay before the next attempt.
Most hosting platforms and security plugins let you turn this on with a setting, not custom code. We've put this in place on client sites and watched failed login attempts drop from thousands a week to basically nothing, because the bots move on to easier targets once they hit the wall. It's one of the highest-impact, lowest-effort fixes we recommend, and it's the kind of thing that should be on by default but often isn't.
Why Bot Traffic Is Quietly Costing You Money
Not all bad traffic is trying to break in. A lot of it is bots scraping your content, checking for vulnerabilities, or just hammering your server with requests that have nothing to do with real customers. This traffic doesn't always show up as an attack, it just shows up as your site being slower than it should be, or your hosting bill being higher than it should be, because you're paying for server resources spent serving bots instead of people.
We've looked at traffic logs on client sites and found that a huge chunk of total requests, sometimes the majority, were coming from bots that had no business being there. Not Google, not legitimate services, just noise.
The fix here is a mix of a few things working together:
- A web application firewall (WAF) that filters traffic before it hits your server, blocking known bad bots and suspicious patterns
- Robots.txt and proper bot management to tell legitimate crawlers what they can and can't access
- CAPTCHA or similar challenges on forms and login pages, specifically placed where bots cause the most damage, not everywhere, since overusing them hurts real user experience
The goal isn't to block every bot on earth. It's to stop the ones causing real damage, whether that's server load, scraping your content, or probing for weaknesses, while staying invisible to actual customers.
What These Three Problems Have in Common
DNS hijacking, brute-force login attempts, and bot traffic all share something: none of them are the flashy hacking-movie scenario people picture when they think about website security. They're quiet, and they work precisely because most business owners never look at that layer of their site. Nobody's watching their DNS records. Nobody's checking login attempt logs. Nobody's reading traffic reports closely enough to notice the bot noise.
That's exactly why these are worth fixing now instead of after something goes wrong. Every one of these is a setting you can turn on or a small piece of infrastructure you can put in place, not a total rebuild.
We'll keep pulling from real fixes we've done for parts 4 and 5. If you want to know where your own site stands on any of this, DNS, login security, bot traffic, or something else entirely, reach out to Level Up AI and we'll walk through it with you.