Best practices and common mistakes in SEO

MICHAEL: All right. And I think we
are live, so thank you, everyone, for joining us
for this Webmaster Office Hours today. We have some specific topics
for this Office Hours. We’ll actually be talking
about the same topics that we presented last
week at Google I/O. But obviously a lot
of people were not able to attend I/O
in person, so we thought we would just kind
of bring it to all of you. We’ll be talking about
three main topics. The overall theme of
this is best practices and common mistakes in SEO. First, we’ll be talking
about best practices for mobile sites regarding SEO. Then, we’ll be talking
about multilingual and multi-regional
international sites. And then, we’ll also talk
about monitoring your site for spam and abuse. So maybe we can start with
some quick introductions and then we will
just get into it. Mary, did you want to start? MARY: Yeah. Hey everyone, my
name is Mary and I’ll be going over the mobile
section with you guys. ERIC: Hey guys, I’m Eric. I’ll be doing multi-regional
and multilingual sites. MICHAEL: And I’m Michael,
also known as Whiz. And I’ll be talking about
monitoring your site for spam. So, first up, I
think we have Mary, who will be talking
about mobile sites. So I’ll go ahead and
bring up the presentation, and hand it off to Mary. MARY: Cool. Thanks, Michael. All right. So I’ll be speaking about
mobile configurations. These are mistakes that
we see commonly– I’ll be going over best
practices, and the mistakes. We want our search
users to experience the full richness of the web. But sites that have
common mistakes we mention here provide people
a really bad user experience. A few of these
mistakes will drive users to hit the Back
button, and other mistakes can just frustrate your
users, since they’re unable to find the exact
page they’re looking for, or the information. So pay attention to resolving
these common mistakes. And keep in mind that
they’re information we take into account
for ranking purposes, in order to provide our users
the best and most relevant search result. The three that
I’m going to cover are unplayable content,
blocked content, and misdirected content. And as I said, a
bad user experience can hurt your site’s
ranking on search results. So the first one is
unplayable content. Now, I don’t know
about you, but this has happened to
me so many times. I click on a search result
page and want to see a video, but the plug-in
is not supported. This is really frustrating. I usually just click
on the Back button to find a different video
on a different site. To make sure that your site
has no unplayable video, you can just easily test
videos on your phone for incompatible
software such as Flash. And a general best
practice here is, add your summaries
or transcripts of what the video is about
below the actual video. So if your user cannot watch
the video for some reason, or if they just don’t have
time to, they can at least read a summary of it. Now the second misconfiguration
I’m going to talk about is blocked content. If you are blocking your images,
or important CSS or JavaScript files from us, then we
can’t render your site and we can’t recognize
the mobile version of it. It’s really important for us
to be able to see these things. So a good thing to do
is, check your robots.txt files, or any related files, to
see if they’re blocking Google from crawling your JavaScript,
CSS– or even images, in this case. And as I mentioned earlier,
if you’re blocking resources from making it possible
for us to recognize the mobile version, then we
can take that information into account when we’re showing
your site in search results. Now here’s something
you should keep in mind. Make sure you’re treating a
Googlebot as a regular user. What I mean by that is, when
Googlebot is crawling your site and it’s coming to your site,
and it’s saying that it’s an iPhone, for example–
treat it as an iPhone. Don’t treat it
specifically as Googlebot. This is very important, because
in our Webmaster guidelines we want to make sure that
you’re not showing Googlebot one version of your site, and you’re
showing users a different site. This is considered
cloaking, and this goes against our guidelines. Just a sec. We’re going to make sure
the presentation’s going to be shown on your screen. MICHAEL: I believe if you’re
watching live on YouTube, we are showing it. I think maybe if you’re
participating in that, you might just be seeing us. But if you go ahead and pin
Eric, that’s the presentation. MARY: Cool, OK. So just to recap– don’t be
super-specific about the user agent you’re
targeting, and don’t treat Googlebot as a
specific user agent, just treat it as a regular user. OK, so this is a hefty one. I’ll be going over a
few different types of misdirected content. In this first case here, I’m
looking at a search result that’s taking me to news But I’m actually
taken to the 404 not found page when I go
on my mobile device. And this is a really
bad user experience because I’m not sure if the
site exists, and it exists in a different URL, or
if the site doesn’t even exist on mobile. This is a very frustrating
user experience. We don’t want to provide our
users this type of content. So what you can do
in this case is, if you do have a mobile version
available on a different URL, redirect your users
to that different URL, if it’s available. And for some reason
if you don’t have a smartphone-friendly
version available, then serve the desktop
version of that site. So just take your users to, instead of the mobile
version, which is a 404. We say this is better– to
show your users something– than to show them
nothing at all. The second type of misdirected
content are faulty redirects. We see this a lot on sites. This is commonly
occurring when smartphones are redirecting people
based on user agents. So in this case, I have three
different desktop URLs– which are the home page,
the Shop subdirectory, and the About Us subdirectory. When I click on any of
these on my mobile device, I’m taken back to the desktop
homepage of the mobile version. So all three examples
here are taking me to This is a frustrating
user experience too, because I have to look for
the Shop subdirectory myself. Or if I can’t find it, I’ll
probably just leave the page. This is one type of
faulty redirects. We also see cases
where, let’s say, I’m looking for a specific
product– but I’m taken to the generic Shop page. Or also, I’m
redirecting some users, let’s say Android users–
but not iPhone users. As I mentioned, faulty
redirects result in a really frustrating
user experience. It’s so important
that we now flag these in our search
results page. In this example, Google
thinks that if you click on, you’re going to be taken back to
the mobile version of the home page. We want to tell users
this as a warning, and also to make
sure that this is a result that they
want to click on. So make sure you don’t
have any of these, because it can hurt your
rankings in search result. And we want to spare
our users from landing on irrelevant pages. A simple test you
can do here is, you can click on your search
results– using your phone, or a emulator– and test if
they take you to the right URLs. So you can perform a
site search on Google. They’re so important
that we also show them in Webmaster Tools. So if you have your Webmaster
Tools account verified, you can go into URL Errors, and
then look for faulty redirects. If you see any examples
in Webmaster Tools, you can go into your
server configuration and debug where the issues are. Cool. So now I’ll be talking
about some best practices. If you’re listening
to this presentation and you don’t have a
mobile site set up yet, then Google recommends
responsive designs– for a number of reasons. A lot of the errors
that I talked about earlier–
and the mistakes– can be avoided if you
use responsive design, because you’re just
basically using one URL. And you’re using the same
HTML, but different CSS. But if you do have a
mobile site already, and you’re using a separate
mobile URL for the site, then we recommend adding
bi-directional annotations. What this means is, on the
desktop version of your site– which is on the top here,– you want to add a
rel=alternate tag. In this case, we’re
saying that there’s a alternate version
of your site– here it’s– and it depends on the
screen size, here. It’s 640, in this case. And the second part of this
is, you want to make sure that on your HTML, you want to have
a rel=”canonical” that points back
to the home page. This tells Google that, OK,
these two URLs are one entity. This is really important for us. If we don’t understand that your
desktop version of your site and the mobile
version of your site are one entity, then if
people are searching on search results, we might be showing
two different results for that. And in this case, it might
be hurting your search result rankings because we’re
showing them twice. And your ranking might be lower
than they normally would be. If you also have
automatic redirect set up, then you want to add
a vary HTTP header. In this case, it has a
arrow pointing to it, and it says that the
response we get here is based on the user agent
that’s coming to the site. This helps tell
Google that there’s a mobile version of
your site, and it helps us understand that
this is a single entity. Cool. If you have all of
these set up correctly, what we do on our search
results is a really cool thing. It’s called a skipped redirect. In this case, we have If I click on it,
Google actually just puts in the mobile
version of the site, which is–
we just directly give users this URL. The skip redirect removes
an extra redirect latency by half a second to one second. So it makes it a lot faster
for your mobile users. The last general best practice
is– on your mobile version of your site, you should add a
link on the bottom that says, take me to the desktop-optimized
optimized version. And you can also do this
on your desktop version– say something like, take me to
the mobile-optimized version. What this does is,
it helps override any misconfigured redirects. So if something’s
wrong on your site, your users can actually
just go to the version that they prefer. If you have this set
up, make sure you’re keeping your user’s
other preferred version for the entirety of the session. So let’s say they
click on this link, so that they can see that
desktop-optimized version. But they want to go to a
different page, for example, and they get switched back
to the mobile version. It provides a really
bad user experience. So make sure you’re keeping your
users on the preferred version. Cool, thank you. And now I’m going to
pass it over to Eric. ERIC: Thanks, Mary. Hey guys, I’m going
to talk to you a little bit about
multi-regional and multilingual sites in search results. So imagine this is your
business, or you have an app. You can either be like a
small, medium business, or even a large business. But you’ll know that a lot
of people want your apps. They want your content,
they want your services. So you have this whole
wide world to cater to. How do you reach these people
in these different markets? One way might be to
create a website. Multiple websites, actually. So in this case, we have
Dublin, Taiwan, Costa Rica– I know it’s a very eclectic
variation of websites– but how do your users
find these websites? Possibly through
a search engine. And my personal favorite search
engine is obviously Google. So when people are searching
for your site– for example, let’s say this is a
US user on, and they’re searching
for your business. And there’s something weird
about this search result, actually, because they’re
seeing a result for the UK version of the website. This isn’t a very good user
experience for the user, because they might be confused. They might not
even know that you have a US version
of your website and have services
in the US, or even sell things in dollar amounts. So they might not even
click through this site in search results. On the flip side, if you
have a user from Taiwan, and they’re looking
for your content– they see the search
result in search results. Now, this isn’t necessarily
a bad search result, because this is the global
version of the site. So anybody can go
to it and kind of find information
about your site. And that’s OK. But the thing is,
there’s actually a better, more region-specific
website for the user. So this user from Taiwan–
they could actually be getting a search result
that shows a description, and also has a phone number
that you can contact in Taiwan. So this is a much better
search result for a user. It’s better for
them because they can be more connected
to your business, if they’re looking for your
business, your service, your apps. The good news is
that Google actually wants our users to
find the right content. Google has a couple
solutions for telling us that you have multi-regional or
multilingual sites and pages. So let’s talk about
some solutions– ways you can tell Google
that you have multi-regional, multilingual
sites and pages. The first thing is to use
rel=”alternate” hreflang. Now, hreflang tells
Google that there’s multiple versions of a page. So let’s say, for example, there
are three versions of a page here. There is the
international version of a page– this is the
one that you want people to go to if they don’t
have a region-specific or language-specific
version of the page. Then there’s the UK page, here. And then the US page. So three versions of
similar pages, but they have different content
for region-specific users. They might tell about
region-specific services and how to pay in
different currencies. So what type of code do
you put on each page, in order to indicate
to Google that there are three variations
of the same page? This is pretty easy. It’s basically the same code in
the head section of each page. So let’s dive deeper
into each page’s code. First off, there’s This is the international,
global version of your page. That means that if
there’s a user– for this specific example,
from Taiwan– looking for your content,
since they don’t have a region-specific or
language-specific page, then they would be shown this default version of the page. On this page, we also
recommend that you have some type of language
picker, or language selector. There’s a variety of
reasons that you need it. And one of them
is just, if there is a better version of the
page for a user, that way they can select it. And also if you have some
automatic redirects set up, and you’re automatically
redirecting users from, let’s say, one page
to what you perceive as their language-specific
or regional page and they’re
incorrectly redirected, they can go to the default page
and pick the correct language or region. On the next page, we have
the UK version of a page. This is the same exact code. Again, it goes in the
head, and basically links to the other versions
of the same page. And finally, the US version. You guessed it, it’s
the same code again. So this is really
simple to set up. All you have to do is make
sure that you link back to every version of
the page that you have in search results– every
version of the page that you have that has different
languages or regions. So again, this is just
to kind of illustrate, it helps Google
understand and cluster the different
versions of your page. That way, when Google’s
crawling and indexing your site, they understand– OK, there are
three variations of this page. And when we’re serving
results to users, it’ll help Google serve the
correct version of a page to the user. The other thing that you
can do is geotargeting. Geotargeting helps
Google understand that a website is associated
with a specific region. You can do this in Webmaster
Tools, under Site Settings. So in this example,
the Site Settings is telling Google
that this page is for users in the United
States of America. Basically, this just helps
Google– gives another signal, so when serving a page
in search results, it’ll appropriately serve
the result for users in a specific region. This is for a site, and
not specifically a page. So when you’re doing
geographic targeting, just be very careful. Don’t apply just to
a page, but make sure that you’re applying it
to like a whole site, or like a subdirectory
or directory of a site. Implementing hreflang,
it’s pretty easy, but there are a couple
common mistakes that we see, and we just want
to point them out, so you don’t avoid
them on your own site. So this example– it’s
really interesting. It’s not very obvious
where the problem is. When looking at this,
technically this is implemented correctly. But if you look at the
language and the region code, you realize that this is
targeting Spanish users in Laos. And last time I checked
on Wikipedia there aren’t very many Spanish
speakers in Laos. So the person that
created this web page is actually trying to target
people that speak Spanish in Latin America, hence the la. Unfortunately, la is the
regional code for Laos. If you wanted to target
people in Latin America, you would have to pick
the specific region. So let’s say, Spanish
in Peru– so es-pe. This helps Google
understand that, oh, is this the regional page
for Peru, and for users that speak Spanish. The next example– a
common mistake that we see is missing backlinks
to global pages. So in this example, you can
see that the US page is missing a backlink to the global page. This actually causes
Googlebot to be confused when crawling, and indexing,
and processing your site– because then we may
not be able to cluster all these pages
together correctly. So make sure when
you’re adding new pages or adding new regional or
language pages to make sure that the hreflang on
each page is updated, so that Google can
appropriately cluster all these pages together. This third example– this
one really bothers me, because it’s happened to me
a couple times, actually. So let’s say you have
a US user, and they’re using Google to search
for content page apps. And they click in search
results and they’re 301 redirected based on location. In this case, this 301
redirect is incorrect, because it redirects the user
to the UK version of the page. This may not even
be the page’s fault. Maybe the user is
spoofing their location, or there’s something
wrong with the way that the page is processing
the user’s location. And that’s fine. I, as a user, can go to
a country picker page, like the default page, and
pick the correct region or the country. But some pages, they
have a blanket statement for all users, when
they visit any page, to 301 redirect to
what they perceived as the appropriate
language or location page. So in this case, the user is
going to, the country picker
page, but then is 301 redirected back to the
UK version of the page. Basically, the user can never
get to the appropriate language or regional page that
they’re looking for. This is really
frustrating for any user, because they can never get the
content that they want to see. And this is actually
bad for a person’s site, because the user will never be
able to get to that content. This can also confuse Google,
because when Google is crawling and processing the page it
crawls from a specific region. So if it’s crawling from, let’s
say, the US– and this page keeps redirecting users over
Google to the US version of a page– Google
won’t fully understand the differences between
the default page and the US version of a page. So just be very careful of this. Today we’re going to actually
demo a new tool for anybody who has international, multilingual,
multi-regional sites. This isn’t out yet
in Webmaster Tools, but we’re very,
very excited for it. Soon, in Webmaster Tools, you’ll
see a International Targeting tool. This will tell you if you
have any errors with hreflang. So it does two things. First, it tells you if there’s
any wrong region or language codes. So you can see in
this live example, that and en-canada is an
incorrect region code. It should be en-ca. So you can see exactly where
these errors occur, and then you can fix them on your site. The next thing that
this tool will do is tell you if there’s any
problems with missing return links. So you can see here that
there’s a couple missing return links for English, or
the en-ca version of a page. And again, you can click
through, find the problem, and fix it. So we’re really
hoping that if you have a multi-regional,
multilingual site this will really
help you– because we do see these errors
a lot, on many sites. If you have any comments–
when it’s released, please feel free to let
us know on the forums. We’ll be looking for your
feedback in the forums very soon. All right, I’m
going to pass it off to Michael to talk about spam. Don’t think anybody
likes spam, so this is going to be an
interesting talk. MICHAEL: OK, cool. And if anyone has questions–
we are collecting them in the Q&A feature. So feel free to add
your questions there, and after my part we will
start answering them. And you can also join the
Hangout, if you’d like. There’s a comment
on this event that gives you a link to do that. So anyway, like
Eric said, I’m going to be talking about monitoring
your site for spam– because users don’t want spam. You don’t want
spam on your site, you don’t want your
users seeing spam. And Google doesn’t
want to send its users to spam in our search results. I’m going to talk about three
features of Webmaster Tools that you can use to
monitor your site and see if you have
spam on your site. I’ll talk about
security issues, I’ll talk about the Manual
Actions Viewer, and I’ll talk about the
Content Keywords tool. It’s important to think
about spam on your site, too, because it can affect your
site’s reputation in search results. Let’s hop into the demo, here. Hopefully everything works. I’m going to first
show security issues. For this one I’m going to head
over to So hopefully, if you’re checking
security issues for your site, you’re not seeing anything. It should hopefully tell
you that everything’s fine. But what if you did see
something on your site? In this example here,
it says that there is content injection– so
thinks that the pages have been modified by a hacker. And you can see that
there’s a sample URL given here of styles.php. So OK, Google says it’s hacked. Let’s take a look. It looks kind of OK. There’s nothing really there. So let’s go back to the
security issues feature, here. This time I’m going to
click on Show Details. And here you can see
that it’s warning me that the spammy content
might be hidden. It might be cloaking
or hidden with CSS. So it actually links off to a
tool called Fetch as Google, where you can actually
be the actual Googlebot, and go ahead and fetch the page,
and see what Google got back. I’m going to use this as kind of
an excuse to demo that feature. So I’ll click on Fetch as
Google, here, for this page. And I’ll request a
fetch of styles.php. Boom, OK, done. So I’ll go ahead and
click on it, here, and we’ll look at
what we got back. Looks like some
pretty normal content. But then at the
bottom here, you’ll see all of this text that
looks a little suspicious– all of these strange
links to payday loans and that kind of stuff,
that’s not really related to the site’s content. That’s a security issue, so if
you see something like that, definitely
investigate it and see what’s going on with your site. OK. Not every piece of
spam on your site is going to be
inserted by a hacker. But it might be something
where they’re perhaps a little more invited to
the content on your site– if you have
user-generated content. You might have seen
this kind of thing, where there’s user profiles
like this– where it’s actually not a person, that’s
obviously a robot, there. Or maybe you’ve come
across a forum that has turned into something
like this, where I think it’s kind of
small on this screen, but it’s just basically
a bunch of spammy posts. In these cases, the
spammers are hoping to build links to
their spam sites, leaching off of your
site’s good reputation to improve their rankings. When Google sees this
kind of stuff on a site, we can actually
take action on it to prevent it from showing spam
to users in our search results. To show this, I’m going to show
you the Manual Actions Viewer– Because if you have a site
registered in Webmaster Tools, and we do take manual
action on it for spam we will actually
tell you about it. So let me show you
what that looks like, if this would
happen on your site. I’ll switch back to National
Worldwide for this part. For this site here, let’s
say it’s a legitimate site, so there’s no sitewide matches. But you can see that if I
click on partial matches, Google has taken some
granular and precise action on this site. You can see that there are
two sections here– /forum, and then this user profile–
that have been affected by the manual action. So that’s something
that you might see if you have user-generated
content on your site. And that’s a good time to
go ahead and clean it up. And now, a third thing
that I’m going to show is Content Keywords. This all looks pretty
normal, let’s check it out for the haircut site. Nothing’s really sticking
out there, but what if you saw some terms that
were a little bit strange? We have this as kind
of a mock, here. All right, looking
through this– haircut, OK, that makes sense. There’s probably an FAQ,
it’s about grooming, it’s about hair. But online pharmacy, diet
pills, cheap watches, those don’t seem very
relevant to the site. And those are also kind of
commonly associated with spam. So this is a way, even
if we haven’t explicitly flagged your site,
as having spam, this might be a first
indication that something is up. Something like
Content Keywords, you have to basically
log in and check it to see what’s going on. So what if you want to do
some more passive monitoring? One thing that you can do is,
you can set up a Google Alert. So this is at What you can do is
subscribe to a query. For this example here,
it’s doing a site search for So that’s restricting the
search to only show results from this site. And then it’s searching
for some terms that are more commonly spammed, but
also not related to the site. It’s searching for
loans, or casino. So if that triggers
and sends an email, that might be something
where you can take a look and see what’s going
on with your site. That was basically about the
monitoring aspect of spam. You probably want to take
some steps to prevent spam from occurring in
the first place. So there’s a little link set up here where you can go to get
more information about how to prevent user-generated spam
from occurring on your site. And in the unfortunate case
that you do get hacked, we do have a lot
of resources set up at Please check out those
resources, as well. And then in terms
of following us, I guess you already found
us on Google+, or YouTube, so thanks for finding us there. But we also have our main
site at, and our developers’ site at One other resource that I
would really like to point out, if you have any
questions after this, if you head to, at the bottom of the page you
should see a link to our Help forum. That’s where we have a lot
of really knowledgeable webmasters, and
Googlers in there as well, who can help you
out with your questions. So please, definitely check that
out if you want to learn more. That is it for our
main presentation. So I think at this point we’re
going to take a look at the Q&A and see what’s going on there. Or if anyone who is joining us
live wants to ask a question, you can go ahead
and do that as well. [VIDEO PLAYBACK] -So for this site here– [END VIDEO PLAYBACK] MICHAEL: Let’s see, Meeta,
do you have a question? [VIDEO PLAYING] No. OK, whoever that was has left. Do you guys see– here,
Eric and Mary, I’ll bring you guys back in. Anything good going
on the Q&A, here? ERIC: So I think a couple
people had questions about multilingual,
multi-regional sites. So hopefully I covered
that in my presentation. And I think someone asked about
new tools in Webmaster Tools to help you out with that. Hopefully, that new tool
is what you’re looking for. Someone has a
question about, what is the best video player/format
to use for a responsive layout that plays on
mobile and tablets? MARY: We recommend
using HTML5 tags. they’re really good
at understanding YouTube and other
types of videos. ERIC: Yeah, so HTML5 is
probably what we’d go for. Seems to work on
mobile pretty well. MICHAEL: Yeah, I
don’t know of any, like, really specific players. But I would just
say, just make sure that it works on as
many devices as you can. That’s probably the best
thing that you can do. That might be a good
question for the forum– to see if anyone has any
experience with a mobile site, or a video site, and
they might have tried out different players to
see what works best across multiple devices,
and is responsive as well. Thanks for the question. MARY: Does anyone have
any live questions? MICHAEL: No. All right. I don’t see any
other questions here, that are totally on topic. We were hoping to keep
this presentation just kind of to the topics that
we were addressing, and then we’re always
happy in the forum to talk about other questions
that you might have. So if no one has any
additional questions, I’ll just check the
group chat real quick to see if anything
is going on here. OK, so Chris is asking, so
say you have multiple language versions– maybe
the UK, and the USA, both in English– for
an e-commerce site. Would you have to
create original content for each product
within the website, or just use canonicals
for each page to prevent duplicate content. So it sounds like
they probably serve users in both, say,
the UK and the US. And they might have separate
URLs for those product pages– because maybe it’s
showing prices in US dollars and
British pounds. So Eric, is it right to say that
in terms of associating them, they would just use the hreflang
tags to kind of make sure that those are associated
with each other? ERIC: Yeah. So if I’m understanding your
question correctly– if you have products that
you’re targeting for different regions,
like the UK or USA, on all of those
deep pages, you’d want to use that hreflang tag. Because that way, Google can
serve the appropriate product page. If you’re saying you’re
paying in dollars, or you’re paying in
pounds, that way Google can serve the appropriate page
for users in search results. Because you don’t
want users to go to like a generic product page. That can be fairly
confusing for users. Again, if I’m a
US user, and I see your product is being
sold using pounds, I might not want to go
into that search result, because it might be a
little bit confusing for me. So hreflang is for each page. So make sure that all
your deep pages are also tagged with hreflang tags. MICHAEL: Cool. All right. Thanks, Chris, for the question. Oh, I see. That was probably actually
added to the Q&A, there. So let’s say that we answered
this one, right here. So I’ll just mark
that one as done. All right, so– now
the chat’s lighting up. We’re bumping back between
the chat and the Q&A, and we go to one and there’s
people writing in the other, and– oh, Chris is
asking a follow-up, here. ERIC: The descriptions, it
really depends on your page. If you’re trying to
target, like, US users, it should be unique
for US users. MICHAEL: But I think they
don’t need, you know, different product description
for like, UK versus US. If you’re changing
up the language, you might want to do that. But you are already
going to tell us that these are associated
pages, when you’re implementing the hreflang tags. So, I think it would be
OK if the only thing that was changing up was
the price, especially if you’re not trying to rank
those two pages individually, and you’re actually
telling us that they are associated with each other. ERIC: And just a
note about hreflang, it doesn’t affect your
ranking, it actually just swaps the group
pages out for each other. So it’s not like one page
is going to rank differently because of the hreflang. MICHAEL: Cool. MARY: There’s
another chat message. MICHAEL: Of course. Oh, sorry, did you want
me to go back to the Q&A? MARY: Oh, there’s
one more follow-up. ERIC: Using the
appropriate canonicals, where necessary,
is also important. I wouldn’t say no
canonicals at all. I don’t want to make
that blanket statement. But in terms of different
versions of the page, yeah, I would use
the hreflang there. There’s another
question on the Q&A. Same content in different
languages is OK for SEO? Yeah, absolutely. If you have multiple versions of
a page in different languages, if it’s good for your
users, that’s great. You should definitely do that. MICHAEL: And just mark them up. ERIC: Right, right. Just have the appropriate
markup using hreflang. OK, so we have a question. I need to show app download
interstitials to our users, though you don’t
recommend to use them. Is it fine to block
the JavaScript so they will not interrupt
Googlebot to crawl the pages. When it comes to JavaScript,
and CSS, and kind of blocking those
resources, Google really wants to know what
we’re sending users to. And so it’s always best if
we can fully render the page. We want to know
what search results we are sending to users. So we really recommend that you
don’t block JavaScript and CSS on your pages. If we say, users
generally might not like those app interstitials–
just speaking as a user myself, I find them to be pretty
annoying– maybe some of you have seen there’s an
XKCD comic about it that you can look up
that’s kind of funny. Anyway, you don’t want to
try and hide that from Google by blocking a resource. So I would say, yeah,
with anything kind of cloaking, or
blocking related– we want to see what
users will see. So if you have an
app interstitial, and you think that’s the
right thing for your users, don’t try to hide that from us. But, yeah. Thanks for the question. MARY: We have more in
the quality guidelines. So you can look into that too. ERIC: And then we have
our full mobile guidelines on Or you can Google
it– or whatever search engine you want to use. MARY: There’s some
chat questions. MICHAEL: All right. We should have like,
two monitors, here. OK. So I’m not seeing any direct
questions about the topics that we’re addressing today. Check back in the Q&A. No new questions there. So unless you guys had
any final thoughts, or if any new questions come
in we might wrap this up. I’m trying to read and
speak at the same time, and this is not working. OK, it looks like
this chat’s going on. OK. So thank you very much,
everyone, for joining us. This recording will also
be available on YouTube, if you came in late. And please join us in the forum,
continue to ask us questions on Google+ and Twitter, and
thanks a lot for joining us, and have a great week. MARY: Bye. MICHAEL: Bye.

14 comments on “Best practices and common mistakes in SEO”

  1. Philip Zeplin says:

    I feel like I'm here a bit too early…
    Sounds interesting though!

  2. Sa CREW says:

    How can setup the Maps location on Google results based on website language version? 

  3. Hasan Zahid says:

    What's about " Stop Words" ? Should i avoid stop words in my url?

  4. Andrew Rulnick says:

    Great office hours @Google Partners!

  5. Gaurav Rathee says:

    well done webmasters !!!!!!

  6. RankYa says:

    Google hangout on air explaining how to identify spam and other security issues through Google Webmaster Tools

  7. Piyush Khera says:

    Some great & simple tips to keep in mind !!

  8. Tú Cao says:

    Thank for share, i learn more about optimizations mobile for website.

  9. Michael Martín says:

    Thanks to share it! It was really helpfull

  10. Video SEO Services: #1 in 'Performance Based SEO' says:

    Great video

  11. Ronny Marx says:

    Awesome session guys! Especially the mobile issue is one  of the most important ones for future SEO.

  12. Tatoke kokipa says:

    definitely not live….

  13. Tatoke kokipa says:

    I am half way and i have so many question, for instance can i use php to change the language if the url == en-us or do i code it in to en-us.

  14. Tatoke kokipa says:

    I also think we are missing a canonical or meta tag for sites that are in development, i am constantly getting attacked if my site is in development, they say i should not put it online bla bla, then how am i supposed to lean about the SEO, i am getting constantly attacked any way, google products is totaly distroyed by these ppl, we all go to stackoverflow, where the real help is at, sure they try it over there to, but its easy to ignore them there, google should get rid of google products, befor the quality even goes down more, or create a user topic controled ignore button that bans the anoying user from the topic and future comments, any where, these volutairy mods are part of cartel activitys, and they hide the evidence reporting the topics as double post, so it wont get indexed or fool the user that found the topic.

Leave a Reply

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