Where the blows came from when I published my website

I published a website thinking nobody was going to notice it, and within a few hours it already had visitors that weren't people. Here I tell you what hit it from day one, what I did to stop it without being a security expert, and what I'd do today if I were starting over.

I had the same idea almost everyone has: nobody cares about a small website. Who's going to waste time attacking a page that gets a handful of visitors? Well, it turns out plenty do, and none of them are people.

The website is the one I described in I built a website with the help of AI: this very one, the AI Real Cases blog, with a homepage, a list of articles, an "About the project" page and a contact form, built with Claude Code and hosted on one of my six VPSs, with a simple web server in front. I published it on 3 March 2026 with the pride of someone who's just hung a crooked picture in the living room.

What I didn't know then, and it's the first thing I want anyone reading this to take away: the attacks aren't personal. Nobody chose me. There are robots that crawl the internet nonstop testing known flaws on every website they find, and mine was simply one more door on a very long street.

I found out almost by chance. The day after publishing I went to look at the server logs, which are the diary where the server notes down every request it receives, just to see if anyone had visited. There were hundreds of lines. I was expecting five.

I didn't understand half of it, so I did what I do with almost everything lately: I gave it to Claude. I copied a chunk of the log, first removing my IP address and any data that could identify a visitor, and asked it to explain line by line what each request was and which ones looked suspicious. It grouped them into three piles: search engines, curious visitors and people looking for open doors. Then I checked some of its conclusions by hand, because the assistant makes mistakes too, and it makes them in the same calm tone whether it's right or not.

The timeline went roughly like this:

In volume, in the first week I counted around 4,000 requests, of which less than 20% looked like real people. Mind you, requests, not visitors: one person opening a page generates several. To tell them apart I didn't trust the user agent, the label each visitor uses to say which browser it is, because any bot can put whatever it likes there. I grouped by address and looked at behaviour: whoever loads the page with its styles and images and moves from one page to another at a human pace, person; whoever asks for ten odd paths in a second, bot. And the ones claiming to be Google or Bing I checked by their address, which those search engines let you verify. It's an estimate, not an exact count. A snippet of the log, cleaned of sensitive data, so you can see I'm not exaggerating:

203.0.113.45 - - [04/Mar/2026:03:12:08] "GET /wp-login.php HTTP/1.1" 404
203.0.113.45 - - [04/Mar/2026:03:12:09] "GET /.env HTTP/1.1" 404
198.51.100.7 - - [04/Mar/2026:03:14:51] "GET /phpmyadmin/ HTTP/1.1" 404

My website has neither WordPress nor phpMyAdmin. They didn't care: they ask just in case.

A bot is any program that visits websites automatically. And here's the first surprise: not all of them are bad. Google's and Bing's are the ones that put you in search engines, and without them nobody finds you. Then there are the crawlers from AI companies, which read your content to train models or to answer questions. And finally there are the ones that come looking for flaws, which are the scary ones.

On my website all three types showed up: Google's and Bing's from day one, several AI company crawlers during the first week and a constant trickle of anonymous bots testing paths.

To protect a website from bots, many people think first of the robots.txt file. It's a text file where you tell bots what they can and can't visit. The problem is that it works like a "please" sign: the polite ones respect it and the malicious ones don't even read it.

And watch out for the opposite mistake. I was about to block everything except Google in robots.txt, and in testing a line slipped through that blocked Google too. I caught it in time. My advice: before blocking anything, look at the stats for a few days and find out who really visits you.

The contact form started receiving junk on the third day, and within a week about 30 messages a day were coming in. Things like "improve your website's ranking today", "exclusive offer for your company" or just a link with no explanation, sometimes in languages I can't identify.

Why? Because the form the machine built me worked perfectly and had no protection at all: I should have asked for it, and I didn't. When an assistant writes the website, it does what you ask. If you don't ask it to protect the form, it doesn't.

To stop contact form spam I put up a few simple barriers:

• Invisible captcha, which checks whether you're a person without making you hunt for traffic lights. I used Cloudflare Turnstile.
• Trap field, or honeypot: a hidden field a person never sees and robots fill in without thinking. If it comes back filled in, the message is discarded.
• Submission limit: no more than three messages per address in ten minutes.

With Cloudflare in front, the server sees Cloudflare's address and not the visitor's, so you have to read the real one from the header Cloudflare adds, and only when the request genuinely comes from Cloudflare; otherwise anyone can make it up. With IPv6 it's the other way round: one person can use many addresses, so the limit applies to the whole block and not to each individual address. And the form rejects submissions whose origin header isn't my own domain.

About the captcha, two things I checked afterwards. I made sure the form can be submitted using only the keyboard and with a screen reader, because a captcha that shuts out a blind person is worse than the spam. And Turnstile isn't the only option: there are others, such as hCaptcha or Friendly Captcha, and if you'd rather not depend on a third party, the honeypot field and the submission limit already stop a lot.

And a warning I apply to myself: don't open the links that arrive in those messages, however friendly they seem. One distracted click is all it takes for the problem to stop being your inbox.

This is what worried me most at first. The bots tried typical admin paths (wp-login, admin, phpmyadmin), looked for forgotten configuration files like .env, which is where passwords are sometimes stored, and, on the server, tried to get in through SSH, remote access to the machine, trying usernames and passwords in a loop: root, admin, test, ubuntu and the like.

The frequency: about 1,500 SSH login attempts a day and a couple of hundred requests to admin paths. None of them got anywhere: the server only accepts logins with a key, not a password, blocks for a while anyone who fails several times in a row, and the paths they were looking for don't exist.

It hasn't happened to me, but I did sit down to think about what I'd do if someone got in, and I'm writing it down because in that moment you don't think clearly. It's the plan for a hacked website:

1. Change every password: hosting, control panel, database, email, remote access.
2. Take the website offline or put it in maintenance mode if it's harming visitors.
3. Notify the hosting provider.
4. Restore a clean backup from before the attack, don't just delete what you can see, because whoever gets in usually leaves back doors to return.
5. Find out how they got in and close it, or it will happen again.
6. If the website held clients' personal data, check as soon as possible whether it has to be reported to the Spanish Data Protection Agency (AEPD). The GDPR (Article 33) gives you 72 hours from when you become aware of the breach, unless it's unlikely to pose a risk to people; if the risk is high, Article 34 also requires you to tell those affected. It's not something to leave until Monday. (I'm in Spain, so the legal references here are Spanish; elsewhere, check your own regulator.)

I'm telling it as a plan. I hope to keep telling it that way.

This is the practical list of website security measures I applied, with what they cost me in time:

The port change is the least of it: it cuts noise in the logs because many robots only try the usual port, but it protects nothing on its own. What protects you is logging in only with a key, keeping the system updated and blocking whoever keeps trying. And I'm not giving more detail on ports, paths or configurations because the website is still live.

About HTTPS, a clarification that took me a while to understand: the padlock in the browser only means the connection is encrypted. It doesn't make the website safe. It's like a sealed envelope: nobody reads the letter along the way, but the letter can still be a scam.

A web application firewall (WAF) is a service placed in front of the website that filters what comes in before it reaches your server. I used Cloudflare.

Finally, I asked Claude to review the website's code looking for security problems. It found the form's email service key written in plain sight inside the code and a form that didn't sanitise what it received. I fixed them. But careful: asking it for a review is fine; blindly trusting that it didn't miss anything else is not.

The figures changed quite a bit:

• Form spam: from about 30 a day to one or two a week.
• Login attempts reaching the server: from 1,500 a day to fewer than 100, because many get stopped at the firewall.

There were side effects, of course. An acquaintance wrote to tell me he couldn't submit the form from his office network: the submission limit was treating him as suspicious. I had to loosen it. I also got a couple of firewall alerts that turned out to be false alarms.

Now I review the logs and alerts once a week, ten minutes, and the updates and a test restore once a month.

If you published your first website tomorrow, this is what I'd tell you, in short:

1. Have a recent backup, stored off the server, and know how to restore it. Test it once.
2. Protect the form from the start. If an assistant builds it, ask for it explicitly.
3. Long passwords and two-step verification on everything that supports it.
4. Look at the logs in the first week, even if you don't understand them: ask the AI to explain them to you.

The rest gets added over time. What I've learnt is that website security isn't something you buy once and forget. It's a maintenance habit, like taking the car in for its inspection, but a lot more often. And none of those habits requires being an expert: they require remembering.