TL;DR? Just leave it as it is.
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.
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.