Hi,
the favicon URL appears in the top list because it is really accessed that many times and dynamically served through WordPress, not provided as a real static file. About every client will access this icon, so you likely have twice as much hits in total.
I guess you are not using any kind of caching backend and Statify in default configuration, i.e. JavaScript Tracking disabled.
In addition you are most likely using a theme or plugin that servers the favicon dynamically, because Statify would never notice access to static files.
Please provide some additional information on your setup, s.t. we can reproduce the scenario and investigate on a fix for Statify, if possible.
Besides such scenario being close to worst case in terms of performance (but that’s not the point here), the most simple solution for your case would be turning on the „JavaScript Tracking“ option. Doing so, the client browser triggers the tracking action through JS included in your posts/pages, but definitely never in favicon or similar cases.
Cheers,
Stefan
when I click that link I come to a picture with the W WordPress icon.
As a side note, this behavior has changed with WordPress 5.4
Enhancements to favicon handling in WordPress 5.4
All the best
Torsten
Good catch, Thorsten.
We should probably add an exclusion for this in the upcoming Statify release.
Edit: To be fixed with 1.7 (https://github.com/pluginkollektiv/statify/pull/144)
The client is redirected to the real favicon (HTTP 302) by WordPress. Apparently plugins are already loaded at this point, s.t. Statify has tracked the visit.
200ms TTFB for the favicon redirect – I got sites that are served within 20ms (uncached) total.. You want to fix this at the other side, e.g. by copying the “favicon.ico” file to the root directory or defining a custom icon path in the theme.
Cheers,
Stefan
Thanks for your answers. I have tried to understand what you write. But the main question for me, is: “Do vistiors that wants to visit my blog, get a picture of the icon instead of a page that they are searching?”
I see this at “settings” for statify:
⁎ Entries in top lists only for today
Page tracking via JavaScript (recommended if caching is in use)
Skip tracking for referrers listed in the comment blacklist
The first one is marked, but not the other two.
What I do not understand is, why favicon is top target on my site?
Annika
Now I have activated the function “Page tracking via JavaScript (recommended if caching is in use)”
My question is still, who is asking for the favicon? Why is the favicon the second most reached target on my page, beside the start page? Is it robots that are asking or is it real persons? I am just a simple artist and don’t understand these computer things so well.
My question is still, who is asking for the favicon?
About everybody. The webbrowser tries to find an icon to display in the title bar. If nothing is specified, the default is “favicon.ico” and most browsers try this, even if not specified explicitly.
WordPress integrated a redirection to the default “W” icon, if there is none. Otherwise you would see lots of 404 errors in the server logs, because there is no icon.
Cheers,
Stefan
PS: Statify 1.7 has finally been released today! This solves the “favicon.ico” problem even without JS tracking.
I have now updated Statify, thanks for the advice. I understand that the webbrowsers try to show the icon in the title bar. It is not important to me if visitors see an icon there or not. But in my statistics is written like this:
Most popular ccontent:
1, Home Page 196
2, /favicon.ico/ 124
3, En dag i maj 64
4, Bubblig variant 😀 53
etc.
You might think I am stupid but I do still not understandwhy the favicon is the second most popular content and ranked as nr two of the searchings. It makes me think that the statistics is cheating me. 124 persons have seen the icon together with the page they have been looking for, not as a single target? I have had 124 less visitors than I believed?
I’d never dare to call you stupid because of that. I’m sorry if I came across like that. Thee are lots of aspects to completely understand how the exact numbers are made up.
You are absolutely right, tracking the favicon accesses was incorrect. That’s why we excluded it from now on.
If a user visits a real, countable target and loads the icon, both hits have been counted.
So the only safe statement in this case is, your total number of hits is too high by 124.
One might think, the icon should be #1 in the list and the number should be at least as high as the sum of all other targets (even (uncounted) error pages have a favicon).
But in fact not every page visit reloads the favicon from the server, it’s cached on the client. So 124 hits on the icon could be triggered by 124 (new) visitors, but it could easily be 200, 500 or more (recurring) visitors. Hard to guess the real correlation.
Anyway the false hits will disappear after 14 days (or whatever number you configured).
Then I understand what this is about and what’s happening! Thank you very much.
