that we would say, oh, the way that we handle links never


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

changes, or the way that we handle links always


changes when we make a core algorithm update.


These changes can happen essentially at any time.


And they can also coincide with core algorithm updates.


The way that we process links is something that is continuous.


So it's not that we have to wait for a specific time frame


to see the new effect of the links,


but rather, when we see links on the web,


we can take them into account essentially immediately.


In the HTML spec, P is a logical element.


Is that the same for Googlebot?


I mean, a situation where one paragraph contains one theme


is much better for robots understanding


than a stream of thoughts in one big P element.


So this is an interesting question,


because I never really thought about this.


But from my understanding, we don't do anything special


with these kind of paragraph delineators or a div,


for example, is something that people sometimes


use for this as well.


But rather, we kind of see it as a chunk of text.


So it's not that we would say a paragraph separation.


It means something unique.


But rather, when we render the page, when we pull out


the HTML, when we look at how things are semantically


structured, when we see that this is one collection


of thoughts, essentially, a number of sentences that


are all together, then that's something


that we can kind of assume belongs together with regards


to understanding that page.


So I wouldn't say that we go out of our way


to semantically understand that this is a paragraph.


But we do try to figure out what a paragraph is.


So I guess in a way, you could say we do figure it out.


I don't know.


It's weird.


But I don't think it's the case that we


try to turn a p tag into something more than kind


of a separation of paragraph.


One place where this sometimes goes a little bit weird is,


I haven't seen this in the past recently.


But previously, when people were using things


like table-based layouts, then the table cells themselves


are also kind of a paragraph.


And sometimes what we saw is that people


were using a table-based layout to actually structure something


that belongs together.


So you could imagine a situation where you have a table set up.


And a sentence is across a number of different table


cells, which you're using for whatever design purposes.


And for us, when we look at that,


we see a collection of individual cells.


We don't realize that actually these cells belong together


and make up one big text piece.


Or similarly, you could imagine a whole paragraph


being split up into individual table cells.


And that's something where, at least when people were doing


this more often, this kind of table-based layout,


it's something that we did run into every now and then,


that we couldn't work out that these things are actually


next to each other and they belong together


for understanding of a page.


But with all of the modern CSS solutions out there,


I think that's a lot less of an issue.


It seems Google recently launched an update for Search


and News tab, something that many were complaining


about for the past nine months.


Likewise, I also noticed that Search Console is now


showing performance of links for a news section.


Has that always been there, or is that also a new thing?


I'm unable to see any performance insights there.


So I don't know what all is happening on the news side.


I do know that they're working on some things


to kind of catch up with whatever they've


been struggling with there.


So hopefully, for those of you who are waiting for this,


hopefully that will be a little bit better in the future.


But I don't really have any details there to share.


My understanding is that they'll probably also post something


in the News Help Forum at some point with more details.


With regards to Search Console, we


did start including the news information in Search Console,


but that's, I believe, news mode in Search, not Google News.


So it's slightly different from just pure Google News.


And the data that we pulled in there, I think,


only goes back to July or something


like that from when we started collecting this data for sites.


So sites that have been around for longer that


have the usual 18 months of data in Search Console,


they still have a limited set there for that news section.


Over time, as we collect more data for these sites,


then we'll have that full time period again.


I wanted to ask if linking from the main content


part of the old but still relevant articles on my domain


to the new recently published articles on the same domain


increases relevance for specific internal anchor text and topics


used in the link or if it otherwise helps that new article.


So the question is kind of complicated,


but I think essentially what you mean is,


does it make sense to link from content


on one page within your website to new pages on your website


or to other pages on your website?


And from my point of view, that's an obvious yes.


Of course, linking between different parts


of your website, creating a good internal linking structure,


that always makes sense.


So that's something that I would always recommend.


It's good for users.


It's really helpful for search engines


because if we have multiple paths to crawl your website,


it's a lot easier for us to crawl your website.


If we can better understand which parts of your website


are important to you, which is usually the parts that you


link to more often within your website, then that


helps us to better focus our efforts on those parts as well.


So any kind of improvement that you can do for internal linking


is a good thing.


Two questions.


Let's see.


When is the next Google Core update coming?


The last one for me was hard.


I don't have any dates for Core algorithm updates.


I know everyone kind of wants one,


but it's something that from our side,


we try to minimize the amount of big disruptions like these


as much as possible.


And when we do work on bigger changes with regards


to understanding relevance of search,


it is something that we try to significantly test to make sure


that it's working well.


We run a number of evaluations on our side


to kind of determine where the different search results will


be, if that matches what we want.


We do a number of tests with external raters


to figure out if we're missing anything,


if we're kind of accidentally not recognizing


that this negatively affects some things that we


were worried about.


And from our point of view, it's not


that we would wait for a specific date


and then just launch whatever we have then.


But rather, we want to make sure that this is working


as well as possible.


And then when it's working well, then we will launch it.


So it's not like a release date that we have to hit,


but rather, we will launch it when things are ready.


My Search Console is showing nothing,


but I suspect my site may have a ranking penalty


for some reason.


So is the only way to check in Search Console manual actions,


or is there another way to check this?


Yes, if there's a manual action on your website.


So if the web spam team has manually


kind of needed to step in and take some action with regards


to your website, then that will be visible in Search Console.


I think there is an extremely small number of cases


where that wouldn't be visible, but those are really


kind of tricky edge cases.


And it's not something that an average site would run into.


So in general, if you're not seeing anything


in Search Console in the manual action section,


then I would assume that your website is


ranking algorithmically the way that we think it makes sense.


And it's not the case that there is anything manual kind


of playing a role in that.


Finally, I want to point out that a cache plugin named


WP Rocket released yesterday a JavaScript delay


function that solves all of the problems


that AdSense generates in PageSpeed Insights.


So that sounds pretty promising.


I haven't taken a look.


I also don't have AdSense on my blog, so I can't really test


it.


But I know lots or some people have


been complaining about AdSense and some of the other things


that services and products that we have that you can embed


on your site that make a page slower.


And if there are ways to improve the speed for that,


then I think that's a good idea.


So it might be something to try out.


I found a snag in the Google workflow


to recover account access.


So I took a quick look at this question ahead of time.


And I don't know exactly what it's referring to.


I suspect it's tied into the Google Ads side of things


and not with a Google Search Console kind of scenario.


So I really don't have any insight


on what can be done there.


I know that, in general, the account recovery team


works really hard to make sure that things


work as much as possible.


But if you're finding that the normal account recovery


flow isn't working, then I would definitely


post in the Help Forum.


I don't know if there is now a separate Google account Help


Forum.


Otherwise, probably the Gmail Forum is a good proxy for that.


I want to ask, what is the best to write


in the alt text of an image that has quotes written on it?


The quotes work best are the keywords from the article.


How should a person go with such images?


So the alt attribute for images should


be a description, essentially, of the image itself.


And from that point of view, if your image is a quote,


then you can describe that quote,


or you can just copy that quote into the alt attribute.


That's a perfect setup.


So that's kind of how I would go there.


I wouldn't use the alt attribute just


to stuff keywords from the site in there,


because that's not useful for users.


It's not useful for us as a search engine, either,


because we already see those keywords


from the rest of your page.


For search, what happens with the alt attribute


is we use that to better understand the images


themselves, in particular for image search.


So if you don't care about image search,


then from a search point of view,


you don't really need to worry too much


about the alt attributes.


But if you do want these images to be shown in image search,


which sometimes it makes sense to show kind of fancy quotes


in image search as well, then using the alt attribute


is a good way to tell us this is on that image,


and we'll get extra information from around your page


with regards to how we can rank that landing page.


I'm seeing a constant influx of spam and malicious domains


appearing in the search results for a website I manage.


We're finding about 30 to 50 new ones per day ranking


in the top 10 pages for our brand search.


Most of them redirect to phishing scams and virus


warnings.


What's the best way of dealing with these,


and most importantly, preventing them?


It's quite strange that these domains are ranking in the top


10 pages for Google for a brand when


we have hundreds of popular articles


that Google should be shown ahead of these.


Is this just a loophole that affects all brand searches?


So I don't think this is something that


affects all brand searches.


That would be something where probably we'd hear


a lot more complaints about.


But it is something where, depending on the kind of query


that your brand search essentially is,


it can happen that we don't have a ton of really good content.


And even if we have more good content from one website,


it might be that we just show a handful of results


from one website, and then the rest we kind of take whatever


else we can find on the web, which if we don't find


a lot of good things, then we kind of


have to scrape the bottom of the barrel


and we come up with things that aren't that great, especially


if you're talking about the first 10 pages of the search


results for something like a brand query.


Probably users, when they're searching for your brand,


they find your brand on the first page,


and they kind of go to your site directly.


They wouldn't go through the top 10 pages


to see what else is there.


However, if this is something where


it looks like these kind of hacked fishing kind of virusy


sites are in a particular pattern,


and it feels like Google is missing this pattern completely


for whatever reason, then I would strongly


recommend posting more about this in the Webmaster Help


Forum so that the folks there can also pass that on to us


if they recognize that there is something


more general and broader that Google would need to do.


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


Of course, with virus content, you


can also report that through a special forum on Google's side,


which we use quite a lot.


Also, for phishing content, you can do the same thing.


So that can help there.


But essentially, if there is nothing good


that we can show for some of these queries,


and you're going to page 10 in the search results,


then we end up with all kinds of weird things


that happen to be indexed for some reason.


We have a news site, and we use advertising.


When I look at the HTML code inside Search Console URL


inspection, I see there is a lot of CSS code injected


by the ads, JavaScript in the DOM.


Does this affect the page ranking in any way?


Usually not.


So various JavaScript snippets do inject CSS.


They do inject some HTML into the page,


depending on what they're meant to do.


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


doesn't affect ranking.


There are two things to watch out


for when it comes to third-party JavaScript


that you use on your website.


One is that some kinds of JavaScript


inject code, HTML, into the head of the page, which


can result in us not being able to understand


which elements of your content are actually in the head.


So one example is that a JavaScript might inject


something like an iframe to the top of the head of your page.


And when we parse that HTML page, we'll see the iframe tag.


And we'll say, oh, the head of this page is closed.


We can skip all of the rest of the meta tags


and things like that that are there.


And then it can happen that a robots meta tag is missed,


that a rel canonical is missed, that hreflang links are missed,


because we think that they're no longer in the head of the page.


So that's one thing to watch out for.


In URL inspection, you should be able to see that.


It is really tricky to spot.


And the first time you see it, you'll


be really surprised and big aha moment.


But it is something that can happen.


And to fix it, you essentially have


to work with the provider of that third-party JavaScript


to let them know that injecting things


into the head of the page can be problematic.


The other element that can play a role


with third-party JavaScript and content injected into a page


is essentially everything around speed,


where if a JavaScript element injects


a lot of content into a page and that makes that page really,


really slow, then when we evaluate


the speed of a page for ranking, then that's


something where we might see that, oh, this page is very,


very slow.


And we would not differentiate between it


is you, the site owner, that is making this page slow,


or it is some third party that you're


embedding with JavaScript that is making the page very slow,


but rather, when we load your page, it is very, very slow.


So that's the other aspect to kind of keep in mind.


Does Googlebot ignore the container tag while crawling?


So I don't know what the container tag is.


So I didn't have a chance to double check


before the Hangout.


I feel I'm missing something totally obvious.


But in general, if the container tag,


let's say the container tag is some new HTML element that


somehow I missed, if that's a new HTML element,


for example, an HTML5 or something even newer than that,


then from Googlebot's point of view,


we would essentially process that as any other tag


that we don't know about.


So that's something where we would


try to render the page if we can render the page


and get the content.


We render the page using a fairly modern Chrome version.


So if we can render the page and get the content,


then that's essentially fine.


If the container tag is something


that just provides extra functionality


and doesn't change the content that is shown for rendering,


then we would essentially ignore that.


Perhaps they're referring to the Google Tag Manager container.


Oh, OK.


Google Tag Manager, yeah.


Good point.


Yeah, that's also a container.


Oh, it's awkward when you don't know what it is.


And it's like, am I missing something totally obvious,


or did they confuse something?


Yeah, so if it's Google Tag Manager,


then that's something that could be tied in


when it comes to rendering.


You can test that with the URL inspection tool


to see what happens there.


And I haven't played around with Google Tag Manager for a while,


but you can do things like include JavaScript, which


means you could update some of the content on the page


as well.


So if you're using that to update the content,


to add content, to remove content,


then when we render the page, we'll


be able to take that into account.


Do you know about any updates coming to Google My Business


regarding keywords as a business plan?


I don't know anything about Google My Business,


essentially, so I don't really know there.


I have seen anecdotally on Twitter various people


both complaining and asking for features around that,


but I really don't have any insight on Google My Business.


If you see a URL as a 200, which was previously a 404,


then Google will treat this as a fresh new URL


and not impact performance on the big picture.


My question is, if URLs were performing well previously,


does that mean it might have some kind of a score, page


authority, which would influence Google ranking?


If Google sees those URLs as fresh URLs,


that means all score authority will be zero.


Wouldn't this indirectly impact performance?


So at least from as far as I know,


we don't have any kind of score that we


would maintain after we drop a URL from the index.


So it's possible that there are some elements that


remain kind of in our index, I don't know, metadata for a URL


when a page just temporarily drops into a 404 state


and doesn't really get removed from our index.


But as soon as we remove that page from our index,


we essentially don't have that metadata anymore.


So if something is longer a 404, if it's longer and no index,


then we don't have that information anymore.


However, there might be a lot of signals


that we pick up from the rest of the web.


So if that page comes back, we wouldn't


know about that page anymore.


But we might have lots of signals


from the rest of the web that tells us this is actually


a good page.


So in particular, if you have a lot of internal links pointing


to that page, if the rest of your site


is something that we would consider very important or very


high quality, then that gives us a lot of information


more about that new page or that page that has come back.


So it's not so much that we would keep those signals


and we return them when that page comes back


after some time, but rather the information


where those signals are coming from,


that still exists somewhere, perhaps.


And when that page comes back, then we


can rebuild those signals based on the information


that we have otherwise.


So that's probably what you'd be seeing there


if you kind of test around with this kind of functionality.


OK, we're kind of running low on time.


This looks like we still have a bunch of questions left.


But I thought I'd just open things up for you all as well.


If there's anything else on your mind


that you'd like to talk about, feel free to jump in.


I'll also be around a little bit longer


if there's anything you want to chat about after the recording


as well.


Hey, John.


JOHN MUELLER-ROSENZINEK, JR. This is Shiva again.


Last week we spoke about the news.


Just wanted to update you something


that we have seen an update last night in the Search Console.


And previously it was listing only our site operator keyboard.


But now it is listing all of our articles in the Search Console.


And we are also seeing static clicks number as well


in the Search Console.


But it is not increasing, though, for some reason.


We don't know why the clicks doesn't increase


if the incoming is there.


And one thing we have noticed is that a couple of our articles


did surface on the News tab in the regular search.


But when we go into the Google News app or news.google.com,


we don't find the same articles there.


So if you could please throw some light


on the difference between these two.


And probably if there is something coming in future,


maybe in a couple of weeks as an improvement to this.


Because we have come a bit far from what we have been last


week, so that is good.


Thank you so much for that.


Yeah, I don't work directly with the News theme.


So I don't have a lot of direct insights there.


But I'm really glad to hear that things


are looking up a little bit.


If you're seeing these changes just from yesterday,


then I would give it a little bit more time to settle down.


Because in general, indexing changes,


I assume it's the same when it comes to News.


Indexing changes do take a little bit of time


to settle down and to rebuild the signals


that we need for that.


So that's something where I'd say it's cool to see


the initial jump.


But you need to give it a couple of days


to see where it settles down and where you start


seeing data being collected.


Also, the data in Search Console,


depending on the element that you're looking at,


has a little bit of a delay.


So it might be that after a couple of days,


that data actually starts showing up there.


But let me know if you still end up seeing issues like this


after a couple of days, maybe next week.


Then we can see if there's something


unique with the News side that we need to push.


SPEAKER 2 Sure, John.


There is a difference between the News tab on Search Console


and the News app, or they're both same?


There is a difference, right?


Yeah, so the News in Search Console


is the News tab in Search, or the News mode in Search.


And it's not Google News.


So it's very confusing because they're all called News.


But we treat them as something different.


OK, thank you, John.


We'll come back to you next week.


Thank you so much, though.


Cool.


Hey, John.


Hi, good question.


Yeah, I got a question regarding guest postings.


I know you've covered that previously.


But my question is, for very high quality guest posts,


for SEO purposes, and generating lots of traffic,


having original helpful content, and even ranking high


on Google, should the links be nofollowed as well?


And are those links being devalued?


And the next one would be, what's


your take on websites with large amount of articles


from industry experts that were professional writers that


contribute great content?


Thank you.


I think it's hard to have a general guidance there.


But from our point of view, if these guest posts are really


purely there for those links, then that


would be something that the web spam team would


be worried about.


There are lots of ways to do guest posts where you're


essentially just driving publicity to your content


or driving awareness of your content.


And that's something where, from my point of view,


I don't see that as being problematic.


The one way I look at it is, if you,


as the person writing this guest post,


don't really care if that link is follow or nofollow,


then that's a good sign that you're


writing this with the intent of bringing awareness,


reaching a broader audience, reaching other people.


Whereas, if you're saying that the only reason I would ever


publish this guest post is to get a link that does not


have a nofollow attached to it, then that's


kind of a sign that you're really just trading


that post for a link.


And that would be a problem.


And focusing it on great content and really great people,


smart people writing these posts,


that's something that I sometimes


see as more of a distraction rather than the actual issue


at hand there.


But I do know there are some sites that have guest authors


that are posting, and they write fantastic content.


But it's essentially someone who is writing on that website


where there is an editor involved,


and essentially they're working to create


normal content for that website.


It's not some random guest post that they get submitted


that they just publish one to one.


I don't think that really answers your question,


but that's kind of the way that we would look at it.


Also, the other thing that is sometimes also worth


keeping in mind is that when the web spam team takes


a look at your website, kind of think about what they would see.


It's something where sometimes the web spam team will


take a look at a website and say, well,


these links are all over the place.


There's all kinds of linking happening here.


It's like if there's something bad in between, then it happens.


That's not the end of the world.


But if they look at a website and they say,


well, all of the important links to this website


are guest posts, and they're high quality guest posts


on high quality sites, but all of the links to the site


are guest posts, then that's kind of a sign


that maybe we need to be a bit more careful here with regards


to the links to the site.


SPEAKER 2


John, in the infinite scroll documentation,


that old blog post, one of the best practices mentioned there


is the fact that each separate pagination page, when accessed


directly, should only have products


for that specific page.


So like products from 20 to 40 or something like that.


And you shouldn't really mix products together.


So the reason why I'm asking this


is I have a case where if you go to page 2


of a certain category, you also have the products loaded


from page 1.


So you have page 1 plus page 2.


If you go on page 3, you have page 1 and page 2 and page 3.


And it kind of scrolls you down to page 3.


So how much of a negative impact does that


have, having those kind of previous pages


also loaded on those pagination URLs?


It really depends on what you're using the pagination for.


So in a case like this, it looks like the primary objective


is to find links to the product pages.


And if we find those links on multiple pages, that's fine.


It doesn't matter.


In cases where you have one really long article


or you have multiple articles that you're


loading with infinite scroll, then it's


more a matter of the content itself being indexed,


not the links.


And if by indexing the content, we


have this mix of different articles on the same URL,


then that's a problem.


So that's kind of the differentiator.


Is the reason for this infinite scrolling page finding links


to other pages, in which case duplicates are fine?


Or is the infinite scroll the matter


of finding indexable content on that page itself?


And in that case, differentiating


between the different pages is really important.


But is it a risk that, for example, you


have a category with 10 pages, and that last 10th page kind of


has all of the products for that category


because it loads all of the previous pages?


Well, would Google kind of think, well,


this seems to have everything that I need,


so I'll index that one and show that one in the search results?


Is there a danger that that might happen?


I don't think so.


I don't think that would be a problem.


So I guess the main place where we saw this as actually causing


problems is more on news websites.


Content-based websites.


Yeah, content-based websites, and really in particular


on news websites, where if you load multiple articles using


infinite scroll and they end up being on the same page,


then you can end up in a situation


where you have two completely disconnected articles loading


on the first page.


And then the title is something like, this politician said x.


And then in the bottom, there's an article about a car crash.


And then suddenly, for queries like politician plus car crash,


it's like, oh, this politician had a car crash.


But it's essentially completely disconnected articles


on the same page.


And that's something where we have ended up contacting sites


and letting them know, hey, this is really a problem.


And it almost causes news cycles of its own


because you go to Google and search politician name


plus car crash and all these articles.


It's like, there's a conspiracy.


Something is trying to be hidden.


Yeah.


But so from an e-commerce point of view,


given that the documentation features


that specific example for e-commerce,


should websites try to not have that kind of issue,


try to solve it?


Or it doesn't really matter?


I think it is always a good practice because then you


don't accidentally run into this.


But it's definitely not critical for e-commerce.


Especially, I mean, for e-commerce,


we really need to find those links to the product pages


and the category pages.


The first paginated version of the category page


will almost always be the most important one


because that's the one that's linked


from the rest of your site.


So that's something where I don't see this


as being a problem for e-commerce.


I think it's a good practice just


to make sure you don't avoid that.


But it's not going to change anything for e-commerce.


OK.


Cool.


Let's take a break here with the recording.


I'll pause here.


As always, if any of you want to hang around a little bit


longer, perfectly fine.


Thank you all for joining.


I hope you found this recording useful.


And hopefully, I'll see some of you


all again in one of the future Hangouts.


Bye, everyone.


Crawl Budget: SEO Mythbusting

How about crawl budgets?


Crawl Budget: SEO Mythbusting

I would love to talk about crawl budgets.


Crawl Budget: SEO Mythbusting

Yeah, I think it's a term that's thrown around a lot in the industry


Crawl Budget: SEO Mythbusting

and it seems like an abstraction of something that is much more technical and concrete


Crawl Budget: SEO Mythbusting

and I think we can get a lot of clarity through this video.


Crawl Budget: SEO Mythbusting

Fair enough.


Crawl Budget: SEO Mythbusting

Hello and welcome to SEO Mythbusting. With me today is Alexis Sanders from Merkle


Crawl Budget: SEO Mythbusting

and you are a senior account manager.


Crawl Budget: SEO Mythbusting

Yes.


Crawl Budget: SEO Mythbusting

Yeah, okay. So you work with a lot of different companies and accounts and I have like different


Crawl Budget: SEO Mythbusting

kinds of work. Yesterday we were discussing fermented food because that's a hobby of yours.


Crawl Budget: SEO Mythbusting

Yeah, definitely. I went on a trip, came back and my boyfriend had fermented like everything.


Crawl Budget: SEO Mythbusting

Everything. So like lots of kimchi.


Crawl Budget: SEO Mythbusting

Oh my god, we have so much kimchi in a huge jar.


Crawl Budget: SEO Mythbusting

But we're not here today to talk about kimchi. So what are things that your


Crawl Budget: SEO Mythbusting

clients and customers are dealing with and what's the question that you often get?


Crawl Budget: SEO Mythbusting

What's the topic you would like to discuss?


Crawl Budget: SEO Mythbusting

I would love to talk about crawl budget today. So to get started, before we even talk about


Crawl Budget: SEO Mythbusting

anything, can we start with what is crawl budget? So kind of like recapping some of the stuff that


Crawl Budget: SEO Mythbusting

Gary covered in his Google Webmaster article.


Crawl Budget: SEO Mythbusting

That's a very good point. Actually the article is a fantastic starting point into this entire journey.


Crawl Budget: SEO Mythbusting

So when we are talking Google search and indexing and thus crawling, we have a bit of a like,


Crawl Budget: SEO Mythbusting

what's it called, trade-off to make. And the trade-off that we have to make there is we


Crawl Budget: SEO Mythbusting

want to get as much information crawled as quickly as possible but we don't want to overwhelm the


Crawl Budget: SEO Mythbusting

servers. Definitely. And would you categorize that part of it as crawl limit? Almost like


Crawl Budget: SEO Mythbusting

an abstraction under an abstraction. Yeah, it's like that's the crawl rate basically.


Crawl Budget: SEO Mythbusting

How much stress can we put on your server without crashing anything or like suffering


Crawl Budget: SEO Mythbusting

from killing your server too much. And that's one thing. The other thing is we just have to


Crawl Budget: SEO Mythbusting

be reasonable with our resources, right? The web is really really large. So instead of just crawling


Crawl Budget: SEO Mythbusting

everything all the time, we need to make some distinctions there, right? A news website


Crawl Budget: SEO Mythbusting

probably changes quite often and we probably need to like be catching up with them every now and


Crawl Budget: SEO Mythbusting

then. Whereas a website on the history of Kimchi is probably not changing as often. I mean,


Crawl Budget: SEO Mythbusting

nothing against Kimchi but I think like the history isn't as fast-paced as the world news are.


Crawl Budget: SEO Mythbusting

Yeah, definitely. So that's the crawl demand. So we try to figure out like is this something


Crawl Budget: SEO Mythbusting

that we need to crawl more often or is this something where it's okay if we check up every


Crawl Budget: SEO Mythbusting

now and then. And what goes into that decision-making process? So for instance, if you had that Kimchi


Crawl Budget: SEO Mythbusting

website or if you had something like archive.org where it's really just something that's going to


Crawl Budget: SEO Mythbusting

be constant for a long period of time and there really isn't going to be any changes. Yeah. How


Crawl Budget: SEO Mythbusting

do you guys determine that? So we basically fingerprint content as we crawl it, right? So we


Crawl Budget: SEO Mythbusting

see like what is this page about. We use that for deduplication later on but we also look into like


Crawl Budget: SEO Mythbusting

when was this last change. So you can tell us in things like structured data has possibilities.


Crawl Budget: SEO Mythbusting

You can have date elements somewhere in your page. We more or less keep track of one or how often or


Crawl Budget: SEO Mythbusting

how frequently things are changing. And if we detect that the frequency of change is really low,


Crawl Budget: SEO Mythbusting

then we don't have to crawl as much. That has nothing to do with quality. You can have fantastic


Crawl Budget: SEO Mythbusting

content that will rank really high or whatever that never changes. It's more about is this


Crawl Budget: SEO Mythbusting

information that we need to revisit every now and then or is this something that we can leave


Crawl Budget: SEO Mythbusting

alone for a longer period of time. Now do you guys use something like the ETag or the less modified


Crawl Budget: SEO Mythbusting

network header or is it more about taking that fingerprint of the content? So you can give us


Crawl Budget: SEO Mythbusting

various like hints as I said structured data dates are one. ETag is an interesting one as well. The


Crawl Budget: SEO Mythbusting

HTTP headers are useful for this last modified date in sitemap, right? And the more useful you're


Crawl Budget: SEO Mythbusting

making these if you just like automatically update the last modified date in the sitemap and we figure


Crawl Budget: SEO Mythbusting

out that does not correspond to actual changes on the website or the website changes are minimal,


Crawl Budget: SEO Mythbusting

then that's not helping us. Not only that, at some point we're just going to be like, OK,


Crawl Budget: SEO Mythbusting

this is not useful for this particular site. But as much information as we get, we will use to


Crawl Budget: SEO Mythbusting

figure out what we can reasonably expect as a change frequency. Nice. So going backwards a


Crawl Budget: SEO Mythbusting

little bit, what size of sites should be worried about crawl budget? Should be worried about


Crawl Budget: SEO Mythbusting

hitting that crawl limit? Large sites. And like if we were to give like millions of pages. OK,


Crawl Budget: SEO Mythbusting

cool. So if you have under a million pages, really crawl budget is not something that you should be


Crawl Budget: SEO Mythbusting

concerned about. Unless you have a really flaky server setup. But then again, crawl budget isn't


Crawl Budget: SEO Mythbusting

your problem. Your problem is just server setup, right? No, definitely. So do you typically see


Crawl Budget: SEO Mythbusting

that the issue isn't really with the server setup but more with the crawl demand or do you see it


Crawl Budget: SEO Mythbusting

more with the server setup? Depends on what you say the issue is. So normally crawl budget gets


Crawl Budget: SEO Mythbusting

cited in many, many different times when it actually wasn't an issue to begin with. It was


Crawl Budget: SEO Mythbusting

just like the quality of the content was bad and that's why we didn't index it. So we crawled it,


Crawl Budget: SEO Mythbusting

we figured out, oh, this is not worth keeping. Then we didn't index it. So is this a crawl budget


Crawl Budget: SEO Mythbusting

problem? We're like, no, we have crawled it. It's just not good. And is that what you would


Crawl Budget: SEO Mythbusting

typically see in the excluded section of the GSE report? Something along those lines?


Crawl Budget: SEO Mythbusting

Yeah, these things are really helpful. Sometimes you also see people are like, oh, yeah,


Crawl Budget: SEO Mythbusting

my crawl budget is really low. And then we're like, yeah, but is that a problem? Are you having


Crawl Budget: SEO Mythbusting

lots of changing content? And they're like, actually, no, it's like a blog that updates


Crawl Budget: SEO Mythbusting

once a week. And I'm like, hmm, how big of a problem really is that? Sometimes it's also people


Crawl Budget: SEO Mythbusting

just barely missing the crawl window where we did not discover the URL. And if you're not submitting


Crawl Budget: SEO Mythbusting

it in sitemaps, then we have to crawl another page to find that link to that URL. And then we're


Crawl Budget: SEO Mythbusting

going to crawl that one. So using sitemap reasonably is a good idea for these things.


Crawl Budget: SEO Mythbusting

But again, if you're not having millions of pages and crawl budgets is really an issue.


Crawl Budget: SEO Mythbusting

Yeah. So let's say you're working with a major e-commerce or something like real estate where


Crawl Budget: SEO Mythbusting

you have hundreds of millions of pages that are a little bit smaller, maybe a little bit similar.


Crawl Budget: SEO Mythbusting

Is there anything that those industries can do to make their pages crawled more often or more


Crawl Budget: SEO Mythbusting

appealing to Google? So as you said, so the thing is like being crawled more often is not necessarily


Crawl Budget: SEO Mythbusting

helping. It's not giving us a signal for quality or it's not meaning like, oh, this is fantastic.


Crawl Budget: SEO Mythbusting

Having something crawled and then indexed and then never changing is OK as far as we're concerned.


Crawl Budget: SEO Mythbusting

But for e-commerce, I would highly recommend if we were saying something very interesting, like


Crawl Budget: SEO Mythbusting

lots of smaller pages that are very similar to each other, if they are very similar to each other,


Crawl Budget: SEO Mythbusting

should they exist is my first question. Or is it more like a can you extend the content,


Crawl Budget: SEO Mythbusting

for instance, if it's product variations of it, maybe you just describe them in the table


Crawl Budget: SEO Mythbusting

inside one page rather than having 10 pages for all the variations. Definitely. Which colors are


Crawl Budget: SEO Mythbusting

available? Well, it almost brings to the fact that there's so many different issues that fit


Crawl Budget: SEO Mythbusting

into crawl. It's like duplication or finding the pages or yes, service is an issue. Right.


Crawl Budget: SEO Mythbusting

If you have a server that every now and then just flakes on us, then we don't know. Is that because


Crawl Budget: SEO Mythbusting

it's a flaky server? Is that because we are about to overwhelm you? You got a flaky server.


Crawl Budget: SEO Mythbusting

It's wobbly and falling over every now and then. Then we have to be careful.


Crawl Budget: SEO Mythbusting

You have to touch very lightly on that. So let's say someone is switching over their site to a


Crawl Budget: SEO Mythbusting

more powerful server. What is something they should expect to see in their log files if


Crawl Budget: SEO Mythbusting

Google's testing their service to see how much they can handle? They might see an increase in crawl


Crawl Budget: SEO Mythbusting

activity and then a small decrease again. And basically there's this wave motion that's going


Crawl Budget: SEO Mythbusting

to happen. But normally when you just switch the server and nothing else changes, you might not even


Crawl Budget: SEO Mythbusting

see us doing anything. You just see it just continues to go through. Definitely. Unless


Crawl Budget: SEO Mythbusting

you change from something that was broken to something that works, then you probably see more


Crawl Budget: SEO Mythbusting

crawling happening. Okay. So what about in the situation of migrations? A lot of sites are really


Crawl Budget: SEO Mythbusting

hyper aware about how their site is being crawled during a migration. Are there any tips that you


Crawl Budget: SEO Mythbusting

guys have to making sure that your site is being crawled accurately? So what you can definitely do


Crawl Budget: SEO Mythbusting

is you can make sure that you're more or less progressively updating your site map and saying


Crawl Budget: SEO Mythbusting

like, this has now changed, this has now changed, and this has now changed. And it's now time to


Crawl Budget: SEO Mythbusting

crawl that. And we crawl it, we get a redirect. That's actually a change that is interesting


Crawl Budget: SEO Mythbusting

for us. And then you can control a little bit on how we discover the change in the migration.


Crawl Budget: SEO Mythbusting

But generally speaking, just make sure that both servers are up on par and running smoothly and not


Crawl Budget: SEO Mythbusting

like flaking out every now and then or like giving us error codes. Definitely. Make sure that your


Crawl Budget: SEO Mythbusting

redirects are set up correctly as well and that you're not accidentally blocking important things


Crawl Budget: SEO Mythbusting

for us to understand once we are landing on the new site. If you have like a robots.txt beforehand


Crawl Budget: SEO Mythbusting

and then you change that completely different URLs being blocked and put that on the other thing,


Crawl Budget: SEO Mythbusting

then we're like, what's happening here? What is going on? Yeah, so that's not a great idea. So


Crawl Budget: SEO Mythbusting

try to like do one thing at a time. Do not be like, we're going to change the tech stack,


Crawl Budget: SEO Mythbusting

we're going to change the server, we're going to change the URLs, we're going to change the


Crawl Budget: SEO Mythbusting

content, and we're going to migrate to a different domain. It's like, that's a lot. Too much for one


Crawl Budget: SEO Mythbusting

year, too much for one project. No, for sure. Okay. So for crawl budget, what levels of a


Crawl Budget: SEO Mythbusting

site does it affect? So if you have a CDN, will it affect your site? If you have a subdomain or


Crawl Budget: SEO Mythbusting

a domain, at what levels of your infrastructure is it affecting? That depends. So generally speaking,


Crawl Budget: SEO Mythbusting

we go on the site level, so everything that is on the same domain. Sometimes subdomains might be


Crawl Budget: SEO Mythbusting

counted towards that, sometimes they are not. CDNs are one where it's like kind of counted against


Crawl Budget: SEO Mythbusting

your site, but not really. And you should normally not worry about it. And I think like crawl budget.


Crawl Budget: SEO Mythbusting

So much SEO. Enjoy yourself. And what's interesting is when it comes to crawl budget,


Crawl Budget: SEO Mythbusting

where I would say like you should consider this, especially if you're dealing with user generated


Crawl Budget: SEO Mythbusting

content, you can try to tell us not to index or not to crawl certain things that you know are bad.


Crawl Budget: SEO Mythbusting

So it's more of a content side of things rather than the technical infrastructure side of things.


Crawl Budget: SEO Mythbusting

Yeah, definitely. Okay. So does crawl budget actually affect both your indexing phase,


Crawl Budget: SEO Mythbusting

your crawling phase, and your rendering phase? Crawl budget does actually touch on rendering,


Crawl Budget: SEO Mythbusting

because as we render, we will fetch additional resources that comes from the crawl budget.


Crawl Budget: SEO Mythbusting

Because again, the trade off is still there, right? When we're crawling initially, we don't


Crawl Budget: SEO Mythbusting

want to overwhelm your server. But the same goes to when we're rendering, we don't want to overwhelm


Crawl Budget: SEO Mythbusting

the server there. What's the point in killing your ecommerce website just because we are making


Crawl Budget: SEO Mythbusting

thousands of requests at the same time to crawl all these resources. So it can happen, especially


Crawl Budget: SEO Mythbusting

if you have a large site with millions of URLs, and you get your caching wrong, for instance,


Crawl Budget: SEO Mythbusting

that we actually have to fetch everything over and over and over again, which means we have a lot of


Crawl Budget: SEO Mythbusting

simultaneous requests to your server. If your server then slows down significantly, then we'd


Crawl Budget: SEO Mythbusting

be like, oh, okay, careful. And then resource fetches might fail. So we might be able to like


Crawl Budget: SEO Mythbusting

fetch and render the first, I don't know, 500,000 pages. But then suddenly, resources seem to fail,


Crawl Budget: SEO Mythbusting

because we're like, ah, we don't want to make more requests at this point. And then we can't


Crawl Budget: SEO Mythbusting

really render them. So that would be bad. Yeah. So what do we do in terms of caching for those


Crawl Budget: SEO Mythbusting

resources? So obviously, with pages, we can put them in Excel site maps, and all the stuff you


Crawl Budget: SEO Mythbusting

mentioned before with potentially structured data, and then maybe even adding some network headers.


Crawl Budget: SEO Mythbusting

But what do you think about those resources that could be really consuming of Google's resources?


Crawl Budget: SEO Mythbusting

Absolutely. So the thing is, we're trying to be as aggressive as possible when we're caching


Crawl Budget: SEO Mythbusting

sub-resources, such as CSS, JavaScript, API calls, all that kind of stuff. If you have API calls that


Crawl Budget: SEO Mythbusting

are not get requests, then we can't cache them. So you want to be very careful with doing like post


Crawl Budget: SEO Mythbusting

requests or something like that. Some APIs are doing that by default. And then I'm like,


Crawl Budget: SEO Mythbusting

that's an interesting one, because we can't cache it. So that's going to consume your


Crawl Budget: SEO Mythbusting

crawl budget quicker. The other thing is, you can help us by making sure that URLs


Crawl Budget: SEO Mythbusting

optimally never change. So what is a really good idea is you can have content hashes in your


Crawl Budget: SEO Mythbusting

resources. So instead of saying like application.JavaScript, you can say application dot,


Crawl Budget: SEO Mythbusting

and then this hash that describes the content like A, F, C, exactly like this, these MD5 hashes,


Crawl Budget: SEO Mythbusting

dot JavaScript, then this will never change. So when you're making an update to your JavaScript,


Crawl Budget: SEO Mythbusting

you get a different URL. So we can cache the other thing forever. And once we get to get the new


Crawl Budget: SEO Mythbusting

HTML, we get a new URL for the JavaScript. And then it's almost like versioning. It's like


Crawl Budget: SEO Mythbusting

versioning in the URL. Exactly. Nice. So for that first version that you would have, or any


Crawl Budget: SEO Mythbusting

particular version that you would have, would that how long is that typically cache for?


Crawl Budget: SEO Mythbusting

It depends. But we're trying to cache as aggressively as possible. So this can be like


Crawl Budget: SEO Mythbusting

a day, this can be a week, this can be a month, and we might ignore caching headers. So if you're


Crawl Budget: SEO Mythbusting

telling us this expires tomorrow, and we're like, no, it does not, then we might just cache it


Crawl Budget: SEO Mythbusting

nonetheless. Yeah. Awesome. So do you find that any issue, any particular industries complain more


Crawl Budget: SEO Mythbusting

about crawl budget than others? I think we're talking more about it. That's true. I think like


Crawl Budget: SEO Mythbusting

e-commerce and publishers are quite prone to this because they have historically typically large


Crawl Budget: SEO Mythbusting

sites with lots of pages. And they might actually run into this. We had a really interesting


Crawl Budget: SEO Mythbusting

situation with one map master presented at a webmaster conference in Zurich once. In Japan,


Crawl Budget: SEO Mythbusting

it's a website that has lots of user-generated content. And they do machine learning to figure


Crawl Budget: SEO Mythbusting

out if the quality of the content that was produced is considered good or not. And if it's


Crawl Budget: SEO Mythbusting

not good, then they put it in noindex, and they put it in robots.txt so that we're not wasting


Crawl Budget: SEO Mythbusting

crawl budget on it. And that way they steer, because they had a crawl budget of like 200,000


Crawl Budget: SEO Mythbusting

pages per day or something like that. But they had like a million coming in, and most of it was spam.


Crawl Budget: SEO Mythbusting

So they're like, it's annoying if we just waste our crawl budget for the day on spam, that will


Crawl Budget: SEO Mythbusting

not get indexed anyway. So that's an interesting one. So do you believe that there's an overall


Crawl Budget: SEO Mythbusting

quality metric that Google uses? So for that particular site in general, because they had so


Crawl Budget: SEO Mythbusting

much non-high quality content, did that affect Google's outlook on their content overall? Not


Crawl Budget: SEO Mythbusting

really. It was more like, this page is not good. We're not going to put it in the index. So that's


Crawl Budget: SEO Mythbusting

the outcome, really. Or if it's light on content, if someone just literally posts a picture and says


Crawl Budget: SEO Mythbusting

like, ha ha, then that's not great content necessarily, especially if the picture is just


Crawl Budget: SEO Mythbusting

a repost of some meme or some stock photo, right? Yeah, definitely. So what are some things that we,


Crawl Budget: SEO Mythbusting

as webmasters and SEOs and agency people, can recommend to our clients on how to help Google


Crawl Budget: SEO Mythbusting

bot out and help your rendering system out as well? So if you know that there's URLs that you


Crawl Budget: SEO Mythbusting

don't need to render the page, and that's a very big be careful here, because if you're like


Crawl Budget: SEO Mythbusting

blocking the entire API, because like, ah, we don't need the API, and then the JavaScript does need


Crawl Budget: SEO Mythbusting

the API to render the page, then that you should block. You don't get the full experience. Exactly.


Crawl Budget: SEO Mythbusting

Do not block that, because then we might actually not see much content. But if you have something


Crawl Budget: SEO Mythbusting

that definitely, like internal analytics or some internal tools or some chat tool that pops up


Crawl Budget: SEO Mythbusting

or whatever, just don't let that be crawled, because what's the point? Yeah.


Crawl Budget: SEO Mythbusting

Also, you can use... And do you recommend blocking it in the robots.txt for those particular resources?


Crawl Budget: SEO Mythbusting

If you don't want them crawled, sure. Yes, yes. Just be careful that you're not putting something


Crawl Budget: SEO Mythbusting

in robots.txt that turns out to be useful and important later. Yeah, yeah. You can also...


Crawl Budget: SEO Mythbusting

Big caution there. Yes, you can also, especially with client-side rendered apps, you oftentimes have


Crawl Budget: SEO Mythbusting

like a bunch of API calls going to and from. You can proxy that through like a facade kind of thing.


Crawl Budget: SEO Mythbusting

You basically build a little application that all it does is it takes one request for one specific


Crawl Budget: SEO Mythbusting

piece of data that you need to render the page, makes all the API requests and all the back-end


Crawl Budget: SEO Mythbusting

requests that it needs, maybe has a layer of caching as well to make this faster, and then has


Crawl Budget: SEO Mythbusting

one response going back. That way you have one request, one response cycle.


Crawl Budget: SEO Mythbusting

So I may sound a bit goofy, but this is something like GraphQL?


Crawl Budget: SEO Mythbusting

Yeah, GraphQL, exactly. Yes. But with GraphQL, again, be careful to not use the post mode.


Crawl Budget: SEO Mythbusting

No post mode, people. Make sure that users get requests, not post requests.


Crawl Budget: SEO Mythbusting

Yeah, cool. Yeah, there's a bunch of stuff you can do and basically cut off the bits that you


Crawl Budget: SEO Mythbusting

don't want crawled and give us information of the frequency of change in sitemaps and stuff


Crawl Budget: SEO Mythbusting

so that we can get a better grasp of where we should be spending our time.


Crawl Budget: SEO Mythbusting

Definitely. And do you see any pitfalls that people fall into with Crawl Budget quite often?


Crawl Budget: SEO Mythbusting

Well, definitely the robots one. That happens all the time, that they block something that


Crawl Budget: SEO Mythbusting

turns out to be an important resource. It does not need to load the CSS.


Crawl Budget: SEO Mythbusting

And we're like, eeewww. We don't know what the page looks like, so we need the layout.


Crawl Budget: SEO Mythbusting

Exactly. People sometimes fall for it when they do AB testing, that something gets no index when


Crawl Budget: SEO Mythbusting

they don't want it, and then they waste Crawl Budget on something that doesn't end up in the


Crawl Budget: SEO Mythbusting

index. And I'm like, hmm. Yeah, all sorts of things can go wrong. My favorite is when people are


Crawl Budget: SEO Mythbusting

dealing with servers that are not configured correctly, and then they just give you a 500


Crawl Budget: SEO Mythbusting

something, and we're like, OK, if this happens, then we're not crawling this much anymore because


Crawl Budget: SEO Mythbusting

we don't want to overwhelm your server. And people are like, why is Google not crawling this? And


Crawl Budget: SEO Mythbusting

we're like, wow, because your server constantly tells us that it's overwhelmed. So, hmm.


Crawl Budget: SEO Mythbusting

Yeah. So let's say you have a very large site, and you know you have these mega powerful servers


Crawl Budget: SEO Mythbusting

with gigabytes and gigabytes of data. Is there any way that we can tell Google that, hey,


Crawl Budget: SEO Mythbusting

you can crawl us more, like we expect you to crawl us more here?


Crawl Budget: SEO Mythbusting

Right. You can't really. We are detecting that. What you can do is you can limit us,


Crawl Budget: SEO Mythbusting

but you can't really say more please, more please.


Crawl Budget: SEO Mythbusting

OK.


Crawl Budget: SEO Mythbusting

This Crawl Scheduler is relatively clever when it comes to these kind of things. And normally,


Crawl Budget: SEO Mythbusting

if we detect like, oh, there's lots of good content out there on this page, and the site


Crawl Budget: SEO Mythbusting

map is full of URLs, then we'll try to grab as much as we can. And as long as your server doesn't


Crawl Budget: SEO Mythbusting

tell us not to, we'll continue doing that. So eventually, the Crawl Budget might ramp up


Crawl Budget: SEO Mythbusting

to what you would expect to see.


Crawl Budget: SEO Mythbusting

Ah, lovely. So just keep creating fresh, great quality content is really what it comes down to.


Crawl Budget: SEO Mythbusting

That's generally the answer to pretty much everything. Good quality content, if it's fresh,


Crawl Budget: SEO Mythbusting

also great.


Crawl Budget: SEO Mythbusting

Awesome.


Crawl Budget: SEO Mythbusting

Yes. Alexis, thank you so much for being with me and having this fantastic conversation.


Crawl Budget: SEO Mythbusting

And I think there was like a bunch of nuggets in there. And it's great having you here.


Crawl Budget: SEO Mythbusting

Thank you so much.


Crawl Budget: SEO Mythbusting

You did this. I hope you enjoyed it. And see you soon again.


Crawl Budget: SEO Mythbusting

Thanks so much, everyone.


Crawl Budget: SEO Mythbusting

Next episode, we have Eric with us. And we're going to be talking about page speed, how


Crawl Budget: SEO Mythbusting

it works in ranking, what to look out for, what to not do and how to not get it wrong.


Crawl Budget: SEO Mythbusting

It's such a great topic because so many people do get it wrong, I'm afraid.


Crawl Budget: SEO Mythbusting


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

First, I have to jump out.


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


Office Hours Hangouts.


My name is John Mueller.


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


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


I guess are not in the office anymore,


but rather at home at the moment.


But whatever, we'll improvise.


I hope you're all doing well and safe wherever you are,


whichever place at home, I guess pretty much everyone


is at home nowadays you're at.


We have a bunch of questions submitted.


But if any of you want to get started


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


Hi, John.


I achieved this slide.


So John, I want to ask a question about the crawl


depth of a website.


So what happens is I was working on a website,


and it has approximately 200 blogs.


So when I initiated the crawl on it, I used Screaming Crawl.


And what I found is the blogs are deep in the IA.


That is, their most profound blog was on 8th crawl depth.


So how could I cope with it, and what is the best practice


for it?


What would you suggest?


In general, with crawl depth, you


need to find a balance between having a flat architecture


and a really narrow and deep architecture.


And that's something where there is no hard rule where


you can say, for technical reasons,


it should be like this or like this.


But rather, we generally try to crawl things


that are closer to their home page,


because usually the home page is the most important page.


We tend to crawl things that are linked from there a little bit


more frequently, and that kind of bubbles down.


So depending on the website, whatever


page happens to be the most important page


for that website, from there is kind


of where we start looking at the crawling.


And that essentially happens through the links on the page.


And if we find pages that you think are really important,


just very far away from the pages


that Google or your users think are important, then for us,


it's hard to understand that this is actually


an important page.


So when it comes to crawl depth in a situation like this,


if this is something that you find


is really important for your website, which


might be because there's important information on there,


it might be because you're doing a special offer at the moment,


it might be because you make the most money


from a certain product, then I would just


make sure that it's really visibly


important on your website.


So link to it from kind of higher level places


within your website's architecture.


That could be from the home page.


That could be from category pages, things like that.


So that's something where you kind of


have to use your judgment and say, well,


this is an important page for me.


Therefore, I want to make sure that everyone, users


and search engine crawlers, understand that it's important.


OK, so just to follow up, I just want


to ask one thing, what would be the better approach?


Should I categorize those blogs into certain categories,


or should I use breadcrumb implementation for that?


Or just simply categorize into them?


That's totally up to you.


Sometimes it's enough to just categorize the blog post


that you have kind of higher level category pages, which


are easier to crawl and find.


Sometimes you can take individual posts


and just highlight them on the home page of the site


and say, these are my most important posts,


or my most popular posts, something like that,


and link to them a little bit more prominently


within the website.


But how you do that is up to you.


And it might also be that this kind of eighth level


in that particular site is also OK.


It's not necessarily a sign that eight is bad or anything


like that.


John, I have a follow up on that.


Sure.


You said, I think, let me try to interpret your tweets.


Basically, you said something about the way


to visibly see, according to Google,


if Google thinks you have a flat architecture is


if you don't have site links show up for your website.


Can you clarify that a little bit if I miss something?


It's not so much that they don't show up, but with site links,


we try to figure out what the context is of the other content


on your website.


And if we can really tell that a handful of pages


are really associated with this one page that's


shown visibly in search, then we might show that as a site link.


Whereas if everything is really flat,


if it's like everything is equally important


and there is no hierarchy at all,


then it's really hard for us to say,


these pages belong together with that other page


that we're showing in the search result.


So not seeing site links is kind of hard to say that that's just


because of the flat architecture.


We don't show site links for lots of pages.


But showing irrelevant site links,


that's a really clear sign that we


don't understand the architecture of the website.


And your hierarchy is kind of maybe too flat for us


to understand which pages belong together.


Cool.


Thank you.


OK.


Any other questions before we get started?


John, with movie schema, is that intended for movie theaters?


Or, well, I should say, is it appropriate for a site that


just has information about a movie?


Does a review, has information on the actors and directors


and that type of thing?


Is movie schema appropriate for that?


I think so.


So I am just peeking at the documentation.


And it feels like that's one of the big use cases.


You write about movies.


You review the movies, those kind of things.


OK, great.


Yeah.


All right.


Anything else before I jump into the submitted questions?


I got another question about a tweet you posted.


OK, go for it.


About manual actions, you basically


said it could happen where you don't include sample URLs.


What scenarios would you guys not include sample


URLs in a manual action?


I don't know offhand.


I gave some assumptions.


I can tell you what I think, but OK.


I mean, I'd have to totally guess, because I don't know.


I don't know that part of the system that well,


just from day-to-day interaction with the teams.


My guess is if it's something where it's purely site level,


then probably it doesn't make sense to show individual URLs.


Whereas if there's something really specific


on individual pages, then we probably should show URLs.


But I haven't looked into that in a while.


OK, thank you.


But if they never add anything to the email


and you reply back, they sent you an email saying some,


like I had one recently where they would reply back and then


kind of show what the issue was.


So that tells me, OK, there was a human interaction there.


It wasn't, I mean, it's good to see that nowadays.


We're not all robots.


Exactly.


Yeah, we try to do that, but we can


tell that there is a good faith effort by the site owner


that they're trying to fix something.


And maybe they just need a little bit more information


than we try to do that.


I assume just for time reasons, it's


not possible to do that with every manual action


and reconsideration request that comes in.


All right, let me run through some


of the submitted questions.


And you're welcome to jump in in between


if you have any related questions


or need any more clarifications.


OK, for a multilingual website, if we have different language


versions with one domain under different directories,


so slash en, slash fr, et cetera,


if we have hreflang set up in place,


does it matter if the domain is a ccTLD like.de?


Would it be better to move the website to a gTLD like.com?


For just purely multilingual content,


if it's different language versions,


it doesn't matter if there is a ccTLD or a gTLD.


On the other hand, if you have content


that is specific to individual countries,


so for geotargeting, then that would be something


where hosting it on a ccTLD makes it a lot harder


because you can't specify the geotargeting


for other countries.


So using a gTLD, a generic top-level domain like.com,


would be a lot better there.


But like I said, if it's purely just different language


content, if it's not specific to individual countries,


host it wherever you want.


Is it true that Google uses font size to detect headers?


For example, if my h2 is 35 pixels and my h1 is 25 pixels,


then Google is going to say, well, the bigger phrase is more


important, and use the h2.


Second, do you use this technology only


when there is no h1 to 6 tags on a page,


like if there are divs and spans?


I think we do a combination of all of these things.


So on the one hand, we do try to understand


the headings on a page.


And headings are ideally flagged with the h1, h2, h3 tags,


where you can semantically tell us


what the heading of individual pieces of content on a page is.


And that's really useful for us.


On the other hand, we also render the pages


so we can see which text is actually visible,


which text is not as visible.


We see the overall layout of the page


as well to better understand how things


work together there.


So from that point of view, if you're


trying to optimize at this level, which probably does not


have a giant effect on your website,


but if you're trying to optimize on this level,


then I would make sure to use proper headings,


and I would make sure to display those headings in a way that


is relevant for the user as well.


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


If we don't have any headings on a page at all,


then obviously we have to guess.


And sometimes we guess right, and sometimes it's pretty hard.


For what it's worth, especially with headings,


that's one area where we found some trouble with switching


to mobile-first indexing on sites,


because for whatever reason, some sites


don't like to use headings as much on the mobile version


of their pages.


And in those cases, we do lose a little bit of information


there.


So that's something where, especially for images,


if we don't understand which heading this image belongs to,


then it can be a bit tricky for us


to show it appropriately in the image search results.


SPEAKER 2


Also has accessibility implications.


You want to make sure that people on screen readers


get a structural rundown, and that doesn't work with font


sizes.


Doesn't matter for SEO as much, but for accessibility, it does.


Yeah, that's definitely another thing to keep in mind.


I always forget to explicitly call that out,


but it is something where it's good to watch out


for these kind of things.


A web page schema natively has breadcrumb schema field built


into it.


A web page, not the schema, but the rendered one possibly


includes a header with a menu and a footer and a menu


and so on.


Does it make sense to add these header footer elements


to be nested within the web page schema


or separately as their own schema


since it's not natively included in the web page schema?


Wow, that's a confusing question with lots


of web pages and headings and navigation elements.


So I think, just first off, probably this


makes absolutely no difference for us


at all when it comes to search.


So that's something where if there is a specific use


case you have in mind with regards to the schema


markup on those pages and that use case works


with this kind of a setup, then obviously go for it.


On the other hand, if you're mostly


worried about how Google would interpret this and use it


for SEO reasons, then I would spend my time somewhere else


because this kind of level of structured data


nesting and integration within a page


is not something that we would show in the search results.


So it's very easy to spend a lot of time on something like this


and to focus on lots of theoretical variations of how


this could or should be nested.


But if it doesn't have any effect at all in search


and what you're really trying to do


is achieve something for search, then probably it's


better to spend your time somewhere else.


With regards to how it theoretically would be done,


if you care about the schema.org variations,


I honestly don't know.


You probably need to ask someone on the schema.org side.


I believe they have a Google group where you can probably


ask this kind of a question.


But again, for SEO reasons, I don't think


that changes anything at all.


When a bot is scanning a page and finds schema markup,


does it validate the schema accuracy


through schema.org, which means sending a bot to validate


for every schema?


Or does it validate via Google's own database?


We validate the structured data with our own systems.


So I believe we regularly sync those with the schema.org setup.


I don't know what the technical implementation


is there with regards to syncing the schema specifications.


But that's something where we sync with the schema.org setup,


and we have our own set of rules as well with regards


to which fields and values are required or optional


or what kind of restrictions apply to individual fields.


So that's something where that essentially


happens on our side in the background


and is not something that is done one by one when


crawling and indexing the way.


So that's another reason also why using HTTP or HTTPS,


when it comes to the JSON-LD markup that you have there,


doesn't matter so much for us.


Because we understand HTTP schema.org


is the same as HTTPS schema.org.


And it just tells us we should use our validator


for structured data.


It doesn't mean that we need to double check if this HTTP


or HTTPS URL is the right one.


So that makes it a little bit easier


and allows us to crawl and index a lot faster.


There's Google, which remains very strict with webmasters


with regards to correct information for users.


Do the same with news sites in some manner.


It is often noticed that many news sites nowadays


publish fake news regularly and move to next paid news


when the truth comes out frequently


without clearly declaring the said news came out false


with relevant apologies.


That's a complicated sentence.


Does Google downgrade their rankings


based on some trust site's logic?


So I'm not aware of us explicitly looking


for this kind of information within web pages to see,


like, is this the correct information or not?


But I'm pretty sure you would see a lot of indirect effects


there, where if a website regularly posts information


that is not correct and users end up not trusting


that website, then that's something


that would probably be reflected in our search results


over time.


So that's not that Google's algorithms goes out


and kind of fact checks the math on all of these pages.


And if it's not correct math, then we


will demote them in search.


But it's more that, well, we see that there


are lots of good signals for this page


and not a lot of good signals for another page.


So we'll try to rank the good page a little bit better.


If we have critic reviews with user reviews,


how should we implement schema, one schema for user reviews


and one schema for critic reviews?


Which ratings will Google display in the search results?


What's the best practice when we have both kind of reviews?


So my understanding is that both of these types of structured


data would be shown slightly differently in the search


results.


So my general recommendation here,


when you're faced with a situation where you have


essentially different kinds of structured data


on a single page, where only one of them


is shown in the search results, is to try


to make a decision yourself.


So instead of kind of implementing all of this markup


on a single page and saying, well,


I hope Google chooses the right one


and you don't really know which one is the right one,


then I would make a decision and say, well,


I want Google to show my critic reviews,


or I want Google to show my user reviews.


Therefore, I will explicitly mark those up and maybe not


mark up the other parts.


So when you're seeing this kind of situation


where multiple kinds of rich results are possible,


but you can't combine them, then pick


what you would like to have shown


and be as clear and direct as possible with regards to that


so that our systems can pick it up and say,


oh, these are clearly user reviews.


They're marked up properly.


We should show them in search.


A question about adding no index tag to 404 pages.


In my understanding, if a page was removed and has a 404


status on it, it's already telling crawlers


all they need to know.


So adding a no index tag isn't really


adding any value apart from the speed of removal from the index.


But if my clients already included no index tags


on the 404 pages, are there any negative consequences


of that setup?


So the easy answer is, when we see that a page returns 404,


we ignore all of its content.


So whether or not it has a no index on there,


whether there is, I don't know, a really fancy picture on there


or not, whether the 404 page is essentially just the text 404,


if it's a really fancy 404 page, we


don't see any of that at all.


When it comes to search, we see the status code 404,


and it's like, that's OK.


That's enough for us.


So adding a no index tag there wouldn't change anything


at all, neither positively nor negatively,


nor would it speed up the removal from the index.


As soon as we see the 404, we understand,


well, this is probably something we don't need to index.


So with that in mind, if they already


have a no index on the 404 pages, that's fine.


If they don't have it there, you definitely


don't need to add anything.


If a web page has millions of URLs


with parameters that don't change the content only


slightly, do you recommend to configure in Search Console


this parameters?


Is it strongly recommended?


I think it really depends on the website itself a little bit.


To a large part, we try to learn these parameters automatically.


And so often, if you go into Search Console, into the tool,


you'll see Google has already determined


that these parameters are less important or more important,


for example.


And in a lot of cases, when we have


worked with a website for a while,


then we'll figure out which parameters are important,


which ones are not important, and treat that appropriately


automatically.


If you're starting out new with a new website


or you're adding new parameters to an existing website


and you really have millions of URLs that use these parameters


and maybe thousands of URLs that don't use any parameters, which


are the normal content that you would like to have indexed,


then using the URL parameters tool


is a great way to let us know about that.


So that's something where I would use it, especially


if you're starting out, especially


if you're making bigger changes on your website.


But if it's been running like this for a number of years,


probably we already figured that out.


On our price comparison website, we also


have a shop and seller who sell products


on the site-related pages.


On the shop pages, we have shop info and ratings and reviews.


So we've implemented organization markup


with reviews and ratings in February.


But still, we have not gotten any impression


in rich results yet for those pages in the search results.


I'm seeing our competitors are displaying rich results.


What can we improve here?


Should I implement rating and reviews in separate schema?


Because that's the only thing I want to see with our shop pages


in search.


So I hope the review stars are not the only thing


that you want to see in search, but rather kind


of your content should be visibly indexed anyway.


That's kind of the most important part.


So looking at the review markup, one


of the things that has changed recently,


I don't know if that was in February or sometime before,


everything is a blur.


That's more than a couple of days back.


One of the things that has changed there


is that we only show the review markup for a limited number


of objects.


So that's something where maybe you're marking something up


with a review that is not one of the supported types.


And that might be a reason why we might not


show that in the search results.


The other thing to keep in mind is that, especially


with review markup, the reviews should


be specific to the primary object of the page.


So if you have a shopping comparison site


and you have one page with lots of products on it


and it's just from this one company, for example,


then that wouldn't be relevant to mark that up


with the review markup because you don't really


have one primary item of the page.


You have lots of different items.


Whereas if you have one product that you're selling,


which happens to be from one manufacturer,


and the reviews are all specific for that one product,


then that would be a good use of the review markup on the page.


So structured data should be as specific as possible


to the primary object of the page


and not something general for a page.


Being a newbie blogger, how much time


will my site take to rank in the Google search results


after implementing both on-page and off-page SEO techniques?


So I don't think there's any specific amount of time


for a site to rank in the Google search results.


And it is really kind of a tricky question in itself


because often we just index websites as quickly as we can.


But that doesn't mean that we show them as visibly


as possible.


So everything around ranking depends a little bit


on what else is happening in those search results.


We might be indexing a page within a couple of hours,


a couple of minutes, depending on the website.


But if you're targeting a topic that


is very competitive in nature where other people have spent


a decade or longer kind of working on their website


to improve it, to make it really as fantastic for that one


question as possible, then it's not


going to be something where you can just implement


a little bit of markup and do some off-page SEO techniques


to suddenly rank above these other people who


have worked so much and done so much good stuff


to appear in the search results.


So that's something where there's


no fixed amount of time.


It doesn't mean that you'll never


be able to show above other people in the search results.


But it does mean that when we look at the search results,


we need to figure out what is relevant for the user.


And if we have a lot of information that's telling us


these existing pages are really relevant because they've


been doing really well for such a long time,


then that's a strong signal for them.


On the other hand, if we see, well, these existing pages


haven't been updated in a long time,


and they're outdated, they're obsolete information,


and there's a new website out here


that's providing fantastic information talking


about those themes in a way that others haven't before,


then we might choose the new website instead.


So these kind of things are really impossible to say.


And it's impossible to give it a time


until a website will rank in the Google search results.


I'm wondering if the current COVID-19 crisis will push back


Google's plans for mobile-first indexing for all sites


from September to later this year or early next year.


Good question.


I'd love to have your all's input on that as well.


So I've been in touch with the mobile-first indexing team,


and for the most part, they're still


seeing sites preparing and getting


ready for mobile-first indexing.


So it feels like people are still working on their website,


even if they're maybe not working in the office anymore.


On the other hand, the whole situation


is really hard to take and really throws


a lot of companies off, throws a lot of websites off,


and people working on websites.


It's very challenging.


So that's something that might say, well,


we're seeing people are struggling with this,


and we don't want to create an extra burden of saying,


well, you have to do all of this extra work until September.


Maybe we should push it back.


But it would be really useful for me


to get some feedback from any of you on Twitter or where else


to kind of let us know, is this something


you're seeing people struggle with,


or do you think this is something that people


are planning to do regardless?


Let me know.


I'm happy to pass that on to the team


and to figure something else out.


My guess is we will make a decision on this maybe


sometime in the next month and then either update a blog post


or tweet something with the official account with regards


to the actual date.


I feel like Google sold me a bad domain


and is doing nothing about it.


I bought a domain from Google in March.


A few days after having my old site without penalties


redirected to a new domain is when I found out


about a pure spam manual action.


Two reconsideration requests have been denied.


My site has completely new content and is free of spam.


What are my options besides asking the community?


Because even they don't know.


So that's really hard to say.


I mean, from our point of view, the whole search ranking side


of things is not something that the Google Domains


team works on.


So they would not know which domains had a manual action


or not.


In general, whenever you're buying a new domain name


and you want to move from one domain to another,


it's worthwhile to do some research


and to figure out what happened with the domain name


that you're considering.


And to really look into the details of what


was hosted there in the past.


Is this something that I can deal with?


Do I have to deal with anything or not?


Is this something where maybe there


are a whole bunch of crazy links pointing at the domain name


and it was used by, I don't know,


spammers hosting all kinds of crazy content?


That's something where you kind of,


like if you move to that domain, then you kind of


have to live with that and work on ways


to improve that situation.


So that's something where you really


need to do some research ahead of time


before moving a website to another domain,


especially if it's something that was used in the past.


With regards to this specific case,


it's impossible for me to say because I don't


know the websites involved.


But generally speaking, a pure spam manual action


is based on the content.


It's not based on a domain.


It's not something that would be transferred from one owner


to the next owner.


It's really based on the content that you host there.


So if you're seeing a pure spam manual action,


then that's really something where you need to think


about your content really hard and think about,


like, why would my content perhaps trigger this?


And it's really hard to say because I don't


know what the site is here.


It's certainly possible that the web spam team


gets one of these things wrong.


And with a reconsideration request,


that's a great way to get it in front of another person


on the web spam team.


But it feels kind of unlikely that you


would have two reconsideration requests


and the initial manual action happen


if there's really nothing with regards to the actual content


here that's problematic.


So I mean, it's certainly possible


that you have really bad luck.


If you really feel that it's one of these cases


where you really have fantastic content


and the web spam team just doesn't realize it,


then you feel free to ping me on Twitter


so I can take a look and pass that on to the web spam


team to double check.


But it really feels kind of iffy just based


on the question itself.


I hope you're doing well despite all of this coronavirus crisis.


The question I have is the following.


We recently transferred our website, example.com,


to a multilingual one.


So for most language versions, we


have the ordinary setup, such as example.fr, example.nl,


example.es.


But for the Swedish extension, our international sales


director requested to keep the original domain


of the acquired company.


So instead of having the ordinary example.se,


we have random.se.


I was totally against this setup because I didn't believe Google


will see this domain extension as a primary domain Swedish


extension, but will treat it as a separate domain.


Please clarify from Google's perspective


how this is going to be seen by Google.


OK, so in general, these are all separate domains.


We would not infer from just the example part in the beginning


that these domains belong somehow together.


Essentially, these are completely separate websites


from our point of view.


However, for most kind of multilingual setups


or international setups, you would


use something like the hreflang annotations between maybe


the home page, maybe between other pages on the website.


And for hreflang, it doesn't matter which domains you use.


So if you have example.fr and random.se,


you can have the hreflang annotation between those two.


And that tells us all we need to know,


that this page on random.se has an equivalent


in French on example.fr.


So from that point of view, it doesn't really


matter with regards to which of these domain names


you use for which country version.


For the country versions, it sounds


like you're using country code top level domains, which


is great.


It means geotargeting is already automatically handled.


If you just want international language versions,


then you don't really need to use country code top level


domains.


But if you want to, that's also fine.


So from my point of view, I wouldn't


see this as any kind of a deal breaker or any critical issue


if you don't have example.se and instead have random.se.


Question about multilingual websites.


If we have a proxy buying website that


helps users from different countries


buy clothes from a Chinese auction website,


we use an API to get the product information present


in our website in English and German, et cetera.


While we manually translate information


about the product categories and provide


UIs in each language, there's no realistic way


for us to manually translate the product names and descriptions.


If we leave them in Chinese, that's


not a good user experience and also does nothing


for our English SEO.


Providing automatic translations would greatly help our users.


However, it looks like automatically translated


content is against the webmaster guidelines.


Do we have to leave the product in Chinese to avoid a penalty?


So that's an interesting question.


I think there are probably lots of things that could apply here


as well.


But in general, I would see the automatic translation


as something where, in many cases,


it's just the quality of the translation is really bad.


And that's one of the primary reasons


why we say this is not something that you should be doing.


It might be something that changes over time, where


over time, if we see that these automatic translation setups are


able to create content that's of really high quality


and really easily understandable, then maybe


you can do that.


And maybe that's something that would make sense there.


But overall, we often see that these automatic translations


are just kind of borderline gibberish even,


where it's really hard to tell what those products,


in this case, would actually be about.


So that's kind of the primary consideration


I would have here is if you're taking content


and you're just automatically translating it


into a number of different languages,


and the content that you get out of this is of such low quality,


then keep in mind that we will look at those pages


and say, well, this is low quality English content.


It's low quality German content.


Why should we show it at all in our search results?


So it's not so much about whether or not


you use automatic translations or human translations.


It's just, well, the content is really bad and hard


to understand.


Another thing that sometimes plays a role,


I don't think if you have this many products so much,


but is that a lot of times it's not just


a matter of translating a product name or product


description, but actually you kind of have to localize it


and write in the way that users would expect


and categorize and group your content in a way


that users would expect for those languages.


And that can sometimes be subtly different


across different languages, different cultures,


those kind of things.


So just going back to your question here,


it's like, should you post it in Chinese


or post it in English?


I think the general configuration


is something you might want to reconsider.


I don't think it's something where the manual web spam


team will take a look at this and say, oh, this is terrible.


We should remove the whole website.


But more kind of from a quality point of view,


our teams might look at it and say, well,


we should not be ranking this website because it's really


not that useful of content.


For the new image license metadata for Google Images,


which can result in a badge in Google Images,


I know some large photo sites are


adding necessary structured data and license pages.


But some are adding license pages per image.


And that's resulting in the addition of tens of millions


of new URLs to the site, basically


doubling the number of pages.


For example, a site with 30 million images


might be adding 30 million license pages.


For some of those sites, the URLs


were both crawlable and indexable.


So those sites are adding double the amount


of URLs that can be indexed.


Is Google's recommendation to disallow the license


URLs in robots.txt?


Do the license URLs need to be crawled by Google in order


for the license badge in Google Images to show up?


I can see potential problems with letting


Google crawl and index tens of millions of additional URLs.


So the additional URL here, I had to look this up.


I saw this.


I think the same question was submitted last week as well.


The additional URL is that on a per image basis,


you can specify metadata for licensable images.


And per image, you can specify where the user can buy or


license this image.


So essentially, it's a link to a checkout page, if you will.


From that point of view, like other checkout pages,


you don't necessarily need to have those indexed.


So if you use a no index on those pages,


if you disallow crawling of those checkout pages,


then that's perfectly fine.


That's totally up to you.


So from that point of view, you can definitely


block those from being indexed.


It might make sense to find other ways to deal with that.


For example, if you have the image landing page,


you could just have a checkout button there.


And then people will go through the same image landing page


and be able to do the checkout flow there.


But ultimately, you have to work with whatever restrictions


you have in your CMS.


And sometimes, just creating a separate page for the checkout


is the easiest approach.


So that's totally up to you.


In Search Console, it indicates there are no security issues.


So it's not possible to request a review.


But if you search for our company name,


the this site maybe hacked message still comes up.


How can it be removed if Google Search Console believes


everything is OK, I guess?


So I did a quick search for this company name


and the search results it shows for your home page


is all about pharmaceuticals.


So my guess is your website is still hacked.


Looking at the website directly, I


see it shows normal content.


So this seems like a traditional kind of a hack


where essentially, the webmaster or the webmaster


or the hacker is cloaking to Google and probably sending


users to a different page when they click on your search


result. So that's something where you probably still


need to resolve that issue to make sure


that we can understand that your page is about, I don't know,


I think it was like silverware or something like that


and not about pharmaceuticals.


The best way to do that is probably


to double check in our Help Center.


We have a whole section on dealing with hacked websites.


I'm not sure if it's in the Help Center or in the developer


documentation, but one of those two places.


And it lists essentially the same kind of hack


that you're seeing there where when you go to the page


yourself, you see the normal content.


In the search results, you see the hacked content.


And it has kind of a step-by-step guide


on how to deal with that.


What you can do once you've resolved that issue,


and if you still don't see any kind of the security


issues being flagged in Search Console,


you can just use the Inspect URL tool


and resubmit the home page for crawling and re-indexing.


And we'll pick that up usually within an hour or so.


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


The tricky part with this kind of hack


is it essentially means that the hacker has access


to your server or had access to your server, which


means that you also need to double


check all of the verification settings in Search Console.


So on the one hand, your verification tokens.


On the other hand, any other verification tokens


that might be on that website.


Because we've frequently seen that hackers


will take over a website.


They'll verify the site in Search Console


or kind of like re-verify it with their own account.


And then they'll use their own account and say,


oh, my website got hacked.


And like Google, can you get rid of this warning


because I fixed a hack?


And hope that someone from the Web spam team


removes kind of the this site is hacked label,


even though it's still the hacker who's


asking for this to be done.


So that's something where you really


need to double check all of the verifications on your website


and make sure that only you are the one who's actually


a verified owner.


And then, of course, by following the guidelines


or the guide in the Help Center, make sure


that your server is locked down appropriately


so that the existing hacker or any other hacker


won't be able to get in again.


So I think it's sometimes a really frustrating process.


But it's really important to follow through


with those steps.


And if you have kind of any difficulties


along the way with that process, I


would strongly recommend getting help


from someone who has a little bit more experience in this


because they'll be able to see kind of those places


where hackers traditionally hide their code


and help you to really clean things out completely


and to get it resolved as quickly as possible.


Oof, OK.


To add the two-step authentication.


Two-step authentication.


Yeah, I think that always makes sense for your accounts.


But if someone is hacking your server,


then the authentication on your own account is kind of, yeah,


not that useful.


But it is something where it's, I


don't know, the first time you get


your site hacked like that, it's so frustrating.


And it's really hard to understand


what you should be doing.


So it is definitely worthwhile getting help.


Maybe go to the Webmaster Help Forum


if you're really unsure about things.


There are people that are active in the Webmaster Help Forum who


have seen a ton of hacks and who can


help you to find some things.


But probably, if this is a company website,


you probably want someone that you can interact with one


to one and just get it resolved as quickly as possible


and understand exactly what happened


so that you can make sure to avoid that in the future.


All right, let's see if anything else popped in.


Otherwise, yeah, I think.


Oops, someone was waiting for the link.


Let me just copy that.


That was 30 minutes ago.


Sorry.


Yeah.


Hey, John, I have a quick question.


Sure, go for it.


Is the special announcement COVID schema live yet?


I don't know if it's live yet.


I think it's, as far as I know, it's still


in kind of in the rollout phase.


I don't think it's live in general yet.