You can keep ready alphabetic lists of the words that occur in webpages you have cached. Google will not accidentally have renamed itself "Alphabet", in August of 2015 (see Investopedia editorial). Each of those words may get assigned the URLs of the webpages it has been found on, as a ranked list of labels to be used in calculations for the output. Once you have such lists, you can handle search words with some dexterity, concerning their respective coordinates. Google states that it uses a search index, on Google.com. When you search a fantasy expression that hardly or not at all occurs in their cached pages, the company tends to display results for a more common word which runs similar.
Of course, in an alphabetic list with a billion entries, you do not have to search through all of the entries occurring earlier in the alphabet than the word you look for. The first letter of the search term "grapefruit" will immediately lead you into a directory of words beginning with a "G". The second letter of the search term will be assigned to a relevance for the question where to go then - here, to "R" -, and so on. That means you only will have to carry out 10 simple series of switching procedures, for the ten letters of the word. After this, you have to manage one further such operation depending on the question how many results the user wants to be shown. If the user wants ten results, there will go a command to a dataset to the effect that all results found (for "grapefruit") until no. 10 have to be displayed. This is altogether 11 primitive operations, until now. The simplicity of such a search has been implied, in the beginning of the question.
One way to get farther, from here, would be to simply save whole groups of words, as if they were one word. Paying attention to whitespace characters, you could save, from the text "Google is a big Internet company with a search engine many do not understand":
- "Google is a big Internet company",
- "is a big Internet company with",
- "a big Internet company with a",
- "big Internet company with a search",
- "Internet company with a search engine",
- "company with a search engine many",
- "with a search engine many do",
- "a search engine many do not",
- "search engine many do not understand".
etc. Even such a multiplied text, as compared with images, requires little memory space. Proceeding this way, you could access each one of the saved snippets just as quickly as a single word, like described above. Who looks for only one of the search terms occurring in a series of such strings can be led to the string beginning with his keyword. More difficult it would become when the user inputs the parts of such a string, in a different succession. Then you could, for example, try to note cases in which hits for the several words occur on one and the same page. Or you assign a label, to every word, and search for any possible succession in that you may have stored such labels. E.g., after you have assigned the labels U, V, W, X, Y, and Z, to the words "is a big Internet company with", a user might search "with a big company, Internet is". Such an input would be translated into ZVWYXU and would automatically be tried out, in your alphabetic list, also for all the other possible successions of its parts.
Complete, ranked lists of URLs for any word encountered while crawling the web should constitute an insignificant expenditure. They might comprise just labels for all of the crawled pages, multiplied by much less than the number of different words encountered. Common words range into just a few thousand, for any language. At the same time, they, and even more the seldom ones, do by far not occur on every crawled page. Again considering how little memory space sheer text uses up, such lists, hence, would certainly constitute a minuscule investment, for Google. They'd require perhaps a few hundred bytes of additional memory, per saved page: about as many bytes as there are words, on the page. At least as long as for each word occurring on a page, the page would be included in just one list. A more expensive task might be the web crawling.
When a second word is added by the user, you then might want to build up a connection from the list for your first search term to such a list for the second. You might establish an additional list of URLs, as such, and make sure that only URLs are displayed which get a permission from both of the search terms. If this does not generate enough content for a result page with highly ranked hits, any more, you can extend your search to less highly ranked pages. On Howstuffworks - How Google Works - The Google Search Engine, we are told that Google ranks its results by the "frequency and location of keywords within the Web page", by the degree to which a page has an "established history", and by the number and prominence of links leading to the page. We should note that Jonathan Strickland and John Donovan in this source are adding: "Out of these three factors, the third is the most important." This implies that pages with an interesting frequency and location of keywords will often be ignored, in favor of pages that are prominent for other reasons! I.e., the actual mathematical analysis of the pages should not be overestimated. It quickly can lose its impact. Such a ranking independent of a more elaborate mathematical analysis enables you to display dozens of results after only having searched through a limited number of pages, and still to maintain that you have treated all pages equally.
With less common search terms, a key to the feasibility of a Google output - often so surprising by its quality - that begins to become fruitful is the uniqueness of rare words. The multitude of languages and of rarer expressions ensures that a list for one word will stay comparatively short. Comparing short lists with each other requires a low amount of computational power. Most of us will be familiar with the situation that you get unwanted, popular results from the world of sports etc., when you search for a person with a common name. That are cases in which Google fails, in which the feasibility we here try to explain is not at all achieved. You need an unusual search term, in such cases, and if you do not find one, you'll often simply give up. On the other hand, the number of junk hits can decrease palpably with a growth of the number of your search terms, even when these terms are still fairly common. The probability of some arbitrary combination will turn out much smaller than with the numbers used in lotteries, because there are more units (thousands of words instead of dozens of numbers) to be selected from. For a keyword missing on a page, the one looking for words rather than for numbers can screen the beginnings of alphabetic labels for URLs, in a list of pages containing the word, quite superficially, to figure out that the word isn't connected with a certain page he has an other hit on. Even if you still want to show such a page with the word missing, you, after all, thus can skip an analysis of where the missing word would have been, on the page. This advantage then especially gains power - for the one who does not want to be shown just some prominent pages of whatever content - in searches for the less common words and names, which you may fear Google will have prepared little output for. You do not have to store very much, and neither do you have to crawl very much, in such cases. Lists will be short. It's like with telephone numbers in a small village. Dialing takes shorter, because there are few citizens. You might acquire results economically, although the pages are of a low rank.
Yes, for common search terms, you can argue that a page may contain 500 words, on average, and that the one who wants to compare so big pages will have to calculate, quite a bit. But you do not need to calculate the exact degree to that catchwords come close to each other, on every page, as long as you also have other variables. That's a major trick, in any statistic operation. Statistics can only simplify, and as long as you simplify uniformly, you're on a sterling path. Once your computational power comes to a limit, you can assign more importance to simpler aspects of your page-ranking algorithm and by that exclude a part of the candidate pages. You can estimate how many hits exist, and notify the user of this number, but only crawl into a few hundred pages.
To precompute an output on combinations of a bigger number of search terms, you might begin with, say, comparing lists of URLs for the 1,000 most common words with each other. That may require a trillion to the second of calculations, if you screen a billion pages, but it's well imaginable, especially if you focus on, say, the 800 highest-ranking pages your algorithm for each of the words in these comparisons demands to be allowed. You have to carry out simple computations, like with the direct distance dialing of the telephone. Rather sooner than later, you'll find something, among your ranked pages. And the problem does not grow more complicated, when it comes to the less common terms, although you in this realm will not have so lush a cushion of prominent pages. Also for any of the few million or so of expressions less often used, you'll possess your ranked lists which you can treat in the same way, while these lists will become ever shorter. It's a complex thing, but I do not really see where the insurmountable hurdle regarding current computational power should be. The number of URLs to be incorporated will shrink, with each additional search term. You may search only those pages for search term 2 which make up a list of pages containing search term 1, to prepare a set of pages affording a particular combination of words. If you have a million pages with the first search term, among a billion pages altogether searched, and your search term 2 occurs in another, arbitrary selection of a million of those one billion pages, you'll now already only have one thousand pages left containing both search term 1 and search term 2. Proceeding like that also with search term 3, you'll on average end up with only one hit, and after handling search term 4 alike, with none at all. As soon as you have no hit at all, any more, for an URL from such a list, concerning such a list of URLs for another search term, you are entitled to state that you haven't ferreted out a result. Such an event will happen quickly if you search for an unusual combination like, say, "scholastic marble cirrus bumper" (without quotation marks, 8 Google hits, today, concerning which on average more than two of the keywords have been crossed out). And of course, the user understands that you are magnanimous if you show to him anything, in spite of such a failure.
Now you are not dealing with 10 or 11 switching procedures, any more, but zeros begin to add up when you have to multiply 10,000 by 10,000 to obtain 100,000,000, for all combinations of the words in a small dictionary, or if you multiply 100,000 by 100,000, to obtain 10,000,000,000. That sort of necessity will have to do with the following statement on Howstuffworks - How Google Works - Google Company Culture: "Google cheekily calls its Bay Area campus the Googleplex, a combination of the words 'Google' and 'complex' and a play on the term googolplex: the numeral 1 followed by a googol of zeroes." However, 10,000,000,000 entries on where to go when a user inputs things like, say, the "telephone number" 3677 (for "grapefruit") + the additional telephone number 1243 (for "juice") do not require much room, any more, today. You can prepare, say, a few hundred results for every single one of such a quantity of 10,000,000,000 combinations of words, and store the resulting, say, five trillion links in a portion of hardware filling a suitcase. That sort of a suitcase might amaze you by how small it already looks, today, enabling you to house many thousands of its type, in one building. According to Howstuffworks - How Google Works - Google Data Centers, estimates on the number of servers Google uses "range as high as 2.5 million machines" (May 2019). The user will not mind if you have prepared the same number of results for a more common than for a less common query - he anyway uses to view only the first few result pages.
Against the background of such a scenario, a thorough customization indeed would have to appear as difficult. It would seem that you'd have to re-calculate all that so thoroughly prepared material, from the beginning, based on an adjusted ranking of the pages. It certainly would require little memory space, though, to keep track of pages a user has already visited, and to display hits on such pages a little higher, among the results. You also can assign a set of parameters to every page concerning the categories of its contents. A user's browsing behavior then can be made into an own set of such parameters for him. Among a limited number of hits for a query, those with the highest similarity, concerning such parameters, to the preferences of the user can be displayed prominently.
