(No comment was entered for this change.)

(No comment was entered for this change.)

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?

(No comment was entered for this change.)

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

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?

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.

(No comment was entered for this change.)