The Google crawler sometimes hits URLs have ExpressionEngine error messages on them and caches them because they respond with HTTP 200.

enter image description here

These error messages are handled by the show_user_error() method. Before I go and start hacking core, am I correct in suggesting that these error messages show return an HTTP error?

If so, which HTTP status should it show (I'm thinking 403 Forbidden but perhaps there is a more precise status)

3 Answers 3


TL;DR? Just leave it as it is.

Request Codes

Before getting into this it's worth familiarising yourself with different HTTP request codes. A 200 header (the default) has the following meaning:

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

  • GET an entity corresponding to the requested resource is sent in the response;
  • HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
  • POST an entity describing or containing the result of the action;

In instances where an app has hit an exception it's common to send HTTP 500 headers:

The server encountered an unexpected condition which prevented it from fulfilling the request.

Within the context of EE it's difficult to definitively state which headers should be sent with error messages. In apps that I've developed I've used 500 headers only when an uncaught exception is triggered, since this represents an unexpected behaviour that the app is unable to process/work around. The request has failed in a manner that wasn't/could not be anticipated.

If an expected error crops up, such as validation failure, I'll implement any redirects/status messages as necessary, but I won't send a 500 header. The request has 'succeeded' in the sense that 'an entity corresponding to the requested resource [was] sent in the response'.

With EE, error messages can crop up for both expected and unexpected errors, as there's no granularity to the native error handling. It doesn't matter whether someone's forgotten to enter their email address or a required extension could not be loaded, the same error handler is used.

There's a very strong argument that EE should have its error handling beefed up significantly, but with the current system it's debatable whether the show_user_error method should send non-standard headers. In some situations it might be appropriate, in others it wouldn't be. Throw in the fact that core modifications are generally inadvisable and I'd suggest that you're better off sticking to the default behaviour.

Search Engines

A typical production EE site will only be displaying errors for validation issues, so error pages should never be indexed (as search engines don't POST). If your site is frequently returning errors for GET requests I'd have thought you'd want to focus on the underlying cause of those errors, rather than stopping them from being indexed.

  • +1, might be worth moving the TL;DR to the top for newbies though
    – Tom Davies
    Dec 6, 2012 at 11:11
  • Good point, I've moved it.
    – Dom Stubbs
    Dec 6, 2012 at 11:17
  • Not too long, thanks for the detailed response. Dec 6, 2012 at 13:01
  • If you were going to hack the core, I would recommend sending the HTTP "422 Unprocessable Entity" error code. Any 4xx code clearly communicates that there was a problem with the client's request, not an unexpected exception on the server (5xx error). See also en.wikipedia.org/wiki/… Feb 17, 2013 at 5:00

Before you hack the core you can check out this add-on ($12):


It allows you to use your own defined templates in case of an error. In the template you can use PHP, and thus send different headers.

  • I don't think custom system messages allows you to specific HTTP error codes though, does it?
    – Tom Davies
    Dec 6, 2012 at 11:10
  • You can add this for example to the top of the template for an 404 HTTP status code: <?php $this->EE->output->set_header("HTTP/1.0 404 Not Found"); ?>
    – Thijs
    Dec 6, 2012 at 11:28
  • 1
    Assuming you're using EE's built-in 404 capabilities there's no need to send 404 headers manually, it will do that for you. Also I think there's a pretty good chance that calling set_header within a template will result in a 'headers already sent' error, since template code isn't parsed particularly early.
    – Dom Stubbs
    Dec 6, 2012 at 11:43
  • Custom System Messages bypasses the EE built-in capabilities, so therefor you need to set your own headers. Which I can confirm are early enough outputted to prevent 'headers already sent'-errors.
    – Thijs
    Dec 6, 2012 at 12:07
  • I suppose you might be able to use that approach to send custom error headers, but why use it for 404s? Unlike other error types you can specify a custom template for 404s without the aid of any addons.
    – Dom Stubbs
    Dec 6, 2012 at 12:41

Add meta no-index to your message templates:

<meta name="robots" content="noindex">

  • 1
    I'd tread carefully with this. What if, for example, your gallery module breaks and yoursite.com/gallery starts to display an error? The next time a search engine crawls that page it'll parse your noindex setting and remove your gallery from its search results. There's no guarantee that it'll be re-crawled when the error has been fixed.
    – Dom Stubbs
    Dec 6, 2012 at 13:36
  • +1 for that very good point. Dec 7, 2012 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.