All the tabs in the report will update to provide you only image search results.


Performance reports in Search Console - Google Search Console Training

You can then review the queries, the pages, and the countries that are working best for


image search.


Check the trends for desktop and mobile by adding a device filter.


In this case, it might also make sense to use a comparison filter, choosing both mobile


and desktop.


This will add both devices to the chart and tables and allow an easy comparison between


them.


It might be interesting to look at a CTR comparison between mobile and desktop for queries, pages,


and countries.


This information can help you understand your search audience better.


Check where your site is trending upwards and downwards by adding a country filter.


Visit the countries tab of the report and click the country with the highest amount


of traffic.


This will filter the entire report to include only this country.


Make the pages and queries most common in this and other high-traffic countries to inform


your international targeting strategy and localization priorities.


Note that when filtering by queries or pages, the results shown in the chart might not add


up to the total shown in the table.


For example, if you create a query filter not containing your brand name and another


one containing your brand name, they will probably not add up to the chart total.


The reason is that there are some queries that are anonymized by Google for privacy


reasons when filtering.


In addition, there is a limit to how many queries the table can show.


See the documentation to learn more about this.


Another important detail about the data is that when looking at different parts of the


performance report, part of the matrix is aggregated by site and part is aggregated


by URL.


These can generate a few discrepancies.


I won't go over all the details, but I suggest you visit our Help Center article using the


link below to better understand the data available.


Well, I hope you learned a few tricks to understand and optimize your performance on Google Search.


In the next video, I'll go through the URL inspection, which is a valuable tool to help


you understand how your page is appearing in search results.


Or if not, why is it so?


Don't forget to subscribe to the Google Webmasters YouTube channel, where we'll be publishing


lots of Search Console videos.


English Google SEO office-hours from October 30, 2020

All right, welcome, everyone, to today's Google SEO


office hours.


My name is John Mueller.


I am a search advocate at Google here in Switzerland.


And part of what we do are these office hour hangouts,


where people can join in and ask their questions


around their website and web search.


A lot of questions were submitted already on YouTube,


so we can go through some of those.


But if any of you want to get started


with the first question, you're welcome to jump in.


Hi, John.


I've got a question about passages.


OK.


So obviously, the new release of the core update


regarding the passages has been announced.


So it's more about how Google will see


the structure of a paragraph.


Because obviously, more recently, we're


seeing more conversational kind of blog posting,


like on Backlinko and people like that.


And I'm wondering if there is kind of a minimum word count


or character count within a paragraph to Google


realize that this is a paragraph.


I don't know.


So I guess there are a few things that fall in there.


I don't have the details of all of the passages things.


A few comments.


It's not a core update.


It's not.


I mean, we wouldn't consider it a core update.


I think core update is kind of an arbitrary term anyway.


But it's not what we would consider a core update.


It's more about ranking these passages from existing pages


rather than indexing them individually.


So more about recognizing this is a big page


and this is a part of the page that


is particularly relevant to this query that is coming.


So we'll focus on that part of the page.


So it's not that there's a separate passage index


or anything like that involved.


It's really more about understanding


the page and the different parts of the page


and being able to recognize which of those parts


are relevant for a user's query.


I don't have much more details past that


to share from our side.


I did notice there are some folks that


have been digging up patents and papers and kind of the more,


I don't know, what would you call it, educational content


or theoretical content around some of these topics.


And they mentioned there are things


like you should make sure that you have clear headings


and that you have well-structured content


on your pages so that we can recognize these sections,


which to me is kind of obvious.


If you want Search Engine to recognize a part of your page,


then you should structure your page properly,


that it's easy to recognize.


But maybe that's kind of a direction to head.


In general, with a lot of these changes,


one thing I would caution from is


trying to jump on the train of trying


to optimize for these things.


Because a lot of the changes that we make like these


are essentially changes that we make because we


notice that web pages are kind of messy and unstructured.


And it's not so much that these messy and unstructured web


pages suddenly have an advantage over clean and structured


pages.


It's more, well, we can understand these messy pages


more or less the same as we can understand clean pages.


So if you take a clean page and you try to make it messy


so that it works well for this new kind of setup,


then I don't think you would, under the bar, kind of


have any advantage over what you had before.


Where if you already have clean pages,


if they're already easy to recognize by search engines,


if they have clean titles and headings,


and they focus on individual topics,


then that's essentially what search engines


need to be able to understand what this page is about


and when to show it to users.


OK, thank you.


Sure.


Hi, John.


Hi.


I have actually three questions.


So last week I asked you about changing websites.


So this week I'm going to ask you some more question


about website changing.


So this is about one of our clients.


So they are moving their website from WordPress to Zumba.


And we are expecting that it will affect their current URL


structure.


So we are planning to use 301 redirection


to minimize any sort of ranking loss.


But even if we do the 301 redirection,


is there any possibility to see losing rank initially


after launching the website?


Yes.


I mean, it is kind of frustrating to hear.


But yes, there's always a chance that something will go wrong


and that you will drop in rankings.


And I think it's not so much that something randomly


will go wrong and break.


And it's like nobody knows why it suddenly breaks.


But if you change the website structure in the sense


that you're changing all of the internal URLs,


you're changing the internal linking,


usually that also means you're changing the layouts,


all of these things can play a role


in how we understand a website.


So things like suddenly this page has no internal linking


or only one internal link, and it


used to be very important internally,


then that's something that can affect how that page ranks


in the search results.


So it's not so much that you set up the redirects


and then suddenly something randomly breaks.


It's just you have a new website structure.


And that new website structure is different from the old one.


And it might be that the new structure is much better


because you worked so hard on making sure


that it works well for SEO.


It has clean titles and headings.


The internal linking works really well.


You use the right anchor text, all of that.


And the new structure might be ranking much better.


It might also be that you change to a different CMS


and you install the default setup from the CMS


and the default setup is not optimized


for your business or your site, then the site's ranking


could go down.


So from that point of view, it's something


to keep in mind that 301 redirects


is one part of a change within a website,


but there's a lot more involved when you make


a bigger change on a website.


SPEAKER 2


So the next question is about the same client.


So they are actually an organization, non-profitable.


So they have a lot of clubs in New South Wales, in Australia.


And each club provides various type of activities,


like boxing training, gym and fitness training,


this sort of training.


Now, the current website has individual page


for each activity.


So they have two type of website.


One is corporate, another one is a club.


So corporate and club both have individual page


And each of those activity page has ranking on Google.


Now, what they're planning to do,


they are planning to consolidate all this activity in one


activity page for corporate and club site.


Now, we are assuming that there will be


a ramification of doing this.


I just need to know how much it can affect,


because they are planning to consolidate all this page,


to consolidate it in one page, because some of the activities


are boxing, some are badminton.


So it will be very difficult to write a title tag for all


these activity that will be long title tag.


So we are not sure what to do.


So who do you think?


Yeah.


I think that's also one of those questions where it depends.


It sounds like you have multiple pages now


and you want to reduce the number of pages, right?


Kind of just very roughly.


Yes.


OK.


So essentially, what would happen theoretically


is that if you focus your site more on fewer pages,


then those fewer pages will be stronger in search,


and they could be more visible in search.


So generally, that's a good thing.


On the other hand, it also means that those fewer pages


will be less focused on those individual topics.


So if someone is searching for that variation


that you currently have a page for,


and afterwards you have folded that


into kind of a general variation,


then it might be that that search is no longer very


relevant to those pages, and we don't


show your pages for those queries.


So what I would do there is look at the queries that


are leading to the current pages and think


about which of these queries you can still


kind of fulfill with the new setup that you have.


And if you notice that overall, the important queries


that you care about, the ones that you have high ROI on


where you get good traffic and it converts well,


if you see that those queries can still


be fulfilled with your new pages,


then I think you're on the right track,


because then you have fewer pages,


you're still fulfilling the needs of the people


that you can kind of interact with,


and those fewer pages will be much stronger.


So that's kind of like all of the good things.


Whereas if you can tell that with your fewer pages,


you're not going to be able to fulfill these queries,


and these queries are very important for you.


Maybe these are things for products or services


where you have a high return because you earn


a lot of money from them, and a lot of people


are searching like this, and suddenly you


realize your new pages are not that relevant for that anymore,


then that's something where I might reconsider and say,


well, at least for this topic, we


should continue to have something separate.


SPEAKER 2 Thank you, John.


JOHN MUELLER Sure.


All right.


Any other questions before we jump in?


Yes.


SPEAKER 3 Hey, John.


Hey, John, may I ask a question?


SPEAKER 3 About first navigation,


I will post it here.


So I just noticed there are two way people usually deal with it.


One way is to use pagination pages.


When you click a certain first navigation,


they go to a page that will list a certain product.


And if there are too much product,


they will use pagination to list all of them.


And another way is that when you scroll


to the bottom of the page, they will use


Regex to load more products.


And my instinct is that Regex approach is not


as good as the original one, because Google might not


be aware of all the product that you have for that navigation.


But how do Google actually realize that all the product


that you have for that specific navigation,


if you use pagination, will they consolidate all these pagination


pages into one so they know, oh, when you click,


for example, under $10, and they are aware of every inventory


that under $10?


Probably not.


So I think there are a few things that


come into play there.


On the one hand, normally through the category pages,


we need to be able to find the individual products.


That's kind of the baseline configuration


for an e-commerce site that we can


find the individual products.


And usually that happens through the category pages.


Often it's through paginated category pages.


Often there's also cross-linking between different products.


So that's kind of the baseline that we


know all of these products.


And then for the individual facets and filters,


usually my recommendation is not to let those be indexed at all,


but rather to focus on things where, I mean, usually


the thing with all of these facets


is that you're essentially recombining the same products


that you've already shown in the category pages


just on separate facet pages.


And if you feel that these facet pages are


pages that can stand on their own,


then that might be fine to let them index.


If it's really important, a really critical topic


for your site is, I don't know, running shoes under $20


because that's your brand or whatever,


then you can see that as a kind of a category page.


And you can keep that indexed.


But I would generally recommend at least


having the paginated pages within these facets


not being indexed because you don't gain


any value from doing that.


So it's not that Google will think, oh, all


of these products belong into this category.


We will concentrate them on the first page of the set.


But rather, we'll crawl all of these pages.


And we'll crawl a ton of pages from your website


if you let us index all of these facets.


And we essentially don't get much value out of page five,


out of this specific facet from your e-commerce site.


So usually, the recommendation there


is either don't index any of the facets


or only let those be indexed that you think are


really critical for your website.


That's kind of the baseline.


And with regards to pagination or that kind


of automatic loading, what is it, lazy loading,


where you scroll to the bottom and then it loads more,


that's essentially, those are different ways of doing it.


And if you use pagination, we can definitely


crawl through that.


So for category pages where we need to crawl the pages,


pagination is probably the best approach.


The lazy loading can also work to some extent.


But you need to implement it in a way


that Google can process it.


So in particular, we load the page once.


And then we see what all is loaded on that page.


And if your site requires that you


scroll to a certain position on the page,


and then suddenly more content appears,


then Google will not see that.


So we won't be able to see any of that kind of automatically


loaded content if we have to do something


specific to make it load.


I see.


So one follow-up question is that you


say for fascinated pages, they won't consolidate it


to the first pages of pagination.


And they probably won't be aware of what kind of inventory


they have in a certain specification.


But how about category pages?


You say you recommend we index the category pages.


So if we do have pagination in category pages,


do Google will consolidate it and know


that in certain category, even they


have several pagination, they know that in certain category,


they have all the inventory that we assign to them?


No, we wouldn't assign the products


to a specific category.


We would use the paginated category pages


to find the products.


And we know, OK, here's a product page for, I don't know,


some specific shoe or whatever.


But we wouldn't kind of keep that connection


between this shoe and that category page.


So usually what happens is if someone searches


for a category of product, we'll show probably the first page


from the category page set.


And if someone searches more for a specific product,


we'll try to show the product landing page.


So it's not kind of that combination of this product


is on page five of the category page.


Therefore, Google does something fancy with that.


It's more like either the category page


is relevant for the query or the product is relevant.


I see, so just one very good follow-up question.


You say that we should only index high-level test


and navigation.


But for a big website, they have a lot of product.


The high-level test and navigation


is very important because category pages might not


be fragmented enough to target more long-tail keyword.


In that case, using regex that require user input is OK,


because we don't want the pagination after the first page


to be indexed anyway.


Yeah, I think you probably mean JavaScript, not regex.


But yeah, yeah.


I mean, I understand what you mean.


But yeah, that's perfectly fine.


If you don't want those pages to be indexed


and you use one of these patterns


to automatically load the content


and Google doesn't index it, that's kind of what you want.


That's perfectly fine.


AUDIENCE MEMBER 1 I want the stuff that


haven't been loaded being indexed.


So like this page, yeah.


Yeah, yeah.


I think that's perfectly fine, yeah.


OK, thank you.


Sure.


OK, let me run through some of the submitted questions.


I also see there's a really long one here in the chat.


But let me run through some of the submitted ones first,


and then I'll get back to you there as well.


I just found out about emoji domain names,


and I saw they can actually rank in Google Search.


For example, if you Google for emoji domains.


I also saw you can search for things like coffee emoji


near me, and it would show you actual coffee shops.


So will emojis in Search and Web be


something viable in the future, especially


if we're moving into a more mobile-centric world?


So I think we already moved into a mobile-centric world.


So that part, at least, has already happened.


With regards to emojis in Search,


there's a really interesting talk from Paul Haar


that we have on our YouTube channel from,


I think, last December.


I don't know, sometime when we could still


travel from Mountain View, one of the webmaster conferences,


where he also goes into emojis in Search,


and how at some point we realized that people actually


search a lot for emojis, and we should give them


usable search results.


So my guess is not that you need to optimize for emojis


and people searching for emojis.


But essentially, what we try to do


is understand the emoji, and then we just map that


to a normal text search.


So if you search for coffee, or the coffee emoji,


then usually we should be able to understand that.


I don't know if it's worthwhile to actually optimize for this,


because my feeling is, while a lot of people


search for emojis, it's probably not


comparable to people who actually search


for textual words.


But try it out.


I think it's always cool to try out these newer things.


I guess one of the difficulties with emojis


is if it ends up being a part of a voice search


result for Google Assistant or some other assistant device,


then it'll be hard for the device


to tell you which URL to check out.


But I don't know.


We're trying to learn more about how we can get our site,


travelgay.com, to rank in the local search results


box at the top.


At the moment, it seems to only show TripAdvisor and Yelp


for keywords like gay bars in Brighton.


When we know that we offer the best and most up-to-date


content along those lines, what can we


be doing more on our site, apart from schema markup,


which we already have, to ensure that we can rank


in the local search result box?


I don't know.


So my feeling is you don't mean the map search result


that we show for local queries, but kind of that bar on top


where you can, I think, pick different kinds of aggregator


sites as well.


I don't know what all is involved there.


But I'll check with the team here


to see if I can figure something out, maybe for next time.


Yeah, this is a similar question you had two weeks ago


from someone in Poland asking a similar question.


I don't know if he contacted you,


but I was waiting, I've been speaking to him.


It's related to the local search and probably


to do with the EU kind of regulations


and stuff like that around showing other providers.


OK.


It would be good to know how to get into this.


Yeah.


I know.


I looked into it like a long time ago.


And back then, it was more about us


trying to algorithmically recognize


these sites have a lot of content along those lines


and then show that.


I don't know if kind of the more niche sites would have trouble


kind of being shown like that.


Might be a bit harder, which I could imagine


might map to smaller countries.


I don't know, Poland isn't necessarily small, but still.


And perhaps also to kind of specific topical areas


like Travel Gay is probably less visible overall compared


to something like Yelp or TripAdvisor.


But I don't know.


I think it would be nice to have more of those sites visible


there.


So I'll definitely check.


Yeah, because I work for one of the largest


private medical providers in Poland, so with like 3,000


doctors.


So we kind of compete against the searches on this.


So it would be good to understand


how we can be surfaced in this search,


because we actually own kind of also a ranking kind of website


as well for doctors, which is similar to your kind of Trip


Advisors and stuff like that.


So it's like why is one being considered above another?


Yeah.


Can you send me some details?


Yeah, I'll drop you an email.


I've got your email.


OK, cool.


Thanks.


I've seen a lot of times I got some image results


for a search term.


How does Google identify that images is good for showing


in the results?


Is Google crawling images with their binary code format


or just as a snapshot?


I don't quite understand the second part of the question.


But in general, what happens when


we show multiple kinds of search results on a page,


such as kind of that image box and the normal text results,


sometimes the video results as well?


That comes in kind of, I don't know, how should I frame it?


It happens.


So essentially what happens when someone types in a query


on Google is we send that query to a lot of different indexes,


a lot of different search systems within Google.


And we try to send it out to as many of these systems


as possible on the one hand so that we get answers from them.


On the other hand, we also get quick results.


So we can, like if we have really,


the web results come back really quickly,


and images take a longer time because, I don't know,


somehow images are a bit slower today, then at least we


have the web results that we can show.


But essentially, we send it out to all


of these different systems, and the systems


tell us how relevant the results are that they have.


So the image search system might come back and say,


oh, image results are kind of important for this query.


And here's a set of images that I have for that.


And if we get the web results back and the web results say,


oh, web results are super relevant for this query,


then we might show the web results and not


the image results.


On the other hand, if we hear back


from these different systems and they say,


oh, image results are super important for this query,


and the web results are kind of OK as well,


then we will almost certainly show kind of an image one box


somewhere in the search results.


That might be on top.


If we think that's super critical,


it might be somewhere in the middle, anything like that.


And the same thing happens for video.


And I imagine for the different other types of kind of one boxes


and things that we have as well.


I don't know.


Maybe top stories.


I don't know how all of that flows in.


But essentially, all of these different systems


come back to that one central place and say,


here are my results, and here's how relevant I think they are.


And based on that, we try to figure out


which of these elements we should show.


So that's kind of how the images flow in there.


It's not that someone is manually saying,


oh, we should show images for this query


and not for that one.


It's really these systems are trying


to understand how relevant the results are


that they can bring back.


And based on that, we try to make an automated decision.


And that's also why this can change over time, where


if you search for something now, then maybe we won't show images.


And if we recognize that everyone is actually looking


for images for this query, then over time,


we will start showing images in the web search results as well.


And I guess regarding the second part of the question,


I'm guessing you're kind of asking


if Google is just taking the image as an image file


or if they're looking at the contents of the image,


like there's a cat on this image or not.


And we do a bit of both.


For the most part, we do take focus on the image file


and on all of the context around that image,


because that really helps us to understand


why this image is relevant.


And if we don't have a lot of information otherwise,


then we might try to understand what this image is about


as well.


It's tricky from my point of view


to focus purely on what is visible in the image,


because it might not be why this image should be ranking


in the search results.


So it could be that you have a photo of a beach,


and you use that in a travel blog, where you're like,


oh, look at this fancy beach that I visited.


It could be that you have a photo of a beach,


and you use it on an article about environmental pollution,


because it's like, we want to preserve our beaches.


And those are very different use cases and very different ways


and times that we should show this image.


So that's something where purely from understanding


the image's point of view, we need


to understand essentially how that image is embedded


within the web page.


And that's something you can do with the alt text,


with headings and titles on the page,


understanding sections of a page better, captions,


if you have anything like that, the file name for the image


as well.


All of these things play a little bit


of a role in how we understand the image and its context.


My website is already on HTTPS, but still missing


the content security policy header


whenever scanned from a tool.


Does that have any effect on rankings,


and how does Google look into it?


I have to be honest.


I don't know exactly what the content security policy


header is, so my guess is it's probably not that critical.


I don't know.


But in general, when it comes to HTTPS,


we try to understand which of your pages


should be seen as the canonical version of your content.


And usually, that's a matter of we have some HTTP pages,


we have some HTTPS pages, and we see


the HTTP pages are redirecting to the HTTPS version.


And internally, you link to HTTPS.


So we will pick the HTTPS version as the canonical.


And we will do that even if your certificate is no longer valid,


even if you're missing something critical on a page,


even if there is some content within the page that's


not on HTTPS, where if you load it in the browser,


it has kind of that warning icon on top.


Even in those cases, we will probably shift to HTTPS


just because all of the other signals


tell us HTTPS is the right one.


And when we shift our indexing to HTTPS,


then essentially all of our ranking factors


that apply to HTTPS kind of kick in and apply there.


So if there are things with regards to security


that you could be doing better but you're just not doing


perfectly at the moment, which might be something


like the content security policy header,


then that's something I would definitely recommend doing.


That's something that sounds like you probably


need to do to make sure that you have a modern and secure


website.


But at least from an SEO point of view,


it's probably not critical for your site's ranking.


So if you, I don't know, I don't know how to frame it.


If you care about your users, then probably you


should make sure that you have all of this done.


If you just care about SEO, then probably that's fine.


My question is regarding the bounce


rate of an affiliate site.


It's designed in a way that we want the user


to consume information and then bounce them


to an affiliate site as soon as possible.


In a way, we only earn when someone


clicks on those affiliate links, which eventually


causes a poor bounce rate.


What's your take on this since it


might be a factor for rankings?


Essentially, that's totally up to you.


You can set up your pages like that.


But what happens on our side is that we


don't care so much about whether or not


a site is an affiliate site, but we care about whether or not


your site provides information that is relevant for us


to show in the search results.


So if people are following the links


and going to a different place to buy something


from your site, theoretically in analytics,


that might be something that is flagged as a bounce.


I don't know how analytics compiles that overall.


But if people are going to your site


and finding the information they need


and then going off to buy it somewhere,


then that's essentially perfect.


On the other hand, if people go to your site


and they're like, there's no information here,


or this is just the same information


as all of the other sites, and they


click on your affiliate links, then that's something that's


kind of, from our point of view, not that useful.


Then we might as well just show the affiliate link


target as a search result and not your site.


So it's not so much the matter of, is it an affiliate site


and driving traffic somewhere else,


or is it a site that's selling things directly,


or is it just an informational site?


It's more a matter of, does your site fulfill


what the user was looking for?


And for that, it's not something that I can purely


judge automatically.


It's something you kind of have to look at on your own


and figure out, am I really providing something


unique, compelling, and of high quality that


would be indexable, even if there were no affiliate links


on there at all?


Real-time dashboard versus process report.


Real-time direct is three times higher than process data.


I think this is about Google Analytics.


I don't really have any insight there,


so I can't help with that.


Somehow, our 20-year-old business


has created two websites of almost the same primary


content.


Both domains are 15 years old.


Same categories, same product pages,


except variations like UI.


On one domain, we show more textual content,


curated reviews.


The result is we get product page traffic on one domain


and category page traffic on the other domain.


If we cross-canonical those domains, can that help an SEO?


Yeah, I think, I mean, somehow, over 20 years,


lots of things get collected.


So that's kind of normal.


In general, if you combine your site


and make one strong version out of two kind


of medium-strong versions, then usually that's a good thing,


especially if you're targeting the same audience.


If, essentially, your message and the conversions


that you're trying to achieve are the same thing,


then it definitely makes sense to combine things


from my point of view.


On the other hand, if you're targeting


completely different audiences, then maybe that's


something where you kind of have to make


more of a judgment call.


So a common use case that we sometimes see


is B2B versus B2C.


So if you're selling directly to users


or if you're selling directly to businesses that then sell it


to users, sometimes it makes sense


to keep these websites separate because you're targeting


something completely different.


The messaging you have on these pages


might be completely different.


And in those cases, it might make sense to keep it separate.


On the other hand, if it's just like, naturally, over time,


you somehow collected multiple websites


and they're all trying to do exactly the same thing, just


different departments and different people over time


trying their hand at making a website,


then that's definitely something that's worth combining


and saying, we will take all of the good parts of all


of these websites and make one really strong website out


of it.


And probably, you will see some improvements in search


if you're able to do that.


ZH undrafted religion I posted it to my question


is a regarding rich results.


The choice of images and which is Alex Mehli recipes


I notice that we will use a 16-by-9 images there


and on many recipes.


I provide three different ratios of 6, 911, and 43


as Google recommends.


And I noticed that in many cases,


Google is picking the 43 or 11 and cropping


the top part of it, making sometimes the product doesn't


even appear in the image.


So I was wondering if there's something


to know about the choice of images there.


I don't know.


I heard that from another recipe site,


but I've stopped hearing from them about it.


So either they gave up or it's working now for them.


But if you can send me some examples


or if you posted it in the question,


maybe just add a reply to that and add some examples there,


then I can pass that on to the team and we can take a look.


Sure, sure.


We'll do that.


Sure.


Thanks, John.


OK.


Let me run through some more of the questions here,


and then we can open things up for everyone as well.


The request indexing tool in Search Console


has stopped any update when it's coming back.


It would be welcomed.


I don't know when exactly it'll be back.


I know that the team is working on improving that, though.


My ranks have dropped heavily with the core update for May.


So since then, I'm trying to improve to come back from it


in every way that I can by updating my posts


and trying to improve my content daily.


Does a webmaster in this situation


need to wait for the next core update,


or can a result be felt without that?


This is kind of a tricky question in the sense


that depending on what all happened with the last core


update, you can definitely see improvements over time


in the sense that what happens in search


is we have all of these different factors that


play a role depending on the query and the site.


And it might be that from one of the core updates,


like one of those factors is smaller,


but you can work to improve the other factors


and make them stronger again.


So overall, you can definitely move things around a little bit


to improve over time.


But if that effect from that core update


is so strong that you can't compensate it


with the other factors that you can work on,


then it'll be hard to reach that barrier again.


But it is something also from our side


where we say the core update isn't necessarily


the sign that you're doing anything wrong,


but rather that we just figured out


or we kind of realized that maybe your site wasn't


the most relevant for some of these queries.


So that's something where it's not always the case that we


would say you could just tweak things and slightly improve


things on your site.


And then suddenly it will become relevant


because sometimes relevance is something that requires a lot


more compared to just slightly improving your posts


and maybe adding some content every now and then.


So I don't know if this is something


where if you're seeing a really strong change in how we were


showing your site in search, if it's actually


a matter of just tweaking things,


or if you need to kind of reconsider overall what you're


doing with your website and making sure that overall you're


really super relevant for these queries.


And it's something where if we were to show it


to the engineering teams, for example, they would say,


yes, there's a bug in our systems


if we're not showing this site as a first result


for those queries.


So it's not a matter of how can I


make my site kind of similar to the other sites that


are ranking there, but really how can I


make sure that my site is by far the best


result for these queries?


And that kind of a change is really hard.


So usually that's a lot more than just kind


of like updating a few blog posts


and adding some content every now and then.


And then please don't take too long


to update, upload the next video.


Yeah, OK.


I'll try to get it in this afternoon.


Sometimes we have to wait a little bit because other teams


or other folks are also posting things to the YouTube channel


and we don't want to kind of like bombard people


with videos on the same day.


Question about discontinuation of Flash.


I work on an online gaming site where we serve


quite a lot of Flash games.


In terms of quality, they occupy roughly 50%


of all pages of the site.


But in terms of organic traffic, they


only account for about 10% of our total traffic.


After December 2020, should we anticipate


a complete loss of traffic only to this portion of the site,


or will there be wider site repercussions


if we don't take steps to remove all of those pages that


serve Flash games?


So I think I saw this question in one


of the previous Hangouts.


I don't know if it's like the same question or the same


person.


That's fine.


In general, when it comes to Flash, the previously,


I think we stopped doing this.


Previously, it was that we would take the Flash files


themselves and try to understand what textual content is


within these Flash files and see that


as a part of the indexable web content for those pages.


So that particularly makes sense for Flash websites


where the whole content is in Flash.


When it comes to Flash games, however,


it's not that there is textual content within the game that


is relevant for indexing, but rather,


the text is all around the Flash game.


And we can use that for indexing even


if we don't take into account anything from the Flash


elements at all.


And I would expect that after December 2020,


I think December 2020 is when it's removed from Chrome


or something like that.


But I would expect that nothing changes for your website


in that regard at all with regards to indexing


because we already focus on the textual content of the page.


And we kind of ignore the Flash part of the page.


So at most, I would expect that people maybe


search differently at some point,


but not that we would drop these from search


or drop them in rankings.


Sure.


Yes.


SPEAKER 2.


John, can you hear me?


Couldn't have any indirect ranking.


Maybe users are searching for Flash games,


but they're not getting the results


because Chrome isn't supporting that.


Couldn't have some indirect effect on searching your rankings.


I could definitely see people searching less for them


over time, but I don't think there would be any kind


of ranking effect for that.


So it's something where even 10 years in the future,


if these pages still exist, if someone searches for Flash


games, we will show whatever content we have for Flash games


and that would likely be pages like this,


even if nobody even knows anymore what a Flash game was.


So I wouldn't expect that to drop.


What you might see is if people are searching for,


I don't know, a specific game type where I don't know.


I forgot what the game types are called.


But where if they're searching for a specific type of game


where you have kind of like maybe a normal HTML5


game or an installable game app or game for game console


and you also have Flash games, then I


could imagine for that generic game type query, then over time


the Flash game pages will kind of become less and less


relevant because they're less and less recommended by users


and they're less useful for users.


But if someone is explicitly searching for that game type


plus Flash or just Flash games in general,


this is the only content we have that's relevant.


So we will stick to it even if by default people might not


be able to see the Flash content.


SPEAKER 2 interesting.


Thank you.


Sure.


When I redirect from one site to another, 301 or 302,


and it contains the same content, images, internal links,


is it considered duplicate content with Google in general?


In theory, yes, we would consider this duplicate content


and we would use it for canonicalization.


But it is not a bad thing.


I think this is kind of more like in theory,


we would consider this duplicate content


because if you enter that URL in a browser,


then you would end up with the same content.


So if you redirect from an old domain to a new domain,


if you enter the old domain, then you


would end up with the same content


as if you just entered the new domain.


So theoretically for our systems,


that would be duplicate content.


In practice, we would see this as a sign


that these pages are the same and we


need to pick one of these to choose as the canonical.


And we will focus our energy on that canonical URL.


So that's something that from our point of view,


it's perfectly fine and normal and not something


that you need to worry about in terms of ranking.


So essentially, we would probably switch things over


to the new domain if you have this kind of redirect setup.


We have a site in French.


And if we only translate this content on Google,


translate into another language, is


this considered duplicate content?


No.


If you translate content, we would not


consider it duplicate content because the words


are different.


So kind of just purely from a technical point of view,


search engines are sometimes pretty simple.


And they look at the words on the page,


and they say, oh, these are different words.


So the content is likely different.


They don't look at the text on a page


and say, oh, it says the same thing


in this abstract way of when I try to understand the words.


Therefore, the content is duplicate.


We focus on the words.


And if the words are different, then the content is different.


So if it's in French and in English,


they're different words.


We will treat them as different pages.


SPEAKER 2


John, may I?


JOHN MUELLER 1 Sure.


SPEAKER 2 My question is about lazy load.


We have set up lazy load.


And when you scroll down to the place where the image is,


it loads and appears on the page.


Before the moment an image is on the screen,


there is like a gray rectangle of a random size


instead because we don't know image's size before we load it.


So imagine you have slow mobile internet,


and you are loading a page.


And the text appears.


And you scroll down, and you see a gray rectangle


at the place where an image should be.


And there is the text below.


And the moment the image has loaded, the text shifts down


because the image has the different height.


And with Core Web Vitals in general and CLS,


which measures visual stability in particular,


could that be a problem for us?


Thank you.


Yes.


Yes, it could.


That's kind of the thing that the visual stability


is focusing on, where it's like if you scroll


part of a page into view, and suddenly it shifts around,


then that's kind of what we're trying to catch and focus on.


So my general recommendation there


would be to try to find a way to embed the size of the image


in kind of the lazy loading element by default.


And even if you just showed the gray rectangle,


if the rectangle is the same size as the image afterwards,


then that results in kind of more stable page load


experience.


OK, thanks.


Sure.


All right, getting kind of close to the end of time.


Maybe I'll just open up for more questions from any of you all.


It looks like there's a lot of stuff happening in the chat,


but I haven't been able to keep up there.


So if there's anything critical you


want me to help out with, let me know.


Hey, John.


I have a question about redirect.


I remember you once said that redirect only passed


link juice if they are very close match.


So there is a situation that we want


to consolidate multiple article into one big article.


In that case, we redirect the fragmented article


to the big article with a passed link juice


because the big article will be like a broader thing,


but the fragmented will be more long tail.


Yeah, I think that's perfectly fine.


So basically, you're saying this old URL is


being replaced by a new one, and then we


will forward the signals that we had with the old URL


to the new one.


That's perfectly fine.


Yeah, and specifically referring to when


we are consolidating multiple short article to a long one


with a passed link juice.


Yeah, that's perfectly fine.


That's a very common setup that you take multiple pages,


you combine them into one.


Maybe you have multiple pages in the beginning,


and you pick one of those pages, and you make it bigger.


That's essentially all normal.


I see.


On the same token, because I remember


you once say that they have to be very close match


to be passing link juice when you redirect.


In that case, it work to pass link juice.


But what if I redirect an informational page


to a transactional page?


For example, I write a blog post about goat cheese.


What is about goat cheese?


And then one day, I decided I don't want that to be ranking.


So I redirected to the transactional page of goat


cheese with a pass link juice.


Yeah, that's also fine.


I think with regards to the content needing to be similar,


it's more a matter with the rel canonical, where you actually


have content on the page.


So if you set the rel canonical from one page to another page,


then that's something where for us, it's


a sign that you want these pages to be treated the same.


But we need to be sure that these pages are really


a part of the same cluster and to recognize, oh, these pages


are actually equivalent, and this


is the one that you would like us to show in the search


results.


With a redirect, it's essentially


the old page no longer exists.


And if you enter the old URL, then we show you the new URL.


So they're already essentially identical.


So with a redirect, that's a lot less of an issue


if the pages are different or if they change their focus,


all of those things.


So that's kind of normal kind of evolution on the web, I guess.


AUDIENCE 1 So we can even redirect


a page that has completely different content if we


think it makes sense, and they will still have link queues?


More or less, yeah.


For the most part, that should work, yeah.


I see.


Thank you so much.


Sure.


I think the one exception there would be if you go off


and just buy a bunch of domain names


and then redirect them all to one central site,


then that's something where our systems might kick in and say,


oh, this looks kind of sneaky.


But if you're changing things within your website


and you say, I don't want to sell basketballs anymore,


I want to sell shoes, or whatever,


then those are changes that you kind of decide


within your site.


And we generally just follow that.


So just one follow-up question.


I have a client doing a very weird thing.


They try to, in Black Friday times,


they redirect a certain informational page


to the transactional page.


And they try to consolidate authority


from the informational page to the transactional page


in the hope that the transactional page will


bring better.


And then they want to remove the redirect


after the Black Friday.


My thing, tell me, is not a good idea.


I don't know.


I mean, I think it's really hard with these Black Friday things


because it's just a handful of days.


And theoretically, you could make some really big changes


on a website just for a couple of days


and you change it all back.


I don't know if under the line it's really worthwhile


to do that.


And if you kind of break more things,


then you actually improve there.


But I don't know, especially if you're


struggling with kind of getting your Black Friday content


ranking when everything else is really strong,


and then I could imagine people resort


to kind of these weird tricks.


I think from a web spam point of view,


we wouldn't see that as being problematic.


From a web search point of view, we wouldn't say,


oh, this is a sign that the website is low quality


or anything like that.


I think it's purely from a technical point of view,


it's easy to confuse our systems with this.


It's not so much that it's a really bad idea


and you should never do it, but you can confuse things.


And if the end result is that when you change things back,


it takes a month for everything to be kind of restored


in the normal state, then I don't


know if you've really made a profit under the line


in a case like that.


I see, thank you so much.


I think it's also the case that just because Google follows


the redirect doesn't mean that the new page will


rank for everything the old page used to rank.


So Google might follow the redirect,


but if you redirect our informational page


to a transactional page, it's likely


that the informational page had a lot more content,


and it's likely that it ranked for a lot more keywords


that the new page probably won't.


Yeah.


And sometimes these things also take a bit of time,


where if we see a redirect and we start following it,


then maybe it'll take a day or two


to actually start seeing that effect in search.


And I don't know if for these kind of events


where it's really a matter of being there for two,


three days, if that actually works.


But I'm 100% certain people have been testing this for a while


now, and everyone is fine tuning their strategy for all


of these Black Friday things.


But I think it's just easy to also break things.


So it's good to be careful.


OK.


I think we reached the end of time.


I don't have a ton of time after this,


so I will have to jump out this time.


Maybe next time we can hang around and chat a bit more.


End of times.


It's not that bad.


It's only Friday.


It's not end of times.


Yeah.


So thank you all for coming in, and thanks


for all of the questions that you submitted.


Thanks for joining in and asking questions live as well.


And I wish you all a great weekend,


and see you all next time.


Thanks, John.


Bye, everyone.


Web Frameworks: SEO Mythbusting

When I was first building the Preact site,


Web Frameworks: SEO Mythbusting

I had it kind of all client-side rendered.


Web Frameworks: SEO Mythbusting

We weren't doing any pre-rendering or anything.


Web Frameworks: SEO Mythbusting

We are now, but at the time, I did that


Web Frameworks: SEO Mythbusting

and we weren't super concerned with SEO at the time,


Web Frameworks: SEO Mythbusting

which immediately vanished.


Web Frameworks: SEO Mythbusting

And I was definitely worried when we first pushed it live,


Web Frameworks: SEO Mythbusting

like, is this just gonna be like, you know,


Web Frameworks: SEO Mythbusting

a title on Google search with no body content?


Web Frameworks: SEO Mythbusting

Yeah.


Web Frameworks: SEO Mythbusting

So I was kind of confused with that.


Web Frameworks: SEO Mythbusting

And then there was other weird things


Web Frameworks: SEO Mythbusting

like we were doing client-side routing.


Web Frameworks: SEO Mythbusting

And in response to the client-side routing,


Web Frameworks: SEO Mythbusting

we would change the meta tags for the description stuff.


Web Frameworks: SEO Mythbusting

No idea whether that gets picked up in Google search.


Web Frameworks: SEO Mythbusting

So let's try that next one.


Web Frameworks: SEO Mythbusting

Hello, and welcome to another episode of SEO mythbusting.


Web Frameworks: SEO Mythbusting

With me today is Jason Miller.


Web Frameworks: SEO Mythbusting

I'm really excited to have you here.


Web Frameworks: SEO Mythbusting

Chrome and sort of test them out.


Web Frameworks: SEO Mythbusting

Cool, and you build Preact as well, right?


Web Frameworks: SEO Mythbusting

I do build Preact on the side, yes.


Web Frameworks: SEO Mythbusting

That's a cool thing.


Web Frameworks: SEO Mythbusting

So now that I've got you here, let's


Web Frameworks: SEO Mythbusting

talk about SEO and frameworks.


Web Frameworks: SEO Mythbusting

So I guess there's like a bunch of misconceptions


Web Frameworks: SEO Mythbusting

about how frameworks and SEO come together.


Web Frameworks: SEO Mythbusting

It would be a perfect opportunity


Web Frameworks: SEO Mythbusting

to get them all mythbusted.


Web Frameworks: SEO Mythbusting

There's definitely a conception that search engines


Web Frameworks: SEO Mythbusting

don't run in JavaScript, just across the board.


Web Frameworks: SEO Mythbusting

I'm not 100% sure where that comes from.


Web Frameworks: SEO Mythbusting

I think maybe back in the early days of the web,


Web Frameworks: SEO Mythbusting

it wasn't a thing.


Web Frameworks: SEO Mythbusting

That's true.


Web Frameworks: SEO Mythbusting

I mean, there's still probably cases


Web Frameworks: SEO Mythbusting

where some other engines don't.


Web Frameworks: SEO Mythbusting

So maybe it's pervasive because of that.


Web Frameworks: SEO Mythbusting

That makes sense.


Web Frameworks: SEO Mythbusting

I mean, we do still have crawlers and engines out there


Web Frameworks: SEO Mythbusting

that are not executing JavaScript.


Web Frameworks: SEO Mythbusting

Is there anything that you wonder or worry about


Web Frameworks: SEO Mythbusting

in terms of discoverability?


Web Frameworks: SEO Mythbusting

Yeah, definitely.


Web Frameworks: SEO Mythbusting

If you build an app where the HTML payload is a script


Web Frameworks: SEO Mythbusting

tag in a style sheet, you laugh.


Web Frameworks: SEO Mythbusting

This is every app.


Web Frameworks: SEO Mythbusting

That is true.


Web Frameworks: SEO Mythbusting

That's what happens.


Web Frameworks: SEO Mythbusting

Yeah, I mean, besides the user implications


Web Frameworks: SEO Mythbusting

that this has, because obviously the browser then


Web Frameworks: SEO Mythbusting

has to fetch more content and you look at a blank page


Web Frameworks: SEO Mythbusting

for a little longer, that also does affect the crawlers


Web Frameworks: SEO Mythbusting

a little bit, especially the ones that are not actually


Web Frameworks: SEO Mythbusting

executing JavaScript.


Web Frameworks: SEO Mythbusting

Definitely.


Web Frameworks: SEO Mythbusting

I can speak for those, but I can say that Googlebot does


Web Frameworks: SEO Mythbusting

execute JavaScript.


Web Frameworks: SEO Mythbusting

So we do see your content unless there's some good reason not


Web Frameworks: SEO Mythbusting

to see your content, like JavaScript errors or network


Web Frameworks: SEO Mythbusting

errors happening.


Web Frameworks: SEO Mythbusting

I did see in the CDS talk you did,


Web Frameworks: SEO Mythbusting

there was a new feature in Search Console


Web Frameworks: SEO Mythbusting

that you guys were talking about for errors.


Web Frameworks: SEO Mythbusting

Yes.


Web Frameworks: SEO Mythbusting

So I don't know if you've ever used the Fetch and Render


Web Frameworks: SEO Mythbusting

in Search Console beforehand.


Web Frameworks: SEO Mythbusting

To get a screenshot, yes.


Web Frameworks: SEO Mythbusting

To get a screenshot.


Web Frameworks: SEO Mythbusting

So what do you do when you get a blank screenshot?


Web Frameworks: SEO Mythbusting

Cry.


Web Frameworks: SEO Mythbusting

Yeah, that was, yeah, I feel you.


Web Frameworks: SEO Mythbusting

So one way of working around that


Web Frameworks: SEO Mythbusting

is to use the mobile-friendly test, which


Web Frameworks: SEO Mythbusting

is the tool that we brought out.


Web Frameworks: SEO Mythbusting

It does what it says it does in the name.


Web Frameworks: SEO Mythbusting

It tells you if your page is mobile-friendly,


Web Frameworks: SEO Mythbusting

which is fantastic.


Web Frameworks: SEO Mythbusting

But more importantly is it also gives you


Web Frameworks: SEO Mythbusting

a list of the resources that we couldn't fetch for whatever


Web Frameworks: SEO Mythbusting

reason.


Web Frameworks: SEO Mythbusting

And it gives you the console logs.


Web Frameworks: SEO Mythbusting

All of them?


Web Frameworks: SEO Mythbusting

All of them, including stack traces.


Web Frameworks: SEO Mythbusting

What?


Web Frameworks: SEO Mythbusting

Yeah.


Web Frameworks: SEO Mythbusting

So you can actually debug.


Web Frameworks: SEO Mythbusting

So you get a blank screenshot, and you're like, oh, no.


Web Frameworks: SEO Mythbusting

But then you can go to the console and see why.


Web Frameworks: SEO Mythbusting

So what we are doing right now is


Web Frameworks: SEO Mythbusting

we are working on the new Search Console that also contains


Web Frameworks: SEO Mythbusting

a thing that we call the URL Inspection Tool.


Web Frameworks: SEO Mythbusting

That's part of the Search Console and for every page


Web Frameworks: SEO Mythbusting

that you have on your site that you verified for,


Web Frameworks: SEO Mythbusting

because we don't want to serve that data to the public.


Web Frameworks: SEO Mythbusting

Oh, yes, show me Google Search itself.


Web Frameworks: SEO Mythbusting

Exactly.


Web Frameworks: SEO Mythbusting

Show me your Google Search data.


Web Frameworks: SEO Mythbusting

So we tried to have one-stop solution for pretty much


Web Frameworks: SEO Mythbusting

everything.


Web Frameworks: SEO Mythbusting

Right now, that includes when we last


Web Frameworks: SEO Mythbusting

crawled you, if it's on Google or not,


Web Frameworks: SEO Mythbusting

if there has been any issues with, I think,


Web Frameworks: SEO Mythbusting

mobile friendliness or AMP.


Web Frameworks: SEO Mythbusting

But yes, but it's going to be extended to structured data


Web Frameworks: SEO Mythbusting

and also to JavaScript errors, I think.


Web Frameworks: SEO Mythbusting

So we mentioned the features thing.


Web Frameworks: SEO Mythbusting

What features can I count on being available in the crawler?


Web Frameworks: SEO Mythbusting

So we do parse HTML.


Web Frameworks: SEO Mythbusting

Really?


Web Frameworks: SEO Mythbusting

Yeah, right?


Web Frameworks: SEO Mythbusting

That's a mind-blowing one.


Web Frameworks: SEO Mythbusting

We are stateless.


Web Frameworks: SEO Mythbusting

So that means we are basically pretending


Web Frameworks: SEO Mythbusting

to be a incognito browser that opens the tab for each URL


Web Frameworks: SEO Mythbusting

that we're indexing the first time.


Web Frameworks: SEO Mythbusting

Local storage, that kind of stuff.


Web Frameworks: SEO Mythbusting

Local storage.


Web Frameworks: SEO Mythbusting

Well, we do store cookies.


Web Frameworks: SEO Mythbusting

But basically, when we go from one page to another,


Web Frameworks: SEO Mythbusting

these cookies are cleared.


Web Frameworks: SEO Mythbusting

So you can't really rely on cookies


Web Frameworks: SEO Mythbusting

to be available across.


Web Frameworks: SEO Mythbusting

We're not running WebGL.


Web Frameworks: SEO Mythbusting

OK.


Web Frameworks: SEO Mythbusting

Yeah, I don't think we are rendering what's on a canvas.


Web Frameworks: SEO Mythbusting

I'm not sure about that.


Web Frameworks: SEO Mythbusting

You can't really search it anyway, right?


Web Frameworks: SEO Mythbusting

That's the thing, exactly.


Web Frameworks: SEO Mythbusting

Everything in there is inaccessible to pretty much


Web Frameworks: SEO Mythbusting

every user who's using assistive technology.


Web Frameworks: SEO Mythbusting

And you can think of a crawler as a user


Web Frameworks: SEO Mythbusting

that needs assistive technology to understand the content.


Web Frameworks: SEO Mythbusting

I'm curious.


Web Frameworks: SEO Mythbusting

Let's say, this is a super biased question,


Web Frameworks: SEO Mythbusting

but let's say I built a website using a framework that


Web Frameworks: SEO Mythbusting

ends in ACT, one of the many.


Web Frameworks: SEO Mythbusting

So let's say I built a website using whatever technology,


Web Frameworks: SEO Mythbusting

client-side rendering.


Web Frameworks: SEO Mythbusting

And I'm doing push state routing using the history API.


Web Frameworks: SEO Mythbusting

Does Google pick up on push states?


Web Frameworks: SEO Mythbusting

Yes.


Web Frameworks: SEO Mythbusting

Yes, we do.


Web Frameworks: SEO Mythbusting

Because you give us a proper URL, right?


Web Frameworks: SEO Mythbusting

Right.


Web Frameworks: SEO Mythbusting

You have example.com slash blurb slash listing or something


Web Frameworks: SEO Mythbusting

like that.


Web Frameworks: SEO Mythbusting

So we do pick those up.


Web Frameworks: SEO Mythbusting

If you use hash-based routing, we don't pick them up.


Web Frameworks: SEO Mythbusting

So please do not use push state routing.


Web Frameworks: SEO Mythbusting

History API is the way to go.


Web Frameworks: SEO Mythbusting

So if you use proper history API URLs.


Web Frameworks: SEO Mythbusting

However, don't fall for a thing that I have


Web Frameworks: SEO Mythbusting

seen a few people fall for.


Web Frameworks: SEO Mythbusting

You might test by basically loading your page


Web Frameworks: SEO Mythbusting

from the home page and then clicking through.


Web Frameworks: SEO Mythbusting

We are not doing that.


Web Frameworks: SEO Mythbusting

Remember, we are stateless.


Web Frameworks: SEO Mythbusting

So if I go straight to slash something.


Web Frameworks: SEO Mythbusting

So if you use a URL and use a link to that URL


Web Frameworks: SEO Mythbusting

somewhere in your page, that's fantastic.


Web Frameworks: SEO Mythbusting

But make sure that people can enter right there.


Web Frameworks: SEO Mythbusting

Interesting.


Web Frameworks: SEO Mythbusting

So you have to make sure that the server understands


Web Frameworks: SEO Mythbusting

how to serve this.


Web Frameworks: SEO Mythbusting

One way of doing it is using a server that actually serves


Web Frameworks: SEO Mythbusting

the index HTML for all routes.


Web Frameworks: SEO Mythbusting

And then the JavaScript displays the right content.


Web Frameworks: SEO Mythbusting

That is perfectly fine.


Web Frameworks: SEO Mythbusting

Just don't give us a 404 or 4F500 or something like that.


Web Frameworks: SEO Mythbusting

Right.


Web Frameworks: SEO Mythbusting

OK.


Web Frameworks: SEO Mythbusting

So a bunch of the services, I'm super lazy


Web Frameworks: SEO Mythbusting

and deploy all my stuff to CDNs.


Web Frameworks: SEO Mythbusting

Nice.


Web Frameworks: SEO Mythbusting

Yeah.


Web Frameworks: SEO Mythbusting

So they let you do a 200.html.


Web Frameworks: SEO Mythbusting

And it returns that content for any URL that's not a file.


Web Frameworks: SEO Mythbusting

That is fantastic.


Web Frameworks: SEO Mythbusting

I did file for something once.


Web Frameworks: SEO Mythbusting

You might use a static site thing that you can use.


Web Frameworks: SEO Mythbusting

On occasion?


Web Frameworks: SEO Mythbusting

Like GitHub pages or S3 or whatever.


Web Frameworks: SEO Mythbusting

It doesn't matter.


Web Frameworks: SEO Mythbusting

They also give you the possibility


Web Frameworks: SEO Mythbusting

to do a custom 404 page.


Web Frameworks: SEO Mythbusting

And I have abused that to serve all.


Web Frameworks: SEO Mythbusting

Because I didn't know all my routes up front.


Web Frameworks: SEO Mythbusting

So I'm like, yeah, if it finds a route that it doesn't know,


Web Frameworks: SEO Mythbusting

it serves this 404 HTML.


Web Frameworks: SEO Mythbusting

Is the status code 404?


Web Frameworks: SEO Mythbusting

Yes, and that's why it's not being indexed then.


Web Frameworks: SEO Mythbusting

So it's an error page that is actually very useful.


Web Frameworks: SEO Mythbusting

Yeah.


Web Frameworks: SEO Mythbusting

But you shouldn't be doing that.


Web Frameworks: SEO Mythbusting

Because if you give that to a crawler and say,


Web Frameworks: SEO Mythbusting

this is not a page, then we are not picking it up.


Web Frameworks: SEO Mythbusting

Because you told us not to.


Web Frameworks: SEO Mythbusting

So you said, if I'm using HTML links or whatever,


Web Frameworks: SEO Mythbusting

I can link between pages, that's fine.


Web Frameworks: SEO Mythbusting

What if I'm using, don't judge me for this, a button,


Web Frameworks: SEO Mythbusting

and the button has a click handler.


Web Frameworks: SEO Mythbusting

And that click handler calls push state.


Web Frameworks: SEO Mythbusting

I'm not saying I'm doing this.


Web Frameworks: SEO Mythbusting

I'm not saying I'm not doing this.


Web Frameworks: SEO Mythbusting

Let me guess, a friend of yours does that.


Web Frameworks: SEO Mythbusting

Right.


Web Frameworks: SEO Mythbusting

Yes.


Web Frameworks: SEO Mythbusting

What's the name?


Web Frameworks: SEO Mythbusting

Bob.


Web Frameworks: SEO Mythbusting

Yes, Bob.


Web Frameworks: SEO Mythbusting

Boop.


Web Frameworks: SEO Mythbusting

Boop uses buttons and on click handlers.


Web Frameworks: SEO Mythbusting

Poor Bob.


Web Frameworks: SEO Mythbusting

You clearly do not do that.


Web Frameworks: SEO Mythbusting

No, I would never do that.


Web Frameworks: SEO Mythbusting

And I'm very happy that you're not doing that.


Web Frameworks: SEO Mythbusting

Because your friend really needs to use links for that.


Web Frameworks: SEO Mythbusting

Because links are to go from A to B.


Web Frameworks: SEO Mythbusting

Button triggers an action.


Web Frameworks: SEO Mythbusting

I think you can use buttons and on click handlers


Web Frameworks: SEO Mythbusting

for all the things that are like, I don't know,


Web Frameworks: SEO Mythbusting

doing a pop up or something.


Web Frameworks: SEO Mythbusting

Modals.


Web Frameworks: SEO Mythbusting

Because, yeah, modals or even like trigger function,


Web Frameworks: SEO Mythbusting

trigger a countdown, whatever.


Web Frameworks: SEO Mythbusting

If it's an action that happens on the page, that's a button


Web Frameworks: SEO Mythbusting

and that's perfectly fine.


Web Frameworks: SEO Mythbusting

But if it takes you to another piece of content


Web Frameworks: SEO Mythbusting

and you want to make this content accessible via search


Web Frameworks: SEO Mythbusting

and make it discoverable in search engines, if it has a URL,


Web Frameworks: SEO Mythbusting

it should be a link.


Web Frameworks: SEO Mythbusting

OK.


Web Frameworks: SEO Mythbusting

Right.


Web Frameworks: SEO Mythbusting

So like if I had a modal that had like high value content


Web Frameworks: SEO Mythbusting

in it or whatever, and right now it's


Web Frameworks: SEO Mythbusting

just a button with a click handler that shows


Web Frameworks: SEO Mythbusting

a thing on the page, if I want that to actually have


Web Frameworks: SEO Mythbusting

like a representation in the search results, give it a URL.


Web Frameworks: SEO Mythbusting

Give it a URL.


Web Frameworks: SEO Mythbusting

Make it a link.


Web Frameworks: SEO Mythbusting

Yes.


Web Frameworks: SEO Mythbusting

And what you can always do is, so I


Web Frameworks: SEO Mythbusting

like the idea of exposing some of the application state


Web Frameworks: SEO Mythbusting

in the URL.


Web Frameworks: SEO Mythbusting

So you can basically say like, and we support parameters.


Web Frameworks: SEO Mythbusting

So you could basically go like, I don't know, slash action


Web Frameworks: SEO Mythbusting

question mark modal or pop up equals true.


Web Frameworks: SEO Mythbusting

And if you use a link to go to that one,


Web Frameworks: SEO Mythbusting

and then that means that it displays the thing,


Web Frameworks: SEO Mythbusting

basically you have to understand that search results work


Web Frameworks: SEO Mythbusting

like as if you would take the URL,


Web Frameworks: SEO Mythbusting

copy that into your messenger, and someone else tapping


Web Frameworks: SEO Mythbusting

on the message on whatever device you don't know.


Web Frameworks: SEO Mythbusting

So basically, they start a fresh browser,


Web Frameworks: SEO Mythbusting

have never been to your page.


Web Frameworks: SEO Mythbusting

Do they see what you are seeing?


Web Frameworks: SEO Mythbusting

If that's the case, then that's an indexable URL.


Web Frameworks: SEO Mythbusting

Right, because otherwise, like if I had a modal and let's say


Web Frameworks: SEO Mythbusting

Google somehow crawled it, if you click on a link from Google


Web Frameworks: SEO Mythbusting

search, how does the link open the modal?


Web Frameworks: SEO Mythbusting

That's the thing.


Web Frameworks: SEO Mythbusting

Exactly.


Web Frameworks: SEO Mythbusting

It has to make it happen for the user,


Web Frameworks: SEO Mythbusting

because if that's a mismatch, then what's the point?


Web Frameworks: SEO Mythbusting

Another situation like that is infinite scrolls, right?


Web Frameworks: SEO Mythbusting

Right.


Web Frameworks: SEO Mythbusting

Don't you hate it when someone sends you a link


Web Frameworks: SEO Mythbusting

and then goes like, did you see that bird?


Web Frameworks: SEO Mythbusting

And then you look at it and it's like, what bird?


Web Frameworks: SEO Mythbusting

Oh yeah, you have to scroll for a while.


Web Frameworks: SEO Mythbusting

You have to scroll 600 meters down the page, or 400 feet


Web Frameworks: SEO Mythbusting

or whatever.


Web Frameworks: SEO Mythbusting

Yeah, I use metric system.


Web Frameworks: SEO Mythbusting

Oh, good, good.


Web Frameworks: SEO Mythbusting

Thank you very much for that.


Web Frameworks: SEO Mythbusting

I think more people should do that.


Web Frameworks: SEO Mythbusting

So yeah, if you scroll down like 600 meters on a page


Web Frameworks: SEO Mythbusting

to find the content, that's an issue to hike.


Web Frameworks: SEO Mythbusting

But if you could link to it, if there's an anchor on it,


Web Frameworks: SEO Mythbusting

then you're good.


Web Frameworks: SEO Mythbusting

Exactly.


Web Frameworks: SEO Mythbusting

If it's an anchor, and specifically


Web Frameworks: SEO Mythbusting

if you're using push state to update the URL


Web Frameworks: SEO Mythbusting

and then allow the JavaScript to pick that up when you come back


Web Frameworks: SEO Mythbusting

into the site and load the right content for it,


Web Frameworks: SEO Mythbusting

you are off really well.


Web Frameworks: SEO Mythbusting

So it's almost like you're doing virtual scroll,


Web Frameworks: SEO Mythbusting

but the Google search bot almost sees it


Web Frameworks: SEO Mythbusting

as next and back buttons.


Web Frameworks: SEO Mythbusting

Pretty much, yeah.


Web Frameworks: SEO Mythbusting

That's kind of like the modality.


Web Frameworks: SEO Mythbusting

You give it an offset, and then we're like,


Web Frameworks: SEO Mythbusting

oh, now our JavaScript starts at page five,


Web Frameworks: SEO Mythbusting

and then you're good.


Web Frameworks: SEO Mythbusting

And then Googlebot comes and goes, oh, so there's


Web Frameworks: SEO Mythbusting

a link here with page five.


Web Frameworks: SEO Mythbusting

All right, so in that case, it surfaces these 25 images,


Web Frameworks: SEO Mythbusting

the bird being the third one.


Web Frameworks: SEO Mythbusting

Off we go.


Web Frameworks: SEO Mythbusting

That's a good way of doing it.


Web Frameworks: SEO Mythbusting

So let's say I was driving a page with a worker.


Web Frameworks: SEO Mythbusting

I have a worker that's doing all of my state management


Web Frameworks: SEO Mythbusting

or even doing DOM rendering or something crazy.


Web Frameworks: SEO Mythbusting

And in order to actually get pixels on the screen,


Web Frameworks: SEO Mythbusting

I have to round trip through that worker


Web Frameworks: SEO Mythbusting

and get all the HTML and DOM manipulation


Web Frameworks: SEO Mythbusting

back onto the main thread.


Web Frameworks: SEO Mythbusting

Is the fact that that might take a little while going


Web Frameworks: SEO Mythbusting

to be a problem for Googlebot?


Web Frameworks: SEO Mythbusting

Generally speaking, no.


Web Frameworks: SEO Mythbusting

I'm definitely encouraging to test that carefully


Web Frameworks: SEO Mythbusting

using the tools that we've got available to make sure


Web Frameworks: SEO Mythbusting

that everything works the way you expect.


Web Frameworks: SEO Mythbusting

But basically, if you see the content in the,


Web Frameworks: SEO Mythbusting

so the mobile-friendly test also gives you the rendered HTML


Web Frameworks: SEO Mythbusting

that we are using for indexing.


Web Frameworks: SEO Mythbusting

So you can use that to see if it appears.


Web Frameworks: SEO Mythbusting

Normally, if it takes a little bit of time,


Web Frameworks: SEO Mythbusting

that doesn't matter that much because we're


Web Frameworks: SEO Mythbusting

doing wonky, interesting things with time anyways,


Web Frameworks: SEO Mythbusting

because we have to deal with a bunch of interesting things.


Web Frameworks: SEO Mythbusting

You can just take a wild load of pages.


Web Frameworks: SEO Mythbusting

Exactly.


Web Frameworks: SEO Mythbusting

So don't worry too much about the time it takes.


Web Frameworks: SEO Mythbusting

If it's a little fragile, you will find out using the tools.


Web Frameworks: SEO Mythbusting

The HTML that it shows, is that, like if I've


Web Frameworks: SEO Mythbusting

done DOM manipulation, is that after the DOM manipulation?


Web Frameworks: SEO Mythbusting

Yeah.


Web Frameworks: SEO Mythbusting

OK, so it's like a snapshot.


Web Frameworks: SEO Mythbusting

And if you're not seeing it, then something


Web Frameworks: SEO Mythbusting

has gone sideways.


Web Frameworks: SEO Mythbusting

OK, so even if I didn't have the error reporting thing.


Web Frameworks: SEO Mythbusting

I mean, I want the error reporting thing.


Web Frameworks: SEO Mythbusting

But even if I didn't have the error reporting thing,


Web Frameworks: SEO Mythbusting

I can see it.


Web Frameworks: SEO Mythbusting

You still have the rendered HTML that you can deduct


Web Frameworks: SEO Mythbusting

from what we're indexing.


Web Frameworks: SEO Mythbusting

OK, that works.


Web Frameworks: SEO Mythbusting

I can live with that.


Web Frameworks: SEO Mythbusting

That's pretty cool.


Web Frameworks: SEO Mythbusting

Anything else from the top of your head?


Web Frameworks: SEO Mythbusting

Is there any difference?


Web Frameworks: SEO Mythbusting

So like, when I'm picking a framework


Web Frameworks: SEO Mythbusting

or trying to figure out how I'm going to build my front end


Web Frameworks: SEO Mythbusting

stack, is there much of a difference between framework


Web Frameworks: SEO Mythbusting

sizes and approaches for how those might get crawled?


Web Frameworks: SEO Mythbusting

So when we're talking about crawl budget, which


Web Frameworks: SEO Mythbusting

means how often and how quickly we can crawl,


Web Frameworks: SEO Mythbusting

the frameworks don't have that much of a difference,


Web Frameworks: SEO Mythbusting

because we are not discriminating or preferring


Web Frameworks: SEO Mythbusting

any of those.


Web Frameworks: SEO Mythbusting

And we're not looking too much at the size, really.


Web Frameworks: SEO Mythbusting

So generally speaking, the more requests


Web Frameworks: SEO Mythbusting

you do to get the content together,


Web Frameworks: SEO Mythbusting

the more requests we count towards that we


Web Frameworks: SEO Mythbusting

have done 1,000 requests.


Web Frameworks: SEO Mythbusting

And if each page of your content makes 100 requests,


Web Frameworks: SEO Mythbusting

that's literally like 10 pages.


Web Frameworks: SEO Mythbusting

So it's also a usability thing, basically,


Web Frameworks: SEO Mythbusting

if you think about it, being on a flaky network.


Web Frameworks: SEO Mythbusting

Right.


Web Frameworks: SEO Mythbusting

Not nice to get half-baked content


Web Frameworks: SEO Mythbusting

or get no content at all and only the empty shell.


Web Frameworks: SEO Mythbusting

So it makes sense to look into server-side rendering


Web Frameworks: SEO Mythbusting

or hybrid rendering to minimize the amount of requests


Web Frameworks: SEO Mythbusting

that it takes, because that helps you with a crawl budget


Web Frameworks: SEO Mythbusting

sometimes.


Web Frameworks: SEO Mythbusting

But that being said, crawl budget


Web Frameworks: SEO Mythbusting

is a really tricky topic, because we cache stuff.


Web Frameworks: SEO Mythbusting

So if we have the content already in the cache,


Web Frameworks: SEO Mythbusting

it doesn't count towards it.


Web Frameworks: SEO Mythbusting

Yeah, if your home page loads all this stuff,


Web Frameworks: SEO Mythbusting

and then all your product pages or whatever


Web Frameworks: SEO Mythbusting

are just hitting the cache, maybe you're


Web Frameworks: SEO Mythbusting

slipping under the crawl budget.


Web Frameworks: SEO Mythbusting

That might happen, exactly.


Web Frameworks: SEO Mythbusting

And crawl budget adjusts all the time, anyways,


Web Frameworks: SEO Mythbusting

because we want to make sure to not overwhelm your servers.


Web Frameworks: SEO Mythbusting

Interesting.


Web Frameworks: SEO Mythbusting

Jason, it has been a fantastic conversation.


Web Frameworks: SEO Mythbusting

Thank you so much for being here and really looking forward


Web Frameworks: SEO Mythbusting

to what you're building next.


Web Frameworks: SEO Mythbusting

Cool.


Web Frameworks: SEO Mythbusting

Thanks a lot for being on the show.


Web Frameworks: SEO Mythbusting

Thanks.


Web Frameworks: SEO Mythbusting

In the next episode of SEO Mythbusting,


Web Frameworks: SEO Mythbusting

Dion Alma is going to join me to talk about the web platform


Web Frameworks: SEO Mythbusting

and SEO and all the road that lies ahead of us.


Web Frameworks: SEO Mythbusting


English Google Webmaster Central office-hours from March 20, 2020

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


Office Hours Hangouts.


My name is John Mueller.


I am a webmaster trends analyst at Google in Zurich, usually.


Now I'm at home, like I guess most of you.


Part of what we do are these Office Hour Hangouts,


where folks can join in and ask any question


around their website and web search,


and we'll try to find some answers for you.


A bunch of things were submitted already on YouTube,


but if any of you want to get started


with a question of your own or something you submitted there,


feel free to jump on in.


Hi, John.


Hi.


I have a question about the Google Cloud for Clients website.


So they are a gift basket website.


They sell different type of gift hampers.


So last year, we finished the website.


Our ranking was good for the Christmas hampers,


which was Q1 until October.


But after October, we don't think


that our ranking dropped a little bit.


And when we checked our computer website, some of our computer,


they add big content on their category page.


And the content was, if the content doesn't


have this information, it has information


like the delivery policy and what type of Christmas


gift hampers you should buy.


So literally, it was a blog post they


put on the category description.


On the other hand, we put a tier one description


like what is new gift hampers we have,


and what is the last gift to order,


and what offers we have, and it comes


to provide this information.


So now, how do we decide which content is useful?


Is there a new way?


OK, it's really hard to understand you from the audio.


But I think what you're asking is you have category pages,


and there's a lot of extra content on those category


pages.


And you're wondering, is that good or not?


Is that roughly it?


OK, so in general, having some amount of text on category


pages is always useful, because it


helps us to understand those pages a little bit better.


But the important part is also that we can still


recognize that this is a category


page of an e-commerce site and not a blog post or kind


of like a Wikipedia article on the type of products


that they sell.


So with that in mind, I would try


to put useful text that makes sense for a category


page on the category page.


And if you want to write background information,


if you want to include the full copy of the terms of service


and things like that, I would put that on a separate page.


That makes two things a little bit easier for us.


On the one hand, it's a lot easier for us


to determine the intent of the page.


So is this an informational page?


When a user is looking for information,


should we send them to this page?


Or is this primarily a kind of a shopping page,


where someone is trying to buy products


and we should send them to this page when


they're trying to buy a product?


So that's something where you need


to make up your mind what kind of page you want it to be,


because it's not that you can just do all of these things


on one page and we will think it's


perfect for all kinds of needs.


But rather, what we will do is look at this page


and say, well, we don't know what the best


use of this page is, because there are so


many different aspects here.


We have to guess.


So the clearer you can really make a category page


be what you want that page to be,


what kind of address the needs of the users


that you think they will have or that you want to cover,


then the clearer we can follow that and say,


oh, this is a really strong category page for people


within Shopping Intent.


We should send them to this page when they want to buy a product.


Thank you, John.


Sure.


Yeah.


Robin?


John, can I ask a quick question?


So John, actually I'm working on a B2B client


and he's into the business of sales intelligence tools.


So my question is, in such a tight B2B space,


is it good to do FAQ schema implementation on the FAQ


pages?


Because big girls like Salesforce and Zoho,


even they are not applying or making use of that schema.


Well, I think if other people aren't using it,


that gives you more opportunity.


So I wouldn't say that's a bad thing


if the competitors aren't using the new features yet.


But I would think about what kind of content


you want to provide there in the FAQ sections


to make sure it's really frequently asked questions


and that it's specific to the individual pages,


not that you just copy all of the questions


to all of the pages on your website.


But I wouldn't assume that just because a big website is doing


something or not doing something that they're


doing that on purpose.


Sometimes they just don't have time


to fix things or change things.


Yeah.


Thanks, John.


Stay safe.


Sure.


You too.


All right.


Go for it, Robin.


Hi, John.


First, I'd like to introduce myself.


My name is Robin Lespagnard.


I'm the founder and CEO of Selectus, a product review


website in French, and proud employer


of 12 full-time employees.


So I'm going to read out my question out loud, I guess.


We sent a reconsideration request for our website


on the 16th of March.


Should we be expecting a longer review period


than the usual a few days to two weeks


due to the situation right now with coronavirus?


And also, if I may ask, does Google sometimes


send a warning before applying a manual action?


Because in the case of our website,


we instantly let last 90% of our traffic


putting in revenue, putting our company and its employees


at risk of bankruptcy.


We realized we made a mistake, which we quickly corrected


after receiving penalty.


But a simple warning with something like 15 or 30 days


notice would have done the job too.


Yeah, I'm going to go.


Yeah.


Hold on.


I don't know.


Bye.


OK.


So I took a quick look at the site just beforehand.


And usually, with regards to reconsideration requests,


it does take a lot longer than just a couple of days,


especially the linking reconsideration requests.


I've seen they sometimes do take up to a month or so.


So that's something where, at least at the moment,


they're quite overloaded with regards


to these kind of requests.


I can double check with the team to see if there's something


that they can do here, if this is something where there's


like a clear case where they can just say,


oh, we don't need to spend a lot of time on this.


This is actually OK now.


With regards to sending a warning,


that's something we do discuss from time to time.


And I don't know if that's something that will change.


The primary reason why we tend not to send a warning


is that when we run into this kind of a situation


where the web spam team notices that there's a problem,


then usually that's something that's


affecting the normal search results already.


So that's something where users are seeing bad results,


and we know that users are seeing bad results.


Then that's something where we want to take action


as quickly as possible and to resolve that.


So for the most part, that's always kind of tricky


to say we would send a warning when we know that it's


currently in a bad state.


One other thing, maybe especially with regards


to linking reconsideration requests,


I think that's the issue that you had there.


One of the tricky parts there is that sometimes a site's ranking


is partially due to some of these link schemes


that they were doing.


So by fixing those link schemes and removing them or disavowing


them, then you're removing some of that kind


of artificial support that was for that website as well.


So it won't necessarily be the case


that when the manual action is resolved


that it'll pop back up right at the same place


as it was before.


Just because you've kind of removed


that artificial aspect, then you're


in the natural place again, which


might be a little bit lower than before.


It depends a little bit on how the algorithms looked


at that in the past.


But I'll definitely take a look with the web spam team


to see if there is something that we can do there.


It's kind of tricky because I know they also


have a lot of work to do.


And if I send them everyone that contacts me directly,


then suddenly I'm just the person


that slows everything down rather than kind of the process.


Thank you.


I thought, could you maybe explain to people here,


the two SEOs, the process, the whole process from start


to finish of a manual penalty?


Because when I checked, we looked


at all the information on Google Webmasters thing.


And most of it, the dates of the dates of Marquette,


it seems like there's no new updates.


Has the process evolved in some ways?


The manual review process is essentially the same


because people have to take a look at it manually.


The guidelines have been fairly stable for quite some time


now as well.


I think what will be happening a little bit more over time


is that we can automate more of this.


We already do a lot of this with some of our linking algorithms


where we algorithmically determine


these are unnatural links, and we just ignore them.


So it's not the case that someone manually


has to look at all of the links and say, oh, these are bad.


These are OK.


But rather that we do that automatically.


And I think that's the direction we'll probably continue to go,


that it's less and less people having to manually take action


and then you have to fix something and send


like a letter back saying I fixed it,


and then it's like someone looks at it again kind of thing.


But more that we can automatically


recognize problems, ignore them ideally.


If we can ignore them, then on the one hand,


it makes it harder for you because you don't


know what is happening.


But on the other hand, it also doesn't harm your site.


So if you accidentally do kind of these things


or if you did these things in the past


based on bad advice maybe, then if we ignore them,


then you're not causing your site any harm.


But you're also not having any profit


from kind of those unnatural things.


AUDIENCE 1 I'm curious, does the, for example, in our case,


or in another case, does the manual reviewer


like checks the website out, looks at the company


maybe behind the website?


Sometimes, yeah, sometimes.


I mean, it's something where because these


are manual reviews, we can spend a little bit more time.


But it's also the web is big and we have a limited time.


So what usually happens is someone


will look at the bigger picture of the website


and try to determine if there's really


a strong pattern of unnatural issues here, which


could be all kinds of things.


With links, it's always a bit tricky.


That's something where the manual reviewer


has to double check a little bit more and see,


is this really something that probably the website did


by themselves, or is this something maybe a competitor


did, or someone is trying to harm them and frame them


by doing these links?


And if we can recognize that it's not in their control,


we'll try to find a way to just ignore those links.


But they do spend a little bit more time


to look at the website as well.


And do you have multiple teams in multiple languages,


or just one big team in the US?


We do have multiple people in multiple locations


for multiple languages, just because sometimes websites


are hard to understand in different languages.


And just looking at the number of links


makes it really hard to determine,


is this kind of unnatural, or is this just, I don't know,


maybe one language that they don't speak,


and all of the links look like this because that's


a very common word.


I don't know.


So that's something where we do have multiple teams


in different locations.


On the one hand, that makes it a little bit fairer with regards


to international websites.


But that also means for some languages and some locations,


we might not have as many people as for other locations.


So that sometimes slows things down


with the reconsideration request.


And do you have some kind of minimum reasonable time


that you expect the website owner to take


before sending his request?


No.


That's something where if we send a manual action


and you fix it within half an hour, that's fine.


OK, so that was a myth.


Many people told me, no, no, take your time.


Take your time.


I think, especially with links, it's


more important that you really clean up the bigger picture.


And sometimes that does take a bit more time.


But there are different issues which you can just fix.


If you have a plugin on your website


that causes the problem, then you can just remove that plugin,


and suddenly everything is fixed.


And if you want to stop me, please stop me.


But I have some more questions.


Once you receive the request, are there


different priority queues?


No, I don't think so.


OK.


And how does the team judge that a website has done


a sufficiently good job at fixing the problem?


Because maybe sometimes the problem is fixed 90%,


but you judge it to be OK, good enough.


Yeah, especially with links, that's really tricky.


Because you can always find something bad on the internet


if you look far enough.


So that is something where the team


tries to see if a significant amount of the issue


was resolved.


And if that's OK, then that's usually fine.


It's a bit tricky, like I mentioned, with links.


And different people might look at it in different ways.


So what I have seen happen is that someone


reviews a reconsideration request and says,


oh, it's not enough.


And then the webmaster sends a message back and saying,


it was everything I could find.


And then someone else takes a look and says,


oh, yeah, it's actually OK.


OK.


But I mean, that shouldn't be the usual case.


But that's something that is possible whenever there's


a manual review process.


And if the problem has not been fixed sufficiently,


does the team voluntarily wait a longer time


before taking another look at the website?


No.


OK, so that's another myth, too.


That's another myth.


Myth-busting today.


Yeah, the one thing that can happen


is if we see that a website goes back and forth,


then that's something where the web spam team will say,


OK, you're just wasting our time.


Like, if you fix the problem, do the reconsideration request,


and then a couple of weeks later you have the same problem


again, then a little bit of back and forth,


and the web spam team will say, OK,


we will take a look in a couple of months


when you've decided what you want to do.


And last question, London.


After such a review, is the website


put in a check regularly to see if no further problem happens


list?


No.


All right.


If it's fixed, it's fixed.


There's nothing that hangs around.


Well, thank you very much.


I hope this is useful to other SEOs.


We've busted a few myths here.


Thank you very much.


No, thanks.


I think it's always frustrating and confusing


the first time you have some manual action like this.


So I totally understand all these questions.


OK, let me run through some of the questions that


were submitted so that we can try to catch up


with some of that, too.


Is there any image ranking advantage


in using the same image in different blog posts


when talking about the same topic?


For example, every time I post about Parmesan cheese,


I use the same image instead of a different image.


Could it help that image to rank better?


No, that doesn't change anything for the images


because images don't rank on their own.


They always rank together with a landing page.


So it's always a matter of this image on that landing page,


and the landing page has more information, more context


around that image.


So it's not something where the image alone


would be ranking in the search results.


Thank you, John.


That was my question.


Great, cool.


How can we use the mobile-friendly test


for web pages that are under development?


It's an extremely useful tool, but it


doesn't work when there's a robots.txt disallow command.


We're afraid of opening the dev part of the site


because real Googlebot can jump into this whole tool.


So there's a guide in our developer documentation


on how to set up a proxy for debugging locally hosted


or firewall pages.


It's on a page called Debug Your Pages.


I guess that's a good title, which is mostly


about JavaScript sites.


And essentially, what you do is you set up a local proxy that


listens to a specific port, and then you


assign a URL to that location.


And that way, you can test essentially locally hosted


pages and try them out there.


So that should work for the mobile-friendly test.


That should work for anything that you use the URL inspection


tools for.


One thing to keep in mind with the URL inspection tools


is that you would need to add this host to your Search


Console account first.


So there's a little bit more back and forth involved there


if you need to use the URL inspection tool.


But mobile-friendly, rich results test,


structured data test, all of those should work right away.


One of our clients creates paginated pages


with similar or synonym names in h1 title internal linking.


What's your opinion about this?


Can this help to avoid keyword cannibalization


and help us to rank for different keywords


for the same category?


Because theoretically and practically, it


seems to be a great strategy, as I've


seen that our page six of a category


got good clicks because maybe nobody else


is using that specific combination,


and we have it on the h1.


So in general, you can do whatever you want on your


category pages, on your paginated pages.


However, because of the way that paginated pages tend


to be linked within a website, where


you link to the first page of the paginated set,


and then you link to the next page from there,


and kind of the third page from there,


and you have this chain of linking,


we kind of see the first page of a paginated set


as being the most important one.


And that's the one we tend to show in the search results


when someone is looking for this category of products.


So if you spend your time kind of trying


to improve page six of a category pagination set,


then probably that's a lot of time


that's spent on things that are very, very little visibility


in search.


So my general recommendation there


would be to say, instead of trying


to improve this kind of far off and less relevant page


within your website, try to focus


on the more relevant pages on your website,


and make those a lot stronger.


So instead of going off and doing these super long tail


things where you get a little bit of traffic,


and you might be ranking well for those keywords,


but if nobody is searching for them,


that's not very useful.


Instead of focusing on those really long tail things,


focus a little bit more on making the core of your website


much stronger.


Because by making the core of your website stronger,


everything around that will be a little bit stronger as well.


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


It's not that you can't do this.


Like, if you want to optimize page six of your category


pages, go for it.


My feeling is just that it's not the best use of your time.


We've been experiencing slow average response time.


Can this demote our keyword rankings?


Initially, our pages crawled, and the crawl stats also dropped.


But now they've more than doubled.


So yeah, I think that's something