JavaScript SEO Q&A September 15, 2021

And if you scroll up a little bit, and we say, OK,


JavaScript SEO Q&A September 15, 2021

so lots of JavaScript has actually happened.


JavaScript SEO Q&A September 15, 2021

And then we can see the call tree, where we see


JavaScript SEO Q&A September 15, 2021

there's a function being called.


JavaScript SEO Q&A September 15, 2021

There's a bunch of stuff happening.


JavaScript SEO Q&A September 15, 2021

But what function is called, we actually


JavaScript SEO Q&A September 15, 2021

don't have instrumentation on this one.


JavaScript SEO Q&A September 15, 2021

So we really don't know necessarily.


JavaScript SEO Q&A September 15, 2021

But the function call seems to have taken most of the time,


JavaScript SEO Q&A September 15, 2021

because in half a second, we actually decoded the image.


JavaScript SEO Q&A September 15, 2021

So using the performance profiler down here


JavaScript SEO Q&A September 15, 2021

is actually really, really helpful to figure out


JavaScript SEO Q&A September 15, 2021

where your website gets stuck.


JavaScript SEO Q&A September 15, 2021

Someone posted in the chat.


JavaScript SEO Q&A September 15, 2021

I do hope.


JavaScript SEO Q&A September 15, 2021

I can share the URL with you.


JavaScript SEO Q&A September 15, 2021

There's also, I wonder if I actually


JavaScript SEO Q&A September 15, 2021

have a starting page that has links to the other.


JavaScript SEO Q&A September 15, 2021

Yes, it does.


JavaScript SEO Q&A September 15, 2021

So I can share this link with you.


JavaScript SEO Q&A September 15, 2021

It shows different approaches to this.


JavaScript SEO Q&A September 15, 2021

For instance, there is one that uses a web worker


JavaScript SEO Q&A September 15, 2021

to solve this problem.


JavaScript SEO Q&A September 15, 2021

And then there's one that uses WebKit,


JavaScript SEO Q&A September 15, 2021

because it specifically is a graphics issue.


JavaScript SEO Q&A September 15, 2021

So now here, you see it's not perfect.


JavaScript SEO Q&A September 15, 2021

But at least I can continuously interact with the page.


JavaScript SEO Q&A September 15, 2021

Even though the work still takes three seconds,


JavaScript SEO Q&A September 15, 2021

1, 1,000, 2, 1,000, 3, 1,000, it still


JavaScript SEO Q&A September 15, 2021

takes time for the work to be carried out,


JavaScript SEO Q&A September 15, 2021

because it's still JavaScript doing the work on the CPU.


JavaScript SEO Q&A September 15, 2021

And it's really, really not meant for that.


JavaScript SEO Q&A September 15, 2021

But at least my website doesn't stop interacting.


JavaScript SEO Q&A September 15, 2021

And if you can't measure that in lab settings


JavaScript SEO Q&A September 15, 2021

or with your own devices, that is not surprising,


JavaScript SEO Q&A September 15, 2021

because we all have really good devices.


JavaScript SEO Q&A September 15, 2021

But if your users are on slower devices,


JavaScript SEO Q&A September 15, 2021

then they are struggling with this.


JavaScript SEO Q&A September 15, 2021

Here, by the way, is the same example in WebGL,


JavaScript SEO Q&A September 15, 2021

where we can pretty much smoothly navigate


JavaScript SEO Q&A September 15, 2021

through the threshold.


JavaScript SEO Q&A September 15, 2021

It makes it a little slower, because it


JavaScript SEO Q&A September 15, 2021

needs to interact with the WebGL context.


JavaScript SEO Q&A September 15, 2021

But the lag is minimal.


JavaScript SEO Q&A September 15, 2021

And there's no initial delay.


JavaScript SEO Q&A September 15, 2021

If we were to profile this page, 1, 1, 1, 1, 1, 4, 5, 6, 7,


JavaScript SEO Q&A September 15, 2021

we still get a little bit of blockage.


JavaScript SEO Q&A September 15, 2021

But that's mostly because I'm doing stupid things.


JavaScript SEO Q&A September 15, 2021

And the painting is quite large.


JavaScript SEO Q&A September 15, 2021

But then the Java's, I do a bunch


JavaScript SEO Q&A September 15, 2021

of JavaScript to deal with WebGL.


JavaScript SEO Q&A September 15, 2021

And I do that inefficiently.


JavaScript SEO Q&A September 15, 2021

But the tasks are basically faster.


JavaScript SEO Q&A September 15, 2021

So we've dropped one frame here.


JavaScript SEO Q&A September 15, 2021

So yeah, the first input delay is not easy to debug.


JavaScript SEO Q&A September 15, 2021

And I'm very well aware of that.


JavaScript SEO Q&A September 15, 2021

But try to figure out what kind of devices


JavaScript SEO Q&A September 15, 2021

your users are using.


JavaScript SEO Q&A September 15, 2021

And Google Analytics or other analytics solutions


JavaScript SEO Q&A September 15, 2021

could potentially help you with that.


JavaScript SEO Q&A September 15, 2021

And then try to figure out how your website behaves


JavaScript SEO Q&A September 15, 2021

on these devices.


JavaScript SEO Q&A September 15, 2021

And I have a hunch that the devices will be slightly older


JavaScript SEO Q&A September 15, 2021

and probably mobile devices.


JavaScript SEO Q&A September 15, 2021

And it's not going to be easy to debug these things.


JavaScript SEO Q&A September 15, 2021

But it can help you get a better idea of what's happening.


JavaScript SEO Q&A September 15, 2021

SPEAKER 1 I think, actually, I understood the essence.


JavaScript SEO Q&A September 15, 2021

And thank you very much for explaining that.


JavaScript SEO Q&A September 15, 2021

So we do have a lot of visitors from Africa


JavaScript SEO Q&A September 15, 2021

and from a lot of countries with a very slow connection.


JavaScript SEO Q&A September 15, 2021

We've noticed that before.


JavaScript SEO Q&A September 15, 2021

Then especially for the pages that


JavaScript SEO Q&A September 15, 2021

are targeting these regions or targeting the US regions,


JavaScript SEO Q&A September 15, 2021

which is also included in the African countries,


JavaScript SEO Q&A September 15, 2021

the metrics of Corvid Vitals are going down quite a bit.


JavaScript SEO Q&A September 15, 2021

So I think, yeah, really, after this thing,


JavaScript SEO Q&A September 15, 2021

I will try to dig into the data more closely


JavaScript SEO Q&A September 15, 2021

to see if this is the root cause of this problem.


JavaScript SEO Q&A September 15, 2021

And then try to figure out what is,


JavaScript SEO Q&A September 15, 2021

even if it's very short on your devices,


JavaScript SEO Q&A September 15, 2021

you could still properly see what's


JavaScript SEO Q&A September 15, 2021

happening on the main thread and what might be the culprit that


JavaScript SEO Q&A September 15, 2021

takes a long time.


JavaScript SEO Q&A September 15, 2021

If you can get your hands on a device


JavaScript SEO Q&A September 15, 2021

that your users are actually using,


JavaScript SEO Q&A September 15, 2021

try to find out the number one device that the users who


JavaScript SEO Q&A September 15, 2021

are experiencing the problems are using.


JavaScript SEO Q&A September 15, 2021

And you can actually use that in a real-world scenario


JavaScript SEO Q&A September 15, 2021

and debug on that.


JavaScript SEO Q&A September 15, 2021

And you can use remote debugging to actually get this performance


JavaScript SEO Q&A September 15, 2021

timeline, and you see exactly what is taking so long


JavaScript SEO Q&A September 15, 2021

to actually push you over the 100 milliseconds.


JavaScript SEO Q&A September 15, 2021

Sounds good.


JavaScript SEO Q&A September 15, 2021

Thank you very much for this.


JavaScript SEO Q&A September 15, 2021

You're very much welcome.


JavaScript SEO Q&A September 15, 2021

Also, I very much appreciate Caio's background and the fact


JavaScript SEO Q&A September 15, 2021

that your cat is popping by.


JavaScript SEO Q&A September 15, 2021

I'm really enjoying pets on the office hours.


JavaScript SEO Q&A September 15, 2021

Yeah.


JavaScript SEO Q&A September 15, 2021

She is a little bit upset that I'm talking to you and not


JavaScript SEO Q&A September 15, 2021

to her.


JavaScript SEO Q&A September 15, 2021

Not enough attention.


JavaScript SEO Q&A September 15, 2021

I understand that.


JavaScript SEO Q&A September 15, 2021

Yeah, not enough attention, exactly.


JavaScript SEO Q&A September 15, 2021

Cool.


JavaScript SEO Q&A September 15, 2021

Any other questions?


JavaScript SEO Q&A September 15, 2021

Always worried when Giacomo is here


JavaScript SEO Q&A September 15, 2021

because he usually has questions where I don't know the answer


JavaScript SEO Q&A September 15, 2021

to, which is great.


JavaScript SEO Q&A September 15, 2021

No, no, no.


JavaScript SEO Q&A September 15, 2021

No other question today.


JavaScript SEO Q&A September 15, 2021

I just want to ask you an update on the list of the most common


JavaScript SEO Q&A September 15, 2021

JavaScript error, if you had time or not.


JavaScript SEO Q&A September 15, 2021

Damn, I did not have time.


JavaScript SEO Q&A September 15, 2021

I know.


JavaScript SEO Q&A September 15, 2021

No way I could get there.


JavaScript SEO Q&A September 15, 2021

But I sit on the data.


JavaScript SEO Q&A September 15, 2021

I just need to crunch it.


JavaScript SEO Q&A September 15, 2021

And I don't think this is going to happen any time soon,


JavaScript SEO Q&A September 15, 2021

to be honest.


JavaScript SEO Q&A September 15, 2021

But I'm trying.


JavaScript SEO Q&A September 15, 2021

I'll keep it in mind.


JavaScript SEO Q&A September 15, 2021

Actually, I'm meeting with Andre on Thursday, which, oh my god,


JavaScript SEO Q&A September 15, 2021

is tomorrow.


JavaScript SEO Q&A September 15, 2021

So I can probably ask him very nicely.


JavaScript SEO Q&A September 15, 2021

And he'll very nicely say no because I asked him before.


JavaScript SEO Q&A September 15, 2021

But I'll try to ask him again.


JavaScript SEO Q&A September 15, 2021

Maybe.


JavaScript SEO Q&A September 15, 2021

Maybe he has some time.


JavaScript SEO Q&A September 15, 2021

Cool.


JavaScript SEO Q&A September 15, 2021

Excellent.


JavaScript SEO Q&A September 15, 2021

If there are no other questions, I'd


JavaScript SEO Q&A September 15, 2021

like to thank you all for joining in live.


JavaScript SEO Q&A September 15, 2021

And everyone who watches the video,


JavaScript SEO Q&A September 15, 2021

thanks again for your time.


JavaScript SEO Q&A September 15, 2021

Everyone who submitted questions, thanks even more


JavaScript SEO Q&A September 15, 2021

for your time to submit questions.


JavaScript SEO Q&A September 15, 2021

And yeah, I wish you all a wonderful day.


JavaScript SEO Q&A September 15, 2021

Stay safe.


JavaScript SEO Q&A September 15, 2021

Stay healthy.


JavaScript SEO Q&A September 15, 2021

And see you in two weeks.


JavaScript SEO Q&A September 15, 2021

Have a good time.


JavaScript SEO Q&A September 15, 2021

Bye-bye.


JavaScript SEO Q&A September 15, 2021

See you, Martin.


JavaScript SEO Q&A September 15, 2021


English Google Webmaster Central office-hours from October 4, 2019

Let's see.


All right.


Welcome, everyone, to today's Webmaster Central Office Hours


Hangouts.


My name is John Mueller.


I'm a webmaster trends analyst here at Google in Switzerland.


And part of what we do are these Office Hour Hangouts,


where webmasters can jump in and ask us


any question that's kind of on their mind with regards


to websites and web search.


Let's see.


A bunch of things were already submitted.


So we can go through some of those.


But as always, you're welcome to get started here


if you want to ask the first couple of questions.


If not, that's also fine.


OK.


I'll just jump through the questions that came in already


because there are a ton of them this time.


I think everyone dropped their questions


into this Hangout rather than the other ones last time.


But that's fine, too.


The viewport tag on responsive sites.


So this is a fairly complicated question.


It took me a couple of times to try to understand


what exactly is going on.


I think what it comes down to is this


is a website that has separate mobile URLs.


And at the same time, they're using the viewport meta


tag on some of the pages.


And they're kind of wondering, does the viewport tag


tell Google this is a mobile page


and kind of block the separate mobile URLs from being used?


And the viewport tag is essentially something


that we use to try to understand the mobile friendliness


of a page.


So it's a way of kind of scaling things for the viewport, which


is usually used on mobile devices.


But it's not only for mobile devices.


So just because you have a viewport meta tag


doesn't mean that we will see this as the mobile version


and we won't look for the other versions that are available.


So in particular, if you have separate mobile URLs,


what we recommend is on the one hand,


having the link between the two versions.


So from the desktop version, you have a link rel


alternate to the mobile version.


From the mobile version, you have the link rel canonical


back to the desktop version.


That's one thing.


And the other thing that I strongly recommend


is setting up redirects so that when desktop users go


to the mobile site, they get redirected to the desktop site.


And when mobile users go to the desktop site,


they get redirected to the mobile site.


And with both of those mechanisms,


you're really making it clear to us


that this is the mobile version.


This is the desktop version.


And we can connect the two.


So we can use them properly for indexing.


But you're giving us a clear definition


like what these versions are.


And with that clear definition, it


doesn't matter if you have a viewport meta tag


or if the desktop version is also kind of usable on mobile


or not.


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


In general, though, we've stopped recommending


using separate mobile URLs, mostly because they just


add a lot of complexity.


And they make things like understanding


which one is canonical, which one you should track


in Search Console, which one you should focus on,


make all of that a lot harder.


And you add more complexity on your side


as well with regards to keeping track of all those redirects,


making sure that all of those links between those versions


are correct, all of that.


So if you can, move to a single URL setup,


which could be either responsive or dynamic serving


or you're serving a mobile version specifically


for mobile users.


If you do need to use separate mobile URLs,


then the links and the redirects are the way to go.


A client's Google My Business listing isn't showing up.


I can't help with Google My Business issues.


I don't really have any insight there.


So I'd recommend going to their help forum.


I work with a large health fitness publisher


that took a huge hit after the March update,


getting back our results slowly.


Is Google experimenting with health-related search terms


and preference they receive in rankings?


With some of the health partnerships,


we're curious also if more approved terminology is


being evaluated or elevated.


So I don't think we have any specific algorithms that


look out for these kind of sites.


But our general ranking algorithms


do try to make sure that we treat sites in a way


that we think is appropriate in search in terms of trying


to understand the intent of the queries that people have


and trying to show relevant search results that we


can kind of trust.


And some of the ideas behind that


are visible in the quality rater guidelines


that we publish regularly.


There are various sites that go through these,


because these guidelines are quite


comprehensive in the meantime.


So my recommendation there would be


to look through these guidelines and to try


to understand how Google tries to evaluate the quality,


especially in four sites that kind of go


into this health medical area.


The second part is a question with regards to Google News.


We're being denied while competitors


with less research content are being included.


I also don't have any insight into Google News.


I know they have made, I believe they've


made the application process a little bit more strict.


So that's something where I think


it's kind of OK to have a high bar for something that's


included in a news service like Google News.


If you're unsure about why you're not being accepted there


when you're applying, I would also


make sure to post in the Google News Publisher Help Forum.


There are lots of folks there who


have experience with these kinds of issues


and who can help you to figure out what


you could do to improve there.


How to correctly implement pagination on an e-commerce


site.


The links inside each page will be found and indexed.


So that's kind of a short question on a really big topic.


So it's kind of hard for me to kind of package that


into a really short answer.


We do have some guidelines on how to deal with pagination.


I think in our Help Center, as well as a blog post


that we did a couple of years back,


I'm currently trying to look into creating


some more specific guidelines for e-commerce sites


just to make it a little bit easier for them to implement


things like pagination and filtering, category pages,


all of that.


A customer is closing their business site,


but it has a lot of useful articles.


Is it safe to use the content on a different domain name?


Yes, of course.


If this is content that you're allowed to publish


and it's otherwise not published anymore,


then I think that's a good way to make


this kind of content available.


Our website has a growing commerce strategy,


and some members of our team believe


affiliate links are detrimental to our website ranking


for other terms.


Do we need to no follow all affiliate links?


If we don't, will this hurt our organic traffic?


So this is something that I think


comes up every now and then.


From our point of view, affiliate links


are links that are placed with kind


of a commercial background there in that you're obviously


trying to earn some money by having these affiliate links


and pointing to a distributor that you trust


and where you kind of have some arrangement with them.


From our point of view, that's perfectly fine.


That's a way of monetizing your website.


You're welcome to do that.


We do kind of expect that these kind of links


are marked appropriately so that we understand


that these are affiliate links.


One way to do that is just to use a no follow.


A newer way to do that, to let us


know about this kind of situation,


is to use the sponsored rel link attribute.


That link attribute specifically tells us


that this is something that has to do with kind


of an advertising relationship.


We treat that essentially the same as a no follow.


A lot of the affiliate links out there


follow really clear patterns, and we can recognize those.


So we try to take care of those on our side when we can.


But to be safe, usually we recommend just using a no


follow or the rel sponsored link attribute, I guess.


But in general, this isn't something


that would really harm your website if you don't do it.


It's something that makes it a little bit clearer for us


what these links are for.


And if we see, for example, that a website is engaging


in large scale link selling, then that's


something where we might take manual action.


But for the most part, if our algorithms just


recognize that these are links that we don't want to count,


then we just won't count them.


Add new site maps slowly or all at once.


I have a directory that generates 30 million URLs.


And I was advised to submit 10 site maps every five to seven


days to show these in the Search Console.


That means 600 site maps to submit.


So I guess, first of all, from a more general point of view,


if you have a website that generates 30 million URLs,


I'd be kind of cautious about the overall quality


that you're creating there.


So it's obviously possible for a website


to come up and say, well, I have 30 million new URLs,


and they're all fantastic.


I digitized the archive of my city,


and it's a lot of content, and I want to put it all online.


And that might be perfectly fine.


But on the other hand, we often also


see sites that generate 30 million URLs based


on a database or where they enumerate all phone numbers


that are available worldwide, and they


start putting up pages for each phone number individually.


And that's the kind of thing where


it's easy to generate a ton of pages,


but you're not generating a ton of quality.


And that's something when our algorithms look at it,


they'll be like, well, we don't really know


what to do with this website.


We spent a lot of time trying to crawl all of this,


but there is no really fantastic content here.


Why are we spending so much time on this site


when we could be spending time on sites that


do provide really good content?


So instead of worrying about whether or not


the sitemaps is the problem, I would primarily


worry about the quality of your content overall.


And if you're sure that the quality of your content


is really high, if this is really fantastic content


that we've been missing, then just submit it all directly.


Let us know as quickly as possible


so that we can crawl and index all of this content


as quickly as possible.


And if you're unsure about the quality of the content,


then maybe double check the quality of the content first


and not worry so much about how you can sneak this


through with sitemap files.


I have one question.


I just want to know if it's the right practice to add two


authors to one content piece.


Sometimes an article requires technical expertise


about a subject, and the main writer is very like,


I guess they're like two people behind the article.


Sure.


I don't see any problem with that.


I mean, we don't have any authorship markup.


So how you put information about who


wrote your content on your pages is totally up to you.


Some people put the names directly.


Some people just have it as a part of their normal website.


Ultimately, that's totally up to you.


A little bit of background noise somewhere.


Let me see.


OK.


The new snippet tags that Google has recently added,


is it mandatory for every website to implement these?


If I add max snippet number 350 to 400 characters,


is Google going to show that?


Is it required to news and media sites


where their story appears in the latest post section in mobile?


So no, it's definitely not required for every site


to use these new meta tags, robots meta tags


that we have available.


It's totally up to you.


So what you can do with these new meta tags


is on the one hand say, this is the number of characters


I want you to show at most as a snippet for my website.


If you don't care, then just don't specify that.


If you do care, then you can specify that.


You can specify the size of an image preview, which


is something that may make sense if you have images


on your pages that you want to have shown in a large way.


Or it may make sense if you don't


want to have these images shown as a preview for your web


pages.


So in particular there for AMP pages,


because the AMP article markup includes a large image


by default, for AMP pages we would default to large image


for you.


And for normal HTML pages, we would


default to kind of the standard image preview.


I think it's called standard or default or something like that.


And then there's something similar for video


where you can also specify the number of seconds


that you would like to have a video preview shown.


For most websites, these defaults


are the same as before.


For European press publishers, when their content


is shown in France, the default is slightly different.


So I would double check a recent blog post


we did on that topic to see what the exact defaults are there


for European press publishers when


the sites are shown in France.


For all other websites, for other locations,


for non-press publications, you can use them however you want.


The defaults are essentially the same as they've been before.


One thing I would kind of shy away from


is just going in there and saying, well,


I will specify five million characters


as a maximum snippet and always large


and the maximum of everything.


I don't think you'd get any value out of that.


And I think it just makes things confusing for you


because afterwards you're like, why did I specify five million?


What was I thinking of specifically there?


It doesn't really make that much sense.


So that's kind of something where


I'd say unless you have a reason for wanting a change in the way


that your pages are shown in the search results as a preview,


then I would just leave the defaults there.


What's the correct way to add schema markup to a website?


For example, an article schema that


also includes breadcrumbs or a web page that also includes


is part of website and so on, complex schemas.


If incorrect, does every schema have to be separate?


Also, if the schema is being found


by schema tests and rich snippet scanner by URL,


does it mean that crawlers can find it too?


Or is there any other technical aspect


to consider to make them easier to read for crawlers?


Wow.


That's a lot of questions.


Let's see.


So I think the, so in general, we


recommend using JSON-LD to add structured data to pages.


There are different ways that you can do it.


It seems like JSON-LD is the one that's easiest to implement,


because it doesn't rely on the actual HTML elements


within your page's content.


So you don't have to wrap it around the right pieces


of text.


You can just include that snippet of markup


anywhere on the page, and that can be picked up.


And if it can be picked up by the usual testing tools,


then it can be picked up by search as well.


If you're doing something fancy, like injecting


that structured data with other JavaScript,


for example, if you're using the Google Tag Manager to inject


the structured data, then you might


need to watch out how you test that to make sure


that you're actually testing the JavaScript side, not just


the static HTML version of the page.


If you have multiple kind of complex pieces of schema,


then there are multiple ways that you can implement that.


On the one hand, you can include them separately.


On the other hand, you can kind of embed that,


how is it called, like one within the other,


depending on the type of structured data that it is.


That's something that's essentially up to you.


We should be able to pick that up either way, provided,


of course, the testing tools show that information.


There are two other things, I guess,


to watch out for using structured data in a way that


matches our guidelines and doesn't guarantee


that we will show it as rich results in the search results.


So it might, on the one hand, take some time.


It might be something where algorithms say, well,


we don't know if we can actually show this in search.


That's one thing.


And the other thing is that there's


a lot of schema types out there that are not


used at all by our systems.


So that's something where you wouldn't


see any visible effect of applying


that kind of structured data.


So I believe, for example, there are


some types for different types of cheese, for example.


And we don't have a cheese feature in search,


which is kind of sad, I guess.


But it's something where you can specify


these things on your pages.


And search engines can look at that.


They can understand that this markup is here.


But they don't necessarily do anything visible with that.


And from our point of view, that means


you're providing information.


It's nice that you're providing this information.


But we don't actually do anything with that information.


So if you're kind of time limited or resource limited


and can't do everything on your website,


then I would concentrate my efforts


on using structured data for the elements that are actually


visible in search or that you have some other kind


of direct return from.


So if there's something specific that you want to have shown,


like you have events on your page


and you also have a lot of cheese on your page,


then mark up the events so that you


can be shown in the Events feature in search.


And if you have extra time or you feel like it's fun,


then marking up the cheese elements is also fine.


But that's not something where you would see any direct effect


from.


Our company is changing our website from CMS


to a custom solution.


And this change will include design, some content,


and some architecture.


What are some tips that you can give


us to do this while losing as little traffic as possible?


So kind of in general, if you make really big changes


across your website, then you should


expect some changes in search.


Sometimes those are positive changes.


Sometimes those are negative changes.


So that's something where if you significantly


improve your website, if you improve your site's


architecture, if you improve the way that search engines can


pull out information from your pages,


then that's all fantastic.


That's a big change on your website.


And that's something that likely you'll


see some positive effects from.


On the other hand, if you change your website's architecture


and it's essentially all the same,


but it's all set up in a different way,


then probably it'll take a bit of time for us


to understand the new setup and to understand that, oh, this


is actually the same.


And you'll see most likely kind of a significant drop


in visibility over the time where we're confused.


We're like, how do these pages belong together?


How do they connect together?


And over time, that will settle down again.


So I guess with regards to tips how


to avoid any kind of fluctuations over this time,


I would start with the assumption


that you will see fluctuations and that they


will be in place for a couple of months,


even if you improve things overall afterwards.


I think going with that assumption


prevents you from kind of being, I don't know,


surprised by these fluctuations.


Because it's very common that if you make significant changes


across your website, if you change the URL structure,


if you change the design, the internal linking,


then you will see changes in search over the time


where it takes search engines to kind of get reconnected


with your website and to understand how


these pages all belong together.


So going with that assumption, it


might help you to figure out when would be a good time


to make this kind of change.


That might be a period where you're saying,


well, traditionally people don't search for my own business


during this time of the year.


So I'll make this change during that time of the year


so that the practical effect on my site is minimal.


You could also go the other way around and say,


well, during this time of the year,


we're doing lots of TV advertising or lots


of offline advertising anyway.


So we don't really need to have the direct traffic from search


during that time because we're compensating


with all of this other sources of traffic, which


might be another approach.


That's kind of one thing to watch out for.


The other is we generally try to recommend doing these changes


incrementally so that you make one change


and then you move to the next so that you're able to determine


if something in between goes wrong, what that change was,


and to make changes and fix that before you go to the next step.


Sometimes that's possible.


Sometimes that's not easily possible.


So that's something where it depends a little bit


on your site, on the kind of changes that you're making.


If you're moving to another domain


and changing site architecture or if you're


changing your design and changing


all of the internal URLs, sometimes it's


possible to decouple those.


Sometimes that's not so easily possible.


If you can decouple those, I think that generally makes


sense because, like I said, it's easier


to recognize where problems come from


and to fix them before you move on.


But if you can't decouple those, then my main recommendation


there would be to really make an absolutely clear map


of the starting state and the final state


that you're aiming for so that you can monitor everything


that's happening over that period of time


so that you can check for things like redirects


and make sure that all of the content


is correct by crawling your website


and checking it like that.


It's a lot harder to try to figure that out afterwards.


So if you're coming afterwards and you're seeing,


well, I lost a lot of traffic, but I don't know why,


and you don't know what the old URL is exactly where,


then you're kind of digging for information at a time


when everything is falling apart.


Anyway, I hope this move goes well


and that it doesn't all fall apart.


Let's see.


Next question we have here.


I know Google ignores rel next and previous annotation.


And the best practice, if you have two more pages,


was to canonicalize each page like this.


So you have link rel canonical to page equals 2, for example.


I worry if Google can't recognize


the relevance between page equals 1 and page equals 2,


the pages are thought to be duplicated to each other


and the value is not unified.


So we do recognize URL parameters,


and we can crawl URLs with URL parameters


and index them like that.


So in general, that's not something


you need to worry about, that we wouldn't be able to recognize


URL parameters.


However, there is a URL handling tool in Search Console


where you can specify which URL parameters we should ignore.


And if you're seeing that we can't pick up


your page equals 2 annotations or URLs,


then I would double check there to make sure


that you're not accidentally marking these as URL parameters


that we should ignore.


Then a question about short-lived pages,


like product pages that are sold out within a few days.


Is it better to let Googlebot crawl these and index them,


or to add product markup?


Or what should we do?


It's totally up to you.


If you know ahead of time that something will be short-lived,


you can make the decision to say,


well, I'll just noindex it from the start


so that Googlebot doesn't have to spend a lot of time on it.


There's also the unavailable after robots meta tag,


where you can explicitly tell us that the content on this page


is only valid for a certain period of time,


and we can drop it after that date.


So with products that you just have a limited amount from,


you probably don't know the date when it's finished.


But if it's an option, or if it's


some kind of a classified ad that is only


available for a couple of weeks or a week or so,


then you can use that robots meta tag to tell us about that.


So that might be an idea.


With regards to product markup, in general,


if it's an e-commerce site and you have products on there,


I would use product markup.


I think that's a good match.


I think that's independent of whether or not


this is a page that will be longer term on your site


or more short lived.


I found some directory links from a previous SEO pointing


to my client's website, but they use branded anchor text or URL.


Is it safe to assume that these aren't


whoops, now I clicked the wrong button.


Is it safe to assume that these aren't hurting my website


because you would discount the bad anchor text rather


than demoting?


Probably.


So if these are just random links


that you found to your website and you


feel they're kind of irrelevant, then it's


possible that we're ignoring them.


In general, if you find a bigger section of links going


to your website where when you look at them,


you're like, well, someone might assume


that if they're looking at this manually,


that these are paid links or that there


is some kind of a link scheme happening behind these links,


then that might be something where


you could go to the disavow tool and say, well,


I want to make sure that you don't take these into account.


On the other hand, if you just find random links


to your website and some of them are a bit spammy


and some of them a little bit low quality,


I wouldn't lose any sleep over that.


That's something that happens to all websites across the web,


and we ignore a lot of those kind of crazy links


that just happen everywhere.


Google did a core update this June and July,


and many websites that got hit.


My website, too.


Can you please tell us some details


regarding this core update and what we should


do to get our traffic back?


So we did a blog post on core updates maybe,


I think, like two or three months ago.


I would definitely check that out.


It's a pretty long blog post.


There's a lot of information there.


So a little bit of the thoughts behind these bigger algorithm


changes that we make.


So I would kind of check that out.


And with regards to getting our rankings back,


sometimes it's not a matter of getting rankings back,


essentially by fixing a bug or something on your website.


Essentially, these core ranking algorithm changes


are kind of different ways that we look at the relevance


for search results.


So that's not something where we would say a website has


done something wrong, and therefore,


if they fix that issue, then they


will be ranking normally again.


Essentially, we're saying, well, we


think relevance should be determined slightly differently


for these kinds of queries.


And that means we would show slightly different websites.


So instead of thinking about it as something


that you've been doing wrong, think about it more of,


like, how can I make sure that my website is seen


as something that is relevant for these queries


when you look at it based on these criteria


that Google was looking at here?


In a sector I work, a large amount of sites


participate in nefarious link schemes


to manipulate page rank.


These sites often rank extremely well for high-value terms


because of this.


As recommended by Google and standard SEO practices,


I have reported these activities.


How often and how seriously does Google treat these reports?


Yeah, there are definitely some areas


where we see more issues with regards to links


or with regards to other kinds of activities


that go against our webmaster guidelines.


That's definitely the case.


However, I wouldn't necessarily assume


that these sites are ranking because of those activities.


Sometimes what we see is that sites rank fairly well just


in general.


And it's something that they're almost ranking despite doing


a lot of these crazy things.


So that's kind of one thing to keep in mind.


What generally doesn't happen is that when


we recognize that a site is, for example, participating


in link schemes, that we would remove the whole site


from search because often they're


doing other things which are fairly well.


And on a balance, that's something


where maybe we should still show them


in search based on the other things


that they're doing really well.


So it's not that we would remove them completely from search


just because they're doing one thing wrong.


One of the big reasons why I think that's important


is that a lot of sites do things badly accidentally.


They don't know that this is something


that they shouldn't be doing.


They heard about it, I don't know, in some SEO blog


or from some SEO consultant that's working with them


or that used to work with them, and they


did all of this crazy stuff.


And they didn't realize that this was actually something


This is something I see a lot when it comes to smaller


businesses in particular.


They don't have time to invest to understand


all of the details of SEO and all of the details of what you


should and shouldn't be doing.


They worry about their business primarily.


So they'll do weird things like in the past,


they would do a lot of hidden text


or kind of stuff things into the footer of their pages


because they heard that that works.


And our algorithms, when they run


across these kinds of issues, one of the things we try to do


is to ignore this kind of activity and say,


well, we don't know for sure that they did this on purpose.


So we'll try to ignore it, and we'll


try to evaluate the site based on the other factors


that we have there.


So that might be playing a role there.


I know there are probably some niches


where people are doing everything


to push the boundaries.


So that might be something where,


particularly where you're active,


maybe that's slightly different.


If you do find situations where there are really larger


schemes, larger level schemes at play, where you think that


maybe the web spam report isn't a good way to specify that,


you can also send that to me directly.


And I'll take a look at that with the web spam team


to make sure that we're really covering that properly.


In general, they do look at the web spam reports,


and they do try to take appropriate action where


they think that's necessary.


So kind of going back to the starting point,


if the web spam team recognizes that our algorithms are already


ignoring these, then maybe there is nothing extra


that they need to do.


On the other hand, if they recognize


that our algorithms are picking these up in a way


that they shouldn't be picking it up,


then maybe they will take manual action


to make sure that those kind of links are neutralized.


We have a page which downloads certain content


with JavaScript calls to the server on page load.


If the Ajax requests that we do are blocked by robots.txt,


will Googlebot be able to see this content


on the second wave of indexing?


No.


We need to be able to access the JavaScript files and the server


endpoints that you're using for these kind of Ajax requests


if there is content that you're pulling in that way


that you want to have indexed.


So we kind of need to be able to access those things


if that's something that you want to have indexed.


When keeping URLs simple, is it OK to have a URL


to be longer with the top level page?


For example, slash services category slash service type


name, or should it be kept short with just slash service type


name?


That's totally up to you.


You can have longer URLs or shorter URLs.


You can have multiple folders with slashes


in between those URLs.


It's not something that you need to artificially shorten


or artificially make longer.


The limit that we have, I think, is something like 2,000


characters.


So that's something that pretty much no site


runs into accidentally when they're just


creating URLs manually.


Then let's see.


There's a fairly long question about a specific medical site


and also with regards to the algorithm updates


that we had there.


So I haven't been able to take a look at the site specifically,


but I would really take a look at the blog post


that we did on the core algorithm updates a while back


and look at the kind of things that we try to keep in mind


when it comes to medical sites or when


it comes to sites in general.


Also, the quality rater guidelines are a good thing


to go through specifically with regards to medical sites


to kind of understand a little bit better what we're looking


at or what we recommend our quality raters look at.


So just to clarify, the quality raters don't make the rankings.


They help us to improve our algorithms.


Two niche questions about country-restricted websites


due to legal purposes.


When using tools like PageSpeed Insights or Structured Data


Testing Tool, both seem to be coming from external country


IPs and are restricted from accessing the site.


Is there a list of IP addresses that we could whitelist?


I'm not aware of any list of IP addresses


specifically for those tools.


So with Googlebot, you can confirm the IP address


using a reverse DNS lookup.


But specifically for those tools,


I don't think they would use the same Googlebot IP addresses.


So that's kind of tricky.


How could you test those?


I guess one way to test that is to create separate test pages


that are accessible and to see what IP addresses


those requests are coming from.


There are hreflang tags that redirect each user


to the appropriate TLD website based on their country


to avoid restrictions.


There's also a single page.com website.


The website is the x-default hreflang of all websites,


but only in their home page.


Is this the right way, or should this


be x-default for all pages?


I would try it out.


I think it'll be kind of tricky in general


when you're restricting access on a per country basis.


On the one hand, for Googlebot, it


might be tricky because if you're blocking users


from the US, then that would include blocking Googlebot.


So it would limit the number of pages or the exact pages


that we could actually look at there.


But I would try this out.


I think in general, having the hreflang


across different country versions, different TLDs,


that's a perfectly fine accepted approach.


Having the hreflang only on the home page


is also perfectly fine, acceptable.


Using the x-default to have a default page that


is valid for all users that are not within the countries


that you're specifically showing individual pages for


is also acceptable.


We're a news website, and we use news XML sitemap


for discoverability and indexing.


But as a news organization, we have


to update our stories with more facts and information


as a story develops.


And I think it kind of goes in a direction of,


how do we make sure that these updates are also processed


as quickly as possible?


So I'm not aware of anything specific


that you could do to make it so that we pick up


these updates faster.


Essentially using a sitemap file with the last modification


date, that's a great way to do it.


Using a RSS atom feed with the last modification date


is really useful.


Both the news sitemap and the atom feed


are useful because they're just focused


on the new URLs for your website,


or the new and changed URLs on your website.


We don't have anything like an indexing API


where you can push changes to us.


Why does a website's rankings bounce back?


I don't know.


It really kind of depends on the website.


So there are different things that can play a role there.


On the one hand, our ranking algorithms can change.


So it's something where it's possible


that our algorithms will say that one site we don't really


trust that much, or we don't know


if we can trust it that much.


We'll be a little bit more critical.


And the next time around, when our algorithms look at it


again, they might say, well, actually, it's a good site.


We should trust it a lot more and show it more in search.


And then you might see some fluctuations like that.


On the other hand, it might be that within your website,


things change.


And that could be a sign for us that, oh, there's


something different here.


We should perhaps reconsider how we were showing it in search.


And of course, there are situations


where something changes in the rest of the web,


where suddenly we look at other websites and say, well,


actually, they weren't as great as we originally thought.


We'll show them a bit lower.


And then suddenly, those that were below those


start showing up a little bit higher.


And all of these things are essentially


a normal part of search.


We're constantly working on our algorithms


to try to improve them.


We constantly work to try to understand websites better.


And because of that, you will almost certainly


see fluctuations across different things in search.


Is there any means to request Google


crawling from another country other than the US?


No.


We primarily crawl from the US.


There are very few exceptions.


And for those exceptions, it's a very small number of countries.


And it's something that would be essentially limited


to websites in those countries.


So for the most part, we do crawl websites from the US.


Please remove YouTube from Google search.


Let me compete with each other.


And let websites compete with websites.


It's not fair when I write a 4,000-word article covering


every aspect of a topic and then get over-ranked


by a 500-word article just because this website has


more authority.


So I think, first of all, I'm quite


happy with having different kinds of search results


in Google search.


And that includes sites like YouTube.


That includes other video sites.


That includes image sites.


All of these things bring diversity


into the search results.


They bring a diverse set of viewpoints to users in search.


And there are different ways of finding relevant content.


So some people like to find content on video.


Some people like to find content in text form.


Some people don't know what they're


looking for for a specific query.


And then they get surprised by one or the other.


I think all of that is essentially fine.


The other thing is with regards to the number


of words in your article, the number of words on a page


are not a factor that you would use for ranking.


So just because you have 4,000 words and someone has 500 words


doesn't mean that your page is automatically more


relevant than another page.


So instead of focusing on word count,


I would really try to focus on the quality of the content


that you're providing and the consistent quality.


So if you're working on a website


and you're creating one article after another,


make sure that you're really hitting the bar


that you want to reach.


And maybe instead of writing one extra article,


think about ways that you can make sure


that anything that you create on your website


is of the highest quality possible and is, in a way,


is something that clearly should be ranking number one by far


for the things that you're targeting.


So not just like, am I kind of doing the same thing


as other people, but really making sure


that when someone objectively looks at these search results,


they say, well, this article is fantastic.


And it should clearly rank above all of the other ones.


And that's kind of the level that you should be aiming for.


And at that point, that sometimes also means,


maybe you should be including video content.


Maybe you should be including more images.


Maybe sometimes articles need fewer words.


Sometimes they need more words.


That's something where just purely the word count alone


is not really the measure that you should be aiming for.


I have a website in Angular where previously I


had URLs getting indexed through the escape fragment


version of the page.


However, due to some technical issues,


the escape fragment version was removed.


And now the same page is not getting indexed,


though I tried submitting the same using Search Console.


What's an alternative to getting my page indexed?


So there are a few things going on in this question.


And I think instead of trying to answer


all of the different things here, I would double check


kind of the technical setup that you have there


to make sure that things can actually get indexed.


So you can use things like the Inspect URL tool


to double check and make sure that you have actual URLs


on the page and not just hash fragments


that you're trying to index.


And most of all, especially for JavaScript sites,


I would recommend taking a look at our documentation.


We have fairly extensive documentation


on JavaScript sites now.


We have a set of videos on YouTube for JavaScript sites.


So I would kind of make sure that you


have all of the technical basics set up there properly.


It's easy to say, well, it kind of worked in the past,


therefore I just want it to work again.


But especially with JavaScript sites,


you need to make sure that you're doing things properly


so that we can actually render and index the content there


accordingly.


And if you are doing things properly,


then that's something where these sites can show up


in search normally too.


Wow, OK.


Running out of voice almost.


What kind of questions are on your minds?


What am I missing?


Oh, wow, lots of stuff happening in the chat.


Long questions, at least.


We're facing an issue for one of our clients


where two similar pages were made live and submitted


for indexing at the same time.


One got crawled and indexed, and now is ranking well.


The other is still unindexed, so no matter what we tried.


We checked robots.txt, metarobots, no issues,


submitted in sitemap, submitted feedback in Search Console.


But in vain, can you help to understand


what might be the issue?


So I would double check in the Inspect URL tool


to see what the status is there.


Oftentimes, it'll tell you what is happening,


why a page is not being indexed.


So that's something where maybe you


can find more information there.


It's kind of hard to say without looking at the URLs


what exactly is going on there.


If you have a bit of time afterwards,


we can take a quick look.


I have a bit more time afterwards.


I'll pause the recording at some point,


but we can double check that afterwards if you want.


Any other questions from any of you in the meantime?


Wow.


No more questions.


OK.


Actually, I do have a question.


So some of the backlinks to our website


are not showing up in the Search Console in the Links section.


And I wanted to know if that means that they're not


passing any signals if they don't show up in that list.


And they're from big authoritative sites.


We try to show a relevant sample in Search Console,


but we don't show all of the links that we have there.


So if these are normal links that you


know exist to your website, then I


would assume that we can pick those up.


Similarly, what's also sometimes confusing


is if a link has a nofollow or is in a disavow file,


we'll still show that in Search Console


if we think it's one of these sample links


that we should show.


OK.


Now, do links expire after a while?


I mean, the signals that they're passing?


No.


They don't expire.


What does happen, though, is that, especially


if you're talking about a large website that's


growing regularly, then the pages that links are on,


over time, they get even deeper and deeper


within this website.


So for example, if you have a link from CNN


and it's in an article that's linked on the home page,


then that's something that's really important for us.


On the other hand, if this article is maybe a year


or two later, is somewhere in the archive at CNN,


then that article itself is not something


that we would find that important anymore.


So it's not that the link expires


after a certain period of time, but just often


that the page where that link is on,


that becomes less and less relevant over time


if it's on a site that is growing fairly regularly.


OK, but given that the page doesn't change


or if it's on an important page in a website,


then it shouldn't have any different effects over time.


Exactly, yeah.


OK, and I have another quick question.


So we've been getting some new backlinks recently,


and we have seen our ranking increase in search


in the console.


But we haven't seen any difference in actual SERP.


And there hasn't been any change in,


you know, we haven't seen an increase in traffic


to their website.


So we were wondering why is that happening.


That's hard to say offhand.


But in general, one thing to keep in mind


is that the ranking that we show in Search Console


is, on the one hand, based on what


was actually shown to users.


And on the other hand, it's essentially


based on that search results page


that we would show to users.


And sometimes what you'll see is that a site goes maybe


from number 10 to number 8 or something like that.


And that might be something that's


a little bit more visible to users in search,


but it's still not something where you would immediately


get a lot more traffic from.


Yeah, sorry.


And the other thing is that sometimes the title


and the snippet that we show in the search results


doesn't match what the user is exactly looking for.


So it might be ranking higher for certain queries.


But if users are looking for something


different for those queries, then it


wouldn't necessarily mean that you'd see more traffic.


I see.


OK, thank you.


Sure.


Thank you.


Hi.


Question here about Search Console.


So I really would like to understand a bit more


about your take on Google Take in general.


Because whilst using the search analytics,


more often than not, by filtering for queries, pages,


or whatever, if I say I want to include the terms x, y, z,


and then I get some kind of numbers, then if I say,


OK, give me all the numbers without the terms


A, B, Z or whatever it was in the previous example,


the numbers never match.


So I totally appreciate that you say, OK, we do normalize data.


We do certain times exclude x because of whatever


is on privacy, da, da, da.


But my question in reality is, OK,


if you do that kind of discrepancy,


and I can see discrepancy up to 60%, 70% of the numbers,


how would you expect us working in the industry taking the tool


seriously for measurement?


Because we can't really rely on such a data


if you skew too much.


I can understand that for privacy, you can say, OK,


well, let's take out 2%, 3%, 5% because a certain condition


for ourself doesn't really make sense for you to be seeing.


Fair enough.


5%, 6% is OK.


70% or 60%, 70%, it's a bit too much.


I guess it all depends on the kind of site


and the kind of queries and the level of queries


that you're looking at there.


So that's something for some sites,


depending on what you're searching for,


you might see bigger changes.


If you start doing things like including and excluding things


for other sites, you'll see smaller changes.


So what I would recommend doing there,


instead of using the filters to kind of try to tweak things


like this, is just to export the list


and work with the list of queries or the list of URLs


and the clicks, impressions, and position that you have there


and work with those directly.


So doing something in a spreadsheet or database,


pulling them out with the API, for example,


and focusing on the data there.


That's something that makes it a little bit more deterministic


what you're working with because then you


know what the default set is.


Yeah, OK.


It makes sense just using the raw data


at that point in time, which is something


that I've been doing in any case.


I was just a bit more concerned about the general average


of users or even when it comes to some stakeholders


that they just don't really have time, patience,


to wait for you to elaborate on the database


or whatever other tools you may think about.


And they just jump straight on the Google Search Console,


says, OK, let's have a look on how we've been playing balls


over here.


And the numbers didn't really play well.


So then you have double challenge.


Not only finishing the job as in data structure and computation,


but also demonstrating to them that the Google Search Console


is actually wrong because it's such a counter-level


discrepancy.


Who's going to be then on the right side?


You, operating on the API, or Google having the tool?


You know what I mean?


But I guess it all depends on the site


and what you're looking at there now.


Well, it's not on the site.


Just try to put in, say, whatever


are the boss shoes, right?


You are the employee.


I am the boss.


And I'm jumping on Google Search Console this morning.


I say, OK, give me query x minus x, traffic ticks.


And you employee, you have been telling me for, say, a week


or a month that you've been playing


against the optimization of certain page


or certain set of pages to optimize them, right?


Great.


And you have told me, oh, boss, I've


done such a magnificent job over here,


and I got so great results.


And then I'm jumping on the Search Console.


And it says, hold on a minute.


Over here, it says that you just brought me, I don't know,


10k traffic, right, irrespective of the websites.


And you know, and.


I don't know if that's really a reasonable comparison.


Because on the one hand, if you're


doing all of these kind of crazy comparisons


with plus and minus, then that's a fairly advanced usage.


On the other hand, if you're looking at changes,


then those trends would be visible regardless.


So that's something where it's like, sure,


the absolute number might be different if you're doing


this kind of complex query.


But if you're looking at it over time,


that's something where I totally expect


to see reasonable results there.


And I don't see this changing at any point in the future.


So it's not like we wouldn't be able to show


the queries that we're filtering out for privacy reasons.


That's not going to happen.


AUDIENCE 1


Let's take a break here.


I'll pause the recording.


And if any of you want to stick around,


and I think that one URL, I'm happy to take a look at that


too.


And otherwise, I wish you all a great weekend


and hope to see you all again in one of the future Hangouts.


Dynamic Rendering for JavaScript web apps - JavaScript SEO

Are you building a single page app with JavaScript


that has lots of frequently changing content?


Then your web app might benefit from dynamic rendering.


And that's what we're going to look at in this video.


For this video, we will use AffiliCats


as our sample application.


It is a single page app built as a progressive web app


as well that lets you search for cats and create deals on them


online.


We won't go much into the details of this app.


I'm focusing on implementing dynamic rendering instead.


But wait.


What is dynamic rendering?


It is a technique where you switch


between client-side rendered content


and pre-rendered content for certain user agents.


This is useful because you can deliver the full client-side


rendered experience to users while getting


as much content as possible to crawlers such as Googlebot.


As discussed earlier in the series,


that means your content is crawled and indexed


without needing to execute JavaScript first.


All right.


Let's get started.


First, we take a look at our web app.


It loads a list of cats and shows cuteness along


with its price at different affiliates.


When we put the URL into the mobile-friendly test,


though, we only see the loading view rather


than the actual content.


As the cats and the affiliate deals keep changing,


we won't be able to pre-render them easily.


Switching entirely to server-side rendering


might be a little too much on our plates right now.


So we want to look into dynamic rendering instead.


We will write a server so that our users see the app the way


it is right now.


But Googlebot and a few other bots


get a version that was rendered on demand in a headless


Chromium using RenderTron.


We start by deploying a RenderTron instance.


I chose to use Google Cloud for this,


but you can deploy RenderTron to your own infrastructure


as well.


I also set up the cache because starting a headless browser


and render the page on every request will take some time,


and we want to serve the page as quickly as possible


to avoid timeouts.


With our RenderTron server running,


we install Express and the RenderTron middleware from NPM.


Now we can write a small Express server to host our web app.


Then we add the RenderTron middleware


and configure it to use the default RenderTron user


agent list.


But we add Googlebot to also use it for Google search.


Even though Googlebot can execute JavaScript,


we don't want to rely on that now.


The last two steps are setting up the middleware


to use our RenderTron server to pre-render pages,


and we write a little function as part of the server start


to request our single page app so that the cache is ready


to serve pages without having to wait for the headless browser


to run.


We will rerun this function periodically


to make sure the cache data is not too old.


So this video has concluded our JavaScript SEO series.


If you would like to see more JavaScript SEO content


or any other SEO topics on our channel,


please let us know and submit your ideas


English Google Webmaster Central office-hours hangout from July 26, 2019

All right.


Welcome, everyone, to today's Webmaster Central Office Hours


Hangouts.


My name is John Mueller.


I'm a webmaster trends analyst here at Google in Switzerland.


And part of what we do are these Office Hour Hangouts.


And today, we're trying a fairly different setup


because the YouTube Live Hangouts are going away soon.


So we'll see how this works out.


As always, there are a bunch of questions that were submitted.


I can run through some of those.


But if any of you want to get started


with the first question, feel free to jump on in.


If not, it looks like you're all muted.


So I don't know if you probably need to unmute to speak up.


But otherwise, I'll just get started.


And you can jump in whenever something pops up.


All right.


Let's see the questions.


So the first one is fairly long.


My question contains a little bit of critique


on Google's practices recently.


And it essentially goes into the general theme of Google showing


stuff in the search results, and then webmasters not seeing


so many clicks to their website, and how far will this


lead in the future?


Where does Google draw the line?


I think, first of all, thank you for the question.


I think it's something that is really important for us.


It's something that is really something


on the top of our mind essentially every day


as we work in search and we work with different search


features.


It's something that is critical for us


for the long-term survival of the web ecosystem and the search


ecosystem in that we need to make sure


that when you're providing something for a search,


you also get enough back, that there is really


kind of this kind of almost like a deal between Google


and the publishers in the sense that if you work hard


to create some good content, and we can show that in search


and send traffic your way, that the traffic


that you get from that is worthwhile your effort.


And that's something that comes into play essentially


for every search feature that we have,


regardless of how much we show in search


or how little we show in search.


It's something that is always kind of there.


And on the other hand, I think this is also


something from a publisher side that you can also keep an eye


on, where you can think about what


do you want to provide in search and which kind of content


would you prefer to only provide on your website.


There are different mechanisms that you can use to do that.


And through those, you can kind of


adjust that over time as well.


And finally, I think there is one aspect that's


also really important in that for most businesses


when they're online with a website,


the actual important metric for them


is not how many clicks they get from search,


but more how many customers they get.


How do they convert those customers?


So for example, if you're a small business that


is active in a local community and someone


is searching for your opening hours,


they don't need to go to your website


to see those opening hours.


That's not really the way that you kind of get value back


out of search, but rather if they see those opening hours


directly in the search results, they'll


be able to come by and visit your business in person


when it's open.


So a lot of these things are aspects


where people don't necessarily need to go to a website


directly to kind of bring value back to that business.


But anyway, this is something that, from my point of view,


I don't think there is an absolute answer.


And I suspect there'll be some shifts back and forth over time


as things settle down, as new aspects in search


kind of become available, as new types of user behavior


becomes more prominent, as new types of websites


kind of show up and move along.


So that's something where I expect this to kind of shift


a little bit over time.


But in general, it is something that we care about deeply.


And it is something that we don't take lightly.


It's not that we just go out there and say,


well, we can do this in the search results.


Therefore, we will do that.


But rather, where we think about what does it actually mean?


How does this provide value for the user?


And how does this provide value for the publishers as well?


All right.


Presumably, John, Google doesn't make any money if no one ever


I think that's probably the case.


I mean, yeah.


No one's going to advertise if the answers are always


front and center.


It will get to the point where people will say, well,


that's the end of my budget, which is the end of Google.


I think that's kind of the long-term look as well, anyway.


As long as there's kind of this notion of search


is useful to give you more detailed information,


then I think that's something that keeps


people coming back to search.


Whereas if they just get all of the answers directly,


then they don't even need to look into more details.


And then why do we even index more content?


But it's always tricky because you're


balancing kind of short-term interests


and long-term interests.


And with any business, it's like you kind of


struggle with that as well.


My client is a federal medical center,


and all content goes through the doctors first before it


is published on the website.


I think it's a good idea to let our users and Google know


that the information on the website is trustworthy.


I understand that I might just add, for instance, some info


about the doctor who checked the information and some words


like, the content was checked before publication


by Dr. John Mueller, and also put a link


to their personal web page.


But what's the best way to tell Google about this?


And should I do it at all?


So I think, first of all, should I do it at all?


I think that's something that you probably


have answered already, in that if you're providing information


on your web page and it is kind of checked or written,


created by someone who has a lot of knowledge on that topic,


then that's something I would definitely highlight.


So there are lots of ways that you can highlight


that on your web pages.


You can link to those profiles.


You can put text on the pages.


Anything to really show users when they come to your pages


that there is actually something valuable here that they can


trust this information, that this is something that's


reliable, that they can forward onto their friends


without having to worry that maybe it's not correct or so.


So in that regard, anything that you


can do to make that clear, that probably makes sense for users.


That's something you can also check with normal A-B testing.


And that probably also makes sense for search engines


in that regard as well.


My question is regarding duplicacy in content.


Many students who are studying for a certain degree,


recognizable worldwide, and they're


getting the same questions for their assignments.


I am associated with some people who


are providing information and solutions to students


who are looking for an answer on the internet.


My question is that if I publish their assignment


questions, which are quite lengthy and the same worldwide,


and the solutions, which might be different, on my website,


and other competitors do the same,


does Google consider all of this content duplicate content?


Wow.


I wish I had this kind of service as a kid.


It would have made my homework so much easier.


I don't know if I would have learned as much, but fine.


So in general, what happens here is


we would probably recognize that certain blocks of text


on this page are the same across multiple pages.


The whole page themselves are different, of course.


So we would index all of these pages


because they're unique pages.


But there are certain blocks of text that are the same.


And in practice, what would happen here


is if someone is searching just for one


of those blocks of text, we would probably


pick one or two, maybe a handful of sites


that have this text on them, and show those in the search


results because the other sites where the same text is on there


would essentially show the same thing.


So for example, if you have a really long question


and someone searches for the first sentence


in that question, then we would assume


that these pages are essentially about the same topic.


And we would pick maybe a couple of those that we know


and show those in the search results.


And it's not that the others would be shown less visibly


in search or would be ranked lower,


but rather that we would filter them out


because we think that essentially this


is the same thing.


The snippet that we would show in the search results


is the same thing across all of those users.


So that's essentially what would happen there.


With regards to duplicate content,


we would consider that block to be duplicate content.


But again, the whole page itself,


because you have a different answer,


that would be something that we would consider to be unique.


We would index those separately.


So from that point of view, I think


it's fine to go down this route.


I think from a practical point of view,


if you're just starting down this direction


and there are already a lot of sites out there that are


covering the same questions, especially if you


say that the assignment questions are


the same worldwide, then there's probably


going to be a lot of competition.


And I don't know if with a new website,


it would be that easy to get in to this big, bigger


group of sites that are providing content,


essentially on the same theme.


A page has FAQ contents, which are


written on images in their alt text, but not on the body text.


Is that OK with the rich result guidelines to mark that up?


I think, theoretically, we might be able to pick that up.


But practically, I would recommend


making sure that the text is actually visible on the page.


So what kind of happens with the alt attribute for images


is we do pull that into the page.


So it's kind of on the page.


We can kind of see that.


It's obviously not as good as if we have normal, real HTML text


that we can pull in.


So that's one aspect.


And on the other hand, for the rich results types,


we do check to see if this text that you've marked up,


for example, if you're using JSON-LD markup where it's not


marking up the HTML itself, we do


check to see if that is actually visible on the page.


So that's something which is kind of colliding


in a weird gray zone area where I would say,


it's possible that it would work,


but it's definitely not guaranteed.


And it's probably not something that I would try to rely on.


So if you really need to have the FAQ rich results


visible for your pages, or if there's


some other type of rich result type


that you really want to target, then I'd


recommend making sure that you're really


using text on the page and not putting the text in images.


I see that Google does web hosting with a specific web


domain.


I'm learning every day, and I was


wondering if you can use WordPress


on a domain hosted by Google.


At this time, I'm using WordPress


with another company hosting the domain


and using Google products like YouTube for my business.


Is there any advantage or disadvantage


to group everything under Google?


So first of all, I don't know exactly how the hosting


side at Google works.


So that's something kind of on the side.


And my understanding is you can run normal servers


on Google Cloud, for example.


And with that, you could run WordPress as well.


But my understanding there is you basically


have to configure those servers yourself,


and you have to get all of that set up and maintained yourself.


So probably there's a lot of technical effort involved


in running WordPress on Google Cloud.


And if you're just getting started,


maybe that's kind of too much to really make sense


for a smaller website when you're just getting started.


I don't know.


It's possible there are easier ways


to do that on Google Cloud nowadays,


but that's kind of how I remember it.


There are other setups that you can use that run on Google


Cloud as well, which are a lot easier to use,


for example, Blogger or Google Sites.


However, they're set up completely separately.


So if you're currently using WordPress,


you'd have to essentially recreate your whole website


on those other services.


My recommendation in general for this


would be to try to find a good hoster.


If you want to continue using WordPress,


maybe you already have a good hoster that's


taking care of things like updates


and making sure that all of the security patches are installed,


all of those things.


Those are really important if you're


hosting your website with a service like WordPress.


So that's kind of what I would aim for there.


With regards to hosting everything under Google


or not, that's something from a search point of view


is totally up to you.


You can use everything on one hoster.


You can use multiple hosters to host your content.


You can even do things like hosting your textual content


with one provider and your images with another provider.


That's something that some sites like to do.


There is no advantage or disadvantage


from a search engine optimization point of view


of hosting everything together.


There are sometimes speed effects


that play a role, where depending


on how you set up your hosting, how you configure it,


your website might be faster or be a little bit slower.


But those are kind of technical details that


apply to any kinds of hosting.


So it doesn't matter from our point of view for search.


If you host everything with Google


or if you host everything with different providers,


that's totally up to you.


And from a practical point of view,


I would aim for something that is secure, that works well


in the long run, and that makes it easy for you to maintain.


So you essentially decide what level of effort


you want to put in for maintenance.


And if you're OK with doing a lot of hands-on work


to keep your server running, then maybe host it yourself.


If you prefer to have someone else take care of this


and make sure that nothing breaks while you're


on vacation, then I would work to find a good hoster that


does all of this for you.


OK.


Wow.


All of the people trying to join in kind of


keeps pinging up here, and I have to admit them all


in individually.


So that's kind of weird.


I hope you don't hear the ping noise every time.


We'll see if I can find a way to avoid that.


I'm having a tough time getting the mobile index to recognize


my site's new code.


The desktop bot season indexes the update, but on mobile,


Google still sees and displays the old site's code,


meta tags, et cetera.


I would probably need to know a URL from your website.


So it sounds like you posted this before.


If you have a thread in the Webmaster Help


Forum that I could take a look at, that might be useful.


In general, it's not that we have a separate index


for mobile indexing.


Essentially, we have one main index, and in that index,


we keep either the mobile version or the desktop version


depending on whether or not a site has switched


to mobile-first indexing.


And that's essentially the version that we use in search.


The one aspect that's a little bit, I don't know, different


is if you have a separate mobile site,


then we will index, again, the same version,


so either the mobile or the desktop version.


But we'll show the separate mobile site


in the search results for users on mobile devices.


So that might be something that you're


seeing that we're showing the separate mobile URL for users


on mobile.


Another thing that you might be seeing


is that in the mobile search results,


the UI is a little bit more limited in the sense


that the page isn't as big as on our desktop.


So things like titles and descriptions,


they have to be a little bit shorter.


And that might also be something that you're seeing,


that on desktop, we're able to show your full title,


for example, and on mobile, we have


to shorten it to match what would fit on the screen.


And by shortening it, we essentially


process it algorithmically to figure out


what would be a good title for this search result.


And sometimes that can result in our algorithms


picking something that's not really


what you would want to pick.


So it's not so much that we're indexing


the wrong version of your pages, but more


that we're indexing a version of your page.


And the one that we're showing in the search results,


that might not be the one that you'd prefer to have shown.


But I'm kind of guessing here at this point,


because I don't really know what your site is


and what that looks like.


So if you have a thread in the Webmaster Help forum


where you could point to and where you have some details


on what the search results look like, it will be really useful.


Hi, John.


Hi.


So regarding this mdot and the WWI,


I just wanted to know one thing.


What happens, just reverse-wise, what


happens if one person does not have content in desktop,


but has content in mobile and a smartphone is redirected to mdot?


In this case, in desktop, that content will be shown.


Just reverse to older days.


So how do you mean again if 1% of the website is desktop only?


No, no, no, no.


Not like this.


But some piece of the content is available in mdot version,


which is not available in www version or desktop version.


And because it is mobile first, so it is redirected to mdot,


finds that content.


In this case, the truth is that in desktop, that


is not available.


How will we assume that in desktop,


whether it is available or not?


With mobile first indexing, we would only


index the content on the mobile page.


So if there's less content on the mobile page,


we would be able to index less.


And if there's more content on the mobile page,


we would be able to index more.


We would still show the desktop URL for users on desktop.


But we would show those search results


based on what we've indexed for the mobile version.


So it means that the chances are that in desktop,


the content is not available, and still Google


will be showing desktop result.


That's possible.


Yeah.


I mean, it's probably pretty rare,


but theoretically, it's possible.


Yeah, yeah, yeah, obviously.


Thanks.


Sure.


All right.


Is using display none for text images content bad for SEO?


For example, I want to hide some keywords,


as I suppose it doesn't make any sense,


but webmasters still do it.


So you can hide text on a page.


Essentially, from our webmaster guidelines,


we do have a guideline that says you should not


use hidden text on a page.


So that's one thing to kind of watch out for there.


From a practical point of view, there's sometimes reasons


why you would hide something, for example,


on an initial load of the page, where maybe you


have a tabbed interface, where if you click


on one part of the page, then it switches to a different tab


and suddenly makes that content visible.


From our point of view, that's perfectly fine.


So if someone from the web spam team


were to look at a web page like that,


then the initial kind of hidden content on the page


is clear for the web spam team that actually this content can


be made visible.


So it's not problematic from that point of view.


However, if you're using display none just


to hide text to try to put more keywords on a page,


then that's something where the web spam team might


take action on that.


That's also something where our algorithms in general


might take action on that and say, well, that


looks a lot like keyword stuffing.


And in general, I would recommend


if there is something important on your page


that you want this page to rank for,


make sure that it's visible on the page.


Don't hide it somewhere, because it's something that search


engines do watch out for this.


They are able to recognize which parts of a page


are visible and not.


And it's something that users kind of watch out for as well,


where if we show them something in search,


and they click on it, and they go to that page,


and actually what they were looking for


is not there at all, then they will feel misled.


They'll go back to search and search for something else.


They'll feel that Google did them a misservice by sending


them to a site like this.


So from that point of view, if there's


something you want to have shown in search,


and you want to have users find your pages for,


then make sure that it's visible.


Don't hide it.


Don't be shy with that.


And at the same time, don't think that you artificially


need to stuff words into your page


that users wouldn't have any use for.


But rather, think about what kind of the long-term goals


of your site are, and make sure that if you


want to rank for something, that you actually


have content for that, so that when users come to your web


page, that they kind of are all in the mood of like,


well, this is really fantastic content.


I should recommend it to other people as well.


I have a client with an online store.


It's a custom website.


Their products have many variations,


like size, different diameters, and so on for a single product.


They're listed as separate products,


which means that one product is listed multiple times


because so somehow I got muted.


OK.


So it means that one product is listed multiple times


for different sizes, which is something


where the product description is the same on all variations.


How much of an issue is that?


So this is a fairly common setup and a fairly common question


that people bring up every now and then.


From our point of view, if you have


a product with a lot of different variations,


there are essentially two approaches that you can take.


One is to make sure that the product and all variations


are indexed separately, so that you have, for example,


I don't know, a piece of pipe in 85 millimeters diameter


and a piece of pipe in 100 millimeters diameter,


and so on.


That's one approach.


The other approach would be to say that you just


have the individual products on the website,


and all of the variations are listed on that product page.


So you would have one product being a piece of pipe,


and you have 85 millimeters, 100 millimeters, 150 millimeters,


diameter, all of these variations as well.


So those are kind of the two approaches


that you can take there.


And from a practical point of view,


I usually recommend that you try to work on having fewer URLs


rather than more URLs.


So I would tend towards trying to go


to having one product and all of those variations listed


on that same product page, just because it makes it


a lot easier for us to kind of crawl the rest of your website,


because you don't have as many URLs,


and because of you only having one main product


page for this type of product, it's


something where it's a lot easier for us to recognize,


well, this is really the landing page


that you want to have shown for queries about this product.


So that's kind of the one approach.


On the other side, if you're saying


that the individual variations of this product


are so important that people explicitly search them out,


then maybe it would make sense to have individual landing


pages for that.


For example, if you have different size pipes,


maybe that's not so much of an issue.


But if you have this one really unique size that is not


a standard size that people need for, I don't know,


some random purpose, and they explicitly search for that,


then that's something where maybe it


would make sense to essentially provide that on a separate page


as well.


So those are kind of the two approaches


that I would take there.


With regards to how much of a problem


is it to having all of the variations listed


as individual products, that's not really


that much of a problem.


Like I said, it's really more a matter of, well,


we have to crawl all of these different variations.


We have to index them all individually,


and we have to figure out which one of these pages


to show prominently for your site for queries for that


product.


So it's something where probably for different sizes,


it would make sense to fold them together.


For things that are really unique variations,


I would tend to separate them out into separate products.


SPEAKER 2


I have one similar question on that.


So we have a whole website for our hotel rooms


or for the specific hotels.


So we do provide our landing pages.


And that basically, our tactic in my infrastructure


that it's keep on changing with the parameter.


So how do we tackle that part?


We have already added canonical, but I


have seen a lot of the indexing or the crawling


is starting happening for all those kind of things.


So is there a kind of only way to come in


and we can handle just by the canonical or somehow we


can put the fixate like comments so that Google


can able to see that they have a lot of variation


for this particular product, but ultimately,


somebody will want to rank for one page?


I didn't quite understand the whole question.


There's a lot of noise in the background.


I think what you're saying is you


have a lot of different URL variations for the same product


page, essentially?


SPEAKER 3


Yes.


OK.


So that feels like it's essentially


a question of how to encourage Google to pick one canonical


URL and focus the crawling and indexing on that one.


Is that right?


Yeah.


So for that, there are different things that you could do.


If this is something that is really


on a large scale for your website,


then I would recommend looking at the URL parameter handling


tools, especially if these different URL


variations are with different parameters attached to it.


So everything behind the question mark


where you have maybe, I don't know, affiliate key equals this


or, I don't know, color variations equals this,


then that's something with the URL parameter handling tool.


You can give us a lot of information


on which URL parameters are important


and which ones we can skip.


That's one thing.


The URL parameter handling tool is a bit tricky in the sense


that if you tell us parameters are meant to be ignored


and actually they're important for your website,


then probably we will still ignore them.


So that's something where you have


to make sure that you're not telling us to ignore too much.


The other things that can help are essentially


the normal things that you would do within a website.


So trying to make sure that all of the internal linking


goes directly to the URLs that you want to have kept.


That's something that helps a lot.


That ideally you have redirect setup to the URLs


that you want to have kept.


That you use URL canonical to tell us about the URL


that you prefer to have kept for those individual variations.


And that you put the version that you


want to have kept in the sitemap files as well.


So with all of those kind of hints


that you can give us there, that's


something where if we have noticed


that there are multiple URLs that they lead to essentially


the same product page or the same hotel or same location


page, then we'll take all of those URLs


and try to figure out which one of those


we should focus on the most.


And we use all of those different factors


to figure out what the best canonical


URL for this case would be.


And when we pick a canonical URL,


we tend to show that more in the search results.


Not that it would rank more, but kind of instead


of the other variations of that same URL.


And we would try to focus our crawling on that variation.


So for example, if you have a URL with a parameter


and a URL without a parameter, and we pick the one


without a parameter as canonical,


we'll probably crawl the one without a parameter


a lot more frequently than the other ones.


So that makes it a little bit so that it's less a technical


issue with regards to crawling.


But obviously, we still have to discover all of those URL


variations first before we can pick a canonical.


So if you're creating a lot of new content,


and at the same time, lots of separate URL variations


are available for that new content,


then that still means we have to spend a lot of time crawling


all of those variations for one time at least,


and then figuring out, oh, we can pick a canonical


and focus on the canonical URL.


Thanks, Sean.


So it's a lot of things.


So basically, I can just tell you the scenario over here.


So we have one, the one with parameters


that will have a check-in, check-out sort of parameters.


The other one with the rooms where I do it,


you can set a category of the rooms.


So usually, for internal, for internal purpose,


we try to keep it as a without parameters.


But for certain cases, let's say,


from the JS links or something, it's


somehow linked as well from the parameters URL.


So that's my question.


If I look at the kind of my link profile internally,


so the majority of the links are coming through the parameters.


It's not with the, you can say, without parameters.


So in that particular case, I'm assuming


that Google will give more weightage to the parameter


URLs.


Basically, they are linked more as compared to my other ones.


Yeah, I think in a case like that,


if you can't kind of change the internal linking,


then I would focus on all of the other aspects,


especially the URL parameter handling tool.


I think that would probably be really useful for you there.


And for canonicalization, we don't just focus on one aspect.


We look at the bigger picture.


And we kind of say, well, these factors align with this URL.


And these factors align with this other URL.


And these are more important.


So we'll pick that URL.


So that's something, sometimes you


can't fix the internal linking.


Or sometimes you have issues where you can't


place a canonical on the page.


And it's not that we require all of that to be the same.


But the more consistent you can make it,


the more likely we'll follow what you prefer to have.


Sure, thanks, John.


Sure, thanks, Arjun.


John, can I just have one follow up on the same thing?


Sure.


So canonical and URL parameter, if we are using both,


does it mean that we are telling Google not


to crawl that particular page?


Therefore, it will never see the canonical.


So like in the URL parameter, I am adding no URL


to be crawled after this parameter.


But all the URLs are there.


And they are pointing to canonical.


So canonical will not be seen by Google.


If we can't crawl those URLs, then we


don't see the rel canonical link there.


That's correct.


So with the help of URL parameter,


I am telling Google not to crawl, not by robot.txt.


So with the URL parameter tool, there


are different options that you can provide there,


including, I think, telling Google


to crawl one representative URL instead of these URLs.


So I don't know exactly what the phrasing is in the tool


offhand, but there are different variations.


A specified URL probably.


Yeah, yeah.


It's something where with the robots.txt, for example,


you basically say, don't crawl this.


But with the URL parameter tool, you


can give a little bit more nuance and say, well,


these are sort orders, for example.


And this is the default. And just use that one to crawl.


But with parameter, then the canonical URL,


I cannot specify?


No.


I don't know how the tool works kind of directly.


But it's something where, I believe, for some variations,


you can say, crawl this variation of the URL.


And in cases like that, we should be able to.


Let me just check.


So yeah, John over here, I come in.


Google provides first two options,


whether the content is being changed or not.


If it is not changing, then it's something


we have to pick an option, OK, let the Google decide.


And if the content is changing, then it


gives you the option in what manner it is changing.


So maybe it is sorting, is it filter,


or maybe you have a different sort of combination.


Or even though if you do not show,


maybe you can leave it as blank and then just select


whether you want that URL to be crawlable or not.


Yeah, yeah.


I just opened the Help Center page,


and it basically has different variations.


So it's something where you can tell us


which one we should pick.


So, Ramesh, this is the case for duplicate URL


after you are at the query parameter.


All the URLs are duplicate content.


In this case, I want to tell Google not to crawl any URL


after that parameter.


So in this case, John, I cannot use canonical.


Why?


Because canonical is main page, not after any query parameter.


I don't quite understand.


I feel like it would be really useful to have


explicit examples of what you're looking at there.


And for that, it would probably be useful to have something


like a help forum post where you have some exact URLs


that we can look at and kind of give some input based on that.


So I think that would be useful because it's


really confusing doing that just live in the Hangout.


And I have to double check the settings in Search Console,


how that actually looks.


Yeah, sure.


Sure.


All right.


Yeah, hi, Joe.


Hi.


How are you?


Yeah, John, I have the same route in URL structure.


So let's say I have a URL in a folder level.


So after domain.com and after one folder is there,