MAILE OHYE: Hi.
I'm Maile Ohye.
I've been at Google now for over six years, working with
Search and with Webmaster Tools.
I'd like to welcome you to my home.
Let's chat about pagination and SEO.
For today's agenda, we'll first start with some
paginated content examples.
Then we'll get into some of the negative side effects of
pagination and why you as a webmaster might want to make
some effort as to not dilute your indexing properties and
to show better results to users.
Then we'll cover your configuration.
And this comes in two parts--
for those of you webmasters with paginated content and a
view-all page available, and then for those of you
webmasters that have paginated content but
without a view-all page.
So there's going to be two types of configurations there.
Then we're going to step back a little bit and talk about
what Google is doing to help users with paginated content
and webmasters as well.
And then last, given your configuration, whether you
have a view-all page available or you have no view-all page
available, we'll look at the options that you have for your
paginated content.
So let's go ahead and start with some
paginated content examples.
Paginated content exists throughout the web, and I'm
going to cover two of those common cases.
One is a paginated article.
So let's say you go to your favorite content site, and you
see the breaking news story.
"New studies prove that cookies are superior nutrition
to vegetables." And that would be quite the story.
But your favorite site might not put this all on one page,
but instead, paginate it into several component pages.
Now this one article has become three, and this is an
example of paginated content articles.
Another example of pagination is for things like a product
category, like what you would see on your favorite
e-commerce site.
So let's say this webmaster is selling shapes.
They're selling six types of shapes.
But rather than have it all on one page, they have divided it
into two component pages, both of them with shapes, creating
pagination again.
So two common ways are with paginated content articles and
with paginated product categories.
Now, what are some of the negative side effects of this?
Well, there's a couple.
So I'd like to highlight two, the first being that indexing
properties, like links and anchor text, can be diluted
into the different component URLs rather than being
consolidated to the one article or to
the one product category.
So that's one of the negative side effects.
The other is that the most relevant page in the series
might not be reflected in search results.
So if you're the webmaster for this e-commerce site, you
might want users to be sent to page one, say, of your series.
But because search engines see this pagination as three
separate entities, searchers might be sent to a different
page that might not be the most relevant.
So those are a few of the negative side effects of
pagination.
Now let's talk more about your situation and the
configuration you have on your site.
We're going to look at this in terms of two different types
configurations.
One is with a view-all page available, and the other is
with no view-all page available.
Now, if your site has paginated content with a
view-all page available, there are a couple of things you
want to make sure you test for.
One is make sure that you have still decent latency on your
site meaning that, if a user clicks on the view-all
version, that it doesn't take them 15 seconds to load
because it's such a long article, or
it's so many products.
But that they still have a good experience--
say, the page only takes four seconds to load.
The second thing to check for if you have a view-all page
available is to make sure that the page remains easily
navigable, meaning that users can still find the content
that they want or the particular product that they
want by easily scrolling or viewing headings.
So that's the configuration of a view-all page available.
And then obviously, without a view-all page available, it's
fairly straightforward.
So think about your site in terms of configuration you
have. But before we go there, let's take a step back and
talk a little bit about what Google is doing.
We're, of course, always working to improve the
experience for searchers.
And one thing that we found through testing is that our
searchers prefer seeing the view-all page in their search
results opposed to an individual component page.
And one reason for this might be because of latency.
So if you take search results and you click on a result to a
view-all page, while that might take, say, three seconds
to load that article that new studies prove that cookies are
superior nutrition to vegetables, that might be
three seconds.
But on the other hand, searchers were less happy when
search results took them to just page one of the article.
While that might have just had two seconds of latency and
then the page loaded, every time that user wanted to click
Next to read more of the article, it caused some
additional load time.
So because of this latency and other reasons, searches prefer
the view-all page.
So given this knowledge, one of our engineers on indexing,
Benjia Li, actually came out with a new feature
in October of 2011.
This is--
"When we detect that a paginated series also contains
a view-all version, we're now making a larger effort to
return the view-all page in search results when
appropriate." So that's great for searchers.
And what's even better for webmasters is that while we
detect this view-all page, we'll also still consolidate
indexing properties, like links, to the view-all page.
So again, this is good for searchers and good for you as
webmasters for all that indexing consolidation.
Now, let's talk about some of the options that you have as a
webmaster with paginated content.
We're first going to look at the situation where webmasters
have paginated the content and a view-all page available.
But for those of you that have no view-all page available,
it's still good if you pay attention because some of
these options will apply to you as well.
So you have a site with paginated content and a
view-all page, you have three good options.
First, you can leave as is.
There's nothing that you have to do if you have other
priorities on your site.
Paginated content exists throughout the web, and search
engines will continue to do an even better
job of handling it.
And as I mentioned earlier, if you have a view-all page
available, Google will automatically try to detect
that, send searchers there, as well as consolidate your
indexing properties.
So option one is a very solid option.
But you also have a second option.
The second option is to actually use rel="canonical"
to explicitly hint to Google what is your view-all page.
So while we try to detect it algorithmically, you can also
tell us by writing rel="canonical" on your
component pages to your view-all version.
And this is kind of a more explicit hint to us about how
your site is configured.
With the rel="canonical," as many of you already know,
we'll of course consolidate the indexing properties from
the component pages with the canonical version.
So things like links will also be transferred.
And then, of course, we'll send users to
the view-all page.
So that's option number two.
The last option is actually done by two of our engineers,
Joachim and Benjia.
And what this is is using the standard HTML markup of
rel="next" and rel="prev" on the component pages in your
series to signal to Google that these are individual
pages, but they all belong to one series.
So by adding this rel="next" and rel="prev" markup, you
connect these individual components into one.
You can do this by adding rel="next" to page one and
then rel="prev" and rel="next" to page two, all the way to
the last page, which only includes a rel="prev".
And then, of course, on your view-all
page, nothing is needed.
rel="next" and rel="prev" is standard HTML markup, and it's
been around for years.
But now, Google is using this markup for webmasters to let
us know about their paginated content.
So let me explain some ways that rel="next"
and rel="prev" work.
With rel="next" and rel="prev," much like you see
with something like rel="canonical," we'll
actually consolidate indexing properties from the component
pages of the series.
And in addition, unlike rel="canonical" that only
shows the view-all page in search results, with
rel="next" and rel="prev," we're going to override that
behavior and send users to only one of
the component pages.
Most likely, this will be page one, because commonly that's
the most relevant page.
So now if you have, say, that product category, selling
shapes, if you use the rel="next" and rel="prev"
markup, it'll tell us that these two pages
belong to one series.
And then most commonly, we'll send users to page one.
Know that rel="next" and rel="prev" is a strong hint.
It's not a mandate by any means.
The last thing I want to say about rel="next" and
rel="prev" is that component URLs in a series should be
consistent with their parameters.
So let's take the article of new studies prove that cookies
are superior nutrition to vegetables.
Now, let's say that these pages contain a session ID.
All of these values for rel="prev" and rel="next"
should also contain the session ID.
And this is because our indexing team looks to
actually link every page in a series with what was declared
previous and what was declared next.
And when they do that, they want to make sure-- say you're
on page two--
that the rel="prev" that states rel="prev" is
page-1&sid=123, they will go to that URL.
But that URL actually has to list page two
with the same sid.
And that's how we can link every page in the sequence.
So be sure to keep parameters throughout your entire series.
So let's recap those three options.
If you have a view-all page available, you
can leave as is.
You could also explicitly state rel="canonical" to your
view-all page.
Or you can override the view-all page behavior by
adding rel="next" and rel="prev." By adding
rel="next" and rel="prev," you will help us consolidate
component pages in a series.
But instead of sending users to a view-all page, we'll then
send searchers to one component page., most likely
page one of your series.
Now, let's talk about the configuration with no view-all
page available.
So for those of you webmasters that have paginated content
and no view-all page, you have two options.
First, of course, you can leave as is.
That's perfectly fine.
And then your second option is also to use rel="next" and
rel="prev." Again, by using rel="next" and rel="prev," it
connects the component pages in the series, and
consolidates indexing properties, and helps us to
send searchers to the most relevant page, which is likely
the first page of the series.
Now I'm going to beat you to the punch and ask one of the
most commonly asked questions about rel="canonical" as well
as rel="next," "prev." And that is why rel="next" and
rel="prev" for a paginated series rather than
rel="canonical" to page one?
Ha!
I bet you were thinking that.
The answer is that rel="canonical" is for
duplicate content.
So let's take that article.
Let's say page two of the article, cookies
are superior nutrition.
If this page actually has a session ID attached, then it
can list as the canonical the same version, the duplicate
conversion, but without a session ID Because
rel="canonical" is for duplicate content, or it's for
content which is a superset.
So here we have page one, page two, and page three, all
linking to the canonical version being
the view-all version.
And that's perfectly fine as well.
The thing about rel="canonical" is that it
only indexes content from the canonical version.
So let's go ahead and take a look at this.
If we have page two and page three, page two says "cookies
are superior nutrition," and page three says "to
vegetables".
But they both add rel="canonical"
just to page one.
And Google's index will then cluster page one, page two,
and page three all together.
But the only thing that we'll have indexed is the content
from page one, the canonical version.
So our index will actually contain "new studies prove
that."
And now by using this rel="canonical" incorrectly,
this webmaster has totally lost the content "cookies are
superior nutrition" and "to vegetables." So that's why
rel="canonical" doesn't work in this case.
But rel="next," "prev" works for a series or
a sequence of content.
So let's take those two paginated examples again.
By using rel="next" and rel="prev," we'll actually, in
Google's index, mark it as a series.
But we'll have page one, page two, and page three all
indexed separately.
So in our index, we know page one refers to "new studies
prove that," page two, "cookies are superior
nutrition," and page three, "to vegetables." And all three
pages will be indexed and marked as one series.
So that's the big difference between rel="canonical" and
rel="next" "prev."
So something to note is that rel="canonical" can actually
be used alongside rel="next" "prev." So let's take a look
at page two again.
And this time, it has a session ID.
This URL can actually list both the canonical version
without a session ID as well as a rel="prev" and rel="next"
with, of course, the same parameters, including that
session ID.
So now let's recap your new pagination toolbox.
Starting with Google, we have two new features for you.
First, we're making a better effort to detect a view-all
page, and then send searchers to that
preferred view-all version.
The second feature is if you want to actually even override
that behavior.
So for those of you with a view-all page available or
without, if you add markup with rel="next" and
rel="prev," it signals to Google that these are
component pages in a series.
We'll then consolidate indexing properties, and send
searchers to the most relevant page, most likely page one.
Now, let's get into the types of
configurations you have available.
So recapping, if you have a view-all page available, you
have three options.
You can leave as is.
You can use rel="canonical" on your component pages, pointing
to your view-all page.
Or you can override all the view-all detection by adding
rel="next" and rel="prev," telling us that these
component pages belong to a series.
And I'd like you, Google, to send searchers to the most
relevant individual page, again, likely page one.
Now, the other part of the pagination toolbox is for
those of you with no view-all available, and
you have two options.
Of course, you can leave exactly as is.
Or again, you can use rel="next" and rel="prev."
This helps you to consolidate all the component pages into
one series and send searchers to the most relevant page.
So the great thing about these pagination features is that
I've been at Google long enough to see the infancy from
when the webmaster community was talking to us about issues
with pagination until now when we have more features
available to you.
So thank you so much to all of you for your helpful feedback
and for being part of this webmaster community.
For more information on pagination, here are some
links available.
And you can, of course, join us at the Webmaster Central
Blog or in the Webmaster Discussion Forum.
Thanks for your time.
Hallo!
Ich bin Maile Ohye.
Ich arbeite jetzt schon seit über sechs Jahren bei Google
im Bereich Suche und Webmaster-Tools.
Herzlich willkommen bei mir zu Hause.
Heute möchte ich mit euch über Seitennummerierung und SEO sprechen.
Wir beginnen mit einigen Beispielen zu Inhalten
in fortlaufender Sequenz.
Dann kommen wir zu einigen negativen Aspekten der
Seitennummerierung und was ihr Webmaster tun könnt,
um eure Indexeigenschaften nicht abzuschwächen
und um Nutzern genauere Ergebnisse anzuzeigen.
Danach sprechen wir über eure Konfiguration.
Wir gehen von zwei Situationen aus:
Webmaster mit Inhalten in fortlaufender Sequenz
und einer Gesamtansicht sowie Webmaster
mit Inhalten in fortlaufender Sequenz
jedoch ohne Gesamtansicht.
Wir besprechen also zwei verschiedene Konfigurationen.
Anschließend möchte ich eine Übersicht darüber geben,
wie Google Nutzer und Webmaster bei der Verwendung von Inhalten
in fortlaufender Sequenz unterstützt.
Zum Abschluss werfen wir einen Blick auf die Optionen,
die ihr für Inhalte in fortlaufender Sequenz habt,
abhängig davon, ob ihr über eine Gesamtansicht-Seite verfügt
oder nicht.
Lasst uns loslegen mit ein paar Beispielen zu
Inhalten in fortlaufender Sequenz.
Inhalte in fortlaufender Sequenz findet man überall im Web.
Ich möchte über zwei der häufigsten Situationen sprechen.
Erstens Artikel mit nummerierten Seiten.
Ihr besucht zum Beispiel eure Lieblings-Website und seht
eine topaktuelle Meldung.
"New studies prove that cookies are superior nutrition to vegetables!"
Mehr Kekse, weniger Gemüse, das wäre doch was!
Diese Meldung wird jedoch nicht komplett auf einer
Seite angezeigt, sondern ist auf mehreren Komponentenseiten zu sehen.
Der Artikel besteht nun aus drei Teilen und ist
ein Beispiel für Inhalte in fortlaufender Sequenz.
Zweitens Produktkategorien,
die zum Beispiel auf E-Commerce-Websites
zu finden sind.
Nehmen wir an, dieser Webmaster verkauft Formen.
Es stehen sechs Formen zur Auswahl.
Sie sind jedoch nicht alle auf einer Seite zu sehen,
sondern auf zwei Komponentenseiten aufgeteilt, wodurch nummerierte
Seiten entstehen.
Zwei der häufigsten Formen von Inhalten in fortlaufender Sequenz
sind also Artikel und Produktkategorien.
Welche negativen Aspekte gilt es zu beachten?
Da gibt es einige.
Ich möchte hier zwei davon erwähnen. Zum einen verlieren Indexierungseigenschaften
wie Links und Ankertext möglicherweise an Bedeutung,
wenn sie in verschiedene Komponenten-URLs aufgeteilt werden
und nicht in einem Artikel oder einer Produktkategorie
zusammengefasst werden.
Das ist eine der negativen Nebenerscheinungen.
Noch ein negativer Punkt ist, dass die relevantesten Seiten einer Sequenz
möglicherweise nicht in den Suchergebnissen angezeigt werden.
Ihr möchtet beispielsweise als Webmaster einer E-Commerce-Website,
dass Nutzer auf die erste Seite eurer Sequenz geleitet werden.
Da die Suchmaschine diese einzelnen Seiten jedoch als separate Einheiten sieht,
werden Nutzer möglicherweise auf eine Seite geleitet,
die nicht die relevantesten Informationen enthält.
Dies sind einige der Kehrseiten von Inhalten in
fortlaufender Sequenz.
Kommen wir jetzt zur Konfiguration
eurer Website.
Wir beziehen uns hier auf zwei verschiedene
Konfigurationstypen.
Einmal mit einer Seite zur Gesamtansicht
und einmal ohne Übersichtsseite.
Wenn eure Website Inhalte in fortlaufender Sequenz enthält
und eine Gesamtansicht vorhanden ist, solltet ihr
ein paar Dinge ausprobieren.
Überprüft die Latenz eurer Website
und stellt sicher,
dass das Laden nicht 15 Sekunden dauert,
weil der Artikel so lange ist oder
es so viele Produkte sind.
Die Nutzererfahrung soll dabei nicht in den Hintergrund gestellt werden
und die Ladezeit nicht mehr als vier Sekunden dauern.
Es ist außerdem wichtig, sicherzustellen,
dass die Navigation in der Gesamtansicht nutzerfreundlich ist
und Nutzer gesuchte Inhalte
oder spezifische Produkte
ganz einfach durch Scrollen der Seite oder Anzeige von Überschriften finden.
Soviel zur Konfiguration mit einer Seite zur Gesamtansicht.
Websites ohne Gesamtansicht
sind davon natürlich nicht betroffen.
Überlegt euch also, welche Konfiguration für eure Website zutrifft.
Davor möchte ich jedoch ein wenig darüber sprechen,
was Google in diesem Zusammenhang für eine Rolle spielt.
Wir arbeiten natürlich ständig daran, Suchen so nutzerfreundlich wie möglich
zu gestalten.
Wir haben unter anderem herausgefunden,
dass Nutzer bei Suchen bevorzugt die Gesamtansicht-Seite ansehen
und nicht die einzelnen Komponentenseiten.
Ein Grund dafür ist möglicherweise die Latenz.
Wenn ein Nutzer in den Suchergebnissen zum Beispiel
auf eine Seite zur Gesamtansicht klickt,
dauert es vielleicht drei Sekunden,
den Artikel zur neuen Studie über Kekse und Gemüse
zu laden.
Nutzer waren jedoch weniger zufrieden,
wenn sie nach der Suche nur auf die erste Seite des Artikels geleitet wurden.
Die Latenz betrug hier vielleicht nur zwei Sekunden,
doch bei jedem Klick auf "Weiter", um die nächste Seite des Artikels zu lesen,
musste mit zusätzlicher
Ladezeit gerechnet werden.
Aus diesem und noch anderen Gründen bevorzugen Nutzer Gesamtansichten
in den Suchergebnissen.
Auf diese Erkenntnisse aufbauend hat einer unserer
Indexierungs-Entwickler Benjia Li, im Oktober 2011
eine neue Funktion entwickelt.
Und zwar:
"Wenn wir eine nummerierte Seitensequenz erkennen, die auch über
eine Gesamtansicht verfügt, setzen wir verstärkt darauf,
die Seite der Gesamtansicht, wenn zutreffend, in den
Suchergebnissen anzuzeigen." Das ist gut für eure Suche.
Und noch viel besser für Webmaster ist es, dass wir nicht nur
die Gesamtansicht erkennen, sondern auch Indexierungseigenschaften
wie Links für die Übersicht zusammenfassen.
Das bringt sowohl für Nutzer also auch für Webmaster Vorteile
im Hinblick auf die Zusammenfassung von Indexierungseigenschaften.
Kommen wir jetzt zu einigen Optionen, die euch als Webmaster für
Inhalte in fortlaufender Sequenz zur Verfügung stehen.
Zuerst werfen wir einen Blick auf die Situation von Webmastern,
die fortlaufende Sequenzen mit Gesamtansicht verwenden.
Solltet ihr keine Gesamtansicht haben,
können die folgenden Informationen
dennoch zutreffen und hilfreich sein.
Also, wenn ihr Inhalte in fortlaufender Sequenz sowie eine Gesamtansicht habt,
stehen euch drei Optionen zur Verfügung.
1. Alles bleibt wie es ist.
Ihr müsst nichts ändern, wenn ihre andere Prioritäten
auf eurer Website habt.
Inhalte in fortlaufender Sequenz sind überall im Web zu finden
und Suchmaschinen verarbeiten
diese Informationen immer besser.
Wenn ihr also eine Gesamtansicht habt,
versucht Google diese Seite zu erkennen
und Nutzer dort hin zu leiten. Auch die Indexierungseigenschaften
werden dabei zusammengefasst.
Die erste Option ist also eine solide Option.
Nun zur zweiten Option:
Sie schließt die Verwendung von rel="canonical" ein,
um Google explizit darauf hinzuweisen, wo eure Gesamtansicht zu finden ist.
Wir können dies also entweder über unseren Algorithmus herausfinden
oder indem ihr uns auf euren Komponentenseiten mit rel="canonical"
auf die Gesamtansicht verweist.
Damit gebt ihr uns einen konkreten Hinweis,
wie eure Website konfiguriert ist.
Wie ihr vielleicht schon wisst, werden mit rel="canonical"
auch die Indexierungseigenschaften eurer Komponentenseiten
für die kanonische Originalversion zusammengefasst.
Damit werden auch Links im Index beibehalten.
Und Nutzer werden dann natürlich an die
Seite der Gesamtansicht geleitet.
Das ist Option Nummer zwei.
Die letzte Option stammt von zwei unserer Entwickler:
Joachim und Benjia.
Dabei geht es um den Einsatz des HTML-Standard-Markups
rel="next" und rel="prev" auf den Komponentenseiten
eurer Sequenz, um Google darauf hinzuweisen,
dass es sich um einzelne Seiten handelt, die Teil einer fortlaufenden Sequenz sind.
Durch die Implementierung des Markups rel="next" und rel="prev"
werden die einzelnen Komponenten als eine Einheit verknüpft.
Ihr könnt also rel="next" für die erste Seite einfügen,
dann rel="prev" und rel="next" für die zweite bis vorletzte Seite
und rel="prev" für die letzte Seite.
Auf eurer Seite zur Gesamtansicht
müsst ihr natürlich nichts mehr einfügen.
rel="next" und rel="prev" ist HTML-Standard-Markup
und wird seit Jahren verwendet.
Webmastern steht dieses Markup jetzt jedoch zur Verfügung,
um Google konkret auf Inhalte in fortlaufender Sequenz hinzuweisen.
Jetzt mehr zur Funktionsweise
von rel="next" und rel="prev".
Mit rel="next" und rel="prev"
werden so wie bei rel="canonical"
die Indexierungseigenschaften der einzelnen Komponentenseiten
zusammengefasst.
Im Gegensatz zu rel="canonical",
bei dem nur die Gesamtansicht in den Suchergebnissen angezeigt wird,
wird mit rel="next" und rel="prev" genau dieser Ansatz nicht verfolgt.
Hier werden Nutzer ausschließlich
zu einer bestimmten Komponentenseite geleitet.
In den meisten Fällen ist dies die erste Seite, die in der Regel
die relevanteste Seite ist.
Wenn ihr also zum Beispiel diese Produktkategorie für Formen habt
und das Markup rel="next" und rel="prev" verwendet,
weist ihr uns darauf hin, dass die beiden Seiten
zu einer Sequenz gehören.
In der Regel werden Nutzer dann zur ersten Seite weitergeleitet.
rel="next" und rel="prev" sind also ein konkreter Hinweis für uns,
die Verwendung ist jedoch auf keinen Fall verpflichtend.
Zum Abschluss möchte ich zu rel="next" und rel="prev" noch sagen,
dass die Parameter in den Komponenten-URLs
einer Sequenz konsistent sein sollten.
Nehmen wir den Artikel
zu Keksen und Gemüse als Beispiel.
Wenn diese Seiten eine Session-ID enthalten,
sollten alle Werte für rel="prev" und rel="next"
auch die Session-ID enthalten.
Unser Indexierungsteam
versucht nämlich jede Seite einer Sequenz mit der Seite zu verknüpfen,
die als vorherige oder nächste Seite angegeben wurde.
Wenn man also von der zweiten Seite
mit rel="prev"
auf die erste Seite verweist,
wird die Seite "page=1&sid=123" aufgerufen.
Diese URL muss jedoch die zweite Seite mit der gleichen
Sitzungs-ID aufführen.
Damit können wir die einzelnen Seiten einer Sequenz verknüpfen.
Achtet also auf die Konsistenz der Parameter in eurer Sequenz.
Lasst mich diese drei Optionen zusammenfassen.
Wenn ihr eine Seite zur Gesamtansicht habt,
könnt ihr alles so lassen wie es ist.
Ihr könnt mit rel="canonical" explizit auf die
Gesamtansicht verweisen.
Oder ihr könnt den Ansatz der Gesamtansicht übergehen
und rel="next" und rel="prev" einfügen.
Mit rel="next" und rel="prev" könnt ihr außerdem die einzelnen Komponenten
einer Sequenz zusammenfassen.
Nutzer werden in dem Fall jedoch nicht zur Gesamtansicht geleitet,
sondern zu einer Komponentenseite. In den meisten Fällen ist dies
die erste Seite der Sequenz.
Kommen wir jetzt zur Konfiguration
ohne Gesamtansicht.
Falls ihr Inhalte in fortlaufender Sequenz
ohne eine Seite zur Gesamtansicht habt, stehen euch zwei Optionen zur Verfügung.
Erstens könnt ihr natürlich alles so lassen, wie es ist.
Gar kein Problem.
Die zweite Option ist die Verwendung
von rel="next" und rel="prev".
Damit werden die Komponentenseiten einer Sequenz verknüpft und
Indexierungseigenschaften zusammengefasst.
Außerdem können wir damit Nutzer gezielter auf die relevanteste Seite leiten,
was in der Regel auf die erste Seite zutrifft.
Jetzt komme ich euch zuvor und stelle eine der häufigsten Fragen
zu rel="canonical" sowie rel="next" und rel="prev".
Warum soll man mit rel="next" und rel="prev"
auf eine fortlaufende Sequenz hinweisen und nicht mit rel="canonical"
auf die erste Seite?
Ha!
Ich wette, das habt ihr euch auch gefragt!
Die Antwort lautet: rel="canonical" ist für
duplizierte Inhalte gedacht.
Nehmen wir die zweite Seite
des Artikels als Beispiel:
"Cookies are superior nutrition"
Wenn diese Seite über eine Sitzungs-ID verfügt,
kann sie auf die kanonische, duplizierte Version hinweisen,
die jedoch keine Session-ID enthält.
Denn rel="canonical" ist für duplizierten Inhalt gedacht
oder für übergreifende Inhalte.
Hier haben wir Seite eins, zwei und drei,
die alle auf die kanonische Version, also auf die
Gesamtansicht verweisen.
Das ist in Ordnung so.
Das Problem mit rel="canonical" ist,
dass der Index nur Inhalte aus der kanonischen Version berücksichtigt.
Lasst uns einen Blick darauf werfen.
Auf Seite zwei steht also "cookies are superior nutrition"
und auf der dritten Seite "to vegetables".
Wenn beide Seiten
jedoch mit rel="canonical"
nur auf die erste Seite verweisen,
fasst Google den Index für die erste, zweite und dritte Seite
zusammen.
Es wird jedoch nur der Inhalt aus der ersten Seite, der kanonischen Version,
in den Index aufgenommen.
Der Index enthält also "new studies prove
that".
Durch die falsche Verwendung von rel="canonical"
hat dieser Webmaster die Inhalte "cookies are
superior nutrition" sowie "to vegetables" verloren.
Aus diesem Grund funktioniert rel="canonical" hier nicht.
rel="next" und rel="prev" können jedoch für
diese Sequenz eingesetzt werden.
Kommen wir noch einmal zu den beiden Beispielen zurück.
Mit rel="next" und rel="prev" wird im Index von Google
angegeben, dass es sich um eine Sequenz handelt.
Seite eins, zwei und drei werden jedoch separat
im Index erfasst.
Aus unserem Index geht also hervor, dass die erste Seite
"new studies prove that" enthält, die zweite Seite "cookies are superior
nutrition" und die dritte Seite "to vegetables".
Für alle drei Seiten wird ein Index erstellt und sie werden als Sequenz gekennzeichnet.
Darin liegt der große Unterschied zwischen rel="canonical" und
rel="next" und rel="prev".
Gut zu wissen ist, dass rel="canonical"
zusammen mit rel="next" und rel="prev" verwendet werden kann.
Werfen wir einen Blick auf Seite zwei.
In diesem Fall hat die Seite eine Sitzungs-ID.
Diese URL kann sowohl die kanonische Version ohne Sitzungs-ID
als auch rel="prev" und rel="next" enthalten.
Für rel="next" und rel="prev" müssen natürlich die gleichen Parameter, also auch
die Sitzungs-ID, verwendet werden.
Fassen wir jetzt diese Informationen für die Seitennummerierung zusammen.
Beginnen wir mit Google und den beiden neuen Funktionen.
Erstens versuchen wir verstärkt, die Gesamtansicht zu erkennen
und Nutzer dementsprechend zur bevorzugten Gesamtansicht
weiterzuleiten.
Die zweite Funktion dient
zur Aufhebung dieser Funktion.
Egal, ob ihr über eine Gesamtansicht verfügt oder nicht,
könnt ihr mit rel="next" und rel="prev" Google darauf hinweisen,
dass es sich um Komponentenseiten
in einer Sequenz handelt.
Dann werden die Indexierungs- eigenschaften zusammengefasst
und Nutzer zur relevantesten Seite geleitet, in den meisten Fälle zur ersten Seite.
Kommen wir jetzt zu den verfügbaren
Konfigurationstypen.
Ist eine Seite zur Gesamtansicht verfügbar, stehen euch drei Optionen
zur Verfügung.
1. Keine Änderung vornehmen
2. rel="canonical" auf den Komponentenseiten einsetzen,
um auf die Gesamtansicht zu verweisen
3. Erkennung der Gesamtansicht deaktivieren, indem rel="next"
und rel="prev" hinzugefügt werden. Damit wird gekennzeichnet,
dass es sich um Komponentenseiten einer Sequenz handelt.
Google leitet Nutzer dann zur relevantesten Seite weiter,
in den meisten Fälle zur ersten Seite.
Für Webmaster ohne Gesamtansicht
gibt es zwei Optionen
zur Seitennummerierung.
1. Ihr könnt natürlich alles so lassen, wie es ist.
2. Oder ihr könnt rel="next" und rel="prev" implementieren.
Damit werden alle Komponentenseiten in einer Sequenz zusammengefasst
und Nutzer werden zur relevantesten Seite geleitet.
Das Tolle an diesen Funktionen zur Seitennummerierung ist die Entwicklung.
Ich habe bei Google die ersten Schritte
der Webmaster-Community miterlebt, als Probleme mit der
Seitennummerierung diskutiert wurden, und sehe die Weiterentwicklung
bis zu den jetzt verfügbaren Funktionen.
Ich möchte euch allen für euer hilfreiches Feedback danken.
Danke, dass ihr Teil dieser Webmaster-Community seid.
Weitere Informationen zur Seitennummerierung findet ihr
unter den folgenden Links
und natürlich im Blog der Webmaster-Zentrale
sowie im Webmaster-Diskussionsforum.
Vielen Dank für eure Aufmerksamkeit.
MAILE OHYE: ¡Hola!
Me llamo Maile Ohye
y llevo más de seis años en Google trabajando con el equipo
de la Búsqueda de Google y de las Herramientas para webmasters de Google.
Me gustaría darte la bienvenida a mi hogar.
Vamos a hablar de la paginación y de la optimización de motores de búsqueda (SEO).
De acuerdo con el programa de hoy, empezaremos analizando algunos
ejemplos de contenido paginado.
A continuación, abordaremos algunos de los efectos colaterales negativos
de la paginación y los motivos por los que los webmasters deberían tratar
de evitar dividir sus propiedades de indexación e
intentar mostrar mejores resultados a los usuarios.
Posteriormente, hablaremos de la configuración.
Esta sección se divide en dos partes según el tipo de webmaster:
webmasters con contenido paginado y
una página de visualización de todo el contenido, y
webmasters que tienen contenido paginado, pero
que no tienen una página que muestra todo el contenido.
Por tanto, aquí vamos a tratar dos tipos de configuraciones.
A continuación, retrocederemos un poco para hablar
de las iniciativas de Google para ayudar a los webmasters y a los usuarios
con contenido paginado.
Y, por último, en función de tu configuración, es decir, si tienes o no
una página de visualización de todo el contenido,
analizaremos las opciones disponibles para
tu contenido paginado.
Bueno, dicho esto, empecemos analizando algunos
ejemplos de contenido paginado.
El contenido paginado está disponible en toda la Web, por lo que
voy a tratar dos de los casos más habituales.
El primero hace referencia a un artículo paginado.
Imaginemos que accedes a tu sitio de contenido favorito y
ves la noticia de última hora:
"Nuevos estudios demuestran que las galletas son más nutritivas
que las verduras". Esa sería más o menos la noticia.
No obstante, es posible que tu sitio favorito no incluya toda esta información en una
página, sino que pagine el contenido en varias páginas de componentes.
En este caso, este único artículo se ha convertido en tres, lo que constituye
un ejemplo de un artículo de contenido paginado.
Otro ejemplo de paginación hace referencia, por ejemplo, a una
categoría de productos, como la información que aparecería en tu sitio favorito
de comercio electrónico.
Imaginemos que este webmaster vende formas
y que ofrece seis tipos de formas,
pero en lugar de incluirlas todas en una página, las ha dividido
en dos páginas de componentes, en cada una de las cuales se incluyen formas, lo que
da lugar a una nueva paginación.
Por tanto, dos formas habituales de paginar el contenido son los artículos de contenido
paginado y las categorías de productos paginadas.
Pero, ¿cuáles son algunos de los efectos colaterales negativos de este método?
Bueno, existen varios efectos.
Me gustaría destacar dos de ellos: el primero es que las propiedades
de indexación, como los enlaces y el texto de anclaje, se pueden dividir
en las diferentes URL de las páginas de componentes en lugar de
consolidarse en un artículo o en
una categoría de productos.
Bueno, ese es uno de los efectos colaterales negativos.
El otro efecto colateral negativo es que la página más relevante de la serie
podría no reflejarse en los resultados de búsqueda.
Por tanto, si eres el webmaster de este sitio de comercio electrónico, es posible
que quieras que los usuarios accedan, por ejemplo, a la primera página de tu serie.
No obstante, los motores de búsqueda interpretan esta paginación como tres
entidades independientes, por lo que los usuarios podrían ser dirigidos a otra
otra página que podría no ser la más relevante.
Bueno, esos son algunos de los efectos colaterales negativos de
la paginación.
Hablemos ahora un poco más de tu situación y de la
configuración de tu sitio.
Para hablar de este tema, vamos a analizar dos tipos de
configuraciones diferentes.
La primera es aquella que tiene una página de visualización de todo el contenido, y
la otra es la que no tiene esta página.
Bien, si tu sitio tiene contenido paginado y dispone de una
página que muestra todo el contenido, debes asegurarte de comprobar
determinados aspectos.
Uno de ellos consiste en asegurarte de que tu sitio tenga latencia fija
suficiente, es decir, que si un usuario hace clic en la versión con
la página de visualización de todo el contenido, esta no tarde 15 segundos en cargarse
porque se trate de un artículo muy extenso o porque
incluya demasiados productos,
sino que se siga ofreciendo una experiencia positiva al usuario,
por ejemplo que la página solo tarde 4 segundos en cargarse.
El segundo punto que debes comprobar es que, si tienes una página que muestra
todo el contenido, debes asegurarte de que se pueda seguir navegando fácilmente
por ella, es decir, que los usuarios puedan seguir encontrando el contenido
que buscan o el producto específico que quieren
desplazándose fácilmente o viendo titulares.
Bien, esa es la configuración de un sitio con una página que muestra todo el contenido.
Y, si no tienes una página de visualización de todo el contenido,
esto es bastante sencillo.
Por tanto, debes pensar en tu sitio según su configuración.
Pero antes de adentrarnos en este tema, volvamos atrás y
hablemos un poco de las iniciativas de Google.
Por supuesto, siempre estamos trabajando para mejorar
la experiencia de los usuarios.
Y una de las cosas que hemos detectado a través de las pruebas es que
los usuarios prefieren ver la página que muestra todo el contenido en los resultados
de búsqueda en lugar de una página de componentes individual.
Y puede que uno de los motivos de esto sea la latencia.
Por tanto, si analizas los resultados de búsqueda y haces clic en un resultado que
lleva a una página que muestra todo el contenido, esta podría tardar unos 3
segundos en cargar ese artículo sobre los nuevos estudios que demuestran que las
galletas son más nutritivas que las verduras. La página podría cargarse
en 3 segundos,
pero, a pesar de ello, los usuarios mostraban una menor satisfacción cuando los
resultados de búsqueda los redirigían simplemente a la primera página del artículo.
Aunque solo se tratara de 2 segundos de latencia antes
de que la página se cargara, cada vez que el usuario hacía clic en
Siguiente para leer más información sobre el artículo, se producía un
tiempo de carga adicional.
Por tanto, debido a esta latencia y a otros motivos, los usuarios prefieren
la página que muestra todo el contenido.
Así pues, gracias a esta información, uno de nuestros ingenieros de indexación,
Benjia Li, desarrolló una nueva función
en octubre de 2011.
Se trata de lo siguiente:
"Cuando detectamos que una serie paginada también contiene
una versión que muestra todo el contenido, hacemos un mayor esfuerzo
para mostrar esa página en los resultados de búsqueda siempre que sea
adecuado". Eso es fantástico para los usuarios.
Y lo que es aún mejor para los webmasters es que, aunque
detectemos esta página que muestra todo el contenido, también seguiremos consolidando
distintas propiedades de indexación, como los enlaces, en la misma.
Así que, de nuevo, esto resulta muy positivo para los usuarios y para ti como
webmaster en lo que respecta a toda la consolidación de indexación.
Hablemos ahora de algunas de las opciones de las que dispones como
webmaster con contenido paginado.
En primer lugar, vamos a analizar la situación en la que los webmasters
han paginado el contenido y tienen una página que muestra todo el contenido.
Pero si eres webmaster y no tienes una página que muestra todo el contenido,
sigue siendo importante que prestes atención, ya que algunas de
estas opciones también se aplicarán a tu caso.
Bueno, si tienes un sitio con contenido paginado y una
página que muestra todo el contenido, dispones de tres buenas opciones.
La primera consiste en dejar el contenido tal cual.
No tienes que realizar ninguna acción si tienes otras
prioridades en tu sitio.
El contenido paginado está disponible en toda la Web, y los motores
de búsqueda seguirán haciendo un trabajo aún mejor
para procesarlo.
Y, como mencioné anteriormente, si tienes una página que muestra todo el contenido,
Google intentará detectarla de forma automática,
dirigir a los usuarios a ella y consolidar
tus propiedades de indexación.
Por tanto, la primera opción es muy segura.
No obstante, también tienes otra opción,
que consiste en utilizar el atributo rel="canonical"
para indicar de forma explícita a Google cuál es la página que muestra todo el contenido.
Por tanto, aunque intentamos detectar esta página utilizando algoritmos, también puedes
indicárnoslo escribiendo rel="canonical" en
las páginas de componentes que dirigen a la versión que muestra todo el contenido.
Este método es una forma más explícita de indicarnos cómo
está configurado tu sitio.
Con el atributo rel="canonical", como muchos de vosotros ya sabéis,
consolidaremos las propiedades de indexación de
las páginas de componentes con la versión canónica.
Por tanto, también se transferirán elementos como los enlaces.
Y, posteriormente, como es lógico, dirigiremos a los usuarios a
la página que muestra todo el contenido.
Bueno, esa es la segunda opción.
La última opción es en realidad el trabajo de dos de nuestros ingenieros,
Joachim y Benjia.
Esta opción consiste en utilizar el marcado HTML estándar con
rel="next" y rel="prev" en las páginas de componentes de tu
serie para indicar a Google que esas son las páginas
individuales, pero que todas ellas pertenecen a una serie.
Por tanto, al añadir este marcado con rel="next" y rel="prev",
estos componentes individuales se conectan en uno.
Para ello, puedes añadir rel="next" en la primera página y,
a continuación, rel="prev" y rel="next" en la segunda página, y así hasta llegar a
la última página, en la que solo debes incluir un atributo rel="prev".
Después, no es necesario añadir nada a
la página que muestra todo el contenido.
Los atributos rel="next" y rel="prev" representan el marcado HTML estándar,
que se ha utilizado durante años.
No obstante, Google utiliza ahora este marcado para que los webmasters
nos informen de su contenido paginado.
Ahora voy a explicar cómo funciona el marcado con rel="next"
y rel="prev".
Con rel="next" y rel="prev", de forma muy similar a lo que ves
con otros atributos, como rel="canonical", en realidad
consolidamos las propiedades de indexación de las páginas
de componentes de la serie.
Además, a diferencia del atributo rel="canonical", que solo
muestra la página de visualización de todo el contenido en los resultados de búsqueda,
con rel="next" y rel="prev", anulamos ese
comportamiento y dirigimos a los usuarios únicamente a una de
las páginas de componentes.
Lo más probable es que esta sea la primera página, ya que suele ser
la página más relevante.
Por tanto, suponiendo que tienes la categoría de productos de venta de formas,
si utilizas el marcado con rel="next" y rel="prev",
nos estarás indicando que esas dos páginas
pertenecen a una serie.
Y, a continuación, lo más normal es que dirijamos a los usuarios a la primera página.
Por tanto, debes saber que los atributos rel="next" y rel="prev" son muy recomendables,
aunque no es obligatorio utilizarlos en ningún caso.
Lo último que quiero comentar sobre los atributos rel="next" y
rel="prev" es que las URL de las páginas de componentes de una serie deben ser
coherentes con sus parámetros.
Bien, analicemos el artículo sobre los nuevos estudios que demuestran que las galletas
son más nutritivas que las verduras.
Supongamos que estas páginas incluyen un ID de sesión.
Todos los valores de los atributos rel="prev" y rel="next"
también deberían incluir el ID de sesión.
Ese es el motivo por el que el equipo de indexación
intenta en realidad vincular cada una de las páginas de una serie a la declaración
anterior y a la declaración siguiente.
Y cuando hacen esto, quieren asegurarse de que si, por ejemplo, estás
en la segunda página,
el valor del atributo rel="prev" sea
"página-1&sid=123" y de que los usuarios accedan a esa URL.
Pero esa URL en realidad tiene que mostrar la segunda página
con el mismo ID de sesión.
Esa es la forma en la que podemos vincular cada una de las páginas de la serie.
Por tanto, debes asegurarte de mantener esos parámetros a lo largo de toda tu serie.
Bien, recordemos estas tres opciones.
Si tienes una página que muestra todo el contenido,
puedes dejarla tal cual,
aunque también puedes incluir el atributo rel="canonical" en
la página que muestra todo el contenido
o anular el comportamiento de la página de visualización de todo el contenido
añadiendo los atributos rel="next" y rel="prev". Al añadir los atributos
rel="next" y rel="prev", nos ayudas a consolidar
las páginas de componentes de una serie,
pero, en lugar de dirigir a los usuarios a una página que muestra todo el contenido,
los dirigiremos a una página de componentes, que será probablemente
la primera página de tu serie.
Hablemos ahora de la configuración sin una página
de visualización de todo el contenido.
Aquellos webmasters que tengan contenido paginado,
pero no cuenten con una página de visualización de todo el contenido, tienen dos opciones.
La primera opción consiste, como es lógico, en dejar el contenido tal cual.
Esa opción es perfectamente viable.
La segunda opción consiste también en utilizar los atributos rel="next" y
rel="prev". Te vuelvo a recordar que, al utilizar los atributos rel="next" y rel="prev",
se conectan todas las páginas de componentes de la serie y
se consolidan las propiedades de indexación, lo que nos permite
dirigir a los usuarios a la página más relevante, que suele ser
la primera página de la serie.
Voy a anticiparme a lo que estás pensando y plantearte
una de las preguntas más frecuentes sobre el atributo rel="canonical", así como
sobre rel="next" y "rel=prev". La pregunta es "¿Por qué se deben
utilizar los atributos rel="next" y rel="prev" para una serie paginada
en lugar de incluir rel="canonical" en la primera página?"
¡Ajá!
Estoy segura de que estabas pensando lo mismo.
La respuesta es que el atributo rel="canonical" se utiliza para
contenido duplicado.
Volvamos al ejemplo del artículo.
Supongamos que estamos en la segunda página del artículo, que indica "las galletas
son más nutritivas".
Si esta página realmente incluye un ID de sesión,
puede mostrar como canónica la misma versión, es decir, la conversión
duplicada, pero sin un ID de sesión, ya que
el atributo rel="canonical" se utiliza para contenido duplicado o para
contenido que es un superconjunto.
Por tanto, aquí tenemos la primera, la segunda y la tercera página, y
todas ellas están vinculadas a la versión canónica, que es
la versión que muestra todo el contenido.
Esa opción también es perfectamente viable.
El problema del atributo rel="canonical" es que
solo indexa contenido de la versión canónica.
Pasemos ahora a analizar esta cuestión en detalle.
Tenemos la segunda y la tercera página, en las que la segunda página indica "las galletas
son más nutritivas", y la tercera página indica "que
las verduras".
Sin embargo, ambas páginas añaden el atributo rel="canonical"
únicamente en la primera página.
Además, el índice de Google agrupará la primera, la segunda
y la tercera página entre sí.
No obstante, lo único que se habrá indexado será el contenido
de la primera página, es decir, la versión canónica.
Por tanto, el índice incluirá en realidad la información "nuevos estudios demuestran
que".
Así que, al utilizar este atributo rel="canonical" de forma incorrecta,
este webmaster habrá perdido por completo el contenido "las galletas
son más nutritivas" y "que las verduras". Por tanto, ese es el motivo
por el que el atributo rel="canonical" no funciona en este caso.
No obstante, los atributos rel="next" y rel="prev" funcionan para una serie
o para una secuencia de contenido.
Volvamos a analizar estos dos ejemplos de contenido paginado.
Al utilizar los atributos rel="next" y rel="prev", en realidad marcaremos
el contenido en el índice de Google como una serie,
pero indexaremos la primera, la segunda y la tercera página
de forma independiente.
Por tanto, en el índice, sabremos que la primera página hace referencia a "nuevos estudios
demuestran que", que la segunda página indica "las galletas son más
nutritivas" y que en la tercera página se incluye "que las verduras". Además,
las tres páginas se indexarán y marcarán como una serie.
Por tanto, esa es la gran diferencia entre el atributo rel="canonical" y
los atributos rel="next" y rel="prev".
Algo que hay que destacar es que el atributo rel="canonical" en realidad
se puede utilizar junto con los atributos rel="next" y rel="prev". Para ello, volvamos
a analizar la segunda página.
En esta ocasión, se incluye un ID de sesión.
Esta URL puede mostrar en realidad la versión canónica
sin un ID de sesión y con los atributos rel="prev" y rel="next"
con los mismos parámetros, como es lógico, incluido el
ID de sesión.
Bien, recordemos estas nuevas herramientas de paginación.
Empezando por Google, te ofrecemos dos nuevas funciones.
En primer lugar, estamos realizando un mayor esfuerzo para detectar una
página de visualización de todo el contenido y dirigir, a continuación, a los usuarios a esa
versión preferida que muestra todo el contenido.
La segunda función consiste en anular ese comportamiento
si así lo quieres.
Por tanto, para aquellos que tengáis o no una página de visualización de todo el contenido,
si se añade un marcado con rel="next" y
rel="prev", se indicará a Google que esas son
las páginas de componentes de una serie,
A continuación, consolidaremos las propiedades de indexación y dirigiremos
a los usuarios a la página más relevante, que suele ser la primera página.
Hablemos ahora sobre los tipos
de configuraciones que puedes utilizar.
Resumiendo, si tienes una página que muestra todo el contenido,
dispones de tres opciones.
Puedes dejarla tal cual.
Puedes utilizar el atributo rel="canonical" en las páginas de componentes para que
dirijan a la página que muestra todo el contenido.
O puedes anular por completo la detección de la página de visualización de todo el contenido
añadiendo los atributos rel="next" y rel="prev", que nos indicarán que esas
páginas de componentes pertenecen a una serie
y que quieres que Google dirija a los usuarios a la página
individual más relevante, que, de nuevo, será probablemente la primera página.
Bien, la otra parte de las nuevas herramientas de paginación está relacionada
con aquellos que no tienen una página de visualización de todo el contenido.
En ese caso, tienes dos opciones.
Obviamente, puedes dejar el contenido tal cual.
O, de nuevo, puedes utilizar los atributos rel="next" y rel="prev".
De esta forma, podrás consolidar todas las páginas de componentes
en una serie y dirigir a los usuarios a la página más relevante.
Por tanto, lo más interesante de estas funciones de paginación es que
llevo en Google el tiempo suficiente para haber visto la evolución desde
cuando la comunidad de webmasters nos hablaba de incidencias
relacionadas con la paginación hasta las nuevas funciones actuales
que te ofrecemos.
Por tanto, quiero darte las gracias por todos tus útiles comentarios
y por formar parte de esta comunidad de webmasters.
Para obtener más información sobre la paginación, a continuación te indicamos
algunas páginas que puedes visitar.
Y, por supuesto, también puedes participar en el blog del Centro para webmasters
y en el foro de debate para webmasters.
Gracias por tu tiempo.
MAILE OHYE: Hola.
Soy Maile Ohye.
He estado en "Google Now" durante seis años,
trabajando con búsquedas y herramientas para desarrolladores web
Deseo darte la bienvenida a mi hogar.
Hablemos de paginación y SEO.
Para la agenda de hoy vamos a empezar con
ejemplos de contenidos paginados.
Luego veremos algunos efectos negativos de la paginación
y por qué como desarrolladores podríamos querer
hacer un esfuerzo adicional para no diluir las propiedades de indexación
y mostrar mejores resultados a los usuarios
Ahora vamos a cubrir la configuración
Y ésta viene en dos partes--
para aquellos desarrolladores con contenido paginado y una
página que muestra todo el contenido, y para todos aquellos
desarrolladores que tienen contendo paginado pero
sin una pagina que muestre todo el contenido.
Así que allí habrá dos tipos de configuraciones.
Luego retrocederemos un poco y hablaremos sobre
lo que Google esta haciendo para ayudar a los usuarios con contenido paginado
y tambien a los desarrolladores
y por ultimo, dependiendo de nuestra configuración,
si tenemos una pagina donde se muestra todo el contenido disponible
o si no la tenemos, veremos las opciones que existen para
el contenido paginado
Asi que empecemos con
algunos ejemplos de contenido paginado
El contenido paginado existe en toda la web
y voy a cubrir dos de los casos mas comunes.
Uno es un articulo paginado.
Así que imaginemos que vamos a nuestro sitio web favorito y vemos
una noticia de ultima hora.
"Estudios recientes demuestran que las galletas son mas nutritivas
que las verduras". Y esa seria toda la historia.
Pero nuestro sitio favorito no podría poner todo esto en una sola pagina,
en lugar de eso, lo divide en varias paginas relacionadas.
Ahora un solo articulo se ha convertido en tres
ese es un ejemplo de paginado de artículos.
Otro ejemplo de paginacion podria ser una categoria de producto,
como la que podríamos encontrar en
nuestro sitio de compras favorito
Asi que digamos que este desarrollador está vendiendo figuras.
Ellos están vendiendo seis tipos de figuras.
Pero en lugar de tenerlas todas en una sola pagina, las han dividido
en dos paginas relacionadas, ambas con figuras,
creando una nueva paginación.
Así que hay dos formas comunes de paginar, artículos de contenido
y categorías de producto.
Ahora, ¿cuales son algunos de sus efectos secundarios negativos?
Bueno, aquí hay un par.
Me gustaría resaltar dos, el primero es indexar propiedades,
como los enlaces y texto de anclaje, que pueden ser diluidos
en diferentes componentes de URL en lugar de ser
consolidados a un articulo
o a una categoría de producto.
Ese es uno de los aspectos negativos.
El otro es, que la mayoría de las paginas relevantes en la lista
podrían no ser reflejadas en los resultados de búsqueda.
Entonces si eres el desarrollador para este sitio de comercio en linea
podrías querer que los usuarios se envíen a la pagina uno de tu lista.
pero los motores de búsqueda ven esta paginación como
tres entidades separadas, los buscadores serian enviados a diferentes
paginas que podrían no ser las mas relevantes.
Estos son algunos de los aspectos negativos de la paginación.
Ahora vamos a hablar sobre tu situación
y sobre la configuración de tu sitio web.
Vamos a echarle un vistazo a los dos tipos de configuraciones
Una de ellas se aplica cuando existe una pagina donde se muestra todo el contenido del sitio
y la otra para cuando el contenido se muestra de forma tradicional
Ahora, si tu sitio tiene contenido paginado
donde todo el contenido se muestra en una sola pagina
hay algunas cosas que deberías tomar en cuenta.
Una de ellas es asegurarte que el tiempo de carga en tu sitio web
sea el adecuado, es decir, que el usuario no tenga que esperar
15 segundos para ver la pagina donde se muestra todo el contenido
porque el articulo es muy largo
o hay demasiados productos.
Pero aun así que tengan una buena experiencia--
por ejemplo que la pagina solo tome cuatro segundos en cargar.
La segunda cosa que tenemos que verificar con este tipo de paginas
es que sea fácil navegar por ellas,
es decir, que los usuarios puedan encontrar el contenido que desean
o el producto que buscan desplazándose verticalmente
con facilidad por la pagina o viendo encabezados.
Esa es la configuración de este tipo de paginas.
Y obviamente, sin una pagina que muestre todo el contenido,
es bastante sencillo.
Entonces pensemos en tu sitio en términos de la configuración que tienes.
Pero antes de ir allí, vamos a dar un paso atrás.
Hablemos un poco sobre lo que Google esta haciendo.
Estamos, por supuesto, siempre trabajando para mejorar
la experiencia en búsquedas.
Y algo que encontramos a través de varias pruebas
es que los usuarios prefieren ver todo el contenido en una sola pagina
en lugar de ver el mismo contenido dividido en varias paginas.
Y una razón de esto puede ser la latencia.
Así que si haces una búsqueda y al dar clic en un enlace,
éste te envía a un sitio que muestra todo el contenido en una sola pagina,
tardando tres segundos en cargar ese articulo que dice,
"Nuevos estudios revelan que las galletas son mas nutritivas que los vegetales."
Esto podría tardar tres segundos.
Por otro lado, los usuarios son menos felices cuando
los resultados de búsqueda los llevan solo a la pagina uno del articulo.
Esto podría haber tenido dos segundos de latencia
y después la pagina cargaría cada vez que el usuario quiera hacer clic
para leer mas del articulo,
esto implicaría un tiempo de carga adicional.
Gracias a la latencia y otras razones, los usuarios prefieren ver
todo el contenido en una sola pagina.
Sabiendo ésto, uno de nuestros ingenieros en indexación,
Benjia Li, salió con una nueva característica
en octubre de 2011.
Esta es--
"Cuando detectamos que una serie paginada tambien contiene una
versión donde se ve todo el contenido en una pagina, estamos esforzándonos
para devolver en los resultados de búsqueda
enlaces a este tipo de paginas." Eso es grandioso para los usuarios.
Y lo que es mejor para los desarrolladores es que mientras
detectamos este tipo de paginas, también consolidamos
propiedades de indexación, como enlaces a estas paginas.
Esto es bueno para los usuarios y para ti como desarrollador
por la consolidación de la indexación.
Ahora vamos a hablar de algunas opciones que tienes como
desarrollador con el contenido paginado.
Primero echemos un vistazo al escenario donde los desarrolladores
han paginado el contenido y lo muestran todo en una sola pagina.
Pero para todos ustedes quienes segmentan el contenido en diferentes paginas,
aun es importante prestar atención porque algunas de las opciones
también aplican para ustedes.
Entonces, si tienes un sitio web con contenido paginado y ese contenido
lo enseñas en una sola pagina, tienes tres buenas opciones.
Primero, puedes dejarlo como está.
No hay nada que tengas que hacer si tienes otras prioridades
en tu sitio web.
El contenido paginado existe en toda la web y los motores de busqueda
continuaran haciendo cada vez un mejor trabajo
al manipularlo.
Y como mencioné hace un momento, si tienes una sitio web que muestra
todo el contenido en una sola pagina, Google trata de detectarlo
automáticamente, enviando a los usuarios allí ademas de consolidar
tus propiedades de indexación.
Entonces la opción uno es una opción muy solida.
Pero también tienes una segunda opción.
Ésta opción actualmente consiste en usar rel="canonical"
para indicarle explicitamente a Google que tu sitio muestra todo el contenido en una sola pagina
Asi que mientras tratamos de detectarlo con nuestros algoritmos,
también puedes ayudarnos escribiendo rel="canonical"
en las paginas de esta clase que componen tu sitio.
Y esta es una indicación mas explicita para nosotros de como
tu sitio está configurado.
Como muchos de ustedes saben, con el rel="canonical",
consolidaremos las propiedades de indexación de las paginas
componentes con la versión canónica.
Así que cosas como los enlaces también serán transferidos.
Y luego, por supuesto, enviaremos a los usuarios
a la pagina.
Esa es la opción numero dos.
La ultima opción es actualmente hecha por dos de nuestros ingenieros,
Joachim y Benjia.
Y usa el marcado HTML estándar rel="next" y rel="prev"
en las paginas componentes en tu serie
para indicarle a Google que estas son paginas individuales,
pero todas estas perteneces a una serie.
Añadiendo las marcas rel="next" y rel="prev"
conectas estos componentes individuales en uno.
Puedes hacerlo añadiendo rel="next" a la pagina uno
y luego rel="prev" y rel="next" en la pagina dos, de esa manera
hasta la ultima pagina que solo incluye un rel="prev".
Y por su puesto, no es necesario poner nada
cuando tienes una pagina que muestra todo el contenido.
rel="next" y rel="prev" es un marcado HTML estándar
y ha estado vigente por años.
Pero ahora, Google esta usando este marcado para desarrolladores para
dejarnos saber sobre sus contenidos paginados.
Permitanme explicar algunas formas en que funciona
rel="next" y rel="prev".
Con rel="next" y rel="prev", al igual que con
rel="canonical", actualmente nosotros consolidamos
las propiedades de indexación de las paginas que componen la serie.
Y a diferencia de rel="canonical" que solo enseña en los resultados de búsqueda
los sitios que muestran todo el contenido en una sola pagina,
con rel="next" y rel="prev", vamos a anular ese comportamiento
y enviar a los usuarios a solo una de las paginas componentes.
Probablemente, a la pagina numero uno, ya que normalmente esa es
la pagina mas relevante.
A si que si tienes, digamos, esa categoría de producto vendiendo
formas, si usas el marcado rel="next" y rel="prev",
Eso nos dice que estas dos paginas
le pertenecen a una serie.
y luego, regularmente, enviamos a los usuarios a la pagina uno.
Ahora, rel="next" y rel="prev" es una recomendación,
no es una obligación en cualquier sentido.
Lo ultimo que quiero mencionar sobre rel="next" y rel="prev"
es que las URLs de los componentes en una serie debe ser
consistente con sus parámetros.
Así que vamos a tomar el articulo, "Nuevos estudios revelan que las galletas
son mas nutritivas que los vegetales".
Ahora vamos a suponer que estas paginas contienen un ID de sesión.
Todos estos valores para rel="prev" y rel="next"
también deben contener el ID de sesión.
Y esto es porque nuestro equipo de indexación busca vincular
cada pagina de una serie con lo que fue declarado
anteriormente y lo que fue declarado a continuación.
(sous-titre-vide en anglais)
[Maile Ohye] Salut!
Je suis Maile Ohye,
Je travaille chez Google depuis plus de six ans, dans les secteurs
du moteur de recherche et des Outils pour les webmasters.
Bienvenue chez moi.
Parlons de pagination et d'optimisation pour les moteurs de recherche (SEO).
Aujourd'hui, nous commencerons par
quelques exemples de contenus paginés.
Puis nous passerons à certains effets collatéraux négatifs de la
pagination, et nous verrons pourquoi, comme webmaster, vous pourriez souhaiter faire
un effort pour ne pas diluer vos propriétés d'indexation et
pour montrer de meilleurs résultats aux utilisateurs.
Puis nous examinerons votre configuration.
Et cet examen est divisé en deux parties:
pour les webmasters parmi vous qui ont des contenus paginés et
mettent à disposition une page "Tout voir", puis pour ceux
d'entre vous qui ont des contenus paginés, mais
sans page "tout voir".
Il y aura donc deux types de configuration.
Ensuite, nous reviendrons un peu en arrière et nous parlerons de ce que
Google fait pour aider les utilisateurs - et aussi les webmasters -
en cas de contenu paginé.
Enfin, en fonction de votre configuration,
que vous mettiez ou non une page "tout voir"
à disposition, nous verrons les options dont vous disposez
pour les contenus paginés.
Ciao!
Mi chiamo Maile Ohye.
Lavoro per Google da oltre sei anni e collaboro con
i team di Ricerca e Strumenti per i Webmaster.
Vorrei darti il benvenuto a casa mia.
Parliamo di paginazione e SEO.
In base all'ordine del giorno di oggi, inizieremo con alcuni
esempi di contenuti "paginati" (suddivisi in pagine).
Poi ci addentreremo in alcuni effetti collaterali negativi della
paginazione e sul perche' tu come webmaster dovresti sforzarti
un po' per non disperdere le tue proprietà di indicizzazione
e mostrare risultati migliori agli utenti.
Quindi ci occuperemo della tua configurazione,
che e' suddivisa in due parti:
una per quei webmaster che hanno contenuti paginati
e una pagina di visualizzazione complessiva e una
per i webmaster che hanno contenuti paginati ma
senza pagina di visualizzazione complessiva.
Percio' qui ci saranno due tipi di configurazioni.
Poi faremo un passo indietro e parleremo di
cosa sta facendo Google per aiutare gli utenti con i contenuti paginati
e i rispettivi webmaster,
e infine, in base alla tua configurazione,
che tu abbia o meno una pagina di visualizzazione complessiva,
esamineremo le opzioni a tua disposizione per
i contenuti paginati.
Quindi andiamo avanti e cominciamo con alcuni
esempi di contenuti paginati.
Il Web è pieno di contenuti paginati e io
tratterò due tra i casi piu' comuni.
Il primo è un articolo paginato.
Dunque, poniamo che tu visiti il tuo sito di contenuti preferito e che
tu veda la notizia dell'ultima ora.
"Nuovi studi dimostrano che i biscotti sono piu' nutrienti
delle verdure". Sarebbe proprio una notiziona!
È però possibile che il tuo sito preferito non metta tutto in un'unica pagina,
ma lo suddivida in più pagine.
Ora questo singolo articolo si fa dunque in tre e questo è un
esempio di articoli con contenuti "paginati".
Un altro esempio di paginazione riguarda cose come le categorie
di prodotti, come quelle che vedresti sul tuo sito
di e-commerce preferito.
Supponiamo che questo webmaster venda degli stampi:
sta vendendo sei tipi di stampi,
ma invece di inserirli tutte in un'unica pagina, gli ha suddivisi
in due pagine, entrambe con degli stampi, ricreando
nuovamente la paginazione.
Quindi due esempi comuni sono a paginazione di articoli a tema
e a paginazione di categorie di prodotti.
Ora, quali sono gli effetti collaterali negativi di tutto questo?
Beh, ce n'è un paio.
Dunque, vorrei evidenziarne due, in cui il primo è che le proprietà
di indicizzazione, come link e testo ancorato, possono disperdersi
tra i vari URL che le compongono, invece di essere
raggruppate nel singolo articolo
o nella singola categoria di prodotti.
Questo è uno degli effetti collaterali negativi.
L'altro è che la pagina più importante della serie
rischia di non comparire nei risultati di ricerca.
Quindi se sei il webmaster di questo sito di e-commerce,
vorresti che gli utenti venissero indirizzati alla prima pagina della tua serie.
Ma poiché i motori di ricerca vedono questa paginazione come tre
entità separate, chi cerca potrebbe essere indirizzato a un'altra
pagina che non è la più rilevante.
Questi sono alcuni degli effetti collaterali negativi della
paginazione.
Ora approfondiamo la tua situazione e la
configurazione che hai sul tuo sito.
Esamineremo questi aspetti in base a due diversi tipi
di configurazione.
La prima è quella con una pagina di visualizzazione complessiva disponibile, la seconda è
senza pagina di visualizzazione complessiva disponibile.
Ora se il tuo sito ha contenuti paginati con una
pagina di visualizzazione complessiva disponibile, ci sono un paio di aspetti
che devi assicurarti di testare.
Uno e' che devi esser sicuro di avere ancora una latenza decente sul tuo
sito, nel senso che, se un utente clicca sulla versione di
visualizzazione complessiva, non gli ci vorranno 15 secondi per caricarla
per colpa dell'articolo troppo lungo
o dl troppi prodotti,
ma deve avere comunque un'esperienza positiva,
cioe' il caricamento della pagina richiederà solo quattro secondi.
La seconda cosa da controllare, se hai una pagina di visualizzazione complessiva
è assicurarti che la pagina rimanga facilmente
navigabile, nel senso che gli utenti riescano ancora a trovare quei contenuti
ricercati o quel particolare prodotto
ricercato, scorrendo facilmente la pagina o leggendo le intestazioni.
Questo per quanto riguarda la configurazione con una pagina di visualizzazione complessiva disponibile.
E poi, ovviamente, quella senza pagina di visualizzazione complessiva disponibile è
alquanto intuibile.
Dunque pensa al tuo sito in base alla configurazione che hai.
Ma prima di arrivarci, facciamo un passo indietro e
parliamo un po' di quello che sta realizzando Google.
Noi stiamo certamente lavorando sempre per migliorare
l'utilizzo per chi fa le ricerche.
Un aspetto che abbiamo scoperto con i nostri test è che
gli utenti preferiscono vedere la pagina di visualizzazione complessiva dei risultati
di ricerca piuttosto che una pagina con solo una parte,
e uno dei motivi di cio' potrebbe essere a causa della latenza.
Quindi, se prendi i risultati di ricerca e clicchi un risultato che rimanda a una
pagina di visualizzazione complessiva, questa potrebbe impiegare tre secondi
per caricare l'articolo sui "nuovi studi che dimostrano che i biscotti sono piu'
nutrienti delle verdure".
Certo sarebbero tre secondi,
ma ciononostante gli utenti sarebbero meno contenti se
i risultati di ricerca li indirizzassero solo alla prima pagina dell'articolo.
Pur avendo una latenza di soli due secondi per
il caricamento della pagina, ogni volta che l'utente clicca
"successivo" per continuare a leggere l'articolo si aggiunge un
ulteriore attesa di caricamento.
Quindi, a causa di questa latenza ed altri motivi, gli utenti preferiscono
la pagina di visualizzazione complessiva.
Sulla base di queste conoscenze, uno dei nostri esperti di indicizzazione,
Benjia Li, escogitò una nuova funzione
nell'ottobre del 2011.
Eccola qua:
"Quando rileviamo che una serie di contenuti paginati contiene anche
una versione di visualizzazione complessiva, ora faremo il possibile per
restituire la pagina di visualizzazione complessiva nei risultati di ricerca,
quando è opportuno". Quindi e' un'ottima notizia per chi fa ricerche.
E cio' che piu' conta per i webmaster è che mentre
rileviamo questa pagina di visualizzazione complessiva, raggruppiamo anche
tutte le proprietà di indicizzazione, come i link, nella pagina di visualizzazione complessiva.
Quindi, ripeto, è un bene per chi cerca e per
i webmaster come te questo raggruppamento dell'indicizzazione.
Ora parliamo di alcune opzioni a disposizione di quei
webmaster che hanno i contenuti paginati.
Esamineremo prima il caso in cui i webmaster
usano contenuti paginati e una pagina di visualizzazione complessiva.
Anche per quelli senza pagina di visualizzazione complessiva,
è comunque utile fare attenzione perché alcune di
queste opzioni varranno anche per voi.
Dunque: hai un sito con contenuti paginati e una
pagina di visualizzazione complessiva. Hai tre ottime possibilita':
la prima, puoi lasciarlo com'è,
non devi fare niente se hai da fare
altre cose piu' importanti al tuo sito.
Il Web è pieno di contenuti paginati e
i motori di ricerca continueranno a migliorare
il modo di gestirle.
E, come ho detto prima, se usi una pagina di visualizzazione
complessiva, Google tenterà di rilevarlo automaticamente,
indirizzare li' gli utenti e accorpare le tue
proprietà di indicizzazione.
Quindi la prima e' un opzione molto affidabile.
Ma hai anche una seconda opzione.
La seconda opzione è utilizzare rel="canonical"
per suggerire esplicitamente a Google la tua pagina di visualizzazione complessiva.
Così, mentre tentiamo di rilevarlo algoritmicamente, puoi anche
indicarcelo inserendo rel="canonical" nelle
pagine che compongono la tua versione di visualizzazione complessiva.
E questo e' per noi un'indicazione molto più esplicita
sulla configurazione del tuo sito.
Con rel="canonical", come molti di voi sapranno gia',
raggrupperemo ovviamente le proprietà di indicizzazione dalle
pagine componenti con la versione canonica.
Quindi verranno trasferiti anche elementi come i link
e poi, ovviamente, indirizzeremo gli utenti
alla pagina di visualizzazione complessiva.
E questa era la seconda opzione.
L'ultima opzione e' stata implementata da due nostri ingegneri,
Joachim e Benjia.
In pratica consiste nell'utilizzare il markup HTML standard
rel="next" e rel="prev" sulle pagine che compongono la tua
serie per segnalare a Google che si tratta di pagine
singole ma appartenenti tutte a un'unica serie.
Quindi aggiungendo il markup rel="next" e rel="prev",
riunisci questi singoli componenti in uno solo.
Puoi farlo aggiungendo rel="next" alla prima pagina e
poi rel="prev" e rel="next" alla seconda pagina e procedendo
così fino all'ultima pagina, che includerà soltanto un rel="prev".
E poi, ovviamente, nella tua pagina di visualizzazione
complessiva non devi fare nulla.
rel="next" e rel="prev" sono elementi di markup HTML standard e sono
in uso da anni.
Ma ora Google sta usando questo markup per consentire ai webmaster di
indicarci i loro contenuti paginati.
Lasciatemi dunque che vi spieghi alcuni modi in cui rel="next"
e rel="prev" funzionano.
Con rel="next" e rel="prev", proprio come succede
con rel="canonical",
accorperemo in effetti le proprietà di indicizzazione dalle pagine
che compongono la serie.
Inoltre, a differenza di rel="canonical" che mostra
solo la pagina di visualizzazione complessiva nei risultati di ricerca,
con rel="next" e rel="prev" verra' sostituita quell'azione
indirizzando gli utenti a una sola pagina
della serie.
Molto probabilmente sarà la prima pagina, perché in genere è
la pagina più pertinente.
Ora se hai, supponiamo, quella categoria di prodotti per vendere
gli stampi, se utilizzi il markup di rel="next" e rel="prev"
ci segnalerai che queste due pagine
appartengono a una serie,
e poi, molto probabilmente, indirizzeremo gli utenti alla prima pagina.
Sappi che rel="next" e rel="prev" e' una valida indicazione,
non e' in nessun modo obbligatoria.
L'ultima cosa che voglio dire su rel="next"
e rel="prev" è che gli URL che compongono una serie dovrebbero
essere coerenti con i loro parametri.
Riprendiamo l'articolo sui nuovi studi che dimostrano che i biscotti
sono piu' nutrienti delle verdure.
Supponiamo che queste pagine contengano un ID di sessione.
Tutti i valori per rel="prev" e rel="next"
devono anche contenere l'ID di sessione.
Questo perché il nostro team di indicizzazione cerca
effettivamente di collegare ogni pagina di una serie con quanto viene dichiarato
come precedente e come successivo.
E quando lo fanno, vogliono assicurarsi che,
mettiamo di essere a pagina due,
che il codice rel="prev", che dichiara rel="prev" è
pagina=1&sid=123, indirizzi gli utenti a quell'URL.
Ma in realtà quell'URL deve elencare la pagina due
con lo stesso SID.
Ed è così che riusciamo a collegare ogni pagina della sequenza.
Quindi assicurati di mantenere i parametri attraverso tutta la serie.
Ricapitoliamo dunque queste tre opzioni.
Se usi una pagina di visualizzazione complessiva,
puoi lasciarla com'è,
puoi anche dichiarare esplicitamente rel="canonical" per la tua
pagina di visualizzazione complessiva,
oppure puoi sostituire l'azione della pagina di visualizzazione complessiva
aggiungendo rel="next" e rel="prev". Aggiungendo
rel="next" e rel="prev" ci aiuterai ad accorpare
le pagine che compongono una serie,
ma invece di indirizzare gli utenti a una pagina di visualizzazione complessiva,
li indirizzeremo a una pagina componente, molto probabilmente
la prima pagina della tua serie.
Ora, parliamo della configurazione senza pagina
di visualizzazione complessiva.
Dunque, per voi webmaster che avete contenuti paginati
senza pagina di visualizzazione complessiva sono disponibili due opzioni.
Primo, ovviamente, potete lasciarli come sono,
vanno benissimo così.
La seconda opzione è anche qui utilizzare rel="next" e
rel="prev". Ripeto, utilizzando rel="next" e rel="prev" vengono
collegate le pagine che compongono la serie e
vengono accorpate le proprietà di indicizzazione, il che ci aiuta a
indirizzare gli utenti alla pagina più pertinente, molto probabilmente
la prima pagina della serie.
Ora ti batterò sul tempo e ti faro' una delle
domande più richieste su rel="canonical" e
rel="next" o "prev", cioe': perché (usare) rel="next"
e rel="prev" per una serie paginata invece di
rel="canonical" per la prima pagina?
Hah, scommetto che pensavi a quello!
La risposta è che rel="canonical" è per
contenuti duplicati.
Riprendiamo quell'articolo,
diciamo pagina due dell'articolo "i biscotti
sono piu' nutrienti".
Se questa pagina include un ID di sessione,
potrebbe essere elencata come canonica la stessa versione, la versione
duplicata, ma senza ID di sessione, dato che
rel="canonical" è per i contenuti duplicati o per
contenuti che rappresentano un soprainsieme.
Quindi abbiamo pagina uno, pagina due e pagina tre, tutte
che rimandano alla versione canonica che è
la versione di visualizzazione complessiva.
E anche questo è perfettamente ammissibile.
Il fatto e' che rel="canonical"
indicizza solo i contenuti dalla versione canonica.
Quindi procediamo e diamo un'occhiata a questo.
Se abbiamo pagina due e pagina tre, a pagina due c'e' "i biscotti
sono piu' nutrienti" e a pagina tre c'e'
"delle verdure".
Ma entrambe aggiungono rel="canonical"
solo a pagina uno.
E l'indice di Google impilera' quindi pagina uno, pagina due
e pagina tre insieme,
ma gli unici elementi indicizzati saranno i contenuti
a pagina uno, la versione canonica.
Quindi il nostro indice in realtà conterrà "nuovi studi dimostrano che".
Ora, utilizzando questo rel="canonical" in modo sbagliato,
questo webmaster ha totalmente perso i contenuti "i biscotti sono
piu' nutrienti" e "delle verdure". Ecco perché
rel="canonical" non funziona in questo caso.
Ma rel="next" e "prev" funzionano per una serie o
una sequenza di contenuti.
Quindi riprendiamo quei due esempi di contenuti paginati.
Utilizzando rel="next" e rel="prev" li contrassegneremo
come serie nell'indice di Google,
ma avremo pagina uno, pagina due e pagina tre
tutte indicizzate separatamente.
Quindi, nel nostro indice, sappiamo che pagina uno si riferisce a "nuovi studi
dimostrano che", pagina due "i biscotti sono piu' nutrienti"
e pagina tre "delle verdure". Tutt'e tre le
pagine verranno indicizzate e segnate come un'unica serie.
Dunque è questa la grande differenza tra rel="canonical" e
rel="next" e "prev".
È da notare che rel="canonical" può
essere utilizzato insieme a rel="next" e "prev".
Diamo dunque un'occhiata di nuovo pagina due,
che stavolta ha un ID di sessione.
Questo URL può elencare sia la versione canonica
senza un ID di sessione sia rel="prev" e rel="next"
ovviamente con gli stessi parametri, incluso
quell'ID di sessione.
Ricapitoliamo ora i tuoi nuovi strumenti di paginazione.
Iniziando con Google, abbiamo due novita' per te.
Primo, abbiamo migliorato la rilevazione della pagina di visualizzazione complessiva
e per indirizzare poi chi fa ricerche alla
versione di visualizzazione complessiva piu' adatta.
La seconda funzione è utile se invece vuoi sostituire
questa modalita'.
Per quelli che hanno o meno una pagina di visualizzazione complessiva,
se aggiungete il codice di markup rel="next"
e rel="prev", indicherete a Google che si tratta di
pagine che compongono una serie.
Noi raggrupperemo quindi le proprietà di indicizzazione e indirizzeremo
chi fa la ricerca alla pagina più pertinente, molto probabilmente la prima pagina.
Ora esaminiamo i tipi
di configurazioni a tua disposizione.
Ricapitolando, se hai una pagina di visualizzazione complessiva
hai tre opzioni.
Puoi lasciarla com'è.
Puoi usare rel="canonical" nelle pagine componenti in modo che rimandino
alla tua pagina di visualizzazione complessiva.
Oppure puoi sovrapporti al rilevamento della pagina di visualizzazione complessiva aggiungendo
rel="next" e rel="prev" per indicarci che queste
pagine componenti appartengono a una serie
e che vorresti che Google indirizzasse gli utenti alla pagina
singola più pertinente, di nuovo, presumibilmente la prima.
Ora, l'altra parte degli strumenti di paginazione è per
quelli tra voi che non hanno una pagina di visualizzazione complessiva.
Avete due opzioni.
Ovviamente puoi lasciare tutto cosi' com'e',
o, di nuovo, puoi usare rel="next" e rel="prev".
Ciò ti permette di raggruppare tutte le pagine componenti in
un'unica serie e di indirizzare gli utenti alla pagina più pertinente.
Quindi la cosa bella di queste funzioni di paginazione è che
lavoro per Google da abbastanza tempo da averle seguite dalla nascita,
quando la community dei webmaster ci parlava dei problemi riscontrati
con la paginazione, fino ad oggi, in cui abbiamo più funzioni
a disposizione per voi.
Grazie mille a tutti per il vostro prezioso feedback
e per aver fatto parte di questa community di webmaster.
Per ulteriori informazioni sulla paginazione,
ecco alcuni link a disposizione
e ovviamente puoi anche unirti a noi sul Webmaster Central blog
o sul Forum di discussione degli Strumenti per i Webmaster.
Grazie dell'ascolto.
こんにちは。
私はマリー・オーイェです。
Oi
Eu sou Maile Ohye.
Eu estou no Google há mais de seis anos, trabalhando com
Busca e com Ferramentas de Webmaster.
Eu gostaria de lhe dar as boas-vindas à minha casa.
Vamos conversar sobre paginação e SEO.
Na agenda de hoje, nós vamos começar primeiro com alguns
exemplos de conteúdo paginado.
Depois nós vamos ver alguns dos efeitos negativos da
paginação e por quê você como um webmaster pode querer fazer
algum esforço para não diluir suas propriedades indexadoras e
para mostrar melhores resultados aos usuários.
Depois nós cobriremos sua configuração.
E isso vem em duas partes...
para aqueles webmasters com conteúdo paginado e uma
página de visualização de todos os itens disponível, e então para aqueles
webmasters que tem conteúdo paginado mas
sem uma página de visualização de todos os itens.
Então vai ter dois tipos de configurações lá.
Depois nós vamos voltar um pouco e falar sobre
o que o Google está fazendo para ajudar usuários com conteúdo paginado
e webmasters também.
E por fim, dada a sua configuração, tenha você
uma página de visualização de todos os itens disponível ou não,
nós vamos olhar as opções que você tem para o seu
conteúdo paginado.
Então vamos adiante, começando com alguns
exemplos de conteúdo paginado.
Conteúdo paginado existe pela internet afora, e eu vou
cobrir dois dos casos mais comuns.
Um é o artigo paginado.
Então digamos que você vai no seu site de conteúdo favorito e você
vê a manchete.
"Novos estudos provam que biscoitos são mais nutritivos
que verduras." E essa seria uma história e tanto.
Mas o seu site favorito pode não colocar tudo isso numa página só,
mas em vez disso, paginar o assunto em várias páginas componentes.
Agora esse artigo se tornou três, e esse é um
exemplo de artigos com conteúdo paginado.
Um outro exemplo de paginação é para coisas como uma categoria de
produto, como o que você veria no seu site de
e-commerce favorito.
Então digamos que um webmaster está vendendo shapes.
Eles estão vendendo seis tipos de shapes.
Mas em vez de tudo em uma única página, eles dividiram em
duas páginas componentes, ambas com shapes, criando
paginação de novo.
Então dois jeitos comuns são com artigos de conteúdo paginado e
com categorias de produtos paginados.
Agora, quais são os efeitos negativos disso?
Bem, existem alguns.
Então eu gostaria de ressaltar dois, o primeiro sendo que as propriedades de
indexação, como links e texto de âncora, podem ser diluídos
nas diferentes URLs componentes em vez de serem
consolidadas em um só artigo ou em
uma só categoria de .
Então esse é um dos efeitos negativos.
O outro é que a página mais relevante na série
pode não aparecer nos resultados de busca.
Então se você é o webmaster desse site de e-commerce, você
pode querer que os usuários sejam enviados para a página um, digamos, da sua série.
Mas como as ferramentas de busca vêem essa paginação como três
entidades separadas, os buscadores podem ser enviados para uma página
diferente que pode não ser a mais relevante.
Então esses são alguns dos efeitos negativos da
paginação.
Agora vamos falar mais sobre a sua situação e
a configuração que você tem no seu site.
Nós vamos olhar isso em termos de dois tipos diferentes
de configurações.
Um é com uma página de visualização de todos os itens disponível, e o outro é
sem uma página de visualização de todos os itens disponível.
Agora, se o seu site tem conteúdo paginado com uma
página de visualização de todos os itens disponível, então tem algumas coisas que você
quer ter certeza de testar.
Uma é ter certeza que você ainda tem latência suficiente no seu
site, quer dizer, se um usuário clica na versão de visualização
de todos os itens, que isso não leva 15 segundos para carregar
porque é um artigo tão longo, ou
são tantos produtos.
Mas que eles ainda tem uma boa experiência...
digamos, que a página leve apenas quatro segundos para carregar.
A segunda coisa a checar se você tem uma página de visualização de todos os itens
disponível é ter certezar que a página se matenha fácil de
navergar, quer dizer que usuários ainda conseguem encontrar o conteúdo
que eles querem ou o produto específico que eles
querem ao rolar facilmente ou lendo os títulos.
Então essa é a configuração de uma página de visualização de todos os itens.
E então obviamente, sem uma página de visualização de todos os itens disponível,
é bem direto.
Então pense sobre o seu site em termos da configuração que você
tem. Mas antes da gente chegar nessa parte, vamos voltar e
falar um pouco sobre o que o Google está fazendo.
Nós, é claro, estamos sempre trabalhando para melhorar a
experiência dos buscadores.
E uma coisa que nós descobrimos através de testes é que os nossos
buscadores preferem ver a página de visualização de todos os itens nos resultados
das buscas em ve z de uma página componente individual.
E uma razão para isso pode ser por causa da latência.
Então se você pegar os resultados de busca e clicar num resultado para uma
página de visualização de todos os itens, enquanto isso pode levar, digamos, três segundos
para carregar aquele artigo sobre novos estudos que provam que biscoito são
mais nutritivos que verduras, isso pode levar
três segundos.
Mas por outro lado, buscadores estiveram menos felizes quando
os resultados de busca os levaram apenas à página um do artigo.
Enquanto isso pode ter tido apenas dois segundos de latência e
então a página carregou, toda vez que aquele usuário quis clicar
Próximo para ler mais do artigo, isso levou mais
tempo para carregar.
Então por causa dessa latência e de outras razões, buscadores preferem
a página de visualização de todos os itens.
Então dado esse conhecimento, um dos nossos engenheiros em indexação,
Benjia Li, realmente criou uma nova função
em outubro de 2011.
Isso é
"Quando nós detectamos que uma série paginada também contem
uma versão de visualização de todos os itens, nós estamos agora fazendo um maior esforço para
mostrar a página de visualização de todos os itens nos resultados de busca quando
apropriado." Então isso é ótimo para buscadores.
E o que é melhor ainda para webmasters é que enquanto nós
detectamos essa página de visualização de todos os itens, nós também ainda consolidamos
as propriedades de indexação, como links, para a página de visualização de todos os itens.
Entao de novo, isso eh bom para buscadores e bom para voces como
webmasters por toda essa consolidacao de indexacao.
Agora, vamos falar sobre algumas das opcoes que voce tem como um
webmaster com conteudo paginado.
Nos vamos primeiro olhar as situacoes em que webmasters
paginaram o conteudo e uma pagina de visualizacao de todos os itens disponivel.
Mas para aqueles de voces que nao tem uma pagina de visualizacao de todos os itens disponivel,
ainda assim eh bom prestar atencao porque algumas dessas
opcoes tambem vao se aplicar a voces.
Entao voce tem um site com conteudo paginado e uma
pagina de visualizacao de todos os itens, voce tem tres boas opcoes.
Primeiro, voce pode deixar como esta.
Nao tem nada que voce precise fazer se voce tem outras
prioridades no seu site.
Conteudo paginado existe pela web afora e ferramentas
de busca vao continuar fazendo um servico
ainda melhor de lidar com isso.
E como eu mencionei antes, se voce tiver uma pagina de visualizacao de todos os itens
disponivel, o Google vai automaticamente tentar detectar
ela e enviar buscadores la, assim como consolidar as suas
prioridades de indexacao.
Entao opcao um eh uma opcao bem solida.
Mas voce tambem tem uma segunda opcao.
A segunda opcao eh usar mesmo rel="canonical"
para insinuar explicitamente para o Google qual eh a sua pagina de visualizacao de todos os itens.
Entao enquanto nos tentamos detecta-la por algoritimos, voce pode tambem
nos contar escrevendo rel="canonical" nas suas
paginas componentes para a sua versao de visualizacao de todos os itens.
E isso eh tipo um sugestao mais explicita para a gente sobre como
o seu site eh configurado.
Com o rel="canonical", como muitos de voces ja sabem,
nos vamos, eh claro, consolidar as propriedades indexadoras das
paginas componentes com a versao canonica.
Entao coisas como links tambem serao transferidas.
E ai, eh claro, nos mandaremos usuarios para
a pagina de visualuzacao de todos os itens.
Entao essa eh a opcao numero dois.
A ultima opcao eh na verdade feita por dois de nossos engenheiros,
Joachim and Benjia.
E o que isso eh eh usar a marcacao HTML padrao do
rel="next" e rel="prev" das paginas componentes na sua
serie para sinalizar ao Google que essas sao paginas
individuais, mas que elas pertencem todas a uma serie.
Entao ao adicionar essa marcacao rel="next" e rel="prev", voce
Entao a coisa boa sobre essaes recursos de paginacao eh que
eu estou no Google ha tempo o bastante para ver a infancia de
quando a comunidade webmaster estava falando para gente sobre problemas
com paginacao ate agora quando nos temos mais recursos
disponiveis para voces.
Entao muito obrigada a todos voces pelo seu retorno util
e por serem parte dessa comunidade webmaster.
Para mais informacao sobre paginacao, aqui estao alguns
links disponiveis.
E voce pode, eh claro, juntar-se a nos no blog Webmaster
Central ou no forum de discussao dos Webmasters.
Obrigada pelo seu tempo.
MAILE OHYE: bună.
Eu sunt Maile Ohye.
Am fost la Google acum de peste şase ani, de lucru cu
Căutaţi şi cu instrumente pentru webmasteri.
Aş dori să vă urez bun venit la casa mea.
Să discuta despre paginaţie şi SEO.
Pentru ordinea de zi de astăzi, vom începe mai întâi cu unele
exemple de conţinut paginat.
Apoi vom lua în unele dintre efectele secundare negative ale
paginaţie şi ce ca un webmaster ar putea să doriţi să faceţi
unele eforturi pentru a nu dilua dumneavoastră proprietăţi de indexare şi
pentru a afişa rezultate mai bune pentru utilizatori.
Apoi vom acoperi configuraţia dvs.
Şi acest lucru vine în două părţi –
pentru cei dintre voi webmasteri cu conţinut de paginat şi o
Vezi tot filme disponibile, şi apoi pentru cei care
webmasteri care au paginat conţinut dar
fără o pagina de vedere-toate.
Deci va fi două tipuri de configuraţii acolo.
Apoi am de gând să pas înapoi un pic şi vorbesc despre
ceea ce Google este de a face pentru a ajuta utilizatorii cu conţinut de paginat
şi webmasteri, precum şi.
Şi apoi, ultima, dat configuraţia dumneavoastră, dacă aveţi
au o pagina de vedere-toate disponibile sau aveţi nici o pagina de vedere-toate
disponibile, vom uita-te la opţiunile pe care le-aţi pentru dumneavoastră
conţinutul de paginat.
Deci să mergem mai departe şi să înceapă cu unele
exemple de conţinut paginat.
Conţinutul de paginat există de-a lungul web, iar eu sunt
de gând să acopere două din aceste cazuri frecvente.
Unul este un articol de paginat.
Deci să presupunem că te duci la dumneavoastră preferat site de conţinut, şi tu
a se vedea poveste de ştiri de rupere.
"Noi studii dovedesc că cookie-urile sunt superioare nutriţie
la legume." Si care ar fi destul de poveste.
Dar site-ul dumneavoastră preferat nu s-ar putea pune acest toate pe o singură pagină,
dar, în schimb, paginaţi-l în mai multe pagini de componente.
Acum acest articol unul a devenit trei, şi aceasta este o
exemplu de paginat articolele de conţinut.
Un alt exemplu de paginare este pentru lucruri ca un produs
Categorie, ca ceea ce s-ar vedea pe dumneavoastră preferat
e-commerce site-ul.
Deci să presupunem că acest webmaster este de vânzare de forme.
Acestea sunt de vânzare şase tipuri de forme.
Dar, mai degrabă decât l-au toate pe o singură pagină, au împărţit
în două pagini de componente, ambele dintre ele cu forme, crearea
paginaţie din nou.
Deci, două moduri comune sunt cu articole de conţinut paginat şi
cu categoriile de produse paginat.
Acum, ce sunt unele dintre efectele secundare negative de acest lucru?
Ei bine, există un cuplu.
Deci, aş dori să subliniez două, fiind prima care indexarea
proprietăţi, cum ar fi link-uri şi ancora de text, poate fi diluat
în diferite componente URL-uri, mai degrabă decât de a fi
consolidat la un articol sau la
la categoria de un singur produs.
Deci, care este unul dintre efectele secundare negative.
Cealaltă este că cele mai relevante filme din serie
nu ar putea fi reflectate în rezultatele de căutare.
Deci, dacă sunteţi webmaster-ului pentru acest site e-commerce, vă
s-ar putea ca utilizatorii să fie trimis la pagină, spun, din seria dumneavoastră.
Dar pentru că motoarele de căutare a se vedea acest paginaţie ca trei
separa entităţi, caută ar putea fi trimis la un alt
filme care nu ar putea fi cele mai relevante.
Deci acestea sunt câteva dintre efectele secundare negative ale
paginaţie.
Acum sa vorbim mai multe despre situaţia ta şi
configurare ai pe site-ul dvs.
Am de gând să se uite la acest lucru în două tipuri diferite
configuraţii.
Una este cu o pagina de vedere-toate disponibile, iar celălalt este
cu nici o pagina de vedere-toate disponibile.
Acum, dacă site-ul are paginat conţinut cu o
Vezi tot filme disponibile, există câteva lucruri să
doriţi să vă asiguraţi că vă testaţi pentru.
Unul este asiguraţi-vă că aveţi încă decente latenta dumneavoastră
site-ul, ceea ce înseamnă că, dacă un utilizator face clic pe vedere-toate
versiune, care nu ia le 15 secunde pentru a încărca
deoarece este un astfel de articol lung, sau
este atât de multe produse.
Dar că ei încă mai au o bună experienţă--
spun, pagina durează doar patru secunde pentru a încărca.
Al doilea lucru pentru a verifica dacă aveţi o pagina de vedere-toate
este disponibil pentru a vă asigura că pagina rămâne uşor
navigabil, ceea ce înseamnă că utilizatorii încă puteţi găsi conţinut
care doresc sau produsul care le
doresc de defilare sau vizualizarea titlurile cu uşurinţă.
Deci care este configuraţia de o pagina de vedere-toate disponibile.
Şi apoi, evident, fără o pagina de vedere-toate disponibile, ea are
destul de simplu.
Deci crezi despre site-ul dvs., în termeni de configurare
au. Dar înainte de a merge acolo, să luăm un pas înapoi şi
vorbesc un pic despre ceea ce Google este de a face.
Suntem desigur, întotdeauna lucrează pentru a îmbunătăţi
experienţă pentru cei care caută.
Şi un lucru pe care am găsit prin testarea este că noastre
Caută prefera afişează pagina de vedere-toate în căutarea lor
rezultatele spre deosebire de o pagină de componentă individuală.
Şi un motiv pentru aceasta ar putea fi din cauza latenţă.
Deci, dacă vă luaţi rezultatele căutării şi faceţi clic pe un rezultat la un
Pagina de vedere-toate, în timp ce s-ar putea lua, spun, trei secunde
pentru a încărca acest articol că noi studii dovedesc că cookie-urile sunt
nutriţie superioare a legumelor, care ar putea fi
trei secunde.
Dar pe de altă parte, caută erau mai puţin fericit atunci când
rezultate de căutare le-a luat la filme doar una din articol.
În timp ce care ar fi avut doar două secunde de latenţă şi
apoi pagina de încărcat, de fiecare dată că utilizatorul a vrut să faceţi clic pe
Lângă Citeşte mai mult de articol, a cauzat unele
timpul de încărcare suplimentară.
Deci acest latenta şi din alte motive, căutări prefera
Pagina de vedere-toate.
Deci, dat această cunoaştere, unul dintre inginerii noştri pe indexare,
Benjia Li, de fapt, a ieşit cu o nouă caracteristică
în octombrie 2011.
Acest lucru este--
"Când am detectat că, de asemenea, conţine o serie de paginat
o versiune de vedere-toate, acum facem un efort mai mare pentru
întoarce pagina de vedere-toate în rezultatele de căutare atunci când
corespunzătoare." Deci, care este mare pentru cei care caută.
Şi ceea ce este chiar mai bine pentru webmasteri este că în timp ce noi
detecta aceasta pagina de vedere-toate, ne va consolida, de asemenea, încă
indexare proprietăţi, cum ar fi link-uri, la pagina de vedere-toate.
Deci, din nou, acest lucru este bun pentru cei care caută şi bun pentru tine, ca
webmasteri pentru toate că indexarea de consolidare.
Acum, hai sa vorbim despre unele dintre opţiunile pe care le aveţi ca un
webmaster cu conţinut de paginat.
În primul rând vom uita-te la situaţia în care webmasterii
au paginat continutul si o pagina de vedere-toate disponibile.
Dar pentru cei dintre voi care au nici o pagina de vedere-toate disponibile,
este încă mai bine dacă vă acorde atenţie, pentru că unele dintre
aceste opţiuni va aplica pentru tine, de asemenea.
Deci, tu ai un site cu conţinut de paginat şi o
Vezi tot filme, aveţi trei opţiuni bun.
În primul rând, puteţi să lăsaţi aşa cum este.
Nu este nimic ce trebuie să faceţi dacă aveţi alte
priorităţile pe site-ul dvs.
Conţinutul de paginat există de-a lungul web, şi de căutare
motoarele va continua să facă o chiar mai bine
locuri de muncă de manipularea sa.
Şi după cum am menţionat mai devreme, dacă aveţi o pagina de vedere-toate
disponibile, Google va încerca automat pentru a detecta
asta, trimite caută acolo, precum şi consolidarea ţi
indexarea proprietăţi.
Deci opţiune una este o opţiune foarte solid.
Dar trebuie, de asemenea, o opţiune de a doua.
A doua opţiune este să fapt utilizarea rel = "canonical"
pentru a în mod explicit aluzie la Google ce este pagina ta Vezi-toate.
Deci în timp ce vom încerca pentru a detecta algoritmic, puteţi, de asemenea
spune-ne de scris rel = "canonical" pe ta
componenta pagini să Vezi-toate versiunea.
Şi aceasta este un fel de un indiciu mai explicit la noi despre cum
site-ul este configurat.
Cu rel = "canonical", aşa cum mulţi dintre dumneavoastră ştiu deja,
ne va consolida desigur proprietăţile indexare din
componenta de pagini cu versiunea canonică.
Deci lucrurile ca link-uri, de asemenea, va fi transferat.
Şi apoi, desigur, vom trimite utilizatorii să
Pagina de vedere-toate.
Deci, care este opţiunea numărul doi.
Ultima opţiune este de fapt făcut de doi dintre inginerii noştri,
Joachim şi Benjia.
Şi ceea ce este este folosind markup HTML standard de
rel = "next" şi rel = "prev" pe paginile de componentă în dumneavoastră
Seria a semnalului de la Google că acestea sunt individuale
pagini, dar toate au aparţin de o singură serie.
Deci, prin adăugarea acest rel = "next" şi rel = "prev" marcare, vă
conecta aceste componente individuale într-una singură.
Puteţi face acest lucru prin adăugarea rel = "următorul" la pagina unul şi
apoi rel = "prev" şi rel = "următorul" la pagina doi, toate mod de a
ultima pagină, care include numai o rel = "anunt".
Şi apoi, desigur, pe dumneavoastră Vezi-toate
filme, nimic nu este necesar.
rel = "next" şi rel = "prev" este marcare standard HTML, şi este
fost în jur de ani de zile.
Dar acum, Google este folosind acest marcare pentru webmasteri pentru a permite
ne despre conţinutul lor paginat.
Asa ca lasa-mi explic unele moduri că rel = "next"
şi rel = "prev" locul de muncă.
Cu rel = "next" şi rel = "Anunt anterior," mult cum ai vedea
cu ceva de genul rel = "canonical", vom
fapt consolida proprietăţile indexare din componenta
pagini de serie.
Şi în plus, spre deosebire de rel = "canonical" că numai
afişează pagina de vedere-toate în rezultatele căutării, cu
rel = "next" şi rel = "Anunt anterior," vom trece peste asta
comportamentul şi trimite utilizatorilor să numai una dintre
componenta de pagini.
Cel mai probabil, acest lucru va fi filme, deoarece frecvent că pe
Pagina cea mai relevantă.
Deci, acum în cazul în care aveţi, spun, această categorie de produse, de vânzare
-forme, dacă utilizaţi rel = "next" şi rel = "anunt"
marcare, voi ne spune că aceste două pagini
fac parte o serie.
Şi apoi cel mai frecvent, vom trimite utilizatorii la pagina unul.
Ştiu că rel = "next" şi rel = "prev" este un indiciu puternic.
Nu este un mandat prin orice mijloace.
Ultimul lucru pe care vreau să spun despre rel = "next" şi
rel = "prev" este acea componentă ar trebui să fie URL-uri într-o serie
concordanţă cu parametrii lor.
Aşa că haideţi să ia articol de noi studii dovedi că cookie-urile
sunt nutriţie superioare a legumelor.
Acum, haideţi să spun că aceste pagini contin un ID de sesiune.
Toate aceste valori pentru rel = "prev" şi rel = "next"
de asemenea, ar trebui să conţină sesiune ID-ul.
Şi acest lucru se datorează faptului că echipa noastră de indexare pare să
link-ul de fapt fiecare pagină într-o serie cu ceea ce a fost declarat
anterioare şi ceea ce a fost declarat următoare.
Şi atunci când fac asta, ei vor să facă sigur--spune ca esti
pe pagina doi--
care rel = "prev" care prevede rel = "prev" este
Pagina-1 & sid = 123, ei vor merge la acel URL.
Dar că URL-ul are de fapt la lista pagina doi
cu aceeaşi sid.
Şi asta e cum am poate leagă fiecare pagină în secvenţa.
Astfel încât să fie sigur de a păstra parametrii pe parcursul dumneavoastră întreaga serie.
Deci, sa recapitulam cele trei opţiuni.
Dacă aveţi o pagina de vedere-toate disponibile, vă
Puteţi lăsa aşa cum este.
Ai putea, de asemenea, în mod explicit statului rel = "canonical" pentru a vă
Vezi tot filme.
Sau puteţi înlocui pagina de vedere-tot comportamentul de
adăugarea rel = "next" şi rel = "fost" Prin adăugarea de
rel = "next" şi rel = "Anunt anterior," vă va ajuta ne consolida
componenta pagini într-o serie.
Dar în loc să trimită utilizatorilor la o pagina de vedere-toate, vom apoi
Trimite caută pentru o componentă filme., cel mai probabil
pagina ta serie.
Acum, hai sa vorbim despre configuraţia cu nici o Vezi-toate
filme disponibile.
Deci pentru cei dintre voi webmasteri care au paginat conţinut
şi nici o pagina de vedere-toate, aveţi două opţiuni.
În primul rând, desigur, puteţi să lăsaţi aşa cum este.
Asta e foarte bine.
Şi apoi opţiunea a doua este, de asemenea, să utilizaţi rel = "next" şi
rel = "fost" Din nou, prin utilizarea rel = "next" şi rel = "Anunt anterior," se
se conecteaza componente de pagini în serie, şi
consolidează indexare proprietăţi, şi ne ajută să
Trimite căutări la pagina cea mai relevantă, care este de natură
Prima pagina de serie.
Acum am de gând să bată-te să punch şi cere unul din
cele mai frecvente întrebări despre rel = "canonical", precum şi
ca rel = "next", "fost" Şi de aceea rel = "next" şi
rel = "anunt" pentru o serie de paginat, mai degrabă decât
rel = "canonical" la pagina de unul?
Ha!
Pun pariu ca te gândeai că.
Răspunsul este că rel = "canonic" este pentru
conţinut duplicat.
Aşa că haideţi să ia acest articol.
Să presupunem că două filme din articol, cookie-uri
sunt superioare nutriţie.
Dacă această pagină are de fapt o sesiune ID ataşat, apoi se
poate lista ca canonice aceeaşi versiune, duplicat
conversie, dar fără o sesiune ID deoarece
rel = "canonic" este pentru conţinut duplicat sau este pentru
conţinut care este un superset.
Deci, aici avem filme unul, pagina doi, şi pagina trei, toate
conectarea la versiunea canonică fiind
versiunea Vezi-toate.
Şi că este perfect bine, de asemenea.
Lucru despre rel = "canonic" este faptul că
numai indexează conţinut la versiunea canonică.
Deci, să mergem mai departe şi să ia o privire la acest lucru.
Dacă avem pagina doi şi pagina 3, pagina doi spune "cookie-uri
sunt superioare Nutriţie", şi pagina trei spune"
legume".
Dar ambele adăugaţi rel = "canonical"
doar la pagina unul.
Şi indexul Google va cluster apoi pagina unu, doi,
şi pagina trei toate împreună.
Dar singurul lucru care ne veţi avea indexate este conţinutul
din pagina de unul, versiunea canonică.
Deci indexul nostru va conţine de fapt "noi studii dovedesc
asta."
Şi acum utilizând această rel = "canonical" incorect,
Acest webmaster-a pierdut total conţinutul "cookie-uri sunt
nutriţie superioare"şi"la legume." Deci de aceea
rel = "canonical" nu funcţionează în acest caz.
Dar rel = "next", "prev" funcţionează pentru o serie sau
o secvenţă de conţinut.
Aşa că haideţi să ia aceste două exemple paginat din nou.
Prin utilizarea rel = "next" şi rel = "Anunt anterior," vom încerca, de fapt, în
Google index, marcaţi-l ca o serie.
Dar vom avea filme unul, pagina doi, şi pagina trei toate
indexate separat.
Deci în indexul nostru, ştim filme una se referă la "noi studii
dovedi că,"pagina doi,"cookie-urile sunt superioare
Nutriţie", iar pagina trei,"la legume." Şi toate trei
pagini vor fi indexate şi marcate într-o serie.
Deci, care este mare diferenţă între rel = "canonical" şi
rel = "next" "fost"
Asa ceva de remarcat este că rel = "canonical" poate de fapt
fi utilizat alături de rel = "next" "fost" Aşa că haideţi să aruncăm o privire
la pagina doi din nou.
Şi de această dată, ea are un ID de sesiune.
Acest URL poate lista de fapt ambele versiunea canonică
fără un ID de sesiune, precum şi o rel = "prev" şi rel = "next"
cu, desigur, aceeaşi parametri, inclusiv
ID de sesiune.
Deci, acum, sa recapitulam setul de instrumente dumneavoastră noi paginare.
Incepand cu Google, avem două caracteristici noi pentru tine.
În primul rând, suntem a face un efort mai bine pentru a detecta o Vezi-toate
filme, şi apoi cautatori de trimitere la faptul că
Vezi-toate versiunea preferată.
Caracteristica de al doilea este dacă doriţi să suprascrieţi fapt chiar
Acest comportament.
Deci, pentru cei dintre voi cu o pagina de vedere-toate disponibile sau
fără, dacă adăugaţi markup cu rel = "next" şi
rel = "Anunt anterior," semnale de la Google că acestea sunt
componenta pagini într-o serie.
Vom apoi consolidarea indexare proprietăţi, şi trimite
căutări la pagina cea mai relevantă, cel mai probabil una pagină.
Acum, sa trecem în tipuri de
configuraţii aveţi la dispoziţie.
Deci recapping, dacă aveţi o pagina de vedere-toate disponibile, vă
au trei opţiuni.
Puteţi să lăsaţi aşa cum este.
Puteţi utiliza rel = "canonical" paginile de componente, arătând
pagina ta Vezi-toate.
Sau aveţi posibilitatea să reinterpretaţi toate detectarea Vezi-toate adăugând
rel = "next" şi rel = "anunt", ne spune că aceste
componenta pagini aparţin unei serii.
Şi aş dori, Google, pentru a trimite caută pentru cele mai
Pagina individuale relevante, din nou, pagina probabil unul.
Acum, cealaltă parte de instrumente paginare este pentru
cei dintre voi cu nici o Vezi-toate disponibile, şi
aveţi două opţiuni.
Desigur, puteţi lăsa exact aşa cum este.
Sau din nou, puteţi utiliza rel = "next" şi rel = "fost"
Acest lucru vă ajută să consolideze toate paginile componentă în
caută o serie şi trimite la pagina cea mai relevantă.
Deci, mare lucru despre aceste caracteristici de paginare este că
Am fost la Google destul de mult pentru a vedea copilăriei la
Când Comunitatea webmaster a fost vorbesc cu noi despre probleme
cu pagination până acum când avem mai multe caracteristici
disponibil pentru tine.
Deci mulţumesc atât de mult la toate de tine pentru feedback ajutor
şi pentru a fi parte din aceasta comunitate de webmaster.
Pentru mai multe informaţii despre paginaţie, aici sunt unele
link-uri disponibile.
Vă puteţi desigur, alături de noi la Webmaster Central
Blog-ul sau în forumul de discuţii pentru webmasteri.
Vă mulţumim pentru timpul dumneavoastră.
Привет!
Меня зовут Майли Ойе.
Я работаю в Google более шести лет,
работая с поиском и инструментами для вебмастеров.
Я хочу пригласить Вас в мой дом.
Давайте поговорим о пагинации и поисковой оптимизации.
Наш план работы начинается с примеров разбивки
контента на страницы.
Затем мы перейдем к негативным сторонам пагинации
и причинам, по которым Вы как вебмастер можете захотеть
приложить усилия, чтобы не уменьшить Ваши индексируемые свойства
и показать пользователям лучшие результаты.
Затем мы обсудим Вашу структуру.
И этот пункт делится на две части:
для тех вебмастеров, чей контент разбит на страницы,
Итак, давайте начнём
с примеров разбивки контента по страницам.
Разбитый на страницы контент существует по всей сети
и мы поговорим о двух общих случаях.
Первый из них - разбивка статьи на страницы.
К примеру, вы заходите на свой любимый сайт
и видите экстренное сообщение.
Последние исследования показали, что печенье - более питательны, чем овощи."
И, конечно же, это была бы выдумка.
Но ваш любимый сайт мог поместить этот текст не на одну страницу,
а разбить его на несколько подстраниц.
Таким образом, одна статья превратилась в дерево, и это -
пример статей, разбитых на страницы.
Другой пример пагинации - структуры, подобные разбивке товаров
на категории, которые вы можете увидеть на сайте
вашего любимого интернет-магазина.
Итак, давайте представим, что этот вебмастер продаёт фигуры.
Они продают шесть видов фигур.
Но вместо того, чтобы поместить их на одну страницу, они разделили их
на две подстраницы (обе из них с фигурами),
вновь создавая пагинацию.
Итак, два основных способа - пагинация статей
и пагинация категорий товаров.
Какие негативные последствия это влечёт?
Их несколько.
Я бы хотела подчеркнуть два из них. Первый заключается в том, что
индексируемые свойства (такие как ссылки и анкоры), могут быть расположены
на разных URL-адресах вместо того, чтобы
консолидировать их в одной статье
или в одной категории продуктов.
Это одна из негативных сторон.
Вторая заключается в том, что самая релевантная страница в этой последовательности
может не отражаться в результатах поиска.
Если вы - разработчик интернет-магазина,
вы, возможно, захотите, чтобы пользователи, к примеру, были перенаправлены на первую страницу последовательности.
Но поскольку поисковик видит эту пагинацию как три
отдельных объекта, пользователь может быть переадресован на другую страницу,
которая не обязательно будет наиболее релевантной.
Это некоторые негативные стороны
пагинации.
Теперь давайте побеедуем о вашей ситуации и
конфигурации вашего сайта.
Рассмотрим этот вопрос с точки зрения двух разных видов
конфигурации.
В одном из них присутствует страница с полным содержанием,
а во втором - нет.
Если контент вашего сайта разбит по страницам
и есть страница с полным содержанием,
протестируйте следующее.
Для начала убедитесь, что скорость загрузки страниц вашего сайта вполне сносная,
то есть когда пользователь открывает страницу
с полным содержанием, загрузка не займет у него 15 секунд,
поскольку это очень длинная статья
или на странице очень много товаров.
к примеру, загрузка страницы занимает всего 4 секунды.
Второй пункт, который необходимо проверить, если у вас есть страница с полным текстом -
убедитесь, что навигация на странице остается удобной,
то есть пользователь может легко найти контент, который ищет,
или определенный продукт, который им нужен,
прокручивая или просматривая заголовки.
Это конфигурация сайта со страницей с полным содержанием.
И, конечно, сайты без страницы с полным содержанием
не имеют этой проблемы.
Итак, взгляните на ваш сайт с точки зрения его конфигурации.
Но прежде, чем мы займемся этим, давайте вернемся назад
и поговорим о том, что делает Google.
Конечно, мы постоянно работаем над тем,
чтобы облегчить поиск для пользователей.
И во время тестирования мы обнаружили,
что пользователи предпочитают видеть страницу с полным содержанием
рядом с результатами поиска.
И одна из возможных причин - скорость загрузки.
Итак, если вы перейдете к результатам поиска и кликаете
по странице с полным содержанием, загрузка статьи о том,
что новые исследования доказали, что печенье более питательно,
чем овощи, должна занять
три секунды.
Но, с другой стороны, пользователям меньше нравилось,
когда результаты поиска направляли их только на первую страницу статьи.
В то время, как загрузка этой страницы занимается всего 2 секунды.
каждый раз, когда пользователь нажимает на кнопку
"Следующая страница", чтобы прочитать продолжение статьи,
это занимает дополнительное время.
То есть ввиду скорости загрузки и других причин, пользователи предпочитают
страницу с полным содержанием.
Зная это, один из наших инженеров индексации,
Бенджа Ли, предложил новую функцию
в октябре 2011.
Она заключается в том, что:
"Когда мы определяем, что разбитый на страницы контент
имеет страницу с полным содержанием, мы стараемся
вернуть ее в результаты поиска,
когда это необходимо. Для пользователей это очень удобно.
И что еще лучше для разработчиков, так это то,
что хотя мы определяем страницу с полным содержанием, мы все равно
консолидируем индексируемые свойства, такие как ссылки на страницу с полным текстом.
Таким образом, это удобно для пользователей и хорошо для вас как разработчиков
Давайте теперь поговорим о некоторых возможностях. которые у вас есть как у разработчика сайта
с контентом, разбитым на страницы.
Сперва взглянет на ситуацию, когда разработчик
разбил содержание на страницы и сделал страницу с полным текстом.
Но даже тем разработчикам, у кого нет обобщающей страницы,
будет полезно обратить внимание на эту информацию, поскольку
некоторые опции также относятся к вашим сайтам.
Итак. если у вас есть сайт с разделенным на страницы контентом и
страницей с полным содержанием, у вас есть три отличных варианта.
Во-первых, вы можете оставить все как есть.
Вам ничего не нужно делать, если у вас есть
другие приоритеты.
Разбитый на несколько страниц контент распространен по всей сети, и
поисковые машины будут индексировать его
даже лучше.
И, как я уже упоминала, если у вас есть обобщающая страница,
Google автоматически постарается определить это,
перенаправить на нее пользователя и консолидировать ваши
индексируемые свойства.
Первый вариант - это надежный вариант.
Но у вас также есть второй вариант.
Он заключается в использовании атрибута rel="canonical",
который недвусмысленно дает поисковой системе понять, что это ваша обобщающая страница.
таким образом, пока мы пытаемся определить это алгоритмически, вы можете помочь нам,
Chào.
Tôi là Maile Ohye.
Tôi đã làm việc cho Google được hơn 6 năm, đang làm việc về
tìm kiếm và về những công cụ quạn trị web.
Tôi muốn chào mừng bạn tới ngôi nhà của tôi.
Hãy tán gẫu về sự xếp hạng và SEO.
Cho chương trình hôm nay, đầu tiên chúng ta sẽ bắt đầu với một số
ví dụ về nội dung đã được xếp thứ tự
Sau đó chúng ra sẽ nhận lấy một số tác dụng phụ của
của sự sắp xêp thứ tự và tại sao bạn cũng như quản trị web muốn tạo
một số sự nỗ lực cũng như để không làm giảm những đặc tính chỉ số của bạn và
để chỉ ra những kết quả tốt hơn cho người dùng.
Sau đó chúng ta sẽ che đi cấu hình của bạn.
Và điều đó đi kèm trong hai phần
cho những ai trong các bạn quản trị web với nội dung đã được sắp xếp và
một điểm nhìn về tất cả trang có sẵn, và sau đó cho một số người trong các bạn
những quản trị web có nội dung đã được sắp xếp nhưng không
có tầm nhìn tới tất cả các trang.
Vây, sẽ có 2 loại cấu hình.
Sau đó, chúng ra sẽ quay lại 1 tí và nói về
Google đang làm gì để giúp người dùng với nội dung đã được sắp xếp
cũng như quản trị web.
Và cuối cùng, đưa ra cấu hình của bạn,
大家好。
我是Maile Ohye。
我已经在谷歌工作六年了，
做的是和搜索和Webmaster工具相关的工作。
我想邀请你来我家做客。
对于今天的议程，我们先从