After the performance problems we have run into with Lucene.NET we've decided to make a change, we're moving the network on to elasticsearch.

Here's where to get started: https://stackoverflow.com/search

What works:

  • All search operators should be in
  • Many changes below from the old search behavior

What's different:

  • The new search is AND, adding a search term will narrow your results, not expand them.
  • The look of search results is now more unified with the following differences between Q&A:
    • "Q:" or "A:" prefix
    • Answer counts and tags will be present in questions.
    • The answer count will be highlighted in green if it's accepted.
    • (We may index other things later, that's why the results are more generic/google-y now.)
  • It's faster, about 5-10x faster for almost all searches on large sites like Stack Overflow
  • Quoted phrases are exact matches except for case-sensitivity, for example, you can search for code or symbols.
  • If not in a quoted phrase, words will now be stemmed (example)
  • Snippets for context will now be more relevant
  • Excludes are now explicitly supported (like -term and -"my phrase")
  • We don't roll up to the question anymore, if you searched for something that matched an answer, we'll show you the answer directly in search results
  • The search per minute limit is effectively gone, it'll block a bot, but no one else should hit it... We'll be monitoring performance though
  • infavorites:mine is back, with infavorites:12345 (any user id) added

What needs work:

  • What you tell us is broken... Do your worst.

Testing, not yet final:

  • New range support, here are some examples:
    • answers:1..1 (exactly one answer)
    • answers:10..20 (10 to 20 answers)
    • created:2008..2009 (created between Jan 1st, 2008 and Dec 31, 2009)
    • created:2010-04..2010-05 (created between April 1st, 2010 and May 31st, 2010)
    • created:2011-01-05..2011-01-06 (to be clear: it goes to end-of-day)
    • This range syntax applies to a new advanced operator: lastactive: and the other numerical ranges, views:, and score: Additionally, the above syntax is a bit more flexible if you forget it exactly (e.g. score:20-30) in an effort to be intuitive as possible, give it a try - tell us what you think.

I'll try and improve the search as much as possible before it becomes default... At the very least we want it equivalent in relevance and functionality before the switch, but ideally much better. We won't switch until then.

Please give it a try, tell us what you think here, and we'll continually improve it over the holidays as time allows. Bear in mind you may get a search offline page during this test if a change we're making for results necessitates a reindex, and even that should only last about two minutes here on Meta Stack Overflow.

Give it your worst, compare results to the old search, tell us what's better and what's not. We look forward to the feedback.

Update The new search is now the default across the network - we'll be monitoring things over the next few days and would appreciate reports of any crazy behavior you see here.

  • 26
    "What you tell us is broken...do your worst." - Evil grin.
    – animuson StaffMod
    Commented Dec 23, 2012 at 22:16
  • 5
    Any more info on the perf issues? Is there a blog post or similar?
    – redsquare
    Commented Dec 23, 2012 at 23:02
  • @redsquare - I can detail it in a blog post on my blog if there's enough interest...basically I don't think anyone uses Lucene.net at our level of load, so no one's hit the performance bottlenecks on the file locks so hard yet. Commented Dec 23, 2012 at 23:06
  • So you're still using Lucene, you just put a sharded server on top of it. elasticsearch is a great product, I'm surprised this didn't happen sooner.
    – casperOne
    Commented Dec 24, 2012 at 0:12
  • 2
    I hear you used the NEST Elastic search client for .NET that a colleague of mine wrote. That's awesome! Great work!
    – Rahul
    Commented Dec 24, 2012 at 0:21
  • We're all thankful, but let's leave answers for feedback on the search (bugs, enhancements, etc), only as this is an area that needs a ton of attention if it's going to be moved to the main site and we need to make sure it gets all ironed out.
    – casperOne
    Commented Dec 24, 2012 at 0:26
  • 3
    @Rahul - indeed, I've been working with the author to improve on some areas essential to us...I'm committing sections of the health API in the StackExchange fork currently but they'll hopefully be in the main repo soon. Commented Dec 24, 2012 at 0:33
  • @JollyOldSaintNicholas - it's by no means a trivial change, elastic is awesome but also lacked some features we'll be relying on such as bulk UDP (only added in October, etc.). More generally though, there's just no shortage of things to do on our team...search just got a priority boost after becoming a major problem on the Oregon servers for a while a week ago. Bringing something entirely based in Java into our stack (which has nothing else Java, and we have to run on a windows server...for now) isn't a clear win either, has to be well worth it...but in this case it is. Commented Dec 24, 2012 at 0:48
  • 2
    @NickCraver The server setup (whether or not it's something that is running on the same servers as the Redis setups, for example) would probably make for a good Server Fault blog post. Also, did you ever get that search analyst that you guys posted on Careers for, or was this done outside of that position (whether or not it was filled)?
    – casperOne
    Commented Dec 24, 2012 at 0:58
  • 3
    @NickCraver "we have to run on a windows server...for now" Hey now, you're supposed to wait a full year after Jeff left to start hinting at that. :)
    – Pollyanna
    Commented Dec 27, 2012 at 15:47
  • 2
    @TravisJ - there is a stemmer in play unless you use quotes (around a word or phrase, either one) in which case we respect exactly what you were searching for. This is how google works as well...though we may play with the stemmer per-site in some cases - we'll adjust as we go to improve results. Commented Jan 6, 2013 at 23:23
  • 1
    I suppose it has limited utility, but ..# might be nice for all <= # too, if possible. Like score:..# or created:..2009, so I don't have to guess what the minimum value is (or be lazy for operators with minimum value 0)
    – Tim Stone
    Commented Jan 7, 2013 at 22:32
  • 1
    I love the new advanced-search droplist on the right, so I don't get taken away to the advanced-search page for those operators I always forget the syntax of. Commented Jan 8, 2013 at 1:10
  • 1
    @ShaWizDowArd hence the word "effectively." I think noting that it's still there and will block a bot is clear enough as-is. Commented Dec 12, 2013 at 11:05
  • 1
    Phrase search does not exactly work as advertised: meta.stackexchange.com/q/296120/169168 Commented Jun 3, 2017 at 13:00

25 Answers 25


The question result interface is much, much worse than the old one. Compare:

Question list interface


New search question list

Yes, the new interface is much more compact, but some of the most important information about a post - the number of votes, views, answers and whether it has an accepted answer are either missing (in the case of views) or relegated to secondary position that are difficult to see when scanning through a list rapidly. The difference between the new search list and every other question list on the site is jarring and takes some getting used to.

In short, the new interface looks as if it might have been Google's, or any other generic search engine. The reason why I'd use Stack Exchange's search at all is (other than the additional search options), the interface that's unique to questions - if I wanted to see my results as a list like I would on Google, I'd have used Google.

Separate from the interface issue, for many queries the engine now returns answers alongside questions. This is usually a good idea, except that most of the time I don't think it's necessary. Personally, I don't think it's useful for tag searches (e.g. [minecraft] crafting) to return answers, especially since searching for [minecraft] alone will only give you a question list. It also brings up a lot of unnecessary duplicates. Sure, I could add is:question, but I think the answers should not be displayed for these searches by default.

While this might be an issue of getting used to the new engine, there are others queries where it makes no sense at all to include answers. For instance, [minecraft] closed:0 shouldn't return answers, unless explicitly asked to.

Another suggestion, prompted by Jeff's comment: It might be better to group answers with their questions in search results. One of the biggest problem with the new search engine is that if I don't add is:question to my query I'd get a lot of repetition when a question, and multiple answers to the same question, show up in my search results. If I do add is:question though, now I might miss out on answers that may contain my query.

  • 5
    @NickCraver I think it's fine (preferable, even) for posts of different types to be styled (very) differently, assuming this is only an issue with the interface, not with the new search backend being unable to be more flexible in displaying different types of post. Views are useful since questions with large number of views (10k+) and low score can be indicative of problematic questions. Do you have any comments re: searches with tags?
    – Yi Jiang
    Commented Jan 5, 2013 at 6:04
  • 36
    Particularly, I felt lost not being able to spot ratings and views at a first glance, which is a distinctive mark from the Stack. Makes all results look like the same. Really, just a block of equally formated paragraphs very difficult to be dynamically read (in a hypertext sense).
    – brasofilo
    Commented Jan 5, 2013 at 7:40
  • 14
    I don't care so much about number of views but making the number of answers and votes more prominent would be useful.
    – assylias
    Commented Jan 5, 2013 at 11:58
  • 33
    Please, please, please switch back to the old UI. It takes much effort to skim for vote count, answers, etc. That's information I used to determine whether or not a question might be worth looking at. Commented Jan 5, 2013 at 23:34
  • 27
    I also find the new results UI very much inferior. Yes the old made SE distinct from any other site, now I even thought it's an 'dumb' google custom search. Yes the old design made it very easy to give info even by periferic sight about the questions. The old colored boxes made the page stand out and be more interesting visually, helping to focus. It was easy to spot those marked as 'useful' (high votes count) and those ones needing attention. Now all this is lost. I find this change a major feature loss both in character, usefulness and usability.
    – n611x007
    Commented Jan 6, 2013 at 16:24
  • 12
    The feedback I'm hearing again and again is very specific: the score and answer counts need to be more visible. We'll try and tweak the format tomorrow to make these easier to parse at a glance while still working well with the non question/answer result types coming up. Commented Jan 6, 2013 at 21:38
  • 4
    @NickCraver Although I like the new search features, I have to agree with this answer about the UI. Now instead of simply glancing through the search results to easily find the item I'm looking for, I have to actually read each search result to see if it's the one I want. Its far more time-consuming, particularly on days when my brain doesn't feel like it's working at 100%. It would be nice for the # of answers, votes, and if there's an accepted answer or not to visually stand out more, and if Questions and Answers could be separated visually by more than a Q or an A in the text.
    – Rachel
    Commented Jan 7, 2013 at 16:58
  • 9
    You don't need to slightly change the format. Go back to what you had, it was great! Now I need to read lots of q and a to find what I was looking for. It's not very unappealing to me. Searching directly on Google provides me with more readable results. Commented Jan 8, 2013 at 9:04
  • 5
    This change greatly reduces StackOverflow's usefulness to me. I have to read far more text at lower contrast to determine wether or not an answer is useful. As an aside, I created a meta.so account just so I could comment on this. It is very important to me.
    – CornPuff
    Commented Jan 10, 2013 at 19:51
  • 4
    I also find it extremely hard to find something quickly now. The default mixing of questions and answers is just awful, and the layout of the results is cluttered compared to the old one. You just get hit by a brick of text. Please please reconsider the interface!
    – magnattic
    Commented Jan 10, 2013 at 23:30
  • 3
    I also agree the search result UI is getting much worse. It's not a habit problem, it's simply harder to find the useful information. Commented Jan 11, 2013 at 2:57
  • 3
    I have to agree as well; still a few days into using the new search result interface and I find that I am not able to as quickly determine the relevance of the questions my search has presented me with, particularly when I'm looking for questions that might have answers. I find myself using StackOverflow LESS and relying first and foremost on a Google or Bing and THEN coming to StackOverflow begrudgingly to do the search on the site. The way the results are presented is just not as clear as it used to be.
    – Sean Quinn
    Commented Jan 11, 2013 at 14:06
  • 1
    Check out the current results, we took a break from the NY migration for a bit yesterday and introduced quite a bit more consistency with how /questions appears. Let us know what you think. Commented Jan 25, 2013 at 18:13
  • 5
    @nick definitely a lot better. I kinda.. hated.. the old "new" elastic search results. Particularly mixing Qs and As together as different items in the list is really confusing, we had that early on in SO and users really disliked it. Commented Feb 1, 2013 at 0:35
  • 2
    @JeffAtwood I agree that mixing Qs and As isn't helpful. Not only does it reduce compactness by making a single thread take up more than one slot and giving me more to read, but if I determine a question to be irrelevant to my needs after reading it in the results list, I don't really care what answers that question has. The default should definitely be to only display questions.
    – SpellingD
    Commented Feb 1, 2013 at 17:24

Thank you, Thank you, Thank you for giving us a default AND search. You've made it a very Merry Christmas indeed.

  • 6
    I'll upvote this answer since mine would have essentially been identical anyway. Commented Dec 23, 2012 at 22:41
  • 3
    Indeed, this fixes the absolute #1 worst problem with the old search engine. Commented Dec 23, 2012 at 23:03
  • 18
    No more plus key. We're free! WE'RE FREE
    – Zelda
    Commented Dec 23, 2012 at 23:13
  • @BenBrocka - note: the + no longer matters, though we do parse it on +[tag] for example so that it "just works" and doesn't complain...like -[tag] does, intuitive and such. Commented Dec 24, 2012 at 1:02

I just did a search for the Handling Calls to Remove a Moderator post.

Searching normally, with or without quotes, the question comes up first, as expected.

Using the new search without quotes, the question comes up third:

New search for "Handling Calls to Remove a Moderator" without quotes

Using the new search with quotes, the results are even worse, coming in at ninth:

New search for "Handling Calls to Remove a Moderator" with quotes

I think that there needs to be some tweaks added for when the title is an exact match, quotes or not. I assume that it involves giving the title some more weight, but whether or not that's the solution or how this impacts other searches is for you to sort out.

  • 21
    I think the answer here is to promote the question above its answers if in the results - will see the best way to go about this. Commented Dec 24, 2012 at 0:34
  • 2
    Give this search a try now, I've changed how multi-map fields relate to title, body and tags. Title is only searched for questions now, while body and tags are for all posts. I think you'll find the results for title searches in general much stronger...find examples to the contrary and I'll take another look at refining it further. Commented Dec 24, 2012 at 3:13
  • @NickCraver Looks good for now. A very nice touch about the exact title search is that you're searching in the rendered HTML, so I see the original post, as well as this answer in the search results (I used the raw link, not the exact title which was converted). I'll update with more as I find it. Thanks.
    – casperOne
    Commented Dec 24, 2012 at 3:44

Chars such as +, - and underscores are no longer ignored in search terms which makes searches such as "_meta", "c++ books" and "c--" possible.

This is a welcome change. Many thanks! \o/


We need this (default AND, and faster search with effectively no rate limiting) in chat as well. I find myself searching TL a lot for relevant messages, and it takes quite a few searches to get there.

  • 2
    We had considered Lucene.net for searching chat earlier...this is far more likely. After the rollout on the main network I'll get with Ben and Marc to see what it would take to make this happen. Since we can use the same cluster, it's just code that needs writing. Commented Dec 23, 2012 at 23:08
  • We have some huge todo items this week in preparation for the move back to New York (in a shiny new datacenter! weee!) but we'll start planning this out today. It may take a week or two to find the time, but we'll get chat search working on elastic. Commented Jan 7, 2013 at 15:34
  • @NickCraver: Great to know you're looking in to this :) Commented Jan 7, 2013 at 17:38

I saw reference to this in other places here, but please, PLEASE consider changing the behavior of the new search infrastructure to use the is:question search modifier by default. I think searching on questions that have answers is more useful than searching on answers that have questions. If I knew the answer for the problem I'm having, I wouldn't need to come here in the first place. I come to the Stack sites because I have a question on something and I want to know if other people had the same (or similar) question and what the responses were to it.

  • 6
    Yes please, its driving me mildly insane to have to always type "is:question" on all my queries.
    – Rachel
    Commented Jan 15, 2013 at 18:44
  • Totally. This is irritating. Results from a single question should be -by default- coalesced.
    – leonbloy
    Commented Jan 16, 2013 at 20:56
  • 4
    I disagree. When I'm searching for a solution to a problem, it's common that the asker hasn't reached the same point in his investigation, or isn't using the same terminology, so the keywords I'm searching for might appear in the answer but not in the question. I want to search both types of posts more often than questions alone. It would be nice to make questions and answers more visually distinct, and have a button on the search result page to restrict to questions or answers, but don't make questions only the default. Commented Jan 25, 2013 at 19:53
  • 1
    @Gilles I can get behind a better visual distinction between answers and questions. Looks like they may already be working on something to that end from what I've seen recently.
    – Sean Quinn
    Commented Jan 27, 2013 at 17:43
  • I sure wish I could bounty an answer, I'm getting tired of typeing is:question also. Commented Jan 28, 2013 at 14:07
  • Just type is:q. It doesn't completely solve the problem, but it makes it much less annoying.
    – Laurel
    Commented Jun 7, 2016 at 2:23

Not sure if excluding terms was ever a feature of the Lucene.net search.

duplicate -duplicate

Was expecting the search to cancel itself out and return nothing.

  • We never did exclusions really, but I think with some parser adjustments we can do them well...I'll try and implement my ideas tomorrow. Commented Dec 26, 2012 at 23:11
  • 6
    A new build has been deployed, -term and -"quoted phrase" should both work well now...let me know if you find craziness with either. Commented Dec 27, 2012 at 12:00

Can we get comment search? An operator along the lines of is:comment would be perfect. Since we have direct links to comments, and obviously, the rendered comment text, it would be a very helpful tool.

Granted, it could expand the index a lot (and the indexing might have to work differently because we can hard delete comments from the system), but it would be really useful.

Case in point, this feature-request from this morning (at the time of this posting), as well as this feature request as well as the desire to have that from one of the founders of Stack Overflow.

  • 4
    Especially in meta, where are lot of the discussion takes place in comments, I think this'd be a useful addition.
    – Matt
    Commented Jan 7, 2013 at 14:58
  • 2
    The search index literally grabs posts right out of the DB (we don't crawl the HTML)...so yes, it's a completely different indexing path. That being said, yes the new search was designed with more things like comments in mind and were on my TODO list. Unless there's reason for not doing so brought up in our weekly meeting today, I'll probably get to it after NY is back up and running. Commented Jan 7, 2013 at 15:18
  • @NickCraver Excellent! Great to hear, thank you.
    – casperOne
    Commented Jan 7, 2013 at 15:24
  • @NickCraver did this ever get done? Commented Dec 29, 2021 at 14:22

It seems new search can't handle can't:

enter image description here

enter image description here

Can't doesn't stem properly to "cant" which the search box seems to truncate it to.

  • 1
    However: quoting (as in "a sentence") works fine. Same for other single-quotes, like in "don't", it seems.
    – Arjan
    Commented Jan 10, 2013 at 20:30
  • 1
    The can't case will be fixed in the next deploy, this was an error in the parsing layer I didn't notice at first...results are much better with all contractions after the next build (likely in the morning). Commented Mar 1, 2013 at 1:41

It's not good. Not good at all.

First of all, how can I use the old search engine? I tried search and search-old. I was of course looking to make a comparison for my answer, but I'm also contemplating of going back permanently. Heck, I'll even pay. At least Google offers a (near-permanent) choice when they change the Compose in GMail or the Developer Console in Google Play.

There's two parts to this sentiment:

Replacing the engine in the background:

I had no quibble with the old search engine whatsoever. No performance issues, no problem waiting or trying again, and I didn't really need any of the new features that were added.

The only problem I would expect with a new engine is that it does not bring up as many relevant search results. And indeed it doesn't. Searching for "android action bar custom box" gives only 5 results, 2 of which aren't tagged with android (this is a plus for the new engine perhaps, but is it not better to incorporate it into a bot that fixes posts?). None of the results are tagged with android-actionbar. Maybe they are on topic (actually not), but isn't a untagged question usually of less quality?

I have the feeling the old engine would at least give me many more results that were then only based on a part of my keywords. As a user, I would realize this and "recognize" a virtual line where the old engine gave up on my full relevant query and just added far-fetched stuff. This would actually help because sometimes browsing through this last bit would turn up useful insights or just weirdly keyworded questions that were still popular for exotic search queries. So it's a plus for the old engine.

The hard part of searching on SO for me has always been spearheading through to the really related questions. Android's APIs use a lot of common words as terminology. Take the words "action views" for instance. Both are incredibly common. Yet for Android they very specifically refer to Action Views, which all in all might only encompass 20 to 50 questions. Adding "android" wouldn't help because there are a gazillion Android questions that still contain common words. If the new engine allows a wider search, then this isn't helping at all.

Of course, SE might have had good reasons (server performance), and in that case it's a very valid point.

Changing the search UI:

But then it is completely incomprehensible why you, SE, would change your successful search interface. It sounds like Apple maps. Look at the screenshots in Tim Yi Jiang's answer.

Of the old engine I mostly remember that it was somewhat restricted in width, a bit greyish perhaps, but also that there were A LOT of color hints that subconsciously told me something about the question.

Same thing with the avatars. Isn't the point of having them instant recognizability? Then why not show them in search? I know some people that, when they ask a question, you can damn well be sure it was a question needing to be asked (to the point of being yet another bug in Android).

And then there is the issue of text blocks. All I see now is basically two blocks of text (one title, one garbled question with random bold words). Basically, I've found that I'm psychologically blind for the way they are represented now. I also have the feeling the question text part shown below the title is slightly longer than before. Not helping.

I think it was a mistake to abruptly change the search UI and combine it with the engine change.

Sorry, I realize this is not what you want to hear, but it's just my truth.

  • 9
    Am certainly not missing the gravatars at all when searching. Eyes can scan text faster without having that blocking
    – random
    Commented Jan 6, 2013 at 22:17
  • 2
    Google lets you resist the pull of some UI changes for a long time, but there's no rolling back when they update their search algorithm.
    – Shog9
    Commented Jan 8, 2013 at 3:09
  • Yeah, that's true.
    – pjv
    Commented Jan 8, 2013 at 21:01

I didn't think I'd miss the old "ninja" page, but turns out there was one thing I got so used to doing I didn't really even think about it anymore: using the handy custom search boxes there for Google, Bing, and DuckDuckGo.

(By which, of course, I mean Google)

It's not really that much more effort to type " site:stackoverflow.com", but it is somewhat more effort - and it fails to provide the visceral satisfaction that clearing out the search box and hammering the enter key to reach that ninja page did when results fail to meet my needs did.


Search's stemming seems to be a bit wonky. I searched for "ads" on Arqade Meta (to find what we used to tag questions that were about the Community Promotion Ads but were not said threads), and while I did get results for ad and ads, I also got results for "added", "adding", and other permutations of addition that have nothing to do with advertisement. This... makes no sense, really.

  • I have seen "ad" misspelled as "add" so many times that this in fact makes a lot of sense to me (although that's of course not the reason; rather it's an alogrithmic stemmer that doesn't actually know these things).
    – balpha StaffMod
    Commented Jan 9, 2013 at 17:08

I searched for "dont jsfiddle" on meta in an attempt to find this answer, however the only result I got was:

enter image description here

In comparison, Google showed many more results. Even searching for the exact phrase "don't just include a link to jsFiddle" still doesn't show the result.

The search term is included in a blockquote; not sure if that had anything to do with it?

  • Well, after this answer it now has two results! I will be taking a look though, thanks for the report. Commented Jan 5, 2013 at 12:43
  • 4
    I've found the issue, and it's the term split on this example between titles and bodies, with the and not traversing the two. I'll take a look at query construction and see what I can do, likely Monday. Commented Jan 6, 2013 at 1:21
  • 1
    @Nick: Was there a particular "Monday" you had in mind when posting the above comment, or are we talking generally here? ;)
    – Matt
    Commented Mar 7, 2013 at 20:18
  • 1
    @Matt meta.stackoverflow.com/search?q=don%27t+jsfiddle and the phrase works as well Commented Mar 7, 2013 at 21:13
  • @NickCraver: Mmm, that teach me to check before being (lightheartedly) sarcastic ;). I definitely checked this a while ago, and it hadn't been fixed then :P.
    – Matt
    Commented Mar 7, 2013 at 21:15

UPDATE: This feature has been implemented now :-)

Can we please add OR option in tag search box?

Let me explain: If I want to search questions tagged [sql] or [mysql], then I can search like this: https://stackoverflow.com/questions/tagged/sql+or+mysql

We can search for multiple tags (using AND method) like this [sql] [mysql] score:10. But we can't do it with OR operator: [sql] or [mysql] score:10

Is this feature exists? If yes: How can I achieve? If no: Can we implement this? PLEASE....

You can see the problem here.

  • Wish this can be done in normal search terms colors image is different from colours image . Implementation could be [colours OR colors] image. What do you say?
    – anki
    Commented Oct 18, 2019 at 17:28

Could it be that when using non-phrase searches, the stop word removal is quite aggressive?

Searching for what is a codec returns the relevant question only at a poor position 9—even out of the visible scroll area.

Why it should have been ranked better:

  • The title of the relevant question is "What is a Codec (e.g. DivX?), and how does it differ …". There's a literal match for "What is a codec" at the beginning.

  • It's the only question with a high score of 27, compared to the others. The combined score with all answers is 74.

  • The first result has a score of -2. Meh?

It seems the reason for the bad ranking is that the stop words "is" and "a" are removed, but shouldn't these be considered a little more important on Q&A sites than in a normal document-based search engine? I expect users to put a lot of actual questions into the search box.

At least I thought the question I was looking for would be ranked much better if there was a literal match.

Maybe the solution to this would also be to put more weight on the titles and score. But I don't know what consequences this would have.

  • 2
    Titles generally aren't good enough (overall) to weight them. The stop word piece is tricky, because it totally depends on the context as to whether they are useful, it's a 50/50 split on useful vs worse last time we dropped stop words. In the AND case it would often leave off results that didn't contain a stop word, when it wasn't specifically relevant...so an insignificant word caused the best result to not appear at all, rather than not being at the top. It's tricky no doubt, the current hope is it's an improvement over the old search...but we're by no means done making search better. Commented Jan 4, 2013 at 22:40
  • 1
    Thanks for the comment. In fact with the old search I couldn't even find the question if I hadn't used the title filter, so it's definitely an improvement in that regard. Good job nonetheless!
    – slhck
    Commented Jan 4, 2013 at 22:55

I'm disappointed that the number of views for each question no longer shows up in the search results. Seeing how many other people had read the results for a particular query gave me an immediate sense of the size of the community that was interested in the related topics. Although number of votes obviously serves as a proxy for this kind of information, it is a much more indirect measure.

Perhaps more importantly, the display of question views did not make the old-style search results any more difficult to comprehend at a glance. Even if the use cases are not relevant to you personally, the more information that you can expose in the search results (without making them any more confusing or difficult to comprehend) the more useful they're going to be to the site's users. It was the collection and thoughtful exposure of this kind of information that really set Stack Overflow apart from the more generic coding forums in the first place.

  • 4
    If we showed views, they wouldn't be accurate for a variety of technical reasons. At the very least, they'd have to be accurate for them to be displayed (they could be wildly off right now). The second piece of that is they have to be useful, and the vast majority of the time they aren't. You're asking for information that clutters up the UI for all, for the few that use it...we have to weigh those trade-offs when deciding what to display. I'm not saying this is set in stone, but we have several technical hurdles in the way of this currently - with solutions coming as time allows. Commented Jan 6, 2013 at 1:11

In a post from last year (now deleted) when you had upgraded the search system you had got rid of the infavorites: search operator. There is still a feature-request out there for that marked .

Will you be able to re-implement that operator with the new elasticsearch engine?

  • 2
    It's actually in there now, I'll mark it as [status-completed]. It works as infavorites:mine and infavorites:<userid>. I just forgot to add it to the advanced search help...will get that in tomorrow. Commented Jan 6, 2013 at 22:17
  • 1
    You might want to change that to infavorites:me to match the existing self syntax. Commented Jan 6, 2013 at 22:17
  • It just doesn't read well at all, so we went with "mine"...that being said we'll advertise "mine" but make "me" work as well. The same is true for booleans, "yes" and "no" also work in addition to 1/0. Commented Jan 6, 2013 at 22:19
  • So will mine work whereever me did before? Commented Jan 6, 2013 at 22:19
  • 1
    Yeah sure, why not - no need in having them differ. Commented Jan 6, 2013 at 22:20
  • Great, I really like consistency in a user-interface. Commented Jan 6, 2013 at 22:21
  • I see two separate requests in your question...what's in the engine is the old infavorites: which is your favorite questions, not tags. We may add tags later but that's not in at the moment (I'll have to performance test such a change, tags would be much more expensive by nature of how it'd have to work). Commented Jan 6, 2013 at 22:27
  • @Nick, You're right I got confused, let me know how the in mytags thing goes. Commented Jan 6, 2013 at 22:28

Here's a weird one from UX: Bug in the search engine — Why does the search engine fail to find the page?

User was looking for Name or data on this error alert phenomenon? and was unable to find it with the search terms name alert (I can't find it either, out of only 17 results!). Not sure if it's because the words are in the title or what, but it seems like that Q should be a prime result for that Q


Possible bug:

I don't know if this was intentional or not, but I was searching for a question I had read earlier in the day with the title: How to debug System.StackOverflowException without link to source code?.

I tried a few searches and would sort by newest, since it had been created that morning and couldn't find it. The searches were StackOverflowException, StackOverflowException source code, and probably a few others.

The problem is that the analyzer is treating a . within words as part of the token, instead of treating it as a word boundary. A search for System.StackOverflowException makes it the top result when you sort by newest question.

Feature suggestion:

I found out that my first mistake was trying to only search for StackOverflow and not StackOverflowException, which made me think of this idea. It seems to be something that many search engines do when analyzing the text for indexing.

It could be nice to tokenize camelcased words both as the original word, (ie StackOverflowException) and each subword (stack, overflow and exception). To help even out searches, you could apply a fractional boost to the subwords so that those hits don't easily outscore documents that hit on the original, unaltered search term.

  • It seems you were quoting the search term, right? That meanwhile was also reported as a standalone post: Don't exclude results because of quoted punctuation. (So, not embedding it in quotes should not get you the above issue.)
    – Arjan
    Commented Jan 27, 2013 at 7:19
  • @Arjan - I tried both. I'm quite familiar with how Lucene works, so it was sort of an instinct to try it both ways. -- same results. I'm unsure if the problem still happens now. Unfortunately, my example no longer works because the StackOverflowException term now his on the answer (unsure if it's hitting on the question at this point, yet) Commented Jan 27, 2013 at 7:59
  • You might have run into the problem of the post itself also having quotes around the error message... (I added some examples to the bug report I linked above.)
    – Arjan
    Commented Jan 27, 2013 at 9:00
  • @Arjan - Sadly, that is not the case either. Actually, in your picture you've linked on the left in your answer to that question, you can see the question I'm referring two, as the third result. Notice the title has no quotes, while the body does have the single quotes. Commented Jan 27, 2013 at 9:56

I was trying to find this post; How about a "Vote not to close" option to counter the "Vote to close"? by searching for "vote not to close".

However, the result does not show up anywhere on the first page; even though it was a direct phrase match.

Now of course, I could have searched for an exact phrase, but at the time of searching, I didn't know I was searching using an exact phrase.

Also, the "best" result (IMO) in the exact phrase search is superseeded by a shoddy 2 vote answer on an irrelevant question.

  • 1
    ... is there any particular reason for the -1?
    – Matt
    Commented Mar 19, 2013 at 11:52
  • 1
    Matt, I guess -1 was given by someone who didn't bother to read what was clearly stated in the question: "We look forward to the feedback."
    – gnat
    Commented Mar 19, 2013 at 13:11

Code searches are better.

The new way picks up things that have a different case (expected) and picks up things that the old way failed to pick things that it should have that were in code block like

And since it's not case sensitive it doesn't have this issue.

  • Thanks, code search will work properly in the next build - though I'll need to pull the indexes down to fix deleted owners showing up in results over the weekend. Commented Dec 28, 2012 at 23:15
  • The new build went out last night, the code:"GetType" search now finds 373 results, all inside code blocks. Commented Dec 29, 2012 at 9:57
  • Nice it looks good Commented Dec 29, 2012 at 17:16

Most likely by design, but just to be sure: search result summaries for preformatted code blocks are rendered without their newlines. That might look funny, but maybe only when code has been abused for formatting:


Let me show another example:

When I use the new search with the query "Theme.Holo.Dialog on DialogFragment" I get two very mediocre results.

When I use the same query on Google, I get many more results, including from SO. And what's more, the third result is almost what I was looking for, and IT'S FROM SO!

So how come I'm not getting these great search results anymore?

  • 1
    The Google result doesn't have "Theme.Holo.Dialog", but rather "Theme.Holo.Light.Dialog". Basically Google treats a search for x.y.z similarly to a search for x y z whereas here it's kept as one word (which makes sense to me but will indeed limit results).
    – user154510
    Commented Jan 9, 2013 at 17:35
  • Isn't that the basic idea of a good search? That it doesn't try to literally take your search query and match it, but also tries to find similar matches? Anyway, if anyone could show me what the old engine would've given me, maybe I could let this rest.
    – pjv
    Commented Jan 10, 2013 at 17:29
  • 2
    @pjv - the old engine doesn't find it either. That's not say we don't care...I'm collecting these examples and seeing what we can do to improve the search all around. Search is by no means final, we'll continue to improve the results as time allows. I've been quiet here because we're about to move over half our servers and there's a lot of prep to do...we are listening though! Commented Jan 11, 2013 at 14:21
  • Thanks for the signal.
    – pjv
    Commented Jan 11, 2013 at 21:58

What needs work: "What you tell us is broken ..."

When searching all sites at our main site, for example: "number of search results per page", it returns four results per page; and in the case of that search it says: "About 86,100 results (0.38 seconds)".

Google has a 'User Settings' but it would be OK if the choice of "Results Per Page" was on the first returned search page. I could handle more than 4 results per page, why so few; even 10-20 would be much better. The default is too low.

For example, Google has this: Google's "Results Per Page" Setting

On mobile you have to zoom in to tap on one of the tiny numbers [1 2 3 4 ...] to advance to the next page, there's not even a [Prev][Next] link.

For example, Google has this:

    « Prev  1   2   3   4   5   Next »

Thanks for considering this request.


It seems that there is inconsistency with how the questions and answers are displayed in the search results - sometimes you see the Q:, sometimes not. I don't see any reason why some of the results are missing the question text, which is the main thing I look for when scanning the results.

For example, searching SO for "C# automatic type inference" includes this selection of questions below - why is the question text only included on the first two?

enter image description here

  • The new search returns both answers and questions. The second two here matched on the answers, but not on the question
    – random
    Commented Jan 18, 2013 at 22:10
  • @random - interesting, I didn't catch that it was strictly a Q: or an A: and never both. I'd still rather see the question text in the results, though, not just the answers... though I wonder if that's because that's what I'm used to with the old search results, or because I truly prefer looking at the original person's question when trying to determine if the matching result is similar to the issue I'm experiencing. I honestly don't know.
    – Derek
    Commented Jan 18, 2013 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .