Transcript Of The Office Hours Hangout
Click on any line of text to go to that point in the video
JOHN MUELLER: All
right, welcome everyone
to today's Google Webmaster
Central Office Hours Hangout.
My name is John Mueller.
I am a webmaster trends analyst
here at Google in Switzerland,
and part of what I do is talk
with webmasters and publishers
here in the Hangout.
We have a bunch of
questions submitted again.
So thank you all for
submitting questions.
If there any people here
in these Hangouts who
haven't been joining
the Hangouts regularly
and have a question on the
mind, feel free to jump on in.
Let's get started
on the questions.
So one thing I did
with the questions is I
went through and tried to
categorize them roughly
so that we can look at them in
groups that kind of make sense.
Most of them we'll
try to get through,
but if there's anything missing,
feel free to add them again
to the next Hangout.
The topics I have compiled
here are crawling and indexing,
internationalization, structured
data, duplicate content,
and pretty much
everything else, which
we'll see how far we can go.
All right, so starting
with crawling and indexing.
Whoops, let me find
the question here
so we can actually highlight it.
"Is it true that if a page
hasn't been crawled recently,
it won't rank well or
be given less authority.
Also, is there any advantage
to resubmitting your sitemap
weekly or more often?"
So it's not true that
if a page isn't crawled
regularly that it won't
show up in rankings at all?
In general, we try
to do our crawling
based on what we think
this page might be changing
or how often it
will be changing.
So if we think that something
stays the same for a longer
period of time, we might not
crawl it for a couple months,
and that's completely fine.
We can still show it in search.
So that's not something that
see is a direct relationship.
Oftentimes, there is
a kind of relationship
in that when we think
something is important,
we tend to crawl
it more frequently,
and that might be also
more visible in search,
but it's not really
the case that you
could say from the
amount of crawling,
this means how important
it'll be shown in search.
And similarly, it
doesn't really make sense
to resubmit things
in a sitemap file
if you're not
making new changes.
And in addition, most
CMS systems automatically
submit a sitemap file
whenever you make any changes.
So you definitely don't
need to do that manually.
"Are there any crawling
indexing limitations
when moving from
HTTP1 to HTTP2?"
So at the moment,
Googlebot doesn't
support HTTP2-only crawling.
So if your website is
only accessible via HTTP2,
that's the next
version of HTTP, then
we wouldn't be able to
crawl that properly.
We're working on that.
I suspect it'll be really by
maybe the end of this year,
early next year,
something around that.
One of the big
advantages of HTTP2
is that you can bundle requests.
So if you're looking
at a page, and it
has a bunch of
embedded images-- CSS,
JavaScript files-- those things.
Theoretically, you can do one
request for all of those files
and get everything together.
So that would make it
a little bit easier
to crawl pages when we're
rendering them, for example.
Let's see.
So many questions
back and forth.
"We changed our old domain
name to a new domain name,
and did some 301s to a
completely different domain.
Somehow in that redirect
chain we got a 302
in that redirection
due to a CMS issue.
So like an old URL,
302, and then a 301,
and then to the final new URL.
Are we passing some page value?"
Yes, we'd probably see that as
a normal site move, redirect,
and just processes it like that.
So it doesn't really matter
if it's a 302 in there,
it's not the case that 302s
do anything magical to block
the flow of page rank.
So from that point of
view, that's not something
you need to worry about.
"When a domain change happens
with proper 301 and Webmaster
Tools, a change of
address set up properly,
how long does it usually
take for the new pages
to appear instead
of the old ones?"
Hard to say.
It can be up to
maybe hours or a day
or so after you've
set all of that up.
Then we can process that and
handle that as a site move.
That can happen fairly quickly.
But what will probably
happen is that for some
of URLs on your site, it will
take a little bit longer,
and for some it will
go a lot faster,
and that's just from a
natural point of view
how we crawl a website
in that some pages are
crawled more frequently.
Others are crawled
less frequently.
And for those that are
crawled less frequently,
it'll take a bit of
time for everything
to be forwarded there.
So that's something
where you wouldn't
necessarily, if you do a
site query for the old URL
and see that these URLs
disappear within a day, that
probably takes maybe half a
year, maybe even a little bit
longer.
"How does Google
measure web speed?
How much is first [INAUDIBLE]
important in web speed
by using Google Speed Tool.
I'm getting 90% from my
web and 84% from my mobile.
But honestly, poor
performers are ranked well
even though I'm following
all of Google's rules."
So on the one hand,
page feed is something
we do take into
account, but it's not
something that would be a
critical ranking factor.
If we have equivalent
pages, and we
see one is significantly
slower, then that's
something we might
take into account.
With regards to crawling, we
take that time into account
as well, and that's
probably where
you'll see the bigger effect
in that if your page is really
slow to load-- it's really
slow to fetch from a server,
then we probably will crawl
less from your website
and won't be able to pick up all
of your new content as quickly.
So for that, we look at things
like the overall response time,
how long does it
take for this request
to go through, the connection
time to the server.
We see if there are any server
errors that we run across.
And all of this comes
together and helps
us to figure out how
many URLs a day we
can crawl from the server.
And the faster your
server is, the better
it can respond to these
requests, obviously,
the more we can crawl
from the server.
And that particularly
plays a role now
that we're doing more and
more rendering on this page.
And so for indexing, we
don't just look at the HTML.
We try to actually look
at what the page looks
like in a browser.
And that means we have to
fetch things like CSS files,
JavaScript files, images--
all of that as well.
So on the one hand, if your
server is really slow already,
then all those files will
slow it down even more.
On the other hand,
if your pages are
built in a way that require
tons of individual URLs
that also have to be
loaded, then that also
slows down how fast we're
able to index your content
essentially because
we have to do requests
for all this embedded content,
and that takes time as well.
"I have to move a DNS zone
file, and after 48 hours,
we're still getting temporarily
unavailable from Fetch
as Google-- tried confirming
the DNS with DNS Tools.
What can I do?"
So this probably just means
that the old DNS information
is still cached
somewhere, and that's
something that can take a bit
of time to actually settle down.
I assume since you
submitted this question,
things have settled down
already, or at least,
I hope so because at most, I'd
see this maybe a day, maybe
two, in this case here
where you'd see this time.
You can prepare for that a
little bit by setting your TTL
settings in the DNS to say
that these DNS settings are
likely to change very
quickly, for example,
maybe setting them to
an hour instead of-- I
don't know what the default is.
And change that back obviously
when you've actually made them.
"Can you elaborate a bit
on the If-Modified-Sense?
How does it work?
Do we really have
to do anything?
We're using WordPress?"
If-Modified-Since
is essentially a way
to optimize your crawling
in that Google or browsers
in general will do a
request to a server
and say, hey, I really like
the contents of this URL
if it has changed since
this specific date.
And sometimes it
can help your server
by not having to transfer
all of that content again.
If the server can just say,
hey, this file hasn't changed.
You don't need to do
anything, and then we can just
re-use our cached version.
So that kind of helps
to improve the caching
and to make sure that
we're not keeping
any stale content in our index.
That's kind of the
technical background there.
If you're using a common
CMS like WordPress,
then that will be handled
for you automatically.
You don't really need to
do anything special there.
I guess the good part about
these kind of standards
that work across the web, that
work for browsers as well,
is that people implement
them fairly quickly,
and if you're building on
top of an existing platform,
then it's a lot easier for you
to just focus on your content
instead of having to focus on
all of these technical details
as well.
"Search Console is
showing our index status
with 2000 index pages in Google.
However, when I do a
site query, I see 350.
What's up?"
I guess these are different
numbers that you're probably
looking at there,
and they essentially
come from the way the
numbers are generated.
So site query is not meant as a
way of comprehensively looking
at all the content on the site.
It's really not meant for that.
So I wouldn't use it as a
metric from a webmasters
point of view.
The index status
information is a lot more
comprehensive and complete in
that it includes everything
that we've indexed
from your site.
However, it also includes
things like duplicate content
that were probably not showing.
So if you have multiple URLs
that lead to the same content,
we might include those as
separate counts in the index
status count there.
So what I'd recommend doing
is instead of focusing
on these two very
broad numbers, it
is looking at your sitemaps
index count actually.
So if you take all of the URLs
that you really care about,
you put them in the sitemap
file, or even just a text file
with all of the URLs
listed, you could
submit that in Search Console
as well, and on a daily basis,
we'll give you information
on how many of those
URLs that you submitted
that you really care about
are actually indexed.
So instead of looking
at vague number
that kind of fluctuates
up and down a bit,
you're actually
looking at of the URLs
that you really care
about, how many of those
are actually indexed.
All right, moving on to
internationalization.
"My co.uk site returns a .com
version on a branded search
even though it has a
301 back to the co.uk.
How do I fix this, and is this
hurting my rankings as the .com
is showing a higher
PageRank than the co.uk?"
So I guess first
of all, I wouldn't
worry about the PageRank.
That's something that we
haven't updated in, I think,
more than a year now.
So looking at the PageRank
score in the toolbar
is not really going
to be that useful.
On the other hand, you
can do things like use
a hreflang markup to let us
know about your preference
and which URL to show
in which location.
But this is essentially
a hint for us.
It's not a clear directive
because sometimes people
get the hreflang markup
wrong, and that's
something we have to
live with and still show
the proper search results.
So that's something
that you could do there.
Sometimes we also see that a
different version of the site
is actually much more relevant
even though the hreflang
markup is there.
So we'll still show it.
And, finally, with
regards to rankings,
with the hreflang
markup, we're essentially
just swapping out the URLs.
So we're not changing
anything in the ranking.
So if you're seeing the wrong
version of the URL there,
then essentially
we're just showing
the wrong version of the URL.
It's not that it would be
thinking differently if we
were showing the other version.
Let's see.
"I'd like your opinion
on a possible bug
that I sent your way.
We have hreflang and a
301 redirect in place.
Why is it indexed?
Often, but not always, the URL
is rentalcars.com/gb instead
of rentalcars.com/en. "
In general, if you're
seeing things like this,
and these are within
normal pages on your site,
and you have hreflang
markup in place, then
probably we're not able to pick
up hreflang markup properly.
And that can come
from various reasons.
Some of the most
common ones that we see
is that you're not using
the hreflang markup
between the canonical URLs.
So in a case like this,
and the question here--
you have GB in uppercase and
EN in lowercase, for example.
If you allow both versions
of uppercase and lowercase
language codes
there, then you have
to make sure that we're actually
picking the one that you're
using for hreflang markup.
So you can use a rel
canonical for that
to really let us know this
is the version of the URL
that you need to
use as a canonical.
And we'll use the
hreflang markup
between those canonicals.
So that's one thing
to watch out for.
The other thing
that we often see
is that the hreflang
is outside of the head
section of the page
in that maybe there
is some JavaScript
that's generating
a piece of text that's kind of
closing the head implicitly.
Maybe there's something
within the HTML itself.
Maybe the head is
somehow broken HTML
that caused the browser to close
the head section at that point.
So that's something where
maybe this hreflang markup just
isn't being picked up properly
because it's not really
in the right place.
And Search Console gives
you a lot of information
about these kind of errors.
So I'd really double
check there to make sure
that it's in the
right place-- that's
its being picked up
properly-- that you're
seeing those backlinks as
well-- all of those things.
All right, moving on
to structured data.
One thing to mention
before we move
on to more of the questions
here about structured data
is that people are seeing
structured data as something
that probably isn't based on one
of the comments I made in one
of the previous Hangouts.
We do use it to understand
the page a little bit better.
But it's not going to be a
ranking factor in the sense
that your cycles suddenly
start ranking positions higher.
So this is more
of a subtle thing
that we're trying to figure out
what your page is really about
and show it for
the right queries.
It's not that your
site is going to jump
in rankings automatically
just by implementing
structured data.
In general, we try to
go by the guideline
of looking at which pages are
actually relevant for the user
instead of looking at which
pages are implementing
any kind of specific
technical markup, for example.
So that goes with
regards to HTML.
If a page is valid HTML, then
obviously that's a good thing.
But it's not that
a user is really
going to notice that in most
cases if it's valid HTML
or not.
So we're not going to use
that as a ranking factor.
So moving on to
this question here.
"I've been told our
schema markup hasn't
been done correctly even though
Google's testing tool says
it's OK.
Can this affect my rankings?"
In general, if the
testing tool says it's OK,
then that's a good thing.
So that's not something
that would negatively
affect your rankings in any case
if it were marked up correctly
or not.
So at least from
the rankings point
of view, that's not
something I'd worry about.
With regards to markup
being done correctly,
that's sometimes a bit tricky
because technically you
might be implementing
it properly,
but from a policy point
of view, maybe you're
marking the wrong things up.
So, for example, one
thing we sometimes see
is that people
use recipe markup,
and they use is on a page
that actually isn't a recipe.
So maybe they
have, I don't know,
a website that
they're reviewing,
or a picture of their house,
or something like that,
and they add the recipe markup
with the hope of getting
that image shown in search.
And technically that might
be implemented properly.
The testing tool might say
that it's implemented properly
because from a technical
point of view, it is,
but from a policy point of
view, that's not a recipe.
So that's not something
that we'd actually
show as a recipe in search.
Here's another one that
goes in the same thing.
"Rich snippets help
in Google rankings
because it's easy for Google to
understand the web structures."
So again, that's kind
of incorrect there
in that we do use rich snippet
in the structured markup
to better understand
the page, but your site
isn't going to rank
higher just because it
has structured markup.
And specifically,
around rich snippets,
there are snippets
that we highlight
in the search results.
It doesn't mean that we'll
rank it higher if you
have rich snippets shown.
The question goes on, "So even
breadcrumb, rating, webmain all
put a bit of a
ranking factor or only
go for whatever is needed and
easy to implement in the web
design."
So, again, these are things
that are ranking factors.
They help us to better
understand the page,
and sometimes we'll
show some of that
in the snippet in
the search results,
but it's not that
your site is going
to rank better by implementing
all these technical things.
If it were just a matter of
implementing things technically
correct, I'm sure the
search results would
look very different,
and users would
be very unhappy by seeing
all of these pages that
are technically properly
but don't really
have great content.
So instead of focusing just
on these technical aspects,
I'd really focus on making
sure that your site actually
provides something useful
and valuable for the user.
"If Google sees a link between
two sites," so this is,
I guess, more in the direction
of duplicate content.
"If Google sees a link
between two sites,
for example, two affiliates
who have the same manufacturer,
but have separate entities
and their own content,
will you rank both
of these sites?
Or do you choose
one over the other?"
Maybe, maybe not.
So in general, if this
is separate content,
unique content that's worth
showing separately in search,
then we will show
separately in search.
So regardless of whether
or not there's an affiliate
relationship there
or not, if we can
see that this is unique
content and valuable content
to show to you, we'll
try to show it separately
in the search results.
On the other hand, if this
is affiliate content where
the description is just
copied and everything
is the same on these
pages, then we'll
probably recognize that it's
essentially the same thing
and fold them together and
just show one of these things
are in the search results.
"Any harm in having a
canonical tag that's
pointing at the home page?"
I guess there is a subtle thing
here with this question that
might not be directly
noticeable in that
if you're looking
at your home page
and you have a canonical
tag at your home page,
then that's obviously
the right thing to do.
If you're looking
at the whole website
and all of the
pages on the website
have the canonical tag
set to the home page, then
essentially you're saying
don't index all of these pages.
Only focus on the home page.
So you're losing out on
having all of the content
that you have
elsewhere on the site
indexed by us focusing
only on the homepage.
So that would be-- we'd see
that more as a technical issues
on the website.
And that might be
the kind of situation
where our systems might
say, well, the rel canonical
tag is implemented
incorrectly here,
therefore, we'll ignore it.
So if you're talking
about the home page,
then obviously a canonical
tag to the home page
is perfectly OK.
If you're talking about
the whole website,
then the canonical tag is
always to the home page,
then that would be
a technical problem
that I'd recommend fixing.
Let me just find this question.
"Can I keep a
self-referencing canonical tag
while trying to de-index
a page using noindex
and follow at the same time?
Will this send mixed signals to
Google and cause any issues?"
So if you have
self-referencing, canonical tag,
you're basically saying this
is the canonical version
of that page.
And if you have a noindex on
that, you're basically saying,
don't index this page.
So that's, I think,
that's perfectly fine.
I think that would work
without the canonical tag
as well because we'd just find
that page, see the noindex,
and process that.
It would be trickier if
you have one page that
has a canonical tag pointing
at a different page,
and that page has
a noindex on it
because then we'd see one
page without a noindex that
has a canonical pointing
somewhere else, which tells
us don't index this page,
but index that one instead,
and the other one has
a noindex saying, well,
don't index this page.
So we kind of stuck
in the situation
of being a little bit
conflicted there, and that
might be something where you
might see different outcomes.
"An e-commerce site has pages
with similar content except
for the color and has URLs
like product one in red,
product one in
blue, for example,
500 products, 5 to 40
different variations.
Can this cause a penalty?"
No, well, I guess it could cause
a penalty if the content is
really spammy and problematic.
But in general, if
this is null content
for an e-commerce website, then
no this kind of duplication
would not cause a penalty.
We don't have a duplicate
content penalty in that sense.
What will probably happen is
we'll fold some of these pages
together for indexing
and show then
the search results as
one URL instead of all
these different variations.
But essentially, that's more
of a technical issue and not
something that would
negatively affect your website.
"Should all of these pages
except one per product
be noindex?"
I wouldn't use noindex
in a case like this
because with the noindex,
you're essentially
saying this page should
be dropped from search.
That means if anyone is
looking, for example,
to the blue version of the
page, and the red version
is the one that
doesn't have a noindex,
then we would essentially
dropping that link,
and it would disappear.
So that's something where
what might make sense
is to use a rel
canonical and say this
is the main page
for this product,
and I have these
different variations.
But the canonical is
set to the main page.
So in a case like
that, if anyone
were to link to any one of
these specific variations,
we'd still be able to forward
that to the main page.
And that also helps us with
indexing in that we understand,
well, these are
different variations
we've crawled and indexed them.
But, actually, we should
fold all of that information
to that main product page.
So that's one thing that you
might be able to do there.
I definitely wouldn't just
noindex these variations.
MALE SPEAKER 1: Hey, John, can
I have a follow up on that?
JOHN MUELLER: Sure.
MALE SPEAKER 1: So let's
say that person uses rel
canonical to fold their thing
into a main product page.
When you merge all of
these things together,
what happens when
somebody searches
for like red version
of the product,
but the main page doesn't
specify the red version.
It's only the red
separate version
that specifies red keyword
something like that?
Does that affect the ranking
or relevance in any way?
JOHN MUELLER: Yes, it can.
Yeah.
So if the main page doesn't
even mention these variations,
then we wouldn't be able
to take that into account.
But in general, you'd
have a main page,
and it would have a link
saying these variations are
available like red,
green, blue, large, small,
or whatever you have.
And from that, we know
that, well, this word
is on that page, we understand
that it belongs together.
But if there's other
content, for example,
on a page that isn't canonical--
that has a canonical pointing
to a different page, we
wouldn't take that into account.
MALE SPEAKER 1: Right.
Got it.
Thanks.
JOHN MUELLER: All
right, so let me run
through the other questions.
They kind are a mix
of different things.
One quick thing I
noticed is that there
were some questions about the
local rankings and perhaps not
really something I can help with
because that's essentially done
by the local business
people, not something
that we do from a web
search point of view.
Can't try them off hand, but
maybe we'll run across some.
"What would you say if I put
my links to our other branches
in our footer?
Google will not take kindly
to this and see it as spammy?"
In general, that's
fine, especially
if you have a limited
number of different branches
that you're looking at.
If you have handful of sites,
and you're putting them
together, then sometimes
that make sense
if you link those individual
versions from a footer,
for example.
On the other hand, if you
have hundreds of sites, then
probably it wouldn't
make sense to link
all of those in the footer.
On the one hand, that's
probably something
you'd want to consider
folding together anyway
just because it starts looking
a lot like doorway signs.
On the other hand, that's a lot
of stuff to put into a footer,
and I don't know if that would
really be useful to any user.
"Can you offer any advice for
optimum website architecture?
Also, what can you do
over internal linking?"
In general, for
website architecture,
I'd make sure that
it works for the user
that you have a clear context of
the individual pages-- that you
have a clear structure
of the pages--
that they are linked in
a way that makes sense.
And if we can see
those lines-- if we
can see all of our
content, then that's
something we can
pick up on and use.
One variation that
we sometimes see
that probably isn't that
optimal is if all of your pages
are linked from all
of your other pages.
So especially if you have more
than just a handful of pages,
and they're all
interlinked, then it
makes it really hard for us
to understand the context
of any particular page there.
But in general, if
users can use the setup
that you have there for
website architecture,
then we'll generally be
able to use that as well
and be able to handle that
fairly reasonably in search.
Oh, one type of
architecture maybe
worth mentioning
that we do sometimes
see, especially on larger sites
on more reference-type sites,
which could be things like
government sites or sites
where you have to do
lookups from a large catalog
of products is if the main
navigation within the site
is essentially a search form,
then that's something we'll
have a lot of trouble crawling
through because if we just see
that search form, we don't have
leads to the individual pages
that you're actually
showing there,
then that makes it really
hard for us to even find
all of that content.
So providing some
kind of structured way
to navigate through your
content definitely makes sense.
"Do you take
categories into account
when providing the
search results?
So, for example, you don't
show only metasearch engines
on page one-- have a diversity
of different suppliers
or portals."
We take a lot of
things into account
when it comes to ranking.
I'm not sure if we directly
take something like categories
into account.
But we do try to provide a
diverse set of search results
so that when someone is
searching for something,
they don't just see the
same thing over and over
again so that they actually
have a variation there.
Otherwise, if it's the same
thing or the same type of site
over and over again, we
might show it once and not
show 10 different results.
So that's kind of the reasoning
behind showing multiple results
on a page in that it should
be something different so
that the user can pick whichever
one makes sens for them.
"Should we still use
PageRank as a benchmark?
Is it how Google values a page?
Or are there other metrics
that are better to use?
Is the PageRank
algorithm still current
even though it
hasn't been updated?"
So we have updated Toolbar
PageRank in, I don't know,
maybe a year, maybe
two years now.
I think the last update
we did was even accidental
and wasn't really
meant to be updated,
so I definitely wouldn't
use Toolbar PageRank
as a metric for a sidebar.
I would focus on other metrics,
and you know your sites best.
You know best what you want
people to do-- what you think
is a good thing to
do for your sites.
That could be something like
tracking the conversion--
that those kind of things.
But PageRank is definitely
not one of those metrics
that I'd focus on.
"I found some old 404s that
are still showing PageRank."
Oh, my god, everyone is
focused on PageRank this time.
It's crazy.
"So I found some old 404s that
are still showing PageRank
and should've been 301s .
Is it never too late to change
them back, and if we do,
will we still get
the link juice?"
So sure, if these are
pages that are 404,
and we're still seeing
traffic to them,
then using a 301
redirect is a good way
to guide the user in
the right direction.
Obviously, having
a useful 404 page
is also a really good thing
to do because that also
helps users to find
that content again.
If you are just focused
on PageRank, then again,
since we haven't updated
for such a long time,
you're probably looking at a
number that doesn't really make
sense for these URLs anymore.
And if this has been changed
a really long time ago,
then chances are those
URLs are just 404s.
They are not actually
indexed like that anymore.
We don't really do
anything with them anymore.
So redirecting them
just for the sake
of getting some search engine
value out of it probably
isn't the best use of your time.
"Is there any link between one's
Google+ page showing in local
pack and the ranking of
another page from your site
in a similar search return
appearing on page 1?"
This kind of goes into the
Google+ local search results.
So essentially these are done
separately from the normal web
search, and just
because one result
is showing in one
part of the search
results doesn't mean
it's automatically
shown somewhere else.
So I think that's
essentially more coincidental
that these different URLs
from the same business
are showing up on the
same search results page.
"User engagement as a ranking
factor is a rising topic.
How can it be a
reliable ranking factor
if there are so many different
types of search purposes?"
That's a good question.
And I don't think
we have said that we
use that as a ranking factor.
So from that point
of view, that's
something to ask those
who are kind of rooting
for this as a ranking factor.
We do take into
account how people
react to the search results
when be refine our algorithm.
So that's on a very
broad scale where
we say over all of the
billions of searches
that we see implementing
this algorithm
or showing it in search has
resulted in this kind of change
of user behavior.
But doing that on
a per URL basis
is really hard because,
like you mentioned,
there are things like
different intents, people
searching for the same thing,
but trying to find something
completely different-- people
who just want very brief news
blurb on a specific topic
or people who want to find
something that they can sit down
and read for a couple of hours.
So they have very
different intents.
And combining all that makes for
a really, really noisy signal.
And I don't think that would
really make sense there.
"What can we do to get our
Google+ pages to appear
in the local pack?"
I don't actually know about
the local search results.
So I can't really give
you that much information.
As far as I know, this is based
on the Google My Business page
that you have, and on that
page, you can also specify URLs.
So probably specifying
your URL there
will help to get
that shown there.
But I'd probably ask in the
Google My Business forums
to get advice from people who do
actually know what's happening.
"Is unique design a real factor
in ranking-- using already
built templates can
hurt search results?"
No, that's not something
I'd focus on there
with regards to ranking.
So just because it's a template
that other people are using
as well doesn't necessarily
make the site lower quality
or less relevant to users.
So that's not something
I'd say is a problem there.
I think you might see
some effects from users
if you're using something that's
so generic that it doesn't
actually look like it's
a legitimate website.
For example, if you're trying
to sell, I don't know, watches,
and you use a generic template
that 500 other sites are also
using, then it might be
that users come across
that site, and say, whoa,
this looks very vague.
I don't know if I would this
website with my credit card
information, for example.
And that might be
something that you'd
want to take a look at
from that point of view.
But just because it's using a
template that other people use
as well shouldn't really
affect its ranking
if it's a general website.
So, for example, lots of
blogs use the same templates
that are available on
Blogger or WordPress,
and just because they use
a default template doesn't
necessarily mean that
they are lower quality.
"Is there any SEO relevance
to using the HTML Value
tag to increase the
number of key words?"
This kind of implies
that there is
such a thing as optimal
keyword density,
and there isn't really
a thing like that.
So it's not that you have to
hide your keywords on a page
or push them using
whatever methods like this.
That's definitely not the case.
So I think we do pull out things
like the value or at least
the text from dropdowns
and take that into account.
The value item
that you have there
is more of an
internal thing that's
used to maybe generate a URL
that's navigated to depending
on what you select there.
But the text is essentially
the part that we look at there.
We've also seen people try
to use HTML comments to hide
keywords on the page.
And, again, that's something
that's not shown to the user.
That's something
that we don't even
take into account for indexing.
And your time is probably
much better spent
on actually creating something
really valuable for the user
than trying to sneak
your way into the search
results like that.
"When entering
site:www.domain.com in Google
Search Box, is there a random
list of that domain or the best
pages on top?"
We do show them
generally in some kind
of an order where we try
to bring the most important
or the top pages on top.
But it's not an order
that's prescribed
or we'd say, well,
it has to follow
this for a specific pattern.
And if your home page isn't
the first one on there,
that's not something where I'd
say it's a problem or anything.
So we generally try to
show them in an order
that we think makes
sense for someone who's
looking for this
website in general,
and that's often
something like a home
page or a higher-level
category page,
but that doesn't mean that it
has to be like that where it's
reflective of any
internal value that's
been shown through the
search results like that.
ROBB YOUNG: John, on
the search operators,
has the Link search
operator been retired?
JOHN MUELLER: No,
I don't think so.
But I have heard reports
that something weird
is happening there.
ROBB YOUNG: That's what I
read that you retired it.
And I was like, really?
Have you?
JOHN MUELLER: I don't
think we retired it.
I don't know.
I noticed for most sites, it
works, but for some sites,
it doesn't.
ROBB YOUNG: Yeah, it doesn't.
JOHN MUELLER: I
suspect it's more
of a technical issue on a site.
ROBB YOUNG: All right, OK.
JOHN MUELLER: "Is
syndication content a problem
causing punishment?"
Whoa, that sounds serious.
Not necessarily.
So we don't have a
duplicate content penalty
in that sense in that if
you're syndicating content
across a small number
of sites that this
would be any kind of a problem.
If your whole
website is based only
on syndicated
content, some content
that you're pulling
together from other sources,
then it probably doesn't
make too much sense for us
to spend too much time crawling
and indexing your content
because actually you're just
reflecting content that's
visible somewhere else already.
So if a whole
website is only based
on syndicated content,
that would be something
I tend to avoid.
But otherwise, this is
essentially just duplicate
content, and we try to handle
that on a technical level.
And we don't necessarily
penalize a site
for using syndicated
content like that.
"My site has been ranked at the
bottom of page 2 for some time
now, and nothing that I
can do makes it go up.
How can I determine
what the issue is?"
According to Search Console ,
it has 200,000 links to it from
2,500 domains.
So my first thought when seeing
a question like this is you're
focusing on links, and you're
compiling a list of the links
that you have
pointing at your site
and how many domains are that.
So it would kind
of worry me a bit
that you're focusing
so much on links
and maybe there are things with
regards to those links that
are causing more problems that
are actually helping your site.
So, specifically, if
you've been building links
in a way that would be seen
as against our webmaster
guidelines, that
might be something
that you'd want to
clean up and resolve.
If someone else has
been building links
for your website like that,
that's something you'd probably
want to clean up and
resolve, and in general,
just focusing on the number of
links shown in Search Console,
probably isn't the best metric
for how well a site should
be doing in search.
So instead of just
focusing on links,
I'd focus more on the
actual content and the value
that you're providing to the
visitors to your website.
"Disavow links and
[INAUDIBLE] can hurt already
ranked websites.
I know which is
good to my website,
but how can Google
judge my links?
Is there any criteria
that we can follow
to disavow only the bad links?"
So, in general, I'd use
the Disavow Links Tool
if you really have bad
or problematic links
to your website that either
you or maybe a previous SEO
or previous owner of
that site had built up,
then using a Disavow
Links Tool is a good way
to let us know that you don't
want to have these taken
into account.
And it could theoretically
cause problems
for an existing website if
you take all of the links
to your website and just disavow
them like that because then
essentially we'll look at
that and say, well, you
don't want to be associated
with any of the links
to your website.
So maybe that means we
have to kind of rethink
how we were ranking your website
based on these existing links.
So it's really something
that I would only
recommend the more advanced
users to do and really
only to use if you know
that there's really
a problem with regards
to your links there.
"I've been trying to
remove a site link
URL by demoting it in Search
Console with no success.
Why does Google not take
my input into account?"
So the motion in Search
Console is like the name says.
It's a demotion.
It's not that we're
suppressing it completely.
But rather that we'll
give it less weight
while we calculate the
site links of the URLs
that should be shown
as a site link.
And that's something that can
have a subtle effect sometimes.
Maybe it'll go from
being the first site
link to the last site
link that's shown.
Or maybe it will go
from being a site link
to not being shown at all.
So that's something where if
really don't want this URL
to be taken into
account for search,
then probably using a noindex
on it is a better approach.
Obviously, that's
a really big hammer
because that means
the URL itself won't
be shown in search at all.
But that's kind of the range
that we have available there.
The thing also to
keep in mind is
that a site link demotion
can take a bit of time
to be processed,
and sometimes that
can take several
weeks to actually run
through the systems on our side.
So if you've done that,
just recently, then
maybe you need to give
it a little bit more time
to be processed.
And finally, if it's something
that you really can't get out
of the site link, and you're
thinking this is really,
really a bad choice
for the site link,
and the page itself is actually
useful otherwise in search,
then you're welcome
to send that our way,
and we can discuss that
with the site links
to see why are we picking the
site link in a way that makes
absolutely no sense,
and what can we
do to improve our systems
based on this example
that you've sent us.
"Could we benefit
if our product pages
have more virtual descriptions
than other pages on the web
with the same products?
Can a lot of the
product descriptions
that are well-written
be considered better?"
Longer isn't necessarily better.
So it's really a case
of do you have something
that's useful for the user?
Is that relevant for the
people who are searching?
Then maybe we'll
try to show that.
And just artificially rewriting
content often kind of goes
into the area of spinning
the content where you're just
kind of making the
content look unique,
but actually you're not really
writing something unique up.
Then that often
leads to just lower
quality content on these pages.
So artificially
re-writing things
like swapping in synonyms and
trying to make it look unique
is probably more
counterproductive
than it actually
helps your website.
So instead, I'd really
focus on the unique value
that you could provide
through your website which
could be something
that's more than just
like a slightly
re-written description
but rather your expert opinion
on this product, for example,
or the experience that
you've built up over time
on this specific product
that you can show
to users that does provide more
value to the people on the web.
MALE SPEAKER 1: Hey, John,
regarding descriptions,
is it a good idea to
include descriptions
like small descriptions
on categories to increase
the relevance of a page
since, for example,
for categories of products,
usually the category page
just starts just as a cycle and
then starts listing products?
Would including maybe a
paragraph or something
like that-- a short description.
Would it improve the relevance
of the page for Google?
JOHN MUELLER: Sure.
Sure.
That can makes sense.
Sure.
MALE SPEAKER 1: I know
that Matt Cutts mentioned
in one of his previous
speeches that-- it's probably
not the case anymore.
For example, a USB drive can
be referred in many terms
based on the user's location
and things like that.
So maybe you have a USB
drives category page,
and maybe the
description could say
that you look at our
collection of thumb drives
and maybe they fit your use.
I don't know.
If Google is probably better
now with using synonyms
and with all the
new updates, it's
probably better identifying user
intent and things like that.
But I don't know.
JOHN MUELLER: Yeah.
So with synonyms
specifically, that's
something we're pretty good at.
Obviously, there
are some cases where
we don't pick that up properly.
But for the most
part, where we do see
problems is when
the text on the page
doesn't have anything
to do with that what
you're trying to target at all.
So I see that a lot
with small businesses
that maybe it's
a baker, and they
have some really nice pictures
of bakery items on their home
page.
But actually, they
don't actually
mention that they are a
baker or which city they
are a baker in on those pages.
So stating the
obvious definitely
makes sense on these pages,
but I wouldn't go so far as
to compile a list of
synonyms and put them
in there because it goes
towards that direction
of the typical SEO joke
like how many SEOs does
it take to change a light bulb?
You know?
Those things.
So I wouldn't just
artificially include
all of thee synonyms on
a page just to make sure
that you've included
all of the variations
and all of the
different texts there.
But putting a little bit
more text on a category page,
I see no problem
at all with that.
MALE SPEAKER 1: OK, and
since is we're on synonyms,
I wonder how does Google
understand characters-- words
with characters in
languages that have accents.
So for example,
in Romanian, there
are a few letters that don't
exist in the English alphabet,
and they have accents
and, of course,
in other languages as well.
But users usually
don't use these letters
when searching in Google.
So far, Google seems to
be good at identifying
that it's about the same thing.
But how exactly
does it identify?
Does it take it as a synonym?
Or what exactly is the process?
JOHN MUELLER: We usually
pick that up as a synonym.
So that's something where if we
see a lot of people searching
for these different
variations, and we see,
actually, they are trying to
search for the same thing,
then we'll try to take
that into account.
For some languages, it
works better than others.
I imagine most of the
European languages
are easier to pick up.
But for others,
it's a bit trickier.
And sometimes it gets
really complicated
when people search in
a transliterated way,
for example, in Hindi,
that's something
that I've seen where the
content is actually in Hindi
and uses the appropriate
scripts for that,
but people search using the
Latin characters instead.
So they type what it would
sound like if someone were
to say with English characters.
And that makes it
really for us to connect
what they're searching for
with what's actually on the web
because it's not just that
the words are kind of similar.
Essentially, they're
searching for something
completely different, but
expecting the same thing
to show up.
MALE SPEAKER 1: Yeah, excellent.
Thanks.
JOHN MUELLER: All right,
we have a few minutes left,
maybe I'll just open it up
toward question from you all.
What's on your mind?
MALE SPEAKER 2: Hi, John.
JOHN MUELLER: Hi.
MALE SPEAKER 2: I just
had a quick question
regarding the comment made
on the schema markups.
JOHN MUELLER: OK.
MALE SPEAKER 2: JSON-LD being
the most preferred format
or being the growth in the
acceptance of JSON-LD format,
it's becoming more
easy for people
to just mark up
content which is not
even present on the web page.
And I'm seeing specifically
on events, for example,
I've seen websites where
we have multiple events
on a single location.
They will repeat
the event location,
and they just put it in
these script tags in JSON-LD.
The schema is being
accepted by-- it's
valid by these structured
data tool as well,
and it also accepts--
it's actually
valid via the policy as well.
So how does Google
actually take this
into, and what's your
thought about people using
JSON-LD schemas to actually mark
up content which is not even
on the web page?
And by the way, I also sent
you an example as well today.
JOHN MUELLER: OK, so from a
policy point of view, we do
want to have the content
visible on the pages
when it's marked up.
So that's obviously easier
with the existing schema
markup, the macro formats,
those kind of things on a page
and harder to double
check with JSON-LD
because JSON-LD
markup is essentially
JavaScript that's completely
separate from the HTML
on the page.
So that's obviously
a bit trickier there,
and I think that's part of
the reason why we don't accept
JSON-LD markup [INAUDIBLE].
MALE SPEAKER 2:
OK, and by the way,
it will be great if you
can look into the example
that I've sent to you earlier.
JOHN MUELLER: Sure.
I'll look into that.
MALE SPEAKER 2: All
right, thank you so much.
MALE SPEAKER 1: John, I
have one more question.
This is actually a
client-specific one.
There seems to be a
WordPress plug-in that
helps users log certain
data into Google Analytics
by adding a few
parameters to the URL.
This is one example of such URL.
The problem that I see is that
for robots, including Google.
So Fetch as Google shows this.
It shows us being redirected
to the non-parameter URL.
But for users, it's accessible.
So it shows a 200 result code.
And is this a problem?
I assume that a
rel canonical tag
would be better fitted here.
So I'm not sure why
the plug-in does this.
Why does it redirect for
robots but not for users?
JOHN MUELLER: I think a rel
canonical would probably
make it easier here
because that would also
let it be cached properly.
But I don't see any big problem
with redirecting it like this.
I suspect there are
probably other ways
to track this information in
Analytics that wouldn't require
URL changes, and
maybe that would
make things a little bit easier
because you don't have to put
all this logic onto the server.
You can just keep the
HTML pages as they
are and do the tracking
with JavaScript
without modifying the URL.
MALE SPEAKER 1: Right.
But there's no problem
regarding the fact
that we're doing something
for Google that's
not being done for users?
JOHN MUELLER: From purely
a theoretical point of view
that would be cloaking.
But from a practical
point of view,
I don't see a big problem with
doing something like this.
I think the issues
are more subtle.
And any time you're doing
this kind of a cloaking,
there's always a danger of
having something go wrong
that you don't actually see.
So if something is breaking
with a redirect, for example,
and it's only being done for
Googlebot, then diagnosing that
is really, really
tricky because you
have no idea what's actually
happening behind the scenes.
So as much as possible,
I would really
recommend not doing cloaking.
But in a case like this
where you're essentially
just cleaning up URLs, I don't
find it that problematic.
MALE SPEAKER 1: OK, yeah,
thanks, good to know.
ROBB YOUNG: John, I have
an Analytics question
that you may not
know the answer to.
Why when you're
within Analytics,
why can't you update on
the same day notations?
So if I do some work
on the site today,
and I want to notate the disavow
file or I've done this , that,
or the other, I have
to come back tomorrow.
It won't let you say--
JOHN MUELLER: I have no idea.
That's a good point.
I don't know.
ROBB YOUNG: There's no option
to choose today's date ever
in notations.
It seems a little bit strange.
JOHN MUELLER: Yeah, I mean,
you know what happened today,
and you might
forget it tomorrow.
So the Google Analytics
Help Forum just
moved to a new
platform, and maybe this
is your chance to get a question
in early while they're still
paying attention there.
ROBB YOUNG: Are you trying
to get rid of me, then?
JOHN MUELLER: That might
be an option there.
But I don't know how Google
Analytics makes decisions.
And maybe it's something
they didn't even
think about purposely, and
giving them that feedback
helps them to fix that.
ROBB YOUNG: OK.
Because it just
doesn't make sense
that it would be a deliberate
policy as far as I'm aware.
JOHN MUELLER: I don't know.
ROBB YOUNG: OK, then while I'm
here, I have another question.
In the UK, we had a second
site that we were using
with a white label partner.
So you know the sort
things that we do.
It was only extreme
stuff-- bungee
jumping, skydiving, all
of the more extreme stuff.
And it was on a domain
that was essentially
via license agreement owned
by them, but we controlled.
So that license agreement
is coming to an end.
So for the final three
or four months of it,
we're going throw all of
it over to our main site
so we have some kind
of transition plan
so customers don't
suddenly one day disappear.
So we're going to throw one.
We're going to update
or disavow everything.
How long after that domain
essentially goes back to them
will you then consider
that a new domain,
and if they then put
something else on it,
as soon as they put something
else on it, will you say,
OK, well these throw
ones are not there,
obviously-- we'll lose
any of that benefit.
Or after say three or four
months will all of the benefit
be hard-coded into
the other domain
and you'll start
afresh on the new?
Or are you just going
to say it depends?
JOHN MUELLER: Yes.
Most of that we'll probably
be able to forward right away.
And what we generally recommend
with site moves like that
is to also update the
links to the old site
so people are linking
to the old site
as much as possible
kind of encourages them
to link to the new version.
ROBB YOUNG: Yeah, we're
doing that where we can.
JOHN MUELLER: Obviously, you
can't do that for everything.
In general, if
there are things--
if there are URLs that
return a 404 afterwards,
then they kind of have
to leave with that.
And we can still have
that forwarded PageRank--
all of that information
on those new URLs.
So that's kind of
a good thing there.
It becomes I guess
a little bit tricky
if they reuse the old URLs for
something completely different.
ROBB YOUNG: I can't say that
I'm using the exact same URLs
for anything.
It just wouldn't--
JOHN MUELLER: Yeah, I suspect
that probably would make sense.
ROBB YOUNG: It's not
going to be until March.
JOHN MUELLER: It's always a
bit of a tricky situation.
And at least you're
looking at ahead of time
and setting those redirects
up early is definitely
the right thing to do there.
Doing that after this
transition happens
is something that
is a lot harder.
So if you lose your
domain tomorrow
and you forget to
set up redirects,
then that's kind of lost.
But if you've had
a chance to set up
these redirects for
a while, then you're
passing pretty much as much
as you can over to a new site,
and that's a good thing.
ROBB YOUNG: So it must be
at some point in the future
if they-- we're not
doing it until March.
But we're already 301ing.
So we'll have a good four months
or so of exact URL TRL 301ing.
But if they didn't use
that domain for, let's say,
two years, I assume as soon
as they started something new,
it would have no
effect on us at all.
But if they did it
after a week, it would.
But is the period in
between always a bit
of a it depends scenario?
JOHN MUELLER: I wouldn't
really worry about that.
I mean, on the one hand,
you can't control that.
ROBB YOUNG: No.
JOHN MUELLER: So those
redirects are there,
and I suspect some
amount of signals
will still be associated
with the old domain
just because for
historical reasons,
things have been collected
there for a while.
But that's not
something that would
have a negative effect on you.
Let's put it that way.
I think to some
extent, there's always
a balance on our side between
recognizing that a domain is
used for something different
and recognizing that it's still
the same and trying to keep
some of that value there
that's still the same.
And if we recognize that it's
something different, really
treating it as a new domain.
But that's not always
something that can split 100%.
ROBB YOUNG: I know a while
ago people were asking
for a reset button, basically.
Has that ever been
discussed again?
Or is it the same
as the real world
where if you buy
offline real estate,
you have to look at
the inherent problems
with what you're buying?
JOHN MUELLER: Yeah, I
think to a big extent,
we've gotten a lot better at
understanding when something is
new to ignore the old signals.
But sometimes things
still stick around.
So I don't know--
we haven't talked
about a reset button in a while
but only because we probably
haven't had any good examples to
make a case for a reset button
recently.
So any of you out
there are seeing cases
where having a reset
button on a domain
would have made a really big
difference on how you actually
use a domain, use a
website, and those
would be interesting
cases to have
so that we could take them
up to the team and see.
It makes sense because of these
specific examples or these
are just edge cases that
wouldn't have helped anyway.
But I think examples
makes it a lot easier.
MALE SPEAKER 1: John, I'll
give you an example right now.
This is actually
one of my clients
who just acquired a new domain.
And I talked with you last time
regarding the manual penalty
disappearing from Webmaster
Tools regarding this domain.
We actually and disavowed
I think it was 98% or 99%
of the links.
So, yeah, definitely a reset
button with the-- yeah,
when we bought it,
she had no idea
that it came with this whole
spammy links and everything.
JOHN MUELLER: OK, good.
Good.
See, good examples.
I copied that out.
All right, with that, we're
pretty much over time already.
Thank you all for
all of you questions.
Thank you all for joining
in for the discussions.
I hope this was a
useful session for you,
and maybe I'll see you again
on one of the future Hangouts.
Have a great weekend, everyone.
Goodbye.
MALE SPEAKER 1: You too, John.
MALE SPEAKER: 3:
Thank you, John.
MALE SPEAKER 2: Thank you, John.
Take care.
Bye. bye.