Result count varies

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by santhosh.nagaraj on 19 May 2008 at 1:55

[GoogleCodeExporter]

Original comment by jrgeer...@gmail.com on 4 Jun 2008 at 1:00

• Added labels: APIType-Search

[GoogleCodeExporter]

Original comment by internal...@gmail.com on 4 Jun 2008 at 10:53

• Changed state: Accepted

[GoogleCodeExporter]

Related to #4?

Original comment by asheme...@gmail.com on 6 Jun 2008 at 2:32

[GoogleCodeExporter]

pleaaaaaaaseee get this fixed soon

Original comment by are...@gmail.com on 19 Aug 2008 at 8:28

[GoogleCodeExporter]

Case 1:
--------------------------------------------------------------------------------
-----

For start = 0:

http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=access%2Bstudent+sit
e: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+sit
e: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+i
nurl:/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+i
nurl:/uvic-policies/&rsz=large&start=24&filter=0

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

--------------------------------------------------------------------------------
-----

What is going on????

Original comment by a_star_c...@hotmail.com on 27 Aug 2008 at 5:41

[GoogleCodeExporter]

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. 

Original comment by a_star_c...@hotmail.com on 27 Aug 2008 at 5:44

[GoogleCodeExporter]

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

Original comment by a_star_c...@hotmail.com on 27 Aug 2008 at 5:49

[GoogleCodeExporter]

Anyone knows when this issue will be fixed?

Original comment by shervi...@gmail.com on 3 Sep 2008 at 10:37

[GoogleCodeExporter]

bump

Original comment by mark.ham...@gmail.com on 3 Oct 2008 at 2:18

[GoogleCodeExporter]

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?

Original comment by jamiebrammer on 16 Oct 2008 at 11:20

[GoogleCodeExporter]

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

Original comment by jbwhee...@gmail.com on 18 Oct 2008 at 9:47

[GoogleCodeExporter]

Original comment by RichBra...@gmail.com on 28 Oct 2008 at 6:42

[GoogleCodeExporter]

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.

Original comment by jamiebrammer on 7 Nov 2008 at 12:30

[GoogleCodeExporter]

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.

Original comment by david.j....@googlemail.com on 8 Feb 2009 at 6:34

[GoogleCodeExporter]

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...).

Original comment by getyoufo...@gmail.com on 16 Mar 2009 at 8:43

[GoogleCodeExporter]

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

Original comment by chrisbjohannsen on 18 Mar 2009 at 12:22

[GoogleCodeExporter]

*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. 

Original comment by ptar...@gmail.com on 3 Apr 2009 at 5:34

[GoogleCodeExporter]

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

Original comment by dharmesh...@gmail.com on 9 Apr 2009 at 8:20

[GoogleCodeExporter]

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

Original comment by wilo...@gmail.com on 10 Apr 2009 at 3:04

[GoogleCodeExporter]

Issue 222 has been merged into this issue.

Original comment by jrgeer...@gmail.com on 15 Apr 2009 at 10:01

[GoogleCodeExporter]

Issue 221 has been merged into this issue.

Original comment by jrgeer...@gmail.com on 15 Apr 2009 at 10:02

[GoogleCodeExporter]

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

Original comment by andek...@gmail.com on 30 Apr 2009 at 7:52

[GoogleCodeExporter]

Note my complaints also
Fix this

Original comment by amd...@gmail.com on 29 May 2009 at 10:14

[GoogleCodeExporter]

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.

Original comment by peter.ra...@gtempaccount.com on 2 Jun 2009 at 5:59

[GoogleCodeExporter]

please fix this yaar 

Original comment by shaju.be...@gmail.com on 22 Jun 2009 at 12:44

[GoogleCodeExporter]

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...

Original comment by m.kaepp...@gmail.com on 22 Jun 2009 at 12:54

[GoogleCodeExporter]

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.

Original comment by petenma...@gmail.com on 16 Jul 2009 at 8:36

[GoogleCodeExporter]

@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.

Original comment by jrgeer...@gmail.com on 16 Jul 2009 at 12:30

[GoogleCodeExporter]

Hi

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

 Please suggest me ? 

Thanks

Original comment by vikas.k....@gmail.com on 29 Sep 2009 at 10:46

[GoogleCodeExporter]

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

Original comment by anandcom...@gmail.com on 5 Oct 2009 at 9:47

[GoogleCodeExporter]

please fix this bag

Original comment by sergey.z...@gmail.com on 11 Oct 2009 at 11:16

[GoogleCodeExporter]

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.

Original comment by AWNaug...@gmail.com on 30 Oct 2009 at 1:17

[GoogleCodeExporter]

am hoping google fixes this issue soon..

Original comment by Sudharsh...@gmail.com on 4 Nov 2009 at 6:20

[GoogleCodeExporter]

passing

Original comment by somewall...@gmail.com on 12 Nov 2009 at 6:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Is *nobody* @ google watvhing these threads ?

-- gerhard

Original comment by abuse.cl...@googlemail.com on 23 Nov 2009 at 3:58

[GoogleCodeExporter]

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-i
dentical-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).

Original comment by m.kaepp...@gmail.com on 23 Nov 2009 at 4:14

[GoogleCodeExporter]

bump

Original comment by ali.rac...@gmail.com on 27 Nov 2009 at 6:38

[GoogleCodeExporter]

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.

Original comment by schnib...@gmail.com on 29 Dec 2009 at 5:12

[GoogleCodeExporter]

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

Original comment by bodom...@gmail.com on 10 Jan 2010 at 9:07

[GoogleCodeExporter]

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

Original comment by matthias...@gmail.com on 27 Jan 2010 at 9:37

[GoogleCodeExporter]

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.

Original comment by ali.rac...@gmail.com on 27 Jan 2010 at 11:25

[GoogleCodeExporter]

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.

Original comment by m.kaepp...@gmail.com on 27 Jan 2010 at 12:07

[GoogleCodeExporter]

@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.

Original comment by ali.rac...@gmail.com on 27 Jan 2010 at 12:10

[GoogleCodeExporter]

Of course it affects pagination, see comment 5

Original comment by m.kaepp...@gmail.com on 27 Jan 2010 at 12:29

[GoogleCodeExporter]

@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. 

Original comment by ali.rac...@gmail.com on 27 Jan 2010 at 4:46

[GoogleCodeExporter]

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?

Original comment by jscud.w...@gmail.com on 27 Jan 2010 at 11:23

[GoogleCodeExporter]

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.

Original comment by jstarc...@gmail.com on 28 Jan 2010 at 4:05

[GoogleCodeExporter]

@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/

Original comment by jrgeer...@gmail.com on 28 Jan 2010 at 9:35

[GoogleCodeExporter]

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?

Original comment by anas.elg...@gmail.com on 31 Jan 2010 at 8:31