After Disabling Adsterra Native Banner for 6 Days: Abnormal Redirects Disappeared, but Browser Security Warnings Remain

A while ago, I tried integrating Adsterra into my blog, hoping to add a new ad monetization method alongside Google AdSense.

At that time, I did not deploy ad formats like Popunders or Social Bars. I only actually used Native Banner, deploying a total of 3 ad placements:

• At the end of the content on Chinese article detail pages;
• At the end of the article list on Chinese archive pages;
• At the end of the article list on English archive pages.

This was originally just a normal ad platform test, but after running it for a while, I encountered several highly abnormal phenomena on the mobile side.

First, the mobile system’s default browser suddenly started warning that my website posed a security risk.

It was precisely because of this warning that I further wondered:

If the system browser already considers the website risky, could there also be issues in other mobile browsing environments?

So, I specifically used WeChat to open a blog article for testing.

Unexpectedly, this test revealed an even more serious problem: after normally opening an article, the page automatically left my blog, redirected through an unfamiliar domain, and ultimately even entered the phone’s SMS sending interface.

These phenomena made me seriously suspect the recently integrated Adsterra Native Banner.

Therefore, on August 8, I decided to disable all Adsterra ads. I did not actively clear the cache; instead, I waited for it to expire naturally and then observed the results a few days later.

It is now August 14, 6 days since disabling Adsterra, and I can organize the interim results obtained from this actual test.

1. The Starting Point: The System Browser Suddenly Warned of Website Security Risks

On the morning of August 8, 2026, when I used my phone’s default system browser to open my blog, I suddenly encountered a security block.

The browser directly prompted:

Website poses security risks

It also warned about the risk of important information such as accounts and passwords being leaked, and recommended stopping the visit.

Seeing this prompt at the time was quite surprising to me.

After all, this is a blog I have maintained long-term, and I was accessing the normal primary domain.

If this anomaly had only occurred once, I might have suspected a false positive from the browser.

But this security prompt gave me a new idea:

Since the system browser had already started issuing warnings, could the website actually be exhibiting some abnormal behavior in certain mobile environments?

So, I decided to continue testing.

2. Because the System Browser Showed Warnings, I Tested Further Using WeChat

After discovering the system browser’s security warning, I did not stop there.

I subsequently used WeChat specifically to open the blog’s article detail pages, hoping to see whether the website could be accessed normally in another common mobile browsing environment.

As a result, this test revealed an even more serious problem.

Shortly after the article page was displayed, it suddenly left my website.

WeChat then displayed an external URL access warning.

The address it was preparing to visit had already changed to:

https://rd.rvcovers.click/pop.go?spaceid=...

https://rd.rvcovers.click/pop.go?spaceid=...

This was clearly no longer my blog’s domain.

More crucially, I had merely opened my own article normally and had not actively clicked on any obvious external link.

In other words, this was not a case of:

The user actively clicking an ad and entering the ad page.

Rather:

After normally opening a blog article, the page underwent an abnormal redirect on its own.

This made me even more alert to the security warning that had appeared in the system browser earlier.

Although the two phenomena manifested differently, they occurred within the same timeframe.

3. The Abnormal Redirect Ultimately Even Entered the SMS Sending Interface

The issue did not stop at the unfamiliar domain redirect.

After proceeding through subsequent pages, a so-called verification process appeared.

Ultimately, the phone even went directly to the SMS sending interface.

An overseas phone number had already appeared in the SMS recipient field, and the SMS body had been auto-filled.

This went far beyond my acceptable limits for standard web ads.

As a webmaster, I certainly know that the website content, the ad platform, and the advertisers might be different systems.

But ordinary visitors do not make this distinction.

The user simply wants to open a technical article, but ends up encountering:

Normal article
↓
Unfamiliar domain
↓
Other landing pages
↓
SMS sending interface

Normal article
↓
Unfamiliar domain
↓
Other landing pages
↓
SMS sending interface

The impression that users are most likely to form in the end is just this:

This website might be problematic.

And what is truly affected is my website’s domain and user trust.

4. Why Did I Start Strongly Suspecting Adsterra?

Looking back at recent changes on the website, Adsterra is a very obvious new variable.

Moreover, aside from the abnormal redirects, when I previously used the QQ browser to view the website, I also found that the quality of some Adsterra Native Banner ad creatives was rather mediocre. The images were somewhat blurry, and some ad content did not fit well with a technical blog.

At the same time, Google AdSense’s revenue per thousand impressions had already dropped from the previous approximate level of:

0.7

0.7

down to:

0.4

0.4

Of course, a drop in AdSense revenue alone cannot prove that Adsterra is the cause.

Ad revenue is inherently affected by multiple factors such as traffic, user geography, ad bidding, and the number of impressions.

What really made me decide to disable Adsterra was the simultaneous occurrence of several phenomena:

• The system browser started issuing security warnings for the website;
• After normally opening an article in WeChat, an automatic redirect occurred;
• The redirect ultimately even entered the SMS sending process;
• The Adsterra ad creative experience was not ideal;
• The overall mobile access situation also noticeably deteriorated.

Especially the abnormal redirects and the SMS process—for a long-term operating website, the risk was already significantly higher than the value of continuing to test for this little ad revenue.

Therefore, I decided to completely disable Adsterra first.

5. August 8: Disabling All 3 Adsterra Native Banners

My actual Adsterra deployment was not complicated.

The entire website only ever used Native Banner.

There were 3 related ad codes in WPCode:

[Adsterra] Native Banner - End of Article
[Adsterra] Native Banner - Footer Ad for All Archive Pages - Chinese
[Adsterra] Native Banner - Footer Ad for All Archive Pages - English

[Adsterra] Native Banner - End of Article
[Adsterra] Native Banner - Footer Ad for All Archive Pages - Chinese
[Adsterra] Native Banner - Footer Ad for All Archive Pages - English

On August 8, I disabled all 3 of these ad placements.

Among them:

• ID 20250: End of article ad;
• ID 21010: Chinese archive page ad;
• ID 21013: English archive page ad.

For the two archive page ads, I also went into the WordPress theme editor and deleted the corresponding shortcodes from the templates.

Therefore, I actually did two layers of processing this time:

1. Disabled the Adsterra ad codes in WPCode;
2. Deleted the corresponding archive page ad shortcodes from the theme templates.

However, I did not actively clear the website page cache and CDN cache at that time.

My plan was:

To let the existing cache expire naturally, and then retest.

Although this requires waiting a few extra days, it allows for a more natural observation of the process of Adsterra ads gradually phasing out from the website.

6. Retesting After 6 Days: The Abnormal Redirect in WeChat No Longer Occurred

On August 14, I again used WeChat to open a blog article for testing.

This time, the article displayed normally and stayed on my blog properly.

I did not encounter the situation from August 8 again, where:

Blog article
↓
Unfamiliar domain
↓
Other landing pages
↓
SMS sending interface

Blog article
↓
Unfamiliar domain
↓
Other landing pages
↓
SMS sending interface

the abnormal flow occurred.

The two phenomena that worried me the most before:

Automatic redirects and the SMS sending process, have not reappeared.

This is the most obvious change in this disabling experiment.

Looking at the chronological relationship:

Abnormal redirect occurred
↓
Disabled Adsterra Native Banner
↓
Waited for cache to gradually expire
↓
Retested
↓
Abnormal redirect no longer occurred

Abnormal redirect occurred
↓
Disabled Adsterra Native Banner
↓
Waited for cache to gradually expire
↓
Retested
↓
Abnormal redirect no longer occurred

Therefore, I still strongly suspect that the previous abnormal redirects were related to Adsterra.

Of course, based solely on these current tests, I cannot technically prove with 100% certainty exactly which segment of the third-party ad chain triggered the redirect.

But for my own website, the risk assessment is already clear enough:

After disabling Adsterra, the most severe abnormal behavior previously observed disappeared.

This is enough for me to keep Adsterra disabled.

7. The Security Warning Still Exists, But I Do Not Think This Rules Out Adsterra for Now

On August 14, I used the phone’s default system browser again to access the blog.

As a result, I found that the security warning still existed.

However, the prompt content this time was slightly different from August 8.

On August 8, it displayed:

Website poses security risks

While on August 14, it displayed:

This page may contain illegal information

It also mentioned risks such as false advertising and deceiving consumers.

Although the wording is different, I am currently more inclined to believe:

The two warnings might essentially still belong to the same category of website security or reputation risk flags.

So I do not plan to reverse my thinking and conclude that just because the warning has not disappeared 6 days after disabling Adsterra:

“Then it seems the warning must be unrelated to Adsterra.”

I think it is too early to draw this conclusion.

There are at least two possibilities here.

First Possibility: A Time Lag Exists in Security Risk Records

If the website was previously recorded as a high-risk website by a certain platform due to behaviors like third-party ad redirects, then even if I have deleted the relevant code today, this record might not automatically disappear immediately.

It may require some time to re-detect and update.

This is not exactly the same as web caching.

The disappearance of the Adsterra ad code from the website does not mean that the historical risk records of all browsers or security platforms will be immediately updated in sync.

Second Possibility: The Website Owner Needs to Actively Apply for a Review

Another possibility is that once certain security risk flags are generated, they are not immediately lifted automatically just because the problem has gone away.

It might also require the webmaster to actively submit an appeal, an access restoration request, or wait for a manual review.

I have not yet specifically confirmed which security detection system this browser uses, so this can only serve as a direction for further troubleshooting for now.

But at least for now, I do not believe:

“Warning still present = Adsterra is unrelated to the warning.”

Quite the opposite.

Considering the actual abnormal redirects that occurred on August 8, and the disappearance of the redirects after disabling, I still highly suspect that Adsterra is one of the important triggers for this entire problem.

8. Mobile Traffic Has Dropped Significantly, Making Me Pay More Attention to These Security Warnings

Additionally, I later noticed another phenomenon in passing:

The blog’s mobile traffic has dropped quite severely recently.

It cannot yet be proven that this is definitely caused by the security warnings.

But from a user behavior perspective, if some mobile browsers, built-in browsers, or security services directly display:

Website poses risks

or:

Page may contain illegal information

when accessing the website, then the probability of users choosing to leave immediately is obviously very high.

Some users might not even click “Continue Visiting” at all.

This means that even if the website server itself is running normally and pages can open fine, as long as the entrance is blocked by a security prompt, the actual mobile traffic may still be noticeably affected.

Therefore, in addition to continuing to observe when the security warning disappears, I also need to include mobile traffic changes in my observations going forward.

If mobile traffic recovers simultaneously after the security warning is lifted in the future, then the correlation between the two will be even more worth studying.

9. Adsterra Backend Data Recorded the Process of the Cache Gradually Phasing Out

This time, I also kept the complete statistical data for Adsterra from the start of deployment until after it was disabled.

The entire test cycle was only about twenty days, so this time I directly took screenshots and saved all the dates.

This statistical chart is very interesting.

After officially disabling Adsterra on August 8, the backend Impressions did not immediately drop to 0.

For example:

August 8: 17 Impressions
August 9: 22 Impressions
August 10: 13 Impressions
August 11: 12 Impressions

August 8: 17 Impressions
August 9: 22 Impressions
August 10: 13 Impressions
August 11: 12 Impressions

Then came:

August 12: 0 Impressions
August 13: 0 Impressions

August 12: 0 Impressions
August 13: 0 Impressions

This basically matches my handling method at the time.

Because I did not actively clear the cache.

After disabling the code, some already generated cached pages might still continue serving old versions of the content.

As these page caches gradually expired naturally, Adsterra’s impressions finally dropped to 0.

So, a relatively clear timeline can also be seen from the data:

August 8
Disabled all Adsterra Native Banners
        ↓
August 9–11
Still a small number of historical impressions
        ↓
After August 12
Impressions dropped to 0
        ↓
August 14
Conducted mobile testing again

August 8
Disabled all Adsterra Native Banners
        ↓
August 9–11
Still a small number of historical impressions
        ↓
After August 12
Impressions dropped to 0
        ↓
August 14
Conducted mobile testing again

This is also why I did not immediately declare the problem solved right after disabling the ads on August 8.

Testing after the cache has naturally cleared makes the results much more valuable for reference.

10. How Much Money Did Adsterra Actually Make This Time?

From the complete statistics, it can be seen that this Adsterra test earned a total of:

Impressions：221
Clicks：2
CTR：0.905%
Revenue：$2.60

Impressions：221
Clicks：2
CTR：0.905%
Revenue：$2.60

The entire test cycle was only about twenty days, and the number of impressions was very low, so this set of data is obviously insufficient to evaluate the long-term revenue level of the entire Adsterra platform.

From the screenshots, it can also be seen that on some dates, due to extremely few impressions, the CPM fluctuated wildly.

In this situation, the daily CPM itself has almost no significant reference value.

So I will not conclude based on these 221 impressions that:

Adsterra revenue is high.

Or:

Adsterra revenue is low.

What really made me decide was another question:

For this extra ad revenue, am I willing to bear the potential risks of abnormal redirects, loss of user trust, and damage to domain reputation?

After this actual experience, my answer is already very clear:

No.

In the end, this entire test generated only $2.60 in revenue.

Even if traffic increases in the future and revenue improves, as long as there is a possibility of issues like abnormal redirects, the risk remains too high for me.

11. AdSense Revenue Per Thousand Impressions Is Still Around 0.4

There is another issue that needs to be recorded separately here.

While using Adsterra, I noticed that Google AdSense’s revenue per thousand impressions dropped from the previous approximate level of:

0.7

0.7

down to:

0.4

0.4

At the time, I also suspected:

Could Adsterra have affected AdSense’s performance to some extent?

For example, by affecting page experience, user retention, ad viewability, etc.

However, by August 14, 6 days after disabling Adsterra, AdSense’s revenue per thousand impressions still remained roughly at:

0.4

0.4

It had not clearly recovered to the previous level of around 0.7.

Therefore, it cannot currently be concluded that:

After disabling Adsterra, AdSense revenue immediately recovers.

Nor can the current data be used to conversely prove that:

Adsterra had absolutely nothing to do with the drop in AdSense RPM.

6 days is still a relatively short period, and AdSense revenue itself is affected by many variables.

So for this part, I plan to continue observing rather than drawing a conclusion right now.

12. Interim Conclusions After 6 Days

Looking back now at these issues that appeared on August 8, I currently have three main interim conclusions.

1. The Abnormal Automatic Redirects and SMS Sending Process Have Disappeared

This is the clearest change so far.

After disabling Adsterra Native Banner and waiting for the cache to naturally expire, opening a blog article again in WeChat did not result in the previous situation of automatically redirecting to an unfamiliar domain and ultimately entering the SMS sending interface.

Therefore, I currently still:

Highly suspect that the previous abnormal redirects were related to Adsterra.

Although I temporarily have no way to achieve 100% technical evidence regarding the chain of events, from the perspective of actual website operation, this is enough to support my decision to keep Adsterra disabled.

2. The System Browser Security Warning Still Exists, But Adsterra Cannot Be Ruled Out Because of This for Now

This is the problem that has not yet been completely resolved.

When retesting on August 14, the system browser still issued a risk warning for the website, just with some changes to the prompt text.

I am currently more inclined to believe that the two prompts might belong to the same category of risk flag.

There are two possibilities worth continuing to verify as to why the warning has not yet disappeared:

• There is a time lag in updating risk records;
• The website owner might need to actively apply for a review or to have the risk flag lifted.

So the accurate status of this item right now should be:

The abnormal behavior has disappeared, but the browser-side risk record might not have been synchronously lifted yet.

Rather than simply concluding:

Adsterra is unrelated to the security warning.

3. AdSense RPM Has Not Recovered Yet

After disabling Adsterra, AdSense’s revenue per thousand impressions is still around 0.4.

This means it is not yet possible to determine whether there is a relationship between it and Adsterra.

This part can only be observed through longer-term data.

13. This Experience Made Me Re-evaluate the True Cost of Third-Party Ads

When first integrating a new ad platform, the question that is easiest to focus on usually has only one answer:

How much extra revenue can it bring?

But after this actual test, I realized that for a long-term operating website, there are many things more important than short-term ad revenue:

• Domain reputation;
• User trust;
• Page stability;
• Mobile access experience;
• Risk assessments from search and security platforms;
• The long-term brand image of the website.

Especially for a technical blog.

The user is just searching for a technical problem and then entering the website to read an article.

If, after opening the page, they:

• Are warned by the browser that the website is risky;
• Are automatically taken to an unfamiliar domain;
• Ultimately even enter the SMS sending page;

Then regardless of which layer the actual problem ultimately lies in, the visitor will only remember:

This website is unsafe.

In contrast, the total $2.60 revenue brought in by this Adsterra test seems extremely insignificant.

Conclusion

This incident started on August 8, and the first phase of retesting was completed on August 14.

The results obtained so far can be summarized as:

System browser displayed a security warning
        ↓
Further testing using WeChat
        ↓
Discovered abnormal automatic redirects
        ↓
Even entered the SMS sending process
        ↓
Disabled all Adsterra Native Banners
        ↓
Did not actively clear cache, waited for natural expiration
        ↓
Adsterra Impressions ultimately dropped to 0
        ↓
WeChat abnormal redirects disappeared
        ↓
SMS sending process disappeared
        ↓
But the system browser security warning still exists
        ↓
AdSense RPM is still around 0.4

System browser displayed a security warning
        ↓
Further testing using WeChat
        ↓
Discovered abnormal automatic redirects
        ↓
Even entered the SMS sending process
        ↓
Disabled all Adsterra Native Banners
        ↓
Did not actively clear cache, waited for natural expiration
        ↓
Adsterra Impressions ultimately dropped to 0
        ↓
WeChat abnormal redirects disappeared
        ↓
SMS sending process disappeared
        ↓
But the system browser security warning still exists
        ↓
AdSense RPM is still around 0.4

So what I am most concerned about right now is no longer:

How much more money can Adsterra make?

But rather:

How can I make the previously generated browser security warning completely disappear?

Looking at the entire timeline so far, I still strongly suspect that Adsterra is an important trigger for this problem.

Especially after disabling it, the most severe automatic redirect phenomenon has no longer occurred.

As for why the system browser’s security warning is still there, I plan to continue observing for a while and further confirm whether there is a delay in updating security records, or whether the website owner needs to actively apply for a review.

In addition, the recently noticeable drop in mobile traffic is also worth continuing to observe alongside these security warnings.

This Adsterra test can basically come to an end here.

But the issue of the website security warning is not truly over yet.