Googlebot to get that crawled and later to get ranking.


English Google Webmaster Central office-hours from December 10, 2019

So 410 is very, very, very specific.


MARTIN SPLITT


It wouldn't return itself automatically.


But yeah, it's not that we're marking it as do not ever


do this again, but we're just not automatically


crawling much more.


So you can always bring it back.


It's just more effort with a 410 maybe.


So my opinion is controversial in that I think


it's overrated, the difference.


I think in the past, I mean, theoretically, you're right.


We remove it a little bit faster with a 410.


But I think in practice, it doesn't matter.


Because we crawled pages on such a different schedule over time


that if we have to crawl it twice,


then it's still going to drop out anyway.


It's not like you remove a half of the site


and the half of the site is gone tomorrow,


but it'll be removed over the next half year.


And if you're talking about the next half year,


then if something is removed within two weeks


or within three weeks, it doesn't really


matter that much.


And from that point of view, I think


us kind of focusing on the difference between 410 and 404


is something where it's very easy for folks


to get kind of stuck on or hung up on the specifics,


where theoretically, sure, it's better,


but it's not going to break something.


So I have sometimes seen SEOs go and complain


that talking to developers is like, they use a 404 instead


of a 410.


And it's like, our site is doomed.


They're stupid.


Why don't they understand things?


And in practice, it's easy to spend a lot of time and energy


on this small difference, where in practice, the difference is


maybe, I don't know, a couple of weeks


over the course of a couple of months,


whereas it doesn't really change that much.


But it's bigger for some.


I use it more to sound clever.


Yeah, I think there are a lot of these things around SEOs,


where technically, it's like, sure, that's


the correct way to do it.


But in practice, there's so many other things


that play a role that's doing it technically correct.


If you can't do it with the same amount of work, fine.


Go for it.


But if it's a significant more amount of work involved


in doing it technically the correct way,


and the end result is the same, then you


have to make a choice there and say, well,


I can't personally do it.


I have to hire developers to make it a 410 instead of a 404.


And it's a lot of work.


And a lot of time also that you spend in reviewing their work


and making sure it's a 410 that you


could be spending focusing on other things within a website.


So that's kind of tricky in that sense.


I mean, SEO is to some extent very much


based on all of these small things adding up.


So I understand that too.


OK.


Yeah.


You have a question?


No, thank you.


OK, cool.


We have more questions, or do we have more live questions?


No live questions.


OK, fine.


I have more.


I've got one potentially, if that's OK.


OK, sure.


More JavaScript.


I guess, what's the easiest way to look at a shadow DOM


if you were to review a site and go, OK, where you've got?


I saw your rendering talk on a tech boost.


That was really good.


Thank you.


I just need to know what's the best way


to look at a shadow DOM and compare it


to a dot, your Chrome Cs or something like that.


Do you know what I mean?


See if you can do that.


Is that happening?


Yes.


So there's two ways of doing that,


of inspecting the shadow DOM.


The easiest way is within the developer tools.


If you go inspect, you see the elements.


So basically, shadow DOM is usually


used with web components that have their own HTML tag.


You find these because they have to have a dash in the name.


So normal HTML tags, like header, footer, H1, P,


whatever, they do not have a dash in the name.


But if it's like, I don't know, like,


a name, but if it's like content-accordion or content-carousel,


then that's a very good indicator


that this is actually a web component.


And then you can right-click inspect.


And then within the inspector, you see a hash shadow root.


And you can expand that.


And pretty much whatever is in there


is what the shadow DOM contains, which is also


what you probably see in Chrome.


As in, you see the site, you know what you see there.


If you want to inspect it the way that Googlebot sees,


then you can use any of the testing tools as in, like,


the mobile-friendly test, the live test in search


console, the rich results test.


And on of these, you see the rendered HTML.


Within the rendered HTML, you see what we would be seeing.


So we are flattening whatever is in the shadow DOM.


So if you use techniques that actually copy the content


from light DOM into shadow DOM, you would see that.


But you would also see the shadow DOM content.


But you don't see where the shadow border would be.


OK.


Did that make that was very technical and very hard


to explain without a visual?


But does that make sense?


Yeah, is there some sort of, I guess,


I know it's kind of hard to say.


But if you had to quickly look at a page,


is there a plug-in you might recommend


to help break that down easier to see the comparison?


Or do you recommend there's nothing


that you can't do like that?


So what's exactly the goal you're


trying to accomplish with this?


Just to simulate the web rendering view of the page,


so we have got the shadow DOM.


And the DOM, you want to say, well,


we also need to be mindful of that shadow DOM.


So I'm just saying, is there a way to say it?


Normally, it doesn't matter.


And if you want to see that, again,


use the mobile-friendly test or the rich results test.


Because there you see the rendered DOM,


including what was originally in the shadow DOM.


So if you see content not showing up


in the rendered view, then you can use inspect in Chrome


to see if there might be a shadow DOM involved.


OK, cool.


Thanks.


You're welcome.


Good question.


Thank you.


Cool.


OK.


Now we have more controversial questions.


Oh, no.


If a page is marked as no index, but also


as a canonical to an indexable page,


other than being a mixed and kind of pointless thing,


could there be a risk to the no index


being transferred to the target of the canonical?


That's a Dave question, isn't it?


No.


I mean, no is the answer.


No is the answer, yeah.


No is the answer.


But yes is a Dave question.


That's a Dave question.


Good question, Dave.


How did you know?


It sounded like one.


In the reverse logic, if a page has a canonical link pointing


to a URL, oh, no, it's cutting it off.


Let me refresh the page.


Yeah.


I will find it.


So if there is a canonical link pointing


to a URL that is no index, would that be considered no index 2?


Probably.


We would think that it's kind of like a redirect


to a no index page, and we would drop that page.


Thanks.


Can I just ask as well?


I assume if you've got a 404 page,


it doesn't really matter if there's any canonical


or anything on that because it'd just be ignored.


It just doesn't really see past that 404 header, yeah?


When we see a 404, we ignore the whole content.


Brilliant.


Thank you.


So that's something that I recently


ran into someone who had a staging site get indexed,


and the whole staging site would be returning 404


and actually showing normal content to users.


And if we start to index that staging site instead


of their existing site, then suddenly everything


would disappear.


So yeah.


Does Google consume structured data better


if it's coded in a GraphV separate snippets of code


in JSON-LD?


I don't know what a GraphV is.


I'm not sure about that.


I've never heard that before.


I guess that's a no.


Do we have that person in the Hangout?


Do you want to clarify the question if you're here?


Paul?


Maybe not.


No.


OK.


Fine.


Maybe you can clarify for the next Hangout,


and then we can get to that.


I'd like to know if duplicated pages, alternate page


with proper canonical tag, are marked


excluded in the coverage report.


I don't know offhand.


And at the same time, those pages still appear in the search


results.


Oh, OK.


Like mdot pages or AMP pages, does that mean they're excluded


or are they not excluded?


So what happens here, similar to the hreflang question


in the beginning, is we will index the primary version


of the page.


And we'll use that for indexing, but we will swap out


the URL against the alternate version


when we show it in the search results.


So it would be excluded for indexing,


because we indexed the primary version,


but we would know to swap out the URL as appropriate


in the search results.


So it's confusing when you look at the search results,


but we try to do the right thing by just indexing


the main version.


So yeah, I suspect that looks weird in Search Console.


In mobile usability, if the content is too small to read


but isn't the main content of the page, for example, terms


and conditions, Google Search Console will throw errors.


So will that impact the ranking of the page?


I don't know what threshold we would use there.


So I imagine in Search Console, we


would flag that, because technically, these pages are


not mobile friendly.


So they'd be flagged in a mobile usability report.


And it might be something that we would not show as highly


in the search results, because we


think the pages themselves are actually not mobile friendly.


So that's something where usually I'd


recommend if you have content on a page


that you want to use on a page, then make it readable.


Or just don't put it on a page if you don't want it readable.


OK, I'm just going to continue here until someone stops me.


OK.


Yes.


So I have this group of websites.


They are all hosted on the same server.


I mean, not server, but hosting company.


And from time to time, I get some warnings


of those security warnings saying that my content has


been hacked.


I tried going really, really deep into those,


tried looking at server logs and everything else.


And I even tried using the mobile friendly testing


tool to see exactly what Google was seeing on the page.


But it's still the same.


I copied the source code, diffed them.


And besides some minor changes, like variable names and stuff,


they were all the same.


So I'm thinking that maybe our anti bot protection system


is maybe flagging the Google bot or Google security


system as a bot.


And then it's showing a capture page to it.


So maybe then the content will be really different


to the security program than for the actual Google bot.


But I can't debug that.


Or I don't have anything.


I don't have a source code that Google is seeing.


So I can't tell what's happening there.


What exactly is the message that you're seeing?


MARTIN SPLITTENBERG content injection.


Content injection?


OK.


I don't know.


Have you seen that?


No.


I have some ideas.


MARTIN SPLITTENBERG Have you audited the JavaScripts


that you were using?


Is there potential third party content


that you don't have control over in the page?


There are content like third party


critical stuff kind of like that.


Third party, excuse me.


What was that?


Third party what's that?


Third party, I'm missing the name in English,


advertising platforms.


Ads, OK.


Not actually platforms, just tracking.


Right, OK.


I had that happen to one of my Google News websites.


And basically, it was a plug-in issue that,


is it hosted on WordPress?


Nope.


No, OK.


Most of the time, it's something that, basically, it's


a code that you need to kind of look for and remove it.


I would if I knew.


I mean, I didn't do everything.


I did the source.


I did DOM.


And I didn't look at it.


Have you tried looking at the source


in one of our testing tools?


Yes, mobile-friendly testing tools.


Right, and there's nothing fishy in there either.


So I think what could be happening,


if you're pretty sure that it's really not hacked,


the capture page would not be the issue.


That's kind of just first off.


So even if you were to show a capture page to Google Bot


from time to time, that would not


be flagged as hacked or content injection.


What could be happening is that we're


getting confused by some of the content on your pages.


So for example, if you have, I don't know,


like extreme case, you have an e-commerce site,


and suddenly you have one page with pharmaceuticals on it,


then our systems might think, well, pharmaceuticals


is something that is often used by hackers


to inject into websites.


And this website looks like it's not a pharmaceutical site.


So maybe someone is injecting pharmaceutical content


into these pages.


But it could be the case that you're actually


displaying this content purposely,


that you're saying, well, it's like we have this special offer


in, I don't know, maybe something that isn't even


pharmaceuticals.


I don't know, you have a t-shirt with, I don't know,


Viagra branding or something, something crazy,


where you have those keywords on those pages.


And when we crawl and index a page,


we think, oh, like all of these pharmaceutical keywords


on a t-shirt site, it sounds like it's hacked.


And then that might be something that we would flag.


And usually what happens there is as we reprocess those pages,


we realize, oh, it's fine.


And kind of the warning goes away on its own.


So if you're really sure that there's


nothing hacked on your site, that the JavaScripts are OK,


that nothing is being injected there,


and you have some content that kind of touches upon areas


which are sometimes used by spammers or hackers,


then I would assume that it's going in that direction.


One thing I would do there is maybe bring this up


in the Webmaster Help forums so that people


can escalate those specific examples from your site


to the team.


And we can take a look to see if there's


something we need to handle better algorithmically.


Because sometimes we flag things incorrectly like this.


It can get a bit confusing.


And it just helps us to improve our algorithms


if we have more examples of where we get it wrong.


SPEAKER 2 OK, I'll do that.


Just to clarify, are there any plans


on showing us the actual source code


or what Google is seeing there?


JOHN MUELLER I think we try to do that.


And in some cases, we can do that specifically


for malware, like hacked for malware.


We try to show the snippet of the page where we found that.


But for some kinds of issues where just like this


doesn't feel right kind of thing,


we don't have anything specific to pinpoint.


SPEAKER 2 OK, thank you.


JOHN MUELLER Sure.


Let me just double check some of the next questions.


And we can run through those quickly.


So I'm planning to replace my WordPress site


with a normal HTML PHP site.


So WordPress is PHP.


What should we do so that we don't lose


any rankings and visibility?


There basically is no answer for this.


If you're changing your website, you're changing your website.


And we'll reflect that in search.


That includes things like the back end and the UI,


the internal linking, any of that that can theoretically


affect the crawling and indexing of your site.


It can also be a positive thing.


So you can also improve your site by replacing it.


There's an undesirable site link showing up for the Google


search for Facebook support.


How can we kind of tackle that and get rid of it or fix it?


So site links are algorithmically generated.


There's no manual way to tweak things up and down


and to say, like, I don't want this and I do want that.


So there are essentially two things.


On the one hand, try to see if this is really something


that the majority of people are seeing,


if it's really a problem or not.


Sometimes it's just something that you


see with personalized results because you always go there.


And the other thing is if it's really a big problem


that this page is being shown at all in the search results,


then probably you'd need to noindex that so that the page


really drops out completely because it's essentially


a normal organic search result. Other approaches you can do


are things like changing the title of the page


to make it clear what it should be about.


And then, wow, so many more questions.


But we're like so short on time.


Maybe I can just open up for more questions from you all.


Any of you?


MIHAI APERGHISLAVA-SINHAVIORIYA Hi, guys.


Hi.


So quick one.


Well, I hope so.


So let's assume we have a very big e-commerce website, let's


say 500,000 products, something like that.


Of course, a lot of categories holding those products.


And assuming that most categories,


or assuming every link to a given product


has a tracking parameter added to it.


So for example, they want to see what


position was the product within the category


when it was clicked.


So it has like a p equals a number or something like that.


And all of these product URLs do have a canonical tag


to the product without those parameters attached.


So they're canonicalized correctly.


However, there's nowhere on the website a way for Google


to actually get to those canonical version of URLs


directly, only through the stack map.


What would be the biggest downside of doing that?


And I assume one of that would be the crawl budget,


because we're kind of forcing Googlebot to continuously go


over those URLs, even if they're canonicalizing elsewhere.


Yeah, I think crawling is one thing.


The other thing is maybe we will index the other versions


anyway.


And also canonicalization between that page


is also can be an issue.


So maybe answer for me is to not showing that to the Googlebot


that URL parameter for the product URLs.


It's kind of like cloaking, I guess.


Well, I was thinking of using the hash instead of the code


function.


But can we make using a JavaScript code?


OK.


I mean, one thing you could do is


use hash URLs for those keys.


Maybe that would work.


That could kind of make it so that the key is still passed,


but it would need to be processed in JavaScript.


And from there, you can do something with it.


The other thing, I guess, is the URL parameter handling tool.


You could work with that to just say, ignore these.


The other is kind of like if you leave it to canonicalization


and you're OK with sometimes a decision going the wrong way,


then try it out.


But kind of keep in mind that it could


happen that we canonical to those kind of keyed URLs


instead of your preferred ones.


My solution is, for example, if you have categories,


you know on Google IO previous years,


there was an excellent video about that,


that Googlebot track on URL with anchor.


But if you make that anchor is visible,


but you make a supersede like a div that will work on onClick,


Googlebot won't see that onClick URL and won't crawl them.


Oh, that's fancy.


OK.


Yeah.


Just out of curiosity, if you use the URL parameter tool


to force Google to ignore, well, not ignore,


I mean, I guess we would choose that the content isn't changed


as an option.


Is it the same as like using a hash symbol for parameters?


Is it basically the same thing?


Would it achieve the same effect?


Yeah, pretty similar.


So we would still occasionally look at those URLs


to double check that it's OK.


But probably we would just follow that, yeah.


Since that wouldn't involve any development work,


that would be like the easiest kind of work to do.


Awesome.


Thanks.


Cool.


OK.


So I think we have to get out of this room soon.


So I'd just like to thank all of you, all of you who


came here in person, all of you who joined virtually.


Thank you all for coming.


Thanks for submitting so many questions.


And I hope to see you all again in the future sometimes.


I guess some of you tomorrow.


Yeah.


All right.


Thanks, everyone.


Bye.


English Google SEO office-hours from November 12, 2021

All right, welcome, everyone, to today's Google Search Central


SEO Office Hour Hangouts.


My name is John Mueller.


I'm a search advocate here at Google in Switzerland.


And part of what we do are these Office Hour Hangouts


where people can join in and ask their questions


around their website and web search.


Looks like a bunch of things have already


been submitted on YouTube.


Lots of long questions, too.


So we'll see how far we get there.


But as always, I think it's nice to start off


with some live questions.


I think, Zhi, you were first.


But somehow it dropped down.


ZHANG TAN, MD, PhD I tried again.


I did it again, as you said.


No problem.


Go for it.


OK, so I'm first still.


So I recently built a new Chrome extension.


I'm waiting for it to be indexed.


And hopefully people can find it.


The extension has a landing page on the Chrome Web Store, which


is the page where a user click a button to install


the extension to Chrome.


And on that page, it also has the name and description


of the extension, which was submitted by me.


And I don't otherwise control other parts of that page,


just name and description.


But I think it's good enough for me.


And I don't need anything else.


So that page has an URL.


And it can rank.


Meanwhile, I also created a dedicated website


pointing to it.


Let's say my Chrome extension is called abcd.


Then I also created abcd.com, which


shows very similar content as the store page says.


Abcd is a Chrome extension that can do this and this for you.


If you want to try it out, click this link to install.


And that link, of course, links back to the store page.


And that's all for this entire domain,


just does this one thing.


And I didn't create this domain because I


need to show additional content.


I just created it because I thought


maybe it could rank better.


The goal is to have either one of these two URLs


show up in search.


I don't care which one.


So first of all, I want to ask you, based on the setup,


which one of these two URLs do you think


is going to rank better?


I think it's impossible to say for the long run


because it depends quite a bit on how


it's kind of interconnected with the rest of the web.


And I imagine in the beginning, it


might be easier for your own domain to be visible in search


just because you have a little bit more control over that.


You can define exactly what you want to have presented.


You can submit that to Google to be indexed directly.


In the long run, I don't know.


Is Google going to look at the domain


and think this seems to be only pointing to the store page,


so the store page might be more canonical?


No.


Or is it going to think that the Chrome Web Store is


a more trustworthy domain to begin with?


I don't think there's any kind of automatic bias


in that regard there.


It's a fresh new domain.


It's not going to be described.


I mean, it's a new extension too.


So I don't think we have anything where we're like,


well, if it's hosted in the Chrome extension store,


then it automatically shows up in search.


I think that would be something that we'd explicitly


try to avoid happening.


OK.


Now I have two URLs.


I have an issue with backlinks.


So I may create my own backlinks,


and maybe I want to post it to some places to say that, hey,


I built this new thing and check it out.


And I need to pick one of these two.


And I think if I know which one is going


to do better in the future, I would backlink the winner.


Right now, because I want the winner to win more,


but I don't know.


But one of my thoughts is that I can't


control how other people in the future, maybe my users,


find it useful.


And they create backlinks.


And maybe half of them will link to one.


They'll have a link to the other.


That's splitting my backlink power.


And that's a waste.


Might as well delete one of them and force everybody


to backlink to one.


So I think, first of all, you need


to be careful when you're going and creating links


for your own sites.


I would double-check the Webmaster Guidelines


with regards to which ways would be acceptable


and which ways would not be acceptable.


But I think in the future, it's definitely a situation


where you can't control how other people are linking


to your site.


And they might link to the extension


directly or to your site.


And that's not really something that you


can drive directly.


But you can help to influence that


by choosing what kind of content you put on your website.


Because your website specifically


is something where you have full control over that,


where you could put background information or information


about you as a developer, whatever you want,


extra information there.


And sometimes that extra information


means that this is a better place for people to link to,


because it's like, here is about,


I don't know, almost like the company that


is making this extension.


And obviously, some people will also


link directly to the extension and say, just click here.


But yes, do you think that's because some people will always


link directly to the store, do you


think that's splitting my pressures, backlinks, and that's


I think it does split the value from the links.


But the advantage of having two places that


could be visible in search results,


I think that's quite high.


And also the advantage of having one place


that you fully control, I think that is super important.


And that's something where it's like you control the URLs,


you control the full content that is shown there.


That gives you a lot more flexibility


to evolve over time, where maybe you say, I don't know,


next year you make a Firefox extension that


does the same thing.


Or I don't know, whatever other browsers or other systems that


might be relevant, you can create more things.


And that continues to grow within your website,


whereas the Chrome extension side, well, that


could just be one part out of many in the end.


And if you only focus on that, then suddenly you


have all of these small islands, like the individual extensions


or the individual other things that you work on.


So I think having one clear home that is really fully under


your control, that is super valuable.


AUDIENCE 1 OK.


Another thought is about mobile search.


So I'm thinking maybe because a mobile user cannot install


a Chrome extension on their phone,


Google will automatically hide that store page from search


results on mobile.


I don't know.


I would be surprised if we did that.


But it might be something where if we could recognize


that individual pages like this are completely


irrelevant for mobile.


AUDIENCE 1 Maybe Google has an algorithm


that intentionally hides all results that


is a Chrome extension from mobile,


because it knows that it doesn't work.


No, I don't think so.


I mean, it's easy to test.


Find a popular extension and search for it


and see what happens on mobile.


OK.


All right, thanks very much.


Cool.


All right, Wouter.


WOUTER Hey, hello, John.


Good morning.


I have a small Search Console related question.


So for reference, it's about a commerce website


of 2,000 or 3,000 pages in total.


And next to the product pages, it also


contained a couple of course pages.


Now, when these were developed, they


were wrongly set to no index.


This was fixed a couple of weeks or even a couple of months ago.


But in Search Console, most of these pages,


and we're really talking about only a handful of pages,


like maybe 10 pages, but like 80% of these pages


are still set to no index in Search Console.


And I can see that the Googlebot last crawled it months ago,


back in June.


We fixed it in development, so it's


been fixed for a couple of months.


The no index meta tag is gone.


Everything can be indexed.


They are indexed in other search engines as well,


so there's no technical issues really.


But if we check Search Console, it still says, well,


Googlebot last passed this page in June,


and it still contains a no index tag, which


isn't the case.


So we tried to request the indexing via Search Console.


We tried resubmitting sitemaps, but still we


don't get these pages indexed.


And I don't know if you have any ideas as to what


might cause Googlebot not to listen to the indexing requests


or if there are any known issues in Search Console


with indexing.


I don't think there are any known issues in that regard,


but sometimes we're a little bit conservative with regards


to submitting to indexing requests, which is probably


partially what you're seeing there.


I think there might be two things.


Well, I guess a couple of things.


On the one hand, if we see that a page is no index for a longer


period of time, then we usually slow down with crawling of that.


So I think that's what you're seeing there.


That also means that when the page becomes indexable again,


we'll pick up crawling again.


So it's essentially that one kind of push


that you need to do.


Another thing is that since Search Console reports


on, essentially, the URLs that we know for the website,


it might be that the picture looks worse than it actually


is.


That might be something that you could look at by, for example,


looking in the performance report


and filtering for that section of the website or those URL


patterns to see if that number of high no index


pages in Search Console is basically reporting on pages


that weren't really important.


And the important pages from those sections


are actually indexed.


The other thing that you could do,


I think the sitemap is essentially a good start.


But another thing that you could do


is make it clear with internal linking


that these pages are very important for the website


so that we crawl them a little bit faster.


And that can be a temporary internal linking,


where you say, for, I don't know, a couple of weeks,


we link to individual products from our home page.


And we call it, I don't know, whatever section


you want to call it, special products or whatever.


And essentially, when we find that the internal linking has


significantly changed, then usually we


go off and double check those pages too.


So that could be kind of like a temporary approach


to pushing things into the index again.


With internal linking, it's not that you're


saying these are important pages across the web,


but rather important pages relative to your website.


So if you significantly change the internal linking,


it can happen that other parts of the website that were maybe


kind of just barely indexed, that they drop out at some point.


So that's why I would do that on a temporary level


and kind of say, I want to push these back into the system


so that they get recrawled at the regular rate.


And then I'll change the internal linking back


so that everything is more normal.


SPEAKER 1 OK, that's a good idea.


So for example, a footer link as well,


or adding the pages to the footer


would be adding internal links?


I think that would work too.


I think it's usually better or best


if we can find it on really important pages on the website,


where we know, usually on your home page or something,


where we can tell, OK, this is something,


and you're saying that this is important for you.


Therefore, we'll go double check that page.


SPEAKER 2 OK, and what do you think about rewriting


the URLs for these pages?


So having a new URL, a fresh URL,


and submitting that via sitemap, would that speed up the process


or?


SPEAKER 1 I don't know.


I would guess it might for some, and it might not for others.


So I think overall, I would try to keep the old URLs


unless there's really a severe problem with the old URLs,


and just kind of try to push them through that way.


Changing the URLs is something where


you lose any of the information that was associated


with the old URL.


And it's like the advantage is Google


doesn't know that there was a noindex there,


but on the other hand, Google doesn't know anything


about that page.


So it's kind of hit and miss if it actually changes anything


for your situation.


SPEAKER 2 OK.


OK.


Thanks for the info.


SPEAKER 1 Sure.


All right.


Jerome.


JEROME MOUTONO Hi.


Good morning, John.


Good morning.


SPEAKER 1 Hi.


JEROME MOUTONO So I don't have any problems yet


regarding my question, so I'd just like to verify.


I'm using a WordPress website, and I'm using two plugins.


One is Yoast SEO, which automatically


adds a HREF canonical link to every page.


But I also use a translator called WSL, which


is a translator called WPML, I think.


And that one adds of every page an alternate HREF link.


So my question is now that it doesn't make it logic


that it says for that URL it's canonical,


but it's also an alternate.


Does it conflict somewhere in the crawler?


No, I mean, I don't know exactly what these two plugins do.


So it's kind of just from an overall point of view,


if you have a page that has a rel canonical on it,


you're essentially with a canonical saying


the link that is mentioned there is the preferred URL


that I want.


And if it's the same page, then that's perfect,


because then it kind of gives us confirmation


that this page is the one that you want to have indexed.


And the rel alternates basically mean


there are alternate versions of this page as well.


So with different languages, for example,


if you have one page in English, one page in French,


you would have the rel alternate link between those two language


versions.


And it's not saying that the page where that link is on


is the alternate, but rather it's


like these are two different versions, and one of them


is in English, one of them is in French,


and they can both be canonical.


So having that combination is usually fine.


The one place to watch out a little bit


is that the canonical should not be across languages.


So it shouldn't be that on your French page


you have a canonical set to the English version,


because they're different pages, essentially.


But the French page can be canonical, and the English page


can be canonical, and you have the alternate link


between the two, and that's essentially a good set.


SPEAKER 2 OK, so it can be canonical and alternate


on the same page?


SPEAKER 1 Yes.


SPEAKER 2 OK.


OK, well, thanks for the verification.


SPEAKER 1 Cool.


SPEAKER 2 Thanks.


SPEAKER 1 David.


SPEAKER 3 Hey, John.


Hey, everybody.


I already got back to you last week with that quick


or I asked you this question last week.


It was about no indexing versus canonicalization


for robots.


TXT file blocking it there.


So basically what's happening is we


have a website with an e-commerce store


with a lot of product variations that have thin content


or duplicate content even sometimes.


So in this week, I made a list of all the URLs


we want to keep or we want to have indexed, the best URLs


that we have.


And then I made a list of all the URLs


that we don't want to have indexed.


And the more I worked on it, the more


I asked this question to myself, canonicalization


or no indexing.


And still, it doesn't add up.


I'm not sure what the better of those would be.


Even if it might sound like a simple question,


but it's actually not.


If you're about to no index the whole site,


you better want to check again.


So I really don't see what would be better in that situation.


Yeah.


I don't recall your exact situation.


So it might be tricky.


But I think the general question of should I


use no index or rel canonical for another page


is something where there probably


isn't an absolute answer.


So that's kind of just offhand.


It's like if you're struggling with that,


you're not the only person who is like, oh,


which one should I use?


That also usually means that both of these options


can be OK.


So usually what I would look at there


is what your really strong preference there is.


And if the strong preference is you really


don't want this content to be shown at all in search,


then I would use no index.


If your preference is more I really want everything combined


in one page, and if individual ones show up, like whatever,


but most of them should be combined,


then I would use a rel canonical.


And ultimately, the effect is similar in that, well,


it's likely the page that you're looking at


won't be shown in search.


But with a no index, it's definitely not shown.


And with a rel canonical, it's more likely not shown.


OK.


Thank you.


So just to confirm the links, though,


like if I change one link, no, forget it.


Forget this, though.


That's all right.


Thank you very much.


You answered my question.


Sure.


I mean, you can also do both of them.


And it's something if external links, for example,


are pointing at this page, then having both of them


there kind of helps us to figure out, well,


you don't want this page indexed, but you also


specified another one.


So maybe some of these signals we can just forward along.


Hazel.


Oh, no.


Wrong button.


She dropped out.


Hey, John.


Can you hear me?


Yes.


OK.


So I accidentally hung up my meeting.


Sorry.


So the first question, one of my first question


is that I don't know if you remember,


in our formal meeting, I mentioned


that our crawl rate has dropped to over,


dramatically, over 90%.


And we assume that it's because of our response time.


And now we have done many actions


to improve our response time.


And now the response time in the back end of the GSC


has been restored to the formal level,


around 1,400 milliseconds to 500 milliseconds.


Yeah.


But the crawl request, also the crawl rate


is restoring much more slowly than the response time.


I remember that you said if we fix our response time quickly,


and the crawl rate will be restored in several days,


right?


So yeah.


So right now, the crawl rate didn't


restart like what we expected, so we are wondering why that.


And maybe is that because our response time isn't restored


to maybe lower level or something like that?


So we kind of hope that you can give us some advice on that.


Do you know when the response rate has improved


or how long that has been?


The response time, what?


The response time, several days.


It's restored to like 500 milliseconds several days.


And now we couldn't see any improving.


All the improving is much slower in the GSC.


Yeah.


My guess is probably it just takes longer.


So usually, the system that we have


is very responsive in slowing down


to make sure that we don't cause problems,


but is a little bit slower in ramping back up again.


So I suspect if it's been a few days that you improve that,


then probably I would give it maybe a week or longer


to catch up again.


What you can also do in the Help Center in Search Console,


we have a link to a form where you can request that someone


from the Googlebot team takes a look


at the crawling of your website.


And you can give them information about this,


especially if it's a larger website where


we have a lot of URLs to crawl.


You can tell them, we improved our crawl rate significantly.


You can crawl again with, I don't know, 2 QPS,


or however crawl rate you think is appropriate.


And the Googlebot team sometimes has time


to take action on those and kind of adjust the crawl rate up


manually if they see that there is actually


the demand on Google's side, and they


see that the site has changed in that regard.


So that's sometimes a little bit faster


than the automatic systems, but it's not guaranteed.


I can look for the link later on,


or it should be in the Help Center.


I think it's called report a problem with Googlebot


or report a problem with crawling, something like that.


And it's a form where you specify the IP addresses


of the Googlebot that you're seeing.


And it's usually meant to report issues where


Googlebot is crawling too much.


But you can also report issues where


Googlebot is not catching up with crawling yet.


AUDIENCE 1 That one pass, we have already


submitted the IP address and also the problem


through that Googlebot system.


But we still didn't get any response from that.


Yeah, usually they don't respond.


Usually they review these every now and then,


and then they take action on them.


So my guess is probably you just have


to wait a little bit longer.


OK, thank you.


So as our response time has back to the formal level,


around 500 milliseconds, do you think maybe lower is better?


Or we should also?


I think 500 is pretty good.


That's usually in the range where I suggest for crawling.


And I think if you have a very large website with,


I don't know, millions and millions of URLs,


then having an even faster response time is useful.


But for normally sized or even medium large websites,


I think 500 milliseconds should be OK.


OK, good.


So we are a big e-commerce site with millions


and millions of pages.


Yeah.


OK.


Yeah, and probably faster is better.


Yeah, thank you.


And we also spot that as our crawl request job


and our index page is also dropped.


We don't know why that.


Is this because of the crawling rate dropped?


Or is there any other reasons that affect every indexed


pages?


It shouldn't affect the indexing,


because if we just recrawl pages less frequently,


then we still keep them in the index.


It's not that the pages expire after a certain time.


So that would not be related to the crawl rate,


unless the crawling were issues where we received


a 404 instead of content.


But if it's just slower, then that just


means we crawl less, but we don't remove things


from the index just because we crawl less.


OK, that's weird.


So do you know, do I have to know any reasons that


may cause the indexed pages dropped?


I mean, there are lots of reasons why they could drop.


But it's tricky to say, this is what you should be looking for.


The main thing that I see online with regards to indexed pages


is more a matter of quality, that our systems understand


that the relevance or the quality of the website


has gone down.


And then because of that, they decide to index less.


For larger e-commerce sites, that


feels like something that probably


wouldn't happen like that.


But it's really hard to say.


If you want, you can send me the URL,


and I can double check with the Googlebot team.


At least let me just drop my email address here.


I can't promise that I'll be able to respond directly


to you, but I'm happy to pass it on to the team


to kind of double check.


OK, OK, thank you.


I will send the URL in our chat message.


OK, sounds good.


OK, and one more question is about mobile first indexing.


So we all know the mobile first indexing,


and so we optimize our site accordingly.


As for the configuration, Google Doc


recommends two ways of doing it.


The first is responsive web design,


and second is dynamic serving.


And because the first way is a little difficult for us


to achieve it through our tech environment,


so we use the second way.


But we still see that nowadays there are still


over 200,000 daily crawls towards our mobile domain.


Is this normal thing to see?


OK, so you used to have, I guess, in that case,


an MDOT or mobile separate subdomain?


Yeah, the MDOT, and then we redirect the MDOT


to the main domain, and also we use the dynamic serving there.


Yeah, some amount of crawling like that is normal.


It takes a very long time for our systems


to completely stop crawling a domain,


even after it's redirected.


So I wouldn't see that as an issue.


So it takes a long time, maybe?


Our systems have a very long memory for things like this


sometimes.


And if you move a site from one domain to another,


or if you make this mobile change with a subdomain,


sometimes that takes years for the crawling


to stop completely.


OK, OK, I see.


Thank you.


Thank you so much.


Cool, thanks.


Let me go through some of the submitted questions,


and I'll get back to all of the raised hands, so many raised


hands.


And we can see how far we can make it.


Let's see.


The first one is about a website that


has a regional section that targets Latin America,


and we use personalization to change some elements on a page


to match the country's specifics,


like currency or hero image.


There's one product, email marketing,


that offers different features based on the market.


This is how the vendor has set it up,


and we can't do much about it through personalization.


The page is basically 90% different from what


Googlebot sees.


We're not trying to be shady.


It's just that this one product is different.


The rest are the same.


The site has one subdomain that targets


Latin America and only one URL for this product.


Would this be an issue?


In practice, this shouldn't be an issue.


However, what you need to keep in mind


is that Googlebot or Google can only index what Googlebot sees.


And since Google usually crawls from the US,


that means whatever would be visible to users in the US,


users without cookies, Googlebot crawls without cookies,


whatever content would be visible there


is what we would index and what your website would


be findable for.


So if there is something unique that you're only


adding with personalization and you want your website


to be found for that, then we wouldn't see that.


However, if the content that is usually visible on the page


is all you care about and with personalization


you tweak things and you change things


in ways that are not critical to how


you want to be seen in search, then that's perfectly fine.


Another question about Latin American websites.


We consolidated our Latin markets, Mexico, Argentina,


Colombia, and so on into one market.


We also target Spain with a different folder.


For hreflang, we have selected eses for Spain


and referenced the Latin URLs for every Spanish-speaking


market.


So the same URL for es-mx, et cetera.


Google uses es-419 to target the Latin market,


but this no longer seems to be supported.


Is it OK the way that we did it, referencing one


URL for multiple countries?


It's perfectly fine the way that you have set it up.


In fact, it's the way that we recommend doing it.


So it's fine having one version for one country


and another version for lots of other countries.


Listing to individual countries is a perfect way to do this.


With regards to es-419, I think that's an error in our systems.


So in particular, some of our marketing pages


also use hreflang, and for whatever reason,


sometimes we specify es-419 for, I think,


Latin American, Spanish.


And somehow, because it's in our systems internally,


the hreflang links are set up for that as well.


So basically, those links don't work.


And if you're just copying our markup,


then that's not going to work for you.


And I see this kind of mistake across a lot of websites


where they have some internal country or region coding


that they do for their content, and then they


kind of map that automatically to hreflang as well.


And if these are not valid country and region notification


values there, then essentially, those hreflang


individual links are ignored.


In practice, this means the other hreflang links


continue to work, and it's just this one country


link that doesn't work.


So I wouldn't copy what large sites do unless you're sure


that it's actually correct.


And then I think Hazel's questions we went through.


When you say improve the quality of your website,


is this quality something that is quantifiable?


Or is it simply a term used to determine


how multiple algorithms look at your website?


I don't think it's quantifiable in the sense


that we have kind of like a quality score


like you might have for ads when it comes to web search.


And we do have a lot of questions


about how to use web search, and we


have lots of different algorithms


that try to understand the quality of a website,


so it's not just one number or anything like that.


From time to time, I talk with the search quality team


to see if there's some quality metric that we could show,


for example, in Search Console.


But it's super tricky because we could


create a separate quality metrics


to show in Search Console.


But then that's not the quality metric


that we actually use for search, so it's


kind of almost like misleading.


And if we were to show exactly the quality metric


that we use, then on the one hand,


that opens things up a little bit for abuse,


and on the other hand, it makes it a lot harder for the teams


internally to work on improving this metric.


So that's kind of the tricky balance there.


I don't know, at some point, maybe we'll


still have some measure of quality in Search Console,


though.


Is there any relation or impact upon rankings


for websites who have made normal HTML, CSS,


and JavaScript, and another one with PWA,


just because one of our main competitors


has recently adopted it and we notice a huge jump


in their rankings?


So these are essentially different ways


of making a website, and you can make the website


with lots of different frameworks and formats.


And for the most part, we see these as normal HTML pages.


So if it's a JavaScript-based website,


we will render it and then process it


like a normal HTML page.


If it's HTML already in the beginning, we can do that.


The different frameworks and CMSs behind it,


usually we basically ignore that and just say, well,


here's an HTML page, and we can process it.


So just the fact that one of your competitors


has moved from one framework to another


and has seen an improvement in search,


that framework change, from my point of view,


wouldn't be responsible for that.


But rather, maybe they have a newer website now,


together with that framework change.


Maybe the newer website has different internal linking,


different content internally, is significantly faster


or significantly slower, users really like it,


or they did an, I don't know, marketing campaign together


with the website launch.


All of these things kind of play in there,


and these are all things that are not limited to the framework


that you're using.


Then two questions on PageSpeed Insights.


The lab data in Google Search, Google's speed insight results


are the same as Lighthouse results in my Chrome browser.


Do they use the same formula?


I don't know 100%, but they are done completely differently,


in the sense that if you use PageSpeed Insights, that


is run on a data center somewhere


with essentially emulated devices where


we try to act like a normal computer,


and we have restrictions in place


that make it kind of like a little bit slower,


and normal internet connection, those kind of things.


And in Lighthouse, it basically runs on your computer


with your internet connection.


And I think Lighthouse within Chrome


also has some restrictions that it applies


to make it a little bit look, I don't know,


maybe a little bit slower than your computer might


be able to do, just to make sure that it's comparable.


But essentially, these run in completely different


environments, and that's why you would often


see different numbers there.


If you test with PageSpeed Insights, you see one number.


If you test in Lighthouse in your browser,


you might see different numbers.


If you test with other speed tools that run online,


Also, the field data, the data that we actually


use for search ranking that you see in Search Console,


that can be also completely different numbers,


just because your users might have, on average,


a different kind of device or a different kind of internet


connection.


So even if the formulas are the same,


the whole environment around these systems is very different.


And the second question is, if PageSpeed Insight,


the online tool, is using our computers and network.


No.


Like I mentioned, the online tool


runs online in a data center somewhere.


Lighthouse runs locally on your computer.


The main reason I think we have so many different options here


is that websites have different needs with regards


to understanding how speed works.


And especially with things like Lighthouse


that you can run locally, that means


you can run them in your test environment.


So you can set up a test website internally.


You can make it public if you want.


But essentially, you can test things


before you put them on your live website.


So that's one of the reasons why it's really important that you


can try things out locally.


Someone was arguing that bolding important parts in a paragraph


can boost your SEO.


Does it?


Yeah, I think this is something that comes up every now and then.


I double checked before the session, actually.


And Matt Cutts did a video, I think, in like 2012


or something around that about bolding and strong on pages.


So usually, we do try to understand


what the content is about on a web page.


And we look at different things to try to figure out what


is actually being emphasized here.


And that includes things like headings on a page.


But it also includes things like what is actually bolded


or emphasized within the text on the page.


So to some extent, that does have


a little bit of extra value there in that it's


a clear sign that actually you think


this page or this paragraph is about this topic here.


And usually, that aligns with what


we think the page is about anyway.


So it doesn't change that much.


The other thing is that this is, to a large extent,


relative within the web page.


So if you go off and say, well, I


will just make my whole page bold,


and then Google will think my page is the most important one,


then by making everything bold, essentially nothing


is bold because it's all the same.


Whereas if you take a handful of sentences or words


within your full page where you say,


this is really important for me, and you bold those,


then it's a lot easier for us to say, well,


here's a lot of text.


And this is potentially one of the most important points


of this page.


And we can give that a little bit more value.


And essentially, what that kind of goes into


is everything around semantic HTML,


where you're giving a little bit more meaning to a page


by using the proper markup for the page.


And from our point of view, that's good.


It helps us to understand the page a little bit better.


So if you want to simplify it to one word answer,


does bolding important points on a paragraph help the SEO?


Yes, it does.


It does help us to better understand


that paragraph or that page.


Does Google crawler get confused when


it sees a URL that has been canonicalized


but that URL has an hreflang alternate?


I think we talked about this briefly before.


We have an e-commerce site with over 3,500 products.


And I see that all pages are linked to all other pages


through the menu.


How many menu links to different parts of the page


are treated by or how are menu links treated by search engines?


Because obviously, I don't want to link


from each page on my website to each page on my website.


I don't think we do anything special for menu links.


They're essentially normal links on a page.


So from that point of view, I wouldn't


say you have to do anything unique for the menu itself.


There is, I think, some practical limit


with regards to the number of links on a page


that we can process.


I don't know how high that is at the moment.


I would imagine that's, I don't know,


well over 10,000 links on a page.


So if you're cross-linking 35,000 products on every page,


then I could imagine that maybe you


are kind of like over that limit of the number of links


that we process for a page.


If your website is still being indexed properly,


then we can probably find all of those pages.


But it gets really hard for us to understand


the context of individual pages if you're


saying every one of my 3,500 pages


is related to every one of the other pages


that I have on my website.


So it usually makes more sense to provide


some kind of hierarchical structure on the website


where you're saying, this is my main categories.


These are subcategories.


And from there, link to the individual products


rather than to link between all 35,000 products.


May I say something?


This question came from me, actually.


Sure, sure.


Yeah, so that's kind of, I don't know,


I felt stupid even asking this question.


But it's really like the menu is following us everywhere


throughout the page, obviously.


And I've never asked myself this question, actually.


How is this treated?


Because I use Screaming Frog, and I


see that we have the exact amount of in-links and out-links


on every URL.


So it has to come from the menu, because otherwise we


don't link, obviously, through, like, that wouldn't make sense.


We wouldn't do that.


So really, the menu is there, and it's linking everywhere,


always.


I think it might be something where you could double-check


how the menu is implemented, depending on how it's set up.


And if you're using things like JavaScript


to load content when people navigate the menu,


maybe that's fine.


One thing you can do to check is just


open one of these pages in the browser and use View Source.


And then search for, I don't know, the link tag.


So kind of like the angular bracket and A.


And just see how many references it brings up.


And the total number of links on a page is one thing,


but you should kind of see, is it in the order of,


I don't know, a couple hundred to 1,000,


or is it really 35,000 links on every page?


Because if it really is 35,000 links on every page,


then I think from the page size, from the speed, all of that


will be affected as well.


And that's something where if you change to a structure that


has more kind of this categorization,


you will definitely see an improvement there.


SPEAKER 2 Thank you.


Thank you very much.


SPEAKER 1 Sure.


Let me see.


Maybe we can switch to more live questions,


since we have so many people raising hands.


Dordek.


He's probably mispronouncing your name.


Sorry.


SPEAKER 2 Yeah.


It's George.


SPEAKER 1 George.


OK.


SPEAKER 2 Can you hear me OK?


SPEAKER 1 Yes.


SPEAKER 2 OK.


I was wondering, we noticed a big problem with Google


Discover on our website.


It in two days traffic dropped by some 70%.


And it has been dropped to a certain level,


and it has been stable on that level for some time.


So we're wondering if we did something wrong.


Was it an update or something?


Can you clarify as to what exactly happened,


since it's such a drastic drop?


Now, I don't know specifically with regards to your website.


But I anecdotally get reports from a lot of people


that Discover traffic is very either on or off,


in the sense that there's very little kind of room


in between, in that if our algorithms determine we're not


going to show much content from this website in Discover


at the moment, then basically all of that traffic disappears.


And in any other way, it's the same thing,


where if we do show something from your website in Discover,


then suddenly you have that big rush of traffic again.


What I wanted to clarify, it's been stable for, I don't know,


three, four months.


And then in two days, it drops and then stays on that level.


So could it be a technical error or something like that?


If it's a technical issue, then you


would see that in web search as well.


And you would see crawl issues showing up.


So I don't have full insight into exactly what


all happens in Discover.


But usually the issues that I see people talking about


are, on the one hand, quality issues,


where maybe the quality of the website is not so good,


and with regards to the individual policies


that we have for Discover.


So in particular for Discover, we


have some policies that are different from web search


and recommendations that are a bit different with regards


to, I think, adult content, clickbaity content,


things like that.


That's all mentioned in the Help Center page


And sometimes I suspect, I imagine a lot of websites


have a little bit of a mix of all of these kind of things.


And I suspect sometimes our algorithms just


find a little bit too much.


And then they say, oh, we have to be careful now


with this website.


So without knowing your website and without knowing


the details of what exactly Discover is picking up there,


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


There are a number of SEOs externally


that have looked into Discover a little bit more


and tried to figure out what kind of content performs well


or which content shows up at all in Discover.


And they've written a bunch of blog posts


and done presentations on that.


I would try to search for some of that


and see what other people have found.


Because from our point of view, Discover


is something where we try to show a stream of information


to people.


And because of that, we tend not to have


a lot of detailed information on what exactly you


need to provide there to perform really well.


So sometimes it makes sense to look at what other people have


figured out.


OK, thanks.


Well, I mean, the response time is something


that plays into our ability to figure out how much crawling


a server can take.


And usually, the response time from a practical point of view


limits or kind of plays into how many parallel connections


would be required to crawl.


So if we want to crawl, I don't know,


1,000 URLs from a website, then the response time


to spread that out over a course of a day can be pretty large.


Whereas if we want to crawl a million URLs from a website


and a high response time is there,


then that means we end up with a lot of parallel connections


to the server.


And I think we have some limit there with regards to we don't


want to cause issues on the server.


So that's kind of why the response time is very directly


connected with the crawl rate.


For a news website, it's not so much a matter of is it news


or not, but rather the amount of URLs


that we need to crawl per day.


So that's kind of the angle I would look at there.


It can be that a news website, we crawl 10,000 pages a day,


and those are the important news articles are all covered.


It might be that we have to crawl millions of articles


a day because we always have to refresh the archive or things


like that.


Then obviously, the response time, the crawl rate


looks different.


SPEAKER 1 OK.


And that's it.


Thanks very much.


SPEAKER 2 Sure.


Prem?


SPEAKER 3 Yeah, hi, John.


SPEAKER 2 Hi.


SPEAKER 3 So this guy who PWA questions,


which is the normal tech-ish tech statement, CSS, JS,


and one of our computer is adopting the PWA.


So as you explained into that question,


might be there are the minimized elements of the web pages,


internal linking structure are improved and all.


Those are the factors that could be a cause of the rankings


into the CRP.


But what do my intent behind that question?


Overall, game is shifted toward the UI and UX,


whatever happening to the user front,


whenever the websites are open or the rendering


upon the browser.


So when we are seeing upon the web,


our website is a product website.


And it's a very old website.


You can see the 10 to 15 years ago website.


It's launching to the 2005, 2006.


A lot of the complex tech environment,


the stack structure back and front, a lot of.


So when we are to notice our computer adopted the PWA


from the last three, four months.


And obviously, they have to minimize


the some of their HTML elements of their front pages


and some of the internal linking structure as well.


So just we are wondering, is it possible,


you know, the region to be because obviously,


PWA giving the user the best user experience in compare


of the normal websites, if I'm thinking


into the right direction.


So what could be the possible factor and how we can,


you know, is it fine to move with the PWA


or maintaining our current tech stack?


Thanks for you.


Yeah.


So I think the question is kind of like you


have an older website and your competitor just moved to a PWA


and then like everything is better for them.


Should we also move to a PWA?


Yeah, yeah, yeah.


That's a big decision for the management point of view also.


I don't think there is one absolute answer there.


So I think on the one hand, with a PWA,


if it's a pure JavaScript based website,


then you have some challenges there


that are on top of just the normal website.


And that's everything around JavaScript based websites


and making sure that they render well for search.


That can be a lot of work and that


can cause a lot of problems.


So by default saying going to a PWA


will make your rankings better, I don't think that is the case.


It can improve your rankings if you make a better website,


but you also have a lot of other things


that you need to think about.


So it's something where essentially,


from my point of view, it's more of, well,


is going to a new website going to improve my rankings?


And my guess is if your website is really 10, 15 years old


and has kind of grown organically since then,


probably yes.


Probably yes.


Moving to any kind of a newer framework and a cleaner


website, a faster website, one that works better for users,


probably after 10, 15 years, you will see changes in ranking.


And that doesn't have to be a PWA.


Maybe even going to a PWA adds so much extra work


that it's not worthwhile for you.


Maybe it is worthwhile.


I think one of the advantages of a PWA


is also that you have some almost


like mobile app-related elements that


are kind of available by default, which


could be like installing on the home screen,


maybe some offline functionality.


And depending on your market, maybe that's really valuable.


So that might be something that says,


well, it's extra work to make a JavaScript-based website


work in search, but we don't have to create a separate app.


Or we have all of these extra features as well,


and it's worthwhile from a financial point of view


to do that.


But that's something where almost like the SEO aspect


is secondary.


But especially if you have a large old website that


is 10, 15 years old moving to something new,


I'm almost certain that you will see significant changes just


because it'll be a lot cleaner, it'll be a lot faster,


the structure will be a lot better,


it'll be better for users, it will be easier for search


engines to understand.


All of that kind of every all of the HTML improvements


that have happened since then, they play in your favor.


All right, so what I get in from your explanation,


first point, PWA is not directly relates with the CRP


and somehow the ranking factor.


And second point you are telling, obviously,


your product website need to be updated with the latest


tech-ish tech, which is going to be


helpful for the cleaning of overall structure


and the HTML elements which is in on the front.


Is it fine?


Yeah, I mean, I wouldn't say that all websites have


to be the most modern HTML, but if a website has kind of


lingered on for the past 10 years,


you've kind of missed out on a lot of improvements


that have happened across the web.


Got it.


Thank you.


Thank you very much.


I'm going to my management to get your thoughts on it.


OK, good luck.


Cool.


OK, let me take a break here with the recording


and I'll get back to more of your questions


afterwards as well.


It looks like lots of people still have their hands up.


Wow, so good.


OK, if you're watching this on YouTube,


thanks for sticking around to the end.


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


feel free to watch out for the link.


We post them in the community section on the channel.


SEO lightning round 2 #AskGooglebot

Hi, folks.


SEO lightning round 2 #AskGooglebot

It's good to see you all here again.


SEO lightning round 2 #AskGooglebot

There are some questions which have fairly short indirect


SEO lightning round 2 #AskGooglebot

answers, so I thought I'd go through some of these together.


SEO lightning round 2 #AskGooglebot

Riad asks if blocking CSS files in robots.txt


SEO lightning round 2 #AskGooglebot

causes any issues.


SEO lightning round 2 #AskGooglebot

The short answer is yes, it can cause issues,


SEO lightning round 2 #AskGooglebot

and you should avoid doing that.


SEO lightning round 2 #AskGooglebot

Being able to see a page completely


SEO lightning round 2 #AskGooglebot

helps us to better understand the page


SEO lightning round 2 #AskGooglebot

and confirm that it's mobile-friendly.


SEO lightning round 2 #AskGooglebot

Pratmesh asks if there's a simple guide for sitemaps


SEO lightning round 2 #AskGooglebot

available.


SEO lightning round 2 #AskGooglebot

Unfortunately, there's no common simple solution


SEO lightning round 2 #AskGooglebot

that works across all kinds of websites.


SEO lightning round 2 #AskGooglebot

However, most website setups have simple sitemap solutions


SEO lightning round 2 #AskGooglebot

of their own.


SEO lightning round 2 #AskGooglebot

Check your site's documentation for a sitemap setting


SEO lightning round 2 #AskGooglebot

or for a plugin that creates sitemap files.


SEO lightning round 2 #AskGooglebot

Often, it's just a matter of turning that on,


SEO lightning round 2 #AskGooglebot

and you're all set.


SEO lightning round 2 #AskGooglebot

Misha asks if it's possible to reset the indexing of a website.


SEO lightning round 2 #AskGooglebot

Unfortunately, no, it's not possible to reset indexing.


SEO lightning round 2 #AskGooglebot

However, the good news is that if you've changed your website,


SEO lightning round 2 #AskGooglebot

search engines will automatically


SEO lightning round 2 #AskGooglebot

focus on the new version and drop the old version over time.


SEO lightning round 2 #AskGooglebot

You can help this along by using redirects from any old URLs


SEO lightning round 2 #AskGooglebot

to the new ones.


SEO lightning round 2 #AskGooglebot

Jackal asks if having RSS feeds is problematic for crawling,


SEO lightning round 2 #AskGooglebot

since Googlebot fetches them so often.


SEO lightning round 2 #AskGooglebot

The short answer is no, these are not problematic.


SEO lightning round 2 #AskGooglebot

Google systems balance crawling across a website automatically.


SEO lightning round 2 #AskGooglebot

Sometimes this means crawling some pages more often,


SEO lightning round 2 #AskGooglebot

but this only happens once we've looked at the important ones


SEO lightning round 2 #AskGooglebot

already.


SEO lightning round 2 #AskGooglebot

Whew, that was a lot.


SEO lightning round 2 #AskGooglebot

I hope this helps to clarify some of these questions.


SEO lightning round 2 #AskGooglebot

If you'd like more information, join in


SEO lightning round 2 #AskGooglebot

on the discussions in our help forums


SEO lightning round 2 #AskGooglebot

or add your comments below.


SEO lightning round 2 #AskGooglebot

See you next time.


SEO lightning round 2 #AskGooglebot


Javascript: What SEOs need to know #AskGoogleWebmasters

And welcome to another episode of Ask Google Webmasters.


Today, we pick dinosaur t-shirts.


Yeah, cool.


Dinosaurs.


Because we like dinosaurs.


Yeah, into dinosaurs and scary topics.


Scary topics like JavaScript.


It's not scary.


Come on.


Not scary.


All right.


So in the Ask Google Webmasters series,


webmasters is a series of webmasters


SEOs anyone really can submit questions to us using the hashtag


Ask Google Webmasters.


Yeah, and today's topic is all about JavaScript.


So let's get started.


Root asks us on Twitter, when using the rails asset pipeline


for caching, what status code do we give the old asset?


Googlebot crawls the stale assets,


which we currently have 404.


Do we for 10 them instead or do we keep them alive


for a couple of months?


What do you think?


I don't really know what a rails asset pipeline is.


Martin, can you tell us more?


To be fair, it doesn't really necessarily


matter to the specific question because it's pretty much


the same for every assets that you've got


and that you might update at some point.


The rails asset pipeline, however,


is a way for rails to process and pre-process your assets


as you have them in development for the production-ready sites.


It's basically like an automatic pipeline


of dealing with your assets in your rails application.


But what it boils down to is you have old assets.


You eventually have a new version of your website,


and then you have new assets, like some old JavaScript,


some previous version of your CSS,


some images that you're no longer having on your page,


stuff like that, right?


So how do you deal with that?


Well, you just keep it around for a while


until we recrawl your actual HTML content,


and then we get the new assets afterwards.


But because of caching, we try to make it


so that we can crawl and index your page as quickly as possible,


but that might mean that we're going to keep using outdated URLs.


And if you 404 them, then we're just


going to end up with broken renders in between,


and that's something you probably want to avoid.


All right.


So better to keep them around for a while.


For a while.


And you can use your server logs to figure out


when we stop asking for these assets


and then just fully remove them.


Cool.


Our next question comes from Michael.


Michael is asking, if you're going


to be using the same content as you're


using the same content as you're using the same content,


what would you do if you were using the same content?


So Michael is asking, if in pre-rendering,


can you skip or replace irrelevant content,


like JavaScript generated SVG bar graphs or anything else


that is JavaScript generated, really?


From my point of view, you should include everything


as much as possible so that whenever


Googlebot accesses your pages, it sees the full content.


And really, it's just running your JavaScript on the server


side once whenever the content changes


and then deploying the static assets to everyone.


In this case, no, you do not skip things.


But if you mean dynamic rendering,


where you would basically just give different content


to the users versus crawlers, then even then,


I wouldn't skip it.


Cool.


OK, so include everything.


Our next question comes from Graham.


He asks on Twitter, if your site has a chat function that


rewrites the title tag for notifications to the visitor,


how do you or the app supplier prevent


Google from indexing the JavaScript rewritten


version of the title tag?


You don't, I would say.


No.


So as we are rendering the page, we


are picking up rewritten titles.


So in that case, whoops.


What you could do is you could hide or delay


the chat behind the user interaction,


because Googlebot doesn't interact with things.


So if you have to click on the chat button first,


and then the chat pops up and then changes the title,


I think that would be one way of dealing with this properly.


Michael is asking, or asking again, in pre-rendering,


can I still use JavaScript inside the rendered output?


Is it like JavaScript that generates minor content,


or layout changes, or anything that isn't really


a heavy AJAX request?


Yeah, definitely.


So with pre-rendering, you're basically


generating those pages ahead of time


and serving all of that to users.


And it's perfectly fine to have some JavaScript elements


in there as well.


I think from a user point of view,


that makes sense anyway, because sometimes you


can serve content very quickly if it's pre-rendered,


and you can use JavaScript to add interactive elements.


And that's perfectly fine to make sense.


So you don't have to strip out all of the JavaScript


if you pre-render your pages.


Absolutely.


It's also, if you do pre-rendering and then use


something that is called hydration, that's basically


what you're aiming at.


You have all the content pre-rendered,


and then you use JavaScript to enhance it


into a single page wrap app, for instance.


That is perfectly OK.


It's just about giving the content to the user


as quickly as possible.


So it sounds like JavaScript and SEO are going


to be with us for a while again.


I do think so, yes.


Yeah.


Wow, that sounds pretty cool.


So one of the things I keep hearing from people


is pre-rendering or dynamic rendering.


Is that ever going to go away?


Do I still have to bother with all of that?


Yes, this question comes up a lot.


So fundamentally, it will not necessarily go away entirely,


maybe except for dynamic rendering.


Dynamic rendering is a workaround,


so we hopefully do not have to keep that around


for much longer.


But server-side rendering and pre-rendering


are actually very fundamentally useful concepts,


because they give the users and crawlers the content quicker.


It's HTML, we can parse that as it comes in.


JavaScript needs to be parsed and executed


to generate the content, so we cannot basically stream


the content on the browser side.


And we don't have to.


We have server-side rendering available.


Wow.


Yeah, it sounds like there's still a lot to do.


Maybe we should do separate YouTube videos for that.


What do you think, Martin?


It's a great idea and one we already had.


If you are checking out this channel's playlists,


you'll see that we have a series called JavaScript SEO already.


It has a bunch of episodes that are covering


many different topics already, but we


are working on more episodes.


So I guess subscribe to this channel to stay tuned for more.


Yeah, that sounds awesome.


And feel free to continue submitting your questions


using the hashtag.


Ask Google Webmasters.


All right, thanks for watching, and see you next time.


Bye.


Canonicalization: SEO Mythbusting

I think that a lot of people see canonicalization


Canonicalization: SEO Mythbusting

as topical grouping, which isn't right at all.


Canonicalization: SEO Mythbusting

The pages need to be either identical or near.


Canonicalization: SEO Mythbusting

Near identical, exactly.


Canonicalization: SEO Mythbusting

Yeah, that's what it boils down to.


Canonicalization: SEO Mythbusting

Canonicalization is about duplication management.


Canonicalization: SEO Mythbusting

So basically, you want to remove duplications


Canonicalization: SEO Mythbusting

so that we don't have to crawl things multiple times


Canonicalization: SEO Mythbusting

and we don't have to render and index things multiple times.


Canonicalization: SEO Mythbusting

And we also do not serve them all the time,


Canonicalization: SEO Mythbusting

like the same things basically in three different URLs.


Canonicalization: SEO Mythbusting

That's not good search results, really, right?


Canonicalization: SEO Mythbusting

Hello, everybody, and welcome to another episode of SEO Mythbusting.


Canonicalization: SEO Mythbusting

So I basically, well, I used to be a technical SEO myself.


Canonicalization: SEO Mythbusting

And now I've moved into more of the content production


Canonicalization: SEO Mythbusting

side of things, so writing white papers, articles,


Canonicalization: SEO Mythbusting

to educate the wider dev community,


Canonicalization: SEO Mythbusting

digital marketing community about technical SEO


Canonicalization: SEO Mythbusting

and the impact it has.


Canonicalization: SEO Mythbusting

Awesome.


Canonicalization: SEO Mythbusting

That's really interesting.


Canonicalization: SEO Mythbusting

So you're seeing a bunch of misconceptions and confusions


Canonicalization: SEO Mythbusting

and stuff.


Canonicalization: SEO Mythbusting

And we picked an interesting topic, didn't we?


Canonicalization: SEO Mythbusting

We did.


Canonicalization: SEO Mythbusting

What's the topic that you want to talk about today?


Canonicalization: SEO Mythbusting

It's all about canonicalization.


Canonicalization: SEO Mythbusting

All right, so what are the top myths and misconceptions


Canonicalization: SEO Mythbusting

that the community is dealing with?


Canonicalization: SEO Mythbusting

So I think the first thing is that people


Canonicalization: SEO Mythbusting

think it is a directive.


Canonicalization: SEO Mythbusting

You set a canonical tag.


Canonicalization: SEO Mythbusting

It's going to be accepted.


Canonicalization: SEO Mythbusting

Another one, yeah, exactly.


Canonicalization: SEO Mythbusting

Another one is that they kind of use it like a redirect.


Canonicalization: SEO Mythbusting

So if you have a product page that goes out of stock,


Canonicalization: SEO Mythbusting

you add a canonical back to the category page, which


Canonicalization: SEO Mythbusting

doesn't really work that way because I've heard that.


Canonicalization: SEO Mythbusting

The content needs to ideally be identical, if not very similar.


Canonicalization: SEO Mythbusting

So lots of things like that.


Canonicalization: SEO Mythbusting

Oh, interesting.


Canonicalization: SEO Mythbusting

All right, let's start with the idea


Canonicalization: SEO Mythbusting

that it is a directive because it's not.


Canonicalization: SEO Mythbusting

Nope.


Canonicalization: SEO Mythbusting

It is a signal for us, right?


Canonicalization: SEO Mythbusting

So when we talk about canonicalization,


Canonicalization: SEO Mythbusting

we're talking about detecting content or the same content


Canonicalization: SEO Mythbusting

or very similar content that exists


Canonicalization: SEO Mythbusting

under different addresses and the different URLs, right?


Canonicalization: SEO Mythbusting

So we can do many different things


Canonicalization: SEO Mythbusting

to basically identify these things, right?


Canonicalization: SEO Mythbusting

We can just crawl multiple pages and see, like, oh, this


Canonicalization: SEO Mythbusting

is actually the same content.


Canonicalization: SEO Mythbusting

We can also probably see if the same links


Canonicalization: SEO Mythbusting

and the same kind of context is used.


Canonicalization: SEO Mythbusting

But also, we can use the canonical tag, right?


Canonicalization: SEO Mythbusting

It's a signal.


Canonicalization: SEO Mythbusting

We're using many different signals


Canonicalization: SEO Mythbusting

to figure out if something is the same content or not.


Canonicalization: SEO Mythbusting

And canonicalization with the canonical tag


Canonicalization: SEO Mythbusting

is just one of them.


Canonicalization: SEO Mythbusting

So putting a canonical tag on pages that are not the same,


Canonicalization: SEO Mythbusting

it's not going to work.


Canonicalization: SEO Mythbusting

Putting a canonical tag on each of the pages that


Canonicalization: SEO Mythbusting

are exactly the same is also not going to work.


Canonicalization: SEO Mythbusting

It is a signal.


Canonicalization: SEO Mythbusting

It helps us identify what we want to canonicalize,


Canonicalization: SEO Mythbusting

but it doesn't say, like, you have to use this.


Canonicalization: SEO Mythbusting

That's a big one, I think.


Canonicalization: SEO Mythbusting

And you're right.


Canonicalization: SEO Mythbusting

And you should not use it as a redirection either.


Canonicalization: SEO Mythbusting

It's not a redirect.


Canonicalization: SEO Mythbusting

I think people just want to group link equity wherever


Canonicalization: SEO Mythbusting

they can.


Canonicalization: SEO Mythbusting

And it's maybe a bit of a desperate act


Canonicalization: SEO Mythbusting

to try and keep all of their link equity in one place.


Canonicalization: SEO Mythbusting

It is.


Canonicalization: SEO Mythbusting

Again, like, canonicalization makes sense.


Canonicalization: SEO Mythbusting

If you cross post the same content on different,


Canonicalization: SEO Mythbusting

I don't know, platforms or different channels


Canonicalization: SEO Mythbusting

in slightly different locations for whatever reason


Canonicalization: SEO Mythbusting

you're doing that, that's where canonicalization comes in.


Canonicalization: SEO Mythbusting

But if you are having something that goes out of stock,


Canonicalization: SEO Mythbusting

you should either redirect it to something similar that


Canonicalization: SEO Mythbusting

makes sense for the user at that point,


Canonicalization: SEO Mythbusting

or you can just tell us this is a 404 for the moment


Canonicalization: SEO Mythbusting

and might come back.


Canonicalization: SEO Mythbusting

But do not just think that you can, no, it's


Canonicalization: SEO Mythbusting

not the same as a redirection.


Canonicalization: SEO Mythbusting

Also, you're wasting crawl budget that way.


Canonicalization: SEO Mythbusting

Because we are just not understanding, like, oh,


Canonicalization: SEO Mythbusting

so you're saying this is the same as the other page,


Canonicalization: SEO Mythbusting

but it clearly is not.


Canonicalization: SEO Mythbusting

So we're just going to continue doing this.


Canonicalization: SEO Mythbusting

But if you have two pages that are identical


Canonicalization: SEO Mythbusting

and you're not canonicalizing them the way that it makes


Canonicalization: SEO Mythbusting

sense, then we kind of have to look into both as well.


Canonicalization: SEO Mythbusting

And sometimes you get these flipping canonicals.


Canonicalization: SEO Mythbusting

Yeah.


Canonicalization: SEO Mythbusting

What are the typical problems that you're seeing


Canonicalization: SEO Mythbusting

that people are having besides these misconceptions?


Canonicalization: SEO Mythbusting

Like, what are people doing that you think makes no sense?


Canonicalization: SEO Mythbusting

So I think people are just not quite sure.


Canonicalization: SEO Mythbusting

We've been trying to piece together


Canonicalization: SEO Mythbusting

what these different signals are that play into effect.


Canonicalization: SEO Mythbusting

So you've got redirect, site maps, backlinks,


Canonicalization: SEO Mythbusting

and things like that.


Canonicalization: SEO Mythbusting

I think people are trying to weigh up


Canonicalization: SEO Mythbusting

how many of these signals they should add.


Canonicalization: SEO Mythbusting

Maybe they're kind of doing it like a maths equation.


Canonicalization: SEO Mythbusting

If I do these two things, then this


Canonicalization: SEO Mythbusting

will mean that Google picks my canonical tag that I want.


Canonicalization: SEO Mythbusting

But it would just be interesting.


Canonicalization: SEO Mythbusting

I'm always interested to know more


Canonicalization: SEO Mythbusting

about how the signals are weighted, which ones are


Canonicalization: SEO Mythbusting

more preferential to others.


Canonicalization: SEO Mythbusting

Because sometimes I see that maybe this is just my theory,


Canonicalization: SEO Mythbusting

that maybe Google puts more weighting to signals


Canonicalization: SEO Mythbusting

that are more likely to have been implemented by a human


Canonicalization: SEO Mythbusting

rather than maybe an auto-generated setting.


Canonicalization: SEO Mythbusting

I don't know if that has any.


Canonicalization: SEO Mythbusting

Well, duplication and de-duplication


Canonicalization: SEO Mythbusting

is actually done without much human interaction.


Canonicalization: SEO Mythbusting

So this is all automated signals.


Canonicalization: SEO Mythbusting

But we do content fingerprinting.


Canonicalization: SEO Mythbusting

We look at things like what is the gist of it, really.


Canonicalization: SEO Mythbusting

What's the information here?


Canonicalization: SEO Mythbusting

How does this relate to the site structure?


Canonicalization: SEO Mythbusting

What does it say in the site map?


Canonicalization: SEO Mythbusting

So we're looking at a bunch of different factors,


Canonicalization: SEO Mythbusting

but they are mostly technical factors.


Canonicalization: SEO Mythbusting

And we are basically scoring them on an ongoing basis.


Canonicalization: SEO Mythbusting

So it's not that we're determining it once and then


Canonicalization: SEO Mythbusting

just stick to it.


Canonicalization: SEO Mythbusting

We are always looking at the fresh content


Canonicalization: SEO Mythbusting

that we got from crawl and then have a look at,


Canonicalization: SEO Mythbusting

does this change?


Canonicalization: SEO Mythbusting

If it changed, is it now very close to what it has been


Canonicalization: SEO Mythbusting

before?


Canonicalization: SEO Mythbusting

Now, maybe something that has been a duplication


Canonicalization: SEO Mythbusting

is no longer a duplicate because it has changed its content.


Canonicalization: SEO Mythbusting

So that's absolutely possible.


Canonicalization: SEO Mythbusting

But sometimes, especially when pretty much everything


Canonicalization: SEO Mythbusting

is showing up in the same URL structure


Canonicalization: SEO Mythbusting

and it's maybe different language versions


Canonicalization: SEO Mythbusting

or the same thing, but it is the same content,


Canonicalization: SEO Mythbusting

then we might end up with a scoring that is very similar.


Canonicalization: SEO Mythbusting

So we have both versions.


Canonicalization: SEO Mythbusting

And let's say one is 0.49 and one is 0.51 of what we think


Canonicalization: SEO Mythbusting

is a duplication of the other, then it's really hard


Canonicalization: SEO Mythbusting

to pick which one will be the canonical.


Canonicalization: SEO Mythbusting

And that can change.


Canonicalization: SEO Mythbusting

A change in how we crawl things or how the crawler has


Canonicalization: SEO Mythbusting

fetched data and how it has been fetching the other pages


Canonicalization: SEO Mythbusting

beforehand might influence us to have a tiny little bit


Canonicalization: SEO Mythbusting

of a jump in these two numbers.


Canonicalization: SEO Mythbusting

And then the other one is the canonical.


Canonicalization: SEO Mythbusting

So make sure that you're trying to give us as clear a signal as


Canonicalization: SEO Mythbusting

possible and not confuse the algorithms that


Canonicalization: SEO Mythbusting

are working with figuring out which one is the duplication


Canonicalization: SEO Mythbusting

of which other thing.


Canonicalization: SEO Mythbusting

Because if we are having two equal pieces of content,


Canonicalization: SEO Mythbusting

then how do we know which one we should pick?


Canonicalization: SEO Mythbusting

LARA MARTIN-SQUEAKY-SUNDERSEN-MARTIN-LARABE


Canonicalization: SEO Mythbusting

And you don't want Google to be in that position


Canonicalization: SEO Mythbusting

where they feel like they have to pick for you


Canonicalization: SEO Mythbusting

or Google what feels like it has to pick for you.


Canonicalization: SEO Mythbusting

And it makes everything more complicated on your side


Canonicalization: SEO Mythbusting

as well.


Canonicalization: SEO Mythbusting

Especially if you're using things like Search Console,


Canonicalization: SEO Mythbusting

right?


Canonicalization: SEO Mythbusting

We are gathering data and showing you


Canonicalization: SEO Mythbusting

data based on the canonical.


Canonicalization: SEO Mythbusting

So if it's flapping between two URLs,


Canonicalization: SEO Mythbusting

then that's going to look really weird.


Canonicalization: SEO Mythbusting

So anything else that you would say is unclear about it?


Canonicalization: SEO Mythbusting

Or is there something that makes your life really hard when


Canonicalization: SEO Mythbusting

it comes to canonicalization?


Canonicalization: SEO Mythbusting

I think it's figuring out the certain thresholds you


Canonicalization: SEO Mythbusting

need to get to override Google's decision on what


Canonicalization: SEO Mythbusting

is the preferred URL.


Canonicalization: SEO Mythbusting

Because we can align all of our signals on site.


Canonicalization: SEO Mythbusting

But I saw that John Mueller on the Ask Google Webmaster video


Canonicalization: SEO Mythbusting

about canonicalization, he said that there's two aspects.


Canonicalization: SEO Mythbusting

You've got the on-site signals, but you've also


Canonicalization: SEO Mythbusting

got what Google thinks that the user would most


Canonicalization: SEO Mythbusting

like to have a look at.


Canonicalization: SEO Mythbusting

That is true.


Canonicalization: SEO Mythbusting

Yeah.


Canonicalization: SEO Mythbusting

And that depends on a bunch of different things.


Canonicalization: SEO Mythbusting

So for instance, we might canonicalize one language


Canonicalization: SEO Mythbusting

version over the other.


Canonicalization: SEO Mythbusting

If you are telling us that all of them


Canonicalization: SEO Mythbusting

are canonical at the same time, and they have pretty much


Canonicalization: SEO Mythbusting

the same content, especially if it's


Canonicalization: SEO Mythbusting

in the same language, just for different countries,


Canonicalization: SEO Mythbusting

then we might show the version to the searcher


Canonicalization: SEO Mythbusting

that the searcher is in the country of.


Canonicalization: SEO Mythbusting

So if we have a DE version and an AT version,


Canonicalization: SEO Mythbusting

so the German version and the Austrian version,


Canonicalization: SEO Mythbusting

that are pretty much the same.


Canonicalization: SEO Mythbusting

They use the same currency.


Canonicalization: SEO Mythbusting

They might have even the same price if you're unlucky.


Canonicalization: SEO Mythbusting

We might show different URLs to searchers depending


Canonicalization: SEO Mythbusting

on where they are from.


Canonicalization: SEO Mythbusting

It makes more sense for a customer in Austria


Canonicalization: SEO Mythbusting

to see the Austrian version of the website


Canonicalization: SEO Mythbusting

rather than the German one, even though the German one is


Canonicalization: SEO Mythbusting

the canonical.


Canonicalization: SEO Mythbusting

So that might be a little confusing and misleading.


Canonicalization: SEO Mythbusting

Any other questions from your site?


Canonicalization: SEO Mythbusting

Yes, so there was one question I had in that.


Canonicalization: SEO Mythbusting

So if Google accepts the canonical tag on a page,


Canonicalization: SEO Mythbusting

that it will ignore any unique content on that page.


Canonicalization: SEO Mythbusting

But then that's interesting because surely the pages


Canonicalization: SEO Mythbusting

have to be identical in the first place.


Canonicalization: SEO Mythbusting

This is something I've heard.


Canonicalization: SEO Mythbusting

That if there's any unique content


Canonicalization: SEO Mythbusting

on the canonicalized page, it will be ignored.


Canonicalization: SEO Mythbusting

So how would that work?


Canonicalization: SEO Mythbusting

Would the canonical tag not be accepted then?


Canonicalization: SEO Mythbusting

Because they're slightly different pages.


Canonicalization: SEO Mythbusting

So that depends on how different the unique content is.


Canonicalization: SEO Mythbusting

If you have mostly the same content


Canonicalization: SEO Mythbusting

and then maybe have one sentence that is slightly different,


Canonicalization: SEO Mythbusting

then we might still think that it's pretty much


Canonicalization: SEO Mythbusting

the same thing.


Canonicalization: SEO Mythbusting

And then we would not see the unique content necessarily


Canonicalization: SEO Mythbusting

if we think that it's just a copy of another page that


Canonicalization: SEO Mythbusting

is canonical.


Canonicalization: SEO Mythbusting

If this page has the canonical, then we


Canonicalization: SEO Mythbusting

will probably see the unique content there as well


Canonicalization: SEO Mythbusting

because it's the page that we picked.


Canonicalization: SEO Mythbusting

However, if the content is completely different


Canonicalization: SEO Mythbusting

or different enough for the algorithms


Canonicalization: SEO Mythbusting

to decide that this is not a duplication,


Canonicalization: SEO Mythbusting

then the canonical is pointless.


Canonicalization: SEO Mythbusting

Unless there's another page that happens


Canonicalization: SEO Mythbusting

or another URL that happens to point to the exact same page,


Canonicalization: SEO Mythbusting

then it becomes interesting again


Canonicalization: SEO Mythbusting

because then we have two different pointers


Canonicalization: SEO Mythbusting

to the same thing.


Canonicalization: SEO Mythbusting

And we get that oftentimes that people are linking two pages


Canonicalization: SEO Mythbusting

and accidentally have some URL parameter that basically gets


Canonicalization: SEO Mythbusting

ignored or doesn't actually matter


Canonicalization: SEO Mythbusting

or there's a slightly difference in the way


Canonicalization: SEO Mythbusting

that the URL looks like.


Canonicalization: SEO Mythbusting

Maybe you have a slash DE something something


Canonicalization: SEO Mythbusting

and then a slash DE something something question mark


Canonicalization: SEO Mythbusting

cache equals false or something like that


Canonicalization: SEO Mythbusting

that doesn't really matter.


Canonicalization: SEO Mythbusting

Then we might canonicalize to one of these pages


Canonicalization: SEO Mythbusting

and probably the one that does not have parameters and stuff.


Canonicalization: SEO Mythbusting

But that also is debatable.


Canonicalization: SEO Mythbusting

It might also happen that we've canonicalized something


Canonicalization: SEO Mythbusting

with parameters.


Canonicalization: SEO Mythbusting

But that way, you are again making it harder for us


Canonicalization: SEO Mythbusting

to pick a canonical because if you're not saying,


Canonicalization: SEO Mythbusting

oh, this is specifically the canonical we want,


Canonicalization: SEO Mythbusting

then it's back to guesswork.