>Just a SWAG: how about rewriting all current direct JS calls to statcounter from your pages into function/Ajax call into your own server ? Dunno the effort, but you could try to bribe an officially retired coder to munge all such pages with some code in a language with nice string functions.

Actually not an option, because my whole concept is based on generated pages frequently ftped to the server - and then everything's static, it's all in files, there's no app running for me on the server.

>Of course piping the data into table(s) on your server as backup solution easy to do -
>if statcounter has problems data is already saved/safe...

It's already done by them, it's just a matter of finding what API they may have that I can use to retrieve these data. There's time for that. So far, it's no problem to read two pages in the browser (two, because they count http and https separately) and copy a number from each and enter into my local table here.

Just wanted to know if there's something I should have known but didn't, about statcounter and generally such add-ons which require a http call from the webpages to work. I confess I was slow on the uptake - the decline in counted visits began gradually in 2017, and has now dwindled to near nothing, and I ascribed that to google's ever changing rules (which did happen, but were they the cause?).

Yesterday I found a page where the webalizer has statistics for the last twelve months, and I copied those into my tables and guess what - for this year alone I had more visits that the statcounter had counted between 2007 and now. So, I'd say, it's time for a little codectomy.