<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Supplemental Pages: Again</title>
	<atom:link href="http://www.jlh-design.com/2007/06/supplemental-pages-again/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jlh-design.com/2007/06/supplemental-pages-again/</link>
	<description>Terrible writing and mere conjecture</description>
	<pubDate>Fri, 08 Aug 2008 00:26:45 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: dockarl</title>
		<link>http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4737</link>
		<dc:creator>dockarl</dc:creator>
		<pubDate>Wed, 06 Jun 2007 10:41:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4737</guid>
		<description>add 'storage density' where I mention 'processing capacity' above..</description>
		<content:encoded><![CDATA[<p>add &#8217;storage density&#8217; where I mention &#8216;processing capacity&#8217; above..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dockarl</title>
		<link>http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4736</link>
		<dc:creator>dockarl</dc:creator>
		<pubDate>Wed, 06 Jun 2007 10:38:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4736</guid>
		<description>That's a great catch JLH - very interesting.

When you think about it, the mind boggles about just how complex their calculations must be - I'd assume the aggregate processing power required to index pages would increase exponentially (or probably more likely as a power relationship) vs number of pages in existence. Moore's law can't keep up with that.. so I'm guessing land around their server farms would be a good buy, either that or they think of better ways to use their existing infrastructure - I'm certain the supps is probably one of those ways.

By the way - did you see my response to your great suggestions about the wordpress category pages vs real pages supp problem?

http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/d30f62b048fae6f4

Made a bit of a hack to hopefully reduce the 'relevance' of the cat pages, without removing their utility as a way of keeping all pages within a few clicks from the index page.

Cheers,

M</description>
		<content:encoded><![CDATA[<p>That&#8217;s a great catch <acronym title="John Honeck"><a title="JLH" href="http://johnhoneck.wordpress.com/">JLH</a></acronym> - very interesting.</p>
<p>When you think about it, the mind boggles about just how complex their calculations must be - I&#8217;d assume the aggregate processing power required to index pages would increase exponentially (or probably more likely as a power relationship) vs number of pages in existence. Moore&#8217;s law can&#8217;t keep up with that.. so I&#8217;m guessing land around their server farms would be a good buy, either that or they think of better ways to use their existing infrastructure - I&#8217;m certain the supps is probably one of those ways.</p>
<p>By the way - did you see my response to your great suggestions about the wordpress category pages vs real pages supp problem?</p>
<p><a href="http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/d30f62b048fae6f4" >http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/d30f62b048fae6f4</a></p>
<p>Made a bit of a hack to hopefully reduce the &#8216;relevance&#8217; of the cat pages, without removing their utility as a way of keeping all pages within a few clicks from the index page.</p>
<p>Cheers,</p>
<p>M</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JLH</title>
		<link>http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4735</link>
		<dc:creator>JLH</dc:creator>
		<pubDate>Wed, 06 Jun 2007 08:53:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4735</guid>
		<description>I've been fixated on them saving crawling resources with the lower crawl rate of the supplemental results, but seemed to forget about their limited processing resources as well.  This logically fits in.  As the web grows larger and larger Google's index continues to grow, and they have to prioritize their resources: Crawlers, data storage, and processing time.  Supplemental are less important pages, as judged by links of course, and perhaps even by the subject matter? Hmmm, it would make sense to prioritize for the most popular 1,000,000 (random number) queries and their top 1000 results, and then let the others fall to the supplemental crap pile.

After all, people would not be too happy if that little timer at the top of the search page said Results 1 - 10 of about 485,480,000,000 for ___. (8.19 minutes) 

Before we had people worrying about supplemental we had everyone complaining they couldn't get the site indexed.  At least now they index it pretty fast, but it probably won't rank for anything, since it will be mostly supplemental.

I see this as a possible chink in the armor that is the Google monopoly.  It was techno-web-geeks that deemed Google the best search engine a long time ago.  As new sites get indexed fast, but dumped in the supplemental results which send them 3 visitors a year, the other search engines (and I use that term loosely) if they were smart would jump on that and prioritize freshness.  The webmaster's would see most of their traffic is coming from Yahoo and MSN [forget Ask until they get at least 2 more modems and crawl more than once every 2 years] and start pushing them as the real deal. 

The first search engine that doesn't return the same old wiki, ebay, amazon, about, or answers.com for every query but digs deeper may be the next Google.

Millions of links to a page means a page is more popular, which also means almost everybody knows about it, otherwise they wouldn't be SEARCHING.   The real diamonds are buried away in a compressed database that's running on an Atari 400 labeled supplemental somewhere in Googleland.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been fixated on them saving crawling resources with the lower crawl rate of the supplemental results, but seemed to forget about their limited processing resources as well.  This logically fits in.  As the web grows larger and larger Google&#8217;s index continues to grow, and they have to prioritize their resources: Crawlers, data storage, and processing time.  Supplemental are less important pages, as judged by links of course, and perhaps even by the subject matter? Hmmm, it would make sense to prioritize for the most popular 1,000,000 (random number) queries and their top 1000 results, and then let the others fall to the supplemental crap pile.</p>
<p>After all, people would not be too happy if that little timer at the top of the search page said Results 1 - 10 of about 485,480,000,000 for ___. (8.19 minutes) </p>
<p>Before we had people worrying about supplemental we had everyone complaining they couldn&#8217;t get the site indexed.  At least now they index it pretty fast, but it probably won&#8217;t rank for anything, since it will be mostly supplemental.</p>
<p>I see this as a possible chink in the armor that is the <strong style="color: rgb(0, 0, 255);">G</strong><strong style="color: rgb(255, 0, 0);">o</strong><strong style="color: rgb(255, 255, 77);">o</strong><strong style="color: rgb(0, 0, 255);">g</strong><strong style="color: rgb(0, 128, 0);">l</strong><strong style="color: rgb(255, 0, 0);">e</strong> monopoly.  It was techno-web-geeks that deemed <strong style="color: rgb(0, 0, 255);">G</strong><strong style="color: rgb(255, 0, 0);">o</strong><strong style="color: rgb(255, 255, 77);">o</strong><strong style="color: rgb(0, 0, 255);">g</strong><strong style="color: rgb(0, 128, 0);">l</strong><strong style="color: rgb(255, 0, 0);">e</strong> the best search engine a long time ago.  As new sites get indexed fast, but dumped in the supplemental results which send them 3 visitors a year, the other search engines (and I use that term loosely) if they were smart would jump on that and prioritize freshness.  The webmaster&#8217;s would see most of their traffic is coming from Yahoo and <acronym title="Microsoft Network">MSN</acronym> [forget Ask until they get at least 2 more modems and crawl more than once every 2 years] and start pushing them as the real deal. </p>
<p>The first search engine that doesn&#8217;t return the same old wiki, ebay, amazon, about, or answers.com for every query but digs deeper may be the next Google.</p>
<p>Millions of links to a page means a page is more popular, which also means almost everybody knows about it, otherwise they wouldn&#8217;t be SEARCHING.   The real diamonds are buried away in a compressed database that&#8217;s running on an Atari 400 labeled supplemental somewhere in Googleland.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JohnMu</title>
		<link>http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4729</link>
		<dc:creator>JohnMu</dc:creator>
		<pubDate>Wed, 06 Jun 2007 06:56:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.jlh-design.com/2007/06/supplemental-pages-again/#comment-4729</guid>
		<description>I was wondering who would catch that first - congrats!

Parsing pages differently could mean a lot of interesting things. Maybe it was even said on accident, hmmm :-). Or maybe we're just reading too much into Matt's words :-)</description>
		<content:encoded><![CDATA[<p>I was wondering who would catch that first - congrats!</p>
<p>Parsing pages differently could mean a lot of interesting things. Maybe it was even said on accident, hmmm :-). Or maybe we&#8217;re just reading too much into Matt&#8217;s words <img src='http://www.jlh-design.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
</channel>
</rss>
