Support » Plugin: 404page - your smart custom 404 error page » 404 status code changes to 200 after first hit on same URL

  • Leopard-Lady

    (@leopard-lady)


    Hi Peter,
    I’ve found some odd behaviour on the header status code.

    While rerunning security header and performance testing tools, as I’m setting up security headers on a new site, one of the tools at first pass this morning reported the proper 404 header status code (right after installing this plugin).

    I’ve noticed on subsequent tests though it is now failing to return a 404 on the test URL and instead returns a 200.

    After additional testing on this I realized that the FIRST TIME a non-existant URL is accessed it properly returns 404, then all future hits on that SAME URL it returns a 200. The testing tool always uses the same URL to test the 404 header – ie. “page-not-found-test”.

    Also, you may remember from my earlier review, I am running 404 to 301 plugin (for it’s ease of 404 management). Earlier when I first installed your plugin the 404 to 301 plugin continued to work as always (ie. posting the errors to a log and sending me emails). All of a sudden this has stopped working (ie. no longer posting the errors to the log and not sending email notifications even though I’m throwing blatent 404’s at it).

    I am running Nginx on Plesk Onyx – PHP 7.3.2 – FPM Application served by Nginx.

    The only headers I’ve worked on since installing your plugin is the HSTS header (which was already present) I just extended it’s cache time, and I put the Content Security Policy back in place. — I have reverted back to see if these header changes had caused these issues, but that is not the case. Still have the odd behaviour.

    Thank you,
    LL

    EDITED TO ADD: I’m also running Autoptimize and WP Fastest Cache

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Peter Raschendorfer

    (@petersplugins)

    Hi @leopard-lady,

    I’m pretty sure that I know the reason.

    Caching plugins normally do not cache a page if a 404 happens. But after loading your custom designed page the 404 is gone internally in WP. The 404 header is sent, but then the custom page is loaded and the information, that an 404 occured, is gone. I guess, that the page is cached because of that. The second hit on the same URL causes the page to be delivered from cache – and cached pages always are delivered with a code 200.

    WP Fastest Cache does not allow to exclude a page from caching. Excluding is only possible by URL – which does not help you.

    Please try to activate the “Force 404 error after loading page” option. This internally forces a 404 after your custom page has been loaded. But I can not promise that it will help. It depends on WP Fastest Cache.

    Automatically excluding the page from caching is a planned feature for a future version. The first caching plugin I’ll care of is WP Super Cache. Maybe I can add this for WP Fastest Cache also sometime in the future.

    Regards,
    Peter

    Hi Peter – @petersplugins,
    Thank you for your reply. I dug into this last night. Here is what I’ve come up with so far:

    Please try to activate the “Force 404 error after loading page” option

    This did NOT resolve the issue.

    WP Fastest Cache does not allow to exclude a page from caching. Excluding is only possible by URL

    Using search query “exclude a page from caching in WP Fastest Cache” several pages reference how to do this.

    The first 2 in particular are of intereset:
    1 – Exclude Page
    2 – Ultimate Guide To WP Fastest Cache

    So, here’s what I’m thinking on this issue . . .

    – With 404to301 all 404’s resolve on my custom error page URL = /error404/
    – 404to301 does log the ACTUAL 404 URL in the back-end to manage them

    – With 404Page all 404’s resolve to the ACTUAL 404 URL, instead of my custom error page URL

    – EXAMPLE: using this broken URL – mysite.com/broken-url/
    – 404to301 resolves to – mysite.com/error404/
    – 404Page resolves to – mysite.com/broken-url/

    It seems the first step would be for 404Page to resolve all broken URLs to the custom page URL as 404to301 does.

    This would allow us to exclude this page from caching in WP Fastest Cache via manually adding the exclusion – yes?

    Also, this would prevent Google from indexing all of the broken URL’s from cache – yes? — I could see this particular issue becoming an SEO nightmare.

    Automatically excluding the page from caching is a planned feature for a future version. The first caching plugin I’ll care of is WP Super Cache. Maybe I can add this for WP Fastest Cache also sometime in the future.

    It looks like the solution to this is NOT actually plugin specific, just simply “cache” function regardless of cache method.

    By using: define( ‘DONOTCACHEPAGE’, TRUE ); seems best option
    Or possibly: Filters ‘bypass_cache’ maybe?

    There are several threads on here regarding “donotcachepage” method.

    These 3 in particular may be of interest to you:
    Creating a custom header if DONOTCACHEPAGE is True
    How to Exclude a page from being Cached
    DONOTCACHEPAGE for this plug-in

    There are a couple threads regarding Filters ‘bypass_cache’:
    Filters ‘bypass_cache’ not working
    How to exclude CPT Archive from cache

    It seems that “donotcachepage” method is the best option of the two?

    Lastly, I am stumped as to why 404to301 stopped working? Right at first when I enabled 404Page both plugins worked just fine. Then 404to301 stopped unless/until I disabled 404Page. — Don’t know if this comes into play on this issue or not, but after installing 404Page, I did run 2 plugin updates and those were:
    – CAOS for Analytics
    – WP Fastest Cache

    I’m inclined to think it was the WP Fastest Cache update that caused them to no longer work together? – Let me know if you want me to test this by rolling WP Fastest Cache back to the previous version to see if they work together again.

    Getting the 404 header status code correct is an issue I really need to get resolved, as I’m sure many others do as well.

    Appreciate your time and help on this, Peter! You ROCK!

    Best regards,
    LL

    • This reply was modified 5 months, 4 weeks ago by  Leopard-Lady.

    Hi Peter,
    Just touching base to see if you’ve been able to figure anything out on this issue yet?
    Thank you,
    LL

    Plugin Author Peter Raschendorfer

    (@petersplugins)

    Thanks a lot for your detailed analysis. Unfortunately, I am currently unable to take care of the issue. I’ll take a look at it as soon as possible and get back to you.

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.