I have a website hosted by Byethost for a number of years. I would like to migrate that site here, but I notice that Infinityfree seems to use the same Byethost names servers ( ns1-5) I have been using. This makes me wonder if the the same issue I want to leave Byethost over will recur at Infinity Free.

Four years ago, Byethost instituted a practice on free accounts of capturing all requests for a given url with a jscript file ending /aes.js.

Sean At Clicky Analytics, who helped me figure out what was going on with my web stats, described it thus: “This would also explain why referrers are getting hidden [in your stats], this interstitial page is capturing the referrer. When the person finally actually sees your “real” site, the referrer is gone because this is a second page view and not the first one.”

A typical page in my analytics data may show this for a first visit to a page:

When I contacted Byethost Support to ask what was going on, they responded, “This is a newly introduced bot detection feature on free hosting to prevent unwanted bots. This only appears upon first visit to the page.” That obviously sounds ominous since bots are how you get and stay indexed in Google, etc. However, this was never a problem until recently. I am assuming that something has changed in Google’s algoriths because suddenly its bots supposedly cannot access my robots.text page and have been systematically deindexing my pages on the grounds that they don’t know if those pages are on the robots text Disallow list. The only explanation I can come up with is that the robots are no longer processing the Byet-imposed URL endings when they look for robots.txt.

Does anyone here with web analytics know if the same thing is done here (i.e., an interstitial page to capture and redirect) inquiries? Because if so, I don’t see how I can solve my problem by moving my hosting here. It used to just be a problem parsing my web analytic. Now it is a problem that is wrecking my site visits.

Byethost and InfinityFree use the same underlying systems, so you can expect the service to be extremely similar. The same bot protection system you encountered on Byethost is present on our hosting as well.

To my knowledge, precautions were taken to make sure that this would not impact search engine crawlers (since those crawlers can execute Javascript code too), but it’s possible that due to search engine changes this doesn’t work anymore. And since you’re not the first person reporting problems with search engines, I’m going to try to dig into this soon when I have time.

1 Like

To be honest, the AES “bot protection” just causes headaches and nothing more. People who REALLY want to scrape your site, can just execute the AES code on their own server to retrieve the requested resource.

I agree, this Javascript/cookie security system is not perfect. But a security measure doesn’t have to be perfect to be effective. Like you said, if people really want to scrape your site, they can, but most bots will just see the 403 error, assume the website is blocking them or is down, and move on to the next site to attack.

I’ve seen plenty of cases where websites got suspended for hitting resource limits after their website was hit by a wave of hackers which were not stopped by Cloudflare. I don’t know of any case where this happened through our bot protection system.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.