NOPREVIEW - The missing X-Robots-Tag

Google provides previews of non-HTML resources listed on their SERPs:
These "view as text" and "view as HTML" links are pretty useful when you for example want to scan a PDF document before you clutter your machine's RAM with 30 megs of useless digital rights management (aka Adobe Reader). You can view contents even when the corresponding application is not installed, Google's transformed previews should not stuff your maiden box with unwanted malware, etcetera. However, under some circumstances it would make sound sense to have a NOPREVIEW X-Robots-Tag, but unfortunately Google forgot to introduce it yet.

Google is rightfully proud of their capability to transform various file formats to readable HTML or plain text: Adobe Portable Document Format (pdf), Adobe PostScript (ps), Lotus 1-2-3 (wk1, wk2, wk3, wk4, wk5, wki, wks, wku), Lotus WordPro (lwp), MacWrite (mw), Microsoft Excel (xls), Microsoft PowerPoint (ppt), Microsoft Word (doc), Microsoft Works (wks, wps, wdb), Microsoft Write (wri), Rich Text Format (rtf), Shockwave Flash (swf), of course Text (ans, txt) plus a couple of "unrecognized" file types like XML. New formats are added from time to time.

According to Adam Lasnik currently there is no way for Webmasters to tell Google not to include the "View as HTML" option. You can try to fool Google's converters by messing up the non-HTML resource in a way that a sane parser can't interpret it. Actually, when you search a few minutes you'll find e.g. PDF files without the preview links on Google's SERPs. I wouldn't consider this attempt a bullet-proof nor future-proof tactic though, because Google is pretty intent on improving their conversion/interpretation process.

I like the previews not only because sometimes they allow me to read documents behind a login screen. That's a loophole Google should close as soon as possible. When for example PDF documents or Excel sheets are crawlable but not viewable for searchers (at least not with the second click) that's plain annoying both for the site as well as for the search engine user.

With HTML documents the Webmaster can apply a NOARCHIVE crawler directive to prevent non paying visitors from lurking via Google's cached page copies. Thanks to the newish REP header tags one can do that with non-HTML resources too, but neither NOARCHIVE nor NOSNIPPET etch away the "view-as HTML" link.

<speculation>Is the lack of a NOPREVIEW crawler directive just an oversight, or is it stuck in the pipeline because Google is working on supplemental components and concepts? Google's yet inconsistent handling of subscription content comes to mind as an ideal playground for such a robots directive in combination with a policy change.</speculation>

Anyways, there is a need for a NOPREVIEW robots tag, so why not implement it now? Thanks in advance.

Stumble It!

Post it to del.icio.us

SEOs home alone - Google's nightmare

Being a single parent of three monsters at the moment brings me newish insights. I now deeply understand the pain of father Google dealing with us, and what doing the chores all day long means to Matt's gang in building 43, Dublin, and whereever. What a nightmare of a household.

If you don't suffer from an offspring plague you won't believe what sneaky and highly intelligent monsters having too much time on their tiny greedy hands will do to gain control over their environment. Outsmarting daddy is not a hobby, it's their mission, and everything in perfect order is attackable. Each of them tries to get as much attention as possible, and if nothing helps, negative attention is fine too. There's no such thing as bad traffic, err ... mindfulness.

Every rule is breakable, and there's no way to argue seriously with a cute 5 yo gal burying her 3 yo brother in the mud whilst honestly telling me that she has nothing to do with the dirty laundry because she never would touch anything hanging on the clothesline. Then my little son speaks out telling me that's all her fault, so she promises to do it never, never, never again in her whole life and even afterwards. In such a situation I've not that much options: I archive my son's paid links report, accept her reconsideration request but throttle her rankings for a while, recrawl and remove the unpurified stuff from the ... Oups ... I clear the scene with a pat on her muddy fingers, forgive all blackhatted kids involved in the scandal and just do the laundry again, writing a note to myself to improve the laundry algo in a way that muddy monsters can't touch laundered bed sheets again.

Anything not on the explicit don'ts list goes, so while I'm still stuffing the washer with muddy bed sheets I hear a weird row in the living room. Running upstairs I spot my 10 yo son and his friend playing soccer with a ball I had to fish out of a heap of broken crockery and uprooted indoor plants to confiscate it just two hours ago. Yelling that's against our well known rules and why the heck is that [...] ball in the game again I get stopped immediately by the boys. First, they just played soccer and the recent catastrophe was the result of a strictly forbidden basketball joust. I've to admit that I said they must not play basketball in the house. Second, it's my fault when I don't hide the key to the closet where I locked the confiscated ball away. Ok, enough is enough. I banned my son's friend and grounded himself for a week, took away the ball, and ran to the backyard to rescue two bitterly crying muddy dwarfs from the shed's roof. Later on, while two little monsters play games in the bath tub which I really don't want to watch too closely currently, I read a thread titled "Daddy is soooo unfair" in the house arrest forum where my son and his buddy tell the world that they didn't do anything wrong, just sheer whitehatted stuff, but I stole their toy and banned them from the playground. Sigh.

I'm exhausted. I'm supposed to deliver a script to merge a few feeds giving fresh contents, a crawlability review, and whatnot tonight, but I just wonder what else will happen when I leave the monsters alone in their beds after supper and story hour, provided I get them into their beds without a medium-size flame war. Now I understand why another daddy supplemented the family with a mom.

Stumble It!

Post it to del.icio.us

Unavailable_After is totally and utterly useless

I've a lot of respect for Dan Crow, but I'm struggling with my understanding, or possible support, of the unavailable_after tag. I don't want to put my reputation for bashing such initiatives from search engines at risk, so sit back and grab your popcorn, here comes the roasting:

As a Webmaster, I did not find a single scenario where I could or even would use it. That's because I'm a greedy traffic whore. A bazillion other Webmasters are greedy too. So how the heck is Google going to sell the newish tag to the greedy masses?

Ok, from a search engine's perspective unavailable_after makes sound sense. Outdated pages bind resources, annoy searchers, and in a row of useless crap the next bad thing after an outdated page is intentional Webspam.

So convincing the great unwashed to put that thingy on their pages inviting friends and family to granny's birthday party on 25-Aug-2007 15:00:00 EST would improve search quality. Not that family blog owners care about new meta tags, RFC 850-ish date formats, or search engine algos rarely understanding that the announced party is history on Aug/26/2007. Besides there may be painful aftermaths worth submitting a desperate call for aspirins the day after in the comments, what would be news of the day after expiration. Kinda dilemma, isn't it?

Seriously, unless CMS vendors support the new tag, tiny sites and clique blogs aren't Google's target audience. This initiative addresses large sites which are responsible for a huge amount of outdated contents in Google's search index.

So what is the large site Webmaster's advantage of using the unavailable_after tag? A loss of search engine traffic. A loss of link juice gained by the expired page. And so on. Losses of any kind are not that helpful when it comes to an overdue raise nor in salary negotiations. Hence the Webmaster asks for the sack when s/he implements Google's traffic terminator.

Who cares about Google's search quality problems when it leads to traffic losses? Nobody. Caring Webmasters do the right thing anyway. And they don't need no more useless meta tags like unavailable_after. "We don't need no stinking metas" from "Another Brick in the Wall Part Web 2.0" expresses my thoughts perfectly.

So what separates the caring Webmaster from the 'ruthless traffic junky' who Google wants to implement the unavailable_after tag? The traffic junkie lets his stuff expire without telling Google about it's state, is happy that frustrated searchers click the URL from the SERPs even years after the event, and enjoys the earnings from tons of ads placed above the content minutes after the party was over. Dear Google, you can't convince this guy.

[It seems this is a post about repetitive "so whats". And I came to the point before the 4th paragraph ... wow, that's new ... and I've put a message in the title which is not even meant as link bait. Keep on reading.]


So what does the caring Webmaster do without the newish unavailable_after tag? Business as usual. Examples:


Say I run a news site where the free contents go to the subscription area after a while. I'd closely watch which search terms generate traffic, write a search engine optimized summary containing those keywords, put that on the sales pitch, and move the original article to the archives accessible to subscribers only. It's not my fault that the engines think they point to the original article after the move. When they recrawl and reindex the page my traffic will increase because my summary fits their needs more perfectly.

Say I run an auction site. Unfortunately particular auctions expire, but I'm sure that the offered products will return to my site. Hence I don't close the page, but I search my database for similar offerings and promote them under a H3 heading like "[product] (stuffed keywords) is hot" /H3 P buy [product] here: /P followed by a list of identical products for sale or similar auctions.

Say I run a poll expiring in two weeks. With Google's newish near real time indexing that's enough time to collect keywords from my stats, so the textual summary under the poll's results will attract the engines as well as visitors when the poll is closed. Also, many visitors will follow the links to related respectively new polls.


From Google's POV there's nothing wrong with my examples, because the visitor gets what s/he was searching for, and I didn't cheat. Now tell me, why should I give up these valuable sources of nicely targeted search engine traffic just to make Google happy? Rather I'd make my employer happy. Dear Google, you didn't convince me.



Update: Tanner Christensen posted a remarkable comment at Sphinn:

I'm sure there is some really great potential for the tag. It's just none of us have a need for it right now.

Take, for example, when you buy your car without a cup holder. You didn't think you would use it. But then, one day, you find yourself driving home with three cups of fruit punch and no cup holders. Doh!

I say we wait it out for a while before we really jump on any conclusions about the tag.

John Andrews was the first to report an evil use of unavailable_after.

Also, Dan Crow from Google announced a pretty neat thing in the same post: With the X-Robots-Tag you can now apply crawler directives valid in robots meta tags to non-HTML documents like PDF files or images.

Stumble It!

Post it to del.icio.us

Why eBay and Wikipedia rule Google's SERPs

It's hard to find an obscure search query like [artificial link] which doesn't deliver eBay spam or a Wikipedia stub within the first few results at Google. Although both Wikipedia and eBay are large sites, the Web is huge, so two that different sites shouldn't dominate the SERPs for that many topics. Hence it's safe to say that many nicely ranked search results at Googledia, pulled from eBaydia, are plain artificial positioned non-results.

Curious why my beloved search engine fails so badly, I borrowed a Google-savvy spy from GHN and sent him to Mountain View to uncover the eBaydia ranking secrets. He came back with lots of pay-dirt scraped from DVDs in the safe of building 43. Before I sold Google's ranking algo to Ask (the price Yahoo! and MSN offered was laughable), I figured out why Googledia prefers eBaydia from comments in the source code. Here is the unbelievable story of a miserable failure:

When Yahoo! launched Mindset, Larry Page and Sergey Brin threw chairs out of anger because Google wasn't able to accomplish such a simple task. The engineers, eager to fulfill their founder's wishes asap, tried to integrate mindset-functionality without changing Google's fascinating simple search interface (that means without a shopping/research slider). Personalized search still lived in the labs, but provided a somewhat suitable API (mega beta): scanSearchersBrainForContext([search query]). Not knowing that this function of personalized search polls a nano-bugging-device (pre alpha) which Google had not yet released nor implemented into any searcher's brain at this time, they made use of that piece of experimental code to evaluate the search query's context. Since the method always returned "false", though they had to deliver results quickly, they made up some return values to test their algo tweaks:

/* debug - praying S&L don't throw more chairs */
if (scanSearchersBrainForContext($searchQuery) === false) then {
$contextShopping = "%ebay%";
$contextResearch = "%wikipedia%";
$context = both($contextShopping, $contextResearch);
}
else {[pretty complex algo])

This worked fine and found its way into the ranking algo under time pressure. The result is that with each and every search query where a page from eBay and/or Wikipedia is in the raw result set, those get a ranking boost. Sergey was happy because eBay is generally listed on page #1, and Larry likes the Wikipedia results on the first SERP. Tell me why the heck should the engineers comment out these made up return values? No engineer on this planet likes flying chairs, especially not in his office.


PS: Some SEOs push Wikipedia stubs too.

Stumble It!

Post it to del.icio.us

Another way to implement a site search facility

Providing kick ass navigation and product search is the key to success for e-commerce sites. Conversion rates highly depend on user friendly UIs which enable the shopper to find the desired product with a context sensitive search in combination with few drill-down clicks on navigational links. Unfortunately, the build-in search as well as navigation and site structure of most shopping carts simply sucks. Every online store is different, hence findability must be customizable and very flexible.

I've seen online shops crawling their product pages with a 3rd party search engine script because the shopping cart's search functionality was totally and utterly useless. Others put fantastic efforts in self made search facilities which perfectly implement real life relations beyond the limitations of the e-commerce software's data model, but need code tweaks for each and every featured product, specials, virtual shops assembling a particular niche from several product lines or whatever. Bugger.

Today I stumbled upon a very interesting approach which could become the holy grail for store owners suffering from crappy software. Progress invited me to discuss a product they've bought recently --EasyAsk-- from a search geek's perspective. Long story short, I was impressed. Without digging deep into the technology or reviewing implementations for weaknesses I think the idea behind that tool is promising.

Unfortunately, the EasyAsk Web site doesn't provide solid technical and architectural information (I admit that I may have missed the tidbits within the promotional chatter), hence I try to explain it from what I've gathered today. Progress EasyAsk is a natural language interface connecting users to data sources. Users are shoppers, and staff. Data sources are (relational) databases, or data access layers (that is a logical tier providing a standardized interface to different data pools like all sorts of databases, (Web) services, an enterprise service bus, flat files, XML documents and whatever).

The shopper can submit natural language queries like "yellow XS tops under 30 bucks". The SRP is a page listing tops and similar garments under 30.00$, size XS, illustrated with thumbnails of pics of yellow tops and bustiers, linked to the product pages. If yellow tops in XS are sold out, EasyAsk recommends beige tops instead of delivering a sorry-page. Now when a search query is submitted from a page listing suits, a search for "black leather belts" lists black leather belts for men. If the result set is too large and exceeds the limitations of one page, EasyAsk delivers drill-down lists of tags, categories and synonyms until the result set is viewable on one page. The context (category/tag tree) changes with each click and can be visualized for example as bread crumb nav link.

Technically spoken, EasyAsk does not deal with the content presentation layer itself. It returns XML which can be used to create a completely new page with a POST/GET request, or it gets invoked as AJAX request whose response just alters DOM objects to visualize the search results (way faster but not exactly search engine friendly - that's not a big deal because SERPs shouldn't be crawlable at all). Performance is not an issue from what I've seen. EasyAsk caches everything so that the server doesn't need to bother the hard disk. All points of failure (WRT performance issues) belong to the implementation, thus developing a well thought out software architecture is a must-have.

Well, that's neat, but where's the USP? EasyAsk comes with a natural language (search) driven admin interface too. That means that product managers can define and retrieve everything (attributes, synonyms, relations, specials, price ranges, groupings ...) using natural language. "Gimme gross sales of leather belts for men II/2007 compared to 2006" delivers a statistic and "top is a synonym for bustier and the other way round" creates a relation. The admin interface runs in the Web browser, definitions can be submitted via forms and all admin functions come with previews. Really neat. That reduces the workload of the IT dept. WRT ad-hoc queries as well as for lots of structural change requests, and saves maintenance costs (Web design / Web development).

I've spotted a few weak points, though. For example in the current version the user has to type in SKUs because there's no selection box. Or meta data are stored in flat files, but that's going to change too. There's no real word stemming, EasyAsk handles singular/plural correctly and interprets "bigger" as "big" or "xx-large" politically correct as "plus", but typos must be collected from the "searches without results" report and defined as synonym. The visualization of concurrent or sequentially applied business rules is just rudimentary on preview pages in the admin interface, so currently it's hard to track down why particular products get downranked respectively highlighted when more than one rule applies. Progress told me that they'll make use of 3rd party tools as well as in house solutions to solve these issues in the near future - the integration of EasyAsk into the Progress landscape has just begun.

The definitions of business language / expected terms used by consumers as well as business rules are painless. EasyAsk has build-in mappings like color codes to common color names and vice versa, understands terms like "best selling" and "overstock", and these definitions are easy to extend to match actual data structures and niche specific everyday language.

Setting up the product needs consultancy (as a consultant I love that!). To get EasyAsk running it must understand the structure of the customer's data sources, respectively the methods provided to fetch data from various structured as well as unstructured sources. Once that's configured, EasyAsk pulls (database) updates on schedule (daily, hourly, minutely or whatever). It caches all information needed to fulfill search requests, but goes back to the data source to fetch real time data when the search query requires knowledge of not (yet) cached details. In the beginning such events must be dealt with, but after a (short) while EasyAsk should run smoothly without requiring much technical interventions (as a consultant I hate that, but the client's IT department will love it).

Full disclosure: Progress didn't pay me for that post. For attending the workshop I got two books ("Enterprise Service Bus" by David A. Chappel and "Getting Started with the SID" by John P. Reilly) and a free meal, travel expenses were not refunded. I did not test the software discussed myself (yet), so perhaps my statements (conclusions) are not accurate.

Stumble It!

Post it to del.icio.us

Google to kill the power of links

Well, a few types of links will survive and don't do evil in Google's search index ;)    I've updated my first take on Google's updated guidelines stating paid links and reciprocal links are evil. Well, regardless whether one likes or dislikes this policy, it's already factored in - case closed by Google. There are so many ways to generate natural links ...

The official call for paid-link reports is pretty much disliked across the boards:
Google is Now The Morality Police on the Internet
Google's Ideal Webmaster: Snitch, Rake It In And Don't Deliver
Other sites can hurt your ranking
Google's Updated Webmaster Guidelines Addresses Linking Practices
Google clarifies its stance on links

More information, and discussion of paid/exchanged links in my pamphlets:
Matt Cutts and Adam Lasnik define "paid link"
Where is the precise definition of a paid link?
Full disclosure of paid links
Revise your linkage
Link monkey business is not worth a whoop
Is buying and selling links risky? (02/2006)

Stumble It!

Post it to del.icio.us

Danny Sullivan did not strip for Matt Cutts

Nope, this is not recycled news. I'm not referring to Matt asking Danny to strip off his business suit, although the video is really funny. I want to comment on something Matt didn't say recently, but promised to do soon (again).

Danny Sullivan stripped perfectly legit code from Search Engine Land because he was accused to be a spammer, although the CSS code in question is in no way deceitful.

StandardZilla slams poor Tamar just reporting a WebProWorld thread, but does an excellent job in explaining why image replacement is not search engine spam but a sound thing to do. Google's recently updated guidelines need to tell more clearly that optimizing for particular user agents is not considered deceitful cloaking per se. This would prevent Danny from stripping (code) not for Matt or Google but for lurid assclowns producing canards.

Stumble It!

Post it to del.icio.us

Google enhances the quality guidelines

Maybe todays update of Google's quality guidelines is the first phase of the Webmaster help system revamp project. I know there's more to come, Google has great plans for the help center. So don't miss out on the opportunity to tell Google's Webmaster Central team what you'd like to have added or changed. Only 14 replies to this call for input is an evidence of incapacity, shame on the Webmasters community.

I haven't had the time to write a full-blown review of the updates, so here are just a few remarks from a Webmaster's perspective. Scroll down to Quality guidelines - specific guidelines to view the updates, that means click the links to the new (sometimes overlapping) detail pages.

As always, the guidelines outline best practices of Web development, refer to common sense, and don't encourage over-interpretations (not that those are avoidable, nor utterly useless). Now providing Webmasters with more explanatory directives, detailed definitions and even examples in the "Don'ts" section is very much appreciated. Look at the over five years old first version of this document before you bitch ;)

Avoid hidden text or hidden links
The new help page on hidden text and links is descriptive and comes with examples, well done. What I miss is a hint with regard to CSS menus and other content which is hidden until the user performs a particular action. Google states "Text (such as excessive keywords) can be hidden in several ways, including [...] Using CSS to hide text". The same goes for links by the way. I wish they would add something in the lines of "... Using CSS to hide text in a way that a user can't visualize it by a common action like moving the mouse over a pointer to a hidden element, or clicking a text link or descriptive widget or icon". The hint at the bottom "If you do find hidden text or links on your site, either remove them or, if they are relevant for your site's visitors, make them easily viewable" comes close to this but lacks an example.

Susan Moskwa from Google clarifies what one can hide with CSS, and what sorts of CSS hidden stuff is considered a violation of the guidelines, in the Google forum on June/11/2007:

If your intent in hiding text is to deceive the search engines, we frown on that; if your intent is purely to improve the visual user experience (e.g. by replacing some text with a fancier image of that same text), you don't need to worry. Of course, as with many techniques, there are shades of gray between "this is clearly deceptive and wrong" and "this is perfectly acceptable". Matt [Cutts] did say that hiding text moves you a step further towards the gray area. But if you're running a perfectly legitimate site, you don't need to worry about it. If, on the other hand, your site already exhibits a bunch of other semi-shady techniques, hidden text starts to look like one more item on that list. [...] As the Guidelines say, focus on intent. If you're using CSS techniques purely to improve your users' experience and/or accessibility, you shouldn't need to worry. One good way to keep it on the up-and-up (if you're replacing text w/ images) is to make sure the text you're hiding is being replaced by an image with the exact same text.

Don't use cloaking or sneaky redirects
This sentence in bold red blinking uppercase letters should be pinned 5 pixels below the heading: "When examining [...] your site to ensure your site adheres to our guidelines, consider the intent" (emphasis mine). There are so many perfectly legit ways to do the content presentation, that it is impossible to assign particular techniques to good versus bad intent, nor vice versa.

I think this page leads to misinterpretations. The major point of confusion is, that Google argues completely from a search engine's perspective and dosn't write for the targeted audience, that is Webmasters and Web developers. Instead of all the talk about users vs. search engines, it should distinguish plain user agents (crawlers, text browsers, JavaScript disabled ...) from enhanced user agents (JS/AJAX enabled, installed and activated plug-ins ...). Don't get me wrong, this page gives the right advice, but the good advice is somewhat obfuscated in phrases like "Rather, you should consider visitors to your site who are unable to view these elements as well".

For example "Serving a page of HTML text to search engines, while showing a page of images or Flash to users [is considered deceptive cloaking]" puts down a gazillion of legit sites which serve the same contents in different formats (and often under different URLs) depending on the ability of the current user agent to render particular stuff like Flash, and a bazillion of perfectly legit AJAX driven sites which provide crawlers and text browsers with a somewhat static structure of HTML pages, too.

"Serving different content to search engines than to users [is considered deceptive cloaking]" puts it better, because in reverse that reads "Feel free to serve identical contents under different URLs and in different formats to users and search engines. Just make sure that you accurately detect the capabilities of the user agent before you decide to alter a requested plain HTML page into a fancy conglomerate of flashing widgets with sound and other good vibrations, respectively vice versa".

Don't send automated queries to Google
This page doesn't provide much more information than the paragraph on the main page, but there's not that much to explain: don't use WebPosition Gold™. Period.

Don't load pages with irrelevant keywords
Tells why keyword stuffing is not a bright idea, nothing to note.

Don't create multiple pages, subdomains, or domains with substantially duplicate content
This detail page is a must read. It starts with a to the point definition "Duplicate content generally refers to substantive blocks of content within or across domains that either completely match other content or are appreciably similar", followed by a ton of good tips and valuable information. And fortunately it expresses that there's no such thing as a general duplicate content penalty.

Don't create pages that install viruses, trojans, or other badware
Describes Google's service in partnership with StopBADware.org, highlighting the quickest procedure to get Google's malware warning removed.

Avoid "doorway" pages created just for search engines, or other "cookie cutter" approaches such as affiliate programs with little or no original content
The info on doorway pages is just a paragraph on the "cloaking and sneaky redirect" page. I miss a few tips on how one can identify unintentional doorway pages created by just bad design, without any deceptive intent. Also, I think a few sentences on thin SERP-like pages would be helpful in this context.

"Little or no original content" targets thin affiliate sites, again doorway pages, auto-generated content, and scraped content. It becomes clear that Google does not love MFA sites.

If your site participates in an affiliate program, make sure that your site adds value. Provide unique and relevant content that gives users a reason to visit your site first
The link points to the "Little or no original content" page mentioned above.

Don't trade, exchange, swap or purchase links for ranking purposes
"Buying links in order to improve a site’s ranking is in violation of Google's webmaster guidelines and can negatively impact a site's ranking in search results. [...] Google works hard to ensure that it fully discounts links intended to manipulate search engine results, such link exchanges and purchased links."

Basically that means: if you purchase a link, then make dead sure it's castrated or Google will take away the ability to pass link love from the page (or even site) linking out for green. Or don't get caught respectively denunciated by competitors (I doubt that's a surefire tactic for the average Webmaster).

Note that in the second sentence quoted above Google states officially that link exchanges for the sole purpose of manipulating search engines are a waste of time and resources. That means reciprocal links of particular types nullify each other, and site links might have lost their power too. <speculation>Google may find it funny to increase the toolbar PageRank of pages involved in all sorts of link swap campaigns, but the real PageRank will remain untouched.</speculation>

There's much confusion with regard to "paid link penalties". To the best of my knowledge the link's destination will not be penalized, but the paid link(s) will not (or no longer) increase its reputation, so that in case the link's intention got reported or discovered ex-post its rankings may suffer. Penalizing the link buyer would not make much sense, and Googlers are known as pragmatic folks, hence I doubt there is such a penalty. <speculation>Possibly Google has a flag applied to known link purchasers (sites as well as webmasters), which --if it exists-- might result in more scrupulous judgements of other optimization techniques.</speculation>


What I really like is that the Googlers in charge honestly tried to write for their audience, that is Webmasters and Web developers, not (only) search geeks. Hence the news is that Google really cares. Since the revamp is a funded project, I guess the few paragraphs where the guidelines are still mysterious (for the great unwashed), or even potentially misleading, will get an update soon. I can't wait for the next phase of this project.


Vanessa Fox creates buzz at SMX today, so I'll update this post when (if?) she blogs about the updates later on (update: Vanessa's post). Perhaps Matt Cutts will comment the updated quality guidelines at the SMX conference today, look for Barry's writeup at Search Engine Land, and SEO Roundtable as well as the Bruce Clay blog for coverage of the SMX Penalty Box Summit. Marketing Pilgrim covered this session too. This post at Search Engine Journal provides related info, and more quotes from Matt. Just one SMX tidbit: according to Matt they're going to change the name of the re-inclusion request to something like a reconsideration request.

Stumble It!

Post it to del.icio.us