then we would only count that when it's loaded


English Google SEO office-hours from September 3, 2021

into the viewport, actually.


Right, OK.


OK, I thought I'd just ask on that.


And is it a sample of the data, or is it 100% of the data?


It depends.


So we track a certain number of entries per site per day.


And for most websites, that's kind of enough


to track everything.


And for some websites, it's something


where we do have to do some amount of sampling there.


OK, thanks.


Then title tags.


If Google is changing display titles to other HTML elements


but that doesn't impact rankings,


does that mean that the weight of the title tags


as a ranking factor will eventually decrease?


I mean, eventually, who knows what will actually


happen in the long run.


So I can't promise that nothing will change there.


In fact, almost certainly it will change at some point.


But I don't think there are any plans


to decrease the weight of title tags overall.


Maybe that's something that happens over time,


but at least not at the moment and not


with this specific title tag change.


Does Google look at my other websites in Search Console


to give a quality score to a certain website?


Or are all websites separate from each other?


No, I don't think we look at other websites in your Search


Console account.


On the one hand, this would be really tricky


because there are lots of agencies that work


on a wide variety of websites.


And just because they're in one account


doesn't really mean that much.


So essentially, I would assume they're all


treated as separate websites.


Looking at rebranding, moving domains, most of the content,


CMS, and the website structure will remain the same.


The main concern is we're going from a.com domain


to a.co.uk.


Majority of our customers are based in the UK,


but we get traffic from all over the world.


Is that a problem, like going to.com,.co.uk instead of.com?


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


So with a.co.uk domain, you are essentially automatically


geotargeting the UK.


But it can be a global website.


So the one thing that you can't do with a.co.uk domain


is to create a separate section of your website,


like a separate subdomain, and say this


is for a different country.


So if you had maybe, I don't know,


a version of your site for Australia or for, I don't know,


some other country, and you called it Australia.yoursite.co.uk,


you would not be able to do geotargeting


for that part of your website.


Because essentially, we say everything on this domain


is already geotargeted to the UK.


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


I would imagine that you would see traffic fluctuations


for a while when moving like this,


just because of the matter of going from a generic domain


to a country code-specific domain,


or even the other way around sometimes.


It takes a bit of time for things to settle down.


And I would definitely expect fluctuations


when you say most of the content will remain the same.


Because if most of the content remains the same,


that means that there are some changes.


And when there are content changes and domain changes,


and you're moving across this non-geotargeting border,


I would definitely expect some changes there.


With regards to should you use the.com instead


of the.co.uk, I think from an SEO point of view,


there's probably no reason unless you


plan on targeting other countries


with that same domain.


But maybe there are reasons from a marketing point of view


or kind of like general engaging with users point of view.


From an SEO point of view, if you want


to target other countries, the approach


you would have to take with a.co.uk domain


is to essentially use a different domain


for the other countries.


So you would have australia-yourwebsite.com


or.com.au instead of your subdomain site.


But that's also doable.


What are your thoughts on large sites splitting


into multiple CMSs?


Any concerns or anything to watch out for?


We don't do anything special with CMSs.


We do understand that they exist.


And I think we track them in the sense that in, what is it,


HTTP Archive, there's kind of a CMS classification thing there.


But that's more a matter of kind of like having metrics


on what is happening on the web and not something


that we would take into account for ranking or for indexing.


So essentially, having multiple CMSs on the same website


is perfectly fine.


But the things that you would watch out for with CMSs


in general, they apply there as well.


So if you have a CMS that creates kind of crafty URLs,


then that's something you would need to fix.


But that's something you would need to fix anyway


if you use that CMS.


It's not different just because you have multiple of these


on the same site.


My website is a download site.


And I update the post quite a bit.


Sometimes I get Search Console warnings


with unusual downloads or harmful downloads,


even though I test every file I upload.


These tend not to have any example URLs.


So it's very hard to kind of figure out


what should be done there.


Yeah, I don't know what the best approach is here.


So the thing I would watch out for here is, first of all,


to make sure that you're not systematically generating


new download files on your own.


Because I think, what is it, unusual download


or something, uncommon download is the warning that we show.


That's something we show in Search Console


and in the browser.


When we see that a user is downloading something


that looks like it might be an installable that we haven't


seen before or that we've rarely seen before that we haven't


been able to check before.


And that's something that can happen


if you tag your downloads.


For example, if people sign up and you include that sign


up information in the download file itself,


then the download will be unique for every user.


And that means that we won't be able to scan them proactively.


So that's kind of the thing that you


would need to watch out for if you're creating a download


site.


Ideally, make sure that you're passing


on the original download and not something that you're


putting together yourself.


Because that way, we can understand,


oh, this is a file we've seen before.


We know this is safe.


We don't have to do anything with this.


From a site owner point of view, if you're


seeing this occasionally, you can always


use the Request Review button in Search Console,


especially for these kind of files.


Because what will happen there is


our systems will then go off and actually double-check


those files.


And they will let you know if there's something actually


problematic with those files.


And they will give you the URLs then.


So that's kind of like, on the one hand,


try to avoid the situation where you create unique downloads.


On the other hand, it's fine to request review


if there are no examples and you need some more examples.


PPC versus SEO landing pages.


Our site has one URL that we use for PPC and SEO purposes.


We'd like to split this into two URLs.


However, both PPC and SEO teams want to keep the original URL.


So I think the question is, so who gets to keep the URL?


Which is more important, PPC or SEO?


So just from a personal point of view,


I think the SEO side is something


where it probably makes more sense to keep the original URL


because there's just a lot more tied in with regards


to the performance for that specific URL.


So I think on both sides, there is a matter of tracking.


You don't want to change your tracking.


You don't want to change things like that.


But on the SEO side, if you were to create a new URL,


you essentially wouldn't be able to redirect from the old URL


because people want to reuse that.


So essentially, you would be starting off


with a completely fresh page rather than starting off


with that state of whatever you've done so far


kind of gets passed on.


So from that point of view, I would


suggest to keep the original URL for SEO


and create something separate for the PPC side for tracking.


However, I don't know how the PPC side does things


like tracking the quality of URLs


and if that would also play a role


and if both sides want to keep the history of the URL.


So that's, I don't know.


I don't know everything there.


Is structured data penalty a thing and enforced?


I think we looked at this before.


Google News, we looked at that.


The web view page, we looked at that.


We're facing an issue when trying


to call the Search Console API using a service account


authorization.


I looked at this question briefly beforehand,


but I don't know all of the details here.


And it looks like you posted in the help forum.


So I think that would probably be the best place there.


I will send someone from the Search Console side


also to double check the thread in the help forum


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


Now, let's see.


Question about a site link.


I have a global e-commerce site.


Recently, Google started showing other countries in the site


link in the search result. For example, a UK website search


result is included in the Australian site link.


I use hreflang properly.


Google used to have a site link demotion tool,


but that's gone now.


How do I fix this?


Yeah, I think the tool has been gone for a really long time


now.


And the main reason we kind of dropped that tool


is because from our point of view,


site links are essentially normal links on a page


that we would show in the search results nowadays.


And it's less a matter that there is something


kind of unique about the site links.


So that's something where if you're seeing something


like the cross language or cross country versions in the site


link file, in the site link results, that usually points


at something where something with geotargeting


or with hreflang is not working out properly.


So I would double check some of that


just to make sure that the hreflang setup is really


working properly.


And if when you check that, you see that everything is set up


properly on your website and Google is just


confusing everyone by showing a different language in the site


link, then send me some examples.


Send me some screenshots and some sample queries


that I can do.


And then I can pass that on to the team that


works on kind of the international results.


And we can see if we can find something in our algorithms


that we need to improve there.


Can we use the google.com KGMID?


Essentially, kind of a specific URL for knowledge graph


entities, I think, as the schema.org same as property.


As far as I know, you can do this.


I don't know if it's a good idea, though.


Because essentially, the knowledge graph ID


that we have on our side, it could change over time.


And when you're looking at something


like the same as property in structured data,


you really want to provide something that is stable,


something that always remains the same so that over time,


we can kind of associate more and more things with that.


And if you assign something that is generated


by Google, which theoretically could change over time,


then that feels a bit, I don't know, brittle.


And it feels like something that could break over time.


So as far as I know, I would try to avoid doing that.


And instead, do something like pointing at your contact page


or your website home page or a Wikipedia


article about your company or anything like that,


which is something that is more stable than the knowledge graph


ID.


And is it necessary for a new website


to submit a sitemap file?


It's not necessary to submit a sitemap file,


especially if you're a very small and new website.


However, it does make it easier for us


to recognize where there is new and updated content.


So I would definitely recommend doing that, especially


if you're starting out, especially if you're using


a common CMS, whereas making a sitemap file is often


just a matter of a checkmark.


So I would definitely do it.


It's not a requirement, but it's a good practice.


Cool.


OK.


We're kind of running into the end of time of the session.


So maybe I'll just get some more live questions.


And I have a bit more time afterwards as well


where we can extend a bit.


Let's see, Tim.


Hi, John.


Hi, everyone.


Hi.


Just a quick, so we're seeing a slow decline


in mobile-friendly pages in the mobile usability


report in Search Console.


We're also seeing a decline in pages


in that are in the Core Web Vitals report


and also other enhancements like review snippets and all


of this type of stuff.


These are all product pages, I've noticed.


And over the span of maybe a month or a month and a half,


there's about 1,000 pages.


I'd just like to know where I should be looking.


Is this a crawling issue potentially?


Where should I be looking here?


They're not coming up as errors or anything.


They're just simply dropping out of that report.


Yeah, I think we had pretty much the same question right


at the beginning.


But essentially what is happening


is for these reports, we look at a sample of the URLs


from your website.


So it's something where having fewer URLs in these reports


doesn't mean that the other URLs are bad or problematic.


It's just we didn't check them.


So especially for the aggregate reports,


which is for the Core Web Vitals to some extent,


the AMP report, the structured data reports,


mobile friendliness, I think, as well, for those reports,


we only take a look at a sample of the things.


And that sample can change over time.


So it can happen that we look at 200 URLs from your site,


I don't know, now.


And then maybe in a month or two,


we'll look at 100 URLs from your website.


And that doesn't mean that the difference is bad.


It's just we looked at a smaller sample of the URLs


So usually what you would do with these reports


is look more at the relationship between the bad pages reported


there and the good ones.


If these are all reported as being OK without any errors,


then that means all of the URLs we checked from your site,


they're OK.


So from that point of view, that's fine.


If, on the other hand, you see that the proportion of errors


rises over time, then that's kind of a sign


that something is problematic that you


might want to take a look at.


But the absolute number of URLs that we show there,


that's not something that you need to take any action on.


OK.


Sorry about asking the same question.


I joined maybe 10 minutes late.


Sorry about that.


No problem.


So just on, OK, well, that pretty much


answers my second question as well.


So thanks for that.


Cool.


All right.


Let me take a break here and pause the recording.


And there's still some hands raised


so we can get to you all later as well.


To anyone watching this recording,


thank you for watching.


If you'd like to join these in the future,


feel free to jump on in.


We post them in the calendar on the Google Search Central site


as well as in the community section on our YouTube channel.


So feel free to drop questions in there.


If I didn't get to yours, feel free to go to the Help Forum


as well.


Lots of experts are there who are able to help.


And maybe see you in one of the future episodes.


English Google Webmaster Central office-hours from January 24, 2020

OK, welcome, everyone, to today's Webmaster Central


Office Hours Hangouts.


My name is John Mueller.


I'm a Webmaster Trends Analyst here at Google in Switzerland.


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


where folks can join in and ask their questions around SEO


and websites and Google Search, of course.


Bunch of questions were submitted already.


But if any of you want to get started with a question,


you're welcome to jump on in now.


Good.


I would like to get started.


So I mentioned already in the comments.


So we see at the moment the huge issues


when it comes to indexing of correct URLs.


So for example, for the brand IKEA in Germany at the moment,


so when we are searching for IKEA Kitchen in Germany,


Google is showing the Austrian version of the URL


instead of the German version.


And on the second place, an old URL,


which is in PDF, which is redirected.


So we tried everything to fix this from a technical side.


So we were checking all redirects, sitemap XML,


hreflang text, robots.txt, check technical issues


like our times regarding also CDN and so on.


But we haven't found any issues, technical side or content side.


And also have an old manual action in place,


especially in our other search engines,


as showing this issue.


So it would be interesting to get your thoughts about this.


Now, I saw that question this morning.


And I had a chance to briefly look into it.


And it feels like something maybe on our side


where we're kind of holding on to particular URLs.


So I've passed that on to a team to double check.


OK.


Yeah.


I don't think there is anything particular on your side


that you're doing wrong.


Sometimes with different country versions


that show the same content, it's a bit confusing on our side.


But we should be able to catch that better, especially,


I think, the PDF example that you gave with the PDF URL.


That's something that, to me, just looks like something


is stuck on our side.


So you will keep us updated on such an issue


and we'll give an official update on this?


Usually, what happens with these kind of things


is when I pass them on to the engineering teams,


they're able to kind of look at them


and find a way to resolve them.


And that's something that'll resolve itself over time.


Most of the time, we don't have any official updates


that we can pass back.


OK.


So we should see some updates in the Google Search Console


regarding indexing status of the correct subdomain.


I imagine you'd see that.


Yeah.


Thanks, John.


Sure.


I think there was another one who wanted to jump in.


Hi, John.


I have a question.


Hi.


Thing is that, say, I met a client


and I'm going to begin for him.


When I saw the website, a majority of the pages


are indexed in non-dub-dub, and a few pages


are indexed in dub-dub-dub.


So is it OK if we just select the preferred domain


as HTTPS-WW, or do I need to do 301 for all the non-dub-dub


majority pages to WW version?


I'm just scared because the site is around five years old


and there are around 20k-plus pages indexed with non-WW.


So just wanted to check on you.


Usually, the preferred domain is good enough


for these kind of cases where it's the same content


on both of the variations.


From a best practice point of view,


it's always good to redirect, though,


to make sure that you're following up on that.


But if you can't set up the redirect,


then the preferred domain makes it easier for the data


to be in the right version.


The other thing you can do is use domain verification


in Search Console.


If you use domain verification, then it


doesn't really matter which of these versions


are shown in Search.


All of the data will still be in that one account.


SPEAKER 2


Hi, John.


Can I ask a question?


Sure.


So I have a question regarding Search Console.


So in Search Console, I find my normal pages are 66k around.


But in the mobile-specific pages,


I only see 300k, three k pages.


So I was just wondering why this happened.


So how do you mean in the mobile section?


So then I see in the main coverage page,


I see 66 valid k pages.


But when I see a mobile usability pages,


I see only three k valid pages.


Oh, OK.


That's completely normal.


So the index coverage report shows essentially


all of the indexed URLs that we have from the site.


And the aggregate reports, like the mobile usability report,


the structured data reports, also the speed reports,


they only focus on a small part of the total index.


So that's something where it would


be normal to see that difference between the total counts.


What you would watch out for in those reports


is just that kind of like the percentage of errors


that we show.


So it's not so much that the total number of pages


has to match, but that kind of the errors in those reports


are fairly low.


OK.


OK, cool.


Thank you.


Sure.


Hey, John.


Can you hear me?


Depends on how complicated the question is.


It's not that complicated.


Yeah, so I guess this question is sort of like a question


off the back of the knowledge panel featured snippets.


And how that's counted in Google Search Console for a few


of the keywords that we've looked at in Search Console,


where after this update has happened,


we've basically just seen our position almost


go to the bottom of the search results.


So is it counted at the bottom, or is it at the top?


How is it supposed to function?


Nothing really changed there with the way


that Search Console tracks the position.


So what happens in Search Console


is we track the topmost position of either the URL or the site,


depending on how you're looking at the report.


And we use that for the averages.


So if the topmost position hasn't changed,


like if you're being featured as a featured snippet already,


then that would continue to count the same.


On the other hand, if your featured snippet


moves on the page, or if the featured snippet is no longer


shown, and only your normal, I guess, well, both of them


are kind of organic search results, but kind


of the traditional search result is shown instead,


then that position would be ranking.


What I've also seen in some screenshots,


I haven't looked at it in detail,


is that we also show something on the right sidebar sometimes


that looks like a mix between a knowledge


panel and a featured snippet.


And that would probably count as, I don't know,


position 10 or 11, because we kind of number them down


and then decide.


So if the featured snippet moved from kind


of the top of the first column to the top


of the second column, essentially,


then that would count as a different position.


Awesome, that perfectly answers the question.


I don't know.


I haven't looked into that in detail.


But that's certainly possible.


I know they're still working out some of the details


and making some changes there.


So it's like some things are still in flux.


Awesome, thanks, John.


Sure.


All right, let me run through some


of the submitted questions.


And we can get to more live questions as we go along.


In Search Console, I see a number


of industry-related websites have linked to a number of PDFs


I have available on my e-commerce site.


However, my PDFs don't have a link


within them going back to the relevant product or category


page.


Should I add one?


Would it help from an SEO ranking point of view?


So first off, I think this is a really interesting question,


because lots of people have PDFs on their website.


And probably most people are not thinking


about links within the PDFs.


From just a pure usability point of view,


I think it makes a lot of sense to have a link back


to your products, back to your website,


back to maybe the category pages even within these PDFs,


because these PDFs might get spread around.


People might share the PDFs directly with other people.


And making it easy for folks to get from the PDF to your website


is a fantastic idea.


So that's something I would encourage


you to do, regardless of any SEO aspect there.


With regards to SEO, because within PDFs,


there is no way to let us know that a link is really


a link that you want to use to pass signals,


we would generally view these links as text links


that we also find in text files, essentially


as similar to a no-follow link, in that we recognize


the link is there.


We can look at where this link is pointing at.


But for the most part, we would not be forwarding any signals


through those links.


So from a pure SEO point of view,


I would say it's questionable that you


had any advantage from this.


But from a usability point of view,


I would totally make sure you have


those links within your PDFs.


There's advice on the internet.


Oh my gosh, I am sure this is bad.


Advice on the internet about cleaning HTML code


and its effect on SEO.


Is it really important to delete old HTML comments, for example?


OK.


So essentially, you don't need to clean HTML comments


within your HTML pages.


That's not something that has any effect on search


at all unless you have kind of an extreme amount of HTML


comments, in the sense that maybe you're


looking at a page that is 100, I don't know, kilobytes of HTML,


and you have 100 megabytes of HTML comments in there,


then that's going to be really hard for us


to figure out where the actual content is.


But if you have a normal amount of HTML


with kind of a reasonable amount of HTML comments in there,


that makes absolutely no difference.


And with regards to those extreme cases,


that's something you'd also see from a speed point of view.


But just from a personal point of view,


I have never seen any page that has so many HTML comments


that it would cause any problems.


So it feels like something where, theoretically, you


could create such pages if you copied,


I don't know, Shakespeare and War and Peace as HTML comments


into a page.


But that's not going to be something you see in practice.


Multilingual sites sometimes use the same media library


that results in the same image being used on the page


in different languages.


Do you recommend going through the hassle


of duplicating the images so relevant


file name can be provided for each language


version of the website?


No, you absolutely don't need to do that.


There are two things here.


On the one hand, the file name is a really, really


small factor.


And we see a lot more information


from the rest of the page.


If you have text on the page, if your image is embedded


in a very prominent way, that helps us a ton more


than the file name.


And on the other hand, when we recognize


that images are duplicated across a website


or across the web, we, kind of like with HTML pages,


we fold them together and just keep one copy in our index


anyway.


So there is no advantage from just duplicating images


for multilingual websites.


How long does it take for Google to replace


the old contents of a website if the website content has


been removed?


How long does it take for Google Mobile to index websites?


So in general, I think this comes back


to how Google crawls and indexes.


And we crawl and index pages at different frequencies.


So what will happen is that some pages we


recrawl every couple of minutes.


Other pages we recrawl every couple of months.


And somewhere in between there is kind of most web pages.


Usually, on a common website, we will


recrawl the important pages, like the home page,


maybe the higher level category pages, every couple of days.


And from there, it kind of goes down to maybe once every half


year or so where we recrawl pages


that we think are really a lot less critical on this home page


or especially pages that we think don't change a lot.


So depending on which page you changed,


if you change your home page, we probably


notice that within a couple of days,


if you changed some random page way


in the bottom of your website, then probably it


would take a couple of months for us to recognize that.


And if you change your whole website,


then what will generally happen is the more important pages,


the ones that are visibly shown in search,


they'll be updated fairly quickly within a couple of days,


maybe a week or so.


And the kind of less visible pages in search,


they'll be updated over a longer period of time.


So you'll see kind of this curve of it really updates quickly,


and then it kind of slows down with the update speed.


If a user right-clicks an element on the search result


page and opens a new tab, will it be counted as a click?


Because the definition says any click


that sends the user to a page outside of Google Search


is counted as a click.


But in this case, the Google Search is still on.


Good point.


Maybe we should clarify that in our documentation,


but it feels like a really weird edge case.


Any click like that is counted as a click.


So if you right-click or if you middle-click


or if you have some other mechanism for opening


a URL in a separate tab or in a separate window in a browser,


we count that as a click.


Essentially, anything where you're going to that page,


you're loading that page directly.


Is it important that all pages of the site


are accessible within transitions


from the main page?


For example, some news from 2015 before, say,


is accessible only in 10-plus steps.


Is that OK?


That's perfectly fine.


Usually, what happens here or where this comes from


is that on a lot of websites, the home page


is the most important part of the website.


So we recrawl that fairly often.


And from there, we try to find new and updated pages


or other important pages.


So what will happen is we'll see the home page is


really important.


Things linked from the home page are generally


pretty important as well.


And then as it moves away from the home page,


we'll think, well, probably this is less critical.


So that's something where you might see things like this,


where someone will say, well, some amount of steps


is the minimum steps from the home page.


From our point of view, that's less about SEO and more about,


well, we have to discover all of these pages somehow.


So if news articles from 2015 are behind some archive


where you have to find the archive, find the year,


and then look at the month, and look at maybe a category,


and then find the news article, usually that's


perfectly fine.


On the other hand, if there's something


that you really, really care about


and you think is really important


and you hide it away like that, then probably we'll


think it's not as important.


So if you think it's important, then


make sure it's really easily findable within your website.


I am seriously considering improving


the usability of some of our pages


by adopting an accordion page presentation.


My concern is, as the user will have to physically open tabs


or windows to see the content within,


will this affect Googlebot's ability


to read and assess the content?


Please advise how accordions affect crawlability


in subsequent or ranking.


Yeah, I don't know exactly what kind of setup


you're looking at.


So it's hard for me to say for sure.


A really common kind of accordion that we see is,


or kind of like a carousel, though it's kind of similar,


I guess, is where you use this UI element to essentially


navigate to other pages.


And in cases like that, usually the content


within the accordion or within a carousel


is still within the HTML page.


So what would happen in a case like that


is we'd be able to pick up this link to the other page


regardless of how it's displayed on your page,


and we would just follow that like a normal link.


So that's generally a total non-issue.


On the other hand, if you're setting something up


where the full content is within an accordion,


then that's potentially kind of tricky.


Maybe that's also kind of OK.


If the full content is within your HTML page


from the beginning, then that's fine.


On the other hand, if clicking on the accordion


causes the server to load that content into the accordion


content, then we would not be able to figure that out


during crawling and indexing.


In particular, anything that requires any interaction


in order for the content to be loaded,


that's something we would probably miss out on.


If the content is already loaded by default,


then that's generally not a problem.


Theoretically, could a website that's only one to two weeks


old rank for top positions on Google


for ultra-competitive head keywords,


say, for example, for shoes?


With significantly better content,


only considering it's the most important part


of the core algorithm.


If not, then clearly time is a factor


when it comes to ranking pages for highly competitive areas,


no matter how good they are, unless new pages are created


on already established websites.


So I think these kind of theoretical questions


are always a bit tricky, because the answer is, well,


theoretically, lots of things could happen.


But in practice, things are not so theoretical.


So I don't really know if there is


a good answer that would be useful to give for something


like this.


We use lots of different factors when


it comes to crawling, indexing, and ranking.


And sometimes that means that completely new websites show up


very visibly in search.


Sometimes that also means that it can take a bit of time


for things to settle down.


In particular, with completely new websites,


one of the difficulties that we have


is we might not have a lot of signals for those websites.


So we have to make estimates.


And depending on how we make estimates,


that can sometimes mean that in the beginning,


we show this website a little bit more visibly than,


like, it turns out that the signals tell us in the end.


It could also mean that in the beginning,


we show this website a little bit more, less visibly


than the signals might tell us in the end.


So that time period of understanding the website


and understanding how it fits in with the rest of the web,


that's always kind of a factor there.


But that can go both ways.


It can go in the direction of, like, you're


shown very visibly in the beginning.


And it can also be that maybe you're shown less visibly


in the beginning.


And as we understand your website


and how it fits in with the rest of the web,


then we can kind of adjust that.


And we do have different algorithms that pick up


on things really quickly.


So for example, some news item happens,


and we try to pick that up within seconds.


Sometimes it's also new websites that show up that we


try to pick up really quickly.


So it's not that time is the only thing that matters


or time doesn't matter at all.


There's lots of nuance.


I have a two-year-old property website


with more than 400,000 pages.


The thing is my URLs are with underscores instead of dashes.


As I'm doing an extensive on-page SEO,


I just want to ask, is it worth changing all my URLs


from underscores to dashes?


So no, you don't need to do that.


In general, we do understand words separated by dashes


a little bit better than words separated by underscores.


But that difference is really, really minimal.


So that's something where I would not just


revamp a whole website to go from one format to the other.


The main reason I would not do this


is because the positive effect is really tiny


and the negative effect from revamping your whole website


to a completely new URL structure,


that is much stronger.


And that's something that you'll have


to worry about for quite some time


until it really settles down.


So any time you completely revamp the URL structure


on your website, that means we have


to understand all of the connections between all


of the old URLs and the new ones.


And we have to recrawl the whole website


to understand how the internal linking works.


And usually, that's something that I'd say


takes a couple of months at least.


And it can take much longer than that,


depending on the website.


So from my point of view, the potential upside


of having dashes instead of underscores


is so tiny compared to the downside of having


to revamp the whole website.


If you're starting a completely new website


and it's like dashes or underscores, I don't care.


I will just pick one.


Then I would go with dashes.


But if you have an existing website,


then don't revamp it just because


of underscores versus dashes.


I'm looking at my home page in Search Console's live test,


and it looks completely unstyled.


Inspecting the More Info tab tells me


the main CSS file wasn't loaded due to an other error.


I'm concerned that Google will evaluate my site's UX


negatively because of this.


So first of all, we would not evaluate your site's usability


That's something that sometimes happens when we render pages.


What might happen in some of these cases


is that we would have trouble understanding


that it's a mobile-friendly page.


But that's something that, for the most part,


settles down fairly quickly.


The other part of the question is, well, this other error


is totally not actionable.


I have no idea what is wrong.


You're not wrong.


That does seem like something that we should


make a little bit clearer.


A lot of times, other error also just


means that we didn't get around to fetching this URL


for this particular live test.


And that's potentially different from when we actually


index the page and render the page on our side


because with the live test, we want to focus on speed.


We want to make it so that you see a result as quickly


as possible.


So we will not use caching.


And we'll have a much lower timeout


than we would for indexing, just so we can show you a result


as quickly as possible.


I don't think it's really that useful if it's like,


you do a live test and it's like, oh, we


will get back to you in a couple of hours with the results.


That's not very useful for you.


So we try to optimize for speed rather than for completeness


with the live test.


And for indexing, it doesn't matter


because we can say, well, we'll spend, I don't know,


an hour or so to figure out how to get all of these URLs that


are embedded and to cache them properly so that we can render


all of the pages on your website.


We have times.


Nobody is rushing us when it comes to rendering.


So that's something to kind of keep in mind there.


I have a sitemap index of 200 plus sitemap files, I guess.


Usually, when we submit the index in Search Console,


it shows all sitemaps indexed.


But on one of my domains, it suddenly


stopped showing some sitemap indexes.


Now, my many URLs have shifted from submitted an index


to submitted but not indexed.


Errors have also reduced in half.


What is happening here is really hard to tell


without knowing your website.


So I'd recommend maybe starting a forum thread with the details


there to double check.


In general, a sitemap file helps us to better understand


your website, but it's not a requirement


for crawling and indexing.


So if at any point we're not able to process your sitemap


file, we'll still be able to crawl and index


your pages normally.


And that's essentially fine.


The other thing to keep in mind is


that we don't guarantee indexing of all pages.


That's just physically not possible.


There's so many things that are submitted as sitemap files,


and we just don't have storage for all of that.


So it's completely normal that we only


index part of a website.


And for smaller websites, we'll generally


try to get everything, but especially


for really large websites where you're creating, I don't know,


hundreds of thousands of URLs, and maybe you


have different facets and filters and pagination


and other URL parameters.


That's something where it's completely normal


that we just wouldn't be able to index all of them.


Implementing a carousel of product pages


with images on the home page or simple text links


in normal font, does it make a difference for crawlers


and priorities?


Not really.


Well, for crawling, we need to find those links.


And if we find those links, that's completely fine.


For search ranking in general, one of the things


to keep in mind is that anchor text does help


us to understand pages better.


So if you don't have any anchor text leading to internal pages,


for example, if you just have an image,


then that makes it a little bit harder for us


to understand what this page might be about.


Whereas if you have a text link, that's a lot easier.


With images, you can also use an alt attribute for the image,


and that works just as well as an anchor text.


Then that question from the beginning.


Talked about that.


What happens to internal links, page rank of a page


when it's canonicalized to a slightly different page


with different internal links?


So when it comes to links, we see links


as being between canonical pages.


So we see any particular link on the web


as going from this canonical page to another canonical page.


And on both sides, there might be multiple pages


or multiple URLs that are associated with that canonical,


where we say, well, these, I don't know, five variations


all belong to this one canonical.


And on the other hand, maybe you also


have multiple URLs that are associated


with a canonical on your side.


And from our point of view, we combine all of those signals


and keep them with that canonical.


And then with that link, we point it at the other canonical,


and we combine all of those signals there too.


So if you're linking from a non-canonical page


to a page that is canonical, then that non-canonical page


will first be canonicalized to the canonical.


And then from there, that link will essentially work.


And similarly, on the receiving side,


if you have multiple pages that are canonicalized,


that's collected in that canonical.


So from that point of view, you don't


need to do anything special.


You don't need to remove links on non-canonical pages


or anything like that.


We try to just figure that out and make it work.


My competitor is sending fake traffic


to my website every day.


Will that affect my website's SEO and ranking?


No, absolutely not.


If this is what keeps your competitor busy,


then you have more of a chance to focus on real business


aspect.


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


you can probably just block them by IP address if you wanted to,


but it has absolutely no effect on your site's SEO and ranking.


So let them do useless things while you do something


that makes a lot more sense.


Is having search keywords Google translated


in other languages on a page a bad thing for SEO?


Users don't seem to click my website


because my title isn't in that language,


but the search keywords are.


Does Google consider this bad behavior?


So I'm not quite sure what you mean with search keywords.


If you mean the keywords meta tag, we completely ignore that.


So you can put whatever you want in there.


It has absolutely no effect.


If you're just dropping these keywords on your pages,


then probably that doesn't make a lot of sense,


because if your page isn't really in that language,


then users might go to your page,


but they just go somewhere else after they look at your pages.


So from that point of view, we don't necessarily


need to consider it bad behavior,


because users are just not finding


what they need on your website.


And that's more like your problem, not our problem.


Well, I guess it's also our problem, because we're


sending people to a page that is not that useful.


But for the most part, it's really


something where if you're placing misleading


content on your pages and hoping that improves your website


in search, then that seems like a very, very short term


thinking and not something that I would recommend.


If I do convert my whole website into another language using


Google Translate, will Google treat it as duplicate content?


So first, we do not treat translations


as duplicate content.


Translations are totally unique pages.


Secondly, if you're using Google Translate,


that translation might not be that great.


We would consider this to be automatically generated pages.


So that's something where I wouldn't recommend just blindly


using Google Translate.


Using Google Translate together with manual translation


reviews, kind of a normal quality assessment


process behind that, that's a totally different thing.


You're essentially creating a localized version


of your website.


But just blindly using any kind of translation tool


to automatically create a translated version,


that also seems like short term thinking,


because a local speaker will look at that page


and say, well, this is not what I need.


I'm not going to stick around on this website.


Is it making attachment pages indexable?


A bad thing for SEO.


My users like to get access to attachments separately.


I populate the attachment page with the metadata of the file.


That seems perfectly fine.


I don't see any issues with that.


Some people like to go to long form text.


Some people just like to get to a specific piece of content


that they're looking for.


And depending on what you're looking for,


and depending on what kind of attachments you have,


what kind of information you have there,


that could be a completely reasonable type of page


within a website.


I would just watch out for kind of going down


the direction of creating pages for the sake


of having created pages.


The number of pages on your website


is not what you should be focusing on.


You should really be focusing on the quality of the pages


that you're creating.


So for example, if you create attachment pages


for every image on your website, then for most websites,


that doesn't make a lot of sense because you're


creating all of these pages and people aren't really using


them.


On the other hand, if it's a stock photography website,


then maybe that does make sense.


So that's something you kind of have to figure out on your own.


I recently saw a significant drop in ranking.


No manual action or security issues.


However, some pages are still ranking high


in the search results.


But most of our service pages have really


dropped significantly in ranking,


along with our blog posts.


What could be the problem?


Some service pages still ranking high,


while others have dropped significantly.


And there's the URL.


I need to take a look at the URL to see what exactly this might


be, but in general, changes in ranking can happen.


So that's something where just because things have been ranking


well for the moment doesn't mean they will always


continue to be ranking well.


And kind of similar to that question earlier on,


new pages can also rank well.


So it can also be that suddenly there


may be lots of other pages that are ranking well


because either they're new and they're


really good, or either our algorithms are thinking


that maybe these are more relevant for some


of these queries.


So these kind of things is not something


where there's one particular reason why this is happening.


There can be lots of reasons why there


might be changes in ranking.


In general, what I'd recommend for cases like this,


where you're kind of unsure, like, is it on my side?


Is it on my website?


Like, is it on my side?


Is it something on Google's side?


I'd go to the Webmaster Help forums


and make sure to mention your website and some of the queries


that you are looking at so that the folks there can take a look


and give you a little bit more of an honest assessment


where they say, well, your website looks fantastic.


Maybe Google did something wrong,


and they can also contact us and escalate it to us.


Or similarly, they might look at your website


and say, well, actually, this doesn't look that great.


Maybe you should put more work into improving your website


first.


And then over time, we'll see if this is something that Google


needs to change as well.


I've been getting hundreds of 500 errors in Search Console.


I check my server logs for the pages that


got reported for 500 errors, the days that Search Console said


it tried to access them.


But I could only confirm that Googlebot visited these pages


one out of 10 times.


Do you know why Search Console would report crawl


for a page on a certain day, and it wouldn't show up


in the server logs?


So I think, first off, we don't kind of randomly generate


errors and put them in Search Console.


If we're seeing crawl errors, then that's


pretty straightforward.


And that's something that we can report on.


It's not something that we have kind of like algorithms


that try to guess when crawl errors might take place.


But rather, these are pretty direct errors


that come from our systems.


So I would assume that the errors that you're


seeing in Search Console with regards to crawling,


in particular, are actual errors that we saw while we tried


to crawl your website.


The other thing that I have sometimes seen


is that a lot of websites have multiple layers


before a request actually reaches the server itself.


And that could be something like, I don't know,


security protections that you have along the way.


It could be content delivery networks that you have set up.


All of these things can also return errors.


And it can certainly happen that a request comes in


from Google Bot side and is blocked by some security layer


outside of your normal web server.


And perhaps that layer either fails and returns a 500 error


or blocks us completely so that the request times out.


And that might be something that you would not particularly


see logged on your server.


So that's something where it might make sense


to double check with your hosting provider


to make sure that you're getting the full picture


and that nothing is being blocked or breaking there.


Finally, the last thing, I think,


is that 500 errors are things that you really


want to take care of.


500 errors are server errors, which


means that something along the way is breaking.


So it's not like a 404 error where the URL just


acts like it doesn't exist and we try again.


A 500 error is really something that we


tend to take seriously in the sense


that we sometimes assume that maybe it's our fault,


like something is breaking.


So whoops.


Something weird.


OK.


So what else happened to be presenting?


Like I said, 500 error is really something that,


let me just do Q. Whoops.


Oh, man.


Too many buttons on this laptop.


500 errors.


Back to 500 errors.


So we assume that these are actual things


that are causing problems.


So what will happen is we will crawl less frequently.


So that's kind of why fixing and finding the source of 500 errors


makes a lot of sense.


So usually it's a sign that something is really breaking.


And usually the results will be that Google


crawls a lot less frequently.


So it's really worthwhile to get to the bottom of those.


We're using the latest version of the Yoast SEO plugin


for our blog, which in theory should


take care of implementing structured data automatically


for all of our articles.


Do you think that's enough, or should we


implement structured data on each article


if we want them to show up for featured snippets?


So featured snippets don't need any structured data.


So that's kind of the first thing there.


So you're probably already on the good side there.


With regards to the structured data,


I wouldn't just blindly focus on one plugin


and say I installed a plugin.


It should be OK.


But rather, I'd use the testing tools


to make sure that the type of markup, the type of structured


data markup that you're using matches


what you would like to have picked up from these pages.


So using things like the rich results test in Search Console


or double checking the aggregate reports in Search Console,


that's generally the direction I would head there.


The Yoast plugin does a lot of things really, really well.


So I think that's definitely a good thing to have there.


But it's not like this one thing that you install


and it fixes everything.


You still should kind of double check


to make sure that things are working


the way that you want it.


And it's not so much that maybe the plugin doesn't do it,


but maybe there are options that you can activate or disable.


So just double check to make sure


that things are working the way that you want it,


rather than just blindly saying, well, I have this installed.


This will fix everything.


Will Google ever offer a CDN solution of its own?


So we do have a CDN.


It's the AMP cache, essentially.


So for AMP pages, that's something


where we cache these pages on our side.


We serve them directly from the CDN to users in the search


results.


They're even preloaded, depending on how that's set up.


So that's something we kind of have there.


If you want something fancier or something separate from AMP,


I don't know if they're potentially


offerings on Google Cloud, or maybe you


can set up your own CDN like that.


But there are also lots of third-party CDNs


out there that are really, really well made.


So I wouldn't just say, if I want to install a CDN,


I have to use Google CDN.


There are some really, really good solutions out there


that can provide a lot of functionality for you as well.


And some of these are not crazy expensive.


So it's worth looking around.


OK, wow.


And a complicated long one.


Let's see if we can get through this.


Due to a copyright issue in Europe,


the company I work for has almost the same English


language website on two different domains,


with the exception of some branding differences.


Basically the same website on two domains.


There is one domain for Europe and one


for the rest of the world.


We differentiate the two from here on by calling one


the EU domain, the other the ROTW domain.


The issue, in addition to concerns over duplicate content,


is that it seems that Google may be confused


as to which is the proper site to show in the search results,


depending on the location of the searcher.


This gets more complicated, as Europe has many languages.


And thus, we have many different language versions


of the EU domain.


However, we obviously do not cover every single language


in Europe.


Thus, we want the English version of the EU domain


to be sort of default for European users


that do not fit in with other various language


versions of the website.


How do we tell Google that the default site for Europe


is the English language EU domain,


but the default domain for the rest of the world


is the other one?


I thought about using a region language, hreflang tags,


and using the other as the x default.


But this would be an issue for two reasons.


One would be that we'd have about 5 billion hreflang


tags on each page.


That seems a little bit exaggerated, but OK.


We'd have to have an English language


tag for each region in Europe, in addition to hreflang tags


for each non-English versions of the site.


The second would be to do with the copyright issue


I mentioned in the beginning.


We cannot send European users to the rest of the world domain.


Hopefully, there is a more elegant solution.


So unfortunately, I don't see an elegant solution here.


I think this is something you'd probably


need to set up with hreflang.


And you'd probably need to go into that with the assumption


that the hreflang markup on its own won't fix this completely.


So the hreflang setup, I think you kind of roughly


understood how that works.


So basically, you'd have to have for every country


the English version kind of marked up within hreflang.


And you'd have an x default version, which would


cover the rest of the world.


So that's something that you can set up there.


And that helps us to understand the connection


between all of these variations.


Obviously, that can get fairly complicated.


So what I would recommend doing here is, first of all,


making sure that you're really implementing it


on the pages that matter, where you're actually


seeing problems.


It might be, for example, that this is just something


that you need to do on your home page


and maybe on a handful of other pages within your website


and not on thousands of individual product pages.


So if you can reduce the scope by focusing


on pages where it really matters,


that sometimes makes it from this crazy impossible thing


to implement to something that's more reasonably possible.


The other thing is kind of how I mentioned


it's not guaranteed that hreflang will fix this,


especially with a really complicated hreflang setup.


It's easy to introduce mistakes.


And it's easy for things just not


to be crawled in time for us to pick them up properly.


So that's something where it can still


happen that we show the wrong country


version in the search results.


And you need to have an elegant way of handling that


on your side.


So the solution that we usually recommend


is using a banner on top of the pages


when you can recognize that a user is looking


at the wrong version of the page.


That means that users who are kind of purposely looking


at the wrong version of the page,


they can still look at that page, which


makes a lot of sense because users might be in one region,


but actually they're based in a different region.


And maybe they'd like to see this page in French,


even though they're based in maybe the UK at the moment.


All of these things, that's something


where a banner makes it possible for users


to continue to use the page, but they're still guided


to the right version.


And the additional effect of a banner


is that when it comes to crawling and indexing,


we can crawl and index those different variations.


We're not forced into the US path within your website.


So in your setup here, if you're redirecting European users


to the European website and everyone else to the everyone


else website, then a user from the US


would be redirected to the everyone else website.


That means Googlebot, when we crawl and index your website,


we would never be able to see your European website.


So we would never recognize that, oh, you


have content in French, and you have content in Italian.


We'd never even get there because you'd always


redirect us to the rest of the world English website.


So those are the two aspects there.


On the one hand, I'd definitely look at hreflang,


and I'd focus on the pages where it's most critical.


And I'd also find a clean solution


for cases where people still get to the wrong version.


All right, next question.


Can you name the top 50 ranking factors?


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


So maybe we can just shift to more live questions


from any of you.


I imagine that's more insightful.


Hi, John.


I have a question regarding updating old content.


So what would be the best thing to do


when you have an old content and you're


trying to update it to something very broader


than the original content?


And would it be wise for me to delete the old content


because it was very narrow, and now I'm


trying to make it a lot wider?


So my question would be, is it wise to update the old content


or delete it and make a new article so that you know?


Because personally, what I've seen or experienced


with Google is that it is always advantageous for me


to have new content published rather than updating it.


Because it takes time for the old content to rank or whatever


the objective that I have.


Oh, my gosh.


So what I would do in a case like that,


if the new content kind of matches the old content,


it's like the same topic, and you're just


creating a much better article there,


then I would rewrite the old content.


I would keep the old URLs and kind of expand on them.


The advantage of that is you keep


all of the signals that are associated with that page


so far.


And that could be things like people


who are linking to that article or even just


your internal navigation, where we already


understand this page is kind of about this topic,


and we have some anchor text associated with that page.


So if you're just expanding it, I


would definitely keep the same URL.


If you're writing something completely different,


then I would just use a different URL.


SPEAKER 2 OK.


And just one more question.


What are your views on activated mobile pages?


Because across the web, even communities where we go,


I don't see a lot of people endorsing it.


And I totally had to have people then go hide it to get it to.


SPEAKER 3 OK.


Sorry.


Go ahead.


So accelerated mobile pages.


I think accelerated mobile pages are a great way


to really make fast mobile sites.


So from that point of view, I don't have anything


kind of against them.


I think, depending on the type of site that you have,


sometimes it takes a lot of work to make a really fast


mobile site.


And AMP is a nice framework that makes


it easy to create new pages that are mobile friendly and really


fast.


But there are also other ways to create


fast mobile-friendly pages.


So depending on the setup that you have,


maybe using AMP is a great way to get started


and to make these pages.


Maybe there are other ways that work just as well.


For a lot of the more common CMSs,


I've seen plugins that just enable AMP by default.


And sometimes that's a really quick way


to make your website significantly faster.


So that's something that's worth looking at to see if that's


an option for your website.


SPEAKER 2


Why would my insights in analytics show me,


I'm going to paste an image into the chat,


show me an insight that tells me my revenue is up in dollars


when it's a UK site in pounds?


I have no idea.


You probably need to ask someone from the analytics side


or maybe check with Daniel Weisberg on my team.


I think he's also on Twitter, so I would just ping him.


Because it's pulling the right property,


they're linked correctly within Webmaster Tools and Analytics.


And the image, it's got the income on the left in pounds


and on the right in.


Oh, wow.


I don't know.


Maybe it's like a separate bank account


that you don't know about.


Daniel can tell me where the money is?


All right.


OK.


Yeah.


And for Webmaster Tools, we're setting up a new site.


This new site we're launching, it


will have lots of different currencies.


Are we best off setting up sub-properties or not


sub-domains, sub-folders in Webmaster Tools for each


country?


Webmaster Tools for each country.


Usually, that's a good idea.


If you really have country-specific content


to separate it out in a clearly visible way,


so that could be sub-domains, it could be sub-directories.


Sub-folders, yeah, sub-directories.


So the one thing I wouldn't do is


to use URL parameters for countries,


because that's something that's really hard for us


to figure out.


URL parameters work great for different languages,


because we look at the languages on a per-page basis.


But for countries, we try to figure out


this block of the website.


When you say URL parameters, do you mean just a pending?


Yeah.


Like if you have an actual URL.


Yeah, if you have like question mark country equals Germany.


That's a lot harder for us to figure out.


OK.


Cool.


Let's take a break here.


I have a bit more time, so if any of you


want to stick around and chat off the record, we can do that.


I think we got through a bunch of the questions.


There's still a lot more.


So if there's something critical that I didn't get to,


feel free to just copy it in to the next hour Hangouts,


and we can look at it there.


Basically, John, I have a small question.


Sure.


Feel free to stick around.


I'll just pause the recording.


And we can continue.


It's good to kind of like pause the recording at some point


so that we don't have an infinite long thing.


OK.


All right.


My question is that nowadays I am facing lots of problem


in my Google Analytics.


That the actual that my Google Analytics account is not


providing me exact data.


Like there is a real time of more than 500 on my website.


But when I check the total number of visitors,


when I check the total number of visitors,


they only provide info of like 10,000 people per day.


They only provide info of like 10,000 people per day


or 8,000 people per day.


According to Google Analytics, if we have a real time of 400


to 500, then there must be the traffic of 30,000 plus


in a day.


So on the one hand, I don't know about Google Analytics.


You'd need to check in with the Google Analytics folks on that.


So maybe in their help center or help forum.


The other thing that is something


that I know we have in Search Console as well


and in some of the other tools is that the live data is often


unfiltered in that it includes all kinds of traffic


and things that tend not to be real users.


So it can happen that the live numbers are much higher


than what is actually recorded because the live numbers


include things like fake traffic and bots and things like that.


So that might be a difference that you're seeing there.


But I would really check in with the analytics team directly.


SPEAKER 2


John, where can I get the solution for this problem?


I would go to the Analytics help forum.


There's a special forum for most of our products.


I can pull it out and drop it in the chat here in a minute.


Please do this.


Sure.


All right.


So let's take a break here.


Thank you all for joining in.


It's been great to have you all here.


And if you want to stick around for a bit,


feel free to do that.


I'll set up the next batch of Hangouts soon.


And until then, I wish you all a great weekend and a great week.


SPEAKER 3


How technical Search content is written and published at Google and more! | Search Off the Record

Welcome, everyone, to the next episode of the Search Off


the Record podcast.


Our plan is to talk a bit about what's


happening at Google Search, how things work behind the scenes,


and who knows, maybe have some fun along the way.


My name is John Mueller.


I am a search advocate on the Search Relations team


here at Google in Switzerland.


And I'm joined here by Martin and Gary, who are also


on the Search Relations team.


But that's not all.


We have Lizzie joining us here today.


Weee, Lizzie.


Do you want to introduce yourself briefly?


Sure.


My name's Lizzie, and I'm also on the team.


And I work with John, Gary, and Martin.


I'm a technical writer, which means


that I help people write stuff down.


And I work on the search documentation.


So what does a workday look like when you're not


writing technical documentation?


Writing a lot of emails and responding


to emails and meetings.


Meetings.


Like a normal person.


Well, I try to avoid meetings as much as I can.


But I think I also saw you at events, right?


We were at the PE Summit together a couple of years


back, for instance.


And you were at the Webmaster Conference in Zurich last year.


So that's happening as well, right?


Yeah, sometimes I go to those.


And not just go to them, because I remember


that you also led a session at the Virtual Webmaster


Unconference.


Yes.


Well, I was there.


Lead the session.


I mean, you were a facilitator, weren't you?


Yes, I was there, and I facilitated the session.


Yeah, that's true.


That's cool.


Will you make an appearance in our Virtual Webmaster


Conference that's coming up?


Maybe.


When will that happen?


What's that?


Well, OK, so here comes the confession.


I know that I said it's going to happen in December,


but it's not happening in December anymore.


We are probably doing it in January or February next year.


So yeah, that's the thing.


But you would love it.


Really?


Yeah, I know.


It takes longer.


But it takes longer because we want


to run it across multiple time zones,


and we want to have community speakers as well.


So it'll be a little larger, but really, really cool.


And I might need your help.


What are you going to do at the conference, Martin?


Is it like the same thing as the Unconference again?


Or tell me more.


OK, so it's not the same as the Unconference.


The Unconference is a different format, which was pretty cool.


And Lizzie can probably testify to it


being very different from normal events, right?


It felt different.


Yeah, it was different.


But it was nice.


It was a nice change because we haven't been to an event,


or I haven't been to an event since this whole thing started,


I guess, since January.


Or when was our last event?


In person?


Yeah, I think it's just January, the last one.


I think I was at a conference in February.


Yeah, I was nervous about it.


I didn't think, I wasn't sure how a virtual event would go.


But it ended up being completely different from what I thought


and a lot less stressful because it wasn't like a presentation


you had to prep, which is a big reason why


I don't like leading a session.


But you did.


And I hear that the session was great.


And did you get the feedback that you needed?


Yeah, yeah.


I thought it was pretty helpful.


And I wish that it was longer and more.


OK, so the good news is that we will do virtual Unconference


events next year as well.


But this one is not an Unconference.


This one is actually one where you


have sessions where people are preparing presentations


and giving presentations.


But we also want to have live Q&A.


And we want to encourage people to have also


some sort of interactive session.


We'll have to see how these interactive sessions would


look like.


But it's basically like a larger event.


I want to get Googlers from multiple time zones in as well.


It's probably stretching across two or three days.


And yeah, it's open for everyone.


The virtual Webmaster Unconference


was limited in the number of people who could attend,


because we needed to make sure that the discussions didn't go


too big and were unproductive.


But this time, everyone can join.


And it's a virtual event.


And if I can, I would like to see a session from maybe John.


Or if you want to MC, that's also an option, just saying.


And maybe Lizzie has something that she wants to contribute.


And I know that I want Gary to do his life of a query.


If possible.


GARY ILLYES-CHAPMAN-MARTINI No.


Is this like the public pressuring place?


MARTIN SPLITT I'm trying to basically get


a public commitment from you all.


But Gary put a stop to it.


LIZZIE HEMNON-KLEINMAN-MARTIN Hey, this is off the record, right?


You can't get us to commit on the record.


MARTIN SPLITT Damn it, you got me there.


Oh, god.


GARY ILLYES-CHAPMAN-MARTINI This was great.


MARTIN SPLITT That was well done.


Well done.


GARY ILLYES-CHAPMAN-MARTINI We should promote Lizzie.


MARTIN SPLITT Definitely.


GARY ILLYES-CHAPMAN-MARTINI This was fantastic.


Public relations work, A plus.


MARTIN SPLITT You got him.


GARY ILLYES-CHAPMAN-MARTINI Next level stuff.


MARTIN SPLITT Oh, this was amazing.


GARY ILLYES-CHAPMAN-MARTINI So, Gary, why can't I have a life of a query


session from you?


MARTIN SPLITT Man, I really wish I could do it, but I really don't want to.


LIZZIE HEMNON-KLEINMAN-MARTINI Wait, that's all you have to say?


You can just say, I really don't want to and we'll leave you be?


GARY ILLYES-CHAPMAN-MARTINI Don't teach her that.


Why are you teaching her that?


No.


No, Lizzie, I will never step down just because someone tells me that they...


MARTIN SPLITT Oh, come on.


GARY ILLYES-CHAPMAN-MARTINI Okay, I love this episode already because


it appears that I can team up with Lizzie against you.


And this is just amazing.


MARTIN SPLITT This is the worst day of my life.


What is happening?


GARY ILLYES-CHAPMAN-MARTINI Finally, I'm not alone.


We are two against the one unicorn.


And this is amazing.


MARTIN SPLITT Don't help.


GARY ILLYES-CHAPMAN-MARTINI So, Gary, why don't you tell us a bit about


life of a query before the conference?


MARTIN SPLITT Yeah, basically do it now.


And then you don't have to record it again.


Come on, do it.


GARY That's because the life of query class, that's


two hours long, and we don't have two hours.


MARTIN SPLITT Then, okay, so we had a bit of crawling.


What's next?


What's up next in the queue, basically?


GARY Right.


So we were talking about indexing, actually, not crawling.


Somehow...


MARTIN SPLITT Right, true.


No, we had crawling and indexing.


We had both, right?


GARY I think we silently skipped over crawling,


which is really weird.


But we can cover that at one point where perhaps there's something to announce around Google


bot, or something interesting happens with Google bot.


And then we can cover how Google bot actually works.


So I don't think that we lost all that much.


But we were talking about indexing and rendering.


And we covered quite a bit about indexing, namely, we talked about content conversion,


we talked about collapsing, basically error page detection.


You talked about rendering a little bit.


We collected signals.


And now we ended up with the next step, which is actually canonicalization and dupe detection.


MARTIN SPLITT Wow, that's a big word.


Isn't that the same?


Dupe detection and canonicalization, kind of?


GARY Well, it's not, right?


Because first you have to detect the dupes, basically cluster them together, saying that


all of these pages are dupes of each other.


And then you have to basically find a leader page for all of them.


And that is canonicalization.


So you have deduplication, which is the whole term.


But within that, you have cluster building, like dupe cluster building, and canonicalization.


MARTIN SPLITT Right, got it.


GARY So for duped detection, what we do is, well,


we try to detect dupes.


And how we do that is perhaps how most people at other search engines do it, which is basically


reducing the content into a hash or checksum and then comparing the checksums.


And that's because it's much easier to do that than comparing perhaps 3,000 words, which


is the minimum to rank well in any search engine.


MARTIN SPLITT Wait, wait, 3,000?


GARY What?


MARTIN SPLITT Oh, I said that.


Um...


MARTIN SPLITT Gary.


We have some documentation in our developers' documentation that's not 3,000 words.


Should we add some fluff?


GARY Is it ranking well?


No.


See?


MARTIN SPLITT It's always ranking well.


Come on.


LIZZIE BOR


We are reducing the content into a checksum and we do that because we don't want to scan


the whole text because it just doesn't make sense, essentially.


It takes more resources and the result would be pretty much the same.


So we calculate multiple kinds of checksums


about the textual content of the page,


and then we compare the checksums.


MARTIN SPLITTMANN


Does that catch near duplicates or only duplicates,


exact duplicates?


GARY ILLYES-SCHMIDT


Good question.


It can catch both.


It can also catch near duplicates.


We have several algorithms that, for example,


try to detect and then remove the boilerplate from the pages.


So for example, we exclude the navigation


from the checksum calculation.


We remove the footer as well, and then


you are left with what we call the centerpiece, which


is the central content of the page.


MARTIN SPLITTMANN Kind of like the meat of the page.


That's where it's at.


Considering you're a vegetarian, yes.


That's the meaty part of the page, yes.


MARTIN SPLITTMANN These meat jokes again.


I feel like that has been the theme of the week from John.


GARY ILLYES-SCHMIDT It is.


Yeah, Sundar sent a memo about this on Monday.


MARTIN SPLITTMANN About meat jokes.


GARY ILLYES-SCHMIDT Yes.


It's the meat jokes week.


And now Lizzie doesn't know if I'm serious or not.


MARTIN SPLITTMANN We're all out of cheese, I guess.


LIZZIE FUCHSEN Yeah, because I'm not checking those emails.


I guess I should go check.


MARTIN SPLITTMANN But he's the boss.


LIZZIE FUCHSEN Well.


MARTIN SPLITTMANN I mean, what could you say, Gary?


You filtered all of those emails, right?


GARY ILLYES-SCHMIDT I do.


I don't even see his emails because I filtered them.


And for context, for those listening and being


very confused about the meat jokes,


this week we had several meetings with the team


or members of the team.


And somehow we always end up with joking about meat,


even though we have several vegetarians on the team.


But going back to our dupe detection,


when we calculated the checksums and we compared the checksums


to each other, then those that are fairly similar,


or at least a little bit similar,


we will put them together in a dupe cluster.


LIZZIE FUCHSEN I have a dumb question.


What is a checksum?


And why do you keep mentioning it?


GARY ILLYES-SCHMIDT So a checksum is basically


a hash of the content.


Basically a fingerprint.


A fingerprint, yes.


That is a better word.


Basically it's a fingerprint of something.


In this case, it's the content of the file.


In case of, for example, zip files, like packages,


it could be, again, the content reduced into a checksum


so you can easily compare two different packages


to each other, essentially.


So from a practical point of view,


it's basically you take all of the letters in the document


and you add them all together.


And you come up with this really long number.


And then you just compare the numbers instead


of comparing the text.


So it's kind of a simple way to have a fingerprint


for the whole document.


And you just compare the numbers.


You don't have to look at the text anymore.


LIZZIE FUCHSEN What if the document changes?


Does it get a new number?


GARY ILLYES-SCHMIDT And the number changes.


Yeah.


And then basically if the number changes,


then the Doop cluster would be, again, different.


Because the contents of the Doop cluster


would be different because you have


a new number in the cluster.


So that would just go into another cluster,


essentially, one that's relevant to that number.


And then once we calculated these checksums


and we have the Doop cluster, then we


have to select one document that we want


to show in the search results.


Why do we do that?


We do that because typically users


don't like it when the same content is repeated


across many search results.


And we do that also because our storage space in the index


is not infinite.


Basically, why would we want to store duplicates in our index


when users don't like it anyway?


So we can basically just reduce the index size.


But calculating which one to be the canonical, which page


to lead the cluster, is actually not that easy.


Because there are scenarios where even for humans,


it would be quite hard to tell which page should be the one


that is in the search results.


So we employ, I think, over 20 signals.


We use over 20 signals to decide which page to pick as canonical


from a Doop cluster.


And most of you can probably guess


what these signals would be.


One is obviously the content.


But it could be also stuff like page rank, for example,


which page has higher page rank.


Because we still use page rank after all these years.


It could be, especially on the same site,


which page is on an HTTPS URL, which page is included


in a site map, or if one page is redirecting


to the other page, then that's a very clear signal


that the other page should become canonical.


The rel canonical attribute, that's also,


is it an attribute tag?


It's not a tag.


It's a tag with a relation canonical.


And then once we compared all these signals


for all page pairs, then we end up with actual canonical.


And then each of these signals that we use


have their own weight.


And we use some machine learning voodoo


to calculate the weights for these signals.


But for example, to give you an idea,


like 301 redirect, or any sort of redirect,


actually, should be much higher weight


when it comes to canonicalization


than whether the page is on an HTTP.


URL or HTTPS.


Why?


Well, because eventually the user


would see the redirect target.


So it doesn't make sense to include the redirect source


in the search results.


So do we get that wrong sometimes?


Why do we need machine learning?


We clearly just write down these weights once,


and then it's perfect, right?


So that's a very good question.


And a few years ago, I worked on canonicalization


because I was trying to introduce


hreflang into the calculation as a signal.


And it was a nightmare to fine tune the weights manually.


Because even if you change the weight by 0.1 number,


I don't think that it has a measure,


then it can throw off some other number.


And then suddenly, pages that, for example, whose URL


is shorter might show up, or more likely to show up,


Which is kind of silly because why would you look at that?


Who cares about the URL length?


So it was an absolute nightmare to find the right weight when


you were introducing, for example, a new signal.


And then you can also see bugs.


I know that, for example, John escalates quite a bit


to index dupes, basically based on what he picks up on Twitter


or the forums or whatever.


And then sometimes he escalates an actual bug


where the dupes team says that, why are you laughing, John?


You shouldn't laugh.


This is about you.


I'm putting you on the spot.


You should appreciate this.


But anyway, so then he escalates a potential bug.


And it's confirmed that it's a bug.


And it's related to a weight.


Let's say that we use, I don't know, the sitemap signal in a 2


or the weight of the sitemap signal is too high.


And then let's say that the dupes team says that, OK, let's


reduce that signal a tiny bit.


But then when they reduce that signal a tiny bit,


then some other signal becomes more powerful.


But you can't actually control which signal because there


are 20 of them.


And then you tweak that other signal that suddenly became


more powerful or heavier.


And then that throws up yet another signal.


And then you tweak that one.


And basically, it's a never-ending game, essentially.


So it's a whack-a-mole.


So if you feed all these signals to a machine learning


algorithm plus all the desired outcomes,


then you can train it to set these weights for you


and then use those weights that were calculated or suggested


by a machine learning algorithm.


JOHN MUELLER-GRANT, Ph.D. Are those weights also


a ranking factor?


You mentioned, is it in a sitemap file?


Would we say, well, if it's in a sitemap file,


it'll rank better?


Or is canonicalization kind of independent of ranking?


GARY ILLYES, Ph.D. So canonicalization is completely


independent of ranking.


But the page that we choose as canonical,


that will end up in the search result pages.


And that will be ranked, but not based on these signals.


Right.


I mean, that was a lot of stuff.


And I wonder if we should just write this up somewhere.


That's probably not a bad idea.


So if we wanted to write that up,


what would we need to do?


It sounds like Gary has all of the inside information.


And he's willing to share it off the record.


What would it take to get it on the record?


Well, since it's Gary, I think he could write it down himself,


maybe.


First draft, yeah.


Yeah.


No.


Because I've seen him write some stuff.


And I think it first draft pretty good.


But to be fair, I find it super hard to write the first draft.


How do you get a draft started?


Because basically, I stare at an empty Google doc,


and to my soul.


Yeah, you and I have had conversations about this.


I know.


The blank page is just like the death of all writing.


And one thing that can really help


is talking about it with someone else,


and then kind of roughly banging out


like a skeleton of what you want to say.


So maybe start with headings, like I


want to talk about this, then this, then this,


and then maybe some notes under each one.


And I guess before even that, maybe deciding


what the point of the doc would be.


So for Gary, for this one that he was just talking about,


would it be something that people will read to then


do something else about it?


Is there any action needed that they need to do?


Or is it explaining a concept so that they can


understand how something works?


So first, kind of deciding what's the main point,


and then that will determine the structure.


OK, so basically, Gary would come up with this idea


that we should document this, and then create a rough draft


and send it to you.


And then you just copy and paste it into the documentation


and hit Publish.


No, I think there's a little bit more back and forth.


Probably we would talk about it first,


and then I would say, Gary, can you please write something down?


And then he would write it down, and then I


would look at it and make comments, probably


in a Google Doc.


And then we would queue it up to go into another review


process for DevSite, because we have to check it


in to our content management system.


And then we would do a final review, stage it,


make sure it looks nice, and then we would publish it.


And depending on what it is, we might


want to promote it a little bit as well, maybe on Twitter


or blog posts, depending on if it's related to a feature


or if it's just explaining a search concept.


OK, cool.


So basically, you'd work on the Docs draft with Gary first,


and then I guess you would turn it into an HTML page?


Or how does that work with the developer documentation?


Yeah, either me or Gary.


But since Gary knows what to do, I think he would do it.


OK.


But yes, he would write in HTML, because that's


how our content management system works.


And then he would basically check it


in any source code file?


Or?


Yes.


Exciting stuff.


And then the publishing part, I guess,


is just clicking a button?


Or is there something fancy?


Just clicking a button.


No, it's not fancy.


You just click a button.


So it used to be a little bit more complicated,


where there was two steps where you had to manually publish.


But the team that maintains the site that we publish on


fixed that so it was automatic.


So all you do is submit to the code base,


and then it pushes it within a second.


So you just click a button, Submit, and then it's live.


So cool.


So basically, you would just publish anything


that we would bring you, and nobody would check it?


No.


That's not true.


That's a little.


I would not just publish anything.


Could we do a guest blog and the developer documentation


and guest blog post?


Well, I don't know how interesting


that would be to people.


But maybe if people want to know about it, then maybe.


I think that that's also a good point.


It's like that's something that I often push back on people who


want to just write something.


Like, what is the point, and why,


and will this help anyone?


Or are you just putting this out there just to put out there?


Because if there's a pile of information and some of it


is not useful, that's not helping anyone.


Oh, OK.


So well, I mean, obviously, it should be useful.


That kind of makes sense.


Yes.


Step one, make sure it's useful or interesting.


OK.


Do you do anything afterwards?


Like, once it's live, is it basically just live forever?


Or do you go back and review that from time to time?


Do you ever get feedback on these things?


How does that tend to work?


Yeah.


So we have a feedback mechanism.


Well, multiple feedback places where you can report things.


So sometimes it's on Twitter, which


we don't like because it's hard to track what's going on.


There's a button in the documentation


where you can click Send Feedback


and then write to us about what is wrong


or what you found confusing.


Mostly it's negative stuff, but you


could write in some positive stuff


if you wanted to if it helped you.


We like to know that.


But mostly it's like typo or like, I don't like this.


And it goes into this queue for us to look at,


and then we will revisit and fix it.


Oh, cool.


It's really helpful if it is specific.


So there's an option where you can select to.


This part of the page is confusing.


So when people give us more context,


then it's easier for us to know how can we improve this.


OK, so it's not like this just giant black box


where people go and they complain


and nobody actually reads it.


It's actually, it goes to people and they try to read it


and figure out what to do.


Yeah, and the people are, me and Gary,


we are looking at everything.


A lot of it is like weird stuff or not very helpful.


Oh, yeah.


I had an idea that maybe we could


have a video where we just read the bad feedback,


like the Twitter.


Bad tweets mean celebrity tweets because some of it


is so aggressive.


Or just like, this is bad.


I don't like it.


And when you get feedback like that, it's like, well,


what should I do differently if it's just bad?


What about it?


I need specifics to improve it.


OK.


So I was thinking about that video and I'm in, actually.


Awesome.


I kind of think as the lead of the team,


we should be careful by doing something like that.


Too much public shaming.


Come on.


I mean, we shouldn't be encouraging people


to leave even worse feedback.


I think getting more actionable feedback is always useful.


But it sometimes feels like, especially


with a big company like Google, if there's a feedback link,


then it's easy to assume, oh, nobody actually reads it.


But it sounds like the feedback that


comes in for the documentation, that's actual people behind it.


So if you want something changed or if you're frustrated


because, I don't know, you're trying to implement something


and it's just not working, then it


sounds like people should just leave more clear feedback.


Yeah.


I completely understand why people don't.


I mean, it's work to write in a long story about why


you had trouble with something.


And it's much easier just to say, bad, one star,


we don't like it.


And if I did get a big pile of that for one document,


then I would look into it more.


I would probably have to speak to some people,


run a survey or something for that doc to find out, OK, well,


more specifically, I'm seeing a lot of one star reviews


for this doc.


Why is it doing so poorly?


What can we do to fix it?


And then more specifics can kind of help that along.


That sounds pretty cool.


OK.


And then also the forum.


Sometimes things like, sorry, I meant to mention that one.


So there's Twitter and the feedback funnel into the docs


and then the forum.


So sometimes people will write in there


and we'll get bugs surfaced from that if something's wrong,


maybe incorrect or out of date or something like that.


And then we'll fix it.


Cool.


What about non-English content?


Is that something where you also process that?


Or does that just go to translators directly?


We also process that.


The feedback tool that we have, it


will translate what they're saying.


A lot of the feedback there is like, oh, you


use this word when you should have used this other word


in this language.


And it will translate that into English, which doesn't really


make any sense because sometimes that auto-translate thing just


makes it sound like the same word.


But that's a signal for us to look into it deeper


to report back like, hey, are we sure


that this is the right word?


And then talk to our localization experts


about what we should do about that.


So cool.


OK.


So I guess if you want to complain


about the documentation on Twitter,


you should go to Gary.


And he will accept your feedback.


But better than that is just to give actionable feedback


in the documentation directly so that.


Wait, what?


No.


I don't know how I feel about this.


Fine.


Then maybe don't complain about it on Twitter to Gary.


Yeah, complain to John.


Why me?


To me?


Yeah.


I'm too nice.


Nobody complains to me.


Right.


Sure.


OK, sometimes.


Sometimes.


OK.


We should move on.


Cool.


I think that helps a lot with the documentation.


So that's something where it sometimes comes across as it


just magically appears and nobody really


knows where it's coming from.


And for the documentation, do you


do all of the search documentation,


or is it just a part?


Just a part.


Yeah, so when you say search documentation,


there's a couple different angles there.


So there's the one that's just for everybody


who's trying to use search.


So web search kind of thing, like how


do I search for a job or a business near me.


That's a different team.


There's also the search console documentation,


which there's a tech writer, Josh, who's


on the search console team who documents stuff


about how to use Search Console.


And then I work on the developers.google.com search


documentation, which is a little bit more technical, I guess.


OK.


Cool.


We should talk a bit about how the process works


with getting new features documented and all of that.


But maybe we can do that in one of the next episodes.


I don't know if we didn't scare you too much with this podcast.


I think maybe we should take a break here.


It has been fun doing this episode,


having more people join in and kind of more viewpoints.


And yeah, I hope you, as a listener,


you found this useful and entertaining


and a bit insightful.


And if you like these, then of course,


let us know on Twitter or wherever


you can give feedback for podcasts in general.


And hopefully, we'll see you again.


Or wait, wait.


I always mess this part up.


We'll hear you.


No, you will hear us again in one of the future episodes.


And of course, to hear us again on a future episode,


don't forget to subscribe.


See you then.


Bye, everyone.


Bye.


Goodbye.


fits


Jetttur r


English Google SEO office-hours from February 4, 2022

All right.


Welcome, everyone, to today's Google Search Central SEO


Office Hours Hangout.


My name is John Mueller.


I'm a search advocate here on the Search Relations


team, Google in Switzerland.


And part of what we do are these Office Hours sessions,


where people can join in and ask their question


around their website in search.


We have a bunch of questions on YouTube,


which we can go through.


But we also have a bunch of people


already raising their hands to jump and ask


the first question.


So maybe we'll just go through some of the live questions


first.


Let's see.


I think, Akash, you're first in the list.


Hi.


Hi, John.


My question is related to a few of the industry,


let's say, stock industry and the mutual fund industries.


So we have titles and my description and header tag.


So we have added the value of the stocks.


Let's say today that stock price could be $20.


Tomorrow it could be $30.


So that title or the value, just the particular number,


it keeps on changing every single day.


So just like you have $20, $30, or could be anything.


So just by changing the titles every single day,


or the header tags, or the meta description,


the values within it, does it have a significant ranking


effect?


Because I've heard you saying that your URL should be clean,


and it should be there for the longer duration


to get the value.


Does the same apply for the titles, metas, and the headers?


Or it could be any other factors.


Yeah, so I guess the question is,


does it make sense to change titles frequently, roughly?


Yeah, but not too much.


It's only the value that keep on just changing


every single day.


So let's say today's Google stock price is like $20.


So this is my title for today.


However, for the next day, it would be like,


today's Google share price is like $25.


So only the number is changing.


However, I look at it as the whole title is changing.


So does it make anything different?


I think that's fine.


I mean, it's something where we wouldn't give it


any special weight if your title tag keeps changing.


But if you want to update your titles regularly,


that's totally up to you.


The difficulty, I suspect, is more that if you change


your titles on a daily basis, we might not recrawl


that page on a daily basis.


So it might be that you change it every day.


But in the search results, the title that we show


is a few days old, just because that's the last version that we


picked up from that page.


But that's more of, I'd say, like a practical effect,


rather than a strategic effect.


So is it like having a date function at the back end


and on the content, like a last modified date


on your particular page?


Does it help Google to index that page much faster,


something like that?


I mean, it helps us to recognize when something has changed.


But it's not necessarily going to happen that we'll say,


oh, we've seen this page change every day.


Therefore, we'll recrawl it every day.


It might be that we recrawl it every day.


It might be that we recrawl it every week or every month.


So it's not that the changes that you make with the titles


would affect how quickly we recrawl.


SPEAKER 2


Actually, I was having a particular domain.


So it's for one of my clients.


So that was a travel domain, the name itself.


But they were into business for travel business,


let's say 10 to 15 years.


And however, they have stopped working


on that particular domain and then


restarted that particular domain for an e-commerce website.


So the domain remains the same.


However, just the business model has been changed from travel


to e-commerce.


So when we started again for adding the Google Search


Console, we got more than lakhs and lakhs


of links in the links section of the Google Search Console.


However, there were some penalties as well,


which were found into it.


And how much time Google usually takes


to understand there's a change of business


for this particular domain.


Earlier, they were in travel.


We have done a lot of PR, a lot of marketing


for all this particular domain.


However, these things can help because it's


been published by so many bloggers, authors,


or news websites.


So this particular thing has been changed.


On our own website also, we did write some content related


to this.


However, my main question is how much time


does Google take to understand that this particular domain was


for x business, but now they have shifted to y business?


I don't think there's any particular time.


So that's something that essentially organically


happens over time.


If you reuse an existing domain and you put something else