English Google Webmaster Central office-hours hangout on best practices
Articles,  Blog

English Google Webmaster Central office-hours hangout on best practices

JOHN MUELLER: Welcome everyone
to today’s Google Webmaster Central office hours Hangouts. My name is John Mueller. I am a webmaster trends analysts
here at Google Switzerland, and part of what I do is I
talk to webmasters like you all to make sure that
you have information you need to make
fantastic websites and so that our engineers
have information from you guys to see what we need to do to
improve our search results. So one thing we
talked about, I think in one of the
previous Hangouts was to do some more general
information, some themes maybe. I compiled a short list of
best practices and myths that I’d love to share with
you guys just start off with, and after that, we’ll
start off with the Q and A. There are lots of questions
submitted already, and feel free to submit
more as we go along. All right. Let’s see if I can switch
over to the presentation here. So I guess we can start
off with something basic. Essentially something
you would assume one of the things we love to
see is that we can actually look at the content,
for example. So we recommend using fast and
reusable technologies the way to kind of present
your content in ways that works across all
different types of devices. So Googlebot can
render pages now so JavaScript isn’t something
you need to avoid completely, but I’d still make sure that
it can actually view it, so check on a smartphone,
check with the Fetch as Googlebot feature
in Webmaster Tools, check with the
webpagetest.org tool to see that it’s actually
loading in a reasonable time. Responsive Web
Design is a great way to create one
website that you can reuse across a
number of devices. So if you don’t have anything
specific for mobile yet, that might be
something to look into. I’d recommend avoiding
Flash and other rich media for textual content. So if there’s text on
your page and you’d like to have it
indexed directly, make sure it’s
actually on the page, make sure it’s loaded
as HTML somehow so that we can pick it up and
index it as good as we can. Someone has a bit of
noise in the background. Let me just mute you. Feel free to unmute if
you have any questions. If videos are critical, make
sure that they work everywhere. Certain types of videos
don’t work on mobile phones, for example. So there’s a special HTML5 tag
you can use to kind of provide alternate medias
for those devices, or if you use a common video
system like YouTube or Vimeo, then those almost
always work as well. And regarding your
website architecture, most CMS systems work
out of box nowadays. You don’t need to
tweak anything. You don’t need to
re change everything to use search engine-friendly
URLs or anything like that. Most of them pretty
much just work. For indexing, we recommend using
sitemaps and RSS or Atom feeds. Sitemaps let us know
about all of your URLs, so these are essentially files
where you this everything that you have on your website
and you let us know about that. We can use that
to recognize URLs that we might have
missed along the way. RSS and Atom feeds
are a great way to let us know about
new or an updated URL. So if you push both of
these at the same time, then usually what will happen
is we’ll crawl the sitemap files regularly, but we’ll crawl
their feed a lot more frequently because usually
it’s a smaller file. It’s easier for your
server to server that. We can use something
like pubsubhubbub to fetch it
essentially immediately once you publish something. An important aspect
there is to make sure you use the right dates
in both of these files, so don’t just use a
current server date, make sure this is
actually the date that matches your primary content. So if you have, for
example, a sidebar that changes randomly
according to daily news, that’s not something you’d use is
a change for these pages. It should really be
the primary content. You can include
comments if you want, but essentially it should be
the primary content, the data [INAUDIBLE]. And the indexed URL
account confirms indexing of exactly the
URLs that you submitted. If the index count
doesn’t match what you think you have indexed, for
example, if you check an index status, then usually that’s
a sign that the URLs you’re submitting there are slightly
different than the ones we find during crawling. So that’s something where I
really double check the exact URLs that are submitted there,
I’m happy also help with that if you have a thread in a forum
or on Google+ where you have an example where it looks like
the index count is lower than it should be, but in almost
all cases that I’ve looked at so far, essentially the URLs
have to match exactly what was actually found during crawling. We recommend using the rel
canonical where you can. This is a great way to let us
know about the preferred URL that you’d like to have indexed. If you use tracking
parameters like analytics, then that’s something
that sometimes is shown. Sometimes people will
link to those URLs with tracking parameters,
and the rel canonical lets us know that
this is actually the URL that you
want to have indexed. It can be the right
upper lowercase. It could be on the right host
name with the right protocol. That’s essentially
the one you want. It’s fine to have that
on the page itself. Make sure you set up correctly
so that they don’t all point at the home page. That’s a common mistake
we see, and it’s important that the pages be
equivalent, so don’t do this across different types of pages. So if you have a blue
shoe and a red shoe and different pages
for that, those pages aren’t really equivalent, so
I’d recommend not setting a rel canonical across those pages. Sorry. Was there a question? AUDIENCE: Oh, yes. JOHN MUELLER: OK. AUDIENCE: I’d like to ask
you about canonical setting. My question is right or wrong. So can I send a group job? JOHN MUELLER: Sure. AUDIENCE: [INAUDIBLE]? JOHN MUELLER: Oh, wow. OK. Long question. Best practice for
canonical setting, small ecommerce site with not
so many items with pagination, faceted navigation. I’d have to take a look
at exactly what you’re looking at there,
but I’d recommend taking a look at our
blog posts we did, a blog post on faceted
navigation earlier this year. AUDIENCE: Yeah. I’ve already read this. But in my example,
the faceted stops are not so important to
the main canonical page, so does it matter if it is
canonical or in [INAUDIBLE]? JOHN MUELLER: Yeah. It should be essentially
equivalent content, so one thing the
engineering sometimes do is they take a look at the
text that actually matches between these pages and
if the text matches, then that’s a good sign. If the order is
slightly different, then that’s less of a
problem, but the text itself should be matching. So if you have different
items in a different order, that’s fine. If you have completely
different items, then that’s something
where I’d say don’t use a rel canonical there. AUDIENCE: I see. Thanks. JOHN MUELLER: All right. Let’s look at the next one here. This is one we see
almost in every Hangout, a duplicate content question. So there’s a myth that
duplicate content will penalize your site, and that’s
definitely not the case. I certainly wouldn’t worry
about duplicate content within your website. We’re pretty good at recognizing
these kind of duplicates and ignoring them. It still makes sense to
clean them up for crawling, and if you’re reusing
content from other websites, if that’s the kind of
duplicate content you have, then just make sure you’re
being a reasonable with that. Make sure you’re using that
with reasonable amounts and not just taking all of your
content from other people’s websites. With regards to where duplicate
content does affect your site, I made this nice
and simple diagram, but maybe not so simple. Essentially this is our somewhat
simplified web search pipeline. We start off with
a bunch of URLs that we know about
from your website, we set them to a
scheduler which makes sure that we don’t crash your
server by crawling everything all the time, and Googlebot
goes off and crawls them from your website and brings
the results back and says, oh, I found a bunch of new URLs. These are here. It also takes the content
that it found on those pages and passes them on to indexing. And essentially what
happens is, if you have a lot of duplicate content
with different URL parameters, for example, we’ll collect a
ton of URLs for your website that we’ll know about with all
these different variations. We try to schedule them
regularly so that we can like double check to make
sure that we’re not missing anything, and we’ll essentially
be kind of stuck in this cycle here crawling all
of these duplicates instead of being able to
focus on your main content. So if you have things that
change quickly on your website, we might be stuck
here kind of crawling all over your duplicates
in the meantime, which makes it a little
bit slower for us to pick up your actual content. So that’s one aspect
where duplicate content can make a difference. This is especially true if
you have a lot of duplication. If you just have like dub,
dub, dub, non dub, dub, dub, those duplicates then
that’s less of a problem. That’s essentially
everything twice, but it’s not that
much of a problem if you have everything 10
times or 20 times or 100 times, then that’s going to make
a big difference in how you can crawl your website. Then once we’ve
picked up the content, we send it off to indexing. Indexing tries to recognize
duplicates as well and will reject those kind
of duplicates and say, hey, I already know about this URL. I already know about this
content under a different URL. I don’t really need to
keep an extra copy of this. So this is another
place where we’ll run through your duplicates. We’ll pass them onto the
system here, and at this point, the system will say,
well, I don’t actually need this content. We didn’t need to waste
our time essentially trying to pick it up. Sometimes what also happens is
that pages aren’t completely duplicate, and in
cases like that, for example, you
have one article that you post on your
US English website and you post the same
article on your UK English website, which makes sense. It’s your company website. The same article might
be relevant for both of your audiences,
that’s essentially fine. And in those cases, we
do actually index some, but we try to filter them out
during the search results. So that looks a little bit like
this with a very simplified figure here where essentially we
have these three pages that we were crawling and indexing
and the green part here is essentially
the content that’s the same across these pages. So this could be, for
example, the same article that you have on your UK
English page, your US English page, and Australia
English page, for example. So the article is the same. The headings are different. There’s some other content
on these pages maybe. And what happens in
these cases we’ll index all of these three pages
and in the search results, if someone searches for
part the generic content, we’ll try to match one of these
URLs depending on whichever one we think is the most
relevant that might be, for example, the location–
these are different country versions– and we’ll
just show that one. So one of these
will be shown here. That’s one we’ll show. We’ll show other
search results as well, but essentially, we’re
just picking one of these to show in the search results. And what happens then
if someone searches for part of the generic
content that also something specific to the page
itself, then, of course, we’ll show that specific
version in the search results. So the generic text,
of course, that people were searching for as
well something unique. So if this article is an article
about a certain type of shoe, for example, if someone searches
for that shoe type directly, we’ll show one of
these pages depending on whatever our algorithms
think makes sense. If someone is searching
for this type of shoe and mentions that they
want to buy it in the UK, then we’ll probably pick
the version that actually has UK address on it and show
that one in the search results. So this isn’t something where
we’re penalizing your website, but essentially we’re
taking these three pages and trying to pick the best
one to show the search results and the others will
be filtered out because it doesn’t
make sense to show the same content to the
user multiple times. So I hope that kind of helps
with the duplicate content question. AUDIENCE: And John,
and to have any sort of play in and this
whole thing, you know, when I looked at quality
across all the pages, would you in an ideal
world be better off doing something different? I mean, in our
circumstances, obviously, we have locations in close
proximity to each other. Or perhaps if you’re looking
for within a certain distance office space that has
one desk available, you’re going to start to get
these groupings of locations where there is duplicate
content that quite suitably across the board. And I wonder
whether people still are talking about this
in multiple forums, is Panda still going to have
some effect on your site, in other words, on the quality. JOHN MUELLER: So
primarily this type of filtering that we do
for duplicate content is a technical thing
that we do just to find the right match
there, and it’s not something that we primarily use
as a quality factor. There are lots of
really good reasons why you’d duplicate some of your
content across different sites. There are technical reasons,
there are marketing reasons, there might be legal reasons
why you would want to do that. That’s essentially
not something that we would say this technical
thing that you’re doing is a sign of
lower quality content. On the other hand,
this is something that users might notice
if you do it excessively, if you create doorway pages, if
you kind of duplicate content from other people’s websites
and act like it’s your content. We see that a lot with
Wikipedia content, for example. And those are the
type of things where the duplicate content itself
isn’t really the problem, but essentially the
problem is you’re not providing any unique value
of your own on these pages. You’re not providing
a reason for us to actually index and to build
these pages in the search results. In this case, where you
have multiple versions for different
countries, for example, there’s a good reason to have
all of these different pages. There’s a good reason
to have them indexed. There’s a good reason to
have them shown in search sometimes because it is
very relevant for the type of queries here. But if you kind of
take this excessively and you create pages for every
city and actually the content itself isn’t really relevant
for every city, then that’s something where
our algorithms would start seeing that as a sign of lower
quality content, maybe even WebSpan. So that’s a situation you’d
want to watch out for. Technically, having content
duplicated by itself is not a reason for us to say
this is lower quality content. There can always be
really good reasons why you’d want to do that. AUDIENCE: Sure. Thanks, John. Is there a sort of a
set amount of words you use as a guide
to what you would consider to be
duplicate content. I mean, would anything let’s
say over five words that are similar be considered to be
duplicate content or would you simply take it right
down to a single stroke to letter words,
sentences, or do you take it in batches of sort
of 10 or 20 words in a row? Does that make
sense, that question? JOHN MUELLER: Yeah. So when it comes to technically
recognizing duplicate content like this, we use a
variety of ways to do that, and sometimes we’ll
even look at things like saying, well, this
looks very similar. It’s not exactly duplicate, but
it’s very similar, therefore, we’ll treat it as
being the same. So that’s something
where we wouldn’t say you need to focus on
a certain number of words or where you’d need to like
alternate every other sentence or something like that. I don’t think this
type of filtering is something you’d need
to kind of work around. This is essentially
the normal part of web search, a
normal thing that you don’t need to kind of like
eliminate from your website. AUDIENCE: Yeah. OK. Excellent. Thanks, John. JOHN MUELLER: Sure. AUDIENCE: Just a
question on when you mentioned duplicate
content from other websites. Would you recommend
putting a kind of locking citationing
back to that website just to kind of ensure
that you kind of want to show that you’re not trying
to steal that content, you’re actually just referencing it? JOHN MUELLER: You can do that. It’s not something that
our algorithms specifically look for, but I think that’s
always a good practice. It helps people to understand
your content a little bit better, but it’s not
something where we technically watch out for. And similarly using
something like I think the HTML5 site
tag is something you can do if you
want to do that. It’s not something
that we would say, oh, this looks like a
quote from another website, therefore, we shouldn’t
count it for this website. Sometimes discussions
around a quote are just as valuable
as a quote itself. So it’s something I
think is a good practice, but it’s not something that our
algorithms would specifically look for. AUDIENCE: OK. No, that’s fine. JOHN MUELLER: All right. Let’s look at a
few more of these. Robots.txt, we have a lot
around robots.txt nowadays. So it used to be
that people would say they used robots.txt to
eliminate duplicate content. We’d see a lot of things
like this on the side where the robots.txt
file disallows everything with parameters in it. And that’s essentially
causing more problems than it solves, because if we
can’t crawl those pages, if we can’t recognize that
they’re duplicate, and we can’t filter
them out afterwards. Well, essentially you have
your original content, all of these duplicates with
the parameters, which will index just with the
URL alone, and we won’t know that they
actually belong together. So if someone were to
link to one of these URLs with a parameter, we wouldn’t
know that we can actually forward this link onto
your main content. We’d say, oh well,
someone is linking to this URL that
happens to be roboted. It must be relevant,
so maybe we’ll show it in the search
results as well. So robots.txt is
a really bad way of dealing with
duplicate content. Best is, of course, to
have a clean URL structure from the start. That’s not always
possible if you’re working with an existing site. Using 301 redirects is a
great way to clean that up. Using rel canonical
is very useful. The parameter handling
tool also helps you in situations
where you might not be able to use redirects
or rel canonical. AUDIENCE: John, just
going back to that. You’re saying just let
Google crawl everything, because we do have some of that
stuff blocked in robots where the dropdowns for search
and dropdowns for filtering are all being or
were being indexed, and so we’d have
thousands of pages. And previously that
was a general feeling that that was duplicate content,
so it doesn’t look good. Particularly if you go into
the web master talks forums and ask that question, you
get jumped on straight away. The general feeling
in those forums is, block it, get
rid of it, don’t have it expire if
it’s duplicate. JOHN MUELLER: Yeah. I think it’s always
a good practice to clean up duplicate
content if you recognize it. I think that’s
something I’d recommend doing if you can do that. AUDIENCE: No, the
duplicate I’m talking about is category pages where
someone has, like on our side, for example, which
I know you know, someone sorts everything in
California by price, but then by location, and then by
something, activity type. You’ve got three
different filters there, which gives half of [INAUDIBLE]
depending on how you do it. You can’t clean that up. You have to let people, the
users, use those dropdowns, because they’re
useful for the user. So you either let Google
crawl those dropdowns and crawl a half a
million URLs and decide, or just you say
actually it’s one, or do you call everything
in canonical back to the main category? JOHN MUELLER: It depends. So again, we have
a blog post I think on faceted navigation
from a while back. I’d double check that. I’m really exactly– AUDIENCE: The one
with the gummy candy that I think was
referenced there. JOHN MUELLER: No, I
think it’s a newer one from this year or
late last year maybe, but it kind of goes into the
faceted navigation aspect there where it’s
tricky sometimes because we have all these
different categories and filters and options
and ways to kind of sort this content out. But I touch upon that I
think a little bit back here, so we can look at that
a bit later as well. But those are always
tricky to handle, the faceted navigation
and how much of that should you allow it to
crawl, how much of that should be no index
or rel canonical. That’s always hard. AUDIENCE: Is there a [INAUDIBLE]
or don’t we just stick it in [INAUDIBLE]? JOHN MUELLER: it really
depends on the website. Some content it makes
sense to index separately because it provides
value when you index it like that or
people are searching for events in California then
having a California landing page for that. AUDIENCE: Right. Which we know we do have. JOHN MUELLER: Yeah. That makes sense. AUDIENCE: But some
people in California are just actually looking by
price and they’re not that. JOHN MUELLER: Yeah. But I think that’s the
situation where people would go to your website
and they kind of use it first where nobody would
be going to search and say, I’d like to have all
events in California listed by price in search. AUDIENCE: No. I mean, it does
happen a little bit from everything in California
with gifts under $100. People would do search for that
stuff in particular, these days search for a budget because they
assume Google knows everything. So it will do it. JOHN MUELLER: Yeah. I mean, that’s
something where you have to make a judgment call
yourself, like how relevant are these specific pages
or how random are they. Are they’re just like people
entering search queries and we’re indexing every word
that people are searching for, and that’s probably
not that useful, but that really depends
a lot on your website and how you have that set up. AUDIENCE: But in
general, best practice is to canonical all
of the search results into the main category. JOHN MUELLER: It depends. I think this is a good
topic for another Hangout. Yeah. I can see that there
are lots of aspects here that we could cover. So let me just go
through these and– AUDIENCE: One little bit of
advice for everybody regarding that robot subtext
though is that I actually blocked a hell of a lot of
pages on my site in the effort to stop Googlebot from
crawling all of those pages and wasting its time doing it. What I’ve done by homing
in on what Googlebot needs to look at, it’s
actually now indexing calling my pages faster than
ever before because it’s not wasting time crawling
pages it doesn’t need to, and we’ve seen an incredible
change in robust calls as a result of that. So in my experience, if
you know what you’re doing, block whatever
you can and you’re going to allow
Googlebot to really do a good job on your site. That’s my opinion. JOHN MUELLER: I’d have to take
a look at how you implemented that before saying, yes, but the
kind of the caveat if you know what they’re doing
applies to a lot of things especially around websites. AUDIENCE: Yeah. JOHN MUELLER: OK. So let’s go through
some more of these. With regard to
robots.txt, we especially want to be able to crawl CSS
JavaScript pages nowadays because we want to know
what they just look like, which is especially
important when you have a mobile-friendly page. Because if we can’t crawl
your CSS and JavaScripts, we can’t recognize
that this page is a really great
mobile page, then we wouldn’t be able to be treated
as such and search them. Another aspect is error pages
where if you have a URL, for example, where all of
your 404 pages redirect to, if we can’t crawl that
URL, we can’t recognize that these URLs
are errors, and we will try to recrawl those
URLs more often than we might otherwise. So being able to see
that a URL as an error is really useful for us
and not something that causes problems for you. Mobile pages, we sometimes
see that the end.domain, for example, is
blocked by robots.txt. That’s a problem. International and translations,
we still occasionally see that that people say,
well, this is my main page, and this is my page for Germany,
but the German version is just a translation,
therefore I’ll kind of block Google from
kind of crawling that. That might be a
problem because then we can’t see the German version. With regards to robots.txt
threads practices, if your content shouldn’t
be seen by Google at all, then by all means mark it. If there is, for example,
legal reasons why you don’t want that
indexed, that’s something you might want to
just block it by robots.txt. If you have
resource-expensive content, for example,
complicated searches, if you have tools that
take a long time to run, then those are type of
things you might also want to block by robots.txt
so that Googlebot doesn’t go through your site
and say, oh well, let me try possible words
that I found on the internet and insert them into
your search page because I might be able to
find something new there. That might cause a lot
of kind of CPU usage on your website
slowing things down. So that’s the type of
thing where you’d probably want to block that
with robots.txt. Robots.txt doesn’t
prevent indexing so if you don’t
want it indexed then I’d recommend using no index
or server-side authentication. For example, if
there is something confidential on your
website, the robust text file isn’t going to prevent it from
ever showing up in search. You really need to block
that on the server itself using something
like a password so that people, when
they find the URL can’t actually
access the content. As I mentioned, don’t
block JavaScript, CSS, other embedded resources. If you use AJAX, don’t
block those replies from being crawled so
that we can actually pick up all of this content
and use it for indexing. Another myth we always
hear is that my website worked for the last five years. Why is it suddenly not
showing up in search anymore, and where webmasters
essentially say, well, it’s been working
so far, so I’m not going to change anything. And it’s important to keep in
mind that the web constantly changes. Just because it
worked earlier doesn’t mean it will continue working. Google also constantly
works on its algorithms, and the user needs to
change over time as well. So I definitely recommend
staying on top of things and making sure that
you’re not like just like sticking to
your old version out of unnecessary reason. So make sure that you’re
kind of going with the times and really offering something
that users want now in a way that they can use now,
which sometimes means kind of enabling
mobile-friendly websites, for example, to let all the new
users who are using smartphones as a primary device
also get your content. Some other myths that
we see regularly, shared IP addresses,
that’s fine. We know that there’s a limited
number of IP addresses. I wouldn’t worry about
it if someone else is using the same IP address. That’s something that
happens on a lot of hosters. Too many 404 pages, that’s
also fine unless, of course, these pages are ones that
you want to have indexed. So that’s something you
want to watch out for, but if we’re crawling
pages that shouldn’t exist, and we see a 404
and we report that in Webmaster Tools, that’s fine. That’s the way it should be. Affiliate sites are also
OK from our point of view, but you should really
have your own content. So don’t be an
affiliate site and just copy all of the affiliate
content as everyone else has. Really make sure
that you’re providing something useful of your own. The value should be with your
content, not with the link that you’re providing. Disavow files, we sometimes
see webmasters say, I don’t want to submit
one because then Google would think I did
something wrong, and that’s totally wrong. You shouldn’t hold off
on using a disavow file. If you find something
that is problematic that’s linking to your
website that you don’t want to be associated with, go
ahead and disavow that. For us, it’s primarily
a technical tool. it takes these links
out of our system. It treats them similarity
to no follow links and then you don’t have to
worry about those links anymore. So even if those
links are things that you didn’t have
anything to do with, maybe a previous SEO
is set up and you don’t want to kind of admit that
maybe they did something wrong, use of this and make sure
that they’re out of the system so that you don’t have
to worry about it. The order of text in an
HTML file isn’t important. You can put your main content
on the top or the bottom. We can get pretty large
HTML files in the meantime and still recognize
the content there, so that’s not
something where you have to kind of micro
optimize at that level. Keyword density is something
we always hear regularly, just write naturally instead. AUDIENCE: So in order
to manage HTML5 file, you’re saying text though. That’s only from a
coding point of view. You’re not referencing it
from a visual point of view, so the content text
wise I think you’ve discussed before is essentially
probably better being higher up rather than from
a visual aspect? JOHN MUELLER: I’d
definitely make sure that at least part of
your primary content is visible when the user
first lands on your page so that when they click
on the search result, they can recognize, oh, this
is what I was looking for. And from that point
of view, that’s something that’s
generally higher up. It doesn’t have to be the
first thing on the page. But essentially what
I’m mentioned here is sometimes people
think that if they move the div with
the primary content to the top of their page
and then use CSS to show it at the right position, then
that would be better than just having a div wherever
it is in the HTML, and that’s not something
you need to worry about. AUDIENCE: Yeah. I mean, we’re actually
internally discussing right now we’re about to put nice,
large images at the very top of our location
pages, and this is one of the questions I actually
wanted to put to you today. They’re going to be somewhere
in the region of sort of an 800 byte, 400 view. So the first thing really
you’re going to see is this beautiful
image of a location that you were
actually looking for and our customers identify
better with an image than they do with a lot of text
but more on the term they’re just interested in pricing. So are we going to be
affected by maybe Hummingbird or something like
that by doing this? JOHN MUELLER: No. You should be fine. AUDIENCE: [INAUDIBLE]? JOHN MUELLER: Yeah. I mean, this is something
where if this image is your primary content for
that page, that’s fine. I wouldn’t do it in
a way that the logo is the primary
image on this page. So if your company’s logo
is taking up the whole page and you have some
random information from a sidebar showing
up on the first page, then that’s probably
not that great, but if the image of this
specific location, the image matching this specific
content is primarily visible, that’s fine. AUDIENCE: Yeah. So Googlebot is pretty
much or some of your crawls are able to kind of distinguish
the difference between what is a consistent
top image as a logo and what is a unique image
to that specific page. JOHN MUELLER: Yeah. AUDIENCE: OK. Wonderful Thanks. JOHN MUELLER: Another
one I didn’t put on here, but we get a lot of questions
about is the keywords meta tag. It’s one of our most
popular blog posts even now, and essentially we don’t
use the keyword meta tag at all for ranking. So I imagine some of
you well know that. If you’re new to
this area, then that might be something
where you think, oh, this a great way to
put keywords for ranking, but we don’t use that at all. Let’s see. This is the last slide so– AUDIENCE: John? JOHN MUELLER: Yes? AUDIENCE: Which
other tags would you say are almost
completely irrelevant? JOHN MUELLER: There are
a lot of tags out there. AUDIENCE: Yes, a lot of them
like the ones that say follow and abating and stuff
like that, things that– JOHN MUELLER: Those are the
ones that we essentially ignore. We ignore, what is it,
the revisit after tag. That’s something that’s
very commonly used. That’s something we
don’t use at all. I’d have to think which
ones we don’t use. That’s always harder than
which ones we do use. But essentially we try to
look at the primary content on the pages instead and not
focus so much on the meta tags there. AUDIENCE: In fact, it’s
important, but in many cases, it doesn’t get used. It’s not relevant
enough to query. Is that right? JOHN MUELLER: Which
one did you mean? AUDIENCE: This description. JOHN MUELLER: Description. Yeah, we use that for the
snippet in the search results, but we don’t use
that for ranking. So if you have a specific
snippet you want to have shown, that’s something you can
use, but that’s not something where you need to
stuff any keywords. Essentially make
it so that users will recognize what
your content is about. And maybe it includes
a keyword say we’re searching
for so that we know this is relevant
for their query. AUDIENCE: A lot of people
have used different tools that will put matching keywords
and all their tags and URL, and surprisingly this
is still very common. There’s the popular SEO
tool used in WordPress, and I suggest
people not use those because it makes everything
very much the same. JOHN MUELLER: Yeah. That’s something
where I’d primarily focus on what works
for your users. Sometimes it’s easy for
users to work with wordy URLs and with like
identifiers in the URL, but essentially that’s something
that we wouldn’t focus on primarily. So if you’re spending
a lot of time tweaking those kind of keywords,
you’re probably spending time on something
that we’re not really valuing that much. All right. Let me go through
these last four and then we can jump to
the Q and A. One thing that I think is
important is make sure you have all the
versions of your site listed in Webmaster Tools. We treat these sites
as separate sites, so you’ll have
different information potentially for
some of these sites. If you have a clear canonical
setup for your website, then we’ll have most
of your information in that canonical version. If you’ve never set up a
canonical for your website, then we might have some
of this information split across different versions
of the URL than we do indexed, so that can include things
like links to your site. It can include things
like the index status information, those
kind of things. The Fetch as Google render view
is an extremely valuable tool that I recommend
using regularly. Go, for example, to the search
queries feature in Webmaster Tools, pull out the top
10 URLs from your website, and make sure that they
really render properly with Fetch as Google
so that there’s no embedded content that’s
blocked by robots.txt that it kind of matches
what you would see when you look at
it in a browser. Mobile is extremely
important at the moment. There are lots of people who
are using mobile primarily to access the
internet, so make sure you can use your
site on a smartphone, and don’t just look
at your home page. Try to actually complete a task. So if you have an
e-commerce site, try to search for something
within your website. Try to actually order it. See that you can fill out all
of the fields that are required, that’s it’s not
a complete hassle to actually go through
an order something there. Kind of take it
step by step and go from someone who’s
first visiting your website to actually
completing whatever task that you’d like them to do. And finally don’t
get comfortable. Always measure. Always ask for feedback. Always think about ways that
you can improve your website. The whole internet is
changing very quickly, and our algorithms
are changing quickly. What users want is
changing quickly, and if you get too
comfortable, then it’s easy to get stuck in a situation
that everything has changed around you and
suddenly your website isn’t as relevant
as it used to be. So make sure you’re kind
of staying with the trends. And with that, I think that’s
it with this presentation. AUDIENCE: John, why is the
Fetch as Google limited when it comes to submissions? And so you’ve got I think it’s
500 submissions for singular pages and only 10 for
the larger option, and why is it limited
to Webmaster Tools it counts, specifically,
because it’s not a site. JOHN MUELLER: I
don’t know why we chose to do that
specifically there, but that’s something
where we kind of have to reprocess those
URLs in a special way. So that’s something where we’d
like to kind of limited the use there so that it doesn’t
become like the primary way that content is
embedded in Google. And in general, if you make
normal changes on your website, we can pick that
up fairly quickly. I wouldn’t use this tool
as a normal way of kind of letting us know about
changes on your website, instead I’d use
things like sitemaps and feeds to kind of
automate that whole process. So that something where
they’re usually better ways to get this content into
Google, but there’s sometimes exceptions where you
need to kind of manually tell Google to, OK, go ahead
and re index this content as quickly as you can. And that’s kind of why we have
that there and to avoid people from kind of overusing
this for things that it doesn’t actually
need to be used for. We have those limits there. AUDIENCE: So if you were to
set something in your sitemap and to say this page was
updated 10 minutes ago, whatever it is, if
Google then picks up on that sitemap on a
very regular basis, the minute it picks
that up, will it kind of perform
a similar action? JOHN MUELLER: Usually, yeah. It’s something where if we
can trust your sitemap pile, if we can see that the URLs
you submit there are real URLs, if we can trust your
dates to be correct, then we’ll try to take that into
account as quickly as possible, and that can in some cases, be
seconds or minutes after you submit the site that file. For new sites, for example,
that happens really quickly, if we see news content
on a site that we know has been
submitting good sitemap files with the
proper dates in them, then we pick that up
within a few seconds. So that’s something that
is fairly automated. It works really well,
and it’s a great way to kind of get the new content
into the search results. AUDIENCE: And so if you were
to incorrectly index something to say these 20 pages
will get updated weekly but really it’s more monthly
or sometimes six monthly, is there a signal that kind
of distrusts your sitemap? JOHN MUELLER: It’s not so
much that we kind of have a signal about your website and
say we don’t trust you on that, but if we look at
a site map file and we see all the pages on
the whole website change just 5 seconds ago, then chances
are your server is kind of just sending the
server date, and that’s the kind of thing
we’d be looking for. If we look at the site
map file, and we say, well, this kind of matches what
we expect from this website and there are some
new pages there, then that’s kind of a really
strong signal for us to say, OK well, this time around this
site map file looks great. We should trust it. We should pick up
this new content. And that’s kind of
what we’re looking for. That change frequency
is something we don’t use that
much from a sitemap file so if you can, just submit
the actual date of the change instead. AUDIENCE: Excellent. Thanks, John. AUDIENCE: Just a very quick
question on the sitemap bit. Do you use priority in sitemaps? So I should prioritize
pages that you think is more important on
your website than others. Is that something
you use at all? JOHN MUELLER: I think
we don’t use that at the moment for web search. I think it might be used
for custom search engines, but I’m not 100% sure. But for web search,
we’ve gone back and forth about using that. We’ve looked at ways that
people are using this, and to a large extent, it hasn’t
been as useful as we initially thought, so we’re not
really using that. AUDIENCE: OK. No, that’s perfect. And just very
quickly on RSS feeds. Is there anywhere in
particular that you kind of advise to upload that feature? You don’t upload it
as a sitemap do you within Webmaster Tools,
that sort of thing? JOHN MUELLER: You can submit
it as a sitemap in Webmaster Tools. What I’d recommend
doing if you can do that, if you have a really
like fast-changing website is make sure you’re using
pubsubhubbub as well. So pick a hub and
make sure that you’re kind of setup on
your CMS supports pubsubhubbub so that you can
push the content that way, because with pubsubhubbub,
you’re essentially telling us every time you make a
change on your website then we can pick
that up immediately. AUDIENCE: No, that’s perfect. Thank you. JOHN MUELLER: All right. Let’s go through some of
the submitted questions and a bunch of these that
people voted on as well. You spoke of duplicate
content within the website. What about duplicate content
on a site that has copied or scrape view. I realize we should attempt
to try DMCA removal request, but is there any way
Google can better determine the original content? We do try to do
that to some extent. Sometimes that
works really well. Sometimes it doesn’t
work so well. Oftentimes, when I see
it not working so well, I see that the site
that’s being copied has a lot of other
issues as well. So it’s always a
tricky situation. If we run across one
website that’s essentially where we can tell that actually
this is the original content but this website has
so many bad signals attached to it that
we don’t really know how much of this
content we should trust, how much you trust this website. So that’s something where if
you’re seeing scrapers ranking above you, I’d just
double check to make sure that your website is
doing things right as well and maybe use a DMCA tool if
that’s something you can use. Check with your lawyers,
your legal team. If you can’t use a DMCA
or if something just doesn’t work right
with the ranking where you’re seeing these
scrapers rank above your site and you’re actually doing
everything properly, then that’s something
you can definitely always send feedback to us about
so that we can take a look and see what we should
be doing different here. That’s always a
tricky situation. I know our teams are looking at
this kind of a problem as well and seeing what we
can do to kind of make that easier for the web master. Links added in the
source code, but not present on the front end. Does Google consider
this as a backlink? Is it something spammy or a way
of connecting to your website? So I think the
question is more around like hidden text, hidden
content, hidden links, those kind of things. In general, we recognize when
text or content is hidden and we try to kind of
discount it for web search. The same applies to
links essentially. So if these are
hidden links, then I wouldn’t count on those
always being used the same as something that’s
directly visible. So if this is a
link that you want to have counted
for your website, then that’s something I’d make
sure that within your website or however you’re linking that
is something that’s actually visible to users,
that’s usable for users so that users can use
those links as well and it’s not just
something that you’re kind of hiding in your HTML
code for technical reasons, so make sure it’s
actually something that works for your users. Is it true that Google
is in the final stages of releasing Penguin. Would you estimate it’s
days or weeks away now? Yes, we’re working on it. I estimate probably like a few
weeks, not too much longer. But as always, these
kind of time frames are really hard to
judge because we do a lot of testing
towards the end, and we need to make sure
that things are working right before we actually release
these kind of changes. So that’s something where
if it’s not released yet, then I can’t really
promise you that it will be released whenever. I know it’s pretty close
and I know a lot of you are waiting for that,
so soon, but not today. When rebranding,
would you recommend going through backlinks in
requesting the anchor text if it’s a brand name in the
URL we changed in the new brand name and domain? We definitely
recommend making sure that the links change to your
new domain as much as possible so that we can
forward kind of page rank or the value of that link
on specifically to the right URL directly instead of having
to jump through redirects. Also for users, when they click
on those links, the redirect, sometimes, for example, if
they’re on a mobile device takes fairly long to get
processed and kind of go through. So if you can have those links
go directly to your site, if these are important
links, then that’s something I recommend
checking in with them and having them update. Whenever I make a change to
any of the content on my site, I see a drop in performance
often a few weeks before I’m back to where I used to be. Why is this? When you make significant
changes on your websites specifically around the layout
and the text [INAUDIBLE] of that, I think that’s
normal because we have to reprocess
everything, especially if you’re changing things
like your internal linking structure. If you’re switching to a
slightly different CMS, then that’s something
where we essentially have to really understand
the whole website again, and that would be normal to
see changes and fluctuations in search because of that. If you’re just fixing typos
or changing small text pieces on a page, then
usually that shouldn’t be something where you’d see
fluctuations in search for. So it kind of depends
on what kind of changes you are making there. For small textual
changes, I wouldn’t worry about that causing
any kind of fluctuations unless, of course,
you’re removing something that people are very
desperately searching for. So if you have a
page about blue shoes and everyone is
searching for blue shoes because they’re really
popular at the moment and you change that page to
talk about green t-shirts, for example, then,
of course, you’re going to see some changes
there because people aren’t finding what
they’re looking for. Our algorithms can’t confirm
that this is actually a good page anymore. We have to understand it again. Why is my site
crawled every week? How often should it be crawled? Well, that kind of
depends on your website and how often you’re
changing your content. The important thing
to keep in mind is we’re not crawling the
sites, we’re crawling pages. So usually we kind
of differentiate between the types of
pages on our site. We’ll try to pick up a home
page maybe a little bit more frequently than some of
the lower-level pages especially when we can
recognize that something has to change for
a really long time. So if you have an
archive from 1995, chances are those articles
aren’t changing that regularly and we don’t have to recrawl
them every couple of days. So maybe we won’t recall
those every couple of months since then. On the other hand,
maybe the home page has current news
events on it, so we’ll have to recrawl it
every couple of hours or every couple of days. So that’s something where there
isn’t any fixed time where I’d say this page should be
recrawled this frequently. It really depends
on your website, on the number of changes
you make better, but also, to some extent, also on
how we value your website and how important we
think it is to pick up all of these changes. So we’ll sometimes see that with
like lower-quality blogs that are essentially
just like resharing copied content from other
sites already that sometimes it will happen that we’ll
kind of slow down our crawling of those sites
just because we’re saying, well, there’s nothing really
important that we’ve missed here if we went to crawling
every couple of days instead of every couple of minutes. So that’s something
where we’d probably adjusted our crawling
scheme, but if you have a normal website and you
have regular changes on there, you’re using something
like sitemaps or RSS to let us know
about those changes, then we should be kind
of keeping up with that and trying to keep up
with the crawling there. The relationship between
the usability and SEO. I guess that’s really kind of
a big and almost philosophical topic. Essentially if your website
isn’t usable for users, then users aren’t
going to recommend it and that’s something that will
recognize in search as well and try to kind of
reflect in search, but it’s not the case that
we read any kind of usability tests on normal
web pages to say, oh, this has, I don’t know,
wrong text color, therefore, people can’t read
it directly, and we should be kind of
demote it in search. So that’s something
where there’s more of an indirect
relationship there. What are some
current SEO tactics as per the latest
algorithm updates? I guess the best tactic, if
you will, that is still current is having good content. Go ahead, Joshua. JOSHUA: I think maybe
that’s tactics in quotes. Latest tactics. JOHN MUELLER: I think, I
mean, the good parts about all of this at the moment is that
if you’re using a normal CMS system, then the technical
foundation for your website is probably pretty sane,
and it’s not something where you’d have to apply
any kind of special tactics to kind of get that into Google. And the actual
tactics on ranking better are more about
like finding ways to create really good
and useful content, finding ways to be
timely in search, finding ways to kind of provide
something that users value, and that’s not a technical
tactic, if you will. There’s no step-by-step
guide to getting there. That’s something where you
have to work with your users and find the right solution. Is it true that any
changes you do to site, disavow bad links, for
example, won’t come into effect before the next
algorithm update? Disavow file is
processed continuously, so that’s taking into
account with every change that we do on our side. Let me see if there
are any higher– AUDIENCE: Rodney had a question. AUDIENCE: John, can I ask one? JOHN MUELLER: Sure. AUDIENCE: Let me just throw this
doc into the chat, if I can. Is someone playing
squash in the background? JOHN MUELLER: Ooh. Ken, let me mute you
out for a second. I can’t seem to mute you. OK. Go ahead. AUDIENCE: OK. I just pasted a URL,
a doc into the chat, and it’s something
that I’ve asked before, and Gary has asked
before in relation to hreflang and secure. So I wondered if given that
we have two versions of each now on four sites,
as per that diagram, can we effectively cut out the
middle and not bother with– I don’t know if everyone
else can see that, but I know other
people have have asked similar questions before. JOHN MUELLER: Yeah. Oh, gosh. Yeah, I wanted to
make a slide on that. Yeah. I know someone who is
working on a blog post– AUDIENCE: I did one for you. JOHN MUELLER: I know
someone who is working on a blog post around
hreflang and canonicals, so I think that would
apply there as well. But I think in a case like
this, essentially what you have is your two sites. I’m just going to assume
like one is US, one is UK. AUDIENCE: No, it’s all US. We’re only using the
hreflang as a kind of work around as you know. They’re both US so we just
had the one site which was previously subject to
some unknown algorithm issues unless you have an
update for me on that. But moving with hreflang to also
a US-based site helped that. But then the secure
thing was releasing, if possible, use secure. So we did, but we actually
saw a drastic drop when secure was released and the same
as when Barry Schwartz was the call a couple of weeks ago
and he said his secure saw it. He showed you his Webmaster
Tools if you remember, and we had very similar
percentage drops. We’re now actually considering
unwinding that because it’s not recovered within
the last 30 days. After moving to secure
we’ve lost another 50% of our traffic, but
it’s just not covered. So we’re thinking
of unwinding that. But aside from that,
we think there’s no point in having four sites
in the mix when we could just have two and go from the
original to the secure new rather than the
original to secure then over to new non-secure
then over to new secure. Because it’s just more
work and more processing for– the more steps
the more that Google can in one way or
another misunderstand what we’re trying to do
whether rightly or wrongly. JOHN MUELLER: So essentially
with the hreflang, you need to make sure
that you’re doing it between URLs that are canonical. So for example, if you have one
URL with a parameter and one URL without a parameter, and
you say you’re rel canonical or you’re a redirect is going to
the one without the parameter, then that’s the one you should
be using for the hreflang pair. So essentially if
you’re using redirects that point to one
version of your site, then that’s the
version you should be using kind of between
the hreflang settings there. AUDIENCE: These four are
absolutely identical, just so you. They are absolutely identical
apart from HTTP versus HTTPS. The content is 100% identical. So going from one
to four, given what you said there would
make sense rather than going from one to two,
from three to four and then two to four. JOHN MUELLER: I’m trying
to visualize how– AUDIENCE: I may draw
you a diagram for you so you can visualize easily. JOHN MUELLER: I see some of
that but I’m not actually sure how it’s actually
implemented at practice, but essentially you just
need to make sure that you’re kind of connecting the
hreflang between canonical URLs because if we see an hreflang
tag pointing at a URL that we’re not
indexing like that, then essentially we
ignore that hreflang tag. So it really needs to
be between the URLs that we’re actually indexing. So if you’re using
301s or rel canonical to point to one
version of the URL, then that’s the one you should
be using for the hreflang param, and if you’re
not using 301s, if you’re like keeping
one version like this and the other version
is the other canonical, then using the hreflang
directly between those two is fine as well. But it should just be the one
that we’re actually picking up for search and
indexing like that. AUDIENCE: Right. Which I believe is– JOHN MUELLER: I’ll
double check your sites because I’m a bit confused
which one is which and how you have
that actually set up. If you want, feel free to send
me a note on Google+ and I’ll– AUDIENCE: Yeah, I’ll send
another email with what we– because I know I
answered your last one. So I’ll send you another
note of what we did, but I think it’s come home again
because of the secure issue, and I was hoping Barry will
be here so he could say, but if anyone else in the
chat, in the call area has had the same
issues with secure. I haven’t seen it on any forums. JOHN MUELLER: Yeah. So we looked at a
whole bunch of clients. AUDIENCE: [INAUDIBLE]
Barry’s does. JOHN MUELLER: Yeah. We looked at a
whole bunch of sites because we thought it
seemed strange to hear this from a handful of
people at the same time, but for most of them, it’s
actually doing the right thing. So I think there might
be some kind of quirkies in some of our algorithms
there’s still, but on a large, I think, moving to HTTPS should
just work out for most sites. But I am happy to take another
look at how you have yours set specifically because
that sounds like it’s not the typical hreflang or
canonical or secure site move. Yeah. AUDIENCE: Right. I mean, if all else,
they equal the boost that you would normally
get from secure I assume is negligible anyway
if everything else is normal, so it’s better to unwind it
than going the 50% traffic back, because you’re
never going to gain 50% by having secure
versus non-secure. JOHN MUELLER: Yeah. I think if you can confirm that
it’s really from that then that definitely makes sense,
or it’s something where you can say,
well, I will just role this back to the moment
and reconsider it maybe in a couple of months. When I see that other
people are posting lots of good experiences
about that move, that might be something to do. I think that’s always
a sane approach when it comes to these
type of issues. AUDIENCE: OK. I’ll drop you an email. with diagrams. JOHN MUELLER: Great. Yeah, I’ll double
check the pages. OK. So with that, I think
we’re a bit out of time. Thank you all for joining in. Lots of good questions. Lots of good feedback. I hope I’ll see you guys again
in one of the future Hangouts as well. AUDIENCE: Thanks, John. AUDIENCE: Excellent Hangout. Thanks, John. Have a wonderful weekend. JOHN MUELLER: Thank
you, everyone. AUDIENCE: Bye. JOHN MUELLER: Have
a good weekend. Bye. AUDIENCE: Thanks so much.


Leave a Reply

Your email address will not be published. Required fields are marked *