Hi Glen, you’ve neatly encapsulated the problem there – because for some this is indeed a deal breaker and all I can say is we are keenly aware of that and there is ongoing internal discussion about this.
I appreciate you answering this, but I’m baffled as to why this behavior would be considered correct.
Well, to take a simplified scenario, if you visit a WordPress site and go to example.com/wrong-url then you’re really querying for a page called “Wrong URL”. If that page doesn’t exist a page not found message will typically be displayed and a 404 status header will be returned. Generally most people agree this is correct behaviour.
The parallel is that if you go to example.com/events/2015-10-01/ (but have no events scheduled for 1st October 2015) then your query is again drawing a blank and so a 404 status is correctly being returned. You will see in a thread like this one that most people feel strongly that this shouldn’t happen, but believe me there are also those with strongly opposing views who feel this is how it should be done.
So Google’s correct in listing all these many 404s because in a typical installation they doubtless exist, and, because customers expect to be able to navigate to the next/previous day we are also linking to them. That aspect is what adds an unusual edge to the situation.
The bind, then, is doing things correctly but also offering an acceptable means of working around this that doesn’t impact on site performance adversely as, again, that’s another area that is of high importance for certain segments of the user-base.
All that to say, we’re aware of the problem and everyone’s concerns and certainly have ideas for solutions – but it won’t I’m afraid be an overnight fix.