Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Optimizing Matters

    (@optimizingmatters)

    there can be 2 reasons for this;
    a) google crawling your CSS/ JS using older HTML cached previously by Google referring to Autoptimized CSS/ JS that got purged (when changing settings and clicking “save & purge cache”). this can be safely ignored, there’s no visitor impact (if you look through the AO support forum you’ll find some solutions to turn these 404’s into 410’s which say “gone permanently”)
    b) visitors seeing the page (HTML) from cache (a page caching plugin or a hoster’s cache or something like cloudflare page rules or sucuri caching) where the HTML refers to Autoptimized CSS/ JS that got purged (when changing settings and clicking “save & purge cache”), this does have customer impact, in this case you should make sure to purge whatever page cache it is you are using.

    what also helps is not purging AO’s cache too frequently and (and this is the exact reason why AO does not do so) not use a solution to automatically clear AO’s cache.

    hope this helps,
    frank

    Thread Starter dbodnariuc

    (@dbodnariuc)

    Hi Frank,

    Thanks so much for the fast turnaround. It is greatly appreciated.
    I know about the bots’ attempts to access old cached css files, but this is a little different.

    The 404 are for existing files. I am using the “Redirect” plugin, and I get reports for 404s. When I click the link for the “inexisting” file, it is live I can access it. (Tried to access it both logged in and logged out.)

    And it’s not only bots, it’s various IP’s.

    I initially wanted to blame it on Cloudflare, but the logs are on my WP, not on Cloudflare’s side.

    Then I thought it was a problem with the “Redirect” plugin, wrongly reporting, but I had the SEMRush bot saying that they got 404s for the CSS files. So the problem is real.

    I then contacted the ISP, (Siteground), which was useless they told me to hire a developer. They said there was nothing in the server’s logs.

    Thanks again,

    Dorian

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Hey Dorian;
    That’s a difficult one; from AO’s point of view the work ends with writing the optimized CSS/ JS to the filesystem and inserting the link to said CSS/ JS files in the HTML. The sending of the autoptimize-files is completely taken care of by the webserver(s) (incl. intermediate proxies/ caches) and there no PHP-code from AO or WordPress involved to do so. If the file is there, the webserver should send it in the response, if the file is not there the webserver should send a 404.

    The only thing that might intervene somehow are “weird” .htaccess rules that were added to stop certain hosts/ ip’s/ useragents from requesting certain files, so maybe check your /.htaccess, /wp-content/.htaccess, /wp-content/cache/.htaccess and /wp-content/cache/autoptimize/.htaccess (where available) to see if anything in there might cause this behavior.

    The million dollar (or euro) question off course is; have visitors of your sites (or you) ever seen the page break due to missing CSS/ JS. Have you gotten any feedback that confirms there _really_ is an issue for _real_ visitors?

    frank

    Thread Starter dbodnariuc

    (@dbodnariuc)

    Thanks so much for the help, Frank. It’s a good starting point.

    Best regards,

    Dorian

    • This reply was modified 6 years, 5 months ago by dbodnariuc. Reason: Marked as closed
    Plugin Author Optimizing Matters

    (@optimizingmatters)

    you’re welcome Dorian, feel free to leave a review of the plugin and support here! ??

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Lots of 404 for the autoptimize css file’ is closed to new replies.