Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter kwikbreaks

    (@kwikbreaks)

    Incidentally I see these 404s in my May AWstats…

    /wp-content/cache/autoptimize/js/autoptimize_2563c81971f88e08f56a96145a24139c.js 1 –
    /wp-content/cache/autoptimize/js/autoptimize_8aaa9603015384ae0a22ef1fe3a81a70.js

    I removed Autoptimize in the middle of April.

    There are others for mmr too.

    All a little strange – certainly there must be some access of filenames cached quite a while back. I recall baidu spider showed one in the logs extract I posted above.

    Thread Starter kwikbreaks

    (@kwikbreaks)

    It don’t think it could have been anything to do with minification because I wasn’t getting any – unless you were doing some name changes despite that.

    Thanks for your new version I’ll give that a try immediately. I can erase the cache on a couple of unimportant sites when I install it and look for future 404s. I’ll leave the existing cache in place on the off chance that google are doing something strange.

    My host must be filtering out stuff from the logs I see because there appears to be a lot of stuff missing – for instance the only /mmr/ references I get are the 404s. The only time I see a .jpg is when accessed by a bot. In other words I see the first access by an IP but the subsequent accesses don’t appear. That means I can only guess at why those 404s occurred.

    ====

    I see from the cache logs that the new version kept the old names and did not minify until after I purged the old logs. That’s maybe in some instructions on the new version I didn’t read or or maybe something you hadn’t anticipated. Anyway I will take my chances on 404s and purge logs post install then visit the site myself to bet the merged and minified files.

    Thread Starter kwikbreaks

    (@kwikbreaks)

    Well assuming the behaviour is going to continue it may be worth setting a cron event to erase them say a week later but it does depend on how often they change and how big the cache gets. Wouldn’t it be possible to base the name on the names of the inner files? That way if the detail changed it wouldn’t lead to a new one.

    TBH I thought the 404s came because I purged all the old files after I made a change to the google cookiechoices.js to avoid bitching about tap areas being too close for mobiles and again when there was a plugin update.

    Thread Starter kwikbreaks

    (@kwikbreaks)

    Yes they should be getting current files for sure which is why I suspected the scenario I mentioned with one bot doing the initial crawl and the rendering engine using the cached crawl bot results.

    Here are some examples…

    66.249.67.6 – – [28/Apr/2015:19:40:00 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1429973119.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.6 – – [28/Apr/2015:19:40:01 +0100] “GET /wp-content/mmr/7de6c2e13d0130a9d9147004ef57a60a-1429818370.js HTTP/1.0” 404 4566 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.150 – – [29/Apr/2015:20:10:21 +0100] “GET /wp-content/mmr/7de6c2e13d0130a9d9147004ef57a60a-1429818370.js HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.6 – – [29/Apr/2015:20:10:23 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1429973119.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.150 – – [29/Apr/2015:22:10:14 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1430043995.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    180.76.5.72 – – [30/Apr/2015:12:33:53 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1429973119.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)”

    Same thing with Autoptimise which I stopped using…

    66.249.64.10 – – [12/Apr/2015:13:41:11 +0100] “GET /wp-content/cache/autoptimize/js/autoptimize_1def9452184e35355f8bea6938800833.js HTTP/1.0” 404 3431 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.64.10 – – [12/Apr/2015:15:20:14 +0100] “GET /wp-content/cache/autoptimize/js/autoptimize_701631908f497308ac278a379c57b69e.js HTTP/1.0” 404 3431 “http://www.kwikbreaks.co.uk/site-1752/” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.64.14 – – [12/Apr/2015:16:34:25 +0100] “GET /wp-content/cache/autoptimize/js/autoptimize_8202e63df1d5530042d6d0701dd44226.js HTTP/1.0” 404 3431 “http://www.kwikbreaks.co.uk/holmbrook-cumbria/” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

    Thread Starter kwikbreaks

    (@kwikbreaks)

    Cache seems to be reasonable. I have purged all a few times but I think it may be a mistake to do so…

    Since google has moved over to being very hot on mobile friendliness their crawler wants to see all css + js. I’ve seen some 404s from their bot on both this and a previous plugin cached files and my multiscreen entry in adsense is showing a down arrow even though I’ve made no changes that impact responsiveness.

    I think google are crawling pages for keyword ranking etc. then using their cached source to later do the mobile friendly bit. As all those pages will be specifying stuff in cache and if you purge cache then they can’t do the mobile friendly testing.

    Might all be complete rubbish but I won’t be purging my cache unless I see it getting silly and even then I’ll just bin really old items.

Viewing 5 replies - 1 through 5 (of 5 total)