So if we just have one URL to index for that piece of content


English Google Webmaster Central office-hours from Nov 12, 2019

and we'll say, sure, we'll index it under that one URL,


because that's all we know.


Whereas if you give us lots of different URLs


for the same content with some connections with rel


canonicals and maybe redirects in place, then we'll be like,


we'll try to figure it out for you.


But it's not sure that we'll figure it out in the way


that you actually want or in the way that is useful for you


when you're tracking metrics.


our


how Google will behave if I only want to do AB testing for desktop?


Or that is not possible?


I think with an m-dot version on mobile-first indexing,


we would index only the mobile version.


So we would not even see this AB testing on desktop.


So that's something that makes it a little bit easier,


in that you can do the AB testing purely from a user


point of view on desktop.


But we would not see that for indexing.


All right, all right.


Sure.


Thanks, John.


All right.


Someone else, I think, had a question.


But I forgot who that was.


No more questions.


Oh my gosh.


OK.


Let me see if I can grab a quick one from YouTube.


Question about verifying status codes.


In the answer, you said, if it's a 400 or 500 error or redirect,


then obviously those are things that we wouldn't render.


We're planning a website switch that


will include some changes of URLs, which


we're currently ranking.


Will redirecting those URLs to new ones


help the new ones get discovered?


Or will Google see the 301 status code and ignore them?


So I think that might have been unclear, or obviously unclear,


if the question comes up in the previous Hangout.


Essentially, that was specific to rendering the page.


So if there is JavaScript content on the page,


and that page itself is returning


a redirect or an error code, then we


would not render the JavaScript content.


You could imagine that you have a user-friendly 404 page,


and it uses JavaScript to show some content, including


some links to other pages.


Then we would not use time to render that error page,


because we already know, well, it's a 404.


Any of the content that we find here


would not be indexable anyway.


So we would not render the page in that case.


When it comes to redirects, obviously, we


wouldn't render those pages either,


but we would follow the redirect.


We don't need to render the JavaScript.


We just follow the redirect to the new location.


So definitely, if you're changing URLs from old URLs


to new URLs, then definitely a 301 redirect


is the right approach here.


And it doesn't matter if we render the redirecting page


or not, because even in the browser,


that move would be fairly quickly.


And you would immediately go to the next step in the redirect.


You wouldn't even try to render the HTML that's returned


with the redirecting page.


I don't think most browsers would even show that.


So from that point of view, 301 redirects


is definitely the right approach.


JOSHUA BERG-ETTMANN-MURPHY.


John, I have a question about the in this video or feature.


I don't know if you know anything about that.


But just to be clear, if you have YouTube videos


and you're putting the timestamps in the description,


you don't need to apply for that beta form or that schema.


The schema is only if you have your own videos


posted on your own site.


I don't know.


Good question.


Is that unclear in the documentation?


I think it was clear that you don't


need to submit the form if you have YouTube videos.


I just wanted somebody to ask me, and they think it was not.


So I just wanted to clarify that with you.


I'll tweet at you and see if you can look into that.


I think the best approach would be just to prove it.


I don't want to prove it because I do both.


And now it's like, all right, which ones are pulling from it?


It doesn't even pull them anyway from my YouTube videos.


I have like 50 timestamps.


And I don't think Google would approve.


So the next question is, how many timestamps


are too many timestamps?


And since this big feature's in beta,


when is it going to be released?


And then if we do it, do we get our DA ranking boost?


So let's spit that out.


Yeah, yeah.


I think that might happen, yeah.


I don't know.


You don't know.


OK.


It's possible.


Maybe, definitely.


It depends.


Got it.


It depends, yes.


All right, perfect ending.


OK, so we're at time.


Thank you all for joining in.


Thanks for all of the questions.


All of the discussions here as well.


I hope you found this useful.


And maybe we'll see each other again


in one of the future Hangouts.


Wishing you all a great week.


Bye, everyone.


English Google SEO office-hours from September 10, 2021

for the recording.


OK.


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


Office Hours Hangout.


My name is John Mueller.


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


And part of what we do are the Office Hours Hangouts,


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


And we can try to find answers.


A bunch of stuff was submitted already on YouTube.


So we have a lot of stuff to go through there.


But we also have some people already with their hands


up.


So let's start off there.


Let's see.


Ashwani, I think you're first.


Yeah.


Hi, John.


How are you?


Pretty good.


OK.


So John, I have a question related to website,


like, code-based website.


So my question is, why code-based website rank


faster as compared to any other website?


Still, they are using the same content.


They are using similar content.


If you are searching, like, Christmas-based code


or New Year-based code, so what you find,


each and every website have the same content.


But still, they are ranking on the top for you.


So why?


What kind of website did you say these were?


Code-based code, like the New Year code,


like 25th December-based code, code-based.


I don't understand what you mean with code-based.


Like, if suppose you are searching for, like,


someone is searching for life-based,


some related to their lifestyle-based code,


related to motivational code, like that.


Oh, like quotes, like a piece of text.


Oh, OK.


OK.


Sorry, I totally misunderstood you.


I thought you meant code, like software code or something.


Thank you.


Like quotes.


I don't know.


I mean, I think it's a very tricky area if you're just


purely, if your whole website is just purely based on quotes.


Because these are small snippets of information,


they're usually essentially public domain.


So anyone can include the same information


on their own website.


So it's very competitive.


It's easy for people to just take a database of quotes


and put them online.


And I don't think there's one simple trick to make


a quote-based website rank.


Instead, I think it's overall probably a tricky area


to try to get a new website to appear.


Because it's just the same content as everyone else has.


So if you want to stand out, you really


need to do something different rather than just


the same quotes and essentially different categorization,


perhaps.


OK, but what I found on internet,


like when I surf on the internet, what I found


is two, three websites have the same content.


Still, they are managed to rank on the first, second,


and third voices.


So my question is, why Google is giving a rank to all those


three, and if Google is giving the ranking,


if Google is giving the position,


so why Google are not penalizing all websites based


on who have published the first content, who


is the first owner of the content?


So why Google are not doing these things?


Why Google always try to focus on the service-based


and product-based website, not on the quote-based website?


I mean, on the one hand, it's not the same page for us.


If it's a quote, it's like one or two lines of text.


But on a web page, you have a lot more information on there.


So from our point of view, it makes sense


to rank those pages separately.


So that's something that we would essentially see as,


like, it's normal.


And with regards to penalizing these websites,


if this is public information, then anyone can publish it.


It's not that the first person to say this quote


is the only person to appear in search,


because usually the quotes are from authors who have written


something long ago.


And it's definitely not the case that the person


running the website made up this quote,


but rather someone else did.


So even if we were to say, like, the first person


to say this quote is the one who should rank,


I don't think that would be the average quote-based website.


OK.


Understood.


And my second question, and this one is last,


related to international targeting.


So I am doing international targeting


for, basically, pharmaceutical industry.


So what I did, I basically targeting language, not


country.


I'm targeting language.


So now my question is, if I want to target country


plus language as well, means country plus language.


So I have to insert inside the HREF language,


I have to mention language plus country code, right?


Now, what should I do inside the Google search


console if I am targeting multiple countries?


Like, if suppose I'm targeting 10 countries,


now how should I make understand to the console


that I am targeting these 10 countries?


Because console is, at one time, console is only supporting


only one country.


Yeah.


So if you want to do geotargeting,


you have to use either subdomains or subdirectories


per country.


And then you add those subdomains or subdirectories


to search console separately.


Yeah, I did that.


I already did that.


Yeah, but once you have them added separately,


and if these are generic top-level domains,


you can set the geotargeting individually.


So it's like your website.com slash fr for France,


and then you add that to search console.


And in search console, in the geotargeting section,


then you can say, this website is for France.


If you don't have a country, if you have a country code


top-level domain, like.in or.uk or something,


then you can't do geotargeting.


OK, OK, thank you.


Thank you, Joe.


Thank you so much.


Baruch.


John, again, it's so good to be here.


I missed all the Hangouts from last year.


But yeah, I have a very important question.


And it's something that I haven't


seen you talk about at all because it's just very fresh.


So I want to know, again, now from a ranking factor


perspective, what is going to happen with the new CSS


property that you guys just recently integrated


to Chrome-only browser?


So the new CSS property that I can implement


to render content better?


I don't know which one you mean.


It's the content visibility property that


was just integrated recently.


OK, I doubt we'll do anything with it in Search.


OK, I mean, because it just basically,


it's all about improving load time and so on.


So I just wanted to know, moving forward,


how important it's going to be to implement it


into your site because a lot of developers


are having issues, and SEOs, they work together.


They're having a lot of issues with CSS and JavaScript.


Those are the two main issues.


Yeah, I don't think we would do anything special


with new CSS properties or new HTML tags, things


like that in Search.


There are two places where it could come into play.


On the one hand, where we render the pages because we


use a modern Chrome browser, that could


be something that plays in.


But if it's CSS, then it's about the HTML is already loaded,


and the HTML is what we would take into account for indexing.


And it's just a matter of maybe shifting things around


on the page with the layout.


So from a rendering point of view,


I don't see a new CSS property changing anything.


It would be essentially, we would still


index the content normally.


The other thing that you kind of suggested


is with regards to speed.


If it is something that affects the speed that users see


the content in, then that could play a role with regards


to Core Web Vitals.


Because for Core Web Vitals, we use essentially the speed


that users see, the field data.


And if users are using a modern version of Chrome,


and they're seeing pages load faster because the pages are


implementing HTML in a better way, and CSS, and JavaScript,


or whatever, then that's something


that will be reflected in the field data over time.


And we could take that into account


through the Core Web Vitals.


So that kind of, I guess, more indirect effect


is something you might see.


Whether that has a noticeable effect on most websites


with regards to the Core Web Vitals, I don't know.


That's something I'm guessing it does have some effect.


Otherwise, the Chrome team wouldn't have worked on it.


But I don't know how strong the effect would


be for the average website.


AUDIENCE 1 But I would appreciate calculating and doing


all the calculations.


It's just going to be better for Googlebot to understand


and implementing that.


Now, I don't think for Googlebot it changes anything.


What I would do is if you're working together


with a developer, and you think this property might make sense,


or some other new HTML property, implement it on a test page,


and test the page with the lab testing tools before and after.


And then you can see, does it really


make a big difference here?


And if it does make a big difference,


then maybe it's worthwhile implementing broader.


If it's a small difference, then it's


like, well, it was an interesting test,


but probably not worthwhile to implement across the whole site.


OK.


Thank you so much.


Sure.


How's there?


Hi, John.


How are you?


Hi.


Pretty good.


Good.


Thanks for doing this again.


I've got quite a few questions, which I'll get through


as quickly as possible.


The first, which I'll show you on the screen.


Can you see the screen OK?


Not really, but OK.


I was just wondering, and I think


you've spoken about this before recently,


that the main content should be above the fold.


Would this lead generation form impact SEO in any way?


Because if we scroll down, it's an article


about the ultimate guide to phone system prices.


And at the top here, there's just a lead gen form


where people can compare telephone system prices.


Would that impact SEO?


I don't know.


My guess is probably not noticeably.


What effect might come into play is


our algorithms do look for things like ads


above the fold that push the main content down


below the fold.


And it's possible that we would think a lead gen form like that


would be like an ad.


But I don't think it would always be the case.


And it also depends on what that page is trying to rank for.


If it's essentially a page that's trying to rank for,


it's like, I don't know, get car insurance,


and the form is about sign up for car insurance,


then that's the intent of the page.


But if the intent of the page is find out more


about why oranges grow, and then you have car insurance


where I'm on top, then that seems more like an ad.


OK, that makes sense.


Thank you.


So it's the relevance of, I guess, the lead gen form.


And also with the images, and I don't


know if this would impact SEO at all,


so I guess it's based on maybe your opinion as well.


But do you think that we shouldn't include images


at the top of the article?


Do you think we should just have the introduction


to begin with, and then?


I don't think it matters that much.


OK.


Yeah.


Well, thank you.


I don't think even for image search,


that would be a big difference if you


were looking at image search.


Got it, brilliant.


And what does note follow mean in terms of what I mean by that


is does it count as a hint, for example?


Essentially, we use nofollow in, so what


we try to do with the nofollow is essentially


stop the passing of signals for that.


But what can happen is that we will still discover the page


that you're linking to.


We might crawl and index that separately.


So for example, a common setup is you use,


well, not really common, but it happens every now and then.


People sometimes use internal nofollow links


to point out a specific page within their website,


and they expect that internal page not to show up in search


because it's only linked with a nofollow link.


But from our point of view, if we discover that URL


and we can crawl it and index it,


then we might still index it independently.


OK, thanks.


And what's your advice for building links?


Because obviously, you can create great content,


and then we can send that across to other relevant websites


and awesome, I guess, check it out and link to it


if they want to.


What's your advice if we gave you 100 grand


and you went working with Google?


What would be the strategy that you would do?


Yeah, I don't know.


I think it's always tricky to try to simplify it


into one quick answer type thing because then people


try to take it out of context and say, oh, John said,


we should do this.


And therefore, we're going off and doing it en masse now.


I think the approach of creating good content


and spreading the word about that content,


finding people who are maybe influential,


who are interested in that topic,


who might want to write about it, I think all of that


is fine.


What is problematic is if you go off and create


those links yourself.


So if you go off and just buy guest posts


or you buy links directly on other people's sites,


from our point of view, that would be problematic.


And essentially, when it comes to web spam,


if someone from the web spam team looks at something


and they look at a website and overall, it


seems like there's a wide variety of different kinds


of links here.


And some of them, you don't really


know if there's a weird story behind it where they might


be kind of questionable.


But there's enough out there that's also reasonable.


And usually, the web spam team will say, well,


we'll let the algorithms take care of it.


But if they look at it and they see all of these links


are essentially things that look quite a lot like guest posts,


even though they're not labeled like guest posts,


then that might be something that they would take action on.


So essentially, when it comes to links, on the one hand,


creating really good content is definitely the first step.


But it's also not the only thing.


Just having good content is not going


to make your site pop up in Google Search.


We do take things into account, like links,


but lots of other factors as well.


But really kind of spreading the word out


and trying to get, I don't know, contacts


who are interested in the kind of content that you create


and encouraging them to, I don't know, maybe link out


or at least check out your content as well.


And that can be all kinds of people.


Like you could, for example, also just run a newsletter


and just include the newest pages that you have,


things like that.


SPEAKER 2


Fantastic.


Thank you for going into TSL there.


And a final question, which everyone will be glad about.


And that is, is there a PDF version of the Webmaster


guidelines, like there is for the quality rating guidelines?


I don't think so.


Yeah.


OK.


I don't know.


Might be an interesting idea.


I've been reading on a computer.


Can be quite tricky if I'm trying


to do like a semi defrosted mackerel.


So yeah.


Thank you very much.


And have a lovely day.


Thanks.


You too.


All right.


Let's see.


Omar.


Hi, John.


Can you guys hear me well?


Yes.


Perfect.


Great.


So we are a very young startup that


just started here in Germany.


And basically, what we do is that we


crawl leading real estate platforms.


And we try and assess which realtor is actually


achieving higher prices, which realtor is achieving


fast sales duration.


And so we have for each postal code in Germany,


we have one specific page for that postal code, which


includes or which calculates to 28,000 pages, which is not


that huge for other websites.


But we're facing challenges in indexing those sites.


So our goal is that someone that's typing in realtor Munich,


that our page with the ranking of the best agents in that


region will pop up.


But currently, we see that 90% of our pages


is excluded from the index.


And I've read a lot about it.


And you also are talking about how


the content might be similar or that the content is not super


interesting for the users.


And my question to you is how to solve this,


so how to get ranked when someone gets or types in,


hey, I want to search for a realtor in that location,


because it's super crucial for him.


But the bot might not understand that.


So yeah, super excited to hear what you have to say.


Yeah, I think there are a few things that come into play.


On the one hand, from the quality side,


that's something that I think you almost


need to figure out before you push too far, in the sense


that it's sometimes easy to create these back ends that


analyze a lot of data and spit out some metrics


for individual locations and maybe make some lists based


on existing things.


But you really need to make sure that these are also


useful pages for people.


So it's not just like a recompilation of data


that's already out there.


So I don't know.


For example, if you take a city and they have 10 realtors,


and it's essentially the same 10 that are in the phone book,


then it's hard to say that your compilation is providing


something of unique value.


So really making sure that the content that you're publishing


is something that is really high quality and useful.


I think that's almost like the first step,


because that helps to grow your website over time.


But how would you indicate that?


Sorry to interrupt you.


How would you indicate that?


Because we are pretty sure that this is pretty unique content


all over Germany.


It might be all over the world.


And that's why it's very analytical.


I also posted an example of a page in the link below.


But we have a hard time knowing how to really, yeah.


Yeah, I think that's something where you almost


need to do something like user studies


to figure out what is the best UX for these kind of pages.


What kind of information do people need?


What ways can you provide assurance


that the content is correct, that you're not skewed by,


I don't know, payments or whatever,


that it's really trustworthy content, essentially?


But that's something which is, from our point of view,


almost like a requirement for the next steps,


because it is possible to get a lot of pages indexed


and using different ways.


But if we recognize that you have a large website


and we think that the content overall is low quality,


then you almost have a bigger problem


telling Google, we improved the quality of our pages.


Whereas if you start off with really high quality content,


then it's more a matter of the challenge of, well,


how do I get more of my pages indexed over time?


So that's the first thing I would do.


And with regards to indexing more pages over time,


that's usually something that happens automatically


as we recognize that your website is really


valuable and really important.


And that's something that it just takes time.


And one of the strategies I try to, I don't know,


encourage people or tell people to think about


is, on the one hand, you can decide what kind of pages


you think are important within your website


and which ones you want Google to focus on


through internal linking and working to make sure that,


if you say 90% are currently not indexed and 10% is indexed,


that you make sure that at least the 10% that are indexed


are really good pages and really important pages for you.


So that you get a mass of people already


going to these pages and saying, this is fantastic content.


Maybe they recommend it to other people.


Maybe they link to it from other places.


But at least that 10% that you start with


is something that you can grow with.


And then over time, what you'll see


is Google crawls more and more of your website


as it recognizes that it's really good and important.


And that can then result in, well, on the one hand,


crawling more frequently the existing pages,


on the other hand, crawling deeper within your website.


So more layers within the internal linking


and digging in a little bit deeper.


So that's something that essentially happens over time


algorithmically.


And it's something where it's sometimes tricky, especially


with a website like I'm guessing yours is,


to create an internal linking structure in the beginning that


focuses on things that you find important.


Because it's very easy to say, well,


I will just list all my postal codes in numerical order.


And Google will crawl and index all of these pages.


But maybe the first 10% of those pages that you have linked


there are irrelevant for your business or very low value


for your website.


So it's almost like you have to create a more funneled web


structure in the beginning.


And then over time, as you see that Google


is doing more and more on your website,


then expand that and expand that step by step


until you've reached your end situation where Google is


actually actively indexing all of the content on your website.


AUDIENCE 1 OK, great.


So summary, I tried to nail down my content


on the pieces of pages that Google already indexed


and from there try to then grow my website by doing


internet linking properly and showing Google


that this content is unique, this content is valuable.


Yeah.


OK.


Yeah, I think, first of all, I would really, really


focus on the quality.


And especially if it's in kind of a almost machine-generated


website, you really need to make sure


that everything is such that it's not only


the correct numbers, kind of like for, I don't know,


analytical people who look at the pages,


but it's also something that the average user thinks


is trustworthy and useful.


And also, I would not focus on the pages


that Google currently has indexed,


but rather look at your site overall and say,


it's like 10% is what I have as a budget,


and which of my 10% of the pages do I want to have indexed?


And then almost like twist it around in that direction.


OK, perfect.


Thanks a lot, John.


Sure.


OK, let me run through some of the submitted questions,


and then I'll get back to more of you here as well.


Lots of people raising your hands.


So good.


And I'll probably have more time afterwards as well


to keep going.


We'll see how far we can make it.


Let's see.


The first question I have on the submitted list


is, what's the best practice when dealing


with affiliate backlinks?


We've sent the guidelines that the link should be nofollowed


and sponsored, but not all sites respect them or even


have knowledge.


Would disallowing Googlebot from crawling those affiliate


parameters help or hurt in any way?


Do we need to disavow those links?


So yeah, it sounds like your website


where other people link to as affiliates.


And from our point of view, we kind of


understand that you can't get everyone


to do the right thing with regards to affiliate links.


But we really want to make sure that at least the things


that you're publishing or you're saying on your side


matches what our guidelines are saying.


So it sounds like you've sent the guidelines that people


should be using nofollow.


And maybe, I don't know, part of your users or people


linking to you are following those guidelines.


And from my point of view, I think that's fine.


With regards to disallowing crawling


of the affiliate parameters, I think that's a bad idea


because that will result in those pages being indexed


without any content.


What you could do, I don't know.


I think the best approach is almost really just


to focus on normal canonicalization


for something like that.


But that wouldn't affect how the value of those links


is being passed on.


What I've seen some sites do is set up


almost like an affiliate domain that is separate that


is blocked from crawling and indexing,


or just blocked from crawling and then redirects


to your actual website.


I think for really large scale affiliate sites,


that can make sense.


But for the average website, that's probably overkill


and not something to worry about.


Regarding disavowing these links,


usually that's really kind of hard to do if it's just,


like, I don't know, 10%, 20%, 30% of the people linking to you


are not following your recommendations.


Keeping track of that, I think, is almost too much work.


So in short, I think if you're giving


the right recommendations, if a significant part of your users


are following those recommendations,


then I think you should be fine.


I don't think you need to do anything special past that.


We embed YouTube videos on our website.


However, the significantly slowed down


our page loading times, according


to PageSpeed Insights.


Embedded MP4 videos do not slow down the page loading time


at all.


Therefore, for SEO, is it better to embed MP4 videos?


I don't know.


At least from kind of the normal ranking and search crawling


indexing ranking point of view, I


don't think it makes sense to switch to a different video


format just because of SEO reasons.


If you're looking at speed, obviously, there


are different ways of embedding videos.


And that can be different formats of videos.


That can be different ways of embedding the existing videos.


And in particular, when it comes to YouTube,


there are ways to embed videos that use a kind of lazy loading


where you show, for example, a placeholder image.


And if someone clicks on it, then it activates the video


itself.


And if you set that up, then I think


you should be able to set these pages up so that they actually


load pretty quickly.


I also know the YouTube team is working on improving


the default embed as well.


So maybe over time, that will improve.


But at least until then, I would look into different ways


to just embed the same videos.


And if you decide to host these videos yourselves


and just to put the MP4 files directly on your site,


that's also fine.


That's perfectly acceptable and up to you.


When it comes to videos, the thing I might watch out for


is that Google is able to recognize the video


metadata for these things.


And with normal YouTube embeds, usually we


can pull that out fairly well.


If you're embedding these yourselves


or using a custom player to embed the videos,


then I would double check that you have the structured data


for videos appropriately on your pages as well.


Hosting and crawling.


Does my hosting with shared hosting,


VPS, et cetera, affect crawling efficiency?


No.


By default, the type of hosting you have


does not affect the efficiency or the amount of crawling


that we can do.


However, you can have bad hosting or slow hosting.


And all kinds of hosting can be slow.


So that's something where it's not


kind of an attribute of a specific kind of hosting,


but rather it's like, well, your hosting is slow.


And you happen to be using shared hosting,


or you happen to be using a VPS, or you


happen to be hosting on, I don't know,


a separate infrastructure in some data center.


If it's slow, it's slow.


If it's fast, it's fast.


It's not an attribute of the kind of hosting that you have.


We have a new e-commerce store with lots of different variants


and search queries for products.


For example, we sell diamond cutting disks.


These have search queries like diamond cutting


disk for tiles, wood, concrete.


Our competitors are ranked with own categories


for these products.


We use filter pages, which are optimized


and are also indexable.


But the filter pages don't get ranked or don't get indexed.


So should I create hundreds of unuseful subcategories instead?


So I think, first of all, one important aspect here


is that we don't try to recognize


the difference between different category pages or filter


pages or search pages.


Essentially, we see all of these pages as being equivalent.


And it's more a matter of the kind of content


that you're providing there.


So it's kind of similar to in the past,


we would get questions like, if I do a blog post,


if I set up a separate page for a piece of content,


does Google treat that differently?


And again, we don't treat kind of like the semantic thing


that you have set up on your side separately.


But rather, we recognize on this page,


there are lots of products that are linked here.


There's information about this kind of product on this page.


And we'll take that into account.


And it doesn't matter for us if this


is a category page, a search page, a tag page, a filter


page.


Essentially, it's one URL that has this kind of information


on it.


So from that point of view, I don't think you artificially


need to create something special on your website.


But rather, if you're trying to get these kind of pages


to appear in search, you just need to make sure,


I mean, just need to make sure that you


have the right amount of useful information on these pages.


So that when we look at these pages, we can recognize,


oh, here's some information about the type of page


that it is.


Here's a clean heading on this page.


Maybe there's a subheading there as well.


Maybe there are links for additional context.


And there's a list of products that we can follow and also


go off and crawl and index.


And that's essentially what we'd be looking for.


And if you're seeing that none of these pages on your site


are being crawled or indexed, then the first thing


I would look into is kind of the technical side of things.


Is crawling or indexing of these pages blocked somehow?


Is there a canonical setup?


Is there no index perhaps set up by your shop system?


All of those kind of things.


But if you're seeing that some of these pages


are being indexed and ranking but not all of them,


then I assume from a technical point of view, they're fine.


And it's more a matter of, well, we


don't know enough about these pages


to actually go off and crawl and index them.


So you could do things like look at your internal linking


structure and see what you can do


to make it so that we can find those pages a little bit


easier.


And that could be something like on your home page,


you list a section of popular categories


or popular kinds of products.


And then you link to those pages directly.


Or maybe you do occasional blog posts


with information about a specific kind of product.


And then from there, you link to that kind


of product page on your side, which


could be like a filter page.


It could be a category page, whatever you want to do.


I've been waiting for my pages to get


crawled for more than one month.


I've tried to improve my overall pages outside


of those non-crawled pages.


What would your advice be to improve crawling on a website?


It is really hard to say without knowing the website itself.


Usually, this is something that falls roughly


into the category of crawl budget,


not in the sense that it's a problem for a website.


But essentially, there are two sides


that are always at play there.


On the one hand, the capacity for crawling,


like how much can Google crawl?


If this is a very small website, then probably we


can crawl everything.


And then there's a crawl demand.


How much does Google want to crawl?


And the crawl demand is something


that you can help us with things like internal linking


to let us know about your relative importance of pages,


but also is something that we can pick up over time


by recognizing, well, there's a lot of really good


and important content here.


So we should perhaps be investing more time


in more crawling here.


If you're looking at a bunch of pages that you've created


and they're just not being indexed,


my hunch is that maybe you're creating too many pages.


And you should be focusing on fewer pages


and making sure that they're better first.


And then at some point, when you realize


that the pages that you create, they actually


get indexed fairly quickly, then go off and create more pages.


So first, improve the quality.


And then as a second step, go off


and grow your website step by step.


We've noticed that about three weeks ago,


some of the URLs from our website


moved to the excluded section in Search Console.


I checked them with the inspection tool.


They're indexed in Google.


No changes have been made, but they're still


listed as crawled, currently not indexed.


I thought they will move to a valid section in about a week,


but it doesn't work.


So is there a bug in Search Console,


or should we be worried about it?


I don't know.


I'm not aware of anything specific happening here.


So if you see this or if you're here,


I don't know if you're here.


But if you can send me some examples


or post some examples on Twitter where I can take a look


together with the team, I'm happy to see


what we can figure out there.


Sometimes there is a little bit of a difference


when it comes to different data centers,


that it might be indexed in one data center


and not in the others.


And maybe the reporting gets a bit confused by that.


But usually that settles down after a while.


So if you're seeing this regularly happening


and especially growing over time,


then it feels like something where


it would be good to send some examples to us


so that we can double check if this is actually a problem,


either in Search Console or in indexing.


Or maybe it's just, I don't know,


our systems are a bit confused with your website at the moment.


John, I sent you that thing long time ago, that issue.


Yeah, I've looked at everything in terms of,


so there's probably a technical issue there.


OK, I can double check.


Yeah.


Thank you.


Let's see.


If many URLs are not configured according to best practices,


so no hyphens between words, vague descriptions,


underscores instead of hyphens, is it better


to leave them as is, to change them all at once,


change them one or two a week, or something else?


So from my point of view, the effect of the URL structure


or the way that you put things into the URL


is so tiny that it's almost not worthwhile to go off and make


bigger changes across a website just because of that.


So my recommendation there would generally


be to just leave them be and maybe set up a document


somewhere with things that you would like


to do if you do a bigger revamp.


And at some point, maybe a few years down the line,


you decide to do a bigger revamp of your website,


then take that list out.


And if you notice, well, you should


be doing different URLs, then maybe at that point,


go off and include that and change that there as well.


I think, in general, if you go off and change the URL


structure across a website in a large way,


then you create a lot of fluctuations for, I don't know,


a couple of months.


And in the end, the results will likely


be exactly the same as before.


So you kind of have that long period where things are worse.


And then in the end, you have the same result in the end.


And I don't think that's worthwhile.


Whereas if you go off and do a bigger revamp of your website


anyway, where things will be confusing and worse anyway


in between, then you might as well clean that up as well


and improve that.


Or if you're creating a new website,


then it's obviously something to take into account.


And you don't have fluctuations associated with that.


You're basically just doing the best practices from the start.


So that would be my direction there.


Why does the home page of a website


show higher in the search results


than pages that are more closely related to the search term?


For example, a local photographer


might want their book a photo shoot in Chicago page


to be higher for a term that matches that type.


Yeah, I get this question every now and then.


I think, in general, this is a good problem


to have because it means that your website is already


ranking fairly well for these kinds of queries.


So that's kind of like as a first step.


I think you've probably already done a lot of things


really well.


The main issue that our systems run across here


is we don't understand the relative importance


within your website for these kind of terms as well.


So essentially, what we see is perhaps your home page


is a very strong page.


And it also includes things like photo shoot in Chicago


on the home page.


And we say, well, home page is like a good match


for this query.


And we might recognize the individual page


as well, and we might know there's also something good


here.


But we don't really understand that that individual page


is something that is so much better and much, much more


important for these individual queries.


So that's something where sometimes with internal linking,


you can help to improve that.


Sometimes with improved kind of quality across the pages


or more focused information on these pages,


But essentially, it's something where


we know your website already covered this topic,


and it's more a matter of, well, how


can you tell Google which of your pages


is the best suited for that?


And I think with the home page, it's always kind of tricky


because the home page is usually one of the stronger


pages of the website.


So almost taking that focus away from the home page


is sometimes a bit tricky.


I have a question related to passage ranking.


If Google Search is using a certain passage of a page,


would there be a way that Google Search could link directly


to that passage?


For example, if the passage is an anchor link like this one,


I took a look at that URL, and I wasn't really


able to see what you were trying to show there.


So I'm not quite sure in that regard.


With regards to passage ranking in general,


that's kind of one of the things that we've


started doing to try to understand on a much longer


page, which has kind of several unique almost like parts


of a page within the same page to understand


that the page itself can be relevant to specific parts


of the content.


So it's not so much that we would pull out


like one sentence of this page and then just rank that higher


or show that differently, but rather we essentially


take a really long page.


And usually these are pages that are not super SEO optimized


if you want.


And it has different intents almost on the same page.


And we recognize, oh, this one section on the bottom


is actually very relevant and almost like a unique article


that we can show in search.


And then the passage ranking system essentially


says, well, there's lots of stuff on this page that


is not relevant, but this one part is super relevant.


And then we will rank this page because of that one part.


So that's something where it's more


a matter of ranking the page rather than pointing out


a specific part of a page.


But at the same time, we do try to understand things


like anchors within a page as well.


So it's like you have the hash editorial part


at the end of your URL, which I assume


could point to a different part of the page.


And we do try to understand that.


We sometimes include that in site links


when we show the page itself.


And the other aspect is sometimes we


take things that we show in a featured snippet


and also link to that directly on the page, which we can do


with, I forgot, some new HTML API where essentially you


add something to your URL where it goes to that specific text


segment of the page.


But kind of that jumping to that part of the page that


is essentially separate from passage ranking.


So in short, I don't really have a great answer for you


other than that perhaps this helped to explain


what passage ranking is.


But kind of the jumping to a specific part of a page,


that's something that is almost like if we can figure it out,


we'll try to do that.


But it's not something that we will automatically do just


because it's there on a page.


I have a client who created a new service


page for kitchen and bathroom remodeling,


two very different pages, different from any other service


pages on the site.


I requested crawling a few times over the past month,


but these are not being indexed.


When I inspect the live page, everything is good.


When I request crawling, no problem.


But it isn't being crawled, and the dates in Search Console


reflect that.


Any ideas?


I don't know.


It's super hard to say just based on this description.


It almost sounds like something where I would


need some sample URLs.


It sounds like it's a fairly small website,


and there are two new pages on there.


And usually with small websites and just a handful


of pages that are added, that's something


we can pick up fairly quickly.


So it feels a little weird that this would not


be happening that quickly.


I think one of the things to watch out for


is to make sure that the internal linking is


really well done on the site.


So if it's something new, make sure


that it's linked from your home page


or from some other important page on your website.


But it's really kind of hard to say what exactly


might be happening here.


It feels like something where if you could ping me


some examples on Twitter or somewhere else,


then that would be useful for me to double check.


And maybe one more quickly.


Any idea how to rank organically in a market


where competition is very high with high page authority sites?


For example, how to rank for Tom Ford jeans or Nike shoes,


Model X. Is there any chance to rank


in these competitive markets, or should we just pay for ads?


Obviously, there's a way to rank for these competitive markets


because other people are doing it.


But if it's a very competitive market,


there are other very smart people


that are working on the same problem.


And if there were this one simple trick


to rank very high in a competitive area,


then everyone would be doing that.


And then that one simple trick would not work anymore.


So this is something where, yes, it's possible.


But if you're starting off with a new website,


it's going to be very, very hard because other people have


been working on this for literally decades,


trying to get their pages in there.


And you almost need to get it to that level first.


So should you just go buy ads?


I suspect buying ads for a lot of these very


competitive areas are also going to be very expensive.


So my recommendation here is it sounds a lot


like you're starting out on the web


and trying different things out.


And maybe there is a good affiliate income


that's possible for some of these competitive terms


because, of course, the companies


want to sell the product.


And my recommendation there is if you're starting out,


try to find something that's less competitive.


Try to find something where you can try things out


and you can see a little bit of success step by step


and over time grow that and not jump in and try


to do the most competitive thing ever and try to sell,


I don't know, car insurance or pharmaceuticals or sport


shoes in a very competitive market,


but rather find something small and grow from that.


Cool.


Lots of people still raising their hands.


Let me just start top and see how far we can go.


Luis.


Hey, John.


Sorry.


I have everything off.


Thank you for having me.


Just a quick question.


I work for a network of 20 orthopedic doctors located


throughout the United States.


And they are all under the same umbrella


and provide the same exact services.


Aside from being located in different cities


and having different doctors, there


are no difference in their practices.


So would there be an issue if we use the same content when


building their websites and only optimizing for the location?


So for example, we have multiple websites.


And each website has an elbow surgery page.


And it has the same content, exact same content,


except for instead of saying elbow surgery in New York,


it says elbow surgery Houston.


Is there an issue with that?


Or should we do something a little more customization?


Because we do the customization for the home page


and for the about us page and for a lot of other pages.


But since it's so many other pages,


so many specific services, it's money and time


that is going towards the content.


Now, I think it's something where you almost


need to think about the competitive area as well


and think about what people would be searching for.


If people are searching for elbow surgery in general


and they want information, then maybe it


would make more sense to have a general elbow surgery page


and on the bottom have some kind of dynamic element that says,


our office nearby you is this, or the different addresses


listed there.


Whereas if people are searching for elbow surgery in New York,


then maybe it does make sense to have a unique page for elbow


surgery in New York.


And especially with regards to the more competitive markets


and competitive kinds of content,


I would really try to figure out a way


to make sure that the content is actually unique


and not just by taking blocks of text and shifting it around,


but actually making sure that it is something that is unique.


In the sense that when our algorithms look


at these different pages, that they don't say, well,


90% of the page is the same.


Therefore, we will just index one of these pages.


And then suddenly your elbow surgery Florida page


is the one that is indexed and ranking,


and the New York page is seen as a duplicate of that.


And just to be a little more specific,


there are different websites.


So they're not housed within one website.


So is that still applies what you're saying?


Yeah.


OK.


I think that would still apply there.


So that's something where I think


if you want to create separate pages for this,


I would just make sure that they're really unique.


Because it's something where you really


want to make sure that Google's algorithms don't


look at those pages and say, oh, it's


pretty much the same thing as the other one that we've seen.


And we will just like duplicate one of them


and make it easier for you.


Because our algorithms are kind of like saying, well,


we'll save you the hassle of having


to crawl all of these pages.


We'll just crawl one of them.


But you probably want all of them crawled.


Yeah.


OK.


I appreciate your answer.


Thank you.


Sure.


Cool.


Jason.


Thanks, John.


So this could be tangentially related


to Omar's question earlier.


I have a sneaking suspicion your answer


is going to be either it depends or that's


sort of a strategy decision.


But I'm going to ask anyway.


So previously, you've recommended a pyramid site


structure in terms of navigation and menus.


And in terms of crawlability and sort of the page rank flow,


I could definitely see how that would be beneficial.


I built several sites myself that way.


But my question is, could you see any advantages


from an SEO standpoint to like a dynamic menu, which


may change based on either like content relevance


or maybe like user journeys that we've


identified through analytics or something like that?


I think that makes sense.


I mean, it's something where my guess is when Google looks


at these pages, the menu would essentially


be static for Google because we wouldn't use cookies


or anything like that.


So you wouldn't be able to recognize, oh, this user was


here first and then went here and then went here.


So from our point of view, we would look at that and say,


well, these are the links on this page.


And they're essentially created in a dynamic way


on your back end.


But for us, it's still like, well,


these are the links on this page.


These are the links on that page.


And we understand how kind of the connection there is.


So that, from our point of view, would be perfectly fine.


I think if there's something within your navigation that


depends on how the user is navigating through your website


and you need that reflected in search,


then that's a little bit trickier because, obviously,


Google crawls without cookies.


So we wouldn't kind of keep that trail for you.


Sure, yeah.


And for context, I'm not necessarily


talking about personalization from that standpoint.


I'm thinking in terms of we've noticed in our analytics,


we have a key page view for a sale.


So if we take that page that is viewed before the sale


and we link to the sale page, and there we go.


We should naturally improve that.


I don't necessarily mean following a user with cookies


or anything like that.


And I mean, kind of going back to the content relevance


portion of the question, I mean, yes, from Googlebot's


perspective, the content would be static.


You'd visit the page.


You'd see the same links one time versus another in theory,


unless we've added more content, which we've deemed relevant.


I mean, I guess Googlebot doesn't necessarily


know all of the underlying markup


that we have on server side to know what pages


are more relevant to others.


So in that sense, it could change.


But yeah, I guess linking by relevance


in a dynamic way on menus is kind of the SEO question


I was trying to get at.


Yeah, I think that's also pretty common.


So a lot of the blogs have that set up


where you have related posts linked on the bottom,


essentially.


And that's essentially the same direction


that you're talking about, where whatever on the back end


is recognizing these are some keywords in the current blog


post, and we have similar keywords in other blog posts,


I'll link to them.


And that works well for the user,


and it also gives more context for Google


when it crawls the web pages.


So I think that's kind of a good approach.


Cool, thank you.


Cool.


All right, Nathan.


Hi, John.


Can you hear me?


Yes.


OK, great.


I had to switch to my phone because I


kept getting disconnected.


I work on a publisher website, and the content


is gated, so that means that about 50% of the content


is available without sign-in.


What I noticed was that in Google's search console,


when I view the crawled page, it shows the entire page,


including the ungated content and the gated content.


But when I go onto Google search and I


try to see if the entire page is indexed,


it doesn't appear to be indexed.


Do you have any ideas on how I can change that so


that the entire page is indexed?


Because it looks like other gated websites


have their entire page indexed.


We have some guidance on that for flexible sampling,


essentially, is the name that we have for that, where


essentially, you can use structured data markup


on these pages and let us know which parts of the page


are gated enough.


And you can then dynamically serve those pages


to Googlebot slightly differently than you


would to the average user.


So that's kind of the general setup there.


And that would mean if you use something like the URL


inspection tool, you would see the full content together


with this markup.


And we would index those pages with that markup.


And essentially, when a user goes to those pages,


they would have that gated or limited access setup,


essentially, from that point of view.


OK, so are you alluding to the paywall markup,


where in the CSS side, you essentially


do the you have the schema calling out which classes


in the CSS classes are the gated content?


Is that what you're alluding to?


Let me just double check.


That's the best I can find on that.


That's why I'm asking.


Yeah, I think so we have this documented


as flexible sampling and also as subscription and paywalled


content from a structured data point of view.


And I think that's the one that's


where you specify the CSS selectors


for the different types of content.


OK, I think that does it.


I'll look into that and get back to you


if I don't see anything changing.


All right.


All right, thank you.


Fantastic.


OK, let me take a break here with regards to the recording.


I'll be around more, and there's lots of hands still up.


So we have stuff to go through.


If you're watching this on YouTube,


thanks for watching so far.


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


we publish them in the event calendar


on the Search Central site and in the community section


on our YouTube channel.


So you're welcome to jump in and ask your question live


or post a question in the comments as well.


And with that, let me see if I can find out


English Google SEO office-hours from October 27, 2020

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


Office Hours Hangout.


My name is John Mueller.


I am a webmaster trends analyst at Google in Switzerland.


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


where people can join in and ask their questions


around their website and web search.


A bunch of stuff is submitted already.


But if any of you want to get started,


feel free to jump on in now.


I have a question.


I have a question about dynamically loading content.


So if I have a really long page, like a long article,


so it's going to have a lot of text, images, and some ads


on there as well, are there any best practices


for dynamically loading that with using JavaScript


while making sure that Google can properly


crawl and render that content?


I mean, sorry, crawl and index it?


Yeah.


I guess this kind of goes into the topic of lazy loading


and infinite scroll in that regard.


So that's something where I guess, first of all,


you kind of have to make a decision on whether or not


you want that content indexed or if it's critical for your site


to have that content indexed or not.


Sometimes when you use lazy loading or infinite scroll,


you're kind of adding content from other pages.


So it doesn't necessarily need to be indexed.


But if you do decide that it does need to be indexed,


we have in the developer documentation


some information on how to implement


lazy loading in a way that works well for search.


And I would just double check that.


So I think in general, what happens


when we render the page to process the JavaScript,


we render it with a fairly high viewport.


And basically, we see what gets loaded into that viewport.


And when we see that everything is finished loading,


we use that for indexing.


Whereas if you have code on your page that


watches out for specific events that take place,


like someone is scrolling down to a certain position


of the page or clicking a Read More button,


then probably those are things that won't get triggered.


So that's just very roughly kind of the difference there.


If it's loaded on page load, probably we'll index it.


If you have to do something special to make it load


into the page, then it's very likely


that we won't be able to index that.


OK, so I reviewed the lazy loaded documentation on it.


OK, and then you mentioned that it will just crawl using


a really tall viewport.


So does that mean that if the content is so long that


exceeds what the Google Apps viewport would be,


then the content left out at the bottom


would just not be indexed?


No, it's not that it wouldn't be indexed.


It's just that we wouldn't use that to trigger


kind of additional loading.


So I think it uses the viewport observer or something


like that.


I forgot what the actual name was.


To kind of trigger the code on the page


to say the page is now this tall.


And if your code is waiting for a sign


that the page is now a little bit longer than that,


then that's something we won't trigger.


It's not that we'll stop indexing at that viewport


height.


It's just that's what we'll use to kind of trigger


the JavaScript on the page.


OK, OK, so if the trigger doesn't fire,


then essentially that content also wouldn't be indexed.


I see.


OK, and what's the best way to check if the content is


being properly indexed?


I have been using the mobile-friendly tool.


I don't know if there are any better ways to do it.


You can't see the full size of the page in the screenshot.


So I'm not super clear if the content is being indexed.


Like right now, I have all the content


in a JavaScript variable on the page, which I do see.


It's on the page source, and I do see it


when I test it with the mobile-friendly tool.


But I can't tell if that means that Googlebot is actually


reading the content inside the JavaScript variable


or if it kind of ignores it.


So what's the best way to check that?


What I usually do is just take a piece of that content


and search for it in quotes, like one sentence or four


or five words, and just double check that it actually


shows up in search.


And if it shows up in search, then that's


kind of the ultimate proof.


With the testing tools, you can use


Inspect URL to look at the fully rendered HTML page.


But it's sometimes a bit tricky, especially


if you have a code in JavaScript as well as on the page.


What actually are you finding there?


So usually waiting until one of those pages is indexed,


and then just double checking if it actually goes down that


part is kind of the, I guess, the most secure approach.


OK, so I actually did try that, and I get kind of mixed results.


What would be the possible explanations for an image being


indexed lower down on the page, but the text in that same area


not being indexed?


I don't know.


Hard to say.


It kind of depends on how you have


things set up on your site.


So one of the differences also with regards


to images and the textual content


is we tend not to re-index images that frequently.


So if, for example, one time out of 10, we can crawl the page


and find the link to the image, then we'll pick up that image


and put it into image search.


Whereas if the text changes from time to time,


then we'll always have that version of the current version


for text.


So the image might be a little bit more stable


just because we just don't refresh it that frequently.


OK.


OK, that makes sense.


Thank you very much.


Sure.


All right.


Any other questions before we jump in with the rest?


John, I have one regarding expired products


on e-commerce websites.


So we're working with a shop that


manufactures its own products.


It's a jewelry shop.


Products are unique.


They make one of each.


They sell out, and then that's gone.


They don't usually make the same products again.


They might make similar products,


but not the identical same product.


The thing is, once they go out of stock,


they still do seem to get a lot of traffic from Google Images.


So with jewelry, people are looking a lot in Google Images,


and it's kind of an emotional purchase.


They click on it just because they really


like what they see.


And the site employs a section that this is not in stock


anymore.


There are very similar products that you might want to purchase.


So is it kind of a good idea to keep those products,


even if they're out of stock in this case, to keep them active


so they still get traffic from Google Images


rather than either for affording them or redirecting them


to something else, a category or something like that?


Is there any downside to that?


Yeah, I think in a case like that,


where these are kind of unique products


and they're representative of the business or of the website


overall, that seems like something


that I would try to keep somehow.


And that could be that maybe you have an archive


section of your website or kind of similar products


that we've sold in the past kind of thing


just to keep that kind of content


available so that people can browse that.


Because it feels like that particular thing is out


of stock, but it's representative of the kind


of work that you do.


And that might still be useful to actually have


some of that indexed.


With regards to how you keep that indexed,


I would try to move that more into an archive section


or kind of like, I don't know, things


that we've done in the past, references, something like that,


rather than keeping a product page live,


where it says, like, this product is out of stock,


or you can't buy this product anymore,


and it was like a one-time thing,


and here's a photo of it.


Now, because those kind of out of stock or not available pages


generally tend to end up as soft 404 pages.


And when they go into soft 404 state,


then the landing page disappears from search.


And with that, the image is also kind of lost.


So if you have the image on kind of an archived page


that remains for a longer time, then that image


can remain in image search longer


than if the product landing page ends up dropping out of search.


AUDIENCE 2 Now, I see.


So in their case, they have products


like they've been out of stock for a year or two,


something like that, and still seem to be indexed


and are getting traffic.


Should they start to begin to think about restructuring


that, using that?


Or once they see that those pages start to get de-indexed,


maybe that's?


Yeah.


I mean, with soft 404s, it's sometimes tricky,


because obviously, if there were a clear sign saying


that this page is 404, then we would just


be able to drop them out.


And sometimes, or in general, we try


to recognize text on the page that's telling us, well,


this is no longer available.


So that includes things like search results,


where it's like no results found, also products in general,


where it's like this product is no longer available.


If those product pages are created in a way that


don't have this kind of not available text on it,


but more like we sold this to this price kind of thing,


then that could be something that could remain.


But in general, if it's a product page


and you have a text on there saying,


this is not available, I would assume at some point


we will notice that as a soft 404 and stop dropping those.


Right.


Well, it's currently just out of stock.


So I don't know if Google received that in any way.


Yeah.


And if we include it in structured markup, structured


data markup, and it shows up out of stock,


I think that's a good user experience as well,


because people who really understand it's out of stock


and don't want to visit it, fine.


But people who might want to see similar products,


they can go in and see it.


But I was just curious if there's


any significant disadvantages of leaving


a lot of these products, pages indexed overall.


My general feeling is that I don't


know how many of these products end up being there,


but it feels like it's very easy to create


a mass of pages that are kind of low quality-ish


and that don't tend to attract a lot of attention.


Whereas if you were able to concentrate


some of those existing products and put them


on a gallery or references or kind of an archive page,


then that content could collect a lot of value over time


and still be relevant.


You wouldn't have all of these hundreds or thousands


of other pages that are essentially,


like if people go there, they can't


buy what they wanted to buy.


But if we're talking about 20, 30 pages,


then it's like that doesn't really matter either way.


But if these are really thousands of pages every year


that end up going into this state,


then that feels like a lost opportunity.


And in cases those pages do remain indexed,


does Google look at maybe how well the overall user


experience, how easy is it for people


to go to similar products or something like that?


Do they see a product out of stock?


How the design and everything works towards still


recommending them a very similar product or something


that they keep the user on the site


and satisfied with maybe some different product


on a similar price that looks promising?


I don't think we'd have anything direct to go in that direction.


But indirectly, that might be something


where if people land on these pages and they're like,


this is terrible.


I wanted this, but I can't get it here.


I'll see if I can get it somewhere else.


Then that's something where it's like you end up


losing that potential recommendation from someone.


AUDIENCE 1 OK, so as long as you don't frustrate your users


and keep them satisfied, that should be the end goal.


Yeah, yeah.


I'm still, I don't know, cautious about the approach


overall.


So that's something where I, especially


depending on the number of products


that you're talking about, I would


tend to move those more into kind of like a persistent


gallery or references type section


just to make it clearer to people


and also to make those images a little bit more,


I don't know, have a little bit more weight in image search


as well.


Because over time, we'll see that this gallery section


collects a lot of value.


And then that could tell us, well, actually, these images


are really important.


Whereas if you have individual kind of lost pages


within the website, it could be trickier with competition.


Yeah, yeah, that makes sense.


I'm mainly asking since I've noticed the really large


fashion retailers.


I'm not going to name anyone.


But the really large ones do kind of keep out


of stock products for seems like very long periods of time.


So I was wondering whether there's any official way


to do this or not.


I'm assuming with our smaller, this is a smaller shop,


so a few hundred products.


So it's easier to kind of create that kind of gallery.


But with very large retailers, I'm


guessing that might be a bit more of a challenge.


Yeah, I think that's something also where some sites have


kind of policies where they say, well, we


try to keep it in like on the website for at least a half


a year.


And then afterwards, we just remove it kind of thing.


And you can play around with different variations of that.


And depending on what kind of products you have,


what people are searching for, that's


something where you can get some value out of it.


Even if you currently don't have it on stock,


maybe you have it in a different color or a different brand


or whatever.


Those are all variations.


Cool.


Thanks.


All right.


So I have Brittany's question on top.


I don't know, do you want to go into it briefly,


or should I just read it?


Sure, I can jump in.


So we did a domain migration at the beginning of August


with pretty much entire traffic loss.


In the past few weeks, we are at about 60% traffic loss.


So more broadly asking for updates and advice.


But one specific question I have is


we've been working on a CMS rewrite that


would allow us to render our content server side.


Since right now, we render a lot of our content client side.


We've been having some issues with CLS, some UX issues.


We're dependent on pre-render.


So we think this would be a great investment for our users.


But we are a little wary of making such a big back end


change when it seems like Google is still really not fully


processing our domain migration and passing


all of the signals from the old domain to the new one.


So I was wondering if you had thoughts on whether this is,


if it's too risky to do such a big back end change right now,


or if we should just be full steam ahead,


or how we sort of make these decisions while we're


in the stage that we are.


Yeah, I mean, it's always frustrating to hear cases


like that where essentially domain migration where usually


they kind of go smoothly or it just doesn't work out.


So I've been pinging the engineering teams about this,


I don't know, pretty much every week,


just to make sure that it stays top of mind.


But I can't promise anything.


I don't know what the final state there will be.


But in general, with regards to further updates


on the website, I would just keep working on it.


I don't see any reason to kind of wait and not make changes.


The one thing I would not do is another migration kind


of change, which probably you're kind of healed from that anyway.


But that's the one thing I would try to avoid.


But changes within the website, that seems


like a perfect thing to do.


One thing to keep in mind is if you make changes


within the website that result in the URLs changing,


then you're also kind of redirecting,


and it's a little bit harder to track what was there before,


what was there afterwards.


But if you're able to make those changes with the back end


without changing the URL structure of the website,


then that's basically just an improvement overall.


And that feels like something totally unproblematic to kind


of work on.


And especially if you can improve the usability,


if you can improve the speed overall,


those are always good things.


SPEAKER 2 OK.


I don't know if you recall, but when


we started on this domain migration plan,


the idea was we have two fairly similar products.


We wanted to take our flagship product,


get it on the domain that we really wanted to move to,


we thought it was a fresh domain,


and then take a weaker product and merge it in.


So long term, we are hoping to stay on the domain we're on.


We're obviously hoping to see some more recovery.


But we're also hoping to merge in our weaker domain that


covers a similar topic.


So would rebuilding pages on our new domain and redirecting,


would that be in that area of URL changes


that you're saying we should be wary of?


SPEAKER 1 I think that would be fine.


I'm adding more content, essentially


moving some further content from another site in there.


I think that would be fine.


No, I don't see any problems.


It's more trickier if you take your top pages


and you change those URLs, and that


means you change all of the internal linking


structure of the website.


That gets kind of tricky.


But if you're adding more content,


that feels like a perfect move.


Kind of keep building on what you have there.


SPEAKER 2 OK.


And one more question, and I'll sneak in.


So technically, we're still in that period


where Search Console says we can cancel our migration.


We don't want to.


We want to see this through.


But we're not removing any possibilities at this point,


since this is having such a dramatic impact on our business


and ability to operate.


Yeah, do you have any thoughts on when or if we should


consider reverting the domain migration,


or if that just at this point seems as scary to you


as it does to me?


Yeah, I would try to avoid reverting,


because in general, that just makes it trickier.


Because then it's not so much that everything goes back


to the old domain, and it suddenly just becomes


just as visible as before.


It's basically you're taking the current state


and then moving that to a different domain.


And you're kind of moving with this weird mixed state


at the moment.


So I don't think that would make anything better.


OK, thank you.


Sure.


All right.


Let me go through some of the other questions.


I wanted to get your thoughts on a project that I'm working on.


I am separating one website into two websites,


as the business now offers two totally different services.


So far, I've replicated the pages


that need to move on the new domain,


applied the rel canonical tag to those pages on the former


domain to the new location.


Once Search Console and the search results start recognizing


the new location for those pages, the plan


is to apply 301 redirects.


And let me see where this is going.


Long question.


Is there anything that you would recommend


to kind of minimize the risk of losing damaging visibility?


So in general, when you take one website


and you split it off into two websites,


it's not something that we would see as a domain migration,


because you're essentially generating a new state.


You have kind of the previous state, this one big website


that you have, and then you're generating two separate websites


out of that.


So it's really hard to say ahead of time what the final state


will be with regards to search.


But in general, if you are able to move things


on a per-URL basis, if you're able to kind of fix


the internal linking so it works well


within both of those websites, then that


seems like something that should be fairly straightforward.


And I think the approach that you're taking here,


where you're generating these two websites


and then using rel canonical to kind of get things started


and then setting up 301 redirects,


I think that's perfectly fine.


You could probably also just do the redirects from the start


and just saying, well, these are separate pages,


and they moved here.


And the internal linking on both of those sites, if that's OK,


then that should just work out fine.


One thing I would recommend, though,


just in general with regards to any kind of move like this,


is that you track things really meticulously.


So really keep track of all of the URLs that you have before.


Double check all of those URLs afterwards


to make sure that they're all redirecting appropriately


so that you don't run into a situation where


you move some URLs, but you forget about others.


And then after half a year, you notice, oh,


why is the wrong one being indexed?


And then you set up redirects for those as well.


So really, from the start, set up a really clear plan


for how you want to handle the migration.


And that also lets you use automated crawlers


like Screaming Frog or some others


out there to double check your new websites


to make sure that you have everything set up properly.


So that's kind of the one thing I would watch out for there.


We also have tons of advice in the Help Center


on handling these kind of migrations.


But I think it sounds like you have a lot of stuff already


under control, so probably you've seen some of that.


How does Google crawl podcasts?


Do links from guest podcasts from, say, Spotify make sense?


So we have, I guess, there are two aspects here.


One is we show some podcasts in the search results directly.


And that's based on the ability to recognize where podcasts are.


And we have a lot of Help Center content


on that, which gives you information


on how to set up an RSS feed for podcasts,


how to make sure that we can find your podcasts, all


of those things.


So that's kind of the main thing,


I would say, with regards to podcasts.


And the other is, of course, the angle of, well, actually,


these are also web pages as well.


And when it comes to web pages, you


can treat those just like any other web page.


The thing to keep in mind with podcasts, in particular,


when they're hosted on web pages is


we don't try to do any kind of text analysis on a podcast file


to recognize what you're saying within the podcast.


So if there's something in there that you


think is critical for your pages to show up in search,


then make sure you put it in text form on your pages


as well.


A really simple way to do that is just


to post the transcript of your podcast


together with your pages with the link


to the individual podcast episodes, for example.


So in that regards, there is nothing really tricky


around podcasts.


It's just that there are those two angles, kind of like,


the podcasts themselves can be visible


and the web pages can be visible in search.


By Google standards, our pagination pages


have become canonical by themselves.


But the problem is that sometimes the next pages


get impressed and clicked.


Now we doubt whether the pages should


be canonical to the first page or have the current status.


What should we do to prevent the next pages from being indexed?


We've written a description for the first page


and send the FAQ to Google with the schema.


But is there a way that the next pages will not be displayed


in the search results?


Good question.


So I think we get this question a lot.


And it's something where it feels


like there are differences of opinion


with regards to pagination.


And I think one way to look at it


is to consider why you're setting up


pagination on your site.


So if you, for example, if you have an e-commerce site


and you have a category page and you have pagination


on the category page, then one of the goals of that pagination


is to make sure that the individual products themselves


are actually findable.


So you can go to page 2, page 3, page 4, page 5,


and then you see the link to individual products there.


And that can be really important to get those products indexed.


On the other hand, it might be that you


have all of those products already indexed


because they're really well cross-linked


within your website.


Then the indexing through the paginated category pages


is not as critical.


And that's kind of the first decision


you need to make there.


Is it critical for you that these kind of paginated pages


are indexed and findable in search in terms of,


is the content that you're linking from those pages also


critical to be linked from and recognized


from those paginated pages?


If you decide that those paginated pages are


critical for search and that the products are critically linked


only from those category pages, then you


need to let those be indexed.


If you decide that these products are already


indexed elsewhere, that they're well cross-linked


within your website, then you could decide to say,


well, actually page 2, page 3, page 4


is not something that I need to have indexed


because those products can be findable elsewhere.


And if you decide that those pages don't need to be indexed,


then of course you can do something like the rel


canonical here to canonical back to the first page of that list.


If you decide that they do need to be indexed,


then you'd need to canonical to the individual paginated pages.


Usually the next level from here is when you apply filtering


or when you have other kinds of searches


within those category pages.


And usually that's the step where you can say,


well, these definitely don't need


to be indexed because they're already indexed


through either the paginated pages or normal cross-linking


on the website.


So all of those filters, that's something probably you


can block from being indexed with either no index


or with the rel canonical to go back to your main category


pages.


So those are, I guess, the two aspects there.


It's interesting when we talk with the engineering teams


at Google, we will get very strong opinions


and they will go in both directions.


And I think that is reflected in the fact


that websites are set up very differently.


And some of them need those paginated pages to be indexed.


And some of them just don't need to have them indexed.


And they can focus more on the kind of page 1


of the search results.


In general, though, if those pages need to be indexed


so that we can find your products,


then they can theoretically appear in the search results.


So there's no way to mark those pages as,


I want you to use these for indexing,


but don't show them in search.


That's not something that you can flag with a meta tag.


In practice, in a lot of cases, though,


if you set up pagination so that you're linking from page 1


to page 2 to page 3 to page 4, then those further paginated


pages will be even further away from the root of your category


set.


And usually that means if someone


is looking for that category set,


then probably they'll find the first page from the category


set that you have there, because that's just the strongest page


on your website for that category.


On the other hand, if someone is searching for maybe


a category and a product that is only listed on page 5,


then maybe we will show page 5 in the search results.


So lots of options, lots of variations there.


It's something where it's easy to talk with people,


and they have very strong opinions about which way you


should handle this.


And it's worth considering that your site is kind of unique,


and you need to figure out what makes sense for your site


there.


What should be the best thing to do with products that are out


of stock, but they might be back in stock?


Oh my god, Mihai, did you plant this question?


No?


OK, I think we talked about this briefly before.


Oh, I guess this variation here is


that they might be back in stock again at some point.


And that seems like something if you're


sure that this is more of a short-term kind of out


of stock situation, then I would just keep that in mind.


And if you're sure that these are unlikely to come back in,


and you're sure that you're not getting any traffic for them


anymore, then I would just make them 404.


For the last two weeks, page actions like request URL


for indexing in Search Console have been temporarily disabled.


Do you have an update when this will be back to normal?


I don't have an update at the moment.


I know the team has been working on this,


but I think it's going to be a good thing.


The team has been working on this,


but I don't have any timeline that we can share there.


Usually, these kind of things settle down fairly quickly,


but sometimes there's more involved than just


tweaking things slightly.


And we also don't want to just re-enable the feature in the UI


and then not actually do anything with the submissions


in the back end.


We just want to make sure that everything works well there.


On a large website, if a few pages


have a few 404 outlinks within the domain,


can Google consider that the page is low quality, outdated,


or not fresh?


I don't think so.


So it's something where users might get a little bit confused


if they go to your site and then get lost within your website.


But in general, for Google, it's completely normal


that some links are just 404.


And when we crawl and index one page,


we don't necessarily follow all of the links all the time


directly.


But rather, we will crawl that one page,


and then we will add all of those links to our scheduler


and say, we should take a look at these other pages as well.


And if at some point we crawl those pages


and they turn into 404s, then we're just like,


well, this link led nowhere, but that's fine.


We have enough other content on the website to focus on.


So we wouldn't flag a page as being low quality just


because there's some 404 links on a page.


As the EAT algorithm is becoming more prominent to improve


the overall site quality and important passages in web page


are becoming a ranking signal, can we


consider including more FAQs and landing pages


to be competitive in Google search results?


So I think the different sides there don't necessarily


have much to do with each other.


We use EAT as something primarily from the search


quality raters that we include in the quality rater guides.


It's not something that we would say


like there's a simple algorithmic factor that just


does this.


So that's something where essentially what


we tell the search quality raters to watch out for


are things that normal users would watch out for as well.


And if you improve your website in that regard,


then that seems like something that


would make sense regardless of any algorithms and changes


on Google's side.


With regards to including more FAQs on the landing pages,


you're always welcome to do that.


I think sometimes it makes sense to include FAQs on pages.


Other times, especially when talking


with some of our tech writers, I've


heard that having too many FAQs on a page


is kind of a sign that your content itself


is kind of hard to understand and almost a signal


that you as a writer should consider making sure


that people don't run into these questions


after they read all of your content.


But sometimes having simple questions and answers


on a page makes a lot of sense.


With regards to the structured data side of FAQs,


that's something that's totally up to you.


If you have pages with FAQs that match our guidelines,


then we might be able to pick that up and show


that in the search results.


That's, I think, less a matter of being competitive


in the search results because it's not


that you will rank higher with FAQs on your pages,


but more like you will be visible potentially


with those FAQs being shown.


Just a quick follow up to that.


I noticed that some travel websites are using FAQs


for their hotel pages.


And then you have an FAQ like, does this hotel


have a swimming pool?


How's the breakfast?


And things like that.


And I'm not saying that's an issue or not.


I think that looks fine.


But the documentation mentions that whatever


is in the FAQ structure data markup


should also be on the page.


I'm just curious, should it be word by word?


I mean, if they have hotel facilities and you have pool,


do you still need to have that complete text answer like,


does this hotel have a pool?


Yes, this hotel has a pool.


And whatever you're showing up in the structure data markup


should be word for word what you have


and the content of the page.


I think that's kind of the goal.


So with FAQs based on the content itself,


I think that's a little bit tricky


because the individual words might be on the page,


just not in that order.


But in general, with structured data,


one of the things that our algorithms do


is really try to make sure that the content itself


is on the page.


And it might be with FAQs that these algorithms are


a little bit more flexible in that they say, oh, well,


most of the question is directly visible on the page.


Therefore, we'll let this one go.


But it is something where potentially those algorithms


might get a little bit more strict and say,


well, this text, one to one, has to be visible on the page.


Because we want to avoid the situation where


we're promising something to users in the search results,


and they go to the page and they can't actually find it.


They have to look for the information, yeah.


Yeah.


So it's like, does this hotel have a pool?


And you go there and you search for does this hotel have a pool?


And then you're like, there's no results.


Like, why was that shown in search?


Whereas if you search for just pool and it says yes,


then it's kind of tricky.


But I could imagine our algorithms are currently


in a state where they're a little bit more flexible.


But I don't think that's something


that you can rely on, where if we really


have in our guidelines, you should make sure


that this text is on your page, then at some point


our algorithms might say, oh, we really


need to make sure that this is actually on the page.


Yep.


A question related to the discontinuation of Flash.


Oh, wow.


Flash from the past.


I work on an online gaming site where we still


serve quite a lot of Flash games.


In terms of quality, they occupy roughly 50%


of their pages on the site.


But in terms of organic traffic, they


only account for about 10% of our total traffic.


After December 2020, should we anticipate


a complete loss of traffic only on this portion of content,


or will there be wider site repercussions


if we don't take steps to remove all of those pages that


serve Flash games?


So that's, I guess, an interesting question,


because I think what you're referring to there


is that Flash is, I think, going to be removed from Chrome


or something around like that.


In general, this wouldn't affect how we index this Flash


content.


And I wouldn't see it as something where we say, well,


there's Flash on this page.


Therefore, this page should not be shown in search.


But rather, what I imagine is probably already happening


here is we're indexing this page based


on the content that's visible in the HTML, that's


visible in the DOM when the page is rendered.


And if there just happen to be some elements on the page


that we can't process because they're in Shockwave files


or whatever Java applets or, I don't know,


whatever technology is still in use,


then we will essentially just ignore that part of the page.


We won't say this page as a whole is bad.


We won't say this page as a whole should not be indexed


because we have enough useful information


from the rest of the page.


So probably, in your situation, my guess


is that nothing big will change with the traffic


that you're seeing through your website


because probably we're already indexing your content based


on the HTML content that you provide for these games,


not based on the content within the Flash file.


In the past, it was a little bit different


because some sites were completely made in Flash.


And there, it was such that we did


use the content from the Flash files as a part of indexing.


But when it comes to games, there's


usually not a lot of textual content in these Flash files


anyway.


So I would expect that we're probably indexing things


just based on the HTML anyway.


So probably you wouldn't see any change at all in search.


We were unsure whether the consent management provider


banner would negatively influence


the crawling of our pages.


Therefore, excluded Googlebot via the user agent.


This means Googlebot doesn't get to see the banner at all,


but the user does.


Can this procedure be considered as cloaking and lead


to a penalty?


It does kind of go into the area of cloaking,


especially depending on the way that you


have those banners set up.


And I don't know, judging from your name, I'm guessing,


maybe you're based in Europe.


One of the things that might come into your site's advantage


is that if you only show this banner to users in Europe


and you don't show it to users elsewhere, then in general,


you wouldn't be showing it to Googlebot anyway, because


Googlebot tends to crawl from the US.


So that's kind of one approach to take here.


The other side here is that when it


comes to cloaking and a penalty or manual action,


usually the web spam team tries to take into account


the intent of what the site owner is doing there.


And if we can recognize that this is clearly


a legal interstitial and we're essentially indexing


the content that users would see anyway


when they go through that interstitial,


then probably from a web spam point of view,


that would be less problematic.


So that's kind of the other side there.


That said, I would still, especially


if you're showing this banner to everyone,


I would double check to make sure


that it actually is causing problems


for the indexing of your page.


And maybe you can really just simplify it by also showing it


to Googlebot there.


One way to double check with regards to Google indexing


if this banner is a problem or not


is to use the Inspect URL tool in Search Console,


fetch a live version of the page, have it rendered,


and then you can check in the HTML of the page


to see if the actual content is visible there too.


And if the actual content is visible there too,


then that's something where the banner probably


doesn't cause any issues for indexing anyway.


So maybe one of those options is something


that would work for you.


On a non-medical, high search volume niche site,


do quality raters manually rate, check top sites of the niche,


and ask Google to demote the rankings of the site?


No, we don't do that.


So quality raters are essentially one of the ways


that we test algorithm updates, where


we say we would like to make a change


in this particular direction.


And then we will give information


to the quality raters about that change that


could be in the form of A, B search results,


where we say this search result versus a different one.


And we generally give them information


on what to double check for.


Should they just look at the titles of those pages?


Should they actually look at the content of those pages?


Should they look past just the content of the landing page?


Anything like that.


And the quality raters will review


all of these different search results and give us advice


and say, well, the version without your change was better,


or the version with the change was better.


And based on that, we can work step


by step to improve the quality of the search results.


What they don't do is say, this website is bad,


and you should demote it in search kind of thing.


So just because a quality rater looks at a website


doesn't mean that they're going to change the search results


just for your website.


They review search results on a larger scale.


And any search changes that we make


tend to be reflected in a large number of sites.


So just because one site goes one way or the other way


doesn't mean that the search results will change overall


just because of your website.


So I don't know.


I guess the short answer is really just no.


The quality raters don't manually


rate websites and make changes or make suggestions


with regards to changes for the rankings


of individual websites, but rather they


try to review the changes in the algorithms overall.


One of my clients' English version and French version


of website design is totally different.


When implementing hreflang, will this be an issue,


or should both versions look the same?


That's perfectly fine.


Sometimes different language, different country versions


look completely different.


Sometimes the audience targeting is slightly different.


Often it's such that the words are not translated one by one,


but rather you do keyword research in one language


and you do keyword research in the other language.


And they're essentially trying to cover the same intent,


but the content and the way you present that


can be completely different.


So just because the website is a little bit different,


that would be totally fine.


Let's see.


Is it OK to submit the same sitemap in a sitemap index


file and separately in Search Console?


Because when we submit it separately,


we see index coverage of the individual file.


You can definitely submit them individually and separately


if you want to do that.