Maybe that'll get them more interested.


Why are SEOs and Devs from different planets?

Also, one more thing.


And I'm pretty sure that this will get developers angry with me, but they got to be fine in


the end.


I promise developers, you'll be fine with this.


Oftentimes developers don't know if you're genuinely interested in what they are doing


to solve a specific problem or if you're just like trying to be polite or something.


So they might, when you ask them something, they might weasel out with a bit of jargon.


Like oh, you know, it has something to do with the routing.


Don't be like, oh yeah, the routing.


Yeah, cool, cool.


Because that will tell me that you weren't actually that interested because my answer


was ridiculously unspecific and unhelpful, really.


But it makes 90% of non-genuine conversations go away, which is great.


Because then I can actually get stuff done.


But be asking questions.


Continue to ask, what do you mean with the routing?


How does it actually work?


And then you might get lucky and they might be excited about telling you how that actually


works.


And then you understand more of the system.


So similar problems in similar systems or other teams or other clients or future jobs,


you now know at least how it worked in this one case.


And then there's a good chance that the way that it worked there is the same that it works


elsewhere too.


And then you might actually be able to help an engineer also find the solution a little


quicker.


I still wouldn't come with a solution, but at least you understand a little better what


the system looks like and how it actually works.


And normally engineers are willing to tell you this.


Yeah.


And I think, so that brings it back to the, you know, in the beginning when I said that,


you know, SEOs should be technical.


And you said, oh, engineers shouldn't.


And I think I'm a huge advocate.


Anytime any SEO comes to me and says, I want to learn to do what you do.


I mean, I worked at the most technical company you can work at.


And I've been in many interviews with other corporations where I've been turned down because


I'm not technical enough, believe it or not.


And I think it's a trend and more companies are expecting SEOs, not just to know, you


know, your keywords that you're targeting and how to target them and how to structure


and whatever, but you really got to understand.


And you know, like the conversation of with the engineer, when the engineer says, oh,


we can't do that, which I've been told many times.


And I know enough now to where I can say, actually, I know you can.


But if you can't, then I'll go ahead and write it for you.


And that usually I mean, that's kind of like, challenging a little bit rather than working


with them.


And a lot of times they go, Oh, no, no, no, no.


Okay, I'll take care of it.


Because they don't want me writing in their code.


But yeah, you convinced me there.


You actually Yeah, it makes sense now that you say it.


Because at first I was like, you know, you don't have to do that.


But now Yeah, you're right.


You're absolutely right.


Yeah.


And I think what you're saying with like, having that conversation, and when the developer


says, you know, it's a routing thing, you know, and the SEO says, Oh, okay, and then


it's all done, right?


You know, ask the question, you know, so it's okay, you don't learn, maybe you don't know


enough to ask technical SEO now, but you like you just said, have that conversation with


the engineer.


Yeah, learn a little bit more.


And then the next time you're in that situation, you know, you may get to a point where you'd


be like, well, I'll just do this for you if you're gonna do it.


And being vulnerable and saying like, I don't know, is a relatable for engineers.


And B, it also makes you more trustworthy.


Because as, as developers, we are relatively good at finding out things or like running


experiments to test hypothesis.


So if you present me with something that contradicts my intuition, I'll run an experiment and I'll


find out you lied to me.


And that's definitely not a trust booster.


Yeah.


So why not do this learning together?


As you say, test and learn.


I love that so much.


I think that's one of the key phrases in our conversation today was like, test and learn.


Always test and learn.


Beautifully simple and yet rarely done.


I mean, it's the it's the GitHub culture, which is why I love being here.


Right.


And we were a culture of engineers at the heart of it.


And everything we do, it's, you know, just break things, just push it out.


And if it doesn't work, it doesn't work.


Go on and do the next thing.


You know, nobody makes mistakes because we're all just learning.


So it's, I think other companies should adopt that culture.


And I think what you said earlier, too, you know, it's engineers are in this, you know,


it's the culture.


And a lot of time organizations kind of put engineers on the spot and to where they can't


feel that they can, you know, work with SEOs.


And so, yeah.


Seeing that barrier is the thing that both sides have to do and have to want, I guess.


Yeah, for sure.


We share so much.


We share this culture of test and learn.


We share the fact that we are working with things that we don't necessarily always know


every single detail about.


So why not work together?


Yeah.


Well, we live in a world now where the engineering process is so much faster, too.


I mean, with GitHub and development operations working in an automated way.


Right.


Like, I mean, Google now pumps out, updates what every minute?


Often.


Quite often.


Quite often where you guys in the past, you know, Google would update.


There'd be a big rollout when, you know, you're doing waterfall.


So we live in a world where things can happen very quickly and there's no reason why.


Everything is a lot more agile.


We have much more agile, for sure.


For better or worse.


But yeah, I think it makes sense to just, I think if I were to take some bits and pieces


away from this conversation for the developer side of things.


Be okay with SEOs not knowing everything.


Invite them in as much as they might invite you in to test and learn together.


And again, this phrase is just beautifully simple.


And like, don't get hung up on like specific myths or buzzwords.


Just work together, test things out, try things out and have this conversation.


I think that's the key, really.


Yeah.


And I think what I learned is, you know, don't just leave those engineers that aren't interested


alone.


Like, try to have those conversations and try to get them invited in.


And don't just go to them and tell them what to do.


I think, yeah, like I've already solved it.


I already know what to do.


But yeah, just have, I mean, if you already know what to do, just go to them and say,


hey, look, I'm seeing this thing.


What do you think?


I mean, this is what I'm thinking might be the solution.


You know, what do you think?


Or what do you think the solution is and see if they have the same.


Also allows the developers to learn themselves because next time you might not even have


to go to them and tell them about it because they spot it in the development process.


If they know like, oh, so that's a problem.


Oh, that's something that we need to avoid.


Nice.


And then they might actually factor that in the next time they build something like that.


Yeah, I like that.


It's a win-win.


That's my, I have four pillars and one of them is mitigation.


And that's the technical SEO is to get to a point where companies and the engineering


teams are actually not, you know, like releasing stuff without all those three, you know, redirects


or those, you know, the 301s or 302s or the redirect chains.


Like the code is they're actually looking for SEO fixes before they're launching anything.


And then you don't even really have to do anything as an SEO.


But yeah.


What are the other three pillars?


So we have mitigation.


Oh gosh, I shouldn't have brought it up.


You brought it up for yourself.


Yeah, so mitigation is one and that's the technical SEO.


And it is partnerships or relationships with others across the organization.


And that includes engineering of course.


But it's also, like I said, other teams you're under scrutiny, right?


Another one is ta...


Oh, sorry.


Another one is analytics.


So always being able to measure everything you do.


And I think that helps with a lot of the relationship building too, right?


Like if you launch something, you should be able to say, you know, what is my...


I'm successful or I'm not.


Yeah.


What's before you launch it, what do you think your impact is going to be?


And you can say it in ranking position or you can say it in number of impressions or


you can say it in, you know, more eyes on the page or click through rate, however it


is.


But you should always be able to measure it and, you know, know what it is before you


launch and then also be able to report on it what it was afterwards.


And then the last one is like product management sort of.


So launching projects, you know, as SEOs, we get lumped in this like constantly working


with other teams to support them.


But there's also a place where we could actually build our own content so we could work with


content teams and we can build pages.


I always end up or companies always end up calling my pages SEO pages.


Groupon has them.


If it works, it works.


Nordstrom has them.


Everybody has them.


And I think I remember them as marketing pages.


But in reality, oftentimes they were SEO pages.


SEO pages, which I kind of, you know, it's got a stigma to it because I don't want come,


you know, I don't want organizations thinking that we're creating pages just for SEO.


We're actually creating pages for the users, you know, at the end of the day or otherwise


they won't show up.


Right.


So.


If the work wants to call them that, that's fine.


But they're user pages as far as I'm concerned.


Fair enough.


Yeah.


Thanks a lot for sharing the four pillars.


That was awesome.


Oh my God.


I learned so much today.


And it was fun too.


Thank you so so much for joining and thanks a lot for the conversation.


This was awesome.


I hope that you enjoyed it as much as I did.


Yes, I did.


I learned a lot too.


I have some takeaways and I'm going to go talk to those engineers.


I don't usually talk to.


That's amazing.


Okay.


In that case, I do hope that our audience enjoyed it as much and took away some bits


and pieces too.


And yeah, thanks a lot and thanks for watching and hope to see you all including you, Jen,


as soon again, hopefully in person at some conferences somewhere.


Maybe who knows with like wild hair again.


Yeah, we might have to.


Yeah.


All right.


Thanks a lot.


Have a great time and bye bye.


Bye.


English Google Webmaster Central office-hours from May 29, 2020

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


Office Hours Hangout.


My name is John Mueller.


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


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


where people can join in and ask any question


around their website and web search.


Bunch of stuff was submitted on YouTube,


again, which is great, a good way to get these questions in.


But as always, if any of you want


to get started with the first question,


you're welcome to jump in now.


Hey, John, can I go first?


Sure, go for it.


All right, so my question is regarding a query site


colon domain name dot com.


So usually when we want to see if that specific page is


indexed in Google other than Search Console


is when I do a site colon query directly on the web,


I see the home page is not coming up,


which was coming up back in the time.


And any time I go back in the Search Console and resubmit it,


I don't.


I see it coming up for 24 hours, like for a day,


and then it disappears.


Surprisingly, that page is still coming up normally


or working fine for one of the competitive keywords.


It's not like it's one of the blacklisted page.


If it was an internal page, I would not


worry because variety of reasons.


But since this is the home page, I don't know,


should I be worried?


And there are no signals in Search Console


that it's showing me an error, AMP version and all looks fine.


Yeah, that's something that comes up every now and then.


But it's not a sign of anything being wrong or anything broken.


The main reason you're seeing this


is that for site queries in particular,


we don't have any defined order that we would show them.


So it's very common that you would see the home page first


or on the first page of a site query, site colon results.


But it's not always the case.


And it's not a sign that there's anything wrong with the website


or anything kind of blocked or, I don't know,


otherwise problematic.


So if it's ranking normally, I think you're OK.


Even though it doesn't appear at all in all the pages, I mean.


really meant as a comprehensive list of all the pages


that we have indexed.


And since it's an artificial query,


we don't have any kind of defined order


for the site colon results.


So nothing to worry at all.


It's just completely natural to have the home page missing


in it.


Yeah, I mean, on the one hand, for site colon query,


that's something that happens every now and then.


It sometimes also happens that even within a website,


some other page is seen as a primary page for the website.


So even just from the point of view,


what is your primary page, sometimes that's


not necessarily the home page because, I don't know,


a variety of reasons.


Maybe some product that you have is what your whole company is


known for.


And that's some subpart of your website.


Got it.


OK, thanks.


Cool.


I had a question.


A lot of people who are doing personalization now


are talking about adaptive content for their,


for example, their mobile home page versus their desktop home


page.


And with mobile indexing, how does Google


feel about adaptive content where


the content on the mobile version


doesn't have a lot of content?


Content on the mobile version doesn't necessarily


contain all of the same content that's on the desktop.


Ultimately, that's something that you kind of


have to decide for yourself.


Because from an indexing point of view,


we will index the mobile version of the home page.


And usually, we crawl and index from US-based IP addresses.


So if you're doing adaptive content by country


or by language or by city or something like that,


then that would also play into that.


But essentially, we would index the content that we would see.


And if you show users other content


for other locations or other devices,


that's kind of up to you.


The only problematic case where someone on our side


might get involved is when it gets


into more malicious content, where maybe you show,


I don't know, comic books on the mobile version, which


is the one that we index, and the desktop version


is an adult website or something crazy.


That's something that we don't see very often.


But it can happen every now and then.


But if you're adjusting the content slightly differently,


if you're saying, well, on mobile,


people don't want to read as much,


so we have a shorter version of the page.


And on desktop, we have maybe more links


to PDFs or something like that.


That's completely fine.


Totally up to you.


The only thing to keep in mind is that we'll just


index the mobile version.


So we won't look at the desktop version at all.


If there's something that you want


your site to be known for that's only on the desktop version,


we might not know about it.


Makes sense.


Thank you.


Cool.


Thanks.


I do have a follow-up note on that.


What we have been doing is we'll try and replicate


the same content considering for ranking.


But for a mobile version, we'll probably


add a link called Read More.


So if someone wants to sit down while they're


driving or anything on an iPad or something, they can.


Otherwise, they see a very smaller version


of the same piece of content since that


is what Google is going to consider for ranking.


I don't know if that makes sense, like if it's OK or not.


I mean, from our point of view, that's OK.


I don't know if users always appreciate that,


because lots of people on mobile do


want to see the full content.


But that's ultimately up to you.


So we'll just index the version that you


have on the mobile version.


And if that's all you want to have indexed, that's up to you.


If you prefer to have more indexed,


then make sure that more content is on the mobile version


as well.


All right.


Cool.


OK.


Let me jump into some of the submitted questions.


And if you all have any questions along the way,


feel free to jump in.


Or if there is anything kind of related that comes up,


feel free to bring that up.


Let's see.


I think there's a similar question already, a question


around cloaking in general.


In some situations, we display slightly different content.


For US IPs, for domains with non-English language


to optimize the way that Google indexes our site,


as Googlebot is majorly coming from the US,


do we risk any cloaking penalty with this behavior?


How does Google define or detect cloaking in general?


Is the same IP, the same content,


safe enough of a solution?


So in general, the thing you would need to watch out for


is that you're not serving Google or search


engines specifically different content.


If you're serving all users in the US this content,


that's perfectly fine.


That's the version that we'll index.


If users from other countries see slightly different content,


that's ultimately up to you.


In an ideal world, we would be able to crawl and index


from all of these different countries


and see all of those versions of the content.


But for practical reasons, just crawling the web once


is already pretty hard.


So that's not something that we can easily


expand to all other countries.


So if you're showing content to users in the US


and Google is crawling from the US,


then that's what we would index.


That's not something that we would consider cloaking.


When it comes to cloaking, if the web spam team suspects


there is cloaking happening, then they


have lots of sophisticated means to test that.


So that's kind of something where I suspect


it's not anything you need to worry about if you're


doing this in a reasonable way.


But the web spam team does sometimes


take time to figure out what's actually happening here


and to make sure that it's not causing any problems


in our search results.


And then a question regarding 301 redirects.


For strategic reasons, we would like


to redirect all users coming from IP addresses


from a certain country to a different domain.


Let's say we have domain. or abc.info,


and we redirect every user coming from a Russian IP


to xyz.org.


xyz.org would have canonical pointing to abc.info.


The reason is we want abc.info to rank and xyz.org


to serve visitors from Russia.


Do you see any risks here which might harm


the rankings of abc.info?


In general, this is something that you can do.


I think you probably want to watch out that your users are


also happy with this, because ultimately, if your users learn


that your website is not what they were looking for,


then they'll go elsewhere anyway.


But in general, when it comes to internationalization,


you can have a setup where you have something


like a central home page that redirects users


from different countries to different versions


of your site.


The thing to watch out for, again,


is we will crawl an index from the US.


So if you always redirect US users away


from your Russian content, we would never


recognize that you actually have Russian content, which


might make it hard for you to rank


for all of these Russian keywords, for example.


But in general, this kind of a setup is something you can do.


You can use hreflang to tell us about this


and flag the redirecting page as an x-default page.


And by that, we will generally learn which


versions to show in search.


It's not always guaranteed that we


will show the canonical URL or the one


that you have the rel canonical to.


So if we see lots of signals telling us, actually,


your Russian site is the one that people prefer,


then we might index that URL as your main website.


So for canonicalization, we use a number of different signals.


The redirects help us, the rel canonical helps us,


but we also look at things like links internally and externally,


sitemap files, all of the other signals that we have there.


So that's something just to keep in mind


if you're seeing that the wrong version is being indexed.


What's a typical timeline for large corporate site


to see sitelink search box to be removed from search results?


So I assume this is if you add the no sitelinks.


I don't know what the exact meta tag is called,


but there is a meta tag that you can add that removes the sitelink


search box.


And if you add that to your pages,


then generally over time, we will drop the sitelink search


box for that site.


I don't know how long that takes to be processed.


I do know that if you add the markup to provide


your own sitelink search box within your own website,


that can sometimes take quite a bit of time.


So with some kinds of structured data,


we can pick that up within a couple of days.


With the sitelinks markup, I've seen it sometimes take a month,


maybe a little bit longer.


So sometimes that just takes longer to be processed.


We changed one of our sites, title and description


and content, three weeks ago.


NFL scheduled to the new season.


And at first, Google displayed the new snippet


and ranked the site quite well.


However, after three days, Google


displayed the old snippet and ranked us on page two.


Since then, the snippet and the ranking


are switching about every three days.


Googlebot crawled the site several times since then.


What's the matter here?


I don't know.


It's really hard to say without an example.


This sounds like something that shouldn't


be happening like this.


So if you want to send me some examples of where you're


seeing this happening, Florian, then feel free to do that.


Feel free to ping me on Twitter if you want


or add some more details to the question here.


What's Google's policy on back button hijacking?


Sites like Gear Hungry, once you visit from Google


and click the Back button, they take you to the home page


instead of Google search results.


Is there a penalty for such action, or is it allowed?


It feels kind of sneaky.


So this is something which I certainly


wouldn't recommend doing.


Because if people want to go somewhere,


then it's probably a good idea to let them go there.


I don't think they'd be happier if you just


sent them to your home page.


I am not aware of any specific policies on our side


with regards to back button hijacking.


So I don't know if that's something


that the various Google teams would really worry about there


because it's really something more where


you're annoying your users.


It's not that you're causing problems in search.


Question about EAT and YMYL.


So EAT is Expertise Authority Trustworthiness,


and YMYL is Your Money or Your Life Content.


These are terms from the Google radar guidelines


that we put out.


We're working with news websites.


What tips can you give us about indication of content authors?


Is it really necessary to make pages for each author,


provide big info with photo, bio links to social networks?


I mean, that this really matters that there are


lots of work to do elsewhere.


I think with all kinds of content,


it's not the case that you can say this really matters


and you absolutely must do it.


I do think with a lot of news websites,


especially if you're providing information


that you want people to trust, then this certainly makes sense.


So it's not something where I'd say


it's the same as removing a noindex meta tag on a page


because that's like really an on and off switch.


But if you're improving the content of your site,


that works well for users.


That works well for Google.


So it seems like it's something that could be done.


How to prioritize that versus other things on the website,


that's really hard to do.


That's where you almost need to use your experience


and figure out what works well on your side.


Let's see, we're publishing news articles, or news and articles.


For example, we have 100 new articles every day.


10 of them give us 95% of the organic search traffic,


another 90 go nowhere.


We're afraid that Google can decide our website is


interesting only for 10%.


There's an idea to hide some boring local news


under noindex tag to make the overall quality of all


publishing content better.


What do you think?


In general, we do look at the content on a per page basis,


and we also try to understand the site on an overall basis


to understand how well is this site working.


Is this something that users appreciate


if everything is essentially working the way


that it should be working?


So it's not completely out of the question


to think about all of your content


and think about what you really want to have indexed.


But especially with a news website,


it seems pretty normal that you'd


have a lot of articles that are interesting for a short period


of time that are perhaps more of a snapshot


from a day-to-day basis for a local area.


And it's kind of normal that they


don't become big popular stories on your website.


So from that point of view, I wouldn't necessarily


call those articles low quality articles, for example.


On the other hand, if you're publishing articles from,


I don't know, hundreds of different authors,


and they're from varying quality, and some of them


are really bad, they're kind of hard to read,


they're structured in a bad way, the English is broken,


and some of them are really high quality pieces of art


almost that you're providing, then


creating that kind of a mix on a website


makes it really hard for Google and for users


to understand that actually you do have


a lot of gems on your website that are really fantastic.


So that's the situation where I would go in and say,


we need to provide some kind of quality filtering


or some kind of quality bar ahead of time


so that users and Google can recognize this is really


what I want to be known for.


And these are all things, maybe user-submitted content,


that is something we're publishing because we're


working with these people, but it's not


what we want to be known for.


Then that's a situation where you might say,


maybe I'll put no index on these,


or maybe I'll initially put no index on these


until I see that actually they're doing really well.


So for that, I could see it making sense


that you provide some kind of quality filtering.


But if it's a news website where kind of by definition,


you have a variety of different articles,


they're all well-written, they're reasonable,


just the topics aren't that interesting for the long run,


that's kind of normal.


That's not something where I'd say


you need to block that from being indexed because it's not


low-quality content.


It's just less popular content.


In my Search Console account, I see a lot of URLs


in the coverage report that returns status code 500.


However, there are URLs that existed


by the buttons for sharing the page on social networks


under the path social network slash Facebook slash ID,


for example.


But those URLs are not returning a server error,


but a temporary 302 redirect towards a social network.


How can I correct these errors when they're really not


from our site?


OK, so that sounds like these errors are


things that happen when you redirect to an external site.


And there are things where essentially on your site,


everything is working well, and the external site


is maybe serving a 500 error or serving something else where,


for whatever reason, it's not returning a normal 200 result.


That's something that essentially


doesn't bother us that much.


We will flag it in Search Console


because it is something where we try


to crawl a URL on your site, and we ended up


on an error page, which could be kind of a sign


that there's something weird happening.


But if you're aware of this, then that's


generally not a problem.


What you could do is perhaps block these by robots.txt,


these URLs on your site, because those are not


things that really need to be crawled and indexed.


So from that point of view, you can prevent that error


from appearing in the crawl errors


by blocking them by robots.txt.


In general, I don't think that would


cause any problems overall.


So that's probably the direction that I would go there.


What might happen is that if you do


a site query for these specific directories on your site,


then maybe we would show these URLs


without a title, without a description,


because they're blocked by robots.txt.


But if you do normal queries for your website,


then these aren't things that would be showing up


in the normal search results.


So that's not something you'd really need to worry about.


Does Google ever use historic data


when deciding how to rank a site,


or do the algorithms only look at the present and most recent


snapshots?


I mean, can a website build up goodwill


over a period of time, which may help it?


Yes.


In some ways, that can happen.


So in particular, if you have a website that


has existed for a very long period of time,


then that's something where the whole ecosystem


around the website will have evolved around that.


And there'll be links from all over the web


for a longer period of time.


And when we look at that website,


we will see the current snapshot of the website, what


we recently crawled, but all of these signals that have


been collected over the years.


So that's something that can definitely play a role.


There are also signals within search specific to a website


that might be collected over time.


The ones that I've run into a few times


are generally around adult content.


So that's something where if a website for a longer


period of time provided adult content,


then our algorithms might start learning


that actually we need to filter this using Safe Search.


And if that website were to completely


revamp the whole website and suddenly, I don't know,


a non-adult website, then it can happen


that for a period of time, those Safe Search algorithms


will try to stay on the safer side


and might still filter that site in Safe Search for a while.


So that's something that can sometimes take a bit of time


to settle down.


Similarly, with some of the quality algorithms,


it can also take a bit of time to kind of adjust from one


state to another state.


So if you significantly improve your website,


then it's not that from one crawl to the next crawl


we'll say, oh, this is a fantastic website now.


It's something where probably over the course of a year,


maybe sometimes even longer, our algorithms


have to learn that actually this is a much better website


than we thought initially.


And we can treat that a little bit better in the search


results over time.


So that's something where essentially the historic data


that you mentioned there is not historic in the sense


that it's like 10-years-old data.


But it's more that sometimes the status of things, maybe a year


or even two years ago, can still play into how a website is


ranked in search now.


Regarding one point I came across recently,


does the link pass page rank on a page


that I have temporarily removed in Search Console?


Yes.


So temporary removal in Search Console


does not change anything about indexing of a page.


It really just hides that page in the search results.


So that's something where essentially from our side,


we want to provide a way to make it possible for people


to remove things as quickly as possible.


And if we needed to go through the whole indexing system


to do that, that would take quite a bit of time.


So the temporary removal essentially just


hides it in the search results.


It doesn't change anything from the indexing side.


For the indexing side, we still need


to recrawl and re-index that page.


If that page is now gone, if it has a no index meta tag on it,


then we'll be able to take that into account the next time we


have reprocessed that page.


And then the temporary removal expires, for example.


So similarly, if you add a link to a page,


and this page is something that is temporarily


removed in Search Console, then when we recrawl that page,


we will find that link.


We will treat that as a normal link, as we would


any other link in indexing.


And we might crawl the page that is linked,


or we might pass some signals to the page that


is linked from there.


Can I use a 301 domain after a year or so?


And what amount of page rank will transfer?


Not quite sure how you mean that.


But in general, if you're moving from one domain to another,


then 301 redirect is the right way to deal with that.


And with a clean 301 redirect, if you're


redirecting every page one by one,


and there's nothing left on the old website,


then we will try to pass all of the signals as much as possible.


And the signals include page rank.


We use a lot of other signals, though.


So it's really not just page rank


that is being processed there.


If you wait with this redirect, if you do a partial redirect


from the website, if you do a redirect in a way that


makes it hard for us to recognize


that this is a one-to-one site move,


then that makes it a lot harder for us to process those signals


and to forward them on.


That means, essentially, what usually happens


is it takes a lot longer, and the outcome is not so clearly


defined.


So if you're redirecting a part of a website,


then we essentially have to reprocess both of those,


the old and the new website, and try


to figure out what the new status of this website


should be.


So it's not that we would just pass everything on.


We kind of have to recalculate everything.


Similarly, I think maybe this question goes in a direction


of, what if you only start setting up


the redirect a year after you actually do the site move?


For the most part, we will try to recognize site moves even


without a clear redirect, but it's a lot harder.


And if you wait a year to set up this redirect,


then it's kind of a long time already,


and things have already settled down a little bit.


And what the final state there will be


is really hard to predict.


So I think adding a redirect later,


if you forgot that with a site move, is always a good idea.


If you wait very long, like a year,


then I don't know what effect you would effectively


get from that.


I'm trying to move my landing page from WordPress


to a new React framework server on server-side rendered page.


The new React page gets an almost perfect score


in every category in the DevTools audit.


It scores far better than the WordPress page.


I've copied almost all the content word for word


from the WordPress site over to the new React site.


I ended up changing my name servers from AWS GoDaddy to Zite


and ended up losing my rankings.


I'd love to know how to migrate a site properly,


and not sure what the main problem is


with moving things over.


Is it name server or DNS records?


Is it different?


WordPress adds a lot of metadata and has a lot of plugins.


Yeah, I don't know.


So just from a purely technical point of view,


taking aside moving from WordPress to a React framework,


it sounds like you're essentially


restructuring your website.


You're revamping the whole website.


And that's probably the part where our systems got confused


or where our systems are running into issues.


So it's less a matter of what technical infrastructure


you're moving across, but more that you essentially


have a new website.


So the changing of the name servers,


I would see that as totally inconsequential.


That's something, unless the new name servers are completely


unreachable by Google, then that's totally irrelevant.


But what probably plays a role here


is the change of the site itself.


So copying the content word for word is one thing,


but there's a lot more on a website


rather than just the words on a page.


There are things like titles and headings on a page.


There are images, the way the images are embedded.


There's the design of the page itself, the internal linking,


the navigation.


All of that plays into us understanding what this website


is about and how the individual pages are


connected to each other.


So that's something where sometimes if you


take the content and just copy it word for word


to something else, then we can still understand


this is the same content.


But we might have trouble understanding


the impetus of the individual pieces of content.


Things, like I mentioned, like the headings


or the elements that are somehow otherwise kind of emphasized


within the pages.


So that's something where I could


imagine you might be running into problems there.


The other thing is depending on what all you changed,


if you change the URLs themselves,


then you'd also need to set up redirects between the old URLs


and the new ones.


Sometimes if you're migrating from one CMS to another CMS,


these URLs change.


Sometimes you can keep them the same.


If you can keep them the same, that's an optimal situation.


If they change, then we essentially


have to reprocess the whole website again.


The internal linking is the other part


that I briefly mentioned, things like the navigation,


how you link the various pages and parts of your website


together with categories and higher level pages


and maybe snippets and overviews, all of those things,


that also plays a role in with how we


can index your pages properly.


So that's something where I'd also watch out for that.


The other thing that might be playing a role


is with regards to moving from a static HTML version


to a more JavaScript-based version.


It sounds like you're doing server-side rendering, which


would mean that the new website is also a static HTML page when


we try to crawl and index it, which means it's


more like the same situation.


But at the same time, if you're doing


this kind of server-side rendering for Google


specifically, then there are lots of opportunities


for things to go wrong that you might not be seeing as a user.


So especially if you're doing something fancy for Google


in that regard, then it's something where you just


have to check a lot more things.


So my recommendation here would be


to try to figure out the differences as quickly


as possible.


So if you still have a backup of the WordPress site,


then maybe install that on a different server


somewhere so that you can crawl the whole website.


You can compare it on a page-by-page basis


with the new website so that maybe using some third-party


crawling tool, figure out, is the internal linking the same?


Are the same URLs being used before and afterwards?


If not, is that something that you can still


tweak on your new website to make it more the same?


How do the individual pages look?


Do they have headings, titles?


All of these things, do they match?


That's something that also plays a little bit of a role there.


Let's see, the metadata that you mentioned,


a lot of the metadata on pages are things that we can ignore.


Sometimes they're irrelevant for social media sites,


like finding what is a thumbnail image that


should be shown for this page.


Those are things probably worth adding anyway.


But that's not something that we would


use for indexing and ranking.


There are some other types of metadata on pages,


though, that we would use, especially if it's something


that we would pick up for structured data


or if it's something that we would show maybe


as a description in the search results page.


Both the description and structured data


are not things that we would use for ranking, though.


But you might see that in that your search results entry looks


a little bit different.


And if it looks a little bit different,


maybe users respond to it a little bit differently.


Yeah, wow, so many things to watch out for.


But my general recommendation with this kind of situation


is to try to understand exactly what's happening


as quickly as possible.


Because the longer you let it sit


in this state of being different,


and you're not sure exactly why it's behaving differently,


the more likely our systems will just learn your new website


and say, well, it's a different website.


We should rank it differently, but we've


learned how to deal with it.


Whereas if you can fix these things as quickly as possible,


then we can understand a little bit better, oh, wait,


this just tweaked slightly.


We can take all of the existing signals that we have


and apply them to the new website.


Kind of weird.


Go for it.


Sorry, go ahead, Amanda, first.


Yeah, so it's still there.


It's just kind of hidden away with the old tools


at the moment.


But it is something that the team


is looking into, how we can migrate that


to the new infrastructure.


So I hope that doesn't go away.


Because like you mentioned, a lot of times


you don't have the ability to just go out and get


all of the code changed.


And it's sometimes really useful to be


able to prove to people that actually it's worthwhile doing.


So that's something where I think


there are some options there.


Another thing that we notice is with Google Tag Manager,


you can sometimes also do similar things


in that you can add structured data


and let that be picked up like that.


It's a little bit more complicated,


but it might also be an option.


The question I had around the site move is one of,


like any other SEO guys out there,


have burnt hands changing the website, right?


I don't think I have yet to see a migration that


goes smooth.


If you're ranked on top 10, you're


getting decent attraction.


You want to make it mobile friendly.


You always want to do the next step.


So is there any plan from Google to provide


some kind of assistance in the search console


or somehow saying, hey, we are migrating a new site.


So don't burn the signals.


We'll keep the same URLs.


Obviously, when you move from one CMS to the other,


you see an example of CMS or a different server


slash new code, you are going to expect a complete design


change.


The user can make sure the UI can remain the same


or the link slash content.


But there is so much that runs behind it.


And if Google is going to reprocess it,


it's like a new marriage after everything.


It's like start all over again.


So is Google trying to not promote users


to come out with new websites and let's


give a better experience?


Or how can you help us better, the whole community?


Yeah, good question.


I think the general situation with a lot of these site


revamps is also that you're trying to improve things.


So that's something where I think sometimes it


does make sense to rethink the signals


because these signals can also improve in a positive way.


It's definitely not the case that every site migration


that you do will always result in negative signals


and things getting lost because a lot of times


you will be able to work on a website


and you recognize all of these problems.


And then you create a new structure, a new website,


and it doesn't have any of these problems.


And you want that work that you worked on to be reflected well


in search as well.


So that's something where I don't know.


It's kind of tricky to say that we should keep the signals


and not let a site be able to profit from the improvements


there.


But it is always tricky because I


think the part that always makes it hard for me when talking


about this is that it's hard to judge ahead of time what


the actual effects will be.


And especially if you don't have a lot of experience around SEO,


then it's really hard to judge what will actually happen


when we switch over.


And the other thing that I always see as well


is that sometimes these kind of site revamps


are done by people who don't actually know much about SEO,


who are maybe the developers or maybe the design team


or marketing team that says, oh, we need a new website.


We will outsource a new website.


It looks really nice.


It's really fancy.


And they don't realize that all of these changes


could potentially affect the kind of search visibility


as well.


Things like removing text and putting it into images,


it looks the same in a browser, but it reacts very differently.


And as an SEO, when you look at this new site, you say, well,


this is a problem.


This is something that we need to fix.


Yeah, it looks weird with someone mentioned


that people are having trouble getting in.


I don't know.


It's kind of weird.


Usually, I get a little pop-up saying


that people want to get let in.


But that doesn't seem to be happening at the moment.


Hard for me to figure out what exactly is stuck.


So there are no plans from Google


to help with this problem, right?


From webmaster team, I guess.


So I think the one thing that we've been looking at


is specifically for site moves to have at least some kind


of a progress indicator that lets you know that when Google


has finished reprocessing your site migration, your site


move setup, that I think makes it a little bit easier


to understand when you've reached the final state where


it's not that you're in this uncertainty of,


do we just need to wait for Google to figure it out?


Or is there actually something that you


need to do differently to move into a different situation?


Yeah.


SPEAKER 2 Yeah, I think that would be very helpful,


because when to panic, right?


Wait, Google is still working on it.


Give it six months.


That's fine.


The wait is fine as long as we know it's in transition


or it's progressing.


And going back to the other thing


that we talked that you discussed earlier


from one of the other user about content.


So I had a site.


The content wasn't changed in five years, seven years.


Certainly the guy is free because of this pandemic.


He's like, let me revamp the content.


I haven't changed in a while.


And he didn't see any positive result.


And I kept telling him content is the key.


He's like, it didn't change anything.


I'm like, I guess we need to wait.


And I don't know if there is a temporary removal, just


like a new, hey, I can indicate somewhere in the search


console, this is a new page.


And if Google wants to take six months to settle down,


it's fine.


It would be nice to see the progress, like you said,


site movers if you tag individual page.


I don't know if that's even possible.


But yeah.


Yeah.


Yeah, I think it's always a bit tricky


because there are always some things that


change on a website.


And it's hard to understand when you kind of just


need to let the systems figure it out on a website


or if there's something that you need to change yourself.


Now, I don't know.


Good point.


I think that's something we can certainly think about and see


if there is something that we can do there.


One of the things that we did add in Search Console,


with the new version of Search Console,


is the general concept of being able to validate fixes.


Maybe that's something that we could implement there


in general, where you can say, well, I've revamped my content.


I would like Search Console to kind of validate the changes


that I've made.


With the validation process in Search Console, at the moment,


it's tied to issues that we recognize,


which are usually technical issues, like structured data


or with indexing.


And what will happen there is we will


try to recrawl and reprocess the website a little bit faster


so that we can reflect that new state in the index


a little bit quicker.


So maybe that's something that we could also


expand to more kind of content or revamped situations as well.


SPEAKER 2


Yeah, that's exactly what.


So unless the user checks in manually,


or the team, from the company or someone to say,


hey, this is new.


And then you say, all right, I'm going to do it again.


And I'm also going to show the progress this time,


or something.


Yeah.


Thanks.


Regarding the people that can't seem to get in,


I don't know why that seems stuck.


But I suspect maybe it's tied to the recording that's running.


So once we pause the recording, we'll


see if that starts working again.


I don't see any other option of adding people


unless I have their email addresses, which


I don't really have any.


Sorry, I posted that.


I can get them to try.


They tried a few times.


Do you want me to get them to try now?


Yeah, OK.


Well, maybe we'll just pause the recording


and keep it shorter and see if more people can join in.


All right.


Thanks for watching.


And if you found this useful, feel


free to hang around on the channel.


And maybe we'll see each other again a little bit later.


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

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


Office Hours Hangout.


My name is John Mueller.


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


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


where folks can join in and ask any question


around their website and web search.


And we'll try to find an answer.


A whole bunch of things were submitted already.


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


feel free to jump on in.


Hi, John.


Hi.


I have a few questions, very small, actually.


So first question is about alt text for the image.


So if I have a web page and I have a lot of images


on the web page, if some of the image


do not have the alt text, will it


affect my organic ranking of the web page,


or will it only affect my image ranking?


We treat the text in an alt attribute


as both a part of the page, so kind of for web search


for that page, as well as more information about the image


itself for image search.


So if the text in your alt attribute


is something that's completely unique to the whole page,


then we wouldn't have that if you don't otherwise


give us that information.


But usually, if it's an image on a page


and the image has a little bit more context


to the rest of the page, then that's just extra information.


It's not something that's critical for web search.


And the next question is, some of our clients,


they have some tagline or slogan of their business.


They put it on every page.


Usually, they put it above the footer,


so that text appear on every page.


Now, sometimes those sentence have the keyword.


If we use the keyword for interlinking,


is it bad, because that text is appearing on every page?


I don't think that's a problem.


That's a completely normal kind of website structure,


so I don't see an issue with that.


OK, the last question.


This is also about the image.


So if I have a blog post, it is about a base three file places.


And I have added a featured image,


which is the file place image.


What should be the alt attribute?


Should it be the three base file places, or just file place?


The alt attribute should be an alternate text


for the image itself.


So it's not like a heading on a page or anything like that,


but it should be kind of describing the image itself.


Thank you.


Sure.


I'll go next.


Hi.


All right.


So I inherited a blog post from my company,


and the template on Squarespace makes every single H1


like the site title.


So there's like 500 blog posts with identical H1s.


And then the blog post title are H2s.


Is this something I should address with them?


Because I'd have to ask them to change the template,


and it takes a bit of work.


So is that really bad that everyone has signed?


It's not terrible.


So the H1 heading gives us a little bit more information


to kind of understand the page better.


But it's really common for sites to have kind of this setup


where you have the same H1 heading on all pages.


It's not the best setup, so it's something that at some point


it might make sense to look into.


If you're talking with them about the template anyway,


then this is something that's probably worth fixing.


But it's probably not going to visibly affect


your site's ranking.


So it's kind of like a best practice that's good to do,


but not something that is critical for a site.


OK.


And if I put an H1 text in the body, will that help?


That works, too.


Yeah.


That helps us, too.


So it's not that there's a limit of one H1 tag per page.


So if we find multiple H1 tags, we'll make do with that.


And does it matter which one will kind of like


float to the top, the one I put in or the templated one?


Not really, no.


All right, thank you.


Sure.


All right.


Any other questions before we jump into the submitted ones?


Let's see.


I think your question is actually


the first one on the list, the identical H1s.


So we can skip that one.


The next one is about hreflang.


We're an international brand, and we have five sites


in Latin America.


All have pretty similar content, and we do use hreflang tags.


We have another site in the US that serves Spanish customers.


What we recently noticed is the fact


that for the brand name in Peru, the Peru home page no longer


ranks, and the US Spanish version does.


This only happens in Peru, and only


for the brand name for the product pages, it works fine.


What could be the cause?


Having users land on a different market


interferes with the brand experience


that we wanted to give visitors.


So I think looking at the last aspect there with regards to,


it's like sometimes people get to the wrong page,


that's something you can never completely exclude.


So it's always possible that through some means,


be it through search or be it through clicking on links,


people will land on the wrong version of your site.


So you need to have some kind of a backup on your site,


especially if you strongly care about the differences


between the individual regions or language versions


that you have.


So usually what I recommend is if you


can recognize that someone is on the wrong version of your site,


then show a small banner on top and say,


hey, it looks like you're from this country,


or you're looking for this language content.


We have this content here.


That makes it possible for everyone


to go to the optimal version of the site,


but at the same time allows Googlebot


to crawl your website normally because it doesn't automatically


get redirected to the version that you think


Googlebot would need to see.


So some kind of a banner would always make sense.


With regards to the wrong Spanish version showing,


that's probably due to the content being


seen in our systems as being identical or almost identical.


What happens then is we fold the versions together for indexing.


We try to use the hreflang to show the right URL in the search


results, but we fold them together for indexing.


And you might see some effects of that,


both in Search Console in the reporting,


because we report on the canonical URLs


in Search Console.


And you might see some times where


we show the wrong URL in the search results


because we couldn't work it out with the hreflang properly.


But that's something where what I'd recommend doing here,


especially if this is your home page and not


one of the many product pages that you also have,


I'd try to make sure that the content on these pages


is significantly different so that our systems don't


assume that they can fold this content together.


So that's generally the direction I would head there.


So on the one hand, for your question in general,


make sure the pages are significantly different.


And then with regards to people landing on the wrong version


anyway, make sure you have some kind of a banner as a backup.


I'm working on a website where less than 1% of the content


can be considered erotic.


However, 99% of the queries shown in Search Console


are erotic queries.


We wonder if our website is tagged as an erotic website


because we would like to have traffic on the full website,


or should we delete or no index our small amount


of erotic content.


So in general, this is something that


can be a little bit confusing in regards to the queries


that you see.


I'm assuming what is happening here


is that there are just a lot of people searching


for these maybe erotic keywords, and your site happens


to be ranking for those keywords.


So that's why a lot of people find your site there.


But that doesn't mean that your site is not


visible for other queries.


So even if you were to remove that content completely,


that would not affect how the rest of your site


would rank in the search results.


It's a little bit different if a significant amount


of your site's content would be considered for adults.


Then in cases like that, our safe search algorithms


might kick in, and they might say,


well, perhaps the whole website should


be filtered by a safe search.


And then that would be a case where that erotic content


that you have would be affecting the rest of your content.


But if it's really a tiny amount of the content on your website,


then that's not something that would generally


be happening there.


So from my point of view, you wouldn't


need to remove that content.


It just makes it sometimes weird to look at the statistics,


because there are lots of people searching


for this small amount of content and few people searching


for the rest of your content.


But removing that small amount of content


wouldn't mean that you would have more people finding


your site for the other queries.


Everyone knows about the source-medium combinations,


Google CPC and Google Organic.


Does anyone know what is Google slash web search?


So this looks like a Google Analytics question,


and I really don't know what I can


say about Google Analytics.


So I'd recommend checking in with their help forum


or checking in with them on Twitter


to try to get this answered.


I really don't know how that would be compiled there.


We think there's a serious bug in Google Discover in Sweden.


I think we talked about this one last time, too.


I passed this on to the Google Discover team,


I think, last week or the week before last,


when this came up last.


But I don't know what the status is there.


Usually, with these kind of things,


we pass them on to the appropriate team,


and they try to prioritize them appropriately.


It's not always the case that they'll just


go off and fix it completely or that they even


agree that there is actually an issue here.


But I can double check with the team


here to see what's up with that.


In the developer docs, Google says an organization logo


should be a minimum size of 112 by 112 pixels.


Considering the number of potential uses for the image,


would larger dimensions, maybe 1,000 by 1,000,


be a best practice?


Also, does it matter whether the image is square or rectangular?


To be honest, I don't know the specifics of this kind of logo


and the markup and its usage.


But if we have a minimum image size,


you're always welcome to provide larger image size.


So from that point of view, if you


think that it makes sense to have a larger image,


that's totally up to you.


With regards to square versus rectangle,


I would double check the documentation here


because there are some kinds of images


where we need to have a certain image


ratio and other types of images where we don't really


have any guidelines on what image ratio it should be.


For the cases where we don't have


any guidelines on the image ratio,


I would check to see how those images are actually


used in search.


Sometimes we use more rectangular images in search.


And in that case, it probably makes sense.


But if you see that we're using a square image


and you provide a rectangle, then we kind of


have to fill things out or crop kind


of the central part of the image.


So I'd double check that there.


Question about organization schema markup.


What's the difference between an ID


and the URL of an organization?


And when should we use a different ID


for the same organization?


I don't actually know.


So good question.


I'll need to try to find something here.


What might be useful in the meantime


is to post this in the Webmaster Help Forum.


I believe there's a separate section specifically


for structured data and rich results.


And see if someone there has any input on this specifically.


Are backlinks important in ranking factors?


Because nowadays, 80% to 90% of websites


are buying backlinks, which I think is very unethical.


But these websites are also ranking on the first page.


Why is that?


So we do use links in our ranking algorithms.


We use a ton of other factors as well.


So it's not the case that links is the one thing that


will make your website go up in the search results, regardless


of what other people do.


This is something where we also see


that a lot of sites do things that aren't really


necessary for their website in web search.


They'll go off and buy a ton of links,


and then we ignore all of those links.


So just because you're seeing people doing something


that looks kind of weird doesn't necessarily


mean that they're actually profiting


from that in the sense that there are lots of reasons


why sites can rank in the search results,


and it doesn't necessarily have to do with anything sneaky


that they're doing.


So we get this question around links.


We get this question around keyword stuffing,


around hidden text.


All of these aspects come up regularly.


And in pretty much all of the cases


that I've looked into where we work together


with the Web Jam team and the search quality team


to double check why these sites are ranking,


it's pretty much always because of other things.


And on the one hand, that can be kind of frustrating


if you're seeing people doing crazy stuff


and you're doing normal things and not showing up


in the search results.


On the other hand, that's also useful because our systems


are used to people making mistakes,


and they try to do the right thing regardless.


So if you went off and bought links in the past


because someone told you to do it,


and you didn't realize that was kind of a useless thing to do,


then it's not going to be that we're


going to remove your website completely from web search.


It might still appear in the normal search results


based on the other things that you're doing really well.


If your e-commerce site's organic traffic and keywords


have dropped by more than 90% after a Google algorithm


update, what optimization would you do?


That's really hard to say.


So that's something where I don't


have any specific guidelines on what exactly you would


need to do because there are lots of reasons why


the site might drop in search results.


It might be due to something we changed in our algorithms.


It might also be due to something technical


on the website itself.


So this is something where if you're really not


sure which direction to go, I would


go to the Webmaster Help forums and try


to get some help from other people who've


run into similar situations who can give you some tips on what


to double check.


Sometimes there are simple technical things you can do.


Sometimes it takes kind of a rethinking


of the website in general, which takes a long time


and is really not that easy to do.


Question about pagination.


Is it bad for SEO or seen as duplicate content


to have the same copy and image on the top of every page


in a paginated series?


For example, two examples here.


In this instance, the URL parameters for page


have been set in Search Console to paginate and let


Googlebot decide.


Finally, should the H1s and page titles also


be different for paginated pages to reflect the page number?


So headings and page titles kind of help us


with paginated series to understand that these series


belong together.


So if they're the same or if you have something


like a number in the headings and titles,


then that helps us a little bit.


We can also generally figure this out


through the links on the page where we see,


well, this one has a link to the next page


and it has a link to the previous page.


Then maybe that's a part of a series


that we can hold together.


With regards to duplicate content,


with regards to the header on a page,


the general layout of a page like this,


that's something you generally don't need to worry about.


So we would recognize this as duplicate content,


but it's not that we would demote the website because


of that.


It's more that we recognize there


are some blocks of text on this page that are the same


as other pages on your website.


So if anyone is looking specifically for something


within that block of text, then that's


something where we try to find the most appropriate version


of that piece of content on your website.


But it's not the case that we would say,


well, this piece of text is duplicated multiple times,


so we will treat this website as being bad.


So from that point of view, usually


this kind of pagination where you have blocks of text


or images that are shared across different versions,


that's perfectly fine.


I wonder whether Google algorithms transfer authority


if there are more than four redirects to one page.


Once we set it to HTTPS, it was a huge fall in search traffic.


So I found that there are many redirects from old domains


and redirects to HTTPS might be the fifth or the sixth one.


I also found only one answer to this.


Google uses the first four redirects for SEO.


So this is kind of a tricky thing in the sense


that, on the one hand, you're correct.


We follow a limited number of redirects.


However, we follow a limited number of redirects


during the crawl of one page.


So if we want to access one URL, then we


will try to follow those redirects until we


get to the final state.


And during one crawl cycle, we'll


follow, I believe, up to five redirects before we say, OK,


we couldn't reach the final page.


It seems to be redirecting a bunch of times.


We will check again maybe tomorrow.


And then we'll start again tomorrow from that final state


that we reach to see how many redirects


we can follow from there.


So it's not the case that a website would be demoted


because it has a lot of redirects.


It's just that if we see a lot of redirects


during the crawling of URLs that we try to crawl,


then it might be that it takes a little bit longer for us


to actually reach the content.


So it's always a good practice to redirect as quickly


as possible to the final state.


Then you don't have to worry about this.


It also makes it faster for users.


But once we figured out what the final URL should


be by following all of these redirects,


we'll generally focus on that one anyway.


So the next time we try to crawl something from your website,


instead of starting at the beginning of all


of these redirects, we'll start at the end and say,


well, the last time the content was here,


maybe this is where the content will be.


And we'll try to crawl from that specific place.


So with that in mind, if you're shifting from HTTP to HTTPS,


and you have some old domains, and you have a redirect


from www to non-www, and all of these


could theoretically be lined up, it's


not the case that your website will rank worse because


of that, because we'll follow all of these redirects.


We'll remember that final URL.


And we'll focus on that final URL for the future,


rather than trying to follow all of these redirects


all the time.


So it's kind of like a one-time thing, where everything


is a little bit slow until we follow the redirects.


But the next day or the next time we crawl,


we'll start where we actually find content.


How do you see SEO change in the next five years?


Oh my gosh, I have no idea.


It feels like sometimes very little changes from time


to time, but sometimes there are bigger changes as well.


I could probably spend an hour discussing various ways


that SEO might change.


I think, in general, SEO is not going to go away.


So don't worry about that.


URLs are going to continue to matter,


having the proper technical setup on a website that


continues to be very important.


And on the other hand, things that will always change as well


is the user expectations.


And when the user expectations change,


then it's a matter of also making sure


that your website remains relevant for the new user's


expectations.


But from a technical point of view,


I think there are a lot of things that essentially


will continue to work, because it's a good basis.


There's much debate around Google's interpretation


of schema and thus the inclusion of rich results in rich snippets


into results.


We spend significant time adding schema markup to a site


with little to no results.


How does one try and influence this process a little better


so that we can best serve our customer


needs in the search results?


The industry, these specific search terms,


has seen mass removal of snippets


from the Google search results.


They've seen mass removal of snippets for many terms


they historically existed for.


I have no idea which industry you're talking about,


so that's really hard to say.


In general, there are a few things


that we do care about with regards


to rich results in general.


On the one hand, we want to provide something


in the search results that gives the user a little bit


of a preview of what they would see when they go to a page


so that they can easier understand which


pages are relevant for them.


So if you're doing a search for something


and the rich result that we show is something


that provides value to the user and makes it


so that they understand why your page is the best one that they


should go and visit, then that's something we'd like to show.


On the other hand, if the rich results that you're providing


just add extra bling to a search result,


kind of like click here, click here,


rather than actually giving the user more information about why


this specific page is more important,


then that's something we probably wouldn't want to show.


So that's kind of the general idea there.


And that's something that can evolve over time,


because we will have newer rich results types in the search


results over time.


And people will see these and say, oh, well,


I can highlight the value of my content there better,


and that's kind of a good use.


And there will also be people that say, well,


I can take advantage of this extra room in the search


results by drawing more attention to my site


without actually giving more information about why


this page is more useful.


And people will try to do sneaky stuff along those lines.


And that's something that I think


will continue to evolve in that people will try new things out.


We will launch new features in the search results.


We'll see where it makes sense and where it just


adds extra clutter in the search results.


And these kind of things will continue to change.


So that's something where we do spend a lot of time discussing


the policies around this.


We try to make the policies around rich results


as transparent as possible, because it's not


our idea to make it hard to appear well in search.


But rather, we want to give you some information about where


we think it makes sense to add extra value so that users


understand why your page is the one that they should be going


to.


What is quality content in Google's eyes?


If two people are writing on the same content,


it's possible that they have a different opinion


on the same thing.


Then how does Google decide which one is better?


Because I'm seeing that Google is sharing reviews and locality,


but some people buy things and the other people don't.


I'm not really sure where this question goes.


With regards to quality content in general,


this is something where you, as the site owner,


probably know a lot more about what


is actually quality content for your specific kind of site.


So that's something where I wouldn't worry too much


about what Google thinks about quality content,


but rather, you need to show that you really


have something that's unique and compelling and of high quality.


So instead of trying to work back


how Google's algorithms might be working,


I would recommend trying to figure out


what your users are actually thinking


and doing things like user studies,


inviting a bunch of people to your office


or virtually to show them something new


that you're providing on your website


and ask them really hard questions where sometimes


the answer might be, we don't like your website,


or we were confused by your website,


or we don't like the color of your logo or something.


But this is the hard feedback that's really important to get.


And a lot of times, these are things


that you might not agree with, but if all of your users


are saying this, then maybe that's something


that you need to consider as well.


This is something we do all the time as well.


We do A, B tests in the search results all the time


to see how can we make sure that we continue


to provide relevant results, even when


users' needs and expectations continue to change over time.


We do user studies in Search Console as well,


where we try new features out and try


to see which ways users are either confused


by these new features or which way they can work better


with these new features.


These are things you always need to do,


and you should focus on your users


rather than on how Google's algorithms might currently


be trying to figure out what is high-quality content.


One of the other reasons why you shouldn't be focusing


on how Google's algorithms figure this out


is that Google's algorithms will also continue to evolve,


and will also continue to focus on the users


and see what they need.


And if you're just focusing on Google's algorithms,


you're always a step behind.


So try to focus on your users and figure out


what their needs are and what you


can do to provide something that is really unique and compelling


and different from everyone else in that area


that you're active in.


A few questions around breadcrumb markup.


I noticed Google will drop the final page


from the breadcrumb trail displayed in the search results.


I think we do, yeah.


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 users on a page?


Even if the page title is included in schema markup,


will an excessive character length


cause Google to drop the final page title in a breadcrumb


trail in the search results?


I think we looked at this last time, actually,


or maybe in one of the other Hangouts.


But in general, I'm not sure if we do this by policy


or if it's just kind of the way our algorithms are set up


at the moment.


But if the last breadcrumb trail is actually


a page that is being linked to, like the page that's


shown in the search results, it doesn't really make sense


to show that twice.


So that's something where I think kind of just


from a usability point of view, dropping the last item,


if that's the page that it's actually on,


is kind of reasonable.


It's not so much a matter of the character length there.


But depending on the type of search results,


obviously, there is limited space available.


So it might happen that we have to cut things off at the end


or kind of cut things out in the middle.


And you'll see those kind of dot, dot, dots in the breadcrumb


trail along the way there.


But that's something that I think isn't just mostly focused


on usability.


So it's not that your website will rank better or worse


if you include your last page in the breadcrumb trail as well.


We have a separate mdot site.


Oops.


Now I lost the question.


Just a second.


Too many windows.


After mobile first indexing, do we


need to make any change on our canonical tags, structured data,


or sitemap?


Currently, we're using the desktop URLs everywhere,


and mdot URLs are used in alternative tags.


If you have the mdot site set up properly with the link rel


alternate to the mobile version and link rel canonical


to the desktop version, that's perfectly fine, also


with mobile first indexing.


We recommend with mobile first indexing


or in general to try to have just one version of a site.


It's not that we would not support mdot sites in the future


anymore.


It's more that things are just a lot easier if you just


have one URL rather than two URLs for the same piece


of content.


So that's kind of the direction I


would head if you're looking at a revamp of your website


at some point.


Then try to go towards responsive design


or dynamic serving where you have just a single URL


for your pieces of content.


On my price comparison domain, the error submitted URL


seems to be a soft 404, continuously increases,


possible reasons that I think they have been no index


since a very long time, or we change the meta robots index


to no index frequently.


My question is how to take out this URL from such issues


and get them indexed.


Yes, if you have a URL that has a no index on it,


then we might treat it as a soft 404 URL.


That's kind of equivalent in that sense in regards to how


it would be shown in search.


So that's generally not something


that you'd need to kind of work around.


With regards to making these pages indexable again,


that's something where essentially you


need to let us know that these pages have changed


so that we can recrawl them.


And once we see that there is actually content on these pages


and that there is not a no index blocking indexing,


then we will try to index that page normally again.


So that's something where you can


do the usual things, which could be like submitting a sitemap


file with the last modification date of the time when you


changed it from no index to index.


And then we can go out and double check those URLs again


and see that there's actually content there.


But if there is no content on those pages,


if it's like an empty search results page,


if it's a page that has a no index meta tag on it,


then it can happen that we flag that as a soft 404.


And that's kind of correct in a case like that.


Can adding do follow hreflinks increase the time


to download a page in a crawl status report?


I'm not really sure how that would be connected.


From February 16, our crawl stats


is showing a heavy drop in crawling


due to an increase in time to download a page.


Coincidentally, from the same day,


we're seeing soft 404 errors that has increased from 3,000


to 20,000 pages.


Crawl currently not indexed has also doubled.


Number of valid pages has dropped from 200 to 200,000.


From 292,000 to 205,000.


One change that we made on our site on the 6th of February


was we made our brand filter crawlable on around 1,000


index follow pages.


On a few pages, this added more than 500 crawlable links.


Should we revert this action?


So I think, in general, this change


shouldn't be affecting the time to download a page


significantly, other than the fact


that if you're adding content to a page, which could be links,


which could be just text, could be images that you're linking


to, anytime you're adding additional content on a page,


then obviously we need to download that content in order


to index that page.


So if you're adding a significant amount of content,


then that could be affecting the time to download a page.


But if you're just adding, I don't know,


a small amount or a relatively small amount compared


to the rest of the page, then generally that


wouldn't be affecting that.


However, what it sounds like is happening


is you're not just adding content to these pages,


but you're actually allowing indexing


of a significant amount more content that's


being dynamically generated on your website.


And my guess is what is happening there


is that your server is just spending a lot more time


to generate the content on these pages.


And that's the time that we see with regards


to downloading individual pages on your site.


So it's not so much the amount or the content


itself, but rather the time that it takes for your server


to generate that content, which you're probably seeing there.


And is that good or bad?


I don't know.


It's hard to say.


Sometimes if the content that you're providing like this


is critical for your website, if the internal links there


are critical for your website, then maybe you


need to bite the bullet and say, well, my server is a bit slow,


and that's just the way it is.


And that might be OK.


It might also be that this time is increasing significantly


more than it was before.


And that could result in us, for example,


crawling less of your website.


And that might be the kind of thing


where you'd want to look into either speeding things up


on your server or finding a way to streamline things


in general with regards to how you serve content.


So the common approach here would


be to use more caching so that your server doesn't


have to calculate all of these links


and look them up from the database again,


but rather it can pull them out of a cache


fairly quickly so that these pages can be


created a little bit faster.


The other thing I guess worth looking at here


is depending on the type of website


that you have and the setup that you have,


if you're allowing filter pages to be completely crawled,


that can easily result in a giant mass of URLs


that your website is suddenly providing that we think


we need to go off and crawl.


And depending on the type of your website,


maybe those pages aren't of the kind of highest quality


possible.


So if they're just kind of combinations of existing things


that you're providing again, and suddenly you just


have 100 times the URLs as before,


then you're adding a lot of overhead for something that


brings you very little value.


So that's something you might want to reconsider there


as well, or at least look into the details of what exactly


you're suddenly creating.


How accurate is the crawl stats report?


In our case, Search Console is showing time


to download a page increased, and the pages


downloaded per day also reduced.


But our logs are showing that crawling dropped


when we made some changes.


So these reports are accurate.


They are based on what we kind of pull out


of our crawling logs.


But one kind of tricky thing here


is that these crawl stats include


URLs that are also fetched from other services at Google


that use the same infrastructure as Googlebot for crawling.


So for example, I believe the Google Ads landing page checks


are done with the same infrastructure.


The product search crawling is done


with the same infrastructure.


And that means that when you look at those stats overall,


it's not that you can just add up the Googlebot


requests from your server logs and get the same number.


You might need to add kind of the other crawling


that we do for that number as well.


Our structured data on our mobile site


has slightly more attributes information


than our mobile site.


Is that OK?


Which version will Google pick?


Currently, we're on desktop first indexing.


So I'm guessing the desktop site has slightly more


than the mobile site.


So when it comes to mobile first indexing,


we will only use the mobile version of the content


that we get.


So if your mobile site has less structured data


than your desktop site, then we will use only your mobile site.


And we will not use anything from your desktop site.


We still crawl your desktop site occasionally.


Usually, that's something like 20%, 80% split.


So 20%, maybe desktop, 80% mobile.


But we crawl the desktop site primarily


to make sure that we're not missing any new pages.


And we focus for indexing.


We focus purely on the mobile version.


So if your mobile site has less content, less structured data,


fewer images, lower quality images, anything like that,


then with mobile first indexing, we will focus on that.


And we will not know about the things that


are only on your desktop site.


Mobile search results, Google is showing product images


with each website ranking in traditional blue listings.


Is there any SEO we can do so that Google can


show our product images too?


Do we need any HQ images for that or alt tags?


So there's product structured data that you can do.


And there are some requirements around the product structure


data that you can use.


So I would double check that.


There's also, I believe, the Merchant Center,


which is kind of like a console that you


can use to control the crawling and indexing


and kind of like how product search


results are put together.


And I don't know the details there,


but I believe at the moment anyone


can access the Merchant Center even if you're not


running product ads.


So those are kind of the two places I would double check.


I checked my page with the W3C validator


and it showed me 300 errors.


Can it slow down the time to download a page?


No.


This does not affect time to download a page.


Time to download a page is purely the time


that it takes from Googlebot asking your server for a URL


to your server having provided that full content


to Googlebot.


What is on that page is totally irrelevant


other than that if you have a lot of text,


then maybe it'll take a long time to transfer.


But HTML errors are totally irrelevant for that.


In general, the W3E validation is something


that we do not use when it comes to search.


So you don't need to worry if your pages kind of meet


the validation bar or not.


However, using the validator is a great way


to double check that you're not doing anything


broken on your site.


So in particular, for other kinds of devices,


for people who need accessibility features,


the W3E validator is a great way to kind of get a confirmation


that the markup that you're providing is pretty reasonable


and is something that most kind of consumers of markup


will be able to understand well.


So I definitely recommend checking out the validator tool


and trying it on your pages and seeing what the results are


and then trying to improve things


so that you're a little bit more in line with really valid HTML,


because that just generally makes things a lot easier when


it comes to displaying your pages,


when it comes to understanding the content on your pages


for things like screen readers.


All of that makes it a lot easier


if you have reasonable HTML.


I'm currently working on a site that


wants to make use of Google Jobs that's


coming to the Netherlands.


I'm curious if there's a way to check if the job is already


indexed so I can skip the update delete request to keep queries


as low as possible.


I don't think there's any automated way


to check if a job is already indexed.


So I'd continue using kind of the indexing API for this


and using kind of the update delete request


to update those as needed.


I know when we're migrating a website from one domain


to another, we should use 301 redirects from the old domain


to the new domain.


Does the redirection have to be in place forever


to pass link juice, or does it just


need to be in place until Google picks it up once,


and then we can stop paying for the old domain


in order to redirect from the old one to the new one?


OK.


So 301 is a permanent redirect.


And kind of how the name says, it's


a good idea to have that permanently in place


if you care about that.


So from our point of view, our guidance


is generally that this redirect should


be in place for a significant amount of time


so that we can really be sure that it's there.


From a practical point of view, I


would like to recommend at least one year of having


this redirect in place.


Personally, I would try to keep that in place longer,


as long as you can.


Sometimes there are technical reasons


why it's not possible to keep that redirect in place


for a longer time, but I would try to keep it


in place as long as possible.


Definitely as long as you continue


to see users or search engines kind of go to the old URLs


and get redirected to new ones.


So you can double check your logs on that.


Sometimes people link to your old site


and you forgot to update those links.


But that's something where I try to keep it in place for as long


as possible, and definitely at least one year.


With regards to stop paying for the old domain,


I would be really cautious with that,


because Babermas love to pick up old expired domains,


and they put all kinds of crazy stuff on it.


And if the old domain is, for example, your old brand name,


then suddenly your old brand name


could be used to promote some really crazy spam on the web.


And sometimes that's not really nice to see.


And especially if you've let that domain expire,


then you can't do anything about it.


It's not that you can go to Google and say,


well, this used to be my website,


therefore I demand nobody else is


able to kind of rank in the search results for that.


That's not possible, because if you don't control that domain,


then anyone can host something there.


And sometimes that's reasonable content,


and sometimes that's stuff you don't


want to be associated with.


So personally, I try to keep those old domains as long


as you can.


And if you're keeping those domains,


then maybe also keep those redirects in place


as long as you can.


We did a crawl with Screaming Frog


and realized it seems I've identified pages


with h-entry microdata as article markup,


while in Google's structured data testing tool,


it only recognizes h-entry.


I wonder, should I continue to put extra article markup


in addition to h-entry, or h-entry will be enough?


I would recommend using the rich results test for this


and double checking the markup that is actually


required for the article markup in our developer documentation.


So the structured data testing tool


tries to pull out all kinds of structured data


on a page, which includes things that might not


be used at the moment.


So I really focus on the rich results test,


which focuses more on the rich types that are actually


shown in search, and double checking that


with the documentation that we have.


Wow, OK.


Still a bunch of stuff, but we're


kind of running low on time, so maybe I'll just


open things up to any of you if there are any questions here.


SPEAKER 2


John, I have a quick one.


So a few hangouts ago, I asked you


that it's an e-commerce website, and they


have like 1,000 categories.


And all of them are placed in the main menu.


And you mentioned it shouldn't be a problem for you


from a technical point of view.


You should be able to see those links and crawl them.


And one thing I didn't address was


whether is that a good practice, because if you


have all of those 1,000 categories in the main menu,


then probably Google kind of sees them


as being at the same level of importance, sort of.


So obviously, there are certain categories with subcategories,


and the parent categories are targeting more broader


keywords.


The subcategories are targeting more niche keywords,


as is usually the case with e-commerce websites.


So having this kind of very flat architecture,


can that become a problem in terms of rankings?


Because Google pushes out its ranking signals kind of equally


instead of using a hierarchy in that sense.


So can that be a factor?


Having a clear hierarchy helps us a little bit,


but it's not.


So in most cases, it's not going to be something that has


like a strong ranking effect in that regard.


So what I imagine will probably be trickier


with a case of a really flat hierarchy


is that we won't know which pages belong together,


in that when we try to show site links, for example,


in the search results, where we try to say, well,


this is the main page, and these are


the pages that are kind of sub-pages from this page,


that will be a lot harder to do if there's


a really flat hierarchy, because we don't really know


what the structure is.


And that's something where if these are all categories


and subcategories altogether, maybe it


doesn't make a big difference.


Maybe we're still showing some useful site links there.


That's something you can double check.


Where I have seen it cause a little bit more confusion


is if you have a paginated set, and you


link to all of those pages from the start.


So that's kind of a similar situation


in that you have a flat hierarchy rather than kind


of this paginated set that kind of goes down.


And that's something where I have seen us do weird things


like show page five of a paginated set for kind


of a generic keyword, because we think, well, all of these


are kind of equal, and page five seems


to be the best one there.


And as a webmaster, that seems kind of weird.


Like, why does it start with page five rather than page one?


So that's something where I think purely


from a ranking point of view, you probably


won't see a big effect.


But from understanding the connections between the pages,


things like site links, the pages that


are shown in the search results, that


might be something where you would see some kind of fallout


just from telling Google all of these pages are equivalent.


And then we say, oh, well, all of these pages are equivalent,


so we'll just pick whichever ones we like.


Whereas if you give us a clear structure,


then it's like, oh, well, this is the most important.


This is the second kind of most important.


Then we can focus more on that.


So I was just asking about rankings because of how


internal linking works, especially since subcategories


targeting very niche topics, it's


much easier to rank well for those


because there's a lot less competition and harder


to rank the parent categories because there's


more competition.


There is as well simply because there


would be more focus on ranking emails going to.


Yeah, I think that makes sense.


Sometimes that also shows up, I think,


in the forums or on Twitter.


I've seen that where people say, Google


is ranking the wrong page for my keywords.


Like, I have this higher level category page,


and Google is ranking this low level product or subcategory


page.


And sometimes that also comes from us just not having


a clear hierarchy of understanding.


This is really the broader term, and this is the more niche


term.


And they're kind of above and below each other.


So I'm guessing it shouldn't be very flat.


It shouldn't be very, obviously, very deep either


because you don't want to get 10 pages deep to find something.


Probably it should be best to be somewhere in between.


Yeah, I think that's the part where everyone struggles


is like, what does it mean, like a balanced hierarchy?


Does it have to be square?


I don't have any explicit shape like what it should be in,


but it shouldn't be completely deep.


It shouldn't be completely flat.


It should be somewhere in between.


I'm guessing, would it be a good way to kind of go about this


instead of moving from that very, very flat architecture


to something more drastic?


I mean, cut out all of the subcategories,


maybe move category by category, like just


remove the subcategories from this one,


just see how it goes.


Yeah, OK.


Yeah, I think that, in general, that's always a good idea


because you're testing things step by step,


and you see what the effects are.


And if at some point you're like,


well, it makes absolutely no difference,


then you might as well save yourself the effort


from doing that for the whole thing.


So kind of going step by step and seeing,


is it actually doing what I expect it to do?


That's generally what I'd recommend.


Cool.


Thanks.


OK.


So let me pause the recording here.


I'll stay on for a little bit longer if any of you


want to hang out a little bit kind of off the record


if you have any questions that you didn't want to ask live.


But thank you all for joining in,


and thanks for watching the recording,


if you're watching the recording.


And I wish you all a great weekend.


And stay safe.


Wash your hands, of course.


And see you next time.


English Google SEO office-hours from May 7, 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 at Google here in Switzerland.


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


where people can join in and ask their questions around search.


And it looks like I just need to mute someone here.


And a bunch of questions have already


been submitted on YouTube.


So we can go through some of those.


But it looks like lots of people are rushing to ask questions


here live as well.


So maybe we can get started from the top here.


On my list, I have Sun Koon.


I hope I'm pronouncing your name about right.


SUN KOON KOON KOONI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI


KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI


KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI KOOHNI


OK, so let's move on.


The Korea website has been a very useful tool


for identifying and reporting um,


kinds of issues and issues we have


in order to be able to find our own underclassmen.


Our website has been very useful.


URLs on the portal site for the destination URL.