Hello fellow bloggers and website owners! ProSEOBlogger here.
Our website, Shineads, was humming along nicely, then one morning I logged into my cPanel and my heart dropped. Shineads bandwidth usage, which was normally around 1 GB per day, had suddenly tripled to over 3 GB.
For a site like mine with over 3,500 posts, a sudden spike like that is a serious and expensive problem.
My first thought was, “Am I under attack? Did I get a massive surge of real visitors?” But my traffic stats didn’t show a huge spike in human visitors. To make it even more confusing, I was already using Cloudflare for Shineads, which is supposed to save you bandwidth, not watch it disappear into thin air.
I felt completely lost. After two days of investigation, I finally found the real culprit and a permanent solution.
In this guide, I’m going to walk you through every single step I took to diagnose and fix this problem on shineads.in. I’ll share all my screenshots and data so you can see exactly what happened. By the end, you’ll know how to fix this on your own site and get your server back under control.
So, What Problem Are We Actually Solving?
“Before we dive into the fix, let’s be clear about who this guide is for and why this is such a critical problem, especially for those of us on shared hosting. Most hosting plans advertise ‘unlimited’ bandwidth, but we all know there’s a catch: a ‘Fair Usage Policy’. In reality, your true limit might be between 60GB and 90GB per month.
A normal website might never hit this, but what I experienced wasn’t normal traffic. The kind of aggressive bot activity from my logs acts just like a DDoS attack. It can burn through your entire monthly bandwidth allowance in just a few days. And what happens then? Your hosting provider will send you a warning, suspend your account, or in the worst-case scenario, terminate it completely. Imagine losing your entire website overnight because of a bot you can’t control.
So, this guide isn’t just about saving a few dollars on bandwidth. It’s about protecting your entire online business from a preventable disaster. The settings we’re about to configure will act as a powerful shield for your website, stopping this kind of attack before it can ever threaten your hosting account.”
The Investigation: Following the Clues in cPanel
When you have a bandwidth problem, the first place to look isn’t your analytics; it’s your server logs. For most of us, that means using a tool in cPanel called Awstats.
Step 1: Confirm the Problem in Awstats
I opened Awstats for Shineads and the first thing I saw confirmed the problem was real. The “Monthly history” view showed a clear spike in bandwidth usage. On Sep 22nd it was 1.45 GB, and on the 23rd, it was a massive 3.46 GB.
This proved the bandwidth was being used by my server, but it didn’t tell me who was using it.
Step 2: Find the Culprit in “Robots/Spiders”
The next place I looked was the “Robots/Spiders visitors” report. This is where I had my “Aha!” moment. One entry stood out like a sore thumb: Googlebot.
It had consumed an incredible 11.52 GB of my server’s bandwidth! Bingbot was a distant second at just a few hundred MB.
So, the culprit wasn’t a mystery hacker; it was Google itself! But why was Googlebot suddenly using so much of my server’s bandwidth? And more importantly, why wasn’t Cloudflare stopping it?
The Real Culprit: Why Cloudflare Wasn’t Caching
The next step was to log in to my Cloudflare dashboard for Shineads. It took me less than a minute to find the real “smoking gun.”
I went to Analytics & logs > HTTP Traffic and clicked on the “Bandwidth” tab. I was shocked by what I saw.
Out of 23.44 GB of total traffic, a massive 21.49 GB was UNCACACHED.
This meant Cloudflare was acting like an open door, just passing almost all of Googlebot’s requests straight through to my server. My server was doing all the work, which is why my bandwidth was disappearing.
Why does this happen? By default, Cloudflare caches “static” files like images and CSS, but it does not cache HTML pages. Googlebot requests the HTML for every single one of my 3,500+ posts on Shineads. Since none of it was cached, my server had to generate those pages every single time.
The Solution: A Complete Guide to Fixing the Cache
Now that we know the problem, here is the exact, step-by-step process I used to fix it for good.
Step 1: Force Cloudflare to Cache Everything (The Right Way)
To fix this, we need to tell Cloudflare to cache everything, including our HTML pages. We do this using a “Page Rule.”
The Definitive Fix: Creating the Perfect Page Rule
I learned that just telling Cloudflare to “Cache Everything” wasn’t enough. Sometimes, your server or a WordPress plugin will send a header that tells Cloudflare not to cache a page. We need to create a rule that is powerful enough to override this.
- In your Cloudflare dashboard, go to Rules > Page Rules.
- Click “Create Page Rule”.
- We are going to create a rule that applies to the entire Shineads website. In the URL box, here is the exact code you need to use for your domain:
*shineads.in/* - Now, we add two settings. First, click “+ Add a Setting” and choose “Cache Level” and then select “Cache Everything”.
- Next, click “+ Add a Setting” again. This time, choose “Edge Cache TTL”. For the time, select “a day”.
This second setting is the key. “Edge Cache TTL” tells Cloudflare: “No matter what the server says, I order you to keep a copy of this page in your cache for at least one day.” This overrides any conflicting instructions and forces the cache to work.
Click “Save and Deploy”.
Step 2: Protect Your WordPress Admin Area
We want to cache our entire public site, but we absolutely do not want to cache our WordPress admin dashboard (/wp-admin/). Caching this can cause major login and editing issues.
So, we need to create a second Page Rule to tell Cloudflare to leave this area alone.
- On the same “Page Rules” screen, click “Create Page Rule” again.
- In the URL box, use this code:
*shineads.in/wp-admin/* - For the setting, choose “Cache Level” and then select “Bypass”.
- Click “Save and Deploy”.
Crucial Final Step: Cloudflare processes rules from top to bottom. We need to make sure the /wp-admin/ bypass rule runs before the “Cache Everything” rule. You can just drag the rules to change their order. Make sure the wp-admin rule is in Position #1.
Step 3: Automate Your Cache Purging (The Smart Way)
Now that everything is being cached, you need a way to clear the cache when you publish a new post so visitors see it.
You could log in to Cloudflare and click “Purge Everything” every time, but this is a terrible idea. It’s like burning down a library just to update one book. It forces your server to rebuild the entire site cache and slows things down.
The solution is to use the official Cloudflare WordPress plugin.
- In your WordPress dashboard, go to Plugins > Add New.
- Search for “Cloudflare” and install the official plugin by Cloudflare, Inc.
- Once activated, go to its settings (Settings > Cloudflare) and connect it to your account using your email and Global API Key.
- The most important setting is “Auto Purge Content On Update”. Make sure this is turned ON.
This plugin is incredibly smart. When you publish a new post, it will automatically clear the cache for only the necessary pages: the post itself, the homepage, and the category page. It’s the perfect, automated solution.
Step 4: Final Security & Performance Tweaks
While I was in the Cloudflare settings, I enabled a few other best practices for a complete setup:
- SSL/TLS > Overview: I set my encryption mode to Full (Strict). This is the most secure setting.
- Caching > Configuration: I enabled “Always Online™”. This is a great safety net that serves a copy of your site if your server ever goes down.
- Security > Settings: I kept my Security Level set to “Medium”. This is the perfect balance of security and convenience for most sites.
The Final Results: Did It Work?
After making all these changes, I waited 24 hours and checked my stats again. The results for Shineads were better than I could have imagined.
The Proof is in the Numbers:
Server Bandwidth (from Awstats): My server’s daily bandwidth usage dropped from 3.46 GB to just 657 MB. That’s an 81% reduction!
Cloudflare Uncached Bandwidth: The amount of traffic hitting my server dropped from over 23 GB to just 7.6 GB.
Cloudflare Cache Ratio: My cache hit ratio more than doubled from 23% to nearly 50%!
(And here is the final Awstats report. The bandwidth for Sep 24 is tiny compared to the day before.)
Conclusion
What looked like a terrifying server attack was actually just a simple caching misconfiguration. The problem wasn’t that Googlebot was visiting; the problem was that my server was doing all the work.
By setting up these powerful Cloudflare rules and automating the process with the official plugin, I’ve created a system where Google can crawl Shineads as much as it wants without ever overwhelming my server. As a bonus, my website is now faster and more secure for my real human visitors.
This is the exact process that saved my site, Shineads, and I’m confident it can save yours too. Don’t be afraid to dive into your server logs and Cloudflare settings.
If you’ve ever faced a similar problem, I hope this guide helps you solve it. Let me know in the comments if you have any questions!
All the best,
ProSEOBlogger
