And they are just scrolling in front of you.


SEO Starter Guide: What’s all the drama?

For that, it's not appropriate, I think.


Do you think it's about SEO?


Or is this just general best web practices?


It's a marketing thing, right?


It's less about SEO, more about marketing.


But this is the SEO starter guide.


So you want to cut this part?


I don't know.


That's what I'm asking.


Is this related to SEO today?


Or was it back when we wrote it, I guess?


And should we still keep it?


I mean, I guess that's something interesting to think about.


It's sort of related, because it's like you have a website


and you're reading this document.


So there's some other things in here.


For example, that section about custom 404 pages,


like, oh, this is a nice thing that you should do for users


is to have this page and make it a little bit better for them


to navigate around your website.


And is it necessarily something like where


do we draw the line of like, oh, this


is OK to put in because it's directly related to search?


Or this is sort of a related topic


that would be nice to have in, and people are interested in it.


So we keep it.


Doesn't spark joy, Gary.


So where in the serving pipeline do social media posts get used?


Well, they don't.


I mean, we have a Twitter carousel, right?


But otherwise, they don't.


I'm inclined to say that we should


cut this because it's way too much on the marketing side.


If you think about SEO holistically,


it probably has some marketing as well.


But how people advertise their site,


which tweeting about every piece of content kind of is,


that probably shouldn't be covered by the SEO.


You know, there's also another paragraph earlier


in the promoting your website that


says you should mail physical mail


to people about your website.


I did that.


It doesn't work.


Oh.


Wow.


So maybe more things that we can update.


I mean, it also covers the spamming link requests


to social media sites thing, where


I imagine in the early days, we picked up links


from social media sites and used those for page rank


and things like that.


And probably that's where some of this is coming from,


is like, just don't link drop your sites, URLs,


and random social media sites.


And instead, think about it a little bit more.


But I guess nowadays, social media sites


don't have do follow links anyway.


So it doesn't really matter, right?


GARY ILLYES-SELLS


I can imagine a few very select sites


that don't care for these kind of things.


We should be able to tell these sites apart and just


on our side, no follow or mark as no follow all the links that


are coming from those sites.


I would be very surprised if there was any big social media


site out there with do follow links


that we haven't already marked as no follow internally


for ourselves.


A title tag tells both users and search engines


what the topic of a particular page is, especially users,


because they definitely go to your HTML page


and check the title tag.


The title tag should be placed within the head


element of the HTML document.


You should create a unique title for each page on your site.


Or don't.


We are just a voice recording.


Brandon's baseball cards buy baseball cards,


baseball news card prices.


Brandon's baseball cards provides a large selection


of vintage and modern baseball cards for sale.


We also offer daily baseball news and events.


So one of my favorite sections of the SEO starter guide


is actually about titles and meta descriptions,


because they are actually helpful driving people


to your site, very targeted people


if you are smart about them.


Because what you write in the title tag


and in the meta description may actually


show up in the search results as you provide it.


And we've seen this happening on our own sites,


like the Search Central site.


What's our site called?


Google Webmaster Central site search.


No.


And we got lots of recommendations


from our own SEO team about what kind of titles we should use.


And we see them perform live.


Basically, we can see that they are


changing the kind of visitors that we get from searches


for certain queries.


So what kind of recommendations do we get from the SEO team?


Did they just want to add high traffic keywords


into the titles?


Or what were the recommendations?


I mean, that was definitely a part of it.


They did some keyword research to see what words


they should be putting.


And they sent me this spreadsheet


that had the keywords.


And then they're suggested, OK, we


want to write this based off of this.


So it did make sense how they were coming up


with the title and the description.


They also had some interesting style choices,


like capitalize every word.


Whereas in the docs, if I'm writing a title,


our style guide for the documentation


is just a sentence case thing.


So you just capitalize the first word.


Whereas the title that they were suggesting


had every word capitalized, and then a pipe thing,


and then the name of our site.


So extra stuff that I wouldn't necessarily


want for the heading or title of the page.


So that was sort of interesting.


I'm curious, does that make a difference for just people


who click on things in search results


if things are capitalized every letter versus sentence case?


Is that something that looks more official?


Have you noticed that this is a trend?


I went through some of the recommendations


when they came back.


And I know that I was grumping around


about some of the recommendations


because I felt that they are irrelevant.


But then you were very suspicious.


You were like, I don't think this is going to work.


And we shouldn't have this pipe thing.


So the pipe thing, that's actually interesting.


Because I said that we would just


append the site name again.


Whatever we determined for the site,


we would just append it again.


And that happened.


We have right now in the search results


that have double name.


Even though that's super long, we


have the title, and then Google Search Central,


and then Google Search Central again.


Well, you don't see the second part.


Basically, it just starts Google Search Central pipe,


and then goo dot, dot, dot.


Is it Google Developers?


Because that's the site that we're under.


Or is it to Google Search Central?


I could look it up.


I don't want to because it's our own site.


But yeah, it's kind of weird, I think.


So I was grumping around about that as well.


But the capitalization, in my opinion,


didn't make any sense.


I don't think I said anything about that particular thing.


But I definitely thought that it doesn't make any sense.


I just thought it was interesting.


And I was wondering from a user perspective,


maybe there's nothing from a search engine perspective.


But if you're a user and you're scrolling,


does this result look more official because


of the capitalization?


And it's something that I had not thought about.


And it just seemed like an interesting,


oh, we're going to change it.


And we can support that because we can have the title tag


and then different heading for what I want on the site


so we don't have to align there.


But just the idea that from an SEO perspective,


they think that this is more helpful.


And maybe it's a user thing.


GARY I really like our recommendation in the SEO


Starter Guide.


And I think that makes the most sense.


For example, the snippet that we have in the code block


on the guide is basically just saying


Brandon's baseball cards, buy cards, baseball news,


and card prices.


And that, in my mind, makes perfect sense


because it conveys the information that


is going to be on the page.


I do have one question, though, and that's


the name of the site and where it comes from.


Because throughout the guide, we get


to see information about Brandon's baseball cards.


And I have no idea what that is.


I mean, I know what baseball cards are, but not


what the site is.


BRIAN DORSEY-HEARN.


Yeah, this is actually a little controversial or questionable


when we were writing the guide.


So it's called Brandon's baseball cards


because Brandon was the original author of the guide.


And he was trying to think of a topic,


and baseball cards happened to be his childhood obsession.


But at the time, again, I think we're talking 2008,


baseball cards weren't really popular.


It seems like they were well past their peak


in terms of popularity.


And there was some question as, is this really


going to translate well to other regions?


So when I was talking to Brandon recently,


he's like, you know, now there's NFTs and physical sports cards


are trading for record highs.


And so he said that he feels a bit vindicated.


LYNN FONG-JONES.


Still relevant.


BRIAN DORSEY-HEARN.


But does the site actually exist?


The domain is registered, and it redirects


to a pretty good search engine, my favorite search engine.


MARTIN OMANDER.


Pretty good search engine.


Is it Steve?


Oh, you're not talking about Steve, then.


The Steve search engine, yeah.


I think that's pretty cool.


It's also cool, I think, that the site exists,


because otherwise I'm sure random people will be like,


oh, Google is linking to this baseball card site.


I'm going to just reserve that domain name.


I mean, not that people just go off and reserve domain names


for random reasons.


GARY ILLYESISI.


Yeah, it never happened before.


I totally don't do that every month.


BRIAN DORSEY-HEARN.


I have so many random domains that I


bought as a joke for a one-off thing.


And then every time it comes up for expiration,


I'm like, well, what if somebody parks it,


or what if I want to use it, or I


think I linked to this at some point in a blog post,


and should I go back and delete the link,


or no, I can just renew the domain.


And so this is now over a decade later for some


of these domains.


And so it's hundreds of dollars on one-off jokes in this


recurring billing situation I need to get myself out of.


JOHN MUELLER.


Yeah, but when you consider the value of domain age


in Google search, you know.


GARY ILLYESISI.


Why would you do that?


BRIAN DORSEY-HEARN.


I thought it was really fresh content that we want.


Oh, no, the really old content.


Why?


Let's fight it.


Gary, you should do a session on domain age and authority


on ranking.


Or, you know, not.


Music.


Organic or word-of-mouth buzz is what helps build your site's


reputation with both users and Google,


and it rarely comes without quality content.


I was reviewing the guide since you asked me to be on the


podcast, and I was reading through it, and I realized a lot


of this stuff, like writing for users or, you know, don't


deceive search engines, is just really evergreen.


Like, the advice doesn't change.


Especially with writing for users, I was thinking about,


you know, I used to go to in-person events when that was


a thing, and my favorite part was always if we would do an


in-person one-on-one site clinic.


So you're literally sitting at a table, and someone comes up


and you pull up their site on a laptop and take a look at it.


And so many times someone would pull up their site, and I'd


open it, and I'd stare at the homepage for a minute, and I'd


read it, and it would say something like, we provide


innovative solutions and pigmented liquid to enhance the


aesthetics of residential living.


And I'd be like, okay, all right.


And then I would have to look at the site owner and kind of


admit like, so I don't really know what your site is about.


Like, what do you do?


And they would say, oh, I'm a house painter.


And I was, oh, okay, put that on your site.


That's what users will be searching for, and that's what


users will understand.


Now I'm a tech writer at Google, and I realize writing is hard.


Lizzie, I don't know if you've had the same experience, but I


found that if I start with writing, I'll end up writing in


this really complicated language that's hard to understand.


But then if I'm explaining to someone in a meeting what this


tool is about or something like that, all of a sudden it's


super easy to understand, and I just go and I delete my draft


and I write it out in plain English.


No, I totally relate to that.


And I did not know you were a tech writer now until this


moment. I feel like a connection.


A sudden connection.


Yeah, yeah, I am.


I can totally see that happening, too.


And sometimes I do that with engineers, just like, let's


have a meeting and you tell me, explain verbally and we'll


write it down live together.


And it comes out so much better than if they were to try to


like write it down.


And then it's just a jumble of words verbally.


Like you can tell someone to write how you speak, but it's


hard when you're staring at a blank Google Doc and you sort


of have this like other voice when you're writing like that.


And it's hard to break out of that.


Yeah, definitely.


And I think it's also interesting that this is another


one of those recommendations that can also be a little bit


outside of SEO.


And it's kind of something that you should do anyway, even if


search engines don't exist, because I mean, you might have


like the perfect title and meta description and that shows up


in the search results.


But if someone clicks through to it and then they get to your


page and at that point SEO is kind of over, they're on


your page.


But if they don't understand what your site is about, are


they going to really sit there and try to figure it out?


Or are they just going to click back and go on to the next


thing?


You bring up a good point because you said perfect titles


and descriptions and like perfect for who, the search


engine or the user?


Because that was some of our feedback that we had when we


were given the suggestions for what to put in our


documentation for the titles and descriptions.


Some of them were just like a jumble of keywords just like


mashed together.


And OK, if you were to think if you're a user looking at that


in search results, would that make sense?


It's just like a bunch of random words.


So it does seem like there's a balance of like perfect for


who.


Yeah, I'm a big fan of writing for users, not search engines.


I believe that's in our guidelines.


Focus on the user and all else will follow.


I mean, that's also a direction a lot of our new algorithms


are taking as well.


Or I don't know, not really new, but like a lot of the


machine learning stuff that we do in search is all about


understanding what normal text is and understanding what they


actually meant with this piece of text where it's like, well,


the keywords are not exactly in that text, but it's a clear


concept that's explained what this is about.


So that, I think, always still makes sense.


And I still run across sites where I look at it and I can


see, well, probably a very expensive web designer put this


together.


It looks really, really nice, but I have no idea what the


site is actually trying to sell to me.


And then at that point, maybe you show up in search, maybe


you get traffic.


But if nobody clicks through and actually buys anything,


what use is that site?


Yeah, and that's also another reminder, like if you said the


algorithms are moving more in this natural language


direction, there's always this kind of, I don't even want to


say it's a trade off, but if it's, do you want to think like


long-term or short-term?


And so if you're writing for search engines and maybe


focusing on keywords and the title, because that's like the


hot ranking factor of the moment, but then you have to


keep up with it.


If the algorithm changes, that's a lot of work and you have to


constantly be like reading the latest advice and that kind of


thing.


But, you know, as someone who's like stepped away from search


for a few years, I found that if I just look at the basic


principles of creating sites that users would like, that


hasn't changed.


And then you're chasing the same thing that the algorithms


are chasing.


And so it's almost like search engines will eventually catch


up to you if you've done something that's good for users


and you can just focus on your site and not have to worry


about every single new ranking factor or something like that.


I even looked back in the Internet archives version of the


Webmaster Guidelines from 2003.


That was the oldest version that I was able to find.


And it had things like make pages for users, not search


engines, don't deceive your users and the basic principles


that are still there.


There's always technical reasons for technical


accessibility and that kind of thing.


And if you want to focus on the latest and greatest because,


yeah, sometimes the algorithms aren't there yet, but it's kind


of nice that if you want to, you can sort of sit back and


focus on the long term.


You still love search, don't you?


I do.


I use it every day.


Yeah, I mean, it's how I find things.


It's amazing.


But also the way you talk about it, the way you talk about all


the webmaster comms, I think you miss us.


I do actually think about the team a lot.


There are just so many good things about it, like both in


terms of the work that we did and then also the way that we


work together.


And I'm constantly bringing things up.


I've worked on a couple of other teams since search at


Google.


And with writing specifically, I've talked about how nice it


was to have a global team of experts who were also writers


because then we weren't doing just straight translations or


just straight global versions of all of our content.


It was up to the local teams to figure out what's relevant for


their region.


And they would share it with the team.


And if you remember with the mobile friendly update, we


initially had that label in the search results.


And if you just send, I think in English said something like


this site is mobile friendly or something like that.


And if you just send that to a translator who's not on the


search team and doesn't have context, you might get


interesting translations back that aren't quite right.


Either if there's a different industry term or if mobile can


mean like we think about it in terms of mobile phone.


But what if it also means like the ability to move?


I think some of the initial translations came back in that


kind of strange way.


But fortunately, because we're the search team and we work in


so many different languages, we were able to before launch,


have the team review that and they come up with better ideas


that sometimes were not literal translations, but they actually


got the point across a lot better.


And so that's the story that I like to tell the teams that I


work on now when we talk about making something for a global


audience or moving into a different area.


It's a great team.


Also, I heard some rumors about love stories related to SEO


starter guide or something.


Yes.


Oh, there is a love story.


And it's something that I just learned recently again from


Brandon, who wrote the guide.


So it turns out after the guide was published, there was


someone on our team who was traveling to another office and


he sat next to a woman on the plane who he didn't know.


And I guess they started talking and she asked him, where


do you work?


And he said, Google.


And the first thing that she said was, oh, I'm a small


business owner and I just read the SEO starter guide.


It's great.


And they later went on to get married.


What?


Oh, my God.


Read the SEO starter guide.


It might lead to a love connection.


Well, that escalated fast.


Wow.


OK.


That's so topical.


So crazy.


What is the chance of meeting a random person on the plane?


I just read your documentation.


It's about one in seven billion.


I don't know.


Maybe the chances are better now with fewer people flying.


What do you think?


When was your last flight, Gary?


Don't hurt me like that.


And that's it for this episode.


We've been having fun with these podcast episodes.


And I hope you, the listener, have found them both


entertaining and insightful too.


At any rate, let us know how you're liking these


and if there are any topics that we should


be covering in future episodes.


And of course, don't forget to like and subscribe


and read the SEO starter guide.


Thank you.


And until next time, bye.


Bye bye.


Bye.


Google Search News (March ‘22) - Search Console URL Inspection API, ranking changes and more!

Hi, everyone, and welcome back to the Google Search News.


I hope life is treating you reasonably well wherever


you are.


I'm your host today, John Mueller,


here from Google Switzerland.


Today, we have some ranking changes, a new API,


a change in analytics, and more.


So ready or not, here we go.


Starting off, we have two ranking changes.


The first is about the page experience ranking factor.


It includes the Core Web Vitals, which


are based on measurements for speed, responsiveness,


and stability as seen by users.


Previously, this was used only on mobile.


Recently, we launched this for desktop users too.


As an aside, this is independent of mobile-first indexing.


We've seen some fantastic progress on the web


in regards to the Core Web Vitals.


Many sites, perhaps also yours, have improved significantly.


I'm looking forward to seeing even more of that.


Another update is about product reviews.


Last year, we expanded our recommendations


for websites that include product reviews.


We recommended focusing on in-depth, authentic,


and high-quality reviews.


Recently, we announced an update that


works to better recognize these for ranking.


This update is rolling out in English,


and we aim to cover more languages over time.


If you're publishing product reviews,


I'd recommend checking out the blog post and the information


linked from there.


Even if you're not publishing these,


it may still be worthwhile to check it out.


It can give you a better understanding


of the kind of content that Google's users have found


useful, and perhaps there are some parallels


relevant for your website too.


And now over to APIs.


We just recently launched a new API for Search Console.


An API is a way that programmers can reuse functionality


from one system in an app of their own.


In this case, it's for the URL inspection feature.


This API allows programs to check the indexation


status of any particular page on your website.


Among others, it will let you know


if the URL was discovered, crawled, indexed, and if so,


what the selected canonical was.


This is also available to use manually in Search Console.


As an API, it's now possible for other tools


to include this functionality.


Many have already started including it, perhaps even


some that you're using.


Even if you're just using spreadsheets


to track your website, there's a way to integrate it.


And of course, if you like to write code yourself,


we have great documentation for it.


Combine it with other data sources


to make something really fancy.


Check it out, or try one of the many tools


that have implemented it.


And now for something that's not from Search,


but likely relevant to many of you.


Google Analytics recently announced


that they're stopping data collection


for Universal Analytics next year.


This is one of the more common ways


that people track website metrics.


The newer version, Google Analytics 4,


has been available for a few years now.


While there's still a bit of time,


it can make sense to move to the new setup


and to get used to it early.


There's a lot of documentation and a bunch of smart folks


out there who can help you with the process.


Let us know in the comments if you found a particularly


useful site for GA4.


Moving over to a neat milestone in the community.


Recently, Barry Schwartz from Search Engine Roundtable


announced that he had published over 40,000 articles


on the topic of SEO.


Barry stays on top of every change at all major search


engines and frequently asks us for more details


when things aren't so clear.


Barry has been doing this more or less since the start of SEO.


His work has truly made a big difference


in search engines in the world of SEO


and on websites worldwide.


Thank you, Barry.


But wait, there's still more.


We recently started a blog post series


about using Search Console with Data Studio.


Combining these services allows you


to connect multiple sources of data


and to create fancy dashboards.


Our blog has more.


Another recent update is the launch of the index


if embedded robots meta tag.


This allows a page to specify whether its content should


be used for indexing in certain situations.


It covers a somewhat unique situation,


so you probably won't run into it often.


If you're using Search Console Insights,


you may have received congratulatory emails.


Who doesn't like to celebrate steps on the path


to more success?


Search Console Insights is specifically


tuned for creators who often don't


need the full functionality of Search Console or Analytics.


If you're verified in Search Console,


you will automatically have access to it.


Check out the Google for Creators YouTube channel


for more.


We also recently published a new video series called


SEOs and Devs on our channel.


This series aims to bridge the disconnect between SEOs


and developers by highlighting the intersection of the two


professions.


There is a link to the playlist below.


And finally, even though we're currently still recording


at home, folks from the Search Relations team


are planning to go to a handful of in-person events again.


It's exciting and a bit scary to see folks in person,


so say hi if you see us.


All right, that's all for now, folks.


Thanks for tuning in to this Google Search News episode.


I hope your year has started off well


and the spring or fall is giving you


time to do good things.


If you have any feedback or comments,


please let us know here.


If you subscribe, I'm sure we'll meet again, perhaps


in another episode of the Google Search News.


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

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


Office Hours Hangout.


My name is John Mueller.


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


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


where webmasters and SEOs and Barry


can join in to chat about their website


and search and interesting topics


they've seen along the way.


A bunch of stuff is submitted on YouTube already.


But if any of you want to get started, jump on in.


May I?


Go for it.


Hello.


I'm working for one of the world's best


surgeons in this field.


He has many recognized academic publications, countless awards


from respected authorities.


Moreover, he has countless interviews


made and published by respected newspapers, magazines, TV


channels in the United States.


He's actively taking place in many organizations


and alternative institutions like respected universities


in the United States, too.


His website was performing first page on many related search


terms until 12th March 2019 update.


And then it lost 90% of business traffic


from Google in the next day, dramatic decline.


I'm working and researching for seven months nonstop now.


And we have actually no progress in search at all.


And our performance kept declining.


Meanwhile, we manually and very carefully


rebuilt all the backlinks we can reach.


And this evolved really spammy once carefully.


Search Console shows no errors but excluded pages


that we are totally fine with.


We are actively maintaining according to Search Console.


We developed mobile and desktop score 200%


of Google page speed in size.


And it didn't have to recover.


And the problem that we were able to identify


was that his website was serving pages


with exact text copy of his interviews copied


from those news websites.


And actually, 30% of site content was like this.


And would that be the problem?


Because we were removing all of them


and applied for a removal on Search Console.


It didn't solve the problem for passing one month after we


took the action.


And other thing we tried was moving to WordPress.


But it accelerated the decline.


After three weeks of experiments,


we decided to roll back.


And what would be your opinion about this case?


It's hard to say without knowing the site.


So that's kind of the first part.


It's a bit tricky.


In general, with these kind of things, one thing I would do


is make sure to have a forum thread where


you have the details so that people can look at that.


And so that when you kind of need to get more eyes on it,


you can point them at one place where


you have all of the information.


So that's kind of what I would try to do there.


In general, when you see changes from one day to the next,


usually that's not a technical issue,


because technical issues would kind of have


that normal path of indexing as well associated with that,


where you'd have kind of a large amount of changes


within a couple of days and the rest kind of slowly moving


forward.


Whereas if you're saying it's really from one day to the next,


then that sounds more like our algorithms


are, for whatever reasons, maybe not as happy with the site


as we were in the past, or where we think maybe


it wasn't as relevant as we initially thought.


So that's assuming that's what you've


been able to figure out, that it really happened from one day


to the next, and that it's across the board,


all of the pages, then I would focus less on technical issues


and more on overall quality and things like that.


And would there be a problem about medical content quality


in terms of the citation or references?


Should we be doing academic-style citation


on our medically advising content?


I don't see an issue either way.


I think that's essentially up to you.


But to me, I would try to take a step back and think about how


the website is perceived overall and try to find maybe


some bigger picture issues that are maybe worth focusing on.


I don't think it's something like you have


the wrong HTML for a citation.


That's not something that I would


consider to be a problem.


OK, one last question, John.


Like, it really has this recognition in real life,


but not on Google.


And we really were searching as a team, researching,


reading any kind of articles on every respected, also


the Google's pages.


And would it be possible if I sent you a case,


would you have a look at it for us?


I'm happy to take a look.


You can post maybe a link in the chat,


and I can pick that up afterwards as well.


But I can't guarantee that there'll be anything specific


that I'd be able to say.


Yeah, sure.


Thank you very much.


Sure.


All right.


Any other questions before we get started


with the submitted ones?


John, could I jump in and ask some infinite scroll


based questions?


Basically, it's an e-commerce that we're


looking at at the moment.


And we're trying to implement infinite scroll.


And the question that I have mainly


centers around the idea that Google selected canonical URLs


might be different from webmaster


initiated canonical URLs.


So the behavior that's being displayed


from the chart at the moment is that we


are referencing the first page in the paginated series


on particular pages as the canonical URL.


And I guess the question I have is, do Google drop


the open signals on the subsequent pages


of a canonical URL specified?


I don't see a big issue with us dropping the second pages


like that.


But it's hard to say exactly what your setup is.


It sounds like when you scroll down, it changes the URL.


Like, it's an infinite.


Like, how is the infinite scroll set up?


It's terribly implemented at the moment.


There's no reference to the other URL.


What the developers seem to have done


is they've stuck a rel="preven-next",


in the head, of the document that


references subsequent pages.


And you guys pay no attention to that.


It looks like they're also soft, potentially soft 404-ing


subsequent pages, because it looks


like Google's guessing the next page in the paginated series


to index all the content, from what I can see.


Unfortunately, I don't have access to Webmaster Tools


on that particular site.


It's a demo site, I feel like.


So I guess the question I'm asking really


is, if there's five pages within a category,


we're trying to get all the maximum SEO value from the,


we're competing with some big players.


So we want to squeeze every last drop out of the SEO on site


that we can.


So internal links, all that kind of stuff.


Do we really want to get Google to index all of these category,


page 2, page 3, if all the products are on there,


rather than just dumping in a 20,000-page XML file?


There's no signals.


I don't see any SEO value from that.


Is it worth the extra effort to implement, I guess,


your solution from 2014?


Does it make sense to do the extra effort?


Yeah.


So do you have a category set up at the moment,


or is it just one giant list that leads to the products?


They will have another favorite topic of yours, I think.


It's they're going to implement a mega menu, which


is not ideal, is it, really?


But I think it's the best they have.


OK.


So I think if they have category,


it's kind of like a category-based setup, where


they have one page that lists all products kind of thing,


but they have those products in individual categories as well.


And the lists per category is kind of reasonable.


Then I think that should be fine.


So the important part from our side


is that we're able to find all of the product URLs.


So that's something you could check with a local crawler.


If you have something like Screaming Frog or Deep Crawl,


one of those tools where you can crawl the website yourself


and kind of double check that actually it's


possible to reach every one of the product pages, for example.


And if we can reach all of those product pages


through a category page, then that kind


of infinite list of general products


that you might also have, that's less of an issue.


But that's something where it kind of depends


on how you have that set up, like how many items you


have per page and how the infinite scrolling is set up,


how many categories you split that across.


I think what I would try to do is


balance kind of a reasonable hierarchy for your product


so that you have a reasonable amount of categories


and that you have within each category kind


of a reasonable amount of individual pages


that lead to the product pages so that it's not too flat,


but also not just like one long listing that's very deep.


So in an ideal world, would you want


Google to be able to land on a category page,


scroll through five pages, and then pick up the URLs that way?


Because there's a hierarchy implemented.


There's on-page signals.


There's internal links that are going there from the page,


those header ones and title tags.


You would want Google to be able to see all of that


and those products listed within that hierarchy


to pass those signals to get maximum SEO benefit.


I wouldn't look at it for maximum SEO benefit,


but just purely from a technical point of view,


is Google even able to find those products?


And then kind of like when that baseline of Google


is even able to find everything is passed,


which is usually pretty hard.


It's not always that trivial.


Then that's something where you can think about which


of these products are important and how can I kind of present


them in a way that Googlebot, when it crawls,


recognizes that these are important.


So that's great.


And then that's something where it should work out.


SPEAKER 2 Do you have a preference on categorizing


in terms of the menu structure?


I know you're not a fan of mega menus.


Neither am I. Do you have anything


that you can maybe point me to to have a look at a more


optimal setup, perhaps?


JOHN MUELLER I don't think we have anything


that I could point at there.


What I would do is mostly focus on usability.


And if kind of like from a crawling point of view,


we can find everything and usability is OK,


that users don't bounce, then that's like a good point


to be.


SPEAKER 2 Great.


OK, thanks.


JOHN MUELLER Sure.


SPEAKER 3 So John?


SPEAKER 3 Hi.


Hi.


Hello.


JOHN MUELLER Hi.


SPEAKER 3 Yeah.


So John, I just wanted to know, being SEO,


would you recommend SEO people to focus


on page rank while optimizing for internal linking


or now they should not do like this?


Because I am sure that some, not some, but majority of SEOs


think for internal links only from page rank perspective.


So what is your suggestion on this?


I don't think that makes sense.


Yeah.


So I mean, I think it's interesting to look


at the different algorithms that Google uses,


but I don't think focusing on things like internal page rank


makes a lot of sense.


I would try to look at it more from a holistic point of view.


If there's something important on your website,


then make sure that that's really important to everyone.


But I don't think it makes sense to calculate the internal page


rank and try to optimize things around like that.


So one example that we often see is


that people try to take their terms of service page


and kind of hide that from Google's algorithm


so that it doesn't collect any page rank.


And usually that doesn't make any sense


because we understand that websites


have a structure like this.


And there's no need to hide that, to block it from indexing,


to use internal nofollow links, anything like that.


So that's something where it's very easy to get lost


in the weeds and to do a lot of analysis


to try to find the optimal page rank flow within a website.


But most of the time, it's wasted effort.


And in this case, one example is that when


I have seen a lot of people asking for link in XML site map


is enough or we should give the internal link


to that particular page.


And most of the times in forum, people


are asking only thinking that, OK, page rank may flow.


This is why everyone recommends to add an internal linking.


JOHN MUELLER I think you should always have an internal link


to a page.


If something is important, then make sure it's findable.


I don't, not from a page rank point of view,


but just general point of view.


If you care about the page, then it


should be findable for users when they go to your website.


AUDIENCE OK.


Thanks.


JOHN MUELLER Sure.


AUDIENCE Hello, John.


Let me run through some of the submitted questions first.


And I'll get back to all of you that


are trying to get some live questions in as well.


Because lots of these things got submitted over time


and useful to go through them too.


So the first one is, I work for the World Health Organization


and our website is not findable.


So there's like a long rant there too.


But it would be useful to know which


websites you're talking about.


So if you can send me the site or post the link,


I'm happy to take a look at that.


I've been fooling around with some rank trackers out there.


They tell me that for all of the keywords in their database,


my site ranks position 11 way more often


than any other position.


I can reproduce this in multiple services and anecdotally


as well.


Looking at this data on the graph,


the distribution is not even close to normal.


Nothing like my competitors' distributions.


It looks really like some kind of penalty


or artificial limit that's happening to my site.


Can you think of any penalty or something else


that would result in disproportionate number


of sites' results landing in position 11?


No.


So I'm not aware of anything specific that


would cause something like this.


My guess is that it's probably tricky across different rank


trackers.


So that's something where instead of using external rank


tracking tools, I would look at the search results yourself


and try to think about what is actually going on there.


Because it's something where we often


show a lot of different elements in the search results.


And there are lots of ways to be seen in the search results.


So position 11, just having that number alone,


I don't think that really tells you a lot.


So from that point of view, I wouldn't


focus on this kind of artificial ranking number


that you're seeing there, but really try


to look at what is actually happening in search.


I know there's a lot of talk this week,


but do you know if the nofollow change is


live for crawling and indexing?


I know the original date was March 1st.


Just wondering if that's live now.


So this is something where we made some changes in our search


algorithms with regards to how we treat nofollow links.


I believe the change was split into two parts, one kind


of being able to pass signals through nofollow links,


and the other with using nofollow links


for discovering new URLs.


And essentially, on our side, the change


is that internal systems are now able to do this.


That doesn't mean that internal systems are currently doing it.


But at least from a policy point of view,


they're able to pick this on.


And if there are teams within Google that say,


I will be able to, I would want to use this,


then that's something that they're open to doing that.


So it's possible for them to do it.


It's not the case that it's like we're pumping everything


full through those links now.


It really depends on what teams internally


are kind of testing, evaluating, and what makes sense for them.


We implement organization markup.


SPEAKER 2


John, do you know if teams are actually


doing anything with that now that they're allowed to?


I don't know.


Thank you.


They can, but I don't know.


I also think it's not something where


you would see kind of a big invisible change in the search


results just because they're suddenly doing this.


I imagine the changes would be more subtle.


Big invisible change that you can see.


That would be amazing.


I mean, it's something where we also try to use it as a signal.


So it's not like we will just ignore it completely,


but we'll try to figure out where it makes sense


and where it doesn't make sense.


So to summarize, the policy change


allows anybody in Google to use it for indexing and ranking


purposes.


But it doesn't mean that you are doing it.


And as far as you know, nobody is really doing anything


at Google since the change.


So I haven't looked into whether or not


people are actually doing it, but I don't


know of anything specific.


OK.


Thank you.


We implemented organization markup from schema.org.


There's no postal code on the page.


Can we add it only for robots?


Like, metapostal code and then a content?


If not, please list the situations


when webmasters can add markup data only for robots.


So structured data should be visible in the page itself.


It should be equivalent to what you're showing to users.


So that's something where I would show it to users.


So I don't know why, for example, a postal code


would not be visible.


But essentially, it should be visible for users


if you want us to pick it up.


If a website, for legal reasons, is not


allowed to market its products or a subset of them in the US,


and the most common approach is to block US IPs,


this will, however, lead to not being indexed


on Google for any market, since blocking US IPs means blocking


Googlebot.


Also, only allowing Googlebot but not human visitors


from the US seems risky because of Google's policy


of handling bots and users the same way.


So how should we handle a situation like this?


So you're right.


It's tricky because our policy does


say you should handle Googlebot the same way


as you would handle other users from that same region.


So that's something where if you're not


able to show users in the US that content,


you should not show Googlebot that content when


it's crawling from the US.


That's kind of the baseline policy there.


It's obviously kind of there are subtle differences


between US-based content and other countries' content.


Like if you want to block all users in Switzerland


and Google crawls from the US, then that's perfectly fine.


But if you want to block users in the US


and Google crawls from the US, then that's


something where you will see a change with regards


to indexing.


We don't have any provision for saying


this content is only accessible in individual countries.


So that's kind of, I think, a tricky situation there.


Our general recommendation here is


to make pages that are accessible by users


in the US, which might be kind of simplified pages, which


might be more like marketing pages


rather than the actual content that you're providing,


so that you can allow those pages to be indexed in Google


because they're accessible in the US,


while the actual kind of content that might not


be accessible in the US is hosted somewhere else


and appropriately blocked from crawling.


I know some people say, well, Googlebot isn't a normal user,


and I'll just cloak to Googlebot.


But like you mentioned, that's generally a risky approach


because we would probably see that as cloaking,


and that would be a violation of our webmaster guidelines.


So that's something I'd recommend not doing like that.


We're migrating our radio brand websites


into one aggregator brand website.


What helps Google to understand individual radio


brands under the aggregator brand


without losing news article snippets in search


and Google Discover traffic after the change when


everything is under the same domain?


Does Google have any best practices for these situations?


We might publish the same news article for multiple brands


if it fits the radio brand's audience.


So in general, this kind of merging of multiple websites


into one website is always tricky.


So that's something to keep in mind when you're merging


and splitting websites, then that takes a lot longer for us


to process.


And the outcome is not something that


is trivially able to determine what will happen in the end.


When you're moving from one domain to another,


we can essentially take everything from here


and just pass it on there.


But if you're merging things, the final version


is essentially a different website


than the individual versions.


So that's kind of a new state and not something


that's easily kind of determinable ahead of time.


And that's something where I would


expect to see fluctuations, at least in kind of the midterm


until things settle down.


And it might be that the final state is very different


than the initial state.


It might be that the final state is much better than all


of these individual ones.


It might also be that the final state is a little bit less


than the individual ones.


So that's something where there's no real kind of trick


to handling this, but really where


you have to take it page by page and migrate everything


to that new kind of bigger website.


If I can.


Sure.


Would you, if they have duplicate content


because they have different sites under that one aggregate,


would you just pick out one article to be a canonical?


Or how would you do that?


I think that's generally the best approach.


So if you can pick one article and set that as a canonical


and make sure that that's the best one that you


want to have indexed, then I think that's a good approach.


In general, we're able to recognize


this kind of duplicate content.


We'll try to figure out the canonicalization ourselves.


But if kind of the webmaster, the owner,


has preferences with regards to canonicalization,


then I would definitely just let us


know about that so that we can do it more in the way


that you want it done.


OK, thanks.


May I ask another question?


Sure.


Considering March 2019's update, if a medical website


haven't been updating the most competitive content


for the passing one year, would that


cause a day-to-day dramatic fall right after March 2019 update?


So I don't know offhand what happened in March 2019.


So that's kind of, I don't remember what


all happened back then.


But usually, if you haven't been updating content for a while,


then that's something where over time, we


will see this content as being less relevant.


But it's not that we'll say, oh, it's like 17 pages haven't


been updated.


That's too much.


We will demote the whole website.


That's not the case.


OK, thank you very much.


Yeah.


I've seen that apparently Google has some problems


to show the right spelling of meta title and description


in Persian language.


It shows a Persian alphabet from the end to the start.


And it wouldn't be possible for readers


to read that as it's meaningless.


I'd love to have some examples.


So if you're here or if you can send me some examples


separately or send me some screenshots on Twitter,


that would be fantastic.


It's hard for me to judge what exactly you're seeing there.


Second question is wondering why Google no longer supports


pagination with rel next and rel previous.


Previously, I've encountered some problems


in terms of defining the first page for Google


as it gets my second page instead of the first one.


And what's the ideal implementation


that Google wants from webmasters in this regard?


Is just internal links enough?


So internal links is definitely what we're looking for.


So we don't use the rel next and rel previous.


One of the things that really helps us


with regards to pagination is to have kind of a clear hierarchy


in the paginated pages.


So instead of linking from page one


to all of the pages of your set, link from page one to page two


and from page two to page three and appropriately kind


of forwards through the paginated set.


Because then it's a lot easier for us to understand


this page is embedded within your website


in this particular way.


Because it's linked from here, and it links back


to the previous page and to the next page.


And then we can determine kind of this next and previous flow


ourselves without anyone needing to define that specifically.


So that's kind of the recommendation


that I'd have there.


I've sometimes seen cases where we show maybe page three


or page four in the search results


when someone is searching for something generically.


And usually that comes back to, well,


you're linking to page four from the beginning already.


So it's hard for us to determine why page one would be much more


relevant than page four.


So that's something where I try to just give us


a clear pagination through appropriate links on the page.


And usually we can pick that up.


OK.


My question is about thin content.


The niche I'm working on is gaming.


Recently I built a tool which tells users about any game


specifications.


Last month I launched this service,


and almost 1,500 games were added to the database,


meaning 1,500 new pages were created for each game.


The Google algorithm found these as thin content, which is true.


But from a user's point of view, these


are perfectly fine.


These are sort of question answer pages.


For example, what are the specifics of the Fortnite game?


How do I tell Google about such content?


Such other sections on my website


use appropriate length content where needed.


So in general, I'm not quite sure


how you were able to see that Google sees these


as thin content.


We don't have a thin content tool in Search Console.


So my guess is we're just trying to figure out


how to rank these pages.


And if these are multiple pages that you're


creating for individual questions


about individual games, then I could


see how our algorithms might look at these pages


and say, well, we don't know how important this page is overall.


So my recommendation there might be


to combine some of this information that you have


and create really strong pages rather than


to dilute your content across tons


and tons of different pages.


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


It's not so much that you can tell Google,


this question is really important,


and you should index this page that only has maybe


two sentences on it.


But rather, you need to show Google


that this content is actually really important and relevant


because you provide a lot of detail there.


So that's something where I would go in that direction


more to combine the self-written content that you have


about these individual games together


with all of this database-generated content


that you have and create really high-quality and valuable


landing pages for the kind of content


that you want to provide.


I didn't take a look at your website itself,


so maybe you already have something in that direction.


But that's generally the direction I would go and create


kind of fewer pages with more better-quality content


than to have lots of pages with small pieces of content.


I have a few questions about breadcrumb markup.


I've noticed that Google will drop the final page


from breadcrumb trail displayed in the search results.


For example, the breadcrumb trail


might be domain.com folder instead of domain, folder,


and page.


My questions are, does Google drop the final page


from a breadcrumb trail if the page title is not


included in the breadcrumb list that's


visible to the users of the page?


I don't think the page title would have anything


to do with that in a case like that.


So that's something where usually it doesn't make sense


to, at least from my point of view,


it doesn't make a lot of sense to show


a breadcrumb for the individual page and kind of the page


itself because that's kind of overlapping.


And the second question is, will an excessive character length


cause Google to drop the final page title in the breadcrumb


trail from displaying in the search results?


I don't know of any specific character length limit there,


but there's only so much room in the search results,


especially on mobile.


There is not a ton of room for kind of really strong, long,


and kind of combined breadcrumb trails.


So that's something where we do have to kind of cut things off


at some point and have like either the dot, dot, dot


in the middle or kind of a shortened breadcrumb in general.


So that's something to keep in mind when you're


creating these breadcrumbs.


Exactly what user agent do I need


to filter our server logs for to check


Googlebot crawling our site?


We have a Help Center page on the user agents,


so I would check that out.


Especially for the mobile user agent,


it looks a lot like a normal mobile phone,


but there are a bunch of different user agents


that are worth looking at.


Can a self-referential canonical with no index


confuse Googlebot?


So I don't think that would confuse us,


but if it has a no index on it, then we wouldn't index it.


And then the canonical link there


doesn't really play a role anyway.


So that's something where I don't see it confusing us,


but we just wouldn't index that page because it


has a no index on it.


If page A is non-indexed and canonicalized to another page,


say page B, will Google consider page A as no index


or canonicalized?


If it has a no index, it's a no index page.


We wouldn't index that particular page.


We would potentially index page B,


but that's kind of separate from page A in a case like that.


And it will not also render the page right?


So does it mean that if Google is finding no index,


it will not even render the canonical?


That's correct.


If we so I mean, the canonical is kind of separate,


but if a page has a no index meta tag on it,


then we will not render that page.


So if your JavaScript changes the no index


into an indexable page, we would not notice that.


Correct, yeah.


Got it.


Thanks.


Is there still anything like the no ODP robots meta tag?


There is no open directory project anymore,


at least as far as I know.


So there's nothing really to do in either of those cases.


In the past, the no ODP tag would tell us


not to use the open directory project.


But since that's gone, we couldn't use it


if we wanted to use it.


So not much we can do there.


I would like to know if it's bad to repeat the anchor


text in my internal links.


For example, say I have an article called Solar System.


Can I link it every time with the anchor text Solar System?


Or by contrary, will Google algorithms think that it's spam?


We generally won't think that's spam.


I think that it's normal to have multiple internal links


to individual pages within your website.


Sometimes you have multiple internal links


on the same page.


And that's completely normal.


The thing where it would kind of get spammy


is when essentially all of this text on the page


looks a lot like keyword stuffing.


So if, for example, you're repeating this link hundreds


of times on that page, and it's always like Solar System,


Solar System, Solar System, and at some point


our algorithms would look at this page


and say, this page overall looks pretty low quality,


because there's just so much repetition in here.


It looks like keyword stuffing.


And that might be the case if you're


looking at something maybe like several hundred times


on a page.


It's definitely not the case if you're


talking about maybe five or six times the same link


So those are kind of the two extremes there.


I think for the most part, websites


don't have a problem with this kind of excessive linking


internally, because users, when they


look at a page like that, they also


have trouble navigating that.


If everything is like Solar System, Solar System,


then users have trouble finding the useful content there.


AUDIENCE 1 So in this case, John, in this case,


how Google treats HTML sitemap then?


JOHN MUELLER An HTML sitemap?


Well, it's a link to a lot of pages.


AUDIENCE 1 Yes.


Should we not have this page then?


JOHN MUELLER It depends.


I would make it for users.


An HTML sitemap, from my point of view,


is something that helps users to find the content that they're


looking for.


It's not something I would rely on for search engines.


So for search engines, I would really


make sure the internal navigation works well,


that you have a clean sitemap file.


And usually, you don't need an HTML sitemap file additionally.


So from my point of view, the cases I've looked at, at least,


is if it's a very large website and you


feel you need to have an HTML sitemap,


then probably that's a sign that your normal internal navigation


is bad already.


And you need to fix that.


Whereas if it's a smaller website,


then we wouldn't need an HTML sitemap anyway.


So oftentimes, the decision about whether or not


to make an HTML sitemap is tied to,


am I actually doing the right thing other where on my website?


And if you're doing the right thing elsewhere,


then you generally don't need an HTML site.


OK.


For a website with science content, evergreen,


should I add the credits image, even


if they're a public domain and the bibliography?


Would this help with EAT?


I think, in general, if you have images


that you use that have credits that are associated with that,


I would specify that on your pages.


It seems like the right thing to do, regardless


of the kind of website that you have.


So that's something where I think that makes sense.


In any case, with regards to bibliography,


I think that also makes sense for, in any case,


if you have links to more detailed information


where users can dig in and find out more,


then provide that to users.


I think that's a good service for users that shows them


that you're serious about your content,


and that helps our algorithms to figure out, as well,


that actually this website might know what it's talking about.


If I have two websites for different countries,


like.com and.no for Norway, and I add the same content


in both websites, but I add a canonical tag


in the second website to show the first website,


and the content on my second website


will be crawled by Google, or does it


count as duplicate content in a website by Google?


So if it's duplicate content, it's duplicate content.


So I think that last part is kind of obvious.


The important thing here is that duplicate content on its own


is not a bad thing.


It's not that we will demote your website


and say it's terrible because there's


some duplicate content on it.


It just, for us, means that we understand this is a duplicate.


And when someone searches for this content,


we'll try to show the most appropriate version


to show to that user.


So it's not the case that we'd say this is a bad website


because there's duplicate content here, but rather,


which one of these pages is the right one to show to users?


And we'll try to pick the appropriate one.


So with that in mind, that might be that a user in Norway,


if they're searching, we might say, well,


this is the local version of the website,


and it looks like they're searching for local content.


Maybe we'll show that.


It might also be that we look at this and say, well,


there's a rel canonical telling us


the.com is maybe the appropriate canonical,


so maybe we'll show that.


And these kind of things are sometimes


tricky decisions in the sense that for canonicalization,


we use a lot of different factors.


That includes the rel canonical.


It includes redirects.


It includes internal and external links.


All kinds of stuff come together.


And the clearer we can recognize which one of your pages


should be the canonical, the more we'll


tend towards that one and use that one.


From a ranking point of view, it doesn't matter.


So if you have multiple pages, they have the same content,


we will pick one of these as canonical


and rank it like that.


If we shift the canonical to another one,


perhaps you have a redirect or rel canonical setup,


then the ranking will be pretty much exactly the same,


just with a different URL shown.


So it's usually not something that is critical for you


to fix in search, but more like if you have a preference,


then let us know about that preference


and we'll try to respect that.


And less that there's a magic trick


that you need to do to rank higher


with this kind of a configuration.


The page speed insight tool flags


amp-url discovered with the option


to reanalyze in terms of mobile page speed as a ranking factor


which score is used, that of the standard URL or of the amp-url.


So for speed in general, we use both lab tests as well as


field data.


So field data is what users would see in search


when they go to these pages.


And if users would see the AMP page,


then that's something we would use there.


So that's kind of the two sides that are involved there,


which can come together.


So when you're testing these pages for speed,


my recommendation would be to test both of them.


Usually AMP pages are very fast, but you can also


make slow AMP pages.


So I would really double check both of these versions


and make sure that what users would see


is actually the speed that you'd want them to see it.


Does updating old content is determined


as creating new content by Google?


Let's see.


It's hard to understand this question.


I think it goes in the direction of,


do I need to keep updating all of my old content?


I have hundreds of articles, and I


don't have time to keep updating everything every day.


So we don't have any magic algorithm


that looks at your content and says,


you need to have this updated every week.


But rather, we do look at your website overall.


And if overall we think your website is maybe not


as relevant at some point as it used to be,


then we'll treat it as being less relevant overall.


So it's not the case that you need to kind of go through


and keep updating everything.


But if you're actively creating new content,


then maybe your website will continue


to be relevant over time.


So it's not that you have to go through all of your news


articles and keep updating them with the newest facts,


but really kind of like make sure


that the overall picture of your website


is what you want to have reflected in search.


I have a quick question.


My question is, nowadays, why Google Webmaster Tools become


so rigorous?


And considering most of the structured data warnings


as errors, are these important to have on a website?


For example, breadcrumbs and missing fields, please advise.


So I wouldn't necessarily say that Search Console or Webmaster


Tools is more rigorous than in the past.


But structured data does evolve over time.


And it can happen that things which are fine at some point


with regards to structured data become warnings at some point,


maybe even errors at some point.


So just because you've implemented structured data


once doesn't mean it will always remain valid just in that way.


In particular, our search features evolve.


And some of these search features


rely on structured data.


And if the new version of a search feature


needs extra information from a website,


for example, that you don't have in your current version


of the structured data setup, then it


might be that we would say, well, in order for us


to display your website in that search feature,


you need to provide this information.


It's not the case that we would say your website is bad


because it doesn't provide the structured data the way that


would match our requirements at the moment.


But rather, if you want to take advantage of this search


feature, kind of this fancy way of presenting your website


in search, then you need to make sure


that you're fulfilling the requirements for that.


So from a ranking point of view, that's less of an issue.


But it's really more that, well, there


are fancy new ways to show your website in search.


And if you want to work along with that,


then make sure that we can work with your website for that.


And we try to minimize the changes in structured data


requirements and warnings and recommendations


as much as possible.


We actively work together with the product teams


to really minimize these kind of changes


because they are disruptive.


It is something where if you've implemented it once


and then suddenly Google changes what it needs


to have for a search feature, then that's


frustrating as a webmaster.


Because maybe you need to do some extra work


to get that done, or at the very least,


update a plugin to kind of reflect those new changes.


It's always a hassle.


So we try to minimize that as much as possible.


And we try to have as much of a path forward as possible


where we'll say that maybe something becomes


a recommendation and it will be flagged


as a warning for a while.


And then after some time, we can say, well,


we've been telling you that it would


be good to have this set up for a longer time now.


Maybe now is the time for you to actually make that change.


But yeah, I think it's not so much Search Console,


but just generally the whole ecosystem around structured


data keeps evolving.


And that makes it exciting because there's always


new stuff happening.


But it also means there's a lot of work sometimes involved


in keeping up.


OK, we just have a couple of minutes left.


So maybe we should just switch over


to last questions from you all.


Hi, John.


Hi.


I have a question, and I'm not exactly a technical SEO expert.


So I hope I'll be able to express the situation as


accurately as possible.


We have a multi-regional website.


And this means that basically for every page that we create,


we have like eight different regional versions.


Now, on top of these regional versions,


we also have a global version of each page.


And from what I understand, this is


to make sure that we are distributing authority


evenly throughout the website and not just


to one particular region.


Is this best practice, or are we shooting ourselves


in the foot with the global pages?


I think that can work well.


So what I would try to do in a setup like that


is to make sure that the regional versions have


a strong reason for existing.


So instead of just taking the same content and saying,


well, this is a version for Australia, New Zealand,


and the UK, kind of really make it clear that this is


a localized version of the content, which in some cases


might be that you just have the local addresses and phone


numbers on there, but at least to really clearly make sure


that it's easy for us to recognize


when this page is relevant and when


we should show that in search.


You can also use the hreflang tags between the pages


to tell us what the connection is between those pages.


But in general, that's a very common setup.


So I wouldn't necessarily see that as something


that you'd want to avoid.


OK.


Awesome.


Thank you.


Hi, John.


Quick question for you.


I'm using Dialogflow and working on FAQ pages with markup schema


properly.


But when I plug it into Dialogflow,


they have a beta for knowledge.


It doesn't read the markup schema properly,


so it wants it to be in plain text.


Am I doing it wrong?


I don't know.


I haven't tried anything with Dialogflow.


So I would check with the, I think that's


handled by Firebase, right?


Correct.


I would check with the Firebase support folks on that.


OK.


Yeah, it seems like counteracting answers.


Like you want it schema, but then you don't.


Yeah, I think for the most part, these


are probably different use cases where we want it


in schema for search.


But maybe Dialogflow needs to process it differently


when it tries to understand the pages.


Perfect.


Thank you.


Sure.


Hi, John.


Last question from my side, if you allow.


So yeah, so John, recently I had two pages, two separate pages


for one entity.


Some was like blog page and some was main course page.


Blog page was ranking for main course page,


and featured snippet was also appearing from blog page.


So I just took that particular paragraph from blog page,


pasted it in my course page, redirected blog page


to course page.


But what I saw is that now featured snippet is gone.


The same content is appearing in other page,


but featured snippet is gone.


In this case, how to analyze this?


Was it really content or other third factors


which were playing the role?


Because we are using the same content.


Yeah, please.


Yeah, I don't know.


It's hard to say.


So the featured snippet is something


that is an algorithmic organic search element


from our point of view.


And it uses a lot of different signals


to understand when to show something as a featured snippet


like that.


It might be that if you just take this piece of text


and put it on another page, and the page essentially


has a lot of other content on it, that we might think,


well, maybe this piece of text is not


a relevant representation of that page itself.


So just by taking a piece of text


and copying it somewhere else and hoping


that that new page will rank in the same way,


I don't think that generally works.


And for featured snippets, it probably, in most cases,


doesn't work that well either.


And all the page signals are passed with redirection?


Essentially, with a redirect, you're


telling us that the new page replaces the old one.


So the signals that we have, we can pass.


That doesn't mean it'll rank the same way,


because if the content is different


and you're just redirecting to that different content,


if the layout is different, if the navigation is different,


all of those things can make it differently


relevant for individual queries.


Yeah, but it was a very similar page, not a big change.


I don't know, by the way, what happened.


Yeah.


I would try things out and see what works well, especially


if you're looking at individual pages,


then maybe that's something where


you can experiment a little bit and see what works well.


Yeah, yeah.


Cool, thanks.


Cool.


All right, maybe one last question from anyone.


Hi, John, can I ask a quick question, please?


Sure.


You talked before about noindex, and obviously


noindex on a meta tag at the top of the page


should stop Google from indexing a page.


But we're seeing some kind of strange behavior


where we have certain pages that are marked noindex,


but we're still seeing them in Search Console showing up


as indexed.


And we're actually seeing it says indexed but excluded


by robots in there.


Now, I can send you some links if you want to.


But it seems like it's the old scenario where a page might


have used to have been indexed, then it was blocked by robots,


then the noindex was removed, and of course,


Google then would never have called it


to know that the noindex was removed.


But it's not that.


These are pages that have always been noindexed.


And when you go in the Inspection tool,


it says that they are marked to be indexed.


And there's no kind of typos or code issues


or anything on the page.


They're all by the date fine and everything.


It's just some very strange behavior.


I'm not sure if you're aware of it


or if there's any situations where noindex


would be indexed by Google.


It's just that it's to do with fasted navigation.


So we don't really want to be seeing duplicate content type


and stuff appearing there.


Yeah.


I don't know.


So if it has a noindex and we recognize a noindex,


we should treat it as a noindex.


So we don't use it as a signal where we'd say, well,


maybe we'll index it anyway.


So it's a pretty clear sign.


But I'm happy to take a look if you can send me some examples.


Yeah, that's how I understood noindex.


But I just wasn't sure.


I was thinking I'm going a bit crazy.


But I'll pop an email and I'll stick it in there.


Sure.


Thanks for the map.


Cheers.


Sounds good.


Cool.


All right.


So let's take a break here.


If you have more questions, feel free to drop them


in for the Friday office hours Hangout.


And maybe we'll get to them there.


Or if you want, of course, you're


always welcome to jump into the Webmaster Help Forum, where


there are lots of experts that are able to help out


with a lot of these more common situations.


So with that, let's take a break here.


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


Bye, everyone.


Thank you.


Bye.


English Google SEO office-hours from July 23, 2021

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


SEO Office Hours Hangout.


My name is John Mueller.


I'm a search advocate on the Search Relations team


here at Google.


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


where people can join in and ask their questions around Search


and their website.


We can try to find some answers.


Bunch of stuff was submitted on YouTube already,


so we can go through some of that.


But as always, maybe we can start off


with some live questions to get us started.


It looks like some of you already have your hands raised,


which is great.


Let's see.


Ashwani, you want to go first?


ASHWANI SINHAVANTHAOIYAJIYA JOSEPH MALIKA KUMAR


Hi, John.


Good morning.


How are you?


Hi.


So John, I have a question related


to international market targeting.


OK.


So like, especially related to canonicalization.


My question is, if suppose you have a 100 page


website in an English language.


And now you just wanted to translate, like,


create another directory of a French language.


But in that, you only created 10 page.


Only 10 page you have translated out of 100.


Now, my question is, can we set canonical inside the French


version or not?


Or inside the English version or not?


Can we add canonical?


How do you mean canonical?


Like, look, I'm saying, if suppose


you have an English version.


So for particular English version,


you have also a French version for 10 page only.


OK.


Now I'm asking, can we add canonical for English version


or not?


Because I am already applying hreflang.


Yeah.


So usually, you can apply the link rel canonical to any page


that you want to have indexed.


So that's kind of the basis criteria,


that you have one URL, and you have


a preferred version of that URL.


And then you set the rel canonical to that.


And when it comes to international websites


for different countries or different languages,


each of those versions is unique.


So it would be its own canonical.


So in a case like that, you would


have the English version of one page


would set the rel canonical to itself.


And the French version of a page would set the rel canonical


to itself.


And you would have the cross-linking with hreflang.


But the canonical would be per language.


OK.


So but the content on the English version


and the French version is 100% similar,


like 100% copied content.


Yeah.


So still, can I use canonical for French language


as in a French version canonical?


Even if the content is translated,


then it's unique content.


Then you have the rel canonical per language again.


So from that point of view, whichever URLs


you want to have indexed, that's the one


that you would use for the rel canonical.


Understood.


And another question is related to backlinking purpose.


If suppose I have those pages in French,


I have 10 pages in French language


and 10 other pages in Portuguese language.


So can we start creating links, quality links, especially,


not bulk, can we create links for those different language


space or only have to work on English content?


I mean, it's normal that these pages


would collect links over time.


So it's not something that you'd need to manually do.


So it's, yeah, I think the important part


with multilingual websites or international websites


is that you have really strong internal cross-linking.


But over time, users in French will appreciate your website


and they will link to it, perhaps.


So that's something that essentially happens naturally.


That's not something that you have to go off and do manually.


No.


Like if suppose I am creating backlinks for English content.


So similarly, if I want to create backlinks


for French content, for Portuguese content, OK.


So can we create all those with the help


of those French version of link?


It's completely fine to have the different international


versions collect links.


But I'm kind of worried the way that you frame it as,


like, we will start building backlinks to these pages


because it sounds a lot like you will start dropping


links in different places to get those links.


So that's kind of the part where I'm like,


you need to be careful.


But kind of the aspect that an international web


page collects links over time, that's completely normal.


OK.


Understood.


So we can also go ahead with change.


I can also change a large part of a link.


How do you mean?


Sludge.


The sludge part.


If we have a page like abc.com slash xyz, OK.


And I want to convert xyz into French version.


So can we change our sludge to the French version?


Sure.


Does it impact does it impact SEO?


Not really.


But you can do it.


Some sites have localized URLs, and other sites


have kind of global URLs.


That's up to you.


OK.


Understood.


Thank you.


Thank you, John.


Let's see.


Saidul.


Hi, John.


Hi.


So I have two questions.


One is about one of our client.


They launched a website in June.


By mistake, they did not block search engines


from crawling and indexing the site.


And they realized it at the beginning of July,


and they told us to fix it.


So what we did, we changed the tags.


We submitted the site map on Google Search Console again.


And there was an issue.


Like Google Search Console sent a message


that there are a lot of noindex pages.


So we click on that.


We just submit the website for validation.


A validation is in progress every time we check.


But unfortunately, Google did not index


a single URL of the website.


It's almost one month.


So client is asking whether we can do something different


to make faster the process.


So I'm asking what we can do, because it's almost one month,


and it looks like no URL has been indexed so far.


Like, do you see nothing in the reports


then for index coverage, or?


It's almost same.


Like, what we tried, when we saw that nothing is happening,


we submitted few URL, minimally.


Like, inspect URL, then decrease both indexed.


Those few pages only get indexed by Google.


But the one we submitted through site map submission


did not get indexed at all.


OK.


So it sounds like there's not a technical issue involved.


And if you're saying individual URLs,


when you submit them manually, they do get indexed,


then that sounds like, on the one hand,


there is not a technical issue involved,


and there's also no kind of overall block of the website


involved.


So those are two aspects that sometimes play a role.


The overall block might be if a site removal


request were submitted, and you didn't realize that,


for example.


But it sounds like those two sides are OK.


And then it's essentially really mostly a matter


of us recognizing that this is a useful website,


and going off and crawling it.


And on the one hand, submitting URLs individually,


that's one approach.


But we also kind of need to understand


how this website fits in with the context of the overall web.


So that's something where sometimes it just takes time.


And during that time, a really good approach


is to find ways to promote your website directly.


So instead of putting the website up and hoping


that Google finds it and sends you lots of traffic,


I kind of take the initiative and say, well,


in the beginning, we have to do a lot more work


to drive users to our website because they


don't know about it.


And finding ways to promote your website,


sometimes that just takes a bit of time, a bit of practice,


finding the right channels where you can reach people


who are interested in these topics.


And then, I don't know, maybe running ads,


maybe doing some social campaigns,


maybe working together with other sites.


Any of these things, they can kind of


help to drive awareness of the website.


And with that, over time, we'll understand


that this is actually a website that we


should be indexing a lot more.


But kind of just dropping a website onto the web


and submitting a sitemap file and hoping Google


shows it visibly in search, that's usually not


a great practice.


And one more question.


This is about press release submission.


So one of our clients, they are planning


to do press release submission for one of the recent events.


Now, the question is, when they do the press release submission,


at the bottom of the press release submission,


they provide information about the business


and add the domain name.


And domain name is hyperlink.


Now, the content they use for the press


release submission every time, each time the content


is similar, like when it is an event,


it's the same content publishing on various newspapers.


So will that be a problem from Google point of view?


Because this is the same content publishing there


on these various news websites.


So we are a little bit concerned, actually,


how Google will consider this.


So that it's the same content, I wouldn't worry about that.


If you want to rank for that content,


then obviously putting the content


on other people's websites makes that a bit harder.


But if you just want to drive awareness of your business,


then that's kind of a reasonable approach.


And with regards to links in press releases,


the important part for us is kind of that it's clear


that these are press releases and that you wrote them


yourself.


And you can do that by making sure


that there is a rel="nofollow() on the links that are there.


Or if you just have the domain name link,


then usually that's fine as well,


where if we can kind of recognize,


oh, it's just a domain name.


It's not kind of like this keyword-rich anchor tag


that is there.


So from that point of view, that sounds


like a reasonable approach.


And again, if you're mostly wanting


to drive awareness of the website,


then you don't really care if your content is ranking


or the press release on this site or on a different site.


It would be different if this is content


that you want to rank for.


You did something really fantastic,


and you put the whole report on your website


and into the press releases, then


it's possible that these press releases will


rank instead of your content.


AUDIENCE 1 Thank you.


Thank you.


Sure, Branko.


Hi, John.


Hi, everyone.


Hi.


I have two questions about negative SEO


and bad backgrounds.


The first question is how to isolate from someone who


is doing negative SEO to you.


By negative SEO, I mean someone points


a lot of domains with a lot of bad backgrounds on it,


and he's doing that constantly, for example,


for a couple of months.


And should I pose the second question?


So with something like that, in general, we


would recognize that and just ignore it.


So I wouldn't necessarily worry about it.


If it's something where you're really losing sleep


because you think maybe Google thinks


that I'm buying these backlinks, then


putting the domain in the disavow file is fine.


I don't know, I would just do that from time to time.


It's not something that you need to do every day.


And just by including the whole domain in the disavow file,


you kind of are a little bit faster than what they're doing.


So it's almost more efficient on your side.


So should I put the domain file or their backlinks?


Because previously, I asked questions,


and you said that Google is looking to redirect


between two canonical pages.


And these domains are redirecting their backlinks.


So they have also backlinks on it.


Not quite sure how you mean.


But I think with the disavow file,


I would just list the domain.


If you look into Search Console, you


can see the links report there.


And I would just take the domain name from there and use that.


Yes, but for example, in Google Search Console,


it's showing me their backlinks.


For example, if someone points a domain to my website,


it's showing their backlinks on it.


And there might be more than 50,000 URLs.


Yeah, I would just do it on a domain level.


So I mean, it's something where most websites don't


need to do this.


And I think even if there's someone


trying to do negative SEO for you,


our systems are so used to this kind of behavior,


and they ignore it.


So I would say 99%, you don't need


to do anything about this.


What I would do in the situation where you're just really


worried and you want to make sure that you have everything


covered, I would download the links from Search Console.


I would extract the domain name from there, maybe


in a spreadsheet or something like that,


and then just submit those domain names.


And that way, you kind of have that covered,


because the links that we show there


are kind of the ones that are similar to what


we would pick up.


So from that point of view, I would just submit those.


But again, 99%, you don't need to do anything.


OK.


The second question is, if there are no issues reported


in Google Search Console and no manual actions are taken,


can this be a reason still for a recent drop?


I would suspect not.


It's something where, especially with negative SEO,


we have a lot of practice with that.


And we're really good at recognizing


these kind of things.


And the main thing that we do when we recognize it


is we ignore those links.


So it's not that we would say we will drop your website


in search.


It's just, well, it's like we notice


there is some weird stuff happening.


We will just ignore it.


And we will focus on the rest, on kind of the good things


for your website.


So if you're seeing a drop in search,


then probably that's related to something else.


OK.


Thank you.


Sure.


Let's see.


Hello, I think.


Hey, John.


Can you hear me?


Yes.


Cool.


So a page of my clients got de-indexed from Google


a couple of weeks ago.


This page was in the sitemap, but Google Search Console now


reports it as a soft 404.


And when I use a URL inspection tool,


it says, the Search Console says,


something went wrong, if the issue persists,


try again in a few hours.


But I've been trying this for two weeks.


I tried this URL in the mobile-friendly test.


And it says that it's mobile-friendly.


From the Bing webmasters point of view,


there are no issues as well.


There are no manual actions as well.


So I'm just wondering if I could get closer to what exactly


is wrong with this page.


So this page is a car service pricing calculator tool.


So I was just wondering what could be wrong with this.


Yeah.


So we try to recognize soft 404s automatically, especially


when there is something like a clear text on the page that


tells us there is no content actually here.


So if this is a kind of a calculator page,


I would just make sure that you don't accidentally


have, by default, some message saying, oh, we have no values


calculated for you today, before you enter the numbers


or something like that.


The other thing is with soft 404 pages,


we saw a bunch of these reports recently


in the past couple of weeks, I'd say.


And the team has been looking into that.


And I think they turned one of the classifiers


off now based on some of the feedback that we got.


So I would suspect that maybe this will just catch up again


and work out in the next couple of days, next week or so.


So that might be related to that.


So just to clarify, the first thing you're suggesting


is Googlebot will probably need to see some clear text


on the page indicating the nature of this page, what


it's actually about?


Not so much the nature of the page,


but that there is actually content there.


So for example, a common situation on an e-commerce site


is you go to a category, and then it says,


there are no products in this category.


If we see a text that says there are no products here,


then we might say, oh, it's actually a soft 404 page.


And with a calculator page like that,


maybe it's set up in a way that when you load it the first time


it says, oh, I don't have any results for you.


Whereas if you load it up the first time and says,


oh, this is a calculator and some general text,


then that makes it a lot easier for us to recognize,


there's actually something here, and we


should keep this page indexed.


Cool, and then the second suggestion you're having


is that it's something on Google's side


that this thing may resolve on its own


in a couple of days or weeks.


Yeah, yeah, yeah.


OK, then one additional question on this


is, is there any chance that failing co-ed vitals,


specifically the cumulative layout shift,


could that have anything to do with it


being seen as a soft 404?


No, no.


That's completely separate.


No.


Cool.


Thank you so much.


Sure.


Gregory.


Hey, John.


Thanks for having me here.


Yeah, I submitted my question as well in the comments before.


But my question regards React JavaScript.


One of my clients has a React JavaScript website.


And for some reason, in the meta description,


it picks up snippets from the website.


And it's not even a full sentence.


It's saying it's like a result page, category page, where


they have, let's say, 126 results found.


And then it's saying MapView.


And then it's picking up a title from one of the products


or one of the services.


So the meta description is actually


fabricated by Google itself while we have the meta


description entered.


How can we tackle this to make sure


that Google actually picks up the meta description instead


of the chaos?


Yeah.


I think having a meta description


as a first step is really important.


So I would just double check that.


The other thing is our systems try


to create their own descriptions and titles when


we recognize that things are very


repetitive across the website.


So if you have the same meta description


across hundreds of pages, then we might say,


oh, it's not so descriptive, actually.


We will figure it out.


And when it comes to we will figure it out,


sometimes we do a pretty good job.


And sometimes we don't do such a good job.


So kind of the repetitive nature,


I would double check that.


The other thing is we try to recognize


when things are accidentally spammy in the description.


In that if you have a lot of keywords in the description,


or it looks like you're just including kind of queries


that you want to rank for in the meta description,


that's something where we might say,


well, this is not actually useful for the user.


And the third kind of reason why we sometimes


pick a different meta description


is we try to match the description based on what


people are actually searching for.


So you'll see different descriptions


depending on the query that goes to the page.


And if we can recognize that a part of the query


is clearly written in the meta description itself,


then we'll try to use that.


Whereas if we can recognize that actually the query is not


in the description at all, then we


might pull out some content from the page


and say, here is some kind of context


for why we showed this page in the search results.


Well, I can assure you the query is there, and also


when it comes to the repetitiveness.


When you're talking about SEO on scale,


you do not want to go to every category page


and making sure that they have a unique meta description.


So you find out a way to have it somewhat unique,


but also templatized in a way that you, hey,


these are the keywords that we are trying to use,


and we have, let's say, three versions of some meta


description and sentences that you used,


and you juggle them around to different pages.


Is that valid, or would you say, well, we still


will recognize the repetitiveness


even in that sense?


I think that's usually OK.


So especially on e-commerce site,


you kind of necessarily end up like that.


The important part is kind of that the description is not


like a description of the website,


essentially, where you have the same description across all


of the pages.


If you're automatically generating a description


based on the current page, that's


a perfectly fine approach.


The other thing that you might be able to do


is when we try to create the description to show


in the search results, we often try


to focus on the first text that we find on the page.


And that's something that you can control a little bit


in that if you can give us kind of like a clear heading


on a page way on top in the HTML so that when we look


at the page itself, we see, oh, it's


like we need to create our own description for whatever


reason, which might be wrong now.


But if we do create our own description,


we can take kind of the first part of the page here,


and that's like a clear heading.


It's not like a collection of menu items, for example.


And that sometimes makes it so that even


if we have to revert to creating it ourselves,


we can pick something that's kind of like a reasonable piece


of text.


OK, well, it makes sense because when I started that,


one of the first sentences in the description of the site


itself.


But we moved the content below products


because the goal of the page is, of course,


to get somebody to buy a product instead


of going through a bit of content.


So that's why we moved it down, but now I need to suggest


that we put it back up.


I mean, you can use things like CSS to just display it


somewhere else.


So that's something where technically it


could be on top of the page in the HTML, essentially,


but with CSS, it's located or displayed somewhere else.


So that could be kind of a workaround.


But also, if you can't get this to work at all


and the descriptions look really terrible,


then send me some examples.


Ideally, screenshots of queries, and then we


can pass that on to the team and say, hey,


we're trying to do the right thing, but look at this chaos


that we're creating here.


AUDIENCE 1 OK, I got a second question


regarding the core update.


We actually had a bump in the beginning of May


where we actually saw more traffic coming


into one of our main pages, actually all of the main pages,


and that was very good.


And we actually were doing good in the core web vitals.


And then all of a sudden, they went from bad page experience


to poor, or need improvement, and that was good.


That's where we saw the uplift.


And then the core update came, and it got reversed.


Other clients, I see them recover


in the last couple of weeks, one of the clients,


the client that I just talked about,


actually remains at the same level.


We believe that it still has something


to do with the rendering of the page,


that it's not fast enough, that the first contentful paint is


not low enough, and LCP is still too high.


But it seems that the values have been changed,


or have been testing our website, saying, hey,


now you've got some pages needing improvement,


and all of a sudden, we're back at square one.


How would you approach this in order to get this solved?


Or just to know where the pain is, because right now, you


think you have solved it, and then an update comes,


and hey, buy it to your solution.


So I think, first of all, the core update that we did


is not related to the core Web Vitals.


So that's kind of an unfortunate naming, I guess,


now that I think about it.


But they're really unrelated.


The core update is really about updating the way


that we see relevance across a website.


And the core Web Vitals is essentially


just the speed user experience side of things.


I guess that is coincidence.


Yeah, and the core Web Vitals, we started rolling them out,


I think, in June, early June.