How much does a domain’s age affect its ranking?
This is how google explain how the domain age effect ranking. The answer is: the age doesn't affect ranking.
What make the difference is the quality of the contents and the links going in and out.
CSS3 Solutions for Internet Explorer
CSS3 is probably the hottest trend in web design right now, allowing developers the opportunity to implement a number of solutions into their projects with some very straightforward CSS while avoiding having to resort to nonsemantic markup, extra images, and complex JavaScript. Unfortunately, it’s not a surprise that Internet Explorer, even in its most recent version, still does not support the majority of the properties and features introduced in CSS3.
Experienced developers understand that CSS3 can be added to new projects with progressive enhancement in mind. This ensures that content is accessible while non-supportive browsers fall back to a less-enhanced experience for the user.
But developers could face a situation where a client insists that the enhancements work cross-browser, demanding support even for IE6. In that case, I’ve collected together a number of options that developers can consider for those circumstances where support for a CSS3 feature is required for all versions of Internet Explorer (IE6, IE7, & IE8 — all of which are still currently in significant use).
Opacity / Transparency
I think all developers are baffled at why Internet Explorer still fails to support this very popular (albeit troublesome) property. It’s been around so long, that we often forget that it’s actually a CSS3 property. Although IE doesn’t offer support for the opacity property, it does offer similar transparency settings via the proprietary filter property:
The Syntax
#myElement {
opacity: .4; /* other browsers */
filter: progid:DXImageTransform.Microsoft.Alpha(opacity=40); /* this works in IE6, IE7, and IE8 */
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=40)"; /* this works in IE8 only */
}
You really only need the second line, which works in all three versions of Internet Explorer. But if for some reason you needed the opacity setting to apply only to IE8, and not to IE6/7, then you can use the third line, which the older versions don't recognize.
The opacity value at the end of each IE line works basically the same way that the opacity property does, taking a number from 0 to 100 (the opacity property takes a two-digit number from 0 to 1, so "44" for IE would be "0.44" for the others). Also, as many have experienced when using opacity (even when using the standard method), the opacity settings will be inherited by all child elements, for which there is no easy workaround.
The Drawbacks
The filter property is a Microsoft-only property, so your CSS won’t validate
As is the case for the opacity property, the IE filter causes all child elements to inherit the opacity
Rounded Corners (border-radius)
The border-radius property (more commonly referred to as CSS3 rounded corners) is another popular CSS3 enhancement. This property has allowed developers to avoid the headache of bloated JavaScript or extra positioned elements to achieve the same effect. But once again, Microsoft doesn’t want to cooperate, so IE doesn’t have any support for this property.
Fortunately, at least one person has come up with a very usable workaround that can be used in an IE-only stylesheet. Remiz Rahnas of HTML Remix has created an HTC file called CSS Curved Corner that can be downloaded off Google Code.
The great thing about this piece of code is that it doesn’t require any extra maintenance if you adjust the amount of radius on your rounded corners. You just link to the file in your CSS, and the script will automatically parse your CSS to find the correct radius value from the standard border-radius property.
The Syntax
Here’s what your code might look like:
.box-radius {
border-radius: 15px;
behavior: url(border-radius.htc);
}
The way it works is pretty straightforward, as shown above. Ideally, however, you would apply the behavior property in an IE-only stylesheet, using the same selector in your CSS, so the code knows where to get the radius value from.
The Drawbacks
The HTC file is 142 lines (minifying or GZipping would help, but it’s still extra bloat)
The behavior property will make your CSS invalid
Your server needs to be able to load HTC files for this technique to work
IE8 seems to have some trouble in some circumstances when the HTC file forces the curved element to have a negative z-index value
Box Shadow
The box-shadow property is another useful CSS3 feature that will even add a curved box shadow naturally to an element that uses the border-radius property. IE doesn’t support box-shadow, but a filter is available that offers a close replication.
It should be noted that the box-shadow property has been removed from the CSS3 Backgrounds and Borders Module, so its future in CSS3 seems to be a little uncertain right now.
The Syntax
.box-shadow {
-moz-box-shadow: 2px 2px 3px #969696; /* for Firefox 3.5+ */
-webkit-box-shadow: 2px 2px 3px #969696; /* for Safari and Chrome */
filter: progid:DXImageTransform.Microsoft.Shadow(color='#969696', Direction=145, Strength=3);
}
As shown above, in addition to the proprietary WebKit and Mozilla properties, you can add a shadow filter that works in all versions of Internet Explorer.
The Drawbacks
The settings for the IE shadow filter do not match those of the other proprietary properties, so in order to make it look the same, you have to fiddle with the values until you get it right, which can cause maintenance headaches
The filter property doesn’t validate, but neither do the WebKit and Mozilla properties, so this is a drawback in all browsers
Text Shadow
Adding drop shadows to text elements has been practiced in both print and web design for years. On the web, this is normally done with images and occasionally with text duplication combined with positioning. CSS3 allows developers to easily add shadows to text using a simple and flexible text-shadow property.
Unfortunately, there doesn’t seem to be an easy way to add a text shadow in Internet Explorer — even with the use of proprietary filters. To deal with this problem, a Dutch front-end developer named Kilian Valkhof has written a jQuery plugin that implements text shadows in Internet Explorer.
The Syntax
First, in your CSS, you would set the text-shadow property:
.text-shadow {
text-shadow: #aaa 1px 1px 1px;
}
The values specify the shadow color, position on the horizontal axis, position on the vertical axis, and the amount of blur.
After including the jQuery library and the plugin in your document, you can call the plugin with jQuery:
// include jQuery library in your page
// include link to plugin in your page
$(document).ready(function(){
$(".text-shadow").textShadow();
});
The plugin also allows the use of parameters to override the CSS. See the plugin author’s original web page for more details on the parameters.
Although there is a cross-browser jQuery plugin that applies drop shadows, the one I’m demonstrating above actually utilizes the CSS3 value that’s already set in your CSS, so it has the advantage of working along with the standard CSS setting for text shadows, whereas the other plugin needs to be set independently.
The Drawbacks
There are some significant drawbacks to this method that make it very unlikely to ever be practical. You’re probably better off creating an image to replace the text for IE instead.
In order to make the shadow look almost the same in IE, you need to use different settings in an IE-only stylesheet, adding to development and maintenance time
Requires that you add the jQuery library, in addition to a 61-line plugin file (GZipping or minifying would help)
The IE version of the shadow never looks exactly the same as the other browsers
When using the overriding parameters, the plugin seems to be rendered somewhat useless, displaying a big ugly shadow that won’t change with new values
Unlike the CSS3 version, the plugin doesn’t support multiple shadows
For some reason, in order to get it to work in IE8, you need to give the element a z-index value
Transparent Background Colors (RGBA)
CSS3 offers another method to implement transparency, doing so through an alpha channel that’s specified on a background color. Internet Explorer offers no support for this, but this can be worked around.
The Syntax
The solution for this is not the greatest, but is a legitimate method. For the CSS3-compliant browsers, here’s the syntax to set an alpha channel on the background of an element:
#rgba p {
background: rgba(98, 135, 167, .4);
}
With the above CSS, the background color will be set to the RGB values shown, plus the optional “alpha” value of “.4″. To mimic this in Internet Explorer, you can use a semi-transparent 1-pixel PNG image set as a repeating background in an IE-only stylesheet, which would override the previous setting. The PNG can be set to the same level of transparency when the image is created:
#rgba p {
background: transparent url(rgba-ie.png) repeat 0 0;
}
The repeating PNG image will look exactly the same in IE as in other browsers, duplicating the RGBA transparency effect.
The Drawbacks
Maintenance requires creation of a new PNG file every time the color or transparency is adjusted
Adds an extra HTTP request by referencing the image instead of a color value
IE6 doesn’t support PNG transparency natively, so a JavaScript hack is needed, which is a little trickier to achieve with backgrounds and will add two more HTTP requests
Gradients
Another practical and time-saving technique introduced in CSS3 is the ability to create custom gradients as backgrounds. Although Internet Explorer doesn’t support gradients of the CSS3 variety, it’s pretty easy to implement them for the IE family using proprietary syntax.
The Syntax
To declare a gradient that looks the same in all browsers, including all versions of Internet Explorer, use the CSS shown below (the last two lines are for IE):
#gradient {
background-image: -moz-linear-gradient(top, #81a8cb, #4477a1); /* Firefox 3.6 */
background-image: -webkit-gradient(linear,left bottom,left top,color-stop(0, #4477a1),color-stop(1, #81a8cb)); /* Safari & Chrome */
filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#81a8cb', endColorstr='#4477a1'); /* IE6 & IE7 */
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#81a8cb', endColorstr='#4477a1')"; /* IE8 */
}
For the IE filters, the GradientType can be set to “1″ (horizontal) or “0″ (vertical).
The Drawbacks
Some of the usual drawbacks apply to gradients created with the IE-only filter, along with some other problems.
Your CSS won’t validate, although that’s also true for the WebKit and Mozilla values
Different code is needed for IE8, adding to maintenance time
The WebKit and Mozilla gradients allow for “stops” to be declared; this doesn’t seem to be possible with the IE gradient, limiting its flexibility
IE’s filter doesn’t seem to have a way to declare “radial” gradients, which WebKit and Mozilla support
For a gradient to be visible in IE, the element with the gradient must have layout
Multiple Backgrounds
This is another CSS3 technique that, when widely supported, could prove to be a very practical addition to CSS development. Currently, IE and Opera are the only browsers that don’t support this feature. But interestingly, IE as far back as version 5.5 has allowed the ability to implement multiple backgrounds on the same element using a filter.
The Syntax
You might recall trying to hack a PNG in IE6 and noticing the image you were trying to hack appearing twice, which you had to remove by adding background: none, then applying the filter. Well, using the same principle, IE allows two background images to be declared on the same element.
To use multiple backgrounds in Firefox, Safari, and Chrome, here’s the CSS:
#multi-bg {
background: url(images/bg-image-1.gif) center center no-repeat, url(images/bg-image-2.gif) top left repeat;
}
To apply two backgrounds to the same element in IE, use the following in an IE-only stylesheet:
#multi-bg {
background: transparent url(images/bg-image-1.gif) top left repeat;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader (src='images/bg-image-2.gif', sizingMethod='crop'); /* IE6-8 */
-ms-filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='images/bg-image-2.gif', sizingMethod='crop')"; /* IE8 only */
}
The Drawbacks
Your CSS will be invalid
The second background image applied using the filter property will always be in the top left, and cannot repeat, so this method is extremely inflexible and can probably only be used in a limited number of circumstances
In order to get the element to center (as in other browsers), you have to create an image with the exact amount of whitespace around it, to mimic the centering, as I’ve done in the demonstration above
Element Rotation (CSS Tranformations)
CSS3 has introduced a number of transformation and animation capabilities, which some have suggested are out of place in CSS. Nonetheless, there is a way to mimic element rotation in Internet Explorer, albeit in a limited fashion.
The Syntax
To rotate an element 180 degrees (that is, to flip it vertically), here is the CSS3 syntax:
#rotate {
-webkit-transform: rotate(180deg);
-moz-transform: rotate(180deg);
}
To create the exact same rotation in Internet Explorer, you use a proprietary filter:
#rotate {
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=2);
}
The value for the rotation can be either 1, 2, 3, or 4. Those numbers represent 90, 180, 270, or 360 degrees of rotation respectively.
The Drawbacks
Your CSS won’t validate, although that’s also true for the WebKit and Mozilla code
While the Mozilla and WebKit code allows for rotation changes to increment by a single degree, the IE filter only permits 4 stages of rotation, minimizing its flexibility
Conclusion
Developers might hate me for compiling this list, seeing as any client could search for “CSS3 in Internet Explorer” and stumble across this page. So be careful what you tell your clients; although IE does not support these things natively, that doesn’t mean they’re impossible to implement.
And remember that anytime you need to override the initial CSS settings for IE, or if you have to use JavaScript, jQuery, or an HTC file, make sure the calls to the external resources are made using IE conditional comments. This will ensure the other browsers aren’t making unnecessary HTTP requests.
In many cases, the best solution for dealing with Internet Explorer is to let it display a less-enhanced experience. I hope, however, the above solutions provide some options for working with CSS3 when a client wants a more accurate cross-browser experience.
FROM:http://www.smashingmagazine.com/2010/04/28/css3-solutions-for-internet-explorer/
So You’d Like to Send Some Email (Through Code)
I have what I would charitably describe as a hate-hate relationship with email. I desperately try to avoid sending email, not just for myself, but also in the code I write.
Despite my misgivings, email is the cockroach of communication mediums: you just can't kill it. Email is the one method of online contact that almost everyone -- at least for that subset of "everyone" which includes people who can bear to touch a computer at all -- is guaranteed to have, and use. Yes, you can make a fairly compelling case that email is for old stupid people, but let's table that discussion for now.
So, reluctantly, we come to the issue of sending email through code. It's easy! Let's send some email through oh, I don't know, let's say ... Ruby, courtesy of some sample code I found while browsing the Ruby tag on Stack Overflow.
require 'net/smtp'
def send_email(to, subject = "", body = "")
from = "my@email.com"
body= "From: #{from}\r\nTo: #{to}\r\nSubject: #{subject}\r\n\r\n#{body}\r\n"
Net::SMTP.start('192.168.10.213', 25, '192.168.0.218') do |smtp|
smtp.send_message body, from, to
end
end
send_email "foo@example.com", "title", "body goes here"
There's a bug in this code, though. Do you see it?
Just because you send an email doesn't mean it will arrive. Not by a long shot. Bear in mind this is email we're talking about. It was never designed to survive a bitter onslaught of criminals and spam, not to mention the explosive, exponential growth it has seen over the last twenty years. Email is a well that has been truly and thoroughly poisoned -- the digital equivalent of a superfund cleanup site. The ecosystem around email is a dank miasma of half-implemented, incompletely supported anti-spam hacks and workarounds.
Which means the odds of that random email your code just sent getting to its specific destination is .. spotty. At best.
If you want email your code sends to actually arrive in someone's AOL mailbox, to the dulcet tones of "You've Got Mail!", there are a few things you must do first. And most of them are only peripherally related to writing code.
1. Make sure the computer sending the email has a Reverse PTR record
What's a reverse PTR record? It's something your ISP has to configure for you -- a way of verifying that the email you send from a particular IP address actually belongs to the domain it is purportedly from.
Not every IP address has a corresponding PTR record. In fact, if you took a random sampling of addresses your firewall blocked because they were up to no good, you'd probably find most have no PTR record - a dig -x gets you no information. That's also apt to be true for mail spammers, or their PTR doesn't match up: if you do a dig -x on their IP you get a result, but if you look up that result you might not get the same IP you started with.
That's why PTR records have become important. Originally, PTR records were just intended as a convenience, and perhaps as a way to be neat and complete. There still are no requirements that you have a PTR record or that it be accurate, but because of the abuse of the internet by spammers, certain conventions have grown up. For example, you may not be able to send email to some sites if you don't have a valid PTR record, or if your pointer is "generic".
How do you get a PTR record? You might think that this is done by your domain registrar - after all, they point your domain to an IP address. Or you might think whoever handles your DNS would do this. But the PTR record isn't up to them, it's up to the ISP that "owns" the IP block it came from. They are the ones who need to create the PTR record.
A reverse PTR record is critical. How critical? Don't even bother reading any further until you've verified that your ISP has correctly configured the reverse PTR record for the server that will be sending email. It is absolutely the most common check done by mail servers these days. Fail the reverse PTR check, and I guarantee that a huge percentage of the emails you send will end up in the great bit bucket in the sky -- and not in the email inboxes you intended.
2. Configure DomainKeys Identified Mail in your DNS and code
What's DomainKeys Identified Mail? With DKIM, you "sign" every email you send with your private key, a key only you could possibly know. And this can be verified by attempting to decrypt the email using the public key stored in your public DNS records. It's really quite clever!
The first thing you need to do is generate some public-private key pairs (one for every domain you want to send email from) via OpenSSL. I used a win32 version I found. Issue these commands to produce the keys in the below files:
$ openssl genrsa -out rsa.private 1024
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
These public and private keys are just big ol' Base64 encoded strings, so plop them in your code as configuration string resources that you can retrieve later.
Next, add some DNS records. You'll need two new TXT records.
_domainkey.example.com
"o=~\; r=contact@example.com"
selector._domainkey.example.com
"k=rsa\; p={public-key-base64-string-here}"
The first TXT DNS record is the global DomainKeys policy and contact email.
The second TXT DNS record is the public base64 key you generated earlier, as one giant unbroken string. Note that the "selector" part of this record can be anything you want; it's basically just a disambiguating string.
Almost done. One last thing -- we need to sign our emails before sending them. In any rational world this would be handled by an email library of some kind. We use Mailbee.NET which makes this fairly painless:
smtp.Message = dk.Sign(smtp.Message,
null, AppSettings.Email.DomainKeyPrivate, false, "selector");
3. Set up a SenderID record in your DNS
To be honest, SenderID is a bit of a "nice to have" compared to the above two. But if you've gone this far, you might as well go the distance. SenderID, while a little antiquated and kind of.. Microsoft/Hotmail centric.. doesn't take much additional effort.
SenderID isn't complicated. It's another TXT DNS record at the root of, say, example.com, which contains a specially formatted string documenting all the allowed IP addresses that mail can be expected to come from. Here's an example:
"v=spf1 a mx ip4:10.0.0.1 ip4:10.0.0.2 ~all"
You can use the Sender ID SPF Record Wizard to generate one of these for each domain you send email from.
That sucked. How do I know all this junk is working?
I agree, it sucked. Email sucks; what did you expect? I used two methods to verify that all the above was working:
Test emails sent to a GMail account.
Use the "show original" menu on the arriving email to see the raw message content as seen by the email server. You want to verify that the headers definitely contain the following:
Received-SPF: pass
Authentication-Results: ... spf=pass ... dkim=pass
If you see that, then the Reverse PTR and DKIM signing you set up is working. Google provides excellent diagnostic feedback in their email server headers, so if something isn't working, you can usually discover enough of a hint there to figure out why.
Test emails sent to the Port25 email verifier
Port25 offers a really nifty public service -- you can send email to check-auth@verifier.port25.com and it will reply to the from: address with an extensive diagnostic! Here's an example summary result from a test email I just sent to it:
SPF check: pass
DomainKeys check: fail
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham
You want to pass SPF, DKIM, and Sender-ID. Don't worry about the DomainKeys failure, as I believe it is spurious -- DKIM is the "newer" version of that same protocol.
Yes, the above three steps are quite a bit of work just to send a lousy email. But I don't send email lightly. By the time I've reached the point where I am forced to write code to send out email, I really, really want those damn emails to arrive. By any means necessary.
And for those who are the unfortunate recipients of these emails: my condolences.
FROM:http://www.codinghorror.com/blog/2010/04/so-youd-like-to-send-some-email-through-code.html
Real Fonts and Rendering: The New Elephant in the Room
My friend, the content strategist Kristina Halvorson, likes to call content “the elephant in the room” of web design. She means it’s the huge problem that no one on the web development team or client side is willing to acknowledge, face squarely, and plan for.
A typical web project will pass through many helpful phases of research, and numerous beneficial user experience design iterations, while the content—which in most cases is supposed to be the site’s primary focus—gets handled haphazardly at the end. Hence, elephant in the room, and hence also artist Kevin Cornell’s recent use of elephantine imagery to illustrate A List Apart articles on the subject. But I digress.
Without discounting the primacy of the content problem, we web design folk have now birthed ourselves a second lumbering mammoth, thanks to our interest in “real fonts on the web“ (the unfortunate name we’ve chosen for the recent practice of serving web-licensed fonts via CSS’s decade-old @font-face declaration—as if Georgia, Verdana, and Times were somehow unreal).
For the fact is, even bulletproof and mo’ bulletproofer @font-face CSS syntax aren’t really bulletproof if we care about looks and legibility across browsers and platforms.
Hyenas in the Breakfast Nook
The problem isn’t just that foundries have yet to agree on a standard font format that protects their intellectual property. And that, even when they do, it will be a while before all browsers support that standard—leaving aside the inevitable politics that impede all standardization efforts. Those are problems, but they’re not the elephant. Call them the coyotes in the room, and they’re slowly being tamed.
Nor is the problem that workable, scalable business models (of which Typekit‘s is the most visible and, so far, the most successful) are still being shaken out and tested. The quality and ease of use of such services, their stability on heavily visited sites (via massively backed-up server clusters), and the fairness and sustainability of their pricing will determine how licensing and serving “real fonts” works in the short and long term for the majority of designer/developers.
Nor is our primary problem that developers with no design background may serve ugly or illegible fonts that take forever to load, or fonts that take a long time to download and then display as ordinary system fonts (as happens on, say, about.validator.nu). Ugliness and poor optimization on the web are nothing new. That support for @font-face in Webkit and Mozilla browsers (and for TrueType fonts converted to Embedded OpenType in Internet Explorer) adds deadly weapons to the non-designer’s toolkit is not the technology’s fault. JavaScript and other essential web technologies are equally susceptible to abuse.
Beauty is in the Eye of the Rendering Engine
No, the real elephant in the room—the thing few web developers and no “web font” enthusiasts are talking about—has to do with legibility (or lack thereof) and aesthetics (or lack thereof) across browsers and platforms. Put simply, even fonts optimized for web use (which is a whole thing: ask a type designer) will not look good in every browser and OS. That’s because every browser treats hinting differently, as does every OS, and every OS version.
Firefox does its own thing in both Windows and Mac OS, and Microsoft is all over the place because of its need to support multiple generations of Windows and Cleartype and all kinds of hardware simultaneously. Thus “real type” on a single web page can look markedly different, and sometimes very bad, on different computers at the same company. If that web page is your company’s, your opinion of “web fonts” may suffer, and rightfully. (The advantage of Apple’s closed model, which not everyone likes, is that it allows the company to guarantee the quality and consistency of user experience.)
As near as my font designer friends and I can make out, Apple’s Webkit in Safari and iPhone ignores hinting and creates its own, which Apple thinks is better, and which many web designers think of as “what real type looks like.” The forked version of Webkit in Chrome, Android, and Palm Pre also creates its own hinting, which is close to iPhone’s—close enough that Apple, Palm, and Google could propose it as a standard for use in all browsers and platforms. Whether Firefox would embrace a theoretical Apple and Google standard is open to conjecture, and I somehow have difficulty imagining Microsoft buying in—even though they know the web is more and more mobile, and that means more and more of their customers are viewing web content in some version of Webkit.
The End of Simple
There are ways around this ugly type ugliness, but they involve complicated scripting and sniffing—the very nightmares from which web standards and the simplicity of @font-face were supposed to save us. I don’t know that even mighty Typekit has figured out every needed variation yet (although, working with foundries, they probably will).
For type foundries, the complexity and expense of rethinking classic typefaces to survive in these hostile environments may further delay widespread adoption of web fonts and the resolution of licensing and formatting issues. The complexity may also force designers (even those who prefer to own) to rely on a hosted rental model simply to outsource and stay current with the detection and programming required.
Forgive my tears. I stand in a potter’s field of ideas like “Keep it simple,” by a grave whose headstone reads “Write once, publish everywhere.”
FROM: http://24ways.org/2009/real-fonts-and-rendering
How a Search Engine May Identify Undesirable Web Pages By Analyzing Inlinks
The term “undesirable web pages” is used in a patent application from Yahoo published today to refer to pages that rank highly in search results based upon links pointed to those pages solely for the purpose of increasing their rankings for specific queries even though those pages may not be very relevant for the query terms in question.
“Undesirable” appears to indicate that these are pages that Yahoo doesn’t want ranking well in search results at their search engine.
So, what might Yahoo (and possibly other search engines) look at to determine whether a page is undesirable based upon the links it sees to that page?
Analyzing Inlinks for Manipulation
When search engines show pages to searchers in response to a query, those pages are placed in an order intended to show pages that are a combination of relevance and importance or quality.
One way that search engines determine how important a page might be is based upon the number and importance of pages linking to that page. Search engines may also pay attention to the text used in a link, often referred to as “anchor text,” while determining how relevant a page might be for a certain keyword term or phrase.
But there’s a problem in relying too much upon links pointing to pages to determine how relevant and important a page might be. By giving links such value, the search engines have turned links into a commodity that may determine how highly a page might rank in search results.
Many links pointing to pages are created not to bring direct traffic to a page, or to refer to a page in a specific context, but rather solely to improve the ranking of a page, and may result in “artificially promoted web pages” ranking highly in search results even though those pages may not be very relevant to a query by a searcher.
In response to this problem, search engines may weigh the value of some links differently. The patent application from Yahoo describes how that search engine might distinquish between links pointing to a page, also known as “inlinks” to that page, based upon a statistical analysis of information about those links.
The patent filing is:
Detection of Undesirable Web Pages
Inventws by Gilbert Leung, Lei Duan, Dmitri Pavlovski, Su Han Chan, and Kostas Tsioutsiouliklis
Assigned to Yahoo
US Patent Application 20100094868
Published April 15, 2010
Filed October 9, 2008
Abstract
A system for detecting artificial promotion of a resource, including:
a search engine operative to index a set incoming links (”inlinks”) which reference the resource,
a log module coupled with the search engine and configured to store log data associated with the set of inlinks,
a partitioning module coupled with log module and operative to partition the set of inlinks into a plurality of groups of inlinks based on at least one partitioning scheme,
a statistics module coupled with the partitioning module and operative to compute a statistic associated with the inlinks within each of the plurality of groups of inlinks, and
a computation module coupled with the statistics module and operative to process the computed statistic associated with the inlinks of each of the plurality of groups of inlinks and compute a metric associated with set of inlinks where the metric indicates a level of uniformity of a distribution of values of the respective computed statistics among the plurality of groups of inlinks, and where the search engine places a list of search results, generated in response to a search query, in a pattern based on the metric.
In analyzing links pointing to a page to try to identify the artificial manipulation of links, the search engine may look at information associated with those links to try to see if there are any unnatural patterns associated with those links.
The search engine might look at information such as:
* An internet protocol (IP) address segment of the source of each inlink
* the domain name of a source of each inlink
* The top-level domain name associated with each inlink such as “.com” or “.edu” or country code top level domains
* The written language used in each inlink (e.g., English, French, or German)
* A geographic region associated with the source of each inlink
* A network routing group associated with the source of each inlink
* The anchor text (i.e., the clickable text) contained within each inlink
The patent filing tells us that a quality or importance ranking score might be given to pages based upon link-based ranking approaches such as PageRank, or a system that gives more weight to newer links and less to older, or some other kind of algorithms.
A statistical analysis of information about links pointing to a page over time may result in a demotion of ranking of that page if abnormal patterns appear that seem to indicate that links to a page have been manipulated solely to increase the ranking of that page.
Conclusion
I’ve written about a number of other patents and whitepapers from the major search engines that can be found in my category on Web Spam, but this Yahoo patent filing provides details about some specific kinds of information that Yahoo might analyze that many of those papers or patent filings haven’t mentioned.
Chances are that Google and Bing may perform some similar types of analysis when looking at links pointing to pages.
FROM: http://www.seobythesea.com/?p=3729