Kafe Spesial is a café and restaurant in Bergen, Norway, open since 2004. In May 2026 its website started showing server errors to guests. There was no warning, no ransom note and no defaced home page. Just a site that kept failing.
When we looked closer, we found that the site had been hacked about three weeks earlier. Attackers had filled it with more than 69,000 fake pages, and Google had already indexed them. This is how we found the problem, cleaned it up in three days and made sure it can’t happen the same way again.
At a glance
- Client: Kafe Spesial, café and restaurant in Bergen, Norway
- Platform: WordPress with Elementor on shared hosting
- Problem: hacked site, 69,000+ spam pages, 16 backdoor files and a bot attack that took the site down
- Cleanup: 17 to 19 May 2026
- Result: clean security scans, attacks blocked before they reach WordPress, and a new website built on a clean install
The first sign: errors, not a warning
Guests trying to open the site were getting 503 and 507 errors. The server’s error log was full of failed PHP processes: the hosting account was hitting its resource limits again and again.
The cause was a network of bots sending hundreds of requests a minute to URLs that looked like product searches. Every one of those requests started WordPress, and WordPress used up the account’s resources. We counted more than 79,000 malicious requests in seven days of logs. The oldest log available went back to 11 May, but the infection itself started around 28 April.
What we found inside the site
- 69,000+ fake pages in the database. Online casino pages and fake shops for clothes, shoes and electronics, in several languages. Together with the bot URLs they produced close to 1.7 million spam addresses on the restaurant’s domain.
- Google had indexed them. Search Console showed 69,687 indexed pages. A restaurant site normally has a few dozen.
- 16 backdoor files hidden among WordPress core files, with names chosen to look like they belong there.
- A line in wp-config.php that let the attackers run any code they sent to the server. Deleting the visible spam without finding this would have meant reinfection within days.
- The attackers had taken over the site’s relationship with Google. They verified their own Google Search Console access to the domain, submitted a fake sitemap listing their spam pages, and changed robots.txt to point search engines to it.
- Constant login attempts, including attempts with the credentials of a former developer’s account.
What we did in three days
- Stopped the traffic at the server. We blocked the attacking networks and the spam URL pattern before a request ever reaches WordPress, so the bots cost the site nothing.
- Removed the spam pages and every unauthorised user from the database.
- Removed all 16 backdoor files and cleaned wp-config.php by hand.
- Took back the Google side. We deleted the attackers’ verification file and fake sitemap, restored robots.txt, verified the site in a new Search Console property, submitted a clean sitemap and filed removal requests for the spam URL patterns.
- Changed every password and access key and removed the default admin account.
- Added protection: a firewall with rate limiting and brute-force protection, a login page moved to a private address, and a nightly malware scan.
- Checked our work. Two full scans in a row came back clean (9,682 files). The next day’s error log showed no resource errors and no spam requests getting through.
Then we rebuilt the site
A cleaned site is a site you have to trust was cleaned completely. For a restaurant that depends on its website for bookings and orders, we didn’t want to rely on that. So we built a new website from the ground up: a new design for a 20-year-old Bergen favourite, in English and Norwegian, with the menu, table reservations and direct links to pickup ordering, Wolt and Foodora, running on a clean, protected install.
Where it stands now
The site has been running without problems since. Security scans are clean. The bots haven’t given up and still try every day, but they get blocked before they reach WordPress, so guests never notice. The spam pages keep dropping out of Google as it rechecks them and finds them gone; with tens of thousands of URLs, that takes weeks, not days.
What any restaurant owner can take from this
- A hack rarely announces itself. It shows up as slow pages, odd errors or a sudden drop in bookings from the site.
- Search your own domain. Type site:yourdomain.com into Google once a month. If you see pages you never created, act the same day.
- Close old accounts when you change developers or staff. Old logins are one of the first things bots try.
- Monitoring costs less than cleanup. A nightly scan and someone who reads the logs would have caught this in days, not weeks.
We wrote more about the warning signs and the usual ways attackers get in here: What We Found When a Client’s WordPress Site Got Hacked.
Not sure what’s happening on your site?
We’ll check your site’s speed, security basics and what Google has indexed on your domain, and tell you plainly what needs fixing.
It’s much easier to close the door before someone walks in.
