What steps will reproduce the problem? 1. Searched for Paris Hilton on www.google.com 2. Call the ajax search from java programatically (used the code snippet in the developer's guide)

What is the expected output? What do you see instead? The number of results in step 1 and estimatedResultCount in step 2 differ by a huge number.

What version of the product are you using? On what operating system? OS is Windows XP.

Please provide any additional information below.

Related to #4?

pleaaaaaaaseee get this fixed soon

Case 1:

For start = 0:

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=access%2Bstudent+site:web.uvic.ca+inurl:/uvic-policies/&rsz=large&start=0&filter=0

[estimatedResultCount] => 19 [currentPageIndex] => 0

For start = 16:

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=access%2Bstudent+site:web.uvic.ca+inurl:/uvic-policies/&rsz=large&start=16&filter=0

[estimatedResultCount] => 17 [currentPageIndex] => 2

Case 2:

For start = 0:

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=a+site:web.uvic.ca+inurl:/uvic-policies/&rsz=large&start=0&filter=0

[estimatedResultCount] => 174 [currentPageIndex] => 0

For start = 24:

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=a+site:web.uvic.ca+inurl:/uvic-policies/&rsz=large&start=24&filter=0

[estimatedResultCount] => 25 [currentPageIndex] => 3

What is going on????

Note to the above, it is only the last page in the cursor that does this.

P.S. If the results only fill up labels 1-3 in the cursor, I can still access label 4, and the object returned for that request contains erroneous results.

Sorry also forgot to mention I am using PHP to grab the JSON version of the results.

Anyone knows when this issue will be fixed?

bump

We're implementing for a client now. This is causing many complaints about the UI. Any ideas on when it might be fixed or is this a fundamental architectural problem and will take months to solve?

This is a MASSIVE flaw. I'm really hoping someone can address this bug. Is anyone looking at this?

I've had this reply: "estimated result count is very unstable, especially when results that contribute come from less popular sites on the web. Also, when a fluctuation occurs, the wrong answer may be cached for up to 24 hours. It really is best to not display the estimated result count as it’s just an estimate and really serves no useful purpose". It appears it is unlikely to be fixed in the near future, if ever.

Unfortunately, plenty of applications (including mine) are using this estimated count to work. It appears that the relatively "Google Fight" is scraping normal google.com pages unless they've found some way of working around this issue. For me, it's a showstopper. I'm scraping google.com pages but it's far far slower than using the API.

Please fix this issue as it is a major drawback to the API. This seems to affect most, if not all, of the expected results (normal, allintitle, etc...).

This issue definately reduces my ability to use the API, what a bummer... I hope you will fix

bump

From Comment 13, if the number serves no useful purpose, they when would google.com/search show it? I find it useful for web metrics and would like an accurate guesstimate of the number of pages returned from a result.

I am also facing the same problem. The Ajax search code that I copied from the Developer's guide section returns very few results or nothing for our website. The result count from google search is more. Does any one know if this bug has been fixed or not? Any updates on this issue would be greatly appreciated.

Thanks

We are facing the same problem. WHen will this be fixed?

Issue 222 has been merged into this issue.

Issue 221 has been merged into this issue.

This issue is such a showstopper. I can't believe with all the complaints that nothing is being done about it...

Note my complaints also Fix this

Note to all. The older (and soon to be deprecated) SOAP API returned very stable results for Estimated Result Count for any type of search (allintitle, normal, etc.). While the returned value was sometimes 5% or 10% off from what the google website displayed, we found that this was an acceptable and reliable range (and also a very stable difference, showing that it is likely due to something as simple as internal rounding differences between the SOAP and normal Google web results). With the Newer APIs, the results are all across the board and can be up to 90% off in some cases. They also vary between searches so that the same terms offer drastically different results across a 72 hour period. These differences don't seem to follow a pattern, suggesting that something is seriously wrong with the underlying method of determining an Estimated Result Count within the new API.

please fix this yaar

I still can't believe that a massive bug like this makes it into a public Google API, AND doesn't get any attention by the devs for over a year now...

This problem also makes the whole ajax search useless for me. I don't understand why they are unwilling to fix this. Now I have to get the results without the api which also makes more load for google's servers.

@petenmaili: While I can certainly understand your frustration with this issue's lack of resolution, it should be noted that the use of "screen scraping" applications, or programs which parse the result count or other information out of Google's standard web interface, are strictly prohibited by the Google TOU.

Hi

How we can got the estimated result count of any search in asp.net project.

Please suggest me ?

Thanks

Can you please try to fix this as soon as possible? It is really a show stopper...

please fix this bag

I guess all Internet marketers would be happy so see this fixed, because it will allow to create reliable applications for finding untapped niches.

Internet marketers are good for Google and Internet, because they fill it with content for various long tail terms thus improving user experience with Google (which is able to return some relevant results for long queries).

Everyone will benefit from this fix -- Google will get more content for long tail phrases, users will be able to find relevant pages and marketers will earn some money.

am hoping google fixes this issue soon..

passing

Comment deleted

I think this nasty problem waits too long for a fix!

Is nobody @ google watvhing these threads ?

-- gerhard

They do, but obviously they don't care. Which is weird, because I would have though they get gazillions of conversions from this API (since so many apps are using it... I guess?! AroundMe uses it, and it's massively popular on iPhone.)

This is really not the only problem about this API, however. It is, as a product, broken in many ways beyond just technical issues. I made some very odd observations about the results it yields, which I have summarized here, if you're interested: http://stackoverflow.com/questions/1605641/google-location-api-vs-maps-why-are-identical-queries-yielding-different-result

The quality of the results is definitely worse than the results you get from Google Maps, and definitely much worse than whatever API PlacesDirectory uses (their Android app).

bump

Well I have to resort to yahoo's API. It's a bit unfortunate, but I'm pretty sure that after 38 comments, and months of complaining that Google just isn't going to fix this, and why should they? It's not really a profit-center for them. They're not going to make big money off of us, so oh well.

It hurts....they do not do anyhting. Why?

An official statement would be really nice, so developers can decide if it's possible to use the API soon.

I've done some testing and reached the conclusion that the count returned by the api is the correct one, whereas the one shown by google when you do a web search is the incorrect one. Hence the issue is with the web search count being incorrect and not the api. To test this yourself do a search for a keyword which is likely to return 100-200 results, the api will return the correct number while the web search will return a much higher number. However when you try to browse the web search results to the end, you won't be able to view beyond the result num returned by the api.

So I think the problem here is with the web search, not the api, and its safe to use the api.

that's most certainly not true.

The problem is that the result count reported by the API and the actual number of results returned are inconsistent, resulting in odd situations where the total number of results (say, 10) is distributed over e.g. 2 pages, but when fetching page 1, you will only get 2 results, but 8 on page 2.

That has nothing to do with Web search, the pagination in the Ajax API is simply broken.

@m.kaeppler, this bug doesn't have anything to do with the pagination, this is what the bug description says:

"1. Searched for Paris Hilton on www.google.com 2. Call the ajax search from java programatically (used the code snippet in the developer's guide)

The number of results in step 1 and estimatedResultCount in step 2 differ by a huge number."

I've found that the number of results returned in estimatedResultCount in step 2 is the correct number of results while the number of results returned by the web search in step 1 is incorrect.

Of course it affects pagination, see comment 5

@m.kaeppler, I'm not using the pagination however when you first do an api request, the estimatedResultCount you get for the first page is the correct one and you should do your pagination based on that.

Hi m.kaeppler, I think the pagination issue is actually separate from the estimatedResultCount. However, you are seeing, for example, 3 results on page 1 and 7 results on page 2, then it sounds like an issue. Do you have an example query that would help me reproduce this?

This really put a damper on my development. I may try resortign to SOAP api, but wow I can't believe this new api is so terribly flawed. Most of my results are off by 90%+. Useless.

@jstarcher Unfortunately, the SOAP API was deprecated in late 2006 and discontinued in late 2009. It is the AJAX Search API or nothing for programmatically accessing Google search from your own application.

@ali.rac200 Re: your request on issue 384 to comment here. Sadly, since I don't work for Google, there's not much I can say about this issue other than that it's real, the dev team knows about it, and they will address it if and when they deem it necessary and appropriate. However, I would submit that the estimatedResultCount (ERC) is trivial when the API is used as it was designed to be used: i.e., to provide simple access to rudimentary search functionality from within your non-Google applications. In the vast majority of these use cases, the ERC is superfluous information. What really matters is that users get the results which will direct them to the information they are searching for. In fact, the only use cases I can think of where the ERC is truly critical are in SEO operations. If you read the TOS, which prohibit the use of robots, spiders, and other automated query-making apps, and then consider that the API only returns a maximum of 64 results, you begin to realize that the API really was designed against such uses.

If you really must have an accurate result count, both Yahoo! and Bing offer APIs which you can try. Check them out at the links below:

Yahoo! BOSS: http://developer.yahoo.com/boss/ Microsoft Bing: http://www.bing.com/developers/

Oh this is unbeievable! People have been complaining about this issue (begging, in fact, for a fix) since the Summer of 2008. We are now in Feb 2010! How can it be that a company on the cutting edge of search technology ignores such a glaring bug for a year and a half?! Is it incompetence, apathy, broken chain of command, or is the AJAX API broken on purpose?

Comment deleted

I am also facing problem with this known-issue/bug. Can someone suggest any workaround for this problem till this issue is not solved by Google Inc.

Please fix this bug !!!!!

This issue and Issue 360 seem to be related - there seem to be problems generating the last page of results in a variety of circumstances. I agree with all the other posters - this really needs to be fixed.

wow, just wow... Time to use Bing or Yahoo!

I'm not sure that this is a bug. Google have an agenda, I'm sure.

Has anyone discovered a fix for this? I just built a jQuery plugin that uses the Google AJAX API and now I run into this and it looks like a bug in my code when it's actually Google's fault.

2 years...

I agree to comment #56. When you read #49 along with this, it makes sense .

The Estimated Result Count is just that - it's an estimate of the number of results available. Due to the nature of calculation, this estimate is not stable, and can change from request to request, mimicking the similar count on google.com.