7 thoughts on “Optimizing WordPress 404’s Leave a comment

  1. You could just hook it to init like this:

    add_action('init', 'bm_404Response');

    This only works for static file types, because of the way your server serves these things: for images etc. it first tries to find the file on your server and serves it immediately without loading WordPress. If it can’t find the file, it defaults to loading WordPress, then when you have that function you wrote and do the add_action as above, it’ll immediately output and stop right there.

    By the way, W3 Total Cache has an option where you can set it to quit even sooner, it adds some lines to your .htaccess file that essentially do the same without even booting WordPress at all.

    1. Hey Joost – thats for the feedback. I didn’t realise w3 total cache added rewrite riles for that. That’s clever stuff! πŸ™‚

      I did try adding the code to the init hook, but WordPress hasn’t decided if the content is a 404 or not by that time so I have moved it to the template_redirect hook which seems to work quite well, and cleans up my templates a little.

      1. The funny thing is, when it’s a static file, if you’re not running any weird plugins, WordPress doesn’t have to decide whether it’s a 404. If WordPress is being called for a static file, it is a 404 otherwise the web server would have served the file directly.

  2. By the way, you should really disable paged comments, you’re already having a comment-page being indexed and I don’t think you need them often, to be honest.

    Feel free to just delete this comment πŸ˜‰

    1. Hmm – that’s interesting. I thought WordPress took care of paged comments with it’s rel=canonical, and nofollow settings. I wonder if I can build support for that into my theme…

      The reason for the paged comments is that I have a number of posts with massive amounts of comments (500+), and even more with 100+ comments. I’ve bumped up the number of posts per comment page but that won’t help with this issue since the comments still link to the comments pages.

      1. WordPress does set the canonical correctly, but it’s still not ideal, ideally the comments after 100 or so would be served using JavaScript… Funny thing is, the issue is not with the comments, even at 500 that’ll hardly affect pageload, it’s with the gravatars…

  3. Given I brought this article to Joost’s (Yoast’s) attention, I figured I’d chime in and say it’s been interesting to read. I implemented the stuff in this article into my 404 page via functions, but I haven’t tried via init as of yet. And W3TC does have the 404 option for static files via the “Browser Cache” page (not sure why it’s there). And I guess you could customize the 404 code with that as well by setting the “Error 404” entry in the .htaccess.

    6 of 1, half a dozen, you know. Either way, getting the load for 404’s off WP when it’s bad files being requested isn’t a bad idea. And Yoast’s 404 article (http://yoast.com/404-error-pages-wordpress/) is what started all this anyway. Oh, and Google’s article about intelligent 404’s (https://www.google.com/support/webmasters/bin/answer.py?answer=93641&hl=en)

Leave a Reply

Your email address will not be published.