This article was originally published in Volume 4, Issue 8 (February 27, 2015) and is Copyright © 2015 Reflective Dynamics, Inc. All Rights Reserved.
This is *MY* question. It’s a completely theoretical discussion. We will all want to know the answer(s) to this question eventually. I will speculate some. It’s wild speculation. It’s unfounded speculation. I have no facts to back it up. That’s your only warning about what follows.
We already know that Google once acquired a “Reasonable Surfer Patent” (Cf. US8117209B1 - Ranking documents based on user behavior and/or feature data - Google Patents
). The patent is titled “Ranking documents based on user behavior and/or feature data”. That USER BEHAVIOR part is kind of scary (Google says they do not actually monitor user behavior). The patent describes a MODEL OF USER BEHAVIOR. The most well-known and highly-cited part of the patent is the first described feature:
“According to one aspect, a method may include generating a model based on user behavior data associated with a group of documents. The method may also include assigning weights to links based on the model, where the links may include references from first documents to second documents in a set of documents, and assigning ranks to the second documents based on ranks of the first documents and the weights assigned to the links.”
This is a PageRank-like computation within a set of documents. Call it LocalDocSet PageRank. This value would (presumably) be added to any other scores (including Core PageRank) already computed for each document in the set.
The second described feature goes thus:
“According to another aspect, a system may include means for generating a model based on user behavior data relating to links in a group of documents and feature data associated with the links. The system may also include means for assigning weights to references in a set of documents based on the model and means for assigning ranks to documents in the set of documents based on the weights assigned to the references.”
The modeling process looks at the context of links. The patent describes some of the things that MIGHT be considered:
__1] the font size of the anchor text associated with the link;
__2] the position of the link (measured, for example, in a HTML list, in running text, above or below the first screenful viewed on an 800×600 browser display, side (top, bottom, left, right) of document, in a footer, in a sidebar, etc.);
__3] if the link is in a list, the position of the link in the list;
__4] font color and/or attributes of the link (e.g., italics, gray, same color as background, etc.);
__5] number of words in anchor text associated with the link;
__6] actual words in the anchor text associated with the link;
__7] commerciality of the anchor text associated with the link;
__8] type of the link (e.g., image link);
__9] if the link is associated with an image (i.e., image link), the aspect ratio of the image;
_10] the context of a few words before and/or after the link;
_11] a topical cluster with which the anchor text of the link is associated;
_12] whether the link leads somewhere on the same host or domain;
_13] if the link leads to somewhere on the same domain, whether the link URL is shorter than the referring URL;
_14] and/or whether the link URL embeds another URL (e.g., for server-side redirection)
As for collecting user behavior data, they say:
“… The user behavior data may include, for example, information concerning users who accessed the documents, such as navigational actions (e.g., what links the users selected, addresses entered by the users, forms completed by the users, etc.), the language of the users, interests of the users, query terms entered by the users, etc. IN AN ALTERNATE IMPLEMENTATION, THE USER BEHAVIOR DATA MAY BE STORED EXTERNAL TO REPOSITORY 430 AND PROVIDED AS AN INPUT TO MODEL GENERATING UNIT 410 [emphasis is mine].
"The user behavior data might be obtained from a web browser or a browser assistant associated with clients 210. A browser assistant may include executable code, such as a plug-in, an applet, a dynamic link library (DLL), or a similar type of executable object or process that operates in conjunction with (or separately from) a web browser. The web browser or browser assistant might send information to server 220 concerning a user of a client 210.”
The second paragraph here describes what could be the process used to capture the click-behavior of informed users (people who know their clicks are being recorded) in a training or focus group. I do not believe that Google ran this in the wild.
The purpose of their user behavior model is to predict which links on a random page would most likely be clicked upon by real people. Based on these predicted behaviors, the algorithm this patent describes would assign some weighting factor (value) to each link on a page. Some links would be given more weight than others. Links most likely to be given light weights are (presumably) links that seem to be less important within the page’s design and presentation. Many links might simply be given a default weight of mediocre value simply for lack of distinguishing criteria.
GOOGLE HAS NEVER CONFIRMED THAT THIS ALGORITHM IS IN PLACE
Although you may be familiar with SEO experiments that attempt to determine which links count the most, those experiments which I have reviewed all had flaws in them. For example, when I ran my own experiments with lists of 10 links I found that the unique anchor text and PaqeRank might be passed to destinations only for links 2, 3, 6, 7, and 10. In other experiments I was able to get two links on the same page to pass different unique anchor expressions to the same destination (but this effect was hard to repeat).
So we have no usable experimental data that we can use to evaluate just how much weighting (if any) Google may be applying to links based on position, context, or presentation.
But we do know of manual actions Google has imposed through the years on Websites that were depending on “footer links”, “sitewide (blogroll/footer) links”, and other once-common linking practices. “Home page backlinks” have also led to many manual actions (and quite probably a lot of Penguin downgrades).
Hence, the patent described above may in fact be an early attempt by Google engineers to develop an automated method for identifying potentially spammy links and downgrading them. In other words, this patent may be a proof of concept for some of the engineering that went into the Penguin algorithms (yes, there was more than one).
Bill Slawski discovered that patent in 2010. Here we are in 2015 and Google has told us two months in advance that if your site doesn’t pass its mobile usability test, your site will be downgraded in the MOBILE SEARCH RESULTS (desktop rankings will be unaffected).
This patent and many other patents and technical papers from Googlers and outside search engineers make it clear that algorithms for grouping documents together by arbitrary criteria have existed for years. Google is clearly separating “good sites” (according to its own measures) from “bad sites” with the Panda algorithm, and now they are separating “mobile-friendly” pages from “non-mobile-friendly” pages with the April 21  update.
IS A MOBILE LINK IMPORTANT TO USERS?
It should be trivial for Google to look at a link and determine if it’s less likely to be useful to a mobile user than to a desktop user. I am not saying the link is spammy. I am merely suggesting that Google may already be thinking in terms of “which links will a mobile user most likely click on”.
Now, given that we don’t know whether they are weighting links based on the criteria listed above, we have no reason to argue that they could be breaking out the mobile-usable links from the mobile-unusual links. But, frankly my dears, THAT IS WHAT I WOULD DO if I were running Google’s search teams.
So the million-dollar question is this: given that they can already assess and downgrade pages for not being mobile-friendly, what happens to the value of those links within the Mobile Search environment? Google does not have to do anything with the links if it merely downgrades pages on the basis of its simplistic usability testing.
But what if they have looked at connectivity between mobile-compatible pages and non-mobile-compatible pages? What if they have found that links mobile users are unlikely to click on point to content that is unlikely to be of interest to mobile surfers?
ONLY TIME WILL TELL …
I’m not sure yet of how one should go about testing for this. At the very least we will have to wait until April 21 to see what the effects are. But you could try placing a link on a high-value page that uses RELATIVELY UNIQUE ANCHOR TEXT to point to a destination. You don’t want unique anchor text because that would mean Google has to show you the destination in the first page of its mobile search results.
With relatively unique anchor text you want the destination to rank in the top 5-10 results in desktop search for the anchor expression. You would have to set up multiple sets of source-destination links to look for a pattern that can be confirmed. Combinations would include:
__1] Mobile-friendly Source to non-mobile-friendly Destination
__2] Non-mobile-friendly Source to Mobile-friendly Destination
__3] Mobile-friendly Source to Mobile-friendly Destination
__4] Non-mobile-friendly Source to non-mobile-friendly Destination
Maybe two sets of documents for each condition would tell you if further investigation is worthwhile.
BUT THAT WAS ALL FEAR-MONGERING, WASN’T IT?
Of course, Google may be doing nothing about links within mobile context now and they might differentiate those links at a later time. I can see how clustering might occur naturally within sets of mobile-friendly documents because there is hardly any screen space to spare. People tend to place far fewer links in mobile-friendly themes. Responsive themes (which resize themselves according to the screen size) are an entirely different issue.
In other words, I doubt you could conduct an experiment like this with a Responsive Theme because it includes all the content that is included on the desktop version (including all the links). You might have to run the experiment twice, once with Responsive themes and once without them.
But even in a responsive environment Google may stiill have a model that predicts which links are most likely to be used by a smart phone surfer as opposed to a desktop surfer.
If we assume for the sake of discussion that someone can show that mobile-friendly links carry more weight than non-mobile-friendly links, you might just have a better indicator of link value within Google’s index than anything I have seen in years (since maybe the days when they were updating the Toolbar PageRank on a monthly basis).
This is something to think about. I would not start changing link acquisition strategies any time soon. But you definitely want to keep an eye out for signs of links failing to pass value in the mobile search environment after April 20.
COMMENT FROM 2021
Well, it’s been more than 6 years and we (Reflective Dynamics and our newsletter subscribers) have learned a few more things about how Google handles search results and its index.
*=> How PageRank is passed hasn’t changed.
If a document is in the index, it can (theoretically) pass PageRank. Whether it’s mobile-friendly has no effect on that ability.
*=> How a document appears in any given search result doesn’t indicate whether it’s lost the ability to pass PageRank.
The search results listings are selected on the basis of relevance and quality determination. But once a document gets into the selection set, its ranking is determined by many other signals (in additional to relevance and quality signals) including those that comprise “search context”. So what ranks 5th for you may rank 1st for me, and vice versa. Its linking power doesn’t change.
*=> Google is still indexing desktop-only content.
And the links in those documents -CAN- pass value. We’ve seen this happen many times over the past few years.
The final word on this question is that - for now - Google isn’t differentiating between mobile- and desktop-only links. Of course, that can change at any time.