This behaviour is essential. Especially in German we tend to connect nouns which make words long. To find the correct page we have to completely write that loooong word...

Making partial search possible, you should consider to implement another concept to boost finding.
Did you realize that when you type a word fragment and hit space and enter another word fragment that your number of results gets larger instead of smaller? You are using OR-matches for multiple search inputs.

The idea is the following:

• users use in general letters, numbers and spaces for inputting search terms.
• assumption: whenever spaces are used, users enter multiple fragments for a search term. All content is irrelevant for search when both fragments are not part of title or content.
• the user input (while live typing) should be split by spaces " " and what is left will be used as AND-matching search with partial words.
• example: page with title "whatthehellsuchalongword in this page makes searching hard" can easily be found with entering
  • "wha long" (creating title="wha" AND title="long") or ## your editor doesn't allow to wrap words in asterix as search engines would use) ##
  • "hell pa sear" (creating title="hell" AND title="pa" AND title="sear") ...
• the beauty is: it is the fastest way to find as the AND clause will reduce the number of results. The more spaces users use in the search field, the more they know it's to be found in the page or the page title.

You will have an outstanding search by reducing the number of matches by AND-clauses rather than sorting all possible matches by ranking of search results and by keeping the full list of all potential matches
Try both combined and you will be blasted. And it will fit the stated needs of all comments here...

My hints for you:

• make searching with partial words and AND clauses your standard and leave the rest of the search unchanged.
• Add a selector in your quicksearch to use OR clause when desired but it shouldn't be necessary. (The more spaces used in the search field, the shorter the result list should be - down to 1 entry which is the most probable match. If that doesn't solve then a switch to partial matches with OR should do the rest as then you deliver the current infinite long result lists.

There is one thing: You seem to have forgotten that wiki's context search is the most powerful search available. With your current search implementation you morphed your wiki to a file storage system search. Think wiki!

https://www.getoutline.com/compare/confluence-alternative

Every time i search for a feature that should be obvious in Jira/JSD/Confluence, the ticket has been open for years. 

We wasted so much time today searching for documents because it wouldn't find partial words. 

We are looking for alternatives. 

Our support and QC team is using Onenote for release documentation internally and not only is that tool finding partial words, it's finding partial words from OCR'd document text. 

And it's free, included in our MS license. 

I'm sure there's an issue here. When I click on "Search tips" from the search results thing it takes me to this page which states:

Results will appear as you type — you don't need to hit enter.

Now, we have a page that contains licence details, however, if I start typing in the box:

1. at "l" I see a load of matches from both Confluence settings and our content
2. at "li" there are Confluence settings matches, and a few content matches, but NOT the content I'm looking for
3. by "lic" I can see only 3 Confluence Aministration settings; "License Details", "Application Links" and "Application Navigator"
4. when I get as far as "licen", only the "License Details" item is shown
5. by "licenc", it's showing We couldn't find anything matching "licenc".

However, if I complete the word "licence" (note English, not American English, usage of "c" vs "s", noun vs verb), I get a load of results including the one I'm interested in (not shown here due to confidentiality).

There is, therefore, an issue with the expectations of users. Either Confluence should NOT show the results as you type, or it SHOULD show the results as you type consistently.

Note that I have rebuilt the index, both "normal" and "from scratch" and it has made no difference to this behaviour.

Wildcard searches using * and ? don't help the average user, most people expect to be able to search Confluence in a similar way to a search from a web browser. We have over 130 employees, I won't be asking them to use * and ? in searches, Confluence search should be powerful enough without having to include wildcards. 

I came across this Jira issue because I couldn't find what I wanted either. Thought I'd paste this here for those whom it may also help. Partial searches can use a wildcard, *, to find what you need. It seems to work in my version of Confluence 7.11.0 Server.

https://confluence.atlassian.com/conf711/confluence-search-syntax-1044782023.html

@Atlassian:

In my terms this is not an "improvement request", it is a "bug". Can you please change this?

We are having this issue with the cloud version. Is is a huge issue - and stopped our firm intention to use Confluence as Knowledge Base. This is a very important feature for us - with this issue, we will get zero user acceptance.

For what it's worth, is this something specific to all confluence versions? I just upgraded to Confluence 7 and got bit by this, but by old install of Confluence 5.9.7 worked perfectly fine without wildcard searching... searching `phone` resulted in articles with `Telephone`, just fine.

I can just agree - my team is on the way to get rid of Confluence again - we started it 2 Years ago, and now some ppl left and noone cant really find important stuff.