Let’s talk about accessibility

I think most people, if they're tasked with accessibility, they're probably in a situation


Let’s talk about accessibility

like you are where there's something existing and someone is kind of like, can we make this


Let’s talk about accessibility

more accessible?


Let’s talk about accessibility

Lizzie, can you figure out a way to like, what is it that we need to do to make it more


Let’s talk about accessibility

accessible?


Let’s talk about accessibility

And I'm sure that that is the most probably common scenario that somebody who's working


Let’s talk about accessibility

in.


Let’s talk about accessibility

Well yeah, tasked or like you've discovered it.


Let’s talk about accessibility

Like maybe people are listening to this podcast and they're like, oh yeah, I should look into


Let’s talk about accessibility

this.


Let’s talk about accessibility

Yeah, for sure.


Let’s talk about accessibility

I think since we're talking about websites, I mean the way that I might approach it, I


Let’s talk about accessibility

mean for example, and this is just me, but I happen to be colorblind.


Let’s talk about accessibility

So when I first come to a website, it's fairly easy for me to find the gotchas of not having


Let’s talk about accessibility

strong enough color contrast.


Let’s talk about accessibility

And other examples of that are, you know, you go to websites and they might have a massive


Let’s talk about accessibility

hero image and there's just text sort of overlaid on top of it.


Let’s talk about accessibility

That makes it difficult to see if you don't have a solid background behind the text.


Let’s talk about accessibility

You know, you have sometimes some very, very light text.


Let’s talk about accessibility

There might be some decisions there that are more aesthetically leaning and aesthetics


Let’s talk about accessibility

sort of steamrolled the accessibility.


Let’s talk about accessibility

So you know, you might have like a really light text or really gray text or you might


Let’s talk about accessibility

have text that sort of appears as you scroll or something like that.


Let’s talk about accessibility

And I guess that that in particular would be okay.


Let’s talk about accessibility

But you know what I mean?


Let’s talk about accessibility

Like something that's just like, these like borderline things that are like trendy to


Let’s talk about accessibility

do from a design perspective, like the light gray thing that you're talking about.


Let’s talk about accessibility

Like I've seen that.


Let’s talk about accessibility

Sure.


Let’s talk about accessibility

So many people choosing like very deep black for the font.


Let’s talk about accessibility

Yeah, perhaps.


Let’s talk about accessibility

Simral, that's a good word.


Let’s talk about accessibility

Yeah, exactly.


Let’s talk about accessibility

But even beyond that, I think one thing that I always look for is also spacing, right?


Let’s talk about accessibility

I like to think there's a little bit of a push happening in terms of just cognitive


Let’s talk about accessibility

accessibility in the space and making sure that what you might call chunking your paragraphs


Let’s talk about accessibility

and spacing them out and bullets are great, but just sort of making sure that your text


Let’s talk about accessibility

is succinct and that you don't just sort of put the user in front of giant blocks of text


Let’s talk about accessibility

that they have to read through because whether they're sort of neurodiverse or not, they


Let’s talk about accessibility

probably won't read a giant chunk of text.


Let’s talk about accessibility

So beyond just sort of color contrast and the readability of the font and stuff like


Let’s talk about accessibility

that, you want to be able to space things out and make them consumable, so to speak.


Let’s talk about accessibility

And that's one space that I might look to.


Let’s talk about accessibility

That's fairly easy to understand.


Let’s talk about accessibility

And anybody who owns a website, whether you know it's a coded one or one where you are


Let’s talk about accessibility

actually coding it up or it's just sort of one of those plug and play type of websites


Let’s talk about accessibility

where you're just editing the text.


Let’s talk about accessibility

I think that's something that everyone can kind of do.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

I mean, you have access to this even when you're writing an internal document or something


Let’s talk about accessibility

like a Google doc.


Let’s talk about accessibility

I'm writing a project thing and it's just for my team to understand what I'm working


Let’s talk about accessibility

on, even emails that we write, chunking things out to be consumable and scannable so that


Let’s talk about accessibility

you could see sort of like, yes, you start with the visual thing, but also having it


Let’s talk about accessibility

read to you and making sure that we're not just going on and on in some long paragraph


Let’s talk about accessibility

with multiple ideas.


Let’s talk about accessibility

It can be hard to then understand where am I, where is this thing even going, what kind


Let’s talk about accessibility

of a document am I in, a page, what have you.


Let’s talk about accessibility

Are there cues to tell me that I should continue reading?


Let’s talk about accessibility

I don't know.


Let’s talk about accessibility

Especially if it's longer paragraph texts like that.


Let’s talk about accessibility

And then when you think about localization or translation of that content and then things


Let’s talk about accessibility

becoming longer in other languages, so translated to like German or something and then your


Let’s talk about accessibility

heading is even longer.


Let’s talk about accessibility

So starting out with writing something that is shorter, it benefits in so many more ways,


Let’s talk about accessibility

I think.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

But that's probably where we overlap more with the writing and spacing things out for


Let’s talk about accessibility

sure.


Let’s talk about accessibility

For sure.


Let’s talk about accessibility

Okay.


Let’s talk about accessibility

So you would look at things visually.


Let’s talk about accessibility

You've got like an inbuilt built in tester.


Let’s talk about accessibility

So see immediately what's going on with the website.


Let’s talk about accessibility

What other kind of things would you look at?


Let’s talk about accessibility

So or listen to?


Let’s talk about accessibility

I wouldn't necessarily look at everything.


Let’s talk about accessibility

Would that be the next thing?


Let’s talk about accessibility

Using other senses?


Let’s talk about accessibility

I mean, another thing, and I'm just trying to keep it accessible in itself.


Let’s talk about accessibility

Like what are some really easy things that anybody can kind of just start to do?


Let’s talk about accessibility

But yeah.


Let’s talk about accessibility

Another example besides the text or like the graphical images and contrast and things that


Let’s talk about accessibility

are visible per se, you can kind of just start to hit your tab key, you know, if you use


Let’s talk about accessibility

a keyboard.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

Just see where it goes.


Let’s talk about accessibility

Ideally, it moves in sort of, you know, in an English website, it would move left to


Let’s talk about accessibility

right, top to down in the way that we read, right?


Let’s talk about accessibility

Yes.


Let’s talk about accessibility

And it's not necessarily perfectly like that.


Let’s talk about accessibility

That's not a be all end all it has to be that way.


Let’s talk about accessibility

But generally speaking, that would be sort of an intuitive way for your flow to move


Let’s talk about accessibility

your keyboard navigation.


Let’s talk about accessibility

And if you do start to, so let's say you go to a website and you hit the tab key, a lot


Let’s talk about accessibility

of accessibility minded sites will often in that first keystroke of the tab key will have


Let’s talk about accessibility

a skip links menu, what we call skip links menu.


Let’s talk about accessibility

So oftentimes, the most common function of that is to be able to skip to the main content.


Let’s talk about accessibility

So you can kind of skip past all of the navigation and the top bar and anything that's sort of,


Let’s talk about accessibility

I guess, persistent throughout the site experience and into the main content as it's been defined


Let’s talk about accessibility

by the developer of that page.


Let’s talk about accessibility

So that's really useful.


Let’s talk about accessibility

And then oftentimes, you'll find other functions within that skip links menu.


Let’s talk about accessibility

So for example, you hit tab, and then it's like skip to main content, and then you hit


Let’s talk about accessibility

tab again, and then some other function will appear.


Let’s talk about accessibility

Maybe it's you want you can jump to some sort of keyboard shortcuts menu, or maybe you can


Let’s talk about accessibility

jump to give accessibility feedback or something like that, right.


Let’s talk about accessibility

And then it will naturally progress to whatever the next tab stop is the next one in the next


Let’s talk about accessibility

one.


Let’s talk about accessibility

But that's another way that you might sort of implement something accessibility minded


Let’s talk about accessibility

on your website is having that skip links menu and also ensuring that the flow, as we


Let’s talk about accessibility

call it, of the tab stops, making sure that that's intuitive.


Let’s talk about accessibility

Right.


Let’s talk about accessibility

So you're not like jumping around from like the heading to then now we're out in the top


Let’s talk about accessibility

level navigation or something.


Let’s talk about accessibility

Exactly.


Let’s talk about accessibility

The order doesn't make sense.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

So at this point, would you be in the screen reader tabbing or like you're saying just


Let’s talk about accessibility

hitting tab on the keyboard?


Let’s talk about accessibility

Like we're not even haven't installed anything or we're in like voiceover mode, nothing like


Let’s talk about accessibility

that.


Let’s talk about accessibility

Yeah, I would say it should work without the screen reader.


Let’s talk about accessibility

And we can talk about the screen reader next.


Let’s talk about accessibility

But yeah, I would say let's Yeah, so I just having like a good focus, right, having like


Let’s talk about accessibility

a visible good contrast keyboard focus on whatever element it is that that focus is


Let’s talk about accessibility

on is important.


Let’s talk about accessibility

So you can kind of begin to, you know, get a sense for how well executed those types


Let’s talk about accessibility

of things are without even knowing anything about a screen reader.


Let’s talk about accessibility

Yes, because that's a learning curve there too is like picking a screen reader and installing


Let’s talk about accessibility

it and learning to use that device with things that are just like on the web or like using


Let’s talk about accessibility

your computer and setting it up can be even a hurdle to get started there.


Let’s talk about accessibility

Do you have a preferred screen reader or something that you would recommend that people test


Let’s talk about accessibility

out?


Let’s talk about accessibility

Yeah, so I would say the screen reader you should use is the one that's probably already


Let’s talk about accessibility

available to you.


Let’s talk about accessibility

Yes.


Let’s talk about accessibility

So if you use Chrome, we have Chrome vox, if you use an Android phone, it should have


Let’s talk about accessibility

talkback if you use an Apple device, it'll have voiceover.


Let’s talk about accessibility

So a lot of different companies, I've sort of listed out a browser and like operating


Let’s talk about accessibility

systems that have screen readers available to you.


Let’s talk about accessibility

There's also the third parties, the the NVDAs and the jaws and those companies who have


Let’s talk about accessibility

screen readers that are actually based on the data that I've seen have the most amount


Let’s talk about accessibility

of users, those third parties.


Let’s talk about accessibility

But I think that just using the one that's available to you is going to be easiest, especially


Let’s talk about accessibility

if you're first just starting out and figuring out how it is that you turn it on.


Let’s talk about accessibility

There's generally I would probably just do a really quick search, it'll be right there


Let’s talk about accessibility

at the top, whatever it is that you're looking for.


Let’s talk about accessibility

So you know, for example, Alex screen reader plus whatever device you're on, like I'm having


Let’s talk about accessibility

a Mac, how do I turn on the screen reader, that kind of thing?


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

And oftentimes, those on off switches, those are very easy to access.


Let’s talk about accessibility

So what's a good example?


Let’s talk about accessibility

I think on mine, I've been using voiceover just because I have a Mac setup.


Let’s talk about accessibility

And there's like a keyboard shortcut to turn it on.


Let’s talk about accessibility

And the first time I use it, it took me aback, I think because for me, I'm using things with


Let’s talk about accessibility

my eyes mostly, and then to have information overload on the ears is a completely different


Let’s talk about accessibility

experience.


Let’s talk about accessibility

So like having like the speed read to you, like things that you're not normally used


Let’s talk about accessibility

to experiencing the world this way, I think is a good way to sort of learn the other use


Let’s talk about accessibility

cases for sure.


Let’s talk about accessibility

Totally.


Let’s talk about accessibility

I mean, I think I've seen some like sort of shortcuts to turning on your screen reader


Let’s talk about accessibility

be as simple as hitting your power button three times or something like that, where


Let’s talk about accessibility

you're just like, Oh, that's really easy.


Let’s talk about accessibility

Yeah, but yeah, and probably something that you get used to, like how it navigates, like


Let’s talk about accessibility

you probably use that same thing, just like how we would be like, I'm an iPhone user,


Let’s talk about accessibility

or whatever device you sort of get used to, whatever the shortcuts are, and then you just


Let’s talk about accessibility

tend to use that device again and again.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

And going back to what you said earlier, it is jarring, right?


Let’s talk about accessibility

If you've never heard a screen reader before, I would say that if you're getting started,


Let’s talk about accessibility

bring some patience, right?


Let’s talk about accessibility

Make sure that your volume is sort of in your control easily.


Let’s talk about accessibility

And if it is sort of jarring, I've seen it happen.


Let’s talk about accessibility

Or maybe I've even done this before where I was starting out and I'm just kind of like,


Let’s talk about accessibility

I can't, it can't feel too much.


Let’s talk about accessibility

It's a sensory overload if you're not used to it.


Let’s talk about accessibility

Yes.


Let’s talk about accessibility

And if you don't know what the default settings are, like the volume, like the devices, like


Let’s talk about accessibility

reading it too loud, it can Yeah, take you back or if you're like in a public setting


Let’s talk about accessibility

or something, and then the devices now reading out loud and you didn't have headphones in


Let’s talk about accessibility

or like you're being prepared for Sure.


Let’s talk about accessibility

These kinds of things, I guess.


Let’s talk about accessibility

And then the preferences for speed because you tend to also then maybe want it to once


Let’s talk about accessibility

you get acclimated, you're like, I can listen to this faster, or I can navigate faster.


Let’s talk about accessibility

But in the beginning, it might be like you're reading too fast for my ears to be paying


Let’s talk about accessibility

attention.


Let’s talk about accessibility

Sure.


Let’s talk about accessibility

When you're learning, I guess.


Let’s talk about accessibility

Yeah, mine is super slow.


Let’s talk about accessibility

It's like a bedtime story.


Let’s talk about accessibility

It's just like you nudge it down.


Let’s talk about accessibility

Yeah, I nudge it way down because I want to understand pretty thoroughly and I'm proficient


Let’s talk about accessibility

enough where I can just skip something if it's going on.


Let’s talk about accessibility

And anyone who uses a screen reader somewhat regularly will be able to know how to navigate


Let’s talk about accessibility

in such a way that they're getting out of it what they want.


Let’s talk about accessibility

But it can be frustrating if you don't know how to jump around, you're kind of stuck and


Let’s talk about accessibility

you don't know how to navigate to the element that you want to get to.


Let’s talk about accessibility

And you don't know how to skip to an element that you want to get to and you're sort of


Let’s talk about accessibility

find yourself to say the website isn't particularly accessible.


Let’s talk about accessibility

Exactly.


Let’s talk about accessibility

Right.


Let’s talk about accessibility

That's why you're there.


Let’s talk about accessibility

Like you don't know is it me?


Let’s talk about accessibility

Is it the tool?


Let’s talk about accessibility

Is it the website that's bad?


Let’s talk about accessibility

Like do I not know how to use this thing?


Let’s talk about accessibility

Or have I found something that could be improved?


Let’s talk about accessibility

It's sort of hard to know like, which one is the culprit?


Let’s talk about accessibility

I guess.


Let’s talk about accessibility

Yeah.


Let’s talk about accessibility

Especially when you're learning.


Let’s talk about accessibility

So I think those are some fundamental basics of the screen reader, setting your preferences,


Let’s talk about accessibility

bringing some patience.


Let’s talk about accessibility

I think those are some good steps to getting started with assistive technology and just


Let’s talk about accessibility

trying to make it easy on yourself too.


Let’s talk about accessibility

You don't have to go and download some, some even cost money.


Let’s talk about accessibility

You want to use what you have, I guess, if you're just getting started, if that's your


Let’s talk about accessibility

preference, if for some reason that's just easier for you.


Let’s talk about accessibility

But yeah, if you just keep those things in mind, then your introduction to assistive


Let’s talk about accessibility

technology will be smoother.


Let’s talk about accessibility

And would you say that this is the first thing that people should do if they wanted to get


Let’s talk about accessibility

started with accessibility?


Let’s talk about accessibility

What would be one thing that you would call people to?


Let’s talk about accessibility

Should they test their website out first or should they do some reading?


Let’s talk about accessibility

Would there be like a resource?


Let’s talk about accessibility

What would be the one thing that people should do if they wanted to start thinking about


Let’s talk about accessibility

accessibility?


Let’s talk about accessibility

I think if I have to choose one, it would probably be some sort of education based thing.


Let’s talk about accessibility

I was going to say, you know, if you really are a hands-on learner, it's maybe easier


Let’s talk about accessibility

for you to just learn how to turn on the screen reader and just go from there.


Let’s talk about accessibility

Yeah, the experience you sort of realize like immediately, like this is not good.


Let’s talk about accessibility

Or if you're just even looking through your site, having the experience can jump out at


Let’s talk about accessibility

you sometimes stronger than reading like a document potentially.


Let’s talk about accessibility

But also if you don't know what to look for, how do you know if it's bad?


Let’s talk about accessibility

Yeah, exactly.


Let’s talk about accessibility

I think if you have the patience and doing some searching or reading a book or kind of


Let’s talk about accessibility

like understanding accessibility from that standpoint, or maybe understanding it from


Let’s talk about accessibility

a more general standpoint, instead of just jumping right into the technical side or the


Let’s talk about accessibility

digital side of accessibility, accessibility certainly doesn't just exist in the digital


Let’s talk about accessibility

space.


Let’s talk about accessibility

It's a much larger concept than that in the physical world as well.


Let’s talk about accessibility

But yeah, I think educating yourself as much as you want to and then just diving in hands-on,


Let’s talk about accessibility

those are both, I would say, essential to being able to make progress in the accessibility


Let’s talk about accessibility

And Danny, where can people find you if they wanted to learn more about accessibility,


Let’s talk about accessibility

ask you questions or just generally look more about your background?


Let’s talk about accessibility

Sure, they can find me on LinkedIn.


Let’s talk about accessibility

Amazing.


Let’s talk about accessibility

Do you know the URL profile name for your LinkedIn or is it something embarrassing?


Let’s talk about accessibility

No, it's not embarrassing, but it is kind of messy.


Let’s talk about accessibility

It's like in slash Danny dash Farah dash 36749A8.


Let’s talk about accessibility

Wow, wow.


Let’s talk about accessibility

Okay.


Let’s talk about accessibility

All right.


Let’s talk about accessibility

So we will put the link in the description and then you can just click it to learn more


Let’s talk about accessibility

about Danny.


Let’s talk about accessibility

And Danny, thank you so much for joining us here today to talk about accessibility.


Let’s talk about accessibility

It's been really interesting for me and I hope you, the listeners, have found it interesting


Let’s talk about accessibility

as well.


Let’s talk about accessibility

Yeah, thank you so much, Lizzie.


Let’s talk about accessibility

I had a great time chatting with you.


Let’s talk about accessibility

Me too.


Let’s talk about accessibility

And next time on Search Off the Record, we'll be taking a look at crawl budget and what


Let’s talk about accessibility

does that mean for your website?


Let’s talk about accessibility

And now that I have you here off, off the record, I wanted to see if you would give


Let’s talk about accessibility

us a design review of our Search Off the Record podcast elements.


Let’s talk about accessibility

It's sort of an auditory review for our listeners.


Let’s talk about accessibility

So right now we're looking at, what we have right here is our title cards that we have


Let’s talk about accessibility

on YouTube to sort of show the episode title, the number of the episode and what it is.


Let’s talk about accessibility

And it sort of says Search Off the Record at the top, our banner, and then text that


Let’s talk about accessibility

says Listen to the Podcast.


Let’s talk about accessibility

I think that's probably bad that I can't see it from the distance that I'm looking at it


Let’s talk about accessibility

right now.


Let’s talk about accessibility

And I wanted to get your sort of opinion.


Let’s talk about accessibility

If you could walk us through, is this okay?


Let’s talk about accessibility

Or is it bad?


Let’s talk about accessibility

Should we fix anything?


Let’s talk about accessibility

I would say just going back to my first comments about contrast.


Let’s talk about accessibility

It looks like there's a good amount of lighter contrast here.


Let’s talk about accessibility

There's also some pretty small text in the bottom left corner, you know, where it says


Let’s talk about accessibility

episode 40 also.


Let’s talk about accessibility

I think those things could all be improved.


Let’s talk about accessibility

I guess my approach is if it's not accessible, then not everybody I think thinks this way.


Let’s talk about accessibility

Some people think some things are just sort of decorative by nature.


Let’s talk about accessibility

I kind of feel like maybe we should be going towards a space where everything is accessible


Let’s talk about accessibility

as opposed to just being like, yeah, that's just sort of decorative.


Let’s talk about accessibility

We don't have to make that accessible.


Let’s talk about accessibility

So like anything that's too small to see or understand easily, like all the icons or the


Let’s talk about accessibility

colors.


Let’s talk about accessibility

So probably all the things that we're looking at here is fairly all too small, and I'm seeing


Let’s talk about accessibility

light gray, which we talked about earlier.


Let’s talk about accessibility

So contrast and size.


Let’s talk about accessibility

Yeah, I think so.


Let’s talk about accessibility

Okay, I think we will take all of this feedback back to the team and see what we can come


Let’s talk about accessibility

up with.


Let’s talk about accessibility

And that's the end of this little snippet here.


Let’s talk about accessibility

We've been having fun with this podcast, and I hope you, the listener, have found it both


Let’s talk about accessibility

entertaining and insightful too.


Let’s talk about accessibility

Feel free to drop us a note on Twitter at Google Search C or chat with us at one of


Let’s talk about accessibility

the next events we go to if you have any thoughts.


Let’s talk about accessibility

And of course, don't forget to like and subscribe.


Let’s talk about accessibility


English Google Webmaster Central office-hours from April 9, 2020

All right.


Hi, everyone.


Welcome to this Google Webmaster Central Office Hours Hangout.


My name is John Mueller.


I am a webmaster trends analyst here at Google in Switzerland.


And part of what we do are these Office Hour Hangouts


where people can join in and ask their questions all around web


search.


There are a bunch of questions that were submitted already.


Not a ton, but a few.


But if any of you want to get started


with a question of your own, you're


welcome to jump in right away.


I could actually start off if that's OK.


Perfect.


Yeah.


I have a question regarding some weird Google bot activity


that seemed to not be the only one who's experienced this.


Sort of late March, some of our sites got 20 to 30 times more


bot activity, almost to the extent


we had to go in and sort of limit Google bot for a while


because it was hammering our servers so hard.


Any input on what was going on, if it's something


that shouldn't have happened?


I don't know.


So someone else mentioned this, I think,


with regards to early April.


So kind of the same period, I guess.


I took a quick look at their setup


and the general bigger picture view.


And overall, it's not that Google bot


is crawling a lot more.


So I think what is happening is just on some sites,


we happen to find a lot of URLs.


And we started crawling those more.


And on other sites, we're just crawling normally.


So as far as I know, I don't think anything really


changed in the setup that we use there.


So in the case of the other sites


that I looked into a little bit more, what was happening there


is that for some reason, we were running into some, I think,


some forms on the site which we were submitting,


which Google bot sometimes does.


And that ended up creating a gigantic mess of URL


parameters.


So we found millions of new URLs.


And we thought, well, maybe we should check these URLs out


and crawl them to see what comes up.


And that led to us kind of crawling a ton of URLs.


Because from our point of view, it


seemed that the server was able to handle the load.


So we just decided to crawl a lot more there.


Usually, we didn't have any problems


that it couldn't handle it.


Basically, it's an automated setup


where more servers are added into the cluster on needs.


So all of a sudden, the price went up terribly.


Because my suspicion was that you started following


the nofollow links.


Because this is an e-commerce site with tons of filters


that have been nofollowed forever.


And maybe you started following those


and finding a lot of new interesting parameter URLs


that way.


I don't think that would be that visible.


So it feels like from purely from the nofollow point of view,


I don't think that would be happening.


From the URLs that were being crawled,


would those match the ones that you tend to link like that?


Or was it hard to check in the logs?


Yeah, I actually don't have access to the logs,


unfortunately.


So I can't say for sure.


OK.


If you can send me a link to your site,


I'm happy to take a look afterwards and see


if there's something weird happening with those parameter


URLs or if this is just Googlebot being super curious.


All right, thanks.


Sure.


Yeah, tell me.


Tell me.


I'm listening to you.


All right.


Any other questions before we get started?


I was like, someone's on the phone somewhere else.


Otherwise, I'll just jump in through some of the questions


that were submitted.


And you're all welcome to kind of jump in between


if there's something you want to add


or if you have a related question that you'd like to go through.


Let's see.


Recently in January, Google released product features


in the US search results and also opened up


the merchant account for unpaid users as well.


Is there any advantage for non-US businesses


that SEOs can take advantage of?


So I don't know all of the details around the product


shopping side.


My understanding is that the merchant center is something


that you can use regardless of whether you're


using the paid part of product search or not.


So that might be something to check out.


I don't know what the future plans are in this regard.


Usually what happens when we launch something in the US


first, it's more to kind of get a feel for how


things are working.


And then over time, we end up expanding that


to other regions, other countries, other languages.


I don't know if particularly with product search,


there might be legal or policy reasons involved that make this


a little bit trickier or not.


With some search features, that's the case.


With other search features, it's more a practical nature


that we kind of need to test in a small scale


first before we open things up for everyone.


So just purely from my point of view,


with regards to search features like this that are currently


US only or English only, my recommendation


would be to take a look at them and think


about how they might make sense for your site,


even if you're not in the US.


And if you can implement something


that takes advantage of features like that,


then you'll be ready when things open up a little bit more.


I don't think we can ever really promise ahead of time


when we open up which features and which regions


or which languages.


But in general, our plan is to take features and have them


as broadly used as possible.


I was wondering if there's any best practice for URL structure


of AMP pages.


If you use a subdomain or a folder in upper level,


you can have better possibility for analyzing


on different tools.


But I was wondering if there is any benefit for Google


if you put your AMP pages under the root domain instead


of a subdomain or parameters.


So from Google's point of view, I


think the only criteria that is critical for AMP pages


is that it has to be on the same domain.


So if you have it in a subdomain or a subdirectory, all of that


is perfectly fine.


In general, with these kind of related pages,


I would recommend doing them in a way that works best for you.


So something where it's easy for you to track,


it's easy for you to monitor, it's


easy for you to maintain that setup.


So if it works well for your CMS,


for example, if it works well for your server setup,


then that's a good choice.


I wouldn't worry about is there any kind of Google tweak


that makes a big difference with regards


to these alternate URLs.


The other thing I would watch out


for with these alternate URLs is that you don't change


the patterns too often.


So ideally, if you pick something


like a subdirectory or a subdomain,


then try to keep that for as long as you can.


It's not quite the same as if you change your primary URLs


with regards to search.


But any time you change URLs in general,


then we kind of have to reprocess that.


And if you're changing the alternate URLs that


are associated with every page on your site,


then that means we have to reprocess a lot of URLs


to kind of understand that new setup.


So pick subdomain or subdirectory or parameters if you want,


whatever works best for you.


And try to keep that setup ideally for the long run.


I run a site about smartphone photography occasionally,


like once every three months I write a guest post


on another topically related sites.


These guest posts are about topics


that I don't cover on my own website.


And these guest posts contain a link to my website in the end.


At the bottom of the home page of my website,


I have a section named In the Media, where I link back


to these guest posts.


Currently, these are follow links.


Does this harm my SEO?


What's the best practice for linking back to guest posts


in order to not harm SEO?


So in general, with guest posts, you're


placing the link essentially on another site.


So in general, that would be considered an unnatural link.


So I would recommend using nofollow for that.


So if you're using a guest post, linking back to your site,


then use nofollow links for that.


I think at the scale where you're doing this


at the moment, where it's like, I don't know,


once every couple of months, I don't think anyone


from the web spam team would look at that and say,


oh, this site is maliciously abusing these guest post links


and trying to artificially increase their site's ranking.


So I don't think that's something you urgently


need to worry about.


But in general, for guest posts, you should use nofollow links.


With regards to linking back to that site


to kind of highlight where your content has been shown,


you can do that however you want.


So you can use nofollow links if you want.


But I think a normal follow link is also perfectly fine for that


since you're essentially showing kind


of where all of your content is being published.


And that's pretty cool.


With regards to SEO, I think at the scale


where you're doing it, you probably


wouldn't see any advantage or disadvantage.


With regards to kind of building a bigger


audience for your website, that might be a good thing


to kind of talk about related topics on other websites


and maybe interest some users into visiting your site


as well.


So that's, from my point of view, that sounds kind of good.


But purely from an SEO point of view,


I don't think you're doing kind of a lot in positive or


negative direction there.


We're running an online shop.


Does it make sense to have long descriptions on the product


pages, or is it a problem to have similar content


on the product pages?


We're selling products in different thicknesses for these,


and we're using the canonical tag.


We also have products with similar characteristics.


Should we focus on category pages for longer information


about our products?


Ultimately, that's kind of up to you.


So you can.


So I think the general approach that you're using here


is that you have a canonical to a preferred


version of your product.


And I think that's a good idea, because that


makes that preferred version a little bit more


visible for your site overall.


And that's usually a good thing, because then when


we look at your site, we understand which are kind


of the primary pages to focus on.


We can highlight these a little bit better in search.


They can rank a little bit better.


That's all good stuff.


With regards to the descriptions,


if the alternate versions of those products


have the same or very similar description and a canonical


link back to the primary version of the product,


then that doesn't matter at all, because we


will try to focus our indexing on the primary version


of the product.


So if you have an item that's available in different colors


or different thicknesses, different sizes,


and essentially it's all the same product,


it just has different URLs, and you have a canonical


to a preferred version there, we'll


focus our indexing on that preferred version.


And essentially what you have on these alternate versions


is less critical for us.


In many cases, we won't even index that content at all.


So it doesn't matter for us if that's duplicate or not.


Even if we were to index those alternate versions of a product


and they had a similar description


or the same description, that wouldn't be a problem


from our side of things.


So in particular, it wouldn't be seen as spam,


because this is just the same product.


It's just different URLs, different variations.


It wouldn't be seen as low quality content.


It would just be seen as duplicate descriptions.


We would understand the pages are different,


but some of the content on those pages are the same.


And when someone searches for something generic that's


in that kind of shared piece of content,


then we'll try to find the best matching


page within your website.


That's essentially not something negative for your website.


It just means we have all of these pages indexed.


We know there's a lot of duplication


across these pages, and we'll try to show the right one


in the search results.


In general, as a best practice, I


think the setup that you have is great.


So picking a canonical and saying,


this is the version of the product


that I really want to have indexed,


that's kind of the optimal solution,


because then we can focus on that primary version


of the product.


And with regards to amount of text and descriptions


you have on these pages, that's totally up to you.


I would make sure that you have things there


that make it easy for users to find your content.


So in particular, if you notice your users are


using technical terminology to search for your products,


then make sure you use those technical words.


If they're using less technical terminology to search,


then make sure you're covering that as well.


So kind of make sure that your content matches what


your users are looking for.


And then it doesn't really matter how long


or how short that content is.


Can replacing, redirecting internal links by the final URL


improve anything?


What are the cons if we have a lot of Ahrefs on our site,


which are not the final URL?


So our general recommendation is to link to the destination URL.


That's, on the one hand, a matter of speed for users.


On the other hand, a little bit of an optimization


on our side for ease of crawling and picking


the right URL for indexing.


So for users, obviously, if you click on a link


and it has to redirect, then that's


kind of an extra server trip that has to take place.


And it slows things down a little bit.


And often, it's something that's easy to fix.


So from a user point of view, I would try to fix that.


From a crawling point of view, we also have that redirect.


If it's just one redirect when following a link,


then that's less of an issue.


We have a lot of time.


We just try the next URL that's kind of in that redirect chain


and try that one.


If it's a matter of a chain set of redirects,


like you're linking to one page and then it goes five, six,


seven hops until it finally reaches the destination page,


then at some point, Google will pause crawling and follow


the next steps in the redirect chain maybe a day later.


So multiple steps, I would definitely


try to avoid a single step.


It's less critical there for crawling.


For indexing, what can happen here


is that we might get confused which URL


you want to have indexed.


It doesn't change anything for ranking,


but it's more a matter of which of these URLs


that you have on your website is the right one to show.


So for example, if you're linking to one version of the URL


and that URL redirects to a different URL,


then we kind of have two URLs that lead to the same content.


And then our systems have to make a decision and say,


should I take the one that the website is pointing at


and saying this is the one that they want to have indexed,


or should I take the one that's kind


of destination of the redirect chain and index that one?


From a ranking point of view, it doesn't change anything.


It's really just the URL that's shown in search.


And there, that's essentially also up to you.


If you don't care which URL is shown in search,


then that's all fine.


If you do care which one is shown in search,


then I would make sure that everything


is as clear as possible that this is really the one


that you want to have shown.


I launched a new website recently


and got 5 to 10 impressions.


However, no query data has been shown yet.


I see the number on the graph, the pages, the countries,


but no queries.


Is this normal?


Are queries blocked by the privacy protection policy?


My guess is that it's just not enough queries yet.


So we do filter queries that are below a certain threshold.


And I don't think that threshold is exactly defined.


It might depend on various factors.


It's also mentioned in the Help Center.


And if you're talking about 5 to 10 impressions for a website,


then probably that's still below that amount.


I'm pretty sure that over time, as the number of impressions


for your website grows, then you'll


start to see more of that right there.


So it's also something where once we kind of have


a better picture of the website and understand how it fits in,


with regards to the bigger picture of the web,


then we can show it appropriately in the search


results.


So sometimes it takes a bit of time


to kind of get the ball rolling.


What I would generally recommend,


though, is not just to take this as something like, oh, I'll


just wait a couple of months and then it'll be better,


but take this as a kind of a situation


where it's similar to when you're opening


a business in a new location, where


you need to do something to get the ball rolling yourself.


So instead of just waiting for people


to randomly search for your website


and go to your website, maybe there


is a way that you can promote your website amongst people


who are interested in this topic already.


Maybe it's a matter of doing some ads.


Maybe it's a matter of doing some outreach


to related sites that might be able to point at your site


as well.


Essentially, like a normal business would do,


you need to kind of get the ball rolling.


You shouldn't just wait for people to come to your website


and say, oh, look, I found this new website.


So that's kind of my recommendation there.


I think with a small number of impressions, it's a good start.


But if you just wait for things to grow,


then it's going to take a while for all of that to pick up.


Does the title in Ahref contribute anything to SEO?


So I took a quick look at some of the things


around the title attribute for links.


And accessibility is a really big thing here.


However, I am not an expert on accessibility.


So my recommendation there would be


to check with someone who has more of a background


in accessibility.


Has more of a background in accessibility


to get their input on this.


From an SEO point of view, I don't


think it's something that's super critical.


We pick up information about links from the anchor text,


from the context of the link.


So we get a lot of information there already.


It's not that you also need to just stuff keywords


into the title attribute.


So my recommendation would be instead


of trying to see this ultimately accessibility


feature as an SEO element that you can just


fill with content, try to find ways


to use accessibility features in the way


that they're meant to be used.


And for that, I'd recommend just checking in


with the accessibility experts instead.


In the first phase, we're planning


to add a last mod part of our sitemap.


Basically, URLs which are newly added


are marked as indexed again after temporary noindex.


How will Google treat the remaining 80%


of the sitemap URLs which have no last mod tag?


Can it cause any negative effect?


Later, we'll implement the last mod on all URLs,


but it might take some time.


We have over 2 million URLs on our sitemap.


So the last mod date is the last modification date.


You can add that to URLs in a sitemap file.


It tells us that this is the date and the time when


you last modified a page, which in turn gives us


a little bit of a hint and says, well, maybe we


should check this page out if we haven't seen it


since it was last modified.


It doesn't force us to go crawl those pages,


but it does help us to figure out which ones we


should prioritize as kind of a next step.


So in general, if you're using a sitemap file,


I'd strongly recommend using the last modification date.


If you have the last modification date


for part of your URLs and not all of them,


that's perfectly fine too.


We store, essentially, the sitemap's data


on a per-URL basis.


So it doesn't matter if some URLs have extra metadata


and some URLs don't.


An example here would also be if you have images


that you have in the sitemap file for some URLs


and you don't have them in others or videos


and you include them in the sitemap file independently.


All of those are variations that you can do.


It doesn't make the other URLs in your sitemap file


look worse.


It does help us to figure out which


ones to crawl a little bit faster.


So essentially, that's a good thing.


Is it correct?


That the site will not appear in Search Console linking site


section if the site redirects to the 404 page on our own site.


So I think they're just linking to the 404 page.


So some external site is linking to a URL that returns 404.


Will we see linking sites in Search Console linking sites


report?


I suspect we won't, but the verification would be great.


So my understanding is we would drop these links completely.


And if we drop them completely, then they


would not be listed in Search Console.


So from that point of view, from just purely theoretical


situation like this, we would not


be listing that in Search Console


if an external site is linking to a page that


is 404 on our own website.


The thing where this sometimes could be visible


is if a page goes 404.


If it wasn't 404 before, but now it's 404,


then it takes a bit of time for all of the linking systems that


track the data in Search Console to update the data there.


So it's certainly possible that you see links in Search Console


that lead to pages which are currently 404.


Over time, those will drop out of the report.


But at least in the immediate term,


it's very possible that they'll continue


to be listed there until they've been reprocessed,


until Search Console is able to figure out, oh, it's time


to remove these and to move on.


Since this kind of, I think, situation


where someone is linking to your website


and then accidentally or for whatever reason


you happen to remove a URL on your website


happens from time to time, I don't


know if Search Console would be that useful to kind of track


this and to highlight it to you.


It's possible that external tools


kind of keep track of the links on the web


would be better suited for that.


But it feels like almost a feature request


that I should be passing on to the Search Console team


to see if we can't create a report of people linking


to pages that are now 404 on your website


where you might be able to either restore those pages


or maybe redirect them to a current version of a page


instead so that those links continue to work.


I think for most websites, in the bigger picture,


it doesn't really change that much.


But I realize sometimes people like to optimize


for small things as well.


Recently, I set up one WordPress fully AMP-based URL


early while testing the site with a demo account


with discouraged search engines from indexing the site.


That time, Google crawled the URL,


and now it's showing as currently not indexed


and software for error.


It's also 100% AMP-based website and the 90-page index


but enhancements.


Check AMP page is only one.


OK, I think these are multiple questions.


So let me try to split them out.


I think the general, like the starting point


is you have a test site where you have some URLs that


were marked as no index.


And Google crawled them and found them to be no index


and flags them as currently not indexed and they're software


for.


In theory, that's the way it should be working.


If we find a URL that's no index and we try to index the page


but we realize we can't, then we will flag that to you


in Search Console, or we'll try to do that as much as we can.


If you change that URL to be indexable,


then the next time we reprocess that page


and see the new content or are able to re-index that page,


we'll pick that up, and we'll be able to index it again.


So generally speaking, there is nothing you need to do here.


If these are individual pages, you


could use the Inspect URL and then


Submit to Indexing tool to get those back into the system


a little bit faster.


But in general, for any kind of reasonably sized website,


that's not something that you'd need to do.


Once we see that the no index is gone,


we'll just reprocess that.


With regards to the AMP site and in the AMP report,


you're only seeing a smaller number of URLs


than you have actually indexed.


That's also normal.


The aggregate reports in Search Console,


which includes the AMP report, they're


based on a sample of the URLs from your website.


So in index coverage, we'll try to show it as comprehensively


as possible.


But the structured data reports and the AMP reports,


mobile friendliness and speed reports,


I think these are all based on a sample of your website,


so not the full set of URLs.


So usually, the way you would work with this


is to use the index coverage to track what is actually indexed


and to use these aggregate reports as a way of recognizing


if there are any general problems that you


need to resolve.


And if you're looking at the aggregate reports


and they're saying everything is great


and 10 out of your 100 URLs are tested and they're all OK,


then usually you can assume that the rest of your URLs


are probably in a similar state and also OK.


On the other hand, if you go to the aggregate report


and see half of your pages are bad,


then that's a sign that maybe a lot of your pages are bad.


Or similarly, if you go there and you


see a trend in more pages are being bad


or fewer pages are bad, then that's


also a sign that either something broke, maybe,


or something got fixed.


Let's see.


Next question there is, for the AMP cache,


I use the AMP URL API but didn't give any effect


in Search Console.


Does that process take time?


So the AMP cache is something that happens automatically.


In particular, with AMP pages, they


can be cached because of the way that they're set up.


And they can be served from the search results directly.


And that's something that happens automatically


when someone searches for a page and we see that it's an AMP


page and it's a valid AMP page and we can pre-cache it,


then we will pre-cache it.


There is no need to use the AMP API for that.


The AMP API is probably more for situations


where you have a really large website


and you need to refresh a lot of URLs in the AMP cache,


then that's kind of a useful use of the AMP cache or AMP.


I don't know what it was called, the AMP API.


But if you're talking about a small website


and you're being shown in search in a reasonable way,


then there is no need to use the AMP API at all.


Years ago, you suggested infinite scrolling


with pagination.


And in previous Hangouts, you told us


that Google creates a large report when


a page has infinite scrolling.


So my question is, if we have infinite scrolling


with pagination and mark our paginated pages as no index,


how will Google read or index this?


Will Google index page one on the basis of page one content


only?


Or will it also consider products


which come into the giant viewport?


Or will Google not create a giant viewport for such pages


once it understands that these paginated pages are generally


no indexed?


Wow, this is kind of a complicated setup.


I think, in general, what I would watch out for


is that you're not accidentally no indexing something


that you want to have indexed.


So in particular, with this infinite scrolling setup,


we would try to render the page in a large viewport.


And with the large viewport, we will do that expansion once.


We will try to get the content that


is shown for that large viewport.


And we will render that page and use that for indexing.


So if, by using a large viewport,


your page adds by JavaScript a no index tag to that page,


then we would consider that whole page to be no index.


It's not that we would say, well, initially it


didn't have a no index, and now it does.


So we'll take the initial content and index that.


It's if, after rendering, your page has a no index on it,


we will drop that page from our index.


So that's kind of the tricky part to watch out for.


On the other hand, if, by clicking on a link


and kind of following a new URL, that new URL has no index,


then just that new URL will be dropped from our index.


But if, through rendering a page,


you add a no index to a page, then that's


a no index on a page, regardless of how that came there.


SPEAKER 2


Let's assume it's a category page on an e-commerce website.


Maybe I show 20 products, and then when


you scroll at the bottom of that, I load another 20,


and then that continues until they're all shown.


Are you saying that Googlebot, when crawling or trying


to index this, will do that once,


will basically scroll down once and say, oh,


something more loaded, load that, and then, but not twice?


Yeah.


So I don't think we trigger on scrolling,


but rather we try to load it in a large viewport.


So in Chrome, what you can do is with the, what is it?


What's it called?


The inspect feature, you can specify a different viewport.


So you could specify something like 9,000 pixels high viewport


and load the page like that.


And essentially, what is loaded for a viewport like that


would be what we would try to index.


I don't know what the exact size is.


I think the size also probably changes over time.


But essentially, it's a long viewport.


And if your page is set up in a way


that it loads kind of the next piece of content once,


then we would have that next piece of content.


If it's set up in a way that it understands


the size of the viewport and loads as many


as it needs for that viewport, then we would index that.


That's super interesting, because some sites with,


so let's say, it's not infinite scroll, but what they do


is they'll do that like the first time you scroll,


they'll load another 20.


But then they'll show a button they have to click to load,


which means that wouldn't load if the viewport was bigger.


So thanks.


That was super interesting.


OK.


Our page is crawled often by the mobile crawler.


How is the importance of the desktop page


if the page is crawled by the mobile crawler?


Are there main differences in analyzing pages


by different crawlers?


What are the main factors we should worry about when


creating our mobile site?


So by mobile crawler, I assume you


mean that your website is in the mobile first indexing setup.


And what happens with mobile first indexing


is we essentially only index the version that we see


with the smartphone Googlebot.


We do check the desktop version from time to time,


but that's mostly just to make sure that things are linked up


properly.


If you have alternate URL setup that we understand,


these are linked accordingly.


But for indexing, we would only use


a mobile version of the site.


In practice, I think this difference


is less and less visible because as people


move to responsive web design setups,


it is less the case that you have completely


different content on desktop and mobile,


but more it's just like positioned slightly


differently.


So that's, I think, less of an issue


overall with regards to the amount of content there.


But with mobile first indexing, if there's


anything that's only on your desktop pages,


then we would not see that at all for the mobile index.


And we would not index that.


And that would also mean that regardless


of users using desktop or mobile to search on Google,


we would essentially only show the version that we


see with the mobile Googlebot.


So if you're just changing the design on these pages,


that doesn't change anything for us.


If you're really reducing the amount of content on mobile,


then that means we would only index


that reduced amount of content.


I think overall, mobile sites are more and more going


in the direction that they're almost providing more


functionality nowadays than the old school desktop sites.


And with that, the responsive design


keeps things together.


But I think, at least in the beginning,


it was a bit tricky that sometimes mobile sites were


just slimmed down or simplified versions of a desktop site,


which would make it harder for mobile-first indexing.


With mobile-first indexing in general,


I think we have a significant part of the web moved over


to mobile-first indexing already.


We plan to shift everything over towards end of the year.


I think we had a date in September.


I don't know if that date will shift


with all of the coronavirus stuff happening as well.


But we still see sites preparing for mobile-first indexing.


There are not a ton of sites left over.


So maybe that'll still make sense.


I have a website, and I lost traffic.


It's a ringtones download website


with 16,000 ringtones on it.


On the 17th of December, we lost our ranking.


And if I search my site with a site colon query,


I only see seven pages available.


I have not received any manual action.


Is it an algorithmic penalty in which Google removes web pages?


What can I do to recover my traffic?


So in general, a site query is not


representative of all of the pages that we have indexed.


So it's a good way to get a rough view of what


we have indexed, but it's not the comprehensive list.


It's not meant to be like that.


For more information on how or what we have indexed,


I would use Search Console, the index coverage report there.


That gives you a better look at the pages that


are actually indexed.


With regards to losing traffic, I


realize that's sometimes hard.


What I would do in a case like this


is maybe post in the Webmaster Help Forum


to get some input from peers who might have seen


similar situations on other related websites.


In general, I think with a website that's


focused on ringtones, it'll be a little bit tricky


because our algorithms really do try


to look out for unique, compelling, high-quality


content.


And if your whole website is built up


on essentially providing ringtones that


are the same as everywhere else, then I


don't know if our algorithms would


say this is a really important website that we


need to focus on and highlight more in search.


So with that in mind, if you're focused


on this small amount of content that


is the same as everyone else, then I


would try to find ways to significantly differentiate


yourselves to really make it clear that what you have


on your website is significantly different than all


of those other millions of ringtone websites


that have kind of the same content.


Maybe there is a way to do that with regards to the content


that you provide.


Maybe there is a way to do that with the functionality


But you really need to make sure that what you have on your site


is really significantly different enough


that our algorithms will say, well,


this is what we need to index instead of all of these others


that just have a list of ringtones on the website.


So that's probably not going to be that easy to make


that kind of a shift.


But that's generally the direction I would head.


And that's the same recommendation


I would have for any kind of website that offers essentially


the same thing as lots of other websites do.


You really need to make sure that what you're providing


is unique and compelling and high quality


so that our systems and users in general will say,


I want to go to this particular website


because they offer me something that is unique on the web.


And I don't just want to go to any random other website.


Can it help SEO by reducing web pages by marking our product


pages noindex, which have almost zero impressions in the last 16


months?


Currently, our 10% to 15% pages are like this.


And they're just deadweight on our site.


I was wondering that after noindexing such pages,


we will submit fewer pages to Google in a site map.


And Google could focus on the rest of our site better.


I don't know.


It's something that I know some sites do.


I think it is not a totally unreasonable approach


to say that the pages that nobody cares about I


essentially remove from my website.


But it's something where I wouldn't just blindly do this.


So if you're just blindly focusing


on the number of impressions that you


have for individual products and you drop them from search,


then it's very easy to drop things


that are actually useful, but they're just not that common.


It might be that maybe it's an archive version of a product


or a page where people, after a certain period of time,


they need to go back there to find instructions


for repairing this product.


Or they want to look up historical information


about a specific item.


And that's not something that happens every day.


So if you just purely look at the number of impressions,


then it's easy to accidentally include


a lot of things that are actually


still useful for the web.


They're just not that commonly used.


On the other hand, looking at the number of impressions


and the types of pages that you have on your website,


that can give you a little bit of a better understanding


which types of pages are more important for users.


And that can either guide you to saying, well,


this type of page is something that maybe I


don't want to provide anymore.


Or perhaps it can guide you into saying, well,


this type of page is currently not seen as being that useful.


Maybe if I significantly improved it,


it would be different.


And that's also something where you don't just go and blindly


look at the number of impressions,


but rather you have to make a judgment call and look at that


and see, does it make sense to remove this?


Does it make sense to improve it?


And a lot of times, it does make sense to improve things


on the web.


With regards to just having fewer pages and those fewer


pages then ranking higher, I don't


see that happening so much.


It can help for a very large website


to reduce the number of pages that they provide just purely


from a technical point of view.


And that if we can crawl 1 10th of the pages on a website,


then it's a lot easier for us to pick up


those 1 10th of those pages a lot faster.


And that can, in turn, help us to figure out, well,


maybe these are the pages that are really


important for the website.


But if you're just dropping a handful of pages


here and there, I don't think it changes anything for crawling


and probably not much for the website in search overall.


We made it to the bottom.


Wow, that's a change.


Let's see if there's anything new that got added.


Let's see.


Hosting a sitemap file for domain on a subdomain,


is that OK?


Yes, that's OK.


If it's OK, what steps would I need to take?


So essentially, you just need to let us know that the sitemap


file is on a different host.


You can point at the sitemap file in the robots.txt file.


That's the easiest way to do it.


You can also use Search Console.


If you have both of these verified in Search Console,


you can submit those sitemap files there.


And those would also count.


Sorry for bugging in again with a new file.


Because I saw that question, so I


didn't want to ask mine before you came to it.


So basically, subdomains, sitemaps,


I got that covered since before.


But hosting sitemaps on third-party domains,


like a totally different domain, you're


supposed to be able to do it.


I can see that it works.


Because I can see when we serve hreflang information


through those sitemaps, I can see


how the international targeting report is saying,


you've got hreflangs, and they're all looking good.


But I cannot see any coverage reports per sitemaps in Search


Console.


Is that supposed to be like that?


I think that's the case.


But it's not that we don't use those sitemaps.


It's just that in the UI in Search Console,


they don't have it set up that you can combine the coverage


report with a sitemap file that's hosted somewhere else.


All right, any plans on adding that, you know?


I don't know.


It's the first time I really hear about this,


but it's something that makes sense.


So maybe we should check with the Search Console folks


to see if there's a way to add that.


And I think from a UI point of view, it's probably tricky.


Yeah, I sent you that domain I asked about previously.


This is the same domain.


So they have that set up.


So if you want a sneak peek on that, you can do that as well.


I sent it in the chat here and also on Twitter for you.


Perfect.


OK.


Sounds great.


And the other question is with regards to the 3D AR


program for Google Search.


I have nearly 1,000 products ready to upload


to our retailers.


They could usually really use some help in this.


I don't know what the current status is there.


But if you can send me maybe a domain where some of these


are hosted now, then I can pass that on to the team that's


working on these AR 3D integrations.


I think that's really cool, cool stuff that they're doing there.


But I understand they're kind of short on time.


So I don't know how quickly they'll be able to do that.


Oh, OK.


Cool.


You posted it in the chat.


OK.


I could take a look at that.


Yeah, I think we got through the questions, more or less.


Is there anything else on any of yours minds


that you'd like to talk about?


I gave someone else a chance for a while.


So I'll drop in again.


One thing that we are seeing, at least we're


kind of thinking that we're seeing it,


is that we have a couple of domains that we monitor.


And they're improving quite a lot over the last few weeks,


like tremendously.


Both in terms of that search for their industry


has increased because of this coronavirus.


So that's one thing.


More impressions, you get more pics if you rank.


But we also see improvements in rankings.


And this is despite no changes going on at all


in terms of technical or content-wise, more or less.


So we're kind of sort of thinking


the changes in intent with searchers


is also impacting how we rank because we


match that intent better than our competitors do.


I can understand if you can't really tell me


if that's the case.


But I mean, it's really hard to say offhand.


I don't think it's as simple as just matching those two parts.


But I do know that people are working on our algorithms


to improve them, particularly with regards to queries


where they're seeing a lot more activity with regards


to kind of the coronavirus and the medical situation


in general.


So my general feeling would be it's not just purely


based on changes in user behavior and intent,


but maybe a mix of various things kind of coming together.


As it almost always is, I guess.


Yeah.


I think, in particular, in the current situation,


it is the case that we have more people working on improving


the search results in general.


And there are probably side effects from there as well.


All right, thanks.


Sure.


Hey, John, hi.


Hi.


I have a question regarding negative SEO.


For example, we have basically spammers that link to us


from like hundreds, I don't know, maybe thousands


of domains.


They do it slowly over time.


And I regularly check and add them to the disavow file.


But I don't know if this is having an effect on the site,


because it's like they spam a lot of links.


Like maybe one domain can link you 10,000 times,


and there's like hundreds and thousands of domains.


So in the end, you look at it, and I


think you can even have more spam in common links


than actual real links.


So I'm worried about that.


I don't know if I should be worried.


For most of these things, I think our systems get it right.


And there's nothing you need to do there.


So from that point of view, I wouldn't really


worry about the situation.


If you're already adding them to disavow file,


then you're kind of like making sure


that Google systems can't take them into account.


But in general, a lot of these spammy domains,


they just link to everything.


And we've seen them for the longest time,


and we're pretty good at recognizing


these kind of spammy domains and just ignoring them.


So you'll see them in the link reports in Search Console,


because we've seen their links there.


But just because they're in the link reports in Search Console


doesn't mean that they have any effect on your website.


So that's something where, I don't know,


we occasionally get people who point at things


around negative SEO and say, Google


needs to double check this, because I found this one case


where it did have an effect.


Therefore, it might have an effect overall.


But pretty much all of the negative SEO cases


that I've sent to the web spam team to manually double check,


they're working as intended.


From our side, we're ignoring the things


we should be ignoring and treating things appropriately


that we're not ignoring.


So I would say for most websites out there,


you probably don't need to use the disavow tool at all.


And if you're worried about this and you


see some domains linking to you and it looks really spammy,


then it's like you're welcome to use the disavow tool.


And that has no negative effect.


So it's not that if you're using the disavow tool,


we think you're a spammer, that kind of thing either.


AUDIENCE 1


Why I started using it, because it


was a sheer amount of domains and links,


and I was like, better to be sure.


Yeah, I totally understand that.


And it's something where Google has this magical black box


where we ignore all of these spammy links.


But as a site owner, you just want


to be sure that everything is ignored,


that you don't want to have taken into account.


And that's what this disavow links tool is for.


OK.


Thank you very much.


All right.


More questions from any of you.


Looks like there's also a bunch of back and forth in the chat,


which I haven't had a chance to go through.


Anything we should cover?


I think the page speed question on the extended viewport


was particularly interesting in that chat.


Let me see.


The page speed part.


So we're going to go through the page speed part.


So I'm not quite sure how that's the page speed.


But in general, when it comes to speed and ranking,


it's not the same as what we use for indexing.


So that's sometimes a bit confusing.


For indexing and crawling, we need


to be able to access the resources as quickly


as possible.


And for rendering, we do the long viewport thing.


But when it comes to understanding


the speed of a page for ranking purposes,


we essentially look at the pages the way


that a user would see them when they access them on a device.


So for ranking, we use theoretical lab tests


where we do things like a page speed in-scout score


and other scores.


And we also use field data, which I believe


is also shown in page speed insights now


with kind of similar to the Chrome user experience data


there, which is based on what people have actually seen.


So from a ranking point of view, we


would base our speed factors on the normal viewports


that people have when they view the pages, which


is slightly different on desktop and mobile.


But essentially, it's based on the viewport that people have.


And for rendering, for indexing, we


would use kind of this long extended viewport


with loading the content and trying to make sure


that everything is in there.


So those are sometimes slightly different.


That kind of sparks an interesting follow-up question


as well.


Whereas, so let's say that a website is showing


all green lines in page speed report in Search Console


from the Chrome user experience report.


But in the lab test, they're terrible,


which could be because they target a market where everyone


has really modern cell phones on very high internet connection.


So they load quite quickly.


But on the lab test, they load very poorly.


Would you say then it's still important to try


to improve the lab test even though all our users are


getting a great user experience?


I think that's always something you have to kind of judge


almost on your own.


I think from purely a ranking point of view,


probably that's OK.


It's also a bit tricky with a lot of these kind of lab tests


in that they test so many different metrics.


And it's hard to know which metrics you should really


focus on there.


And from our point of view, we try


to get the overall picture.


And we try to combine multiple of these metrics


to understand what the overall view is of a web page.


So if the field data is looking fantastic


and some lab tests are kind of slow


and others are kind of OK, then I


wouldn't really worry about it.


All right.


Thanks.


Cool.


OK.


Lots of good questions today.


Let's take a break here.


It's been great having you all here.


Thank you all for joining in.


Thanks for all of the questions as well that


were submitted and live.


Always good to see.


I think the next batch is lined up for next week on Tuesday


and Friday again.


So the usual times and dates.


Also another one in German lined up next week.


In the meantime, I wish you all, I don't know,


good Easter if you're celebrating Easter.


Maybe a short break.


I don't know if you can really go out and enjoy things


depending on where you are, but hopefully things are well.


So wishing you all a great weekend at least.


Looking forward to seeing you next time then.


Bye, everyone.


Tips for hiring a web developer (if you need one) | Search for Beginners Ep 3

In order to find more customers on the web, your online presence will require some effort.


You'll need to upload merchandise photos, write descriptions, set prices, explain the delivery method, and so forth.


There are many platforms from which to choose, each with their own unique time, effort, and monetary investments.


The benefits and returns will also vary.


You'll need to make decisions, like how much control you'll want over the site's appearance,


and if you're willing to share a percentage of your profits with a platform.


For example, if you choose to create your online presence in a photography platform,


you may have less control over things like color, text layout, and how your company logo is displayed.


You'll also be bound by the terms of service and the policies of that platform.


If you choose to make a separate website for your business, it will require more effort.


But you can decide exactly how everything will look, and you will have more control over what content you choose to provide.


For some platforms, such as Google My Business, you can do everything yourself,


from displaying your address on a map to adding a photo of your shop.


However, adding these features to a custom website may require help from an experienced professional.


But where do you even start to find the right person to help?


Web designers and developers often have online portfolios.


Look through their portfolios, and see if they have built user-friendly, good-looking websites that you like.


Make sure to open these sites on your phone.


Do they load fast? Is it easy to order products?


Once you've found web designers or developers that meet your standards, get in touch with them and narrow down your list.


Once you've found someone to work with, you'll need to meet and review the content and structure of your site.


How many pages should it have? How will users click from one place to another?


Always make sure to clearly explain your goals, as we covered in the last video,


so the developer knows exactly what you want to achieve.


This process can take anywhere from a few weeks to a few months,


and features like shopping carts and payment processing may add to development time.


Make sure to test everything with people you trust.


Does your website look good and function correctly across devices and browsers?


Keep in mind, your site will need to be updated on a regular basis,


and you may need to add information about new products during periods of technical maintenance.


So make sure your developers will be available to maintain your site and add new content into the future,


or that they teach you how to use the tools so that you feel comfortable doing this yourself.


And now, your site is live, but the work is just getting started.


English Google Webmaster Central office-hours from September 11, 2020

All right, welcome, everyone, to today's Webmaster Central


Office Hours Hangout.


My name is John Mueller.


I am a search advocate at Google.


And part of what we do on the Search Relations team


is to reach out and talk with webmasters and site owners


about any issues they might have with regards to their websites


and Google Search.


Bunch of things were submitted already on YouTube.


But like always, if any of you want to get started,


feel free to jump on in with the first question.


Hi, John.


Hi.


I have two questions, actually.


So one of our clients, they had e-commerce website,


and they have a blog as well.


And the both website, they set up on WordPress.


Now, what we did, we have a lot of content


on blog, which are really high-quality content.


And people are giving link to our blog as a reference.


Now, what we did, we created some interlink


from blog post to product page and product category page.


Now, the backlink we are getting to our blog post,


will that help to rank our product page or product


category page organically?


Yeah, that should work out.


Yeah, that's essentially kind of,


I think that's kind of a best practice almost.


Like, you write about something that's


kind of related to those products


or related to your industry, to the type of work


that you do on your blog.


That's a good place to kind of put out regular content.


That's content that's perhaps easier to attract links for.


And from there, you can link out to the relevant parts


of the rest of your business, essentially.


So from that point of view, I think that's a perfect setup.


OK, now the next question is, I have got this, one of my clients


today morning, actually.


So he wants to set up his e-commerce website


on Shopify, but he wants to use WordPress for the blog.


So he needs to create a subdomain for the blog section.


So the question is, if we do a subdomain


and get the backlink for the blog post,


will that still help the product page and product category


page for the organic ranking?


Sure.


So there will be no effect.


Yeah, I think that's perfectly fine.


Some sites even have the blog on a separate domain


for whatever technical reasons.


That's essentially up to you.


I think, in general, having it as close to your primary site


as possible makes sense, because then also for users,


it comes across as one big structure.


And then it's kind of clear that, oh, this link


from this one part of the site links


to a different part of the site.


And it doesn't come across as something,


I don't know, unexpected.


You click on a link, and suddenly you


land on a completely different site.


If it looks the same, if it's essentially


hosted in a similar place, then that's, from my point of view,


a good idea.


Thank you.


So John, in terms of Google understanding


that even if it's on a subdomain or a different domain,


I assume interlinking plays an important role for Google


to kind of understand that two properties are


from the same entity, from the same website,


from the same company.


What are the things that Google is looking at?


Does design play a role?


Should design for the blog, for example,


be very similar to the website, hosting, things like that?


From my point of view, that's more a factor


from the user side and less an SEO factor.


So from our side, it is important


that we can understand the links between these two pages.


Sometimes what helps us is to understand


that these are part of the same entity, which, in general,


having it on the same host name is a perfect way to do it.


Having it on subdomain is something


that could also work.


But essentially, being able to understand


it's one bigger entity.


And the main reason for that is that we


can kind of build up the trust for this site and understand,


oh, this is actually a very good site.


It has a lot of information on these topics.


There's a lot of information here.


And we can understand the overall structure


a little bit better.


And for that, it doesn't need to look the same.


It doesn't need to be hosted on the same setup,


on the same network, or anything like that.


It is really, from our side, I'd say mostly a matter of the


being it on the same domain so that it's clear for us


that this belongs together.


MIHAI APERGHISLAMOON


The Shopify example is a good one,


since you can't use a subfolder, for example, with Shopify,


especially if your blog is on WordPress.


You cannot go to Shopify and host it there.


It's not going to be hosted in the same place,


because obviously they host it on different servers,


different IPs.


So this is what I was mainly curious,


what kind of signals can one give to Google in order


to make sure that Google understands this is part


of the same entity, like from a technical perspective.


Obviously, from a user perspective,


it's important as well.


But I assume, as mentioned, interlinking and things


like that play a good role in Google understanding.


These are not separate.


These are part of the same entity.


Yeah, exactly.


Yeah.


Cool.


Any other questions before we get started?


Brittany?


Hey, John.


Go for it.


So I submitted again on the YouTube channel.


So you might have had a chance to read that


and shined in last week.


But yeah, I've got the domain migration


with over a 90% traffic loss going on a month


with no major culprits that we've been able to identify.


So I had another theory, potential culprit,


I could run by you.


So one of the things on our mind is our site


relies on a lot of JavaScript.


That's always been true.


But we had our old domain on prerender,


using prerender until June.


I won't get into exactly why we stopped using it.


But we did stop using prerender in June.


And so that was true all summer with the domain migration


at the beginning of August, still off prerender.


Domain migration was at the beginning of August.


And we had all of our traffic loss.


And we were wondering if maybe taking this site off


prerender in June was not the right move.


And there was maybe a bit of a lag in Google totally processing


that the domain migration made it worse, not totally sure.


But we did put our new domain back on prerender


as of basically the beginning of September.


Hasn't helped with the traffic loss at all.


Wondering if you could give your opinion on whether this


is a potential culprit.


And if so, if when we might potentially see recovery,


what we could do to help it.


Or if we are once again pulling at a thread that


is not actually going to help us.


Yeah.


I don't know.


So from the timeline, you basically


have a client-side rendered site in that case,


a JavaScript-based website.


And then until June, you had it running on prerender.


So it's serving kind of the prerendered version to Google.


And then you kind of turn that off


and let Google do the rendering, essentially.


And then in August, you set up the redirect


to the other domain.


I think that makes it more complicated.


But I don't know what the actual effect there might be.


So that's something where I'd probably have to take a look


to see what all was kind of happening.


And during that time, from June until August,


was it fairly stable?


Or were you seeing changes there, too?


Well, we definitely did see a bit of a dip,


but nothing absolutely crazy.


But we saw traffic loss maybe at about 15%


starting after May, which is when we started moving off


prerender.


That's also, of course, right after the May


algorithm update.


So we had originally attributed it to that.


And that's fine.


And we were trying to learn from that and sort


of normal run-of-the-mill stuff.


But then, of course, when we did the domain migration in August


and ended up with a 90% traffic loss, that


made us reflect on if maybe that change was more tied


to prerender than the core algorithm update


and just tried to focus in on that area or any area we could.


OK.


And the domain migration, how did you set that up?


Because if it's a JavaScript-based website,


did you just redirect all the URLs to the new one


with server-side redirects?


Or was there something on the JavaScript side


that you did as well?


Yeah.


We just did like speech with it as much as I can.


But yeah, we set up, from my perspective, standard 301


redirects.


We validated via Webmaster Tools.


We've had four different SEO agencies looking at everything.


And first thing they check is our 301 redirects


and have said everything looks golden there.


Our SEO agency, they picked up on things that aren't perfect.


But all of them are a little bit at a loss


to say how any of those smaller things,


from their perspective and our perspective,


could lead to a 90% traffic loss.


So I feel like we did that part pretty solid.


But I can't say that with full confidence.


I think it makes it a little bit more complicated.


But it shouldn't be such that you would see such a big drop.


So in particular, what could happen,


I don't know if this is something


that happened in your case.


But what could happen with a client-side rendered website,


if it's based on JavaScript and needs


all of the JavaScript to function properly?


Then when you redirect it, because of the way


that we cache all of the resources that


are used for rendering, it might be


that it's a little bit trickier to handle a site move


situation.


Because then we might have the new URL,


and we try to render that based on the previously


cached old content.


And depending on the way that the move is set up,


it might be that rendering fails of that mixed set


of information that we have.


So if you have a pure static HTML page,


when we move that over, we have the static HTML page


with everything.


But if it's based on JavaScript, we


need to be able to process the JavaScript


to see the full content.


And we cache a lot of the content that


is pulled in with JavaScript.


So it's possible there is some kind of clash,


perhaps, that happened there.


But that would be something where


you would see issues with regards to indexing, where


you would see that really the number of index pages


is going down.


It's not something where I suspect you would see just


the traffic drop.


Yeah, our number of index pages is also way down.


We dropped off the map entirely with the old domain.


And the new domain didn't really pick up


more than a very small amount of keywords


compared to what we used to rank for.


So I guess in this case, do you have any specific suggestions


for what we could do from here?


So like I said, the site has been back


on prerender for about a week and a half now.


And that hasn't impacted our rankings for traffic.


Yeah.


OK.


So I passed it on to the ranking team


to double check what was happening there last week.


I haven't heard back anything in particular yet.


But I kind of need to double check just purely


from a technical point of view that we


were able to even process all of these things.


So kind of to determine, is this more of a technical indexing


thing that we can work out, or is there


something from ranking that's actually harder to solve?


Because the technical issues are things that usually you


can fix them.


Like you kind of moving back to prerender


is something where personally you probably


don't need to do that.


But it reduces the number of risky kind of connections


that you have there.


It makes it a little bit more stable in that regard.


So that's something where I'd say that's probably a good move.


But I don't know if it's really purely a technical thing that


needs to be worked out or if there's actually


some ranking or quality issue that we need to work out.


OK.


No.


But I was hoping I'd get more information by now


from the team.


But sometimes it's not that trivial.


Sure.


I appreciate that.


And an excuse for me to join you again at midnight my time.


So thank you.


Yeah.


Have a good night then if you want to drop off.


No problem.


I'll stick around.


Cool.


All right.


Let me look at some of the other questions


that were submitted.


We do a lot of testing on our site.


And the bots are seeing all of these tests.


We're planning quite a big test, which involves drastically


changing the menu.


And this would have quite a big impact on SEO.


But we need to have the test for UX purposes.


We don't want to roll out this change.


If it's not permanent, what should we do?


If we block Googlebot from seeing the test,


will it be considered cloaking?


If we roll out the test for everyone, users and bots,


what would be the maximum period of time


we would run it without impacting SEO?


So first off, I think doing tests


like this for usability, even for SEO sometimes,


is really important.


And I think it's something that everyone should kind of


consider doing and try to find ways that they can do that.


Because sometimes you can only make so many assumptions


about your website.


And you really need to test to see what is actually the case.


Do users respond to this type of menu or that menu better?


Can users respond to this type of menu?


Can we bring our information better to users


if we present it, I don't know, in a different color


or in a different font or in a different layout?


All of these are things that you can't really


know ahead of time.


You almost have to test them.


So doing this kind of A-B testing is really important.


And understanding how you can do that is hard,


figuring those details out.


We have, I think, a help page on A-B testing,


which has a little bit of information there.


But in general, if you're doing something


that you would consider a temporary A-B test,


it's fine to include Googlebot in that.


It's also fine to say, well, Googlebot


is a special category, which might be a category that you


base on, I don't know, geographic location


or on language settings or on capabilities


that this device has.


And then kind of do the A-B testing that way


so that you have a more stable version that you show


Googlebot for crawling, indexing, and ranking.


So that's kind of the direction I would head there.


If you do end up using a separate version for A-B


testing, make sure you have the rel canonical


set to your preferred version that you


want to use for indexing.


If you use the same URLs, then that's less of an issue.


Also keep in mind that Googlebot doesn't use cookies.


So if you use cookies to set an A or B version,


then Googlebot won't keep that and won't return


that cookie, which means that if you're not watching out,


you could end up in a situation that you serve Googlebot


a different version every time Googlebot crawls, which


is probably a bad thing when it comes to SEO,


especially when you're changing things


like the internal linking the menu within a website.


So those are kind of the things that I would look at there.


It's something that's definitely not trivial to do.


I know there are some frameworks out there that make it


a little bit easier.


But it's worthwhile to kind of think


through all of the different variations


and keeping in mind some of the restrictions


from crawlers in general with regards


to how they handle cookies, how they deal with redirects


and different URLs, all of those things.


My old Hindi blog was getting huge traffic.


But after I created some forum and do follow comments,


backlinks from high DAPA foreign websites to my Hindi blog,


after that, my ranking is going down day by day.


And a Google Core update also decreased my ranking by 50%.


In one year, three core updates hit my blog.


I disavowed some of those links, but still no improvement


is showing.


Do I need to disavow all of those links?


So I am kind of skeptical about the links


that you place there, because it sounds


like these are random links that you're


placing on other people's websites


just with regards to SEO.


So if you're kind of looking for high DA, which


is domain authority, it's a metric that Google doesn't use,


it comes from a third party.


If you're using sites like that, then probably other people


are dropping links there too.


And then probably we're going to be ignoring those links


completely.


So my feeling is those links are not going to be the problem,


but they're also not doing any good at all for your website.


So that's a lot of work that you're doing,


which essentially has no effect.


So I would kind of recommend stopping just dropping links


on other people's sites.


With regards to the ranking in general,


my guess here is that it's mostly


based on the content of the website itself


and on the way that we see that website with regards


to kind of the rest of the search world.


So that's something where I wouldn't assume


that those links are necessarily causing problems


or that the core algorithm update is somehow


magically changing things for your website,


but really it's more a matter of your website itself,


the content that you provide, and kind of the overall value


that you bring to the rest of the web.


And the question kind of goes on,


I'm hosting my blog on Blogger with a custom domain.


Do I need to migrate it to WordPress,


or is Blogger still OK?


Blogger is perfectly fine.


So there's no advantage that you would see in a case like this


from moving to any other CMS.


One of the really big advantages of using Blogger


is that you don't have to worry about the infrastructure.


Things essentially just work for you.


There's a team of engineers who work


to handle any outage that comes up,


who make sure that all updates are installed, all of that.


So that's something that if you can save yourself that work,


that's always worthwhile.


But again, I would really focus much stronger on the content.


I don't know your website here, so it's hard to say,


but it's something that we regularly


see when kind of a blog where people are just


publishing content all the time, trying to get traffic,


when that drops significantly in ranking or visibility


in search, then often that's due to kind of the content


not being as fantastic as we would have expected.


I was wondering about when these big announced core updates


happen.


Are there some parts of the linking algorithm updated


as well?


Like you discovered that this site received great links


from great sites.


Would you say that this is a better site now because it


got such recommendations so that the big core updates will


reward it and show it more to users?


So in general, a core algorithm update,


the way that we have it defined is somewhat vague


because it's not that we have this one piece of machinery


that is kind of the core algorithm,


and when we change one screw there,


then that's a core algorithm update.


But rather, we have so many different algorithms


that work in search.


And when we make significant changes across a number of them


or significant changes in the way that we interpret them,


then that's something that we would call a core algorithm


update.


So from that point of view, it's not