Rel=next and rel=prev - how Google might be killing a spec
onderhond.com
onderhond.com
I think Google is right here. If you mark something as a sequence, it is reasonable to presume that the start of the sequence is the normal entry point, in this case the front page of your blog.
Personally, the obsession about date order in blogs is overdone. It is not a book, there are no real dependencies between chapters. My blog is not a sequence (unless I happen to say write a three part article on some subject, where there would be a short sequence here). Sure it has a date order, but semantically thats not very important. I am not self important enough to believe anyone reads it in order. If people want to read by date, you can provide a date index or calendar view, but that does not have to imply a rel=next/prev sequence on that view.
For me, if I click on a URL I want to go to that URL. I don't want the search engine or the browser deciding that I'm better off going to some other URL. Google should provide the information, let me be the driver. If this gets too annoying I'll just switch to ddg.gg.
I agree that the author is misusing prev/next if he plans to put them on ever article in his blog. Using prefetch for similar articles makes sense though.
I don't think that was ever up for debate. This is about which pages appear on search results, so you might see the url of the first page of an article instead of the last page.
This all seems overblown. If you add metadata, expect it to be used!
[1]http://googlewebmastercentral.blogspot.com/2011/09/paginatio...
Thats my interpretation of them, how it works in actual use we shall see.
Sometimes the term does not appear at all, for example if I search for "batman begins sequel" the first result is: http://www.imdb.com/title/tt0468569/ That page does not have the term "sequel" on it, but it is still the first search result. And if you view the cached version, the only word highlighted is "batman".
Very specifically, my post above addresses the comment that Google might display one url, then take you to another. That seems unlikely. Instead, you will only see the url of the page that is the search result, which may be page 1.
A web-log is, for a lot of people, a historical (chronological) record. For these cases rel=next/prev makes sense to semantically create a relationship between individual post.
I disagree. Just because the rel="prev"/rel="next" commands provide the ability to browse forward and backward through a series of documents doesn't mean that the only possible entry point is the beginning of the series. It doesn't mean that there even is a single well-defined first entry in the series. There's nothing to stop a series of links connecting into a closed loop, or to stop a single page from having multiple rel="prev" links because it appears in multiple series, or multiple rel="next" links because a previously linear series bifurcates and the user has multiple choices.
The spec makes no such claims, it just talks about sequences of documents in a very generic way. If the spec is not clear on this, it should be changed first.
And in a search context, I definitely don't agree with your interpretation of "sequence". The fact that my hit is part of a sequence is secondary to the fact that I just want to see a hit on my search query.
Mind you that I don't necessarily disagree with your nuances on the various use cases, but the current spec is clearly written to be very generic and should be interpreted as such.
Imagine applying your rule to Google Book Search. Google found the word "fizbit" on page 2031 of a book. I click on the link and Google takes me to the FIRST PAGE of the book. So I get to hunt through the book page by page until I find that word.
The same thing applies to web pages of all kinds. Here's my maxim: if Google has a result for your query to some term, then clicking on that result better take you to a page with the term on it. Otherwise Google's result was a waste of your time.
> Start: Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
It seems to me from reading Google's blog post on the subject (http://googlewebmastercentral.blogspot.com/2011/09/paginatio...) that they're basing their behavior on what they believe to be preferential to their users based on the data they've collected. Here's an example: "Because view-all pages are most commonly preferred by searchers, we do our best to surface this version..." They don't say "we are assuming view-all pages are preferred," they actually know that they are.
It's true that Google's post doesn't say something similar about why they choose to surface the first page in a sequence, but I think their reputation suggests that they have numbers to support the idea. In any case, I wouldn't assume that their behavior is based on an assumption.
In situations where user preference is key, the only option is to leave the decision to the individual user. I don't mind if Google implements this and offers it as a service to their users, but deciding based on dry statistics is never good, it leaves people frustrated and makes it impossible for authors to properly implement a spec like this.
This is about the philosophy of how we approach problems in ranking.
The appropriate question is not, "is this going to work everytime?". If that was the question, basically no one would make progress in web search ever. The web is littered with randomness and corner cases. The question is, "is this a a generally good heuristic, will it help more than it hurts, and can we detect when the heuristic fails badly?" I am guessing that if this prev/next information is used, it will be to boost the front page of an article that has SOME support for the query over the second or third or n'th page of an article that has more, but not exceptionally more support for the query.
Don't think of this as a hard if, but more like an additional weight in a summed comparison that biases towards the first page over later pages in a sequence.
I doubt there’s a company in the world that doesn’t say it does X in some document but do Y in reality. That’s the problem with documentation: it rots.