JOHN MUELLER: All right. Welcome, everyone, to today's
Google Search Central SEO Office Hours Hangout. My name is John Mueller. I'm a Search Advocate at
Google in Switzerland. And part of what I do are
these office hour hangouts where people can join in
and ask their questions around their websites
and web search, and we can try to
find some answers. Looks like a lot of stuff was
submitted on YouTube as well, but a bunch of people
are already jumping in and raising their hands. So let's get started
with some live questions. Let's see, Praveen, I
think you're first up. PRAVEEN SHARMA: Hi, John. How are you? JOHN MUELLER: Hi. PRAVEEN SHARMA:
So you might have answered this
question in the past, but I didn't find the reference. So I just want to know, as we
know that for Core Web Vitals, Google uses its Chrome
User experience data. So I want to know for this
Chrome User experience data that Google uses
for Core Web Vitals, does Google only
consider users that were coming from
Google organic search or all the Chrome users,
irrespective of their traffic channel or source? JOHN MUELLER: It's
not tied to people clicking from Google Search. It's not-- PRAVEEN SHARMA: So it's
basically all Chrome users? JOHN MUELLER: Well, it's not all
Chrome users because of the way that the Chrome User Experience
Report collects the data, but it's not tied to any
specific source of traffic for your website. PRAVEEN SHARMA: OK. So what kind of
users we will see if this is a user who
falls into that category that we should consider
for this report? JOHN MUELLER: I don't
know it offhand. I think it has to do with
the settings in Chrome that you have it
set up that you're submitting user feedback through
Chrome, those kind of things. But I don't know the
exact details offhand. PRAVEEN SHARMA: OK, sure. Thank you. JOHN MUELLER: Cool. All right, Christian. CHRISTIAN KUNZ: Now? Hi, good morning, John. So I've got a question. So I have this website
I'm looking for, and we have this situation
that this website hasn't been migrated to
mobile first indexing and there is a mixed state. We have some pages which have
a separate mobile version and some other pages
are responsive, and the link structure
is kind of unclear. So I suspect that this might
be the reason for the website not to be migrated
to mobile first yet. And I just wanted to
confirm if this is true or if there might be
other reasons for that. JOHN MUELLER: I don't know. My guess is maybe
at the time where we were migrating all
of the websites over, maybe that was causing
it to be held back. But as far as I
know, there's still a batch of mobile first
indexing sites that are just not migrated over. And it's something where
we're working through some of the bigger sites there step
by step to make sure that they can all be migrated cleanly. And then when we have the
bigger issues resolved, then we'll migrate
the rest as well. So my guess is the website is
in this holding position where it's not necessarily that
they're doing anything wrong now, it's just back when
we checked it wasn't perfect. CHRISTIAN KUNZ: OK,
so you would say it's good to just wait a little
bit longer and to see what happens? JOHN MUELLER: Yeah. I mean, I don't know quite
what the timeline is. But my guess is like
towards the first half of next year we will be
migrating all of the remaining sites over. CHRISTIAN KUNZ: Oh, OK. JOHN MUELLER: And then you'd
probably see that happen. CHRISTIAN KUNZ: OK. OK. Cool. Thank you. JOHN MUELLER: Sure. Aakash? AAKASH SINGH: Hi, John. Hi. JOHN MUELLER: Hi. AAKASH SINGH: One of my clients'
website will be down for a week or for two weeks. OK? And the reason why
I'm here is there are a few bugs on the
website and that's the reason they said they wanted
to take the whole website down for a week or two. And my question is only
that although there will be traffic
loss and so and so, but how can I tell Google that
this is a temporary situation? It will be only
for the two weeks and our website will be live. Is there anything
that I could display, a page showing the website
is temporarily down and will be [INAUDIBLE] I know
that the countdown is there on my page. It's been within two weeks
or the 10 days, something like that. Can I tell Google that this
website is currently down, but it will be just
going back to live again within two weeks or a week? But there shouldn't
be any ranking loss, or there could be a minimum
ranking loss that I could get? Something like that. JOHN MUELLER: I
don't think you'll be able to do it for
that time, regardless of whatever you set up. So for an outage of maybe a day
or so, using a 503 result code is a great way to tell us
that we should check back. But after a couple
of days, we think this is a permanent
result code and we think your pages are
just gone, and we will drop them from the index. And when the pages come back,
we will crawl them again and we will try to
index them again. But it's essentially
during that time, we will probably drop
a lot of the pages from the website from our index. And there's a pretty
good chance that it'll come back in a similar way,
but it's not always guaranteed. So any time you have
a longer outage, I'm thinking more
than a couple of days, I would assume that at
least temporarily you will have really
strong fluctuations and it's going to take a little
bit of time to get back in. It's not impossible, because
these things happen sometimes. But if there's
anything that you can do to avoid this kind of
outage, I will try to do that. And that could be
something like setting up a static version of the website
somewhere and just showing that to users for the time being. But especially if you're
doing this in a planned way, I would try to find ways to
reduce the outage to less than a day if at all possible. AAKASH SINGH: OK. Well, thank you so much. That ends my query. Thank you so much. [INAUDIBLE] JOHN MUELLER: Good luck. Hazel? HAZEL WRONG: Hey, John. Good morning. It's me again. So we want to ask some
questions about Google AdBots. So do you think
will disallow ads URL to the Googlebot
in the robot text will affect our Google Ads? And maybe that cause
ads won't work normally. JOHN MUELLER: So
as far as I know, the AdsBot doesn't follow the
normal robot text directives. You have to use the user
agent directly for it. But I don't know what the
effect would be on the ad side if you block AdsBot. My understanding is
we use this as a way to do quality checks
for the landing page. I don't know what that
would mean from a quality point of view for
ads if you don't let AdsBot check these pages. HAZEL WRONG: The reason we
talk about this question is that we've recently found that
Googlebot crawled our ads URL more than normal page URLs. But we want Googlebot to promote
normal product pages instead of these ads. So we just think if it's OK to
block ads URL for Googlebot. JOHN MUELLER: Sure. Sure. Sure. That's perfectly fine. Blocking the ads landing
pages for Googlebot is fine. Again, if you block the
ads pages for AdsBot, then that's something you'd have
to check with the ads folks. HAZEL WRONG: Yeah,
that's not what we do. JOHN MUELLER: OK. HAZEL WRONG: So also
about the Googlebot, does AdsBot share a same
crawl budget with Googlebot? JOHN MUELLER: Yes. HAZEL WRONG: Yes, so that
means maybe the Chrome requests from AdsBot increase and
maybe Googlebots crawl less? JOHN MUELLER: Yes,
it can happen. Usually it settles
down fairly quickly. Again, I don't know the
details from the ad side, but my understanding
is when you submit new ads campaigns then
the AdsBot checks all of those pages. And once that's
checked then they don't need to be checked
as often as usual. HAZEL WRONG: OK. I see. If we're blocking the ads
URLs in the Googlebot ads, Googlebot maybe still
crawl too many ads URLs. What can we do? Maybe some measures to
handle this situation to let the Googlebot
crawl more product pages? JOHN MUELLER: So I think if
you're blocking the ads landing pages for Googlebot
specifically, then we shouldn't
be crawling the ads landing pages with Googlebot. It would really only be the
AdsBot that's crawling it. HAZEL WRONG: Because
previous time we blocked some certain
pages in the robot text, but we still see that
sometimes Googlebots still crawl these pages even
though we block them. So we just want to make
sure that it's working. JOHN MUELLER: Yeah. It should never be the
case that if we recognize the robot's text file that we
still crawl the URLs anyway from Googlebot. So that feels like
either something we would have to know
as soon as possible or maybe some mistake with
things like upper and lower case in the URLs, or not
exactly the right path being included in the
robot's text file. HAZEL WRONG: OK. So normally if we
in the robots.txt, it shouldn't be
crawled by Googlebot? JOHN MUELLER: Yeah. And if you see situations where
the AdsBot crawling severely drowns out everything else,
I would use that contact form that we have in the Help
Center to report problems with Googlebot. I think you've used it
before in the past as well. HAZEL WRONG: Yeah. Yeah. JOHN MUELLER: Because that
also goes to the Googlebot team and they can help to distribute
the requests a little bit better and contact
the ads team and tell them to slow down with this
website, those kind of things. HAZEL WRONG: Sure. Sure. If we notice something
unusual we definitely would report it to Google. So another question is
about the 304 response code. Do you think the 304 response
code affects crawling? Because logically if we
think if Googlebot checks a URL with the same content and
it returns 304 code first time, maybe there's a
possibility that Googlebot may reduce the crawling
for the same URL because it returns
to the 304 code. JOHN MUELLER: So I think
there are two things. So the 304 is, I
think, in response to the "if modified
since" requests where Googlebot tries to see
if this page has changed. And my understanding is that
a 304 response code would not apply to the crawl
budget side of things. So that basically means for
us, we can reuse that request and crawl something
else on a website. So there's that aspect. And the other
aspect with regards to crawling that
specific URL less, I don't think that
would be the case. But we do try to figure
out how often pages change and we try to recrawl pages
based on the assumed page frequency or update
frequency that we have. So it's not so much that
that particular URL would get crawled less
frequently, it's more that, oh, we
understand a bit better how often these pages change. And then based on that,
we can update our refresh crawling a little bit. HAZEL WRONG: So if most
of the pages on the site returns to 304, so maybe
it's a signal for Googlebot that the site has no
new updated content, maybe reduce the crawling rate? JOHN MUELLER: No,
I don't think so. No. I don't think we would
reduce the crawling rate. We would just try to focus
more on maybe the parts where we do see updates happening. So I would definitely
not artificially hide the 304s is in the hope that
it improves the crawling. HAZEL WRONG: Mhm. Sure. Sure. So also about the
crawling issues. Since our crawling
rate is back to normal, and we noticed that our crawl
requests from smartphone is recovering much more
faster than desktop. Could you shed some light on it? Any possible
reasons behind this? JOHN MUELLER: I don't know. It sounds like what
would be expected with mobile first indexing,
that we crawl a bit more with mobile. I don't know if your
specific site has already moved to mobile first indexing. HAZEL WRONG: Yeah, it is. JOHN MUELLER: Yeah. But then that would be
normal, that we just crawl more with mobile and
then you would see any changes faster there. HAZEL WRONG: Yeah. OK. So it's mobile first indexing. So the last one question
is a more general one. It's about 301 redirects. We are taking down
some useful pages and doing 301 redirects
to them and we just think, well, will a huge
amount of 301 redirects do harm to a site? JOHN MUELLER: No. No. That's perfectly fine. If you're making changes on
your website and redirecting, that's perfectly fine. HAZEL WRONG: So no matter how
many pages we make redirects? JOHN MUELLER: Yeah. Yeah. HAZEL WRONG: OK. That's good. That's good to hear. JOHN MUELLER: Cool. HAZEL WRONG: Thanks. This will be only question. JOHN MUELLER: Thanks. Let's see. Reshmi. RESHMI MOHAN: Hi, John. JOHN MUELLER: Hi. RESHMI MOHAN: Hi. This is the first time actually
I am attending this session. It's regarding to our
e-commerce website. This year only we have
launched one e-commerce website and for 70-plus
countries we have created a [INAUDIBLE] plan. In our URL structures
for different countries we have created-- like we have established in
UAE, so in UAE we have en_a. And when it comes to US,
our website structure is xyz.com/en_us. Like that we have created
for 70-plus countries. And the language is in English
and for all the regions, our content is same
except for some regions we have mentioned few cities. Like UAE we have mentioned
cities like Arab Emirates, like Dubai, Sharjah,
when it comes to US, but overall the
content is the same. And we have more than 800,000
products on our website. And this year only
we have launched. And for other countries also,
even the language is not in English, we
have created locale like bg_bg for Bulgaria and all. And initially we have
submitted all the site map for all these regions as well. And first we have
experienced that Google started crawling our website
and almost 350,000 URLs got indexed. Then we have
started experiencing the indexing of the URLs. So we first thought it can
be the speed of the website and then we have
increased the speed. And then again we started
experiencing, OK, the URL got indexed. Later it changed,
then again it stopped. Then what we did, we removed
all the submitted URLs, and then we have the URL
structure like xyz.com/en. Then we submitted the URL. Now we are experiencing
the indexing of the URL, and when we submitted the
website structure like /en, we had experienced that all
the indexed URLs are going to the excluded list, and we
don't know what is the exact reason behind that. But what can be the reason? Is it because of since
the language is in English and we have created a
different URL structure? We don't know exactly. Now the URL, indexed URL
is showing only 160,000. JOHN MUELLER: OK. I don't know your
website so it's really hard to say, but overall
from what you've mentioned it sounds like you
have a lot of URLs, and you have those 70 different
country and language versions on top of that, so everything
is multiplied by 70. From my offhand assumption is
that this is just too much. So it's not that from a
technical point of view that we can't handle that. But essentially you're
submitting so much content and you have everything
multiplied by 70, essentially. And that means for us
that we start somewhere and we start
indexing some things, but there's almost
no chance for us to get through to everything. So usually what I recommend
in these kind of situations is start off with a very small
number of different countries and language versions and make
sure that they're working well, and then expand
incrementally from there. And in particular, if you have
a lot of English variations, then try to make
sure that you just have maybe one English
landing or English site, rather than all of the different
English country versions, which are essentially the same thing. Because if you
have fewer versions of the English content,
it's a lot easier for us to focus on that for
indexing and to treat that a little bit better when
it comes to ranking overall. So that's my general
recommendation [INAUDIBLE] So that's the thing [INAUDIBLE] With regards to
international versions, it's very easy to
take a website and say I will just make all
English language countries and create a hundred
different versions of website. But it just causes
so many problems and makes everything
in the whole crawling and indexing and
ranking cycle, makes everything so much harder. So that would be kind of
the direction I would head, is just start off a lot smaller
and then build out from there. RESHMI MOHAN: So
that means Google is considering us a duplicate? JOHN MUELLER: Sure. I mean, if these English
versions are all essentially the same thing, then
for the most part we will treat it as duplicates. And then it's kind
of hit and miss which version actually
ends up being indexed. So that's, I think, a
large part of the issue there is that we just see
all of these different copies of the same thing
and we don't know what you really want us to do. We have to focus on
a small part of it. We can't do everything
at once so it ends up causing almost more
problems for your website by having all of these
different versions. RESHMI MOHAN: That means we are
going in the wrong direction. JOHN MUELLER: Probably,
or moving too fast. I don't know. It's something
where it's very easy to take a really large
website that's doing well and say, oh, we will
just copy their system and take all of the different
English versions and language versions and do the same thing. But if you're not
in the situation of that large well
known website already, then it's very
different for you. And then it's a lot harder
to actually get to expanding. So I would try to pick one
English version and maybe one other language version
to start off with, and then expand from there. RESHMI MOHAN: Yeah. Because since we want
to target worldwide-- because it's an
e-commerce website and we want to target worldwide,
and we want to improve our SEO, we just targeted in this
way, creating different URLs and locating them in
different countries like that. So I think we can focus only
on the main domain instead of creating locally, right? JOHN MUELLER: Yeah. I, mean that's what I would do. Yeah. RESHMI MOHAN: And no need
of going for the en-- I mean, the URL
structure should not-- it should be like www.xyz.com
instead of the locale, right? JOHN MUELLER: You can
have the locale in there. It doesn't really matter. But again, I would make it
so that you primarily just have one English
version rather than all of the other variations
of English as well RESHMI MOHAN: OK. OK. Thank you. Thank you, Mr. John. JOHN MUELLER: Sure. Let's see. Gakushi. GAKUSHI NAKAMURA: Hi. JOHN MUELLER: Hi GAKUSHI NAKAMURA: I'm
new, and bear with me if my question
isn't clear enough. But we have a website
with about, say 20,000, 30,000 pages and it's
like a directory service, but we have unique content. So we put no index to probably
about 2/3 of those pages because we wanted to concentrate
what Google looks at. But after a month or so, only
less than 1% of those pages are indexed and we're getting
identified or discovered but not indexed for
almost all of our pages. So kind of scratching
our heads what we can do. We made a lot of tweaks and
it looks like internal linking is all right. We might be
restricting ourselves a little bit by the
canonical setting, but they don't look wrong. So in the end, we
kind of figured going through your
videos and stuff, it might be a site
quality issue, because there are predecessors
with similar content that are already indexed. And yet we do have
very unique content. The problem may be that that
unique content is not text. It's data. And it looks like a
lot of the quality is assessed by things that's
readable by human being. But our service
is really focused on a number that
is very valuable and we're just wondering
what we can do. Should we try to squeeze in
text which isn't actually central to what we do,
or are there things that we can do to tell
Google that it's actually valuable to people
who visit our sites? JOHN MUELLER: OK. I think in general having
numbers on a page is fine and it's something that
we do see as being part of unique content on a page. So just because a lot of
the content is numerical wouldn't necessarily mean that
we would see the whole page as being duplicated. So it's hard for me to
estimate what kind of site it is with regards to-- you mentioned it's a
directory type site. From a quality point of
view, I do think that matters quite a bit in terms of
how much we actually index from your website. So that's something where
I would probably still focus on that. If you're saying the site
is like 25,000 pages large, it feels like something that
we should be able to index if it's something that
we would consider to be a reasonable quality website. And when it comes to
the quality assessment, it is something where we do
look at the content of the page and we try to make sure
that it's not duplicate, but we also try to understand
the bigger picture of that page within the context of
the rest of the web. So that sometimes makes
it a little bit trickier. GAKUSHI NAKAMURA: Right. Just as a follow
up, we're getting discovered and not indexed
rather than crawled and not indexed for those 99%. Should we differentiate
between those two? Because our site is
not that big and this can't be a crawl budget
issue in my view. In that case, are those two
designations pretty much the same in that it's
just a quality issue? JOHN MUELLER: Again, I don't
know your website so it's hard for me to say offhand. But if it's something
where you're seeing the clean URLs being
listed in the discovered not indexed report,
essentially the URLs that you do want to have indexed, then to
me that sounds like it's really less a matter of Google can't
go off and crawl that many URLs. Because, again,
with 25,000 pages, most servers that
are reasonably sized can easily allow that kind of
crawling on a regular basis. And it's probably really more
a matter of our understanding of the overall website quality. And with larger websites or
if in the discovered report-- discovered not
indexed report, you see that there are lots of
different variations of URLs, like with parameters or
with upper or lowercase, those kind of
things, that can be a sign that the internal
linking is kind of messy and that we're having
trouble finding the right URLs to crawl. But if we're showing the right
URLs in the discovered not indexed report and it's a
reasonably small website, then to me that more
points in the direction of the overall site quality. GAKUSHI NAKAMURA: Right. So do you think we should
try to add text in there? What we show is really a
directory of companies, and we show what a
stock price means in terms of future
growth of that company. So it's a number,
but there's not a whole lot of readable
text that goes with it. It's just a number. Does this $20 stock mean
10% growth or 15% growth is what's valuable. We can add it. We do have a
description, but it's common to all those
companies and we've got to figure out
what to do if we were to squeeze in unique
text per each company. But should we head to that
direction, do you think? JOHN MUELLER: I don't
think the text will affect how we index the pages. So from that point of
view, it's something where if you see the
text affecting how users look at your pages
and are able to interact with your pages, and then sure. But that's more a matter
of trying to figure out what users are
actually looking for and where you can provide
unique value to your users. But just adding text
to pages I don't think would affect how we would
crawl and index those pages. If it's something where
you're providing numbers, I don't know, like
the stock numbers there, that's something
where I would also try to figure out what
you can do to make sure that what you're providing
is unique and provides value to users and do something maybe
along the lines of a user study to figure out,
what is it that we can do to make our website
such that users recommend it to other people as well? And that it builds
up almost like, I don't know, trust or something
from the user point of view. And a lot of times those are
not purely technical things that you change on a website,
where you change a design or you convert some of the
numbers into text, for example. It's really a matter of the
overall setup of the website. GAKUSHI NAKAMURA: Great. Thank you so much. JOHN MUELLER: Sure. Let me run through some of
the submitted questions, and then we'll get back to
the giant number of people who have their hands raised. Wow, so many today. Let's see. Does Google have any
trouble indexing sites that have a mobile
version on a subdomain, for example, example.com
and m.example.com? And then the question
goes into they're seeing a lot of pages
indexed without content. So from our point of
view, we don't have-- well, at least as
far as I know-- we don't have any problems
with m dot domains in general, in the sense that this is
one of the supported formats that we have for
mobile websites. We don't recommend
the m dot setup. So if you're setting
up a new website, I would try to avoid
that as much as possible and instead use a
responsive setup, but it is something
that can work. So if you're seeing this
regularly with your website that we're not able to index
your mobile content properly, then to me, that
would point more at an issue on
your website where when mobile Googlebot
is trying to crawl, it's not able to access
everything as expected. So that's the
direction I would head there to try to clean that up. The one thing that throws
people off sometimes with m dot domains is with
mobile first indexing, we switch to the m dot
version as the canonical URL, and it can happen
that we show the m dot version in the desktop
search results as well. So you also need to watch
out for not only redirecting mobile users from the desktop
to the mobile version, but also redirecting
desktop users from the mobile to
the desktop version. And again, that's
something if you have a responsive
design setup you don't have to worry about that. So it's another reason to
go responsive if possible. Would I be penalized if I
don't set the rel sponsored or rel no follow for
my affiliate links? Probably not. So from our point of
view, affiliate links fall into that category of
something financial attached to the links, so we
really strongly recommend to use this setup. But for the most part if
it doesn't come across as you selling
links, then it's not going to be the case
that we would manually penalize a website for
having affiliate links and not marking them up. It is a best practice and I
strongly recommend doing that, but it's not something where I'd
say we will go off and manually take action on these sites. A few months ago, we made a CMS
migration and our URL structure completely changed. All of our URLs execute 301
redirects to the new addresses and we have improved
technical indicators. After that, we realized
that our organic traffic dropped a lot immediately
after the URLs changed. Is that what we should expect? What time does it take? So when you move from
one domain to another, it's very easy for us to
just transfer everything from that domain to the new one. And that's something
that can be processed within almost like a
week or so in many cases. However, if you change
the internal URLs within your website,
then that's something that does take
quite a bit of time because essentially, we can't
just transfer the whole website in one direction. We have to almost
reprocess the whole website and understand the context of
all of the pages on the website first, and that can take a
significant amount of time. And during that time,
you will almost certainly see fluctuations. So my offhand guess would
be you will definitely see at least a month of
fluctuations there, perhaps even longer, especially
if it's a bigger change within the website itself. The other thing is when
you change your CMS, oftentimes things
that are associated with the CMS also
change, and that includes a lot of things around
internal linking, for example, and also the way that your pages
are structured in many cases. And changing all of
those things can also result in fluctuations. It can be that the final state
is higher or better than it was before. It can also be that the
final state is less strong than it was before. So that's something
where changing a CMS and changing all of the
internal linking on a website, changing the internal
URLs on a website, changing the design
of these pages, these are all
individually things which can cause fluctuations
and can cause drops and perhaps even rises over time. But doing that all
together means that it's going to be messy for a while. So that's something
where, on the one hand, waiting to see what
happens is something you almost have to do. But at the same time, I
would also recommend really from a technical
point of view, trying to understand all
of the differences between your new version of
your website and your old one and try to figure out which
of these changes are better and which of these
changes might be worse, and which things you
might want to clean up. Archive.org is a
great way of looking at your website in the past. So I would use that
to try to figure out what things looked like before,
how the internal linking was set up, what anchor tags
were there, what headings, what kind of text was
there, all of that. Another thing to watch out for
with these kind of migrations is oftentimes there's
embedded content that you don't
think about directly because it's not an HTML
page, and a really common one is images. And if you don't redirect
your old image URLs, then we have to reprocess
them and find them again new because we don't
have that connection between the old images
and the new ones. So if your site was getting a
lot of image search traffic, that can also have a
significant effect. And setting up those
redirects probably still makes sense even if you've
moved after a month or so. I don't know what
the timing here was. Then I have not a
technical question, but a career question. What is your advice
for someone interested in pursuing a career in SEO? What should they focus on if
they already started learning and are familiar
with the basics? How to go from there
to become great at SEO? I don't know. I don't get these kind
of questions often, so I don't have a
perfect answer lined up. From my point of view
what I like about SEO is that there's so
many different angles where people can dive in and
understand a little bit more. And oftentimes people
have interest in, I don't know, figuring out what
to do with regards to content, or trying to understand the
audiences that are involved, trying to understand the
technical details of a website, maybe even going into the
direction of JavaScript and developing things. And all of these are, I
think, really neat angles, and they're all
important for SEO. It's not that one of
these is going to go away and suddenly you'll be stuck. So my recommendation
there would kind of be to figure out which of these
angles you really enjoy doing and try to figure out ways to
do a little bit more of that. One of the things I've
recommended in the past which might also be
appropriate here is to take part in the different
Webmaster and SEO forums. So Google has, I think,
a help community as well and there are definitely
others out there as well. And the good part there
with all of these forums is that you see a lot
of different scenarios, and you run into
situations where you can dive in and try
to understand, well, what is the problem here
and how could I solve this. And whether or not you
actively take part in the forum and post your suggestions
there, at least the opportunity to look
at individual situations where you see, well,
there's a problem here. How can I try to
figure this out myself? I think that is really valuable. And that's really
important in the long run because a lot of times you will
see the same kind of problem come back over and over again. And if you understand
the patterns there, it's a lot easier for
you to jump in and say, well, this is the same
pattern as I've seen before, and that means I need to double
check these three or these five things first. So I think that's
always really valuable, to see in practice
a little bit more. But again, there are so many
different options and so many different directions
that you could take, it's hard to just say
you need to do this one thing to become better at SEO. Let's see. I have a situation
with a site where the main navigational
links is visually different from the mobile
and desktop versions. The mobile version is slimmer
and the desktop version has more links. Looking exclusively at crawling,
the desktop is more helpful. For technical reasons we
can't hide the desktop links in the source and the site is on
mobile first indexing already. Is there a chance
that Google might think I'm trying to game the
algorithms by keeping this more link-rich navigation even though
it's invisible to mobile users and bots? So I think overall,
this is a fairly common set up for responsive design,
in that you have both variations visible in the HTML. And from that point of
view, I don't see it as being super problematic,
but it's probably also not super clean because
you have to maintain both variations of the
UI within the same HTML, rather than having just
one variation in the HTML that you adjust depending on
the viewport size of the device. So from that point
of view, I don't think you would be penalized
for anything like this-- well, definitely not
penalized, because it's a very common setup. It's probably not
optimal, but it's also not something where I would say
need to jump in and fix that right away. So that's my assessment there. My question is about
dealing with outdated blogs on our platform. We have about 450
blogs, some of which are four to five years old
and therefore out of date and have almost no
traffic on them. Do you recommend deleting
them because they hurt our general search rankings? What's the best way? Delete all without
traffic at once and request index
deletion at Google, or do you recommend
step by step approach? So I think with
blogs you probably mean blog posts, so individual
pages, not whole sets of pages. Because I think if you have so
many different sets of pages it's probably a bigger change. But with 450 pages,
say, more or less, where you're saying, well, these
don't get a lot of traffic. Should I just
delete them or not? From my point of
view, probably that's something where you can just
make that call on your own. I don't see that
as being something where from an SEO
point of view, you would see a significant change
unless these are really, really terrible blog posts. The main thing, however,
I would watch out for is that just because
something doesn't have a lot of traffic
doesn't mean that it's a bad piece of content. It can mean that it's something
that just gets traffic very rarely, maybe once a year. Maybe it's something that is
very seasonal that overall when you look at it from a
website point of view, it's not very relevant,
but it's relevant, I don't know, maybe right
before Christmas, for example. So from that point
of view, I would say it's fine to go
through a website and figure out which
parts you want to keep and which parts you
want to clean out. But just purely
looking at traffic for figuring out which
parts you want to clean out, I think that's too simplified. But again, from an
SEO point of view removing 450 pages from a larger
website, that's tiny change and I wouldn't worry
about when you do that and how exactly you do that. Delete them whenever you
recognize that they're no longer valuable. Delete them all at once,
that's also an option. With regards to submitting
them with the removal tool as well in Search Console,
that probably wouldn't change anything because the removal
tool in Search Console just hides the page in
their search results, it doesn't actually remove
anything from indexing. So that's one thing
you don't have to do. But again, otherwise, I would
just think about which pages you want to keep, which
ones you want to remove, and go through it like that. Would a query string at the
end of an image source URL have a negative effect for SEO? We use it for cache invalidation
when an image is edited. So no, it wouldn't cause
issues with regards to SEO. But with images in
general, we tend to recrawl and reprocess them
much less frequently. So that means that if you're
regularly changing the image URLs linked in your
website, we would have to refind those again and
put them in our image index again, and that tends
to take a lot longer than with normal HTML pages. So from that point
of view, if you can avoid doing that too often
I would recommend doing that. If it's something that happens,
I don't know, very rarely, and where you're
saying, well, it doesn't really matter
too much how things are processed in image search. We don't rely on image search
for traffic to our website, then from that point of view,
that's totally non-issue. The thing I would
avoid, especially here with image URLs, is
that you embed something that changes very quickly. So something like a session
ID or just always today's date, because that
would probably change more often than we
would reprocess the image URLs, and then we would never be
able to index any of the images for image search. Let's see. Maybe I'll just go back
to more live questions since we have so
many people here. Bruno, over to you. BRUNO MOSCONI: Hi, John. JOHN MUELLER: Hi. BRUNO MOSCONI: Thank you
for this opportunity. John, we are from a news
website here in Brazil and we have a question
about a problem that we're going through in the
last few days in our website. We're going through a huge drop
in the delivery of our content through Google Discover. And now Google Discover is
our main acquisition channel, but in the last 10
days the delivery of our content
through Discover has dropped to practically zero. Our normal audience was
a thousand active users in real time, and now it's about
90 or a hundred active users. And we didn't change anything
technical or editorial. And our Search Console did
not report any problem. We have all Core Web
Vitals rated very high in our CrUX reports, it's
OK too, all above 80%. Our website is 100% AMP, and
we don't know what's happening. What do you think could
be happening with us? Can we do something to fix
this problem in Discover? We don't know what's happening. JOHN MUELLER: Yeah. I think it's always tricky
with Discover because it's-- at least what I
hear from people, it's very binary, in that
either you get a lot of traffic or you don't get a lot
of traffic from Discover. And that also means
that any changes there tend to be very visible. So my main recommendation
is not to rely on Google Discover for
traffic, but rather to see it as an additional
traffic source and not as the main one. When it comes to Discover
there are a few things that play in there. You mentioned some of
the technical things that I think are good practices. One of the things
that also plays in there is, for example, the
core updates also play a role. We recently had a
core update, maybe from a timing point of view
that matches what you saw there. So that's something
where if you do see an effect from
the core update, then I would double check
the blog post that we have about core updates with the
large number of tips and ideas that you could focus on. The other thing is with
Discover in particular, we have a set of
content guidelines that we try to stick to
in an algorithmic way. And depending on
the website itself, it might be something
where some of these content guidelines, your website
is kind of borderline. So for example, I don't
know the content guidelines all by heart, but
I think there is something around
clickbait-y titles or clickbait-y
content in general, or adult oriented
content, for example. And it might be that your
website is kind of borderline there with regards
to how we evaluate your website in that regard. And then it can also happen
that our algorithms say, oh, well, a large
part of this website is just clickbait or one
or the other categories that we list in the
content guidelines. And then we will be a lot
more conservative with regards to how we show the
website in Discover. So those are-- without
knowing your website, that's the direction I would head. On the one hand, the core
updates, think about that. On the other hand, the content
guidelines that we have. And then finally, I
would still make sure that you don't rely on
Discover for your business overall, because it can
change fairly quickly. And it's something where
often there are not pure technical reasons
behind those changes. BRUNO MOSCONI: OK, great. Thank you. JOHN MUELLER: Cool. Brian? BRIAN HARNISH: Hi, John. JOHN MUELLER: Hi. BRIAN HARNISH: Nice
to meet you finally. JOHN MUELLER: Yeah. BRIAN HARNISH: OK, I have
a couple of questions. First one. On a Reddit post
a few weeks ago, I believe, you mentioned that
having less than 30 pages would make Google consider the
website less authoritative, right? And I know that leaves it
open to SEO [? writing. ?] You have to have minimum 30
articles to rank, et cetera. But my question concerns
the other extreme. What about one page sites? JOHN MUELLER: I think you
can make good one page sites. So from that point of view,
I'm not too worried about that. I think the Reddit post,
as far as I remember, was something along the
lines, I created 30 blog posts and they're really good,
and therefore my website should be authoritative. And from my point of
view, you going off and creating 30 blog posts
does not automatically make your website authoritative. And especially for the higher
or the more critical topics, it's something
where you can't just create 30 blog posts on a
medical topic and then say, I am a doctor. I've written 30 articles. So that was the direction
I was headed there. And for a lot of
websites, it's not that you need to be
seen as an authority. You essentially put
your content out there. If you're a small business,
you're selling something. You don't need to
be an authority. And especially things
like one page websites, they're often very
focused on this one thing and you don't need to be an
authority to do that one thing, to sell, I don't
know, an e-book, or to give information about
opening hours for a business. It's like, it's
just information. So from that point of view,
having a one page website I think it's perfectly fine. With regards to starting
out with a one page website, I think that's fine. I would just think
about, well, where do you want to go from
there at some point? Maybe you do want to
create more pages, and try to find a way that
you don't paint yourself into a corner by
saying, well, I have to put everything on
one page all the time, but rather expand when
you see that it fits. BRIAN HARNISH: OK. The second question is actually
more of a hypothetical. So for international
SEO, say you have a site that is basically
generally well established. They have links going
to it, all that stuff. It's generally good
from an SEO standpoint. But at one point,
they decided to build their international URLs
and setup into one domain. Say, for example, it would
be something like media news United States as opposed
to the International URLs and the international setup. And aside from the
obvious, from things like links being combined, maybe
not being redirected properly, stuff like that,
what else would-- and say Google all of a sudden
decides to drop traffic 90% after that implementation. Assuming that everything
was done 100% correctly, which is likely not to
be the case on a larger site like that,
what would happen to cause Google to drop traffic
like that in such a scenario? JOHN MUELLER: It's hard to say. So usually what I would
do in a case like this is try to figure out if things
have settled down or not. Because if it's in
this flux period, it's really hard to determine
what things should be like. And then I would try to dig
into both individual pages and individual queries. So in Search Console, figure
out what the top 50 queries were and look at the top 50
queries now and see, are there certain queries
which have dropped, or is it more a matter of
everything overall dropping slightly? To try to figure
out, is this based on individual parts of the site,
or is it an overall change? And the same thing on
a page level as well. Often what I find when I
look at things on a page level is that
individual pages that used to get a lot of traffic
suddenly don't work anymore. They're 404, or they got
redirected incorrectly or something like that. And then it's something
where it's suddenly not clear what actually happened
there, in that you see, well, some of these top
traffic pages are gone now, then of course,
the overall traffic would be visibly
affected by that as well. But usually going and trying
to find ways to figure out what the details
were of that change, that helps to
understand a little bit better which direction
people should start looking. BRIAN HARNISH: Thank you, John. Thank you very much. JOHN MUELLER: Cool. Thanks. All right, David? DAVID RADICKE: Hi, Thanks. Last one in, I guess. So I posted this
also in the comments. So I have a small
website and it's a couple of hundred URLs only. It's a software company,
and its a small team producing content like white
papers and help articles and blog posts. And it has been going
well for a long time. And suddenly now in
November, the posted pieces, the published pieces
are not indexed anymore, not all of them. Which is very sad
because they're writing nice little
pieces for Black Friday, how to write a newsletter
for Black Friday or for Christmas, and then
we're sitting there and seeing that Google is crawling
them or discovering them-- we see that in the Search
Console-- but it's not indexed. So I tried everything. I looked at the technical
issues, the linking is good. So my question is, is
there a paradigm shift that Google is
saying, well, thanks for suggesting these new-- publishing these articles, but
we don't want it right now? Is this something new
that has changed recently? JOHN MUELLER: Not really,
at least not that I know of. I mean, I think what I
see a lot with regards to a lot of the indexing
questions that I get nowadays is from a technical
point of view, it's very easy for websites to
make websites that just work. You set up WordPress and then
essentially all of the SEO is done for you, it just works. And from our point
of view, this means that it's less often
a case that there is a technical
problem with a page that it doesn't get indexed. That means all of
the content that we get is essentially
technically OK and our systems have to be a
lot more critical with regards to the overall quality
of the website, the quality of the pieces
of content that we get. And then it's something where
additionally in Search Console, we give you all
of the information on things like discovered
and not indexed, or crawling but not indexed. And then suddenly you
see all of these problems and it seems like something
that people have to fix. So from that point of view, it
feels like it's normal for us to get a lot more of
these indexing questions just because, well, a lot
of content is kind of OK and we still can't index
everything on the web, so we have to make
a cut somewhere. That said, if you're really
looking in situations where you're seeing this
is a smaller website and the content is
really reasonable, and it's not something where
they're just rewriting news articles from other
people's sites, I would love to
have example URLs. DAVID RADICKE: I pasted them
actually in the comments. JOHN MUELLER: OK, perfect. Perfect. DAVID RADICKE: And I
would love to hear your-- because it's just not-- you
could say it's not a big deal. I understand that Google
cannot index everything. And we do rank for some of
these topics, for example, Black Friday 2020. We rank for that. And now we wrote a new
piece, "Black Friday 2021: What to do With Your Customers,"
and it's a handwritten piece. So the question would
be there, should we just lay off the content team? Because it's really
expensive to produce content. I mean, they're writing
all those pieces in a couple of days. I mean, those are nice ladies. They're sitting there
writing those content and then they aren't
getting indexed and we're not getting any
traffic from Google for that. So basically the management
is asking me, well, why should we do that? There's no sense in producing
good content if we don't get that part of
the traffic that we get from Google normally,
because Google says, well, we just don't
want it right now. So it's tricky, isn't it? JOHN MUELLER: Yeah. I mean, that's why these
examples are really useful. Because we do bring them
back to the indexing teams and say, well,
what is wrong here? Why aren't we picking this up? This is something reasonable. We should be doing a
better job at that. And especially when things are-- DAVID RADICKE: --not
good or there's something technically wrong,
but I just don't see anything. And again, it's not a site
with millions of pages, but we have 500 pieces, I think,
and they're all handwritten. It has always
worked, just suddenly in November it stopped,
during the time of the core update
so I was afraid that Google's busy with
other things right now. JOHN MUELLER: It shouldn't be. But, I mean, having
these kind of examples is really valuable for me,
because going to the team and saying, oh, people are
complaining that content is not being indexed and I don't
have any examples for you, then they'll be like,
well, we can't do anything. DAVID RADICKE: --content I
have the OK from the company to use this in
public, so it's OK. JOHN MUELLER: OK, cool. I mean, you can
also send it to me privately if there's anything
that you or anyone else runs into. DAVID RADICKE: Great. What's the best way to send
it to you, email or Twitter? JOHN MUELLER: Twitter
is probably easiest and for the most
part, people can ping me and ask to be followed
so they can send me a DM if that makes it easier. DAVID RADICKE: All right. Thanks. JOHN MUELLER: Cool. All right, let me
take a break here with regards to the recording. I can be around a
little bit longer, but not as long
as usual this time because we have more meetings. But thank you for joining. Thank you for all of
the questions so far and I hope we can get through
some of the remaining questions as well. People still have
their hands raised. If you're watching this
recording on YouTube, feel free to submit questions
for the next sessions which I'll be setting up as well. I don't know how the
timing of the next sessions will be with regards to
holidays and things like that, but we'll figure something out. Cool. And with that, let me
pause the recording here. Just a second.
