Examples of valid queries that use advanced operators include these:

In this example, we tried to give Google an invalid option to the as_qdr variable in the URL. (The correct syntax would be as_qdr = m3, as we’ll see later.) Google’s search result page listed right at the top that there was some sort of problem. These messages are often the key to unraveling errors in either your query string or your URL, so keep an eye on the top of the results page. We’ve found that it’s easy to overlook this spot on the results page, since we normally scroll past it to get down to the results.

Sometimes, however, Google is less helpful, returning a blank results page with no error text, as shown in Figure 2.2.

As shown in Figure 2.3, the title of the Web page is “Syngress Publishing.” It is important to realize that some Web browsers will insert text into the title of a Web page, under certain circumstances.

This time, the title of the page is prepended with the word “Loading” and quotation marks, which were inserted by the Safari browser. When using intitle, be sure to consider what text is actually from the title and which text might have been inserted by the browser.

Title text is not limited, however, to the TITLE HTML tag. A Web page’s document can be generated in any number of ways, and in some cases, a Web page might not even have a title at all. The thing to remember is that the title is the text that appears at the top of the Web page, and you can use “intitle” to locate text in that spot.

When using “intitle”, it’s important that you pay special attention to the syntax of the search string, since the word or phrase following the word “intitle” is considered the search phrase. “Allintitle” breaks this rule. “Allintitle” tells Google that every single word or phrase that follows is to be found in the title of the page. For example, we just looked at the intitle:“index of”“backup files” query as an example of an “intitle” search. In this query, the term “backup files” is found not in the title of the second hit but rather in the text of the document, as shown in Figure 2.4.

If we were to modify this query to allintitle:”index of”“backup files” we would get a different response from Google, as shown in Figure 2.5.

Now, every hit contains both “index of” and “backup files” in the title of each hit. Notice also that the “allintitle” search is also more restrictive, returning only a fraction of the results as the “intitle” search.

Be wary of using the “allintitle” operator. It tends to be clumsy when it’s used with other advanced operators and tends to break the query entirely, causing it to return no results. It’s better to go overboard and use a bunch of “intitle” operators in a query rather than using “allintitle operators.”

For this reason, the allintext operator should not be mixed with other advanced operators.

First, let’s talk about what a URL is. Short for Uniform Resource Locator, a URL is simply the address of a Web page. The beginning of a URL consists of a protocol, followed by ://, like the very common http:// or ftp://. Following the protocol is an address followed by a pathname, all separated by forward slashes (/). Following the pathname comes an optional filename. A common basic URL, like http://www.uriah.com/apple-qt/1984.html, can be seen as several different components. The protocol, http, indicates that this is basically a Web server. The server is located at www.uriah.com, and the requested file, 1984.html, is found in the /apple-qt directory on the server. As we saw in the previous chapter, a Google search can be conveyed as a URL, which can look something like http://www.google.com/search?q=ihackstuff.

We’ve discussed the protocol, server, directory, and file pieces of the URL, but that last part of our example URL, ?q = ihackstuff, bears a bit more examination. Explained simply, this is a list of parameters that are being passed into the “search” program or file. Without going into much more detail, simply understand that all this “stuff ” is considered to be part of the URL, which Google can be instructed to search with the inurl and allinurl operators.

So far this doesn’t seem much more complex than dealing with the intitle operator, but there are a few complications. First, Google can’t effectively search the protocol portion of the URL – http://, for example. Second, there are a ton of special characters sprinkled around the URL, which Google also has trouble weeding through. Attempting to specifically include these special characters in a search could cause unexpected results and might limit your search in undesired ways. Third, and most important, other advanced operators (site and filetype, for example) can search more specific places inside the URL even better than inurl can. These factors make inurl much trickier to use effectively than an intitle search, which is very simple by comparison. Regardless, inurl is one of the most indispensable operators for advanced Google users; we’ll see it used extensively throughout this book.

As with the intitle operator, inurl has a companion operator, known as allinurl. Consider the inurl search results page shown in Figure 2.6.

This search located the word admin in the URL of the document and the word index anywhere in the document, returning more than two million results. Replacing the intitle search with an allintitle search, we receive the results page shown in Figure 2.7.

This time, Google was instructed to find the words admin and index only in the URL of the document, resulting in about a million less hits. Just like the allintitle search, allinurl tells Google that every single word or phrase that follows is to be found only in the URL of the page. And just like allintitle, allinurl does not play very well with other queries. If you need to find several words or phrases in a URL, it’s better to supply several inurl queries than to succumb to the rather unfriendly allinurl conventions.

Notice that the first two results are from www.blackhat.com and japan.blackhat.com. Both of these servers end in blackhat.com and are valid results of our query.

Like many of Google’s advanced operators, site can be used in interesting ways. Take, for example, a query for site:r, the results of which are shown in Figure 2.9.

Look very closely at the results of the query and you’ll discover that the URL for the first returned result looks a bit odd. Truth be told, this result is odd. Google (and the Internet at large) reads server names (really domain names) from right to left, not from left to right. So a Google query for site:r can never return valid results because there is no .r domain name. So why does Google return results? It’s hard to be certain, but one thing’s for sure: these oddball searches and their associated responses are very interesting to advanced search engine users and fuel the fire for further exploration.

The site operator can be easily combined with other searches and operators, as we’ll see later in this chapter.

So much has changed in the ten plus years since this process was run for the first edition of this book. Just look at how many more hits Google is reporting! The jump in hits is staggering. If you’re unfamiliar with some of these extensions, check out www.filext.com, a great resource for getting detailed information about file extensions, what they are, and what programs they are associated with.

Google converts every document it searches to either HTML or text for online viewing. You can see that Google has searched and converted a file by looking at the results page shown in Figure 2.10.

Notice that the first result lists [DOC] before the title of the document and a file format of MicrosoftWord. This indicates that Google recognized the file as a Microsoft Word document. In addition, Google has provided a View as HTML link that, when clicked, will display an HTML approximation of the file, as shown in Figure 2.11.

When you click the link for a document that Google has converted, a header is displayed at the top of the page, indicating that you are viewing the HTML version of the page. A link to the original file is also provided. If you think this looks similar to the cached view of a page, you’re right. This is the cached version of the original page, converted to HTML.

Although these are great features, Google isn’t perfect. Keep these things in mind:

This operator flakes out when ORed. As an example, the query filetype:doc returns 39 million results. The query filetype:pdf returns 255 million results. The query (filetype:doc | filetype:pdf) returns 335 million results, which is pretty close to the two individual search results combined. However, when you start adding to this precocious combination with things like (filetype:doc | filetpye:pdf) (doc | pdf), Google flakes out and returns 441 million results: even more than the original, broader query. I’ve found that Boolean logic applied to this operator is usually flaky, so beware when you start tinkering.

This operator can be mixed with other operators and search terms.

Each of the search results shown in Figure 2.12 contains HTML links to the http://www.defcon.org Web site. The link operator can be extended to include not only basic URLs, but complete URLs that include directory names, filenames, parameters, and the like. Keep in mind that long URLs are much more specific and will return fewer results than their shorter counterparts.

The only place the URL of a link is visible is in the browser’s status bar or in the source of the page. For that reason, unlike other cached pages, the cached page for a link operator’s search result does not highlight the search term, since the search term (the linked Web site) is never really shown in the page. In fact, the cached banner does not make any reference to your search query, as shown in Figure 2.13.

It is a common misconception to think that the link operator can actually search for text within a link. The inanchor operator performs something similar to this, as we’ll see next. To properly use the link operator, you must provide a full URL (including protocol, server, directory, and file), a partial URL (including only the protocol and the host), or simply a server name; otherwise, Google could return unpredictable results. As an example, consider a search for link:linux, which returns 151,000 results. This search is not the proper syntax for a link search, since the domain name is invalid. The correct syntax for a search like this might be link:linux.org (with 317 results) or link:linux.org (with no results). These numbers don’t seem to make sense, and they certainly don’t begin to account for the 151,000 hits on the original query. So what exactly is being returned from Google for a search like link:linux? Figure 2.14 shows the answer to this question.

When an invalid link: syntax is provided, Google treats the search as a phrase search. Google offers another clue as to how it handles invalid link searches through the cache page. As shown in Figure 2.15, the cached banner for a site found with a link:linux search does not resemble a typical link search cached banner, but rather a standard search cache banner with included highlighted terms.

This is an indication that Google did not perform a link search, but instead treated the search as a phrase, with a colon representing a word break.

The link operator cannot be used with other operators or search terms.

<A HREF = “http://dmoz.org/Computers/Software/Operating_Systems/Linux/” > current page < /A>

The inanchor operator helps search the anchor, or the displayed text on the link, which in this case is the phrase “current page.” This is not the same as using inurl to find this page with a query like inurl:Computers inurl:Operating_Systems.

Inanchor accepts a word or phrase as an argument, such as inanchor:click or inanchor:James.Foster. This search will be handy later, especially when we begin to explore ways of searching for relationships between sites. The inanchor operator can be used with other operators and search terms.

The cache operator can be used with other operators and terms, although the results are somewhat unpredictable.

This operator can be used with other operators and search terms.

The parameters to this operator must always be expressed as a range, two dates separated by a dash. If you only want to locate pages that were indexed on one specific date, you must provide the same date twice, separated by a dash. If this sounds too easy to be true, you’re right. It is too easy to be true. Both dates passed to this operator must be in the form of two Julian dates. The Julian date is the number of days that have passed since January 1, 4713 B.C. For example, the date September 11, 2001, is represented in Julian terms as 2452164. So, to search for pages that were indexed by Google on September 11, 2001, and contained the word “Osama Bin Laden,” the query would be daterange:2452164–2452164 “osama bin laden”.

Google does not officially support the daterange operator, and as such your mileage may vary. Google seems to prefer the date limit used by the advanced search form at www.google.com/advanced_search. As we discussed in the last chapter, this form creates fields in the URL string to perform specific functions. Google designed the as_qdr field to help you locate pages that have been updated within a certain time frame. For example, to find pages that have been updated within the past three months and that contain the word Google, use the query http://www.google.com/search?q=google&as_qdr=m3. The info operator shows the summary information for a site and provides links to other Google searches that might pertain to that site, as shown. The parameter to this operator must be a valid URL or site name. You can achieve this same functionality by supplying a site name or URL as a search query.

This might be a better alternative date restrictor than the clumsy daterange operator. Just understand that these are very different functions. Daterange is not the advanced-operator equivalent for as_qdr, and unfortunately, there is no operator equivalent. If you want to find pages that have been updated within the past year or less, you must either use Google advanced search interface or stick &as_qdr = 3m (or equivalent) at the end of your URL.

The daterange operator must be used with other search terms or advanced operators. It will not return any results when used by itself.

If you don’t supply a complete URL or hostname, Google could return unpredictable results. Just as with the link and cache operators, passing an invalid hostname or URL as a parameter to info will submit the query as a phrase search. A search for info:linux returns exactly as many results as “info linux,” indicating that Google did indeed treat the info search as a standard phrase search.

The info operator cannot be used with other operators or search terms.

If you don’t supply a complete URL or hostname, Google could return unpredictable results. Passing an invalid hostname or URL as a parameter to related will submit the query as a phrase search. A search for related:linux returns exactly as many results as “related linux,” indicating that Google did indeed treat the cache search as a standard phrase search.

The related operator cannot be used with other operators or search terms.

The stocks operator cannot be used with other operators or search terms.

Allintext gives incorrect results when it is mixed with other operators. For example, a search for allintext:moo goo gai filetype:pdf works well for finding Chinese food menus, whereas allintext:Sum Dum Goy intitle:Dragon gives you that empty feeling inside – like a year without the 1985 classic The Last Dragon (see Figure 2.20).

Despite the fact that some operators do combine with others, it’s still possible to get less than optimal results by running your operators head-on into each other. This section focuses on pointing out a few of the potential bad collisions that could give useless results. We’ll start with some of the more obvious ones.

First, consider a query like something – something. By asking for something and taking away something, we end up with... nothing, and Google tells you as much. This is an obvious example, but consider intitle:something – intitle:something. This query, just like the first, returns nothing, since we’ve negated our first search with a duplicate NOT search. Literally, we’re saying “find something in the title and hide all the results with something in the title.” Both of these examples clearly illustrate the point that you can’t query for something and negate that query, because your results will be zero.

It gets bit tricky when the advanced operators start overlapping. Consider site and inurl. The URL includes the name of the site. So, extending the “don’t contradict yourself” rule, don’t include a term with site and exclude that term with inurl and vice versa and expect valid results. A query like site:microsoft.com -inurl: microsoft.com doesn’t make much sense, and shouldn’t work, but as Figure 2.21 shows, it does work.

When you’re really trying to home in on a topic, keep the “rules” in mind and you’ll accelerate toward your target at a much faster pace. Save the rule breaking for your required Google hacking license test!

Here’s a quick breakdown of some broken searches and why they’re broken:

Most of the operators can be used in combination, the most notable exceptions being the allintitle, allinurl, allinanchor, and allintext operators. Advanced Google searchers tend to steer away from these operators, opting to use the intitle, inurl, and link operators to find strings within the title, URL, or links to pages, respectively. Allintext, used to locate all the supplied search terms within the text of a document, is one of the least used and most redundant of the advanced operators. Filetype and site are very powerful operators that search specific sites or specific file types. The daterange operator allows you to search for files that were indexed within a certain time frame, although the URL parameter as_qdr seems to be more in vogue. When crawling Web pages, Google generates specific information such as a cached copy of a page, an information snippet about the page, and a list of sites that seem related. This information can be retrieved with the cache, info, and related operators, respectively. The stocks operator returns stock information about a specific ticker symbol, whereas the define operator returns the definition of a word or simple phrase.