Updated 16 August 2025
Found that hard disk space occupied by sabhlokcity became 57% – on exploration (go to file manager and activate the “show inodes and space” option) it was this folder under wp-content>cache>sgo-cache>www.sabhlokcity.com-LONG NUMBER) that was causing the problem. Upon going to WordPress plugin speed optimizer> cache> manual cache purge, I found that the directory had been entirely deleted. In other words, one can either manually delete the director or use “manual cache purge”). This brought everything back under control. Therefore NEW STEPS:
STEP 1: WORPRESS DASHBOARD
1) Go to speed optimizer plugin in WordPress dashboard and manually purge the cache.
STEP 2) SITE TOOLS
1A) Site Tools > Speed > Caching > Dynamic Cache, and click the “Flush Cache” icon
1B) ATTACK MODE: Site Tools > speed > CDN and make operational the “under attack mode”
2) Site tools >Site> file manager > public_html > Remove php_errorlog folder
3) BLOCK COUNTRY: Site Tools > statistics > traffic > audience. View the traffic by country. Typically the DDS attacks originate in some random country. Go to settings> security> blocked traffic and block that country
4) Go to site tools> File manager and click on the icon (second from the right) which shows inodes in each folder. Keep drilling down till you arrive at the root cause of the inodes. Typically it is a bloated cache file. Delete that file.
====THIS SHOULD FIX IT===
iF NOT, analyse the access logs (site tools > statistics> access log> — there is no recipe to analyse
On 7 April, after removing php_error log folder, I got the following result. This shows that if everything is done well, the site CAN be managed within the current plan.
ADDITIONAL SECURITY MEASURES
- Using security optimizer plugin, set up two factor authentication + custom login URL.
APRIL 2024
26 April 2024: Informed by Siteground that my websites had reached 80% of the CPU seconds limit. The traffic surge suddenly started on 25th April. Most traffic was to the home page sabhlokcity.com, a denial of service attack.
Websites did not shut down in April since it was towads the end of the month, but we started looking at the issue.
MAY 2024
Early May: Introduced a few referrer based rules in .htaccess to block certain HTTP referrers, in response to the April issue.
But on 3 May 2024, informed that websites have reached 80% of the CPU seconds limit. The changes made had caused page views and bandwidth usage to go down significantly, but not enough for May 2024.
8 May 2024: We were informed that “Your hosting plan is now limited. 100% of your monthly CPU has been used”.
Websites were then shut down for the entire month of May. We had no choice but to wait to see what happens in June 2024.
JUNE 2024
We thought that changes made in May 2024 might help in June, but no, on 3 June the 80% usage message was again received.
Two steps taken urgently:
a) Identified that 99.7% traffic is coming from Android OS. Blocked all requests from Android OS via a mod_rewrite rule in the site root .htaccess.
b) On 4 June 2024 moved to premium (paid) CDN on Siteground.
This helped but by 16 June things flared up again.
On 19 June I raised my first ticket with Siteground and noted: “I paid for Siteground premium CDN but looks like it stopped working from 16 June.” I asked Siteground to also extend the CPU limit.
In their response, they provided technical advice that includes a key point : “while the CDN service aims to improve page load times, reduce overall data transfer amounts between the CDN’s cache servers and the client, there are cases where the caching services are avoided, for example by the WebCrawler bots from different Search engines and social network services.” [This latter bit is a crucial piece of info: Webcrawlers are making a mess of things by bombarding websites with requests]
They also showed that now traffic is being generated internally from our WP installations.
Actions taken in response:
– Deleted Jetpack from every domain and sub-domain
– Enabled “under attack mode” in CDN setting
– Blocked traffic for several user agents: android|semrush|googlebot|uptimerobot|amazonbot
– Blocked traffic for several referring web sites: (livegore|anthroblog\.anthroweb|raddle|lakedonpedro|openculture|toba60|buoiholo)\.
– Disabled several WP plugins and updated remaining ones to their latest versions
– Removed most cron jobs
Siteground did not shut down my websites during the rest of June and things were under control till mid-July when things got bad again – below.
JULY 2024
On 18 July 2024, the 80% limit was reached again. I raised the second ticket with Siteground and received feedback based on which the following additional actions were taken:
– removed all unnecessary plugins from all sites
– activated cache on all sites
– BLOCKED FACEBOOK WEB CRAWLERS
– also, since FTI.SABHLOKCITY.COM was causing trouble, added some text to its htaccess file (below)
Looks like that has brought things under control (SEE IMAGE BELOW)
HTACCESS
Inserted the following code into fti.sabhlokcity.com’s htaccess file:
# block bot requests
RewriteCond %{HTTP_USER_AGENT} android|semrush|googlebot|uptimerobot|amazonbot [NC]
RewriteRule ^ – [F]
# block bad referrers
RewriteCond %{HTTP_REFERER} (livegore|anthroblog\.anthroweb|raddle|lakedonpedro|openculture|toba60|buoiholo)\. [NC]
RewriteRule ^ – [F]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
ALSO SEE MY TWEET.
