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工具相关的工作。
我想邀请你来我家做客。
对于今天的议程,我们先从